Your SlideShare is downloading. ×
Twitter의 대규모 시스템 운용 기술 어느 고래의 배속에서
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Twitter의 대규모 시스템 운용 기술 어느 고래의 배속에서

624
views

Published on

Published in: Technology

0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
624
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
6
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Twitter의 대규모 시스템 운용 기술 ~ 어느 고래 배속에서 최흥배
  • 2. • 2010년 6월22일에 열렸던 Velocity 2010 행사 • Twitter의 John Adams씨의 발표. In the Belly of the Whale : Operation at Twitter (고래 배 속:Twitter에서의 운용) • John Adams씨는 Twitter의 초기 멤버로 애플리케이션 서비스의 리드 엔지니어
  • 3. • Twitter의 현재(2010년 6월) 종업원 수는 210명 • Twitter로의 액세스는 API 경유가 75%이고 상승 중 • 하루에 6500만 트윗, 1초마다 약 750 트윗 • 최대 부한 순간은 월드컵에서 일본 대표가 득점할 때 초당 2940 트윗, 그러나 며칠 후 NBA에서 2연패를 달성한 레이커스가 우승했을 때 초당 3085 트윗
  • 4. 오퍼레이션 팀의 역할 • Peek 때도 그렇지 않을 때도 운용을 담당하면서 Capacity Planning을 하고, 성능을 개선하고, 고래 모습을 나타나지 않도록 한다. • Web 사이트 이용자 수가 500에서 수 백만, 수 천만으로 늘어나면 처음에 설계했던 설계는 유효하지 않게 된다. • 어떤 규모에서 유효한 설계는 그 규모에서만 유효하다라는 것을 배움. • 사이트 설계를 몇 번이라도 다시 생각하지 않으면 안되었다. • 이런 상황이므로 현재까지 몇 번이나 다시 하지 않으면 안되었다. • 오퍼레이션 팀의 최대 역할은 먼저 MTTD(Mean Time To Detect), 문제 발생까지의 시간을 가능한 짧게, 문제를 빠르게 발견하고, MTTR(Mean Time To Recovery), 복구를 단 시간에 끝내야 한다. • 주문, 계측, 로그(기록), 과학적 분석, 시스템 개선, 병목 제거를 여러 번 되풀이 한다.
  • 5. 시스템 관리는 ‘Sysadmin 2.0’ • ‘모니터링’은 웹사이트에 어떤 일이 일어났는지 이해하기 위해 중요. • Twitter는 중요한 metrics를 거의 실 시간으로 모니터하고 있다. • 시스템 관리자에게 큰 변화가 생긴 것을 발견. 이것을 ‘Sysadmin 2.0’이라고 부른다. • Sysadmin 2.0은 데이터를 모아서 수학이랑 과학적 방법을 이용하여 이것을 분석하여, 무엇이 일어났는가를 데이터를 기초로 판단하는 역할을 한다. • 모으는 데이터는 Apache, Ruby 등에 대한 로우 레벨 데이터, 레이턴시, 메모모릭 등. 사용하고 있는 것은 cpdump, tcpdstat, yconalyzer 등.
  • 6. Rails와 로깅 • 많은 사람들이 Rails의 성능 문제에 대해서 물어보고 싶어 하는 것을 알고 있지만 우리들이 경험한 성능 면에서의 문제에 대해서는 Ruby가 직접 관계된 것은 없었다. • 가베지 컬렉션, Replication Lag, SQL 문제 대 부분 여기가 문제였다. • 로그를 얻기 위해 syslog는 높은 부하 환경에서는 도움이 되지 않는 것을 알았다. Syslog 데몬이 다운하며 어떤 데이터도 얻을 수 없게 된다. • 장애가 발생했을 때 로그를 분석하는 것은 중요하다. Facebook의 오픈 소스 Scribe와 HDFS로 이행하였다. 대규모 분석은 Hadoop으로 하고 있다.
  • 7. Dashboard • Dashboard가 모니터링에서 처음 보는 화면 • 여기에서 무엇이 일어 나고 있는지, 10개 정도의 중요한 metrics에 대해서 보고 있다. • 잘 한 것으로 쉘 스크립트로 만든 ‘Whale Watcher’ 스크립트. • Twitter의 에러로 HTTP 503(timeout)이 발생하면 고래가 나타나고, HTTP 500(error) 때는 로봇이 표시. 예전에는 60초 마다 이것들이 얼마나 발생하는 집계하여 그래프화 하였다. 이것은 큰 도움이 되었다.
  • 8. Darkmode • 작년에 많은 시간을 들여서 배포 프로세스를 개선하여 코드를 보다 빠르게, 그러면서 에러 발생을 줄여주는 배포를 하였다. • 코드를 배포할 때는 Release 전에 기능을 블럭하는 ‘Darkmode’를 사용한다. • Darkmode에는 90개 정도의 기능을 정지하는 스위치가 있다. 이것을 아주 강력한데 예를 들면 프로덕션 상태에 있어도 장해에서 회복하기 위한 기능을 off 하는 것이 가능하다.
  • 9. 서브 시스템 - loony • 운영 관리상의 최대 문제 중 하나는 어느 머신이 어떤 것인가를 확인하는 것. • 매니지드 호스팅을 사용하고 있지만 Web100 이라는 호스팅 상의 이름을 우리들의 이름에 매핑하고 있다. 이것을 관리하기 위해서 사용하고 있는 것이 ‘loony’로 머신의 센트럴 데이터 베이스 이다. • loony는 LDAP로도 연결되어 어느 머신이 누가 액세스 하고 있는지도 관리. 리얼타임으로 관리하고 있으므로 서버의 그룹핑, 메일 서버랑 웹서버라는 역할이 다른 서버를 On-Demand로 배포하는 것에 큰 도움
  • 10. 서브 시스템 - Murder • 머신을 만들 때 사용하는 것이 Murder. • 오픈 소스 라이브러리로 합법적인 P2P 기술에 의해 소프트웨어를 수 천대 서버에 빠르게 배포해 준다.
  • 11. 서브 시스템 - memcached • 웹 사이트가 느려질 때 많은 운용 팀이 memcached를 사용한다고 한다. • 그러나 많은 데이터를 memcached의 캐쉬에 넣음으로서 데이터의 축출(Evictions)이 발생하여 백 링크의 트래픽이 증대해버리는 현상이 발생. • Memcached를 사용할 때는 세그멘트마다 데이터 량에 주의를 기울여야 한다.
  • 12. 서브 시스템 - Unicorn • Twitter에 Request하면 로드 밸런서를 통해서 Apache에 도달한다. • 작년 최대의 성공은 ‘Unicorn Rails Server’로의 이행이다.
  • 13. 서브 시스템 - Unicorn • Rails Server의 Mongrel과 Unicorn을 비교하면 Mongrel은 슈퍼마켓의 레지에 줄선 많은 열이 있지만 어느 열의 처리가 어느 정도 걸리는지 모르는채로 열을 세우는 것에 비해, • Unicorn은 처리해 주는 순서를 자동적으로 할당해 주어 긴 열 중에서 기다리고 있도록 해준다. Unicorn Rails Server에 의해 CPU 부하를 약 30% 줄이는 것이 가능, 메모리 사용량을 줄이는 것도 가능. 또 빠른 request를 바꾸는 것이 가능하여 다운타임이 없는 배포가 가능하게 되었다.
  • 14. 서브 시스템 - Kestrel • 처리의 효율화를 실현한 것이 비동기화. • 오픈 소스의 ‘Kestrel’은 memcached와 비슷하지만(같은 프로토콜 사용) 데이터를 캐싱해 주는 서버이다. 이것에 의해 request에 대해 처리를 비동기로 하는 것이 가능, 처리하는 Worker를 줄여지는 것에 의해 파이프라인의 처리가 효율화 되었다.
  • 15. 서브 시스템 - Daemons • Worker로서의 처리에는 daemon을 사용 • 트윗을 복사하여 메일을 보내고, 새로운 팔로워가 발생했을 때의 처리에 이때까지는 처리마다 다양한 타입의 daemon을 운용하고 있었다. • 작년 이것을 하나로 모아서 다양한 처리를 할 수 있도록 하여 사이트 전체의 성능을 높일 수 있었다.
  • 16. 서브 시스템 – Flock DB • 소셜 네트워킹에서 무거운 처리 중의 하나가 누가 누구를 팔로워하고 있는지를 말하는 소셜 그래프 처리 • Flock DB 개발 • 데이터 베이스에는 MySQL을 이용하고 있지만 Sharding 레이어로서 Gizzard를 이용하고 있다.
  • 17. Caching가 만능은 아니다 • 우리들은 memcached에 트윗을 보존하고 memcached의 오픈 소스에 큰 공헌자이다. • 그러나 아무리 리얼타임 시스템이라도 데이터 저장소는 필요하다. • 경험에서 우리들은 ‘Cache Everything’(무엇이라도 캐쉬해라!)은 최고의 정책은 아니라는 것을 발견했다. • 데이터 베이스의 확장으로서 캐쉬를 사용해야 한다. • 만약 memcached에 모든 데이터를 넣어 두면 그것을 잃어버리면 몇 시간이나 복구에 소비한다. 과거에 우리들은 그 희생자였다. 데이터 베이스에 넣어 두었다면 로드 할 수 있다.
  • 18. 마지막으로… • 처음부터 환경 매니지먼트 실행을 추천한다. • 그리고 가능한 많은 로그를 남겨라. • 우리들의 케이스에서는 하나의 설계로 모든 사이즈에 맞지 않았다. 몇 번이라도 다시 고치는 것이 발생하였다. • 도구를 사용하여 분석해라. 로그는 인프라의 문제 해결에 있어서 가장 중요한 것이다.
  • 19. http://www.youtube.com/watch?v=_7KdeUIvlvw 일본어 http://www.publickey1.jp/blog/10/twittertwitter.htm http://www.publickey1.jp/blog/10/twittertwitterunicornkestrelflock_db.html 참조