통신 산업에서 주문 관리 시스템은 고객 주문 처리, 상태 추적, 다양한 업무 시스템 연동 등 핵심 역할을 수행한다. 이 시스템의 안정적 운영은 고객 경험과 서비스 연속성에 직접적인 영향을 미친다. 급증하는 트래픽과 복잡한 운영 환경에 대응하기 위해 통신사는 주문 플랫폼에 고가용성과 재해 복구 능력을 갖춘 아키텍처가 필요하다.

이중화 구조는 두 개의 데이터센터가 동시에 서비스를 제공하고 데이터를 실시간으로 동기화하는 대표적인 고가용성 방안이다. 한쪽 센터에 장애가 발생하면 다른 쪽이 즉시 업무를 인계하여 서비스 중단을 방지한다. 이 구조는 시스템 안정성을 높일 뿐 아니라 재해 복구 시간과 비용을 크게 줄여준다.

본 문서에서는 주요 통신사의 주문 플랫폼에서 MongoDB 기반 이중화 구조를 구축한 실제 사례와 기술적 세부사항을 공유한다.

업무 요구사항 분석

배경

최근 통신 3사는 디지털 전환을 가속화하며 '능력 중대'를 구축하고 있다. 대고객 서비스를 위한 핵심 플랫폼으로서, 이 시스템은 영업, 마케팅, 운영, 배달 역량을 수평 통합하여 대고객 업무 효율을 제고한다. 온오프라인 통합 경험 제공과 자원 공급 가속화를 목표로, 기존의 수직적 '독립형' 구조를 '플랫폼+애플리케이션' 클라우드 방식으로 전환하여 역량 재사용, 프로세스 연결, 데이터 공유를 실현한다.

MongoDB는 이 플랫폼의 여러 업무 모듈, 특히 주문 조회, 고객센터 조회, 심사 목록 조회 등에서 핵심 저장소로 활용된다. 시스템 고가용성을 위해 원격지 이중화 구조가 필요하며, MongoDB 클러스터는 이중 배포, 양방향 기록, 양방향 동기화 기능을 갖춰야 한다.

양방향 동기화의 과제

기존 설계에서 고객 데이터는 두 MongoDB 클러스터에 분산되어 양방향 동기화가 필요했다. 그러나 이 설계는 다음과 같은 난관에 봉착했다:

1. 순환 동기화 문제: 데이터 변경이 무한히 전파되면서 시스템 자원을 고갈시키고 데이터 불안정을 초래한다.
2. 일관성 문제: 동기화 지연으로 인해 두 센터의 데이터가 불일치하여 업무에 차질이 생길 수 있다.
3. 성능 저하: 고부하 상황에서 양방향 동기화가 시스템 부하를 가중시킬 수 있다.

따라서 이중화 구조는 다음 기술 특성을 충족해야 한다:

1. 고가용성: 한 센터 장애 시 다른 센터가 즉시 인계하여 서비스 중단 없음
2. 실시간 동기화: 데이터의 일관성과 적시성 보장
3. 환 방지 메커니즘: 양방향 동기화의 안정성 확보
4. 성능 최적화: 고부하 환경에서도 자원 고갈 방지

시나리오 정의

센터 X와 센터 Y에 각각 MongoDB 클러스터를 배포한다. 애플리케이션 A가 X센터 데이터를 수정하고, 애플리케이션 B가 Y센터 데이터를 수정한다. 동기화 작업 S1은 X→Y 방향으로, S2는 Y→X 방향으로 데이터를 전송한다. 다음 조건을 만족해야 한다:

1. 애플리케이션 변경은 신속히 상대 센터로 동기화되어야 한다
2. 동기화 작업으로 인한 변경은 원래 센터로 되돌아가지 않아야 한다
3. 동기화 작업의 재실행 시에도 데이터 문제가 발생하지 않아야 한다

별도의 처리 없이 작업을 생성하면 다음과 같은 상황이 벌어진다:

1. X센터에서 한 레코드에 연속 갱신 G1, G2 발생 → Y센터에 동일하게 반영
2. Y센터의 신이 역으로 X센터에 전파
3. 지연으로 X센터가 G2 상태인데 G1을 수신하면 G1→G2 과정을 다시 거침
4. 위 1-3 단계가 무한 반복됨

시스템 구조 설계

전체 구성

• 애플리케이션은 지역별로 분리
• X, Y 두 센터가 각각 기록 수신 엔드포인트 제공
• 애플리케이션은 지역에 따라 다른 엔드포인트로 기록 요청
• MongoDB는 데이터베이스 고가용성 제공
  • 샤딩 클러스터의 각 샤드는 복제본 세트로 구성
  • 두 센터에 동일 구조의 MongoDB 클러스터를 각각 배포하여 지속적 서비스 보장
• 동기화 도구는 데이터 일관성 유지
  • X센터에 배치
  • X센터 ↔ 동기화 도구 ↔ Y센터 간 네트워크 연결 확보

구성 요소

• MongoDB(파랑): 주문 플랫폼 이중화 클러스터
• 관리 모듈: 소프트웨어 모듈 조정과 웹 콘솔 제공
• 처리 엔진: 데이터 동기화, 정제, 다중 테이블 연관, 집계 계산 수행
• MongoDB(초록): 동기화 도구의 중간 결과 캐싱용 데이터베이스

운영 모드

장애 시나리오: X센터 장애 시 동기화 도구도 함께 중단된다

수동 복구 절차:

1. 모든 업무를 Y센터 기록으로 전환
2. X센터 서버 복구
3. X센터 MongoDB 클러스터 복구
4. X센터 동기화 도구 복구
5. X센터 동기화 작업 재시작

리스크:

• X센터 장애 시 일부 전송 중 데이터가 Y센터 MongoDB에 기록되지 않음
• 해당 데이터는 Y센터에서 유실되나 X센터에는 존재함

동기화 도구 구현 방안

이중화 구축에서 동기화 도구는 센터 간 데이터 일관성 유지를 담당한다. 고가용성과 데이터 일관성을 확보하기 위한 구체적인 구현 단계는 다음과 같다.

1. 데이터 소스 구성

원본 데이터베이스

• Oplog 저장 공간을 충분히 확보, 최소 7일 분량의 Oplog 유지
• 권한 관리 정책에 따라 동기화/개발 작업용 계정 생성 및 권한 부여
• 샤딩 클러스터의 경우, 샤드 서버가 config 데이터베이스에서 권한을 조회하지 않으므로 각 샤드의 프라이머리 노드에 계정을 직접 생성해야 함

특정 데이터베이스 읽기 권한 부여:

use admin
db.createUser({
    "user": "sync_admin",
    "pwd": "secure_key_2024",
    "roles": [
        {"role": "clusterMonitor", "db": "admin"},
        {"role": "read", "db": "order"},
        {"role": "read", "db": "local"},
        {"role": "read", "db": "config"}
    ]
})

전체 데이터베이스 읽기 권한 부여:

use admin
db.createUser({
    "user": "sync_admin",
    "pwd": "secure_key_2024",
    "roles": [
        {"role": "readAnyDatabase", "db": "admin"},
        {"role": "clusterMonitor", "db": "admin"}
    ]
})

2. 순환 동기화 방지 설계

순환 동기화를 차단하기 위해 데이터 변경의 발생 출처를 식별하는 메커니즘이 필요하다. 각 동기화 작업은 자신이 전파한 변경에 특수 마커를 부여하고, 반대 방향 동기화 작업은 해당 마커가 있는 레코드를 무시하도록 구성한다.

구현 방식:

• 동기화 작업이 대상 컬렉션에 _sync_origin 필드를 추가하여 출처 센터 식별
• 반대 방향 동기화 작업의 필터 조건에 {"_sync_origin": {"$ne": "local_center_id"}} 포함
• Oplog 추적 시 해당 필드 변경은 동기화 대상에서 제외

3. 충돌 해결 전략

양방향 동기화에서 동일 레코드의 동시 수정 가능성을 고려한 충돌 해결 정책:

정책 유형	적용 상황	처리 방식
타임스탬프 우선	비즈니스 시간 중요	최신 타임스탬프 보존
센터 우선순위	특정 센터 권한 우위	지정 센터 변경 강제 적용
필드 수준 병합	독립 필드 수정	각 필드별 최종값 보존

4. 성능 최적화

• 배치 처리: 단건 처리 대신 500~1000건 단위 배치 적용
• 병렬 스트림: 컬렉션 단위 병렬 동기화 채널 구성
• 압축 전송: 네트워크 대역폭 절약을 위한 Snappy 압축 적용
• 인덱스 최적화: _sync_origin, _last_modified 필드 복합 인덱스 생성

5. 모니터링 및 알림

핵심 지표:

• 동기화 지연 시간 (목표: 2초 이내)
• 처리량 (초당 문서 수)
• 에러율 및 재시도 횟수
• 양방향 마커 불일치 건수

임계값 초과 시 자동 알림 발송 및 동기화 작업 일시 중지 옵션 제공

운영 경험 및 교훈

네트워크 단절 시나리오

터 간 네트워크가 일시 단절되었다 복구된 경우:

1. Oplog 보관 기간 내 복구: 자동 추적 재개, 누락 데이터 순차 동기화
2. Oplog 보관 기간 초과 복구: 전량 재동기화 모드 전환, 일관성 검증 후 정상 모드 복귀

데이터 정합성 검증

정기적 검증 절차:

// 샘플링 기반 해시 비교
db.orders.aggregate([
    {$sample: {size: 10000}},
    {$project: {_id: 1, hash: {$toHashedIndexKey: "$$ROOT"}}},
    {$out: "verification_sample"}
])

// 양측 해시값 비교, 불일건 상세 비교 수행

용량 계획

실제 운영 데이터 기준:

• 일일 주문 건수: 약 2천만건
• 평균 문서 크기: 3.5KB
• 양방향 동기화 네트워크 대역폭: 최소 500Mbps 권장
• Oplog 저장소: 쓰기 부하의 15% 추가 여유 확보

위 구성을 통해 해당 통신사는 주문 플랫폼의 연중무휴 서비스를 실현하고, 재해 발생 시에도 고객 영향을 최소화하는 체계를 구축하였다.