Blue-Green을 통한 용량 확장 방식

RDS Multi-AZ DB 인스턴스 구성이 존재한다. 평소에는 한쪽이 운영 DB로 읽기,쓰기를 처리하고 다른 AZ의 대기 인스턴스에 데이터를 동기식으로 복제합니다. 운영 인스턴스나 AZ에 장애가 나면 RDS가 대기 인스턴스로 자동 전환합니다.

하지만 트래픽 증가로 기존 DB 사양의 처리 용량을 초과한 경우에는 동일 사양의 대기 인스턴스로 전환해도 문제가 해소되지 않습니다. 따라서 요청 지연과 오류율, DB 자원 사용률을 모니터링해 용량 부족을 조기에 감지하고 지속적인 용량 증가가 확인되면 Blue/Green으로 상위 사양을 준비해 전환하는 방식을 추가적으로 고려했습니다.

채택 근거

• 일회성·예측 가능한 확장: 단일 인스턴스가 이미 피크를 감당하므로 확장은 트래픽이 사이징을 넘어서는 시점의 일회성 작업이다. 피크가 오후 8~10시로 명확해 트래픽이 바닥인 새벽에 예약 전환할 수 있어 전환 다운타임의 영향 사용자를 0에 가깝게 줄일 수 있다.
• 낮은 전환 비용: Read는 중단 없이 유지되고 Write만 약 30초 중단되며 Green이 Blue의 엔드포인트를 넘겨받아 애플리케이션 설정 변경이 필요 없다.
• 안전한 전환: Green 환경을 미리 띄워 검증한 뒤 전환하므로 문제가 확인되면 전환 전에 중단할 수 있다.

동작 방식

1. Green 환경 생성: 현재 운영 중인 Multi-AZ 구성인 Blue를 기반으로 Blue/Green 배포를 생성한다. Green의 DB 인스턴스를 상위 사양으로 변경하고 이 과정에서도 Blue는 서비스를 계속 처리한다.
2. 동기화 및 검증: Green이 Blue의 변경 데이터를 복제하는 동안 Green의 인스턴스 상태, 복제 상태를 확인한다.
3. 트래픽 전환: RDS는 새 쓰기를 중단하고 기존 연결을 끊은 뒤 Green이 Blue를 따라잡으면 운영 DB의 이름과 엔드포인트를 Green으로 이전한다.
4. 서비스 정상화 확인: 애플리케이션이 DB 연결을 다시 맺은 후 요청이 잘 처리되는지 확인하다.

전환 시 Write는 약 30초 중단되며 전체 전환은 1~2분 내에 끝난다.

참고 자료

• [AWS RDS Blue-Green Deployments — 전환(Switchover) 공식 문서](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-switching.html#blue-green-deployments-switching-actions)
• [LG ThinQ 적용 사례 (영상)](https://www.youtube.com/watch?v=H0kJvLAEcrQ&t=433s) — Read는 중단 없이 계속되고 Write만 약 30초 중단, 전체 전환 1~2분 (위 "동작 방식"의 다운타임 근거)
• [CRED의 Amazon RDS Blue-Green 대규모 활용 사례 (AWS 블로그)](https://aws.amazon.com/ko/blogs/database/how-cred-uses-amazon-rds-blue-green-deployments-at-scale/)
• [Lambda + EventBridge로 예약 기동/종료 구현 사례](https://wikidocs.net/397337) — 새벽 예약 전환 스케줄링 참고