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