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.
6. 시스템 관리는 ‘Sysadmin 2.0’
• ‘모니터링’은 웹사이트에 어떤 일이 일어났는지 이해하기 위해 중요.
• Twitter는 중요한 metrics를 거의 실 시간으로 모니터하고 있다.
• 시스템 관리자에게 큰 변화가 생긴 것을 발견. 이것을 ‘Sysadmin 2.0’이라고
부른다.
• Sysadmin 2.0은 데이터를 모아서 수학이랑 과학적 방법을 이용하여 이것을
분석하여, 무엇이 일어났는가를 데이터를 기초로 판단하는 역할을 한다.
• 모으는 데이터는 Apache, Ruby 등에 대한 로우 레벨 데이터, 레이턴시,
메모모릭 등. 사용하고 있는 것은 cpdump, tcpdstat, yconalyzer 등.
7. Rails와 로깅
• 많은 사람들이 Rails의 성능 문제에 대해서 물어보고 싶어 하는 것을 알고
있지만 우리들이 경험한 성능 면에서의 문제에 대해서는 Ruby가 직접
관계된 것은 없었다.
• 가베지 컬렉션, Replication Lag, SQL 문제 대 부분 여기가 문제였다.
• 로그를 얻기 위해 syslog는 높은 부하 환경에서는 도움이 되지 않는 것을
알았다. Syslog 데몬이 다운하며 어떤 데이터도 얻을 수 없게 된다.
• 장애가 발생했을 때 로그를 분석하는 것은 중요하다.
Facebook의 오픈 소스 Scribe와 HDFS로 이행하였다.
대규모 분석은 Hadoop으로 하고 있다.
8. Dashboard
• Dashboard가 모니터링에서 처음 보는 화면
• 여기에서 무엇이 일어 나고 있는지, 10개 정도의 중요한 metrics에 대해서
보고 있다.
• 잘 한 것으로 쉘 스크립트로 만든 ‘Whale Watcher’ 스크립트.
• Twitter의 에러로 HTTP 503(timeout)이 발생하면 고래가 나타나고, HTTP
500(error) 때는 로봇이 표시. 예전에는 60초 마다 이것들이 얼마나 발생하는
집계하여 그래프화 하였다. 이것은 큰 도움이 되었다.
9.
10.
11. Darkmode
• 작년에 많은 시간을 들여서 배포 프로세스를 개선하여 코드를 보다 빠르게,
그러면서 에러 발생을 줄여주는 배포를 하였다.
• 코드를 배포할 때는 Release 전에 기능을 블럭하는 ‘Darkmode’를 사용한다.
• Darkmode에는 90개 정도의 기능을 정지하는 스위치가 있다. 이것을 아주
강력한데 예를 들면 프로덕션 상태에 있어도 장해에서 회복하기 위한 기능을
off 하는 것이 가능하다.
12. 서브 시스템 - loony
• 운영 관리상의 최대 문제 중 하나는 어느 머신이 어떤 것인가를 확인하는 것.
• 매니지드 호스팅을 사용하고 있지만 Web100 이라는 호스팅 상의 이름을
우리들의 이름에 매핑하고 있다. 이것을 관리하기 위해서 사용하고 있는 것이
‘loony’로 머신의 센트럴 데이터 베이스 이다.
• loony는 LDAP로도 연결되어 어느 머신이 누가 액세스 하고 있는지도 관리.
리얼타임으로 관리하고 있으므로 서버의 그룹핑, 메일 서버랑 웹서버라는
역할이 다른 서버를 On-Demand로 배포하는 것에 큰 도움
13. 서브 시스템 - Murder
• 머신을 만들 때 사용하는 것이 Murder.
• 오픈 소스 라이브러리로 합법적인 P2P 기술에 의해 소프트웨어를 수 천대
서버에 빠르게 배포해 준다.
14. 서브 시스템 - memcached
• 웹 사이트가 느려질 때 많은 운용 팀이 memcached를 사용한다고 한다.
• 그러나 많은 데이터를 memcached의 캐쉬에 넣음으로서 데이터의
축출(Evictions)이 발생하여 백 링크의 트래픽이 증대해버리는 현상이 발생.
• Memcached를 사용할 때는 세그멘트마다 데이터 량에 주의를 기울여야 한다.
15. 서브 시스템 - Unicorn
• Twitter에 Request하면 로드 밸런서를 통해서 Apache에 도달한다.
• 작년 최대의 성공은 ‘Unicorn Rails Server’로의 이행이다.
16. 서브 시스템 - Unicorn
• Rails Server의 Mongrel과 Unicorn을 비교하면 Mongrel은 슈퍼마켓의
레지에 줄선 많은 열이 있지만 어느 열의 처리가 어느 정도 걸리는지
모르는채로 열을 세우는 것에 비해,
• Unicorn은 처리해 주는 순서를 자동적으로 할당해 주어 긴 열 중에서
기다리고 있도록 해준다.
Unicorn Rails Server에 의해 CPU 부하를 약 30% 줄이는 것이 가능,
메모리 사용량을 줄이는 것도 가능. 또 빠른 request를 바꾸는 것이 가능하여
다운타임이 없는 배포가 가능하게 되었다.
17.
18. 서브 시스템 - Kestrel
• 처리의 효율화를 실현한 것이 비동기화.
• 오픈 소스의 ‘Kestrel’은 memcached와 비슷하지만(같은 프로토콜 사용)
데이터를 캐싱해 주는 서버이다. 이것에 의해 request에 대해 처리를
비동기로 하는 것이 가능, 처리하는 Worker를 줄여지는 것에 의해
파이프라인의 처리가 효율화 되었다.
19. 서브 시스템 - Daemons
• Worker로서의 처리에는 daemon을 사용
• 트윗을 복사하여 메일을 보내고, 새로운 팔로워가 발생했을 때의 처리에
이때까지는 처리마다 다양한 타입의 daemon을 운용하고 있었다.
• 작년 이것을 하나로 모아서 다양한 처리를 할 수 있도록 하여 사이트 전체의
성능을 높일 수 있었다.
20. 서브 시스템 – Flock DB
• 소셜 네트워킹에서 무거운 처리 중의 하나가 누가 누구를 팔로워하고
있는지를 말하는 소셜 그래프 처리
• Flock DB 개발
• 데이터 베이스에는 MySQL을 이용하고 있지만 Sharding 레이어로서
Gizzard를 이용하고 있다.
21. Caching가 만능은 아니다
• 우리들은 memcached에 트윗을 보존하고 memcached의 오픈 소스에 큰
공헌자이다.
• 그러나 아무리 리얼타임 시스템이라도 데이터 저장소는 필요하다.
• 경험에서 우리들은 ‘Cache Everything’(무엇이라도 캐쉬해라!)은 최고의
정책은 아니라는 것을 발견했다.
• 데이터 베이스의 확장으로서 캐쉬를 사용해야 한다.
• 만약 memcached에 모든 데이터를 넣어 두면 그것을 잃어버리면 몇
시간이나 복구에 소비한다. 과거에 우리들은 그 희생자였다.
데이터 베이스에 넣어 두었다면 로드 할 수 있다.
22. 마지막으로…
• 처음부터 환경 매니지먼트 실행을 추천한다.
• 그리고 가능한 많은 로그를 남겨라.
• 우리들의 케이스에서는 하나의 설계로 모든 사이즈에 맞지 않았다.
몇 번이라도 다시 고치는 것이 발생하였다.
• 도구를 사용하여 분석해라. 로그는 인프라의 문제 해결에 있어서 가장 중요한
것이다.
