nosql - 도입 사례

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 공조체제 구축 필요

About the author

kth 개발실 데이터지능팀장 이호철입니다. 빅데이터 시대, Data Analytics 에 관심이 무지무지, 그리고, 경험을 무지무지 쌓고 있습니다. 실시간 대용량 분산처리 시스템인 DAISY(Data Intelligence System) 솔루션을 널리널리 퍼트리고 있습니다! http://twitter.com/5clee

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

---

원문 슬라이드 : Why we chose mongoDB for guardian.co.uk

1. 개요

Guardian은 영국의 유력지 중 하나로 꼽히는 신문으로 공정한 논조와 참신한 보도가 잘 조화되어 <타임스>와 견주는 일간입니다. 하루 수백만이 온라인으로 가디언지를 구독하고 있습니다.. 수백 개의 테이블들이 서로 연관되어 있어 쿼리의 복잡성이 매우 높아 유지보수 및 확장이 어려운 상황입니다. 이를 해결하기 위해서 과거에 해왔던 여러 방식과 앞으로의 방식에 대하여 논의 하고 있습니다.

 

2. 가디언의 생존을 위한 노력

 가디언은 트렌드의 변화에 적응을 하기 위해 여러 방법에 대해서 고민은 하고 시스템에 적용을 하였습니다. 아래는 다윈의 말을 인용하며, Mongodb를 선택하기까지의 과정을 함축적으로 나타내고 있습니다.

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change. (강한 種이 살아남는다고 할 수 없다. 지적인 종이 살아남는다고도 할 수 없다. 오직 변화에 가장 잘 적응하는 종만이 살아남는다.)”

MongoDB까지 오기에는 “Early Period”, “Mid Period”, “Modern Period”, “Sticking Plaster”, “Future”로 5단계의 과정을 거쳤습니다. 아래는 각 단계별로 가디언이 해왔던 부분에 대해서 적었습니다.

1) Early Period

• 1995년경으로 Perl, CGI, apache로 구성된 실험적이고 bespoke software(가디언에 특화된 소프트웨어)
• RDBMS, script, static file들을 사용 합니다.

2) Mid Period

• 2000년경으로 벤더의 CMS을 사용하는 시기.
• vignette/AOLserver(open source), TCL(script), Apache, Oracle등을 이용한 온라인 publishing으로 초기 단계 배달에 중점.
• HTML, JavaScript, TCL, SQL, PL-SQL등이 템플릿에 뒤죽박죽 되어 있고, 어플리케이션 계층의 모델이 없고 오직 RDBMS 스키마만 있을 뿐, 가디언이 원하는 것을 할 수 없음.
• 몇 년이 흐르면서 이러한 스키마에 의존적인 구조로 인하여 확장을 하기 어려움.

3) Modern Period

• J2EE 모놀리식(Monolithic )개발 단계로 Spring/Hibernate 프레임웍 사용, DDD/TDD 방식으로 접근, database 는 ORM을 통해 추상화 함.
• 문제점 발생 => 모든 발간(신문, 주간지)은 스키마의 업그레이드가 필요했고, 이시간 동안은 저널리스트들은 일을 할 수 없음.
• 현재도 계속 복잡성은 증가 하고 있음. => 300개 이상의 테이블, 1만라인 이상의 hibernate xml config, database 매핑을 위한 1천개의 도메인 객체들, Database와 매우 밀접한 7만 라인의 이상의 도메인 객체 코드 등.
• ORM도 해결책은 될 수 없다. 데이터베이스는 도메인 모델에 강한 영향을 미친다. 많은 도메인 객체들은 RDBMS에서 복잡한 매핑 조인들을 만든다. 복잡한 hibernate 기능들은 인터셉터, 프록시와 같은 복잡한 hibernate 기능들은 최적화를 위해 복잡한 캐싱 전략을 많이 쓴다. 또한 아직도 복잡한 SQL 쿼리 코드를 사용한다.
• 이러한 것들은 시스템 부하가 이슈가 되고, RDBMS는 확장이 어려워 문제가 된다.

4) Sticking Plaster(땜빵?)

• 부분적으로 NoSQL을 적용한 09 ~ 10년의 시기임.
• 실질적인 NoSQL이라기 보다는 Memcached를 적용하여 RDBMS로부터 READ에 대한 부하를 줄인 것으로 보임.
• 현재까지는 부하문제를 어느정도 해결했지만, “앞으로도 가능할까?”에 대한 답변은 …
• 현재까지는 RDBMS 테이블, java 객체, JSON API의 세가지 모델을 가지고 있음.
• 이 모델들 중 JSON은 멀티 도메인 컨셉을 하나의 문서에 표현하는 것이 가능하며, 앞으로의 확장도 가능하기 때문에 앞으로 사용해야 할 모델의 가장 중요한 모델로 선택함.

5) Future

• 완전한 NoSQL을 사용하기 위한 단계로 현재 개발 중
• 여러 NoSQL(CouchDB, Cassandra, mongoDB ) 중에 가디언의 현 상황에 맞는 DB를 고르는 것이 핵심이며, JSON을 중요 모델로 선택할 때 MongoDB를 사용함.
  • CouchDB – Simple keystore. Too simple?
  • Cassandra: 확장성이 대단히 좋으나 스키마 디자인이 어려움.
  • MongoDB: 사용하기 쉽고, RDBMS의 쿼리와 유사하게 실행할 수 있음.

   

• 아래와 같은 이유로 MongoDB를 선택함.
  • 문서 기반의 데이터베이스 –JSON과 유사한 방식의 Binary JSON 사용
  • 복잡한 쿼리를 사용 가능.
  • Consistency에 대해 유연한 대처가 가능 – 컬럼그룹 기반으로 HBase나 카산드라와 달리 문서형 데이터 모델을 사용, 관계형 데이터베이스와 유사한 사용법 유지, 순서기반분할(Order-preserving partitioning) 자동샤딩(Automatic Sharding)을 구현하여 노드간 데이터 분리 및 확장이 투명하게 이루어짐
  • 런타임에 쉽게 변경 할 수 있는 유연한 스키마를 가짐.
  • 규모가 크거나 작은 모든 곳에 사용 가능.

3. 가디언이 앞으로 해야 할 일

1. 현재의 시스템
   • login/registration => TCL/PLSQL로 되어 있음.
   • 300만 이상의 관계형 데이터베이스에 있음.
   • 매우 복잡한 스키마와 PL-SQL
   • 새로운 시스템이 필요하며, 과연 현재 사용하고 있는 오라클을 NoSQL로 마이그레이션 할수 있을까?
2. 미래의 시스템
• 개발될 API는 새로운 MongoDB와 함께 기존 Oracle도 함께 연동 되어야 함.
• 마이그레이션 후에 Oracle은 제거함.

4. 결론

앞에서 소개된 내용들은 대부분 많이 알고들 있는 부분이며, 새로운 기술에 대한 내용은 아닌 것 같습니다. 우리가 그 동안 해왔던, 그리고 현재도 고민하는 내용들을 가디언도 동일하게 하고 있었으며, 고민만 한 것이 아니라 여러 방법으로 시스템을 변경하며 개발을 했습니다. 다윈의 말처럼 가장 강하거나 똑똑한 종이 살아 남는 것이 아니라, 변화에 적응을 잘해야 살수 있습니다.

kth는 강하거나 똑똑하지는 않지만, 포털중심에서 스마트 모바일로 트렌드의 변화에 적응하고 있는 것처럼 최후까지 살아남는 개발자 개인 또는 회사가 되기를 희망 합니다.

About the author

kth 서비스플랫폼개발팀 이희대입니다. 최근에 ucloud의 Sync(OMA DS 1.2 프로토콜 기반) 서버를 개발했습니다. 현재는 TV 기반의 소셜 서비스를 개발중입니다. 항상 새로운 것을 배우려고 노력하며, 즐기고 있습니다.

출처 - http://dev.kthcorp.com/2011/10/13/why-guardian-chose-mongodb/