MongoDB란 무엇인가?
MongoDB는 대표적인 문서 지향(document-oriented) NoSQL 데이터베이스입니다. 전통적인 관계형 데이터베이스 모델에서 벗어나, 보다 유연하면서도 수평 확장(horizontal scaling)이 용이한 방식으로 데이터를 관리하고 구성하도록 설계되었습니다.
AEM과 MongoDB는 어떻게 연동되는가?
MongoDB는 Adobe Experience Manager(AEM)와 crx3mongo 실행 모드(runmode), 그리고 JVM 옵션인 -Doak.mongo.uri와 -Doak.mongo.db를 통해 통합됩니다.
왜 MongoDB를 선택해야 하는가?
MongoDB를 도입하는 가장 큰 이유는, 기존 CRX 클러스터 구성에 대한 대안적인 고가용성(HA) 구성을 제공하기 때문입니다. 실제로 그 아키텍처는 진정한 의미의 클러스터링이라기보다는 NFS나 NetApp에 공유 카탈로그를 두는 방식에 더 가깝습니다. MongoDB를 사용하는 저자(author)와 퍼블리셔(publisher) 인스턴스는 서로를 반드시 인식할 필요가 없습니다.
솔직히 말씀드리면, CRX 클러스터링은 깨끗한 운영 기록을 자랑하지 못했습니다. 로컬 전용 객체 카탈로그(object catalog)의 근본적인 한계 중 하나는, 대규모 환경에서 단일 카탈로그가 제공하는 다음과 같은 장점들을 활용할 수 없다는 점입니다.
- 데이터 중복 감소
- 성능 분석 및 튜닝 범위의 집중화
- 멀티 노드 간 상호작용 없이 HA 가용성 확보
- 중복성과 성능을 위한 수평 확장
아무리 완벽하게 작동하는 CRX 클러스터라 해도 이러한 장점 중 어느 것도 충족하지 못합니다. 바로 이 지점에서, 공유 데이터 계층(shared data tier)의 시대가 다시 주목받게 됩니다.
NFS 공유 방식의 한계
AEM 5.6.1 이전 버전에서는 규모가 크거나 계속 성장하는 배포 환경에서 객체 저장소(repository)를 공유 NFS로 마운트할 수 있었습니다. 이 경우 프로토콜 또는 NFS 서버가 낮은 충돌률로 다중 쓰기(multi-write) 동작을 위한 잠금(locking)을 지원했습니다. 지금도 유효한 선택지이지만, NetApp을 사용하지 않는 한 컨트롤러나 데이터 계층에 단일 장애점(SPOF)이 발생할 위험이 있어 n*9 수준의 아키텍처를 달성하기 어렵습니다.
AEM 6.x에 MongoDB 마이크로커널(MongoMK)이 도입되면서, 사실상 동일한 아키텍처를 우리가 익히 잘 아는 그 데이터베이스로 구현할 수 있게 되었습니다.
MongoMK의 최적 활용처: 저자(Author) 인스턴스
MongoMK의 주요 사용 사례는 AEM 저자(author) 인스턴스입니다. 동시 접속 사용자 수가 약 25~30명으로 제한되기 때문에, 수평 확장을 논하기 전에 먼저 동시성(concurrency) 문제를 해결해야 합니다. 이때 공유 데이터 계층이 가장 빛을 발합니다. 노드 간 통신의 필요성을 없애는 동시에, 성능보다 확장성과 일관성이 우선시되는 환경에 적합하기 때문입니다.
물론 퍼블리셔(publisher) 인스턴스도 같은 방식으로 연결할 수 있습니다. 하지만 퍼블리셔는 동시성 문제 자체가 없고(필요하면 단순히 인스턴스를 추가하면 됩니다), 비로컬 카탈로그 사용에 따른 성능 저하가 있기 때문에 얻을 수 있는 이득은 상대적으로 줄어듭니다.
"무한대로 확장!"이라고 생각했다면 잠깐, 멀티사이트 배포의 함정
"자, 이제 끝났군요! 무한대로, 그 너머까지 확장하자!" — 잠깐만요, 버즈 라이트이어(Buzz Lightyear). 문제가 하나 있습니다.
단일 사이트(single-site) MongoDB는 빠른 액세스가 가능한 데이터와 인라인 네트워킹 옵션 덕분에 매우 효과적으로 확장될 것으로 기대됩니다. 이 환경에서는 하늘이 곧 한계일지도 모릅니다. 그러나 여러 사이트에 걸친 배포 환경을 생각해 보십시오. MongoDB 복제 세트(replica set)가 서로 다른 데이터 센터 사이, 알 수 없는 수천 킬로미터의 광케이블을 거쳐 통신해야 합니다. 바로 여기서 오플로그(oplog, operation log)가 등장합니다.
오플로그는 복제본들이 동기화 상태를 유지하기 위한 중개자 역할을 합니다. 순서대로 적용해야 하는 델타(delta) 연산의 나열로 구성되며, 다른 일부 데이터베이스 클러스터 구성과 상당히 유사한 방식입니다.
최적화된 운영 상태에서는 오플로그가 프라이머리(primary)와 최대한 실시간에 가깝게 실행됩니다. 물론 MongoDB는 어느 정도의 드리프트(drift, 동기화 격차)를 허용합니다. 하지만 멀티사이트 운영에서는 회선 지연(wire latency)과 연산 지연(operation latency)이 누적되어 더 큰 격차를 만들며, 이로 인해 다음과 같은 문제가 발생합니다.
- 오플로그는 기능적으로 명령어 스택(stack)입니다.
- 많은 스택과 마찬가지로 선입선출(FIFO) 방식으로 동작합니다.
- 스택의 특성상, 다음 push가 아직 pop되지 않은 레코드를 덮어쓰게 되면 데이터 손실이 발생합니다.
MongoDB 개발진은 이러한 상황을 감지하고 대응하기 위해, 해당 복제본을 중단시키고 재구축(rebuild)한 후 새로운 오플로그를 기준으로 다시 동기화하도록 설계했습니다.
재구축의 악순환
겉보기에는 특별하거나 위험해 보이지 않는 작업입니다. 하지만 재구축 과정부터 자세히 들여다볼 필요가 있습니다. 이 과정은 모든 데이터를 삭제한 후, 검증된 프라이머리로부터 새로운 사본을 가져옵니다. 내보내기(export)가 0초 만에 끝난다고 가정하더라도, 지연이 있는 회선을 통해 데이터 볼륨 전체를 복사하는 동안 원격 복제본이 가져오기를 마치기도 전에 이미 새로운 격차(drift)가 발생합니다.
회선 지연만이 유일한 문제라고 가정하고, 재구축 직후 오플로그에 재구축으로 인한 격차만 남아 있다고 가정해 보겠습니다. 하지만 처음에 복제 지연을 유발했던 근본적인 문제는 여전히 그대로 존재합니다. 결국 시간이 지나면 새로 구축된 세컨더리(secondary)는 또다시 재구축을 강요당할 수밖에 없습니다.
일부 경우에는 이러한 동작이 복제 지연과 재구축의 끝없는 반복으로 이어져, 원격 세컨더리가 결코 정상적인 상태로 돌아서지 못하게 됩니다.
AEM에 미치는 영향
AEM 입장에서 이것이 의미하는 바는 분명합니다. MongoDB 복제본을 교차 사이트(cross-site) 저작 환경의 기본 데이터 소스로 사용하면, 원격지에서 작업하는 저자들(remote authors)이 심각한 위험에 노출됩니다. 멀티사이트 아키텍처를 설계할 때는 이러한 복제 지연 리스크를 반드시 사전에 검토하고, 대안적인 데이터 계층 전략을 함께 고려해야 합니다.