V1 Migration - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

0. 도입 배경 및 목표

기존 V1 환경(10.0.0.0/16)의 EC2 기반 데이터베이스를 새로운 아키텍처인 V2 VPC(192.168.10.0/16)의 RDS로 이전해야 하는 상황이었습니다. 서비스 중단을 최소화하고 데이터 정합성을 유지하며, 보안과 비용 효율성을 모두 잡기 위해 AWS DMS(Database Migration Service) 를 활용한 마이그레이션을 결정했습니다.

---

1. 네트워크 설계: 왜 VPC Peering인가?

단순한 데이터 이동을 넘어, 엔터프라이즈급 안정성을 확보하기 위해 VPC Peering을 우선적으로 구축했습니다.

• 보안 (Security): 데이터가 공용 인터넷을 타지 않고 AWS 내부망으로만 흐릅니다. DB 포트(5432)를 외부로 개방할 필요 없이 상대 VPC 대역에만 허용하면 되므로 해킹 위협을 원천 차단합니다.
• 비용 절감 (Cost Efficiency): 인터넷 경유 시 발생하는 높은 'Data Transfer Out' 비용을 피하고, 동일 리전 내 내부 통신 비용만 지불하여 수백 GB의 데이터를 경제적으로 전송합니다.
• 성능 및 안정성 (Reliability): 공용 인터넷의 변동성(Jitter) 없이 저지연(Low Latency) 전송이 가능하여, 대용량 마이그레이션 중 연결 끊김으로 인한 재작업 리스크를 방지합니다.

---

2. 워크로드 분석 및 부하 테스트 전략

단순 복제가 아닌, 서비스 특성에 맞는 마이그레이션 검증을 위해 '현실성' 있는 시나리오를 설계했습니다.

• Read vs Write 집중도: 일반 게시판과 달리 챗봇 서비스는 대화 기록 저장 및 상태 유지를 위한 Write 비중이 매우 높습니다.
• 부하 시나리오: 챗봇의 긴 트랜잭션 특성을 반영하여 DB 커넥션 풀(Connection Pool) 고갈 및 데드락(Deadlock) 상황을 의도적으로 주입, 타겟 RDS가 운영 트래픽을 견딜 수 있는지 사전에 검증하고자 합니다. (Staging에서 체크 예정)

---

3. 트러블슈팅 및 해결 과정

3.1 소스 엔드포인트 접속 불가 (PostgreSQL 설정)

DMS 복제 인스턴스가 소스 DB에 접속하지 못하는 문제가 발생했습니다.

1. 제1관문 (postgresql.conf): listen_addresses가 localhost로 제한되어 있어 외부 신호를 차단하고 있었습니다. 이를 프라이빗 IP로 수정하여 귀를 열어주었습니다.
2. 제2관문 (pg_hba.conf): 신분증 검사 단계입니다. DMS 복제 인스턴스의 프라이빗 IP에 대해 scram-sha-256 방식의 접속 권한을 명시적으로 추가했습니다.

3.2 실시간 동기화(CDC)를 위한 wal_level 변경

DMS의 핵심인 CDC(Change Data Capture) 기능을 위해 로그 수준을 replica에서 logical로 격상해야 했습니다.

• 문제: wal_level 변경은 단순 'Reload'가 아닌 DB 프로세스 재시작이 필수적입니다.
• 대응 전략: * 개발 환경: 새벽 시간대 점검 창(Maintenance Window)을 활용한 즉시 재시작.
• 운영 환경 (Blue-Green): 운영 DB의 EBS 스냅샷으로 Green 서버를 복제 후, Green 서버에서 설정을 변경하고 재시작하여 다운타임을 최소화하는 전략을 채택했습니다.

3.3 타겟 RDS PK 제약 조건 위반 (ID Null 에러)

마이그레이션 중 null value in column "id" violates not-null constraint 에러와 함께 500 오류가 발생했습니다.

• 원인: DMS의 자동 테이블 생성 옵션(Drop tables on target) 사용 시, 데이터 타입은 복사되지만 Serial/Identity/Sequence 같은 자동 증가(Auto-increment) 속성이 누락되는 현상이 확인되었습니다.
• 해결:

1. pg_dump를 사용해 스키마(구조)만 먼저 타겟 RDS에 생성하여 Sequence를 유지했습니다.
2. DMS 설정을 TargetTablePrepMode = TRUNCATE로 변경하여, 이미 정의된 스키마 구조를 건드리지 않고 데이터만 채우도록 수정했습니다.

---

4. 배운 점 및 결론

1. 도구의 한계 이해: DMS는 데이터를 옮겨주지만, 인덱스나 자동 증가 값(Sequence) 같은 상세한 DB 오브젝트까지 완벽하게 재현하지는 않습니다. "스키마는 수동, 데이터는 DMS" 라는 공식의 중요성을 배웠습니다.
2. 네트워크가 우선: 안정적인 마이그레이션의 기반은 탄탄한 VPC 설계(Peering)에서 시작됨을 확인했습니다.
3. 데이터 성격에 따른 분리: 모든 데이터를 옮길 필요는 없습니다. Redis의 ratelimit 같은 휘발성 데이터는 과감히 제외하여 마이그레이션의 효율성을 높였습니다.