포스퀘어가 MongoDB를 선택한 이유 : Auto-Sharding

http://dev.paran.com/2011/07/08/mongodb-atfoursquare-biggest-reason-auto-sharding/

Why MongoDB
MongoDB @ foursquare / Biggest reason : Auto-sharding
포스퀘어의 Harry Harry Heymann 이 직접 발표한 동영상 , 발표자료 슬라이드
최근 1,000만 이용자를 돌파한 서비스인 Foursquare. Foursquare는 매일 300만 건의 checkins 과 총 7억5천만 건의 checkins 데이터가 쌓여 있다. Foursquare 서비스의 환경은 Amazon EC2(Amazon Elastic Compute Cloud) 위에 40대의 장비, 그리고, 8 Clusters – Sharding과 Replica Sets – 로 구성된 mongodb로 가동되고 있다. Foursquare에서 mongodb를 사용한 가장 큰 이유는 Auto-Sharding (오토샤딩)이라고 한다.
Why MongoDB ? Biggest reason (by far): auto sharding
이 글에서는 MongoDB의 아래 2가지 특징 에 대해 알아보겠다.

• Replication (Replica Sets) : 안전성과 높은 가용성(safety and high availability)을 위한
• Auto-sharding : 분산확장(scale-out)을 위한

Replication, Replica Sets
기존 DB들에서 Master-Slave 구조를 통한 Replication을 제공한다. 복제를 통한 안전성과 높은 가용성을 확보했다.
1) Master/Slave Replication

[그림1] Master/Slave Replication

일반적인 개념의 Master/Salve Replication 구조 읽기 부하 분산 : Slave들은 Read 전용 단점 Master에 Write 부하증가 가능성 높음 Master Fail시 대응하기 위한 별도 조치 필요 (예, HA구성, 멀티Node Master 구성)

2) Replica Sets

[그림 2] Replica Sets

• Replica set은 자동 장애 넘김 기능이 있는 Master-Slave 클러스터
• 장애 시 자동 처리
  • 주 서버가 장애가 발생했을 경우 보조서버 중 우선순위가 높은 서버가 자동으로 주 서버가 됨
  • 우선순위는 Priority 가 0이 아닌 노드들 중 높은 순으로 선택
    동일 우선순위 일 경우 최신의 데이터 복제본을 가진 서버가 우선
  • 장애난 서버는 복구 후 보조서버로 다시 편입
• Priority 가 0 인노드 : 절대 주 서버가 될 수 없음, 백업/복구 등의 용도로 사용

3) MongoDB에서 Slave 활용

• 데이터 유실이나 마스터 노드에서 장애 발생시 요청 넘김
• 백업
• 읽기 부하 분산
• 통계 등 데이터 처리용 업무 수행

이 경우에도 마스터 노드로의 쓰기(DB Write) 부하는 줄일 수 없다.
이 쓰기 부하를 줄이기 위해 Auto-Sharding 을 통한 분산확장(Scale-Out)이 가능하다.
Auto-Sharding
샤딩(Sharding)은 데이터를 분할해 다른 서버에 나누어 저장하는 과정을 말한다. 데이터를 여러 서버에 분할함으로써,
Scale-Up을 하지 않고도 더 많은 데이터를 저장, 처리 가능하게 한다.
샤딩은 거의 모든 DBMS가 지원한다. 어플리케이션 단에서 처리, 관리하는 수동 샤딩의 어려움을 MongoDB에서는
Auto-Sharding(자동 샤딩)을 제공으로 해결한다.
1) Sharding 구조

• 샤드 키로 설정된 칼럼의 범위를 기반으로 각각의 값에 맞는 Shard에 저장이 된다.
  필요 시 Shard를 추가하여 Migration 하여 확장이 가능하다.
  [그림 3] Sharding 개념
• 사용하는 Application 단에서는 MongoS 라는 라우팅 프로세스로만 연결함으로써 Shard의 구조에 대해서는 알 필요도,
  구조변경에 따른 수정도 필요 없다.

2) Sharding을 사용해야 할 때

• 쓰기(DB Write)가 빈번 할 경우
• 현재 장비에 디스크 공간이 부족할 경우
• 애플리케이션에 영향을 주지 않고 증가하는 부하와 데이터를 처리하기 위해 장비 추가. 즉, Scale-Out

효과적으로 MongoDB를 사용하기 위해
Replica Sets + Auto-Sharding 구성
대용량 처리를 위한 분산확장이 가능하고 안전성과 높은 가용성 보장을 위해 Auto-sharding 과 Replica Sets 으로 구성

[그림 4] Sharding+Replica set 구성
그러나, 조심해야 할 것
1) Fragmentation

• 단편화, 조각화 문제
• 빈번한 삭제나 업데이트는 단편화를 발생시키고, 실제 데이터 보다 훨씬 많은 메모리를 사용 함
• 데이터 삭제 또는 이전해도 사용량은 그대로 유지
  -> repairDatabase를 통해 복구 해야함
• Foursquare 서비스 장애에 대한 사후 토의 참고
  (http://groups.google.com/group/mongodb-user/browse_thread/thread/528a94f287e9d77e?pli=1)

2) Monitoring

• 최선은 Monitoring : Monitoring is your friend
• 메모리 상주 크기, 디스크 입출력 속도, 쿼리 입력/수정/삭제 비율, 클라이언트 대기열

준비할 사항

• kth 내부에서도 mongodb, cassandra 등 서비스별로 NoSQL 적용중/준비중에 있음
• Scale-out을 위한 Configuration 가이드 및 운영 전담 필요
• 운영실과 Monitoring 공조체제 구축 필요