Write DB 사양을 고정하고 Read DB를 상시 1대 + 피크 시 추가하는 구조. 중단 시간이나 리샤딩 부담 없이 Read DB를 확장과 축소할 수 있다. 다만 현재 부하는 단일 인스턴스 용량을 생각했을 때 초기부터 분리할 근거가 없어 읽기 부하가 임계치에 근접하면 RDS 리드 레플리카로 필요 시점에 적용한다.

초기 설계에서는 이 방식을 채택으로 두었으나, 단일 RDS로 충분하다는 부하 테스트 결과에 따라 "필요 시점에 적용하는 후보"로 조정했다.

                ┌──────────────┐
                │   Backend    │
                └──────┬───────┘
                       │
          ┌────────────┴────────────┐
          │                         │
       Write                      Read
          │                         │
          ▼                ┌────────┴────────┐
  ┌──────────────┐         ▼                 ▼
  │   Write DB   │  복제  ┌──────────────┐ ┌──────────────┐
  │   상시 고정   │ ─────▶ │  Read DB 1   │ │  Read DB 2   │
  └──────────────┘       │     상시      │ │  피크 때만     │
          │              └──────────────┘ └──────▲───────┘
          └──────────────────── 복제 ─────────────┘

1. 사용자가 Write 요청을 보낸다.
2. Write DB가 데이터를 변경한다.
3. Write DB가 변경 내용을 로그에 기록한다.
4. Write DB가 Read DB의 반영을 기다리지 않고 클라이언트에 성공 응답을 보낸다.
5. Read DB가 로그를 가져와 Relay Log에 저장한다.
6. Replica의 스레드가 Relay Log를 순서대로 반영한다.
7. 일정 시간이 지나면 Write DB와 Read DB의 상태가 같아진다.

리샤딩 축소가 어렵고 전환 시 쓰기 중단 필요. 쓰기 부하가 많아서 고려했으나 다운 타임 없이 운영이 불가능해 채택하지 않았다.

Read/Write DB를 분리한 뒤 Write DB만 샤딩해 쓰기 I/O를 여러 노드로 분산하는 구조. 피크/비피크 트래픽 차이가 약 9배라 피크에 맞춰 확장된 상태를 유지하면 낭비가 크고 비피크에 축소하려면 리샤딩이 필요한데 이 과정에서 데이터 재배치와 쓰기 중단이 발생해 채택하지 않았다.

샤드 축소가 어려운 이유

1. 샤딩 키 재배치가 필요하다. 일관된 해싱으로 이동 범위를 줄일 수는 있어도 데이터 재배치 자체를 없앨 수는 없다.
2. 무중단 축소가 어렵다. 전환 중 쓰기 요청을 위한 별도 큐와 재처리가 필요하다.
3. 마이그레이션 중 쓰기를 동기화해야 한다. 쓰기 DB는 변경이 계속 발생해 동기화 지연이 완전히 사라지는 시점을 보장하기 어렵고, 최종 전환 시점에는 정합성을 위해 짧게라도 쓰기를 중단해야 한다.

1. 제거할 샤드를 선정하고 축소 작업을 준비한다.
2. 제거할 샤드가 담당하던 키 범위를 어느 샤드로 이전할지 결정한다.
3. 기존 데이터를 새로운 담당 샤드로 복사한다.
4. 복사 중 들어온 추가 쓰기를 새 담당 샤드에 동기화하고 데이터를 검증한다.
5. 제거 대상 샤드의 쓰기를 일시 중단한다. (요청을 큐에 보관하는 등의 처리 필요)
6. 트래픽을 새 담당 샤드로 전환한다.
7. 전환을 확인한 후 기존 샤드를 제거한다.

참고 자료

• [MongoDB 공식 문서 — 샤드 클러스터에서 샤드 제거](https://www.mongodb.com/ko-kr/docs/manual/tutorial/remove-shards-from-cluster/)

:서비스 특성상 피크 시점이 명확해 상시 자동 스케일링은 비용 비효율이다.

부하에 따라 다운타임 없이 용량이 자동 조절되는 관리형 서비스 부하 발생 시점을 특정할 수 없는 경우에 적합하다. 그러나 우리 서비스는 피크가 오후 8~10시로 명확해 자동 스케일링의 이점이 크지 않고 비용이 비싸다. 부하가 발생하지 않는 시점에도 7000명으로 꽤 많은 사용자가 이용한다.

참고 자료

• [올리브영 기술 블로그 — 피크 시점을 예측할 수 없는 경우 Aurora Serverless v2 채택 사례](https://oliveyoung.tech/2026-02-10/esl-series-2/)
• [Aurora 수직 자동 확장 구현(Lambda 기반) 사례](https://palark.com/blog/aws-rds-aurora-vertical-autoscaling/)