MongoDB 사용 사례 - AreYouInterested.com

MongoDB 사용 이야기보단.. Facebook API 에 대한 내용이 더 많은 듯.. 대강 내용은 이렇다.

AreYouInterested.com 은 여타 다른 데이트 사이트와는 다른 한가지 장점이 있다. 그것은 Facebook API 를 통해 수백만의 회원 프로필을 항상 자동으로, 회원들이 무엇을 좋아하는지 실시간으로 업데이트 시켜주고 있다는 것이다. 하지만 수백만의 프로필을 거의 실시간으로 업데이트 받는 것은 쉽지 않았다. 처음에는 FQL(Facebook Query Language) 쿼리를 사용했고 그 정보들을 MySQL 테이블과 MongoDB 컬렉션(collection) 들에 저장했다. 하지만 데이터를 수집하는 것 뿐만 아니라 회원들의 프로필 정보들이 변했는지 아닌지 알기위해 비교하기까지 해야 하는 것이다. 결국 이 Call 들로 엄청난 병목현상이 일어났고 모든 회원들의 프로필 정보 갱신을 하려면 10일이 걸렸다. 다시말해 회원이 Facebook 에 프로필을 수정해도 우리의 사이트에 10일 이후에나 반영이 된다는 것을 의미한다. 그러다가 Facebook 은 Realtime Update API 를 내놓는다. 이 API는 회원이 Facebook 에서 프로필을 수정하고 나면 몇초 안에 그 변화를 우리에게 알려주게 되었다. 회원들이 프로필의 어떤 항목들을 변경했는지 필드 정보만 알려주며, 그 수는 분당 11,000 명에 달했다. 하지만 Facebook 에서는 그 필드값이 어떤값으로 변했는지 상세한 정보를 주진 않는다. 매 60초마다 11,000 명의 프로필 모두를 체크하고 각 데이터들을 업데이트해야 하는 작업은 간단하지 않았다.

우선, MongoDB에 있는 모든 회원정보를 로드했다. 하지만 가끔 평균데이터의 4~5배 정도에 달하는 데이터가 오는 경우가 있어서 replication 지연이 발생하였고, 이것은 주로 global read/write 잠금(lock)의 원인이 되었다. 회원정보 collection 에서 대용량 쓰기와 거대한 인덱스들의 결합은 secondary 가 oplog를 읽지 못하게 했다. 어떠한 때에는 지연이 replication 을 멈추게 만들정도로 심해졌다. 그래서 우린 더한 파손을 막기위해 oplog 의 용량을 늘였고 Facebook 요청수를 제한했다. 다행히 MongoDB 2.2 버전이 릴리즈되면서 global locking 대신 data level locking 이 추가되면서 이 문제는 해결되었다. 또한 우리는 수백만의 불필요한 요청을 없애기 위해 인덱스를 생성했다.

받은 프로필정보를 가지고 기존에 가진 프로필 정보와 비교하면서도 facebook으로부터 다음 데이터가 오기전에 수정완료 하기 위해서는 한 가지 방법을 고안해야 했다. 한번의 Facebook 요청 대신에, 수백개의 요청으로 나누어 각 호출당 약30명의 데이터를 가져올 수 있게 했다. 데이터를 받으면, 수정된 데이터가 무엇인지 알아내고 회원의 프로필을 수정할 수 있었다.

결국 그렇게 안정된 시스템을 구축할 수 있었다~ 는 해피엔딩 이야기.

아래 사이트 직접 방문해서 읽어보시면 더 좋을 듯.

(원문 : http://blog.snap-interactive.com/post/28341093191/mongodb-scale-facebook-realtime-endpoint )