몽고디비는 계속 크래시 리포트가 올라온다. 그래도 개발팀의 대응을 보면 살아움직이는 프로젝트라는 느낌이 든다. 최근에는 포스퀘어랑 몽고디비가 자신들이 겪은 일을 그대로 외부에 공개해줬는데, 그런 분위기도 상당히 부럽고 내용에도 참고할만한 점이 있다.
사건의 개요는 이렇다.
1. 포스퀘어는 사용자정보를 몽고디비에 저장한다.
2. 몽고디비는 두대의 아마존 EC2(RAM 66G)에서 서비스한다.
3. 샤딩(shard)을 했지만, 균등하게 분산되지 않았다.
4. 어느 순간 한서버에는 67G, 다른 서버에는 50G의 데이터가 저장되었다.
5. 메모리가 넘치면서 디스크로 페이징이 되기 시작했다.
6. 응답속도가 느려지면서 쿼리 요청이 쌓이고, 페이징은 가속되었다.
7. 세번째 샤드를 추가했다.
(몽고디비 최근 버전에 auto-shard가 추가되었습니다.)
8. 몽고디비는 4K단위로 움직이는데, 포스퀘어의 체크인 데이터는 300 byte밖에 안된다.
9. 하나의 체크인데이터를 새 샤드에 생생해봤자, 기존서버의 4K 는 그대로 있다.
10. 몽고디비의 compaction 기능을 사용해보았다.
11. 아마존의 디스크는 네트웍스토리지다. 느리다. 컴팩션도 너무 느렸다.
(몽고디비의 컴팩션은 디스크에서 동작. EBS는 네트웍 스토리지)
12. 그래서, 어쩔수없이... 사용자정보 전체를 백업으로부터 새로 읽어들였다.
13. 이제 세개의 샤드에 고르게 분산 저장되었다.
원본 : http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html (원문에는 위의 개요말고도 볼만한 내용이 더 있음)
사건의 개요는 이렇다.
1. 포스퀘어는 사용자정보를 몽고디비에 저장한다.
2. 몽고디비는 두대의 아마존 EC2(RAM 66G)에서 서비스한다.
3. 샤딩(shard)을 했지만, 균등하게 분산되지 않았다.
4. 어느 순간 한서버에는 67G, 다른 서버에는 50G의 데이터가 저장되었다.
5. 메모리가 넘치면서 디스크로 페이징이 되기 시작했다.
6. 응답속도가 느려지면서 쿼리 요청이 쌓이고, 페이징은 가속되었다.
7. 세번째 샤드를 추가했다.
(몽고디비 최근 버전에 auto-shard가 추가되었습니다.)
8. 몽고디비는 4K단위로 움직이는데, 포스퀘어의 체크인 데이터는 300 byte밖에 안된다.
9. 하나의 체크인데이터를 새 샤드에 생생해봤자, 기존서버의 4K 는 그대로 있다.
10. 몽고디비의 compaction 기능을 사용해보았다.
11. 아마존의 디스크는 네트웍스토리지다. 느리다. 컴팩션도 너무 느렸다.
(몽고디비의 컴팩션은 디스크에서 동작. EBS는 네트웍 스토리지)
12. 그래서, 어쩔수없이... 사용자정보 전체를 백업으로부터 새로 읽어들였다.
13. 이제 세개의 샤드에 고르게 분산 저장되었다.
원본 : http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html (원문에는 위의 개요말고도 볼만한 내용이 더 있음)
