Foursquare의 MongoDB 장애 원인 분석 tech



2010년 가을에 발생한 Foursquare 서비스의 장애 원인을 분석한 주옥같은 포스트가 있어서 원글 중심으로 요약정리해 보았습니다.

- 원글 링크 : 관련 자료 링크
- 2010년 10월 7일 MongoDB User Group에 "Foursquare outage post mortem"이라는 제목으로 게시된 포스트

Foursquare outage post mortem

제목 : Foursquage 서비스 장애에 대한 사후事後 토의

(Note: 아래는 Foursquare의 허락하에 포스팅되는 내용입니다.)

널리 알려진 바와 같이 이번주에 Foursquare에는 심각한 서비스 장애가 있었습니다. 이번 장애는 체크인에 사용되는 MongoDB 서버중 한대의 용량 문제로 인해 야기되었습니다. 이 포스트에서는 무슨 일이 발생했는지와 발생의 원인, 그리고 어떻게 방지할 수 있는지를 소개합니다. 10gen과 Foursquare의 엔지니어들이 이슈를 해결하기 위해 긴밀하게 협업하였다는 것은 매우 중요한 사항입니다.



* 간단한 연혁

Foursquare는 체크인 데이터를 MongoDB로 서비스하고 있습니다. 데이터베이스는 원래 66GB RAM을 가진 단일 EC2 인스턴스에서 실행되고 있었습니다. Foursquare는 2달전, 증대되는 용량 요구를 해결하기 위해 2개의 Shard 클러스터로 구성된 단일 인스턴스로 마이그레이션 되었습니다. 현재 각 Shard는 개별 66GB 인스턴스에서 실행되고 있으며, 모든 Shard는 복제를 위해 slave로 replication 됩니다. 성능을 위해 Foursquare의 모든 체크인 데이터는 RAM에 상주해야 하므로, 마이그레이션은 매우 중요한 작업이었습니다. 데이터는 사용자 ID를 기반으로 200개의 균등한 분산 chunk로 분할되었습니다. 이중 절반이 첫번째 서버로 입력되었고, 나머지 절반이 나머지 서버로 입력되었습니다. 이 시점에서 각 Shard는 RAM에 약 33GB의 데이터를 적재하게 되었으며, 이후 전체 시스템은 두달간 원활하게 작동했습니다.



* 우리가 그 사이에 간과한 것

두달이 지나면서, 체크인 데이터는 각 Shard에 연속적으로 쓰여지게 됩니다. 불행하게도 체크인 데이터는 chunk들 사이에서 균등하게 증가하지 않았습니다. 어떻게 이런 일이 발생하였는지 쉽게 알수 있습니다. 다른 유저들에 비해 활동성이 특히 높은 유저들을 가정해 본다면, 특정 Shard로 업데이트가 집중되리라고 볼 수 있습니다. 이로 인해 한 Shard는 66GB까지 늘어났음에도 불구하고, 또 다른 Shard는 단지 50GB로 유지가 되었던 것입니다. [1]



* 무엇이 잘못되었던 것일까

월요일 아침, 한 Shard(shard0로 지칭)의 데이터는 결국 서비스 장비의 66GB RAM 용량 한계를 넘어선 67GB에 육박하게 됩니다. 데이터 크기가 물리적 RAM의 크기를 넘어설때 마다 디스크로 read/write하는 작업이 필요하게 되었고, 이는 RAM의 read/write보다 매우 느리게 작동했습니다. 따라서 특정 쿼리들은 매우 느려지고, 사이트를 다운시킬 정도의 backlog를 야기했습니다. 우리는 우선 세번째 Shard 추가로 문제를 해결하려 했습니다. 세번째 Shard를 올리고, chunk 마이그레이션을 시작했습니다. 쿼리들은 모두 3개의 Shard들로 분산되었으나, shard0의 disk 병목 현상은 계속되었습니다. Shard 추가로도 문제가 해결되지 않았을 때, 우리는 결국 문제의 원인이 shard0의 데이터 단편화에 기인한다는 것을 발견하였습니다. 본질적으로, shard0에서 5%의 데이터를 세번째 Shard로 옮긴다 하더라도, 단편화된 상태의 데이터 파일들은 여전히 동일한 양의 RAM을 필요로 한다는 것이었습니다.


이는 Foursquare 체크인 문서들이 작다(대략 300 바이트)는 사실에서 설명됩니다. 결국, 많은 문서들이 4KB 페이지에 적합합니다. 5%의 문서들을 제거하는 것은 (페이지들을 함께 제거한다기 보다는) 각 페이지를 약간 더 sparse하게 만들기만 할 뿐이었습니다.[2]


첫날의 장애 이후로, chunk 마이그레이션이 직접적인(또는 즉각적인) 문제해결책이 아니라는 점이 분명해졌습니다. 두번째 날의 장애가 발생할때 까지 이미 shard0에서 5%의 데이터를 옮겨 놓은 상태였습니다. 결국, MongoDB의 repairDatabase() 기능을 이용한 오프라인 데이터베이스 압축 절차를 시작하기로 결정했습니다. 이 절차는 4시간 정도가 소요되었습니다. (데이터 크기와 EBS 볼륨의 낮은 속도로 인해) 4시간이 지나자, shard0의 RAM 요구량이 5%까지 감소되었고 시스템을 오프라인 상태로 전환할 수 있었습니다.



* Afterwards

shard0가 복구되고 세번째 shard가 추가되고 나서도 우리는 더 많은 shard들을 준비했습니다. (이제는 체크인 데이터가 여분의 용량을 가지고 매우 고르게 분산됩니다.) 여전히 우리는 단편화 문제에 전력을 쏟아야 했습니다. 우리는 각 shard가 필요로 하는 RAM을 대략 20GB정도로 줄이기 위해, slave서버에서 repairDatabase()를 실행하고 slave를 master로 전환했습니다.



* How is this issue triggered?
Foursquare 서비스 다운의 여러 요인들


1. 시스템들이 용량 초과가 되었습니다. 용량의 크기는 정의하기 나름입니다. Foursquare의 경우, 만족할 만한 성능을 위해 모든 데이터가 RAM에 적재될 필요가 있었습니다.


2. 문서 크기는 4K 미만입니다. 이런 문서들은 이동될때, 페이지(메모리)들을 해제하기에는 너무나 작은 크기였습니다.


3. Shard key 순서와 삽입 순서는 달라야 합니다. 이는 데이터가 연속된 chunk들로 이동되는 것을 방지합니다. 대부분의 shard 배분은 이런 기준을 만족시키지 않을 겁니다. 4KB 이상의 크기로 된 문서들의 경우, 사용되는 않는 페이지들은 캐쉬되지 않기 때문에 심각한 단편화로 고통받지는 않을 것입니다.



* Prevention

시스템이 최대 용량에 달했을때, 염두해야할 사항이 있습니다. 객체들이 매우 작다면, downtime 없이 용량을 추가하는 것은 어렵습니다. 그에 비해, 용량 초과 이전에 shard를 추가하는 것은 downtime없이 가능합니다.


예를 들어, 우리가 추가 용량이 필요로 하는 시점보다 12시간 이전에 경고를 받았었다면, 세번째 shard를 추가하면서 데이터 마이그레이션을 수행하여 slave 서버들을 안정화 했을 것입니다.



* Final Thoughts

10gen 기술팀은 Foursquare 서비스 장애로 알려진 이슈 해결에 노력하고 있습니다. 우리는 MongoDB를 사용하는 모든 이들이 최고의 경험을 갖을 수 있도록 하기위해 계속 노력할 것입니다. 불명예스러운 사건이 일어나는 동안 Foursquare와 MongoDB 커뮤니티에서 보내준 지원에 감사합니다. 언제나 그렇듯이 어떤 질문이나 문의도 환영합니다.


[1] chunk들은 200MB가 되었을때 2개의 100MB chunk로 분할됩니다. 이는 각 Shard들의 chunk 숫자가 같더라도 데이터 크기는 항상 다를수 있다는 것을 의미합니다. 우리는 MongoDB에서 이 사항을 검토하고 본격적으로 착수해야 합니다. 우리는 이런 불균형을 찾아서 balancing 분할이 되도록 할 예정입니다.


[2] 10gen 팀은 데이터 파일과 색인 모두를 실시간으로 증분 압축하는 작업을 진행하고 있습니다. 이는 Non-shard 시스템에서도 중요한 사항입니다. 이에 대한 자세한 사항들은 몇주 후에 제공될 예정입니다.




핑백

  • MongoDB 소개 » 엔지니어와 아티스트 사이 2012-02-14 01:52:33 #

    ... 이고, foursquare 같은 서비스에서 성능의 우수성을 보장하였다.-하지만 데이터의 안정성을 보장하지는 않는 것 같다. 장애보고가 심심치 않게 보여진다. 다음의 기사를 참고하라. 기사 – HTTP/REST 보다 Binary Wire Protocol 을 기본으로 사용하기에 통신에 추가 부담이 크지 않다. 문서에 추가 공간을 동적으로 미리 할당해 두 ... more

  • 그런지's Ltd. : Foursquare의 MongoDB 장애 원인 분석 2012-03-02 19:29:02 #

    ... - http://monetary.egloos.com/3600459 ... more

덧글

댓글 입력 영역