Lv.2 초급MongoDB

2026.05.2522분 읽기Lv.2 초급

시리즈MongoDB Atlas 완전 정복 · 파트 2시리즈 허브 보기

MongoDB Atlas 완전 정복 Part 2 — 클러스터 설계 전략: Flex vs Dedicated, 멀티 리전, 비용 최적화

2025년 Flex Tier 등장으로 달라진 Atlas 클러스터 티어 구조를 정리하고, M0·Flex·Dedicated를 워크로드 특성에 따라 선택하는 기준을 잡습니다. M30 프로덕션 기준선, 3리전 5노드 고가용성 패턴, 샤드 키 선택 원칙, Auto-scaling 범위 제한·Analytics Node·Online Archive 비용 최적화 패턴까지 한 글에 담았습니다.

시리즈 구성

• Part 1 | Atlas 개념·구조·왜 쓰는가
• Part 2 ← 지금 여기 | 클러스터 설계 전략
• Part 3 | 보안, 네트워크, 접근 제어 완전 해부
• Part 4 | 성능 최적화 — 인덱싱, 쿼리 튜닝, Auto-scaling
• Part 5 | AI 시대의 Atlas — Vector Search, Stream Processing, RAG 파이프라인

목차

1. 2025년 Atlas 클러스터 구조의 변화 — Serverless의 종말
2. 4가지 클러스터 티어 완전 분석
3. 티어 선택 가이드 — 내 서비스엔 뭐가 맞을까?
4. 멀티 리전 & 멀티 클라우드 설계 전략
5. 레플리카셋 vs 샤딩 — 언제 샤딩을 써야 하나?
6. 비용 최적화 실전 패턴
7. 클러스터 설계 체크리스트
8. 실무 적용 노트

1. 2025년 Atlas 클러스터 구조의 변화 — Serverless의 종말

MongoDB Atlas를 오래 써온 사람이라면 티어 구조가 꽤 달라졌음을 눈치챘을 것이다. 한때 인기를 끌었던 Serverless Instance와 Shared Tier(M2/M5)가 2025년 초에 공식 Deprecated되었고, Atlas Flex Tier가 이 둘을 완전히 대체했다.

이 변화가 중요한 이유는 단순한 이름 변경이 아니기 때문이다. Serverless의 예측 불가능한 비용 문제와 Shared Tier의 기능 제약 문제를 동시에 해결한 새로운 모델이 등장한 것이다. 기존에 Serverless나 M2/M5를 사용 중인 계정은 MongoDB가 Flex로 자동 마이그레이션하고 있다.

2. 4가지 클러스터 티어 완전 분석

M0 — Free Tier

M0는 학습, 프로토타입, 개인 프로젝트 용도다. 연결 수 제한, IOPS 제한, 백업 미지원 등 제약이 많다. 프로덕션에서는 사용할 수 없다.

Flex Tier — 2025년 2월 GA

Flex는 구 Serverless와 Shared(M2/M5)를 통합 대체한 새로운 티어다. 핵심 가치는 예측 가능한 비용과 가변 스케일링의 조합이다.

Flex 요금 시뮬레이션 (참고용):

시나리오: 100 ops/sec × 20일 + 250 ops/sec × 5일 + 500 ops/sec × 5일
→ 예상 요금: 약 $13.67

시나리오: 100 ops/sec × 20일만 사용 후 삭제
→ 예상 요금: 약 $5.28

Flex가 적합한 경우:

• MVP / 사이드 프로젝트
• 개발 / 스테이징 환경
• 트래픽이 불규칙한 초기 스타트업
• Vector Search 기능 테스트

Flex가 부적합한 경우:

• 지속적 고트래픽 서비스 (Dedicated M10이 더 저렴할 수 있음)
• 멀티 리전 / HA 구성 필요 시
• VPC Peering, Private Endpoint 등 고급 네트워크 보안 필요 시

Dedicated Tier — M10 ~ M700

프로덕션의 핵심이다. 전용 vCPU와 전용 RAM이 보장되며, Atlas의 모든 기능을 사용할 수 있다.

M10/M20는 공유 vCPU라서 CPU 집약적 워크로드에 취약하다. 프로덕션 기준선은 M30으로 잡는 것이 권장된다. Auto-scaling을 활성화하면 트래픽에 따라 M30 ↔ M40 ↔ M60 사이를 자동으로 오간다.

M30 이상에서 지원되는 전용 기능:

• 샤딩 클러스터
• 멀티 리전 / 멀티 클라우드 배포
• Private Endpoint / VPC Peering
• LDAP, X.509 인증
• Encryption at Rest (자체 KMS 키)
• Online Archive (Cold 스토리지 자동 계층화)

티어 구조 한눈에 보기

3. 티어 선택 가이드 — 내 서비스엔 뭐가 맞을까?

실제 현업에서 자주 만나는 시나리오별 권장 구성을 정리했다.

시나리오 A: 개인 개발자 / 사이드 프로젝트

추천: M0 (무료) → 필요 시 Flex로 업그레이드
이유: 비용 제로에서 시작, 5분 안에 클러스터 생성 가능

시나리오 B: 스타트업 초기 (MAU 10,000 미만)

추천: Flex Tier
이유: $8~$30/월 예측 가능, Vector Search 포함, 트래픽 스파이크 흡수
전환 신호: CPU 지속 70% 초과 또는 500 ops/sec 한계 도달 시 M30으로 업그레이드

시나리오 C: 일반 프로덕션 서비스

추천: M30 + Auto-scaling (M30-M60 범위 설정)
이유: 전용 vCPU 보장, 안정적 SLA (M10+ 기준 99.995%), 전체 기능 지원
백업: Continuous Cloud Backup (PITR) 활성화 필수

시나리오 D: 대용량 데이터 + 글로벌 서비스

추천: M50+ + 멀티 리전 (3리전 5노드 구성)
이유: 리전 장애 무중단 서비스, 글로벌 읽기 레이턴시 최소화
비용: 멀티 리전 구성 시 단일 리전 대비 약 2-3배 비용 증가 예상

시나리오 E: 글로벌 엔터프라이즈 / 컴플라이언스

추천: Global Cluster (M30+) 또는 지역별 독립 클러스터
이유: GDPR/데이터 주권 대응, 리전별 데이터 격리
핵심: EU 데이터는 EU 리전에만, 국내 데이터는 국내 리전에만 저장

4. 멀티 리전 & 멀티 클라우드 설계 전략

기본 개념: Replica Set의 리전 분산

Atlas의 모든 클러스터는 기본적으로 3노드 Replica Set이다. 단일 리전에서는 Atlas가 자동으로 3개의 Availability Zone에 분산 배치해 AZ 장애를 흡수한다.

단일 리전 구성은 AZ 1개 장애를 자동 Failover로 흡수하지만, 리전 전체 장애 시에는 서비스가 중단된다. 리전 장애까지 방어하려면 멀티 리전이 필요하다.

멀티 리전 구성 — 3리전 5노드 패턴 (M10 이상)

이 구성의 장애 대응 동작:

• 리전 A 전체 장애 → 리전 B가 Primary 자동 승격
• 리전 B 전체 장애 → 리전 A + C로 과반수(3/5) 유지
• 이론적 가용성: 99.999% 이상

Terraform으로 멀티 리전 클러스터를 구성하는 예시:

resource "mongodbatlas_advanced_cluster" "prod" {
  project_id   = var.project_id
  name         = "prod-cluster"
  cluster_type = "REPLICASET"

  replication_specs {
    region_configs {
      provider_name = "AWS"
      region_name   = "AP_NORTHEAST_2"  # Seoul
      priority      = 7
      electable_specs {
        instance_size = "M30"
        node_count    = 2
      }
    }

    region_configs {
      provider_name = "AWS"
      region_name   = "AP_SOUTHEAST_1"  # Singapore
      priority      = 6
      electable_specs {
        instance_size = "M30"
        node_count    = 2
      }
    }

    region_configs {
      provider_name = "AWS"
      region_name   = "AP_EAST_1"       # Hong Kong
      priority      = 5
      analytics_specs {
        instance_size = "M30"
        node_count    = 1
      }
    }
  }
}

멀티 클라우드 구성 — 벤더 락인 탈출

멀티 리전에서 한 발 더 나아가 AWS + Azure + GCP를 동시에 사용하는 멀티 클라우드 구성도 가능하다. 이 구성을 지원하는 것은 Atlas가 유일하다.

사용하는 이유:

• 특정 클라우드 장애 시 다른 클라우드로 자동 Failover
• 클라우드 벤더 협상 레버리지 확보 (락인 탈피)
• 클라우드별 특화 서비스 활용 (AI는 GCP, 메인은 AWS 등)
• 데이터 주권 요건 충족 (특정 국가에서 특정 클라우드만 허용되는 경우)

단점:

• 크로스 클라우드 트래픽 비용 발생 (인그레스/이그레스)
• 암호화 키 관리(KMS)가 클라우드별로 분리됨
• Private Endpoint를 각 클라우드마다 별도 설정 필요
• 운영 복잡도 증가

대부분의 서비스는 멀티 리전(단일 클라우드)으로 충분하다. 멀티 클라우드는 금융·의료처럼 컴플라이언스가 엄격하거나 매우 큰 엔터프라이즈에서 검토할 옵션이다.

Global Cluster — 진정한 글로벌 서비스를 위해

전 세계 사용자에게 로컬 쓰기(Local Write)를 제공해야 한다면 Global Cluster를 검토해야 한다.

Global Cluster는 최대 9개 Zone, 70개 샤드를 지원하며, 각 Zone이 독립적으로 읽기/쓰기를 처리한다. 아시아 사용자의 데이터는 아시아 샤드에, EU 사용자의 데이터는 EU 샤드에 저장해 GDPR 준수와 레이턴시 최소화를 동시에 달성한다. 단, 설계가 복잡하므로 진짜 글로벌 서비스가 아닌 이상 과투자가 될 수 있다.

5. 레플리카셋 vs 샤딩 — 언제 샤딩을 써야 하나?

샤딩이 필요한 시점

데이터가 많다고 무조건 샤딩이 답이 아니다.

샤드 키 선택 — 가장 중요한 결정

샤딩에서 가장 중요한 것은 샤드 키(Shard Key) 선택이다. 잘못 고르면 한 샤드에 부하가 집중되는 "핫스팟" 문제가 발생한다.

// 나쁜 샤드 키: 시간 기반 단조 증가 (모든 쓰기가 마지막 샤드에 집중)
{ createdAt: 1 }

// 나쁜 샤드 키: 카디널리티가 너무 낮음 (예: 성별)
{ gender: 1 }

// 좋은 샤드 키: 고카디널리티 + 균등 분포
{ userId: "hashed" }           // 해시 기반 균등 분포
{ region: 1, userId: 1 }       // 복합 키 (지역별 쿼리 최적화 + 균등 분포)
{ _id: "hashed" }              // 범용적으로 안전한 선택

샤드 키는 한 번 설정하면 변경이 어렵다(MongoDB 5.0 이전 기준 불가). 충분히 신중하게 결정해야 한다.

6. 비용 최적화 실전 패턴

패턴 1: Auto-scaling 범위를 좁게 설정

Auto-scaling은 양날의 검이다. 범위를 너무 넓게 잡으면 스파이크 때 M60으로 쭉 올라가버린다.

권장: M30 (최소)에서 M50 (최대) 범위 설정
비권장: M30 (최소)에서 M140 (최대) 범위 설정  ← 비용 폭탄 가능성

패턴 2: Analytics Node로 리포팅 쿼리 분리

무거운 집계 쿼리나 리포팅 쿼리를 프로덕션 Primary에서 실행하면 성능 저하와 불필요한 티어 업그레이드로 이어진다. Analytics Node를 별도로 달아 분리하는 것이 권장 패턴이다.

// Analytics Node로 라우팅하는 드라이버 설정 예시 (Node.js)
const client = new MongoClient(uri, {
  readPreference: 'secondary',
  readPreferenceTags: [{ nodeType: 'ANALYTICS' }]
});

패턴 3: Online Archive로 Cold 데이터 자동 계층화

오래된 로그 데이터를 Primary 클러스터에 그냥 두면 스토리지 비용이 급증한다. Online Archive를 설정하면 자동으로 S3-compatible 스토리지로 이동되고, 쿼리는 기존과 동일하게 동작한다.

// 30일 이상 된 데이터를 자동으로 Archive로 이동하는 규칙 예시
{
  "dataProcessRegion": { "cloudProvider": "AWS", "region": "AP_SOUTHEAST_2" },
  "criteria": {
    "type": "DATE",
    "dateField": "createdAt",
    "dateFormat": "ISODATE",
    "expireAfterDays": 30
  }
}

패턴 4: 비프로덕션 클러스터 업무 시간 외 자동 종료

개발/스테이징 클러스터를 24/7 켜두는 것은 낭비다. Atlas CLI와 스케줄러로 자동 종료/시작을 구현할 수 있다.

# 평일 밤 11시에 스테이징 클러스터 일시 정지
atlas clusters pause staging-cluster --projectId <PROJECT_ID>

# 평일 오전 8시에 재시작
atlas clusters start staging-cluster --projectId <PROJECT_ID>

패턴 5: 데이터 전송 비용 절감

Atlas 비용 중 의외로 큰 비중을 차지하는 것이 데이터 전송(네트워크 이그레스) 비용이다.

비용 발생 순서 (낮음 → 높음):
1. 같은 리전 내            → 무료 또는 최저
2. 같은 클라우드 다른 리전  → 중간
3. 다른 클라우드           → 높음
4. 인터넷으로 나가는 이그레스 → 가장 높음

절감 팁:
- 앱 서버를 Atlas 클러스터와 같은 리전에 배포
- 쿼리 Projection 사용으로 반환 데이터 최소화
- 드라이버에서 네트워크 압축 활성화

// 네트워크 압축 활성화 예시 (Node.js)
const client = new MongoClient(uri, {
  compressors: ['snappy', 'zlib'],
  zlibCompressionLevel: 6
});

7. 클러스터 설계 체크리스트

클러스터를 생성하기 전에 확인할 항목이다.

기본 설계

• 티어 선택: 워크로드에 맞는 티어 (Flex / M10 / M30+) 결정
• 클라우드 & 리전: 앱 서버와 동일한 클라우드/리전 선택
• MongoDB 버전: 최신 안정 버전(8.x) 사용
• 클러스터 이름: prod-myapp, staging-myapp 등 환경 구분 포함

가용성 & 복구

• Auto-scaling: Dedicated 클러스터라면 반드시 활성화
• Continuous Cloud Backup (PITR): 프로덕션 필수 (분 단위 복구 가능)
• 멀티 리전: SLA 99.999% 목표라면 3리전 5노드 구성
• Maintenance Window: 서비스 저트래픽 시간대(예: 새벽 3-5시)로 설정

보안 (Part 3에서 상세 설명)

• IP Access List: 최소 접근 권한 원칙 적용
• Database User: 앱별 전용 사용자 + 최소 권한
• Private Endpoint: M10+ 프로덕션이라면 설정 권장

비용 관리

• Billing Alert: 월 예상 비용 150% 초과 시 알림 설정
• Online Archive: 30일 이상 Cold 데이터 자동 아카이브 설정
• 비프로덕션 클러스터: 야간/주말 자동 pause 설정

Part 2 요약