NeedU V1 → V2 Production 마이그레이션 결과 보고서 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki
NeedU V1 → V2 6차 Production 마이그레이션 결과 보고서
1. 개요
1.1 목적
2026년 10월 19일 진행한 6차 Production 마이그레이션에서는 V1 EC2 환경에서 V2 ECS/RDS 환경으로 데이터베이스와 서비스 트래픽을 이전하는 자동화 절차를 최종 검증했다.
이번 리허설에서는 5차에서 확인한 결과를 기준으로 다음 항목을 검증했다.
- Production Preflight 20개 항목 통과 여부
- MySQL DMS Full Load 및 CDC 상태
- PostgreSQL Catalog 및 임베딩 구조 정합성
- GitHub Actions 기반 Preflight + Cutover 전체 실행 시간
- Write Gate 활성화 및 해제 시간
- ECS 및 ALB Target Health
- Cutover 중 조회 부하 및 ALB 오류
- V2 데이터 정리 작업
- 실패 시 V1 복구 정책과 자동 복구의 한계
1.2 마이그레이션 환경
| 항목 | 내용 |
|---|---|
| 수행 일자 | 2026-10-19 |
| 대상 | V1 → V2 Production |
| V1 | EC2 + Nginx + Docker Compose |
| V1 DB | EC2 MySQL / PostgreSQL |
| V2 | ALB + ECS Frontend/Backend/AI |
| V2 DB | RDS MySQL / PostgreSQL |
| MySQL 이전 | AWS DMS Full Load + CDC |
| PostgreSQL 이전 | pg_dump / pg_restore |
| 트래픽 전환 | ALB Listener Rule |
| 쓰기 제한 | ALB Write Gate |
| 자동화 | GitHub Actions |
| 부하 테스트 | k6 |
| 모니터링 | Grafana, CloudWatch |
| 도메인 | needu.gift |
1.3 주요 결과
| 항목 | 결과 | 판정 |
|---|---|---|
| Preflight | 20 PASS / 0 FAIL | PASS |
| Preflight 완료 | 15:52:28 KST | 확인 |
| Preflight 소요 시간 | 1분 17초(77초) | 확인 |
| Cutover 소요 시간 | 2분 37초(157초) | SUCCESS |
| Preflight + Cutover 전체 | 4분 41초(281초) | SUCCESS |
| Write Gate ON | 15:53:49 KST | 확인 |
| Write Gate OFF | 15:55:22 KST | 확인 |
| Write Freeze | 1분 33초(93초) | 확인 |
| DMS Full Load | 100% | PASS |
| DMS Validation | Pending/Failed 없음 | PASS |
| ECS | FE/BE/AI 각각 2개 이상 | PASS |
| ALB Target Health | 정상 | PASS |
| RDS | MySQL/PostgreSQL Available | PASS |
| Data Reconciliation | 대상 DB 검증 통과 | PASS |
| 최종 RPO 0 | 별도 증빙 필요 | 미확정 |
| 실패 시 V1 복구 | 실제 실행 검증 미확정 | 추가 검증 |
종합 판정: Preflight 20/20 PASS / Cutover SUCCESS / 전체 자동화 281초 / Write Freeze 93초
2. Production 마이그레이션 타임라인
2.1 실행 기록
모든 시각은 2026-10-19 KST 기준이다.
| 시각 | 단계 | 결과 |
|---|---|---|
| 15:50분대 | 전체 자동화 | GitHub Actions 실행 시작 표시 |
| 15:52:28 | Preflight 완료 | PASS 20 / FAIL 0 |
| 15:53:49 | Write Gate ON | 쓰기 요청 제한 시작 |
| 15:55:22 | Write Gate OFF | 쓰기 요청 제한 종료 |
| 정확한 초 단위 미확인 | 전체 자동화 완료 | SUCCESS |
GitHub Actions 실행 기록:
6차 Production GitHub Actions 실행 시간
Oct 19, 3:50 PM GMT+9
4m 41s
GitHub Actions에 표시된 4분 41초는 Preflight와 Cutover를 포함한 전체 실행 시간이다.
2.2 단계별 실행 시간
| 단계 | 소요 시간 |
|---|---|
| Preflight | 1분 17초(77초) |
| Cutover | 2분 37초(157초) |
| Preflight + Cutover 전체 | 4분 41초(281초) |
| Write Freeze | 1분 33초(93초) |
개별 단계와 전체 실행 시간을 구분하면 다음과 같다.
Preflight = 77초
Cutover = 157초
개별 단계 합계 = 234초
전체 Workflow 실행 시간 = 281초
차이 = 47초
전체 Workflow 실행 시간과 개별 단계 합계 사이에는 47초 차이가 있다.
이 차이는 두 단계 이외의 실행 시간 또는 대기 구간 등이 포함됐을 가능성이 있으나, 정확한 원인은 Workflow Step별 실행 기록을 확인해야 한다.
따라서 281초를 Cutover 단계만의 실행 시간으로 해석하지 않는다.
2.3 Write Freeze 계산
Cutover Summary:
Result: success
Gate ON: 2026-10-19T06:53:49Z
Gate OFF: 2026-10-19T06:55:22Z
UTC를 KST로 변환하면 다음과 같다.
Gate ON = 2026-10-19 15:53:49 KST
Gate OFF = 2026-10-19 15:55:22 KST
Write Freeze = 93초
= 1분 33초
2.4 Cutover 중 Write Gate 비율
Cutover 단계 = 157초
Write Freeze = 93초
Gate 외 시간 = 64초
Write Gate 활성 비율
= 93 / 157 × 100
≈ 59.2%
Cutover 단계 157초 중 93초 동안 Write Gate가 활성화됐다.
이는 Cutover 단계의 약 59.2%에 해당한다.
전체 Workflow 실행 시간 281초를 기준으로 하면 Write Gate 활성 비율은 약 33.1%다.
Write Freeze는 쓰기 요청 제한 시간이며, 조회 서비스까지 포함한 전체 서비스 중단 시간과 동일하지 않다.
3. 5차 및 6차 마이그레이션 비교
3.1 실행 시간 비교
| 항목 | 5차 | 6차 | 변화 |
|---|---|---|---|
| Preflight | 62초 | 77초 | 15초 증가 |
| Cutover | 192초 | 157초 | 35초 단축 |
| 개별 단계 합계 | 254초 | 234초 | 20초 단축 |
| 전체 Workflow | 261초 | 281초 | 20초 증가 |
| 단계 합계 외 시간 | 7초 | 47초 | 40초 증가 |
| Write Freeze | 129초 | 93초 | 36초 단축 |
| Cutover 중 Gate 외 시간 | 63초 | 64초 | 1초 증가 |
3.2 Cutover 단계 개선
5차 Cutover = 192초
6차 Cutover = 157초
단축 시간 = 35초
감소율 = 35 / 192 × 100
≈ 18.2%
6차 Cutover 단계는 5차 대비 35초 단축됐다.
3.3 Write Freeze 개선
5차 Write Freeze = 129초
6차 Write Freeze = 93초
단축 시간 = 36초
감소율 = 36 / 129 × 100
≈ 27.9%
6차 Write Freeze는 5차 대비 36초 단축됐다.
3.4 전체 Workflow 시간 분석
5차 전체 Workflow = 261초
6차 전체 Workflow = 281초
전체 실행 시간 = 20초 증가
6차에서는 Cutover 단계와 Write Freeze가 단축됐지만, Preflight를 포함한 전체 Workflow 실행 시간은 20초 증가했다.
따라서 Cutover 단계의 실행 시간 개선과 전체 Workflow 실행 시간 개선을 구분해야 한다.
현재 확보한 단계별 기록만으로 전체 Workflow 시간이 증가한 정확한 원인을 확정할 수는 없다.
4. Production Preflight 검증
4.1 Preflight 실행 결과
| 항목 | 결과 |
|---|---|
| Workflow | Prod Migration Preflight |
| 실행 방식 | Read-only |
| 완료 | 2026-10-19 15:52:28 KST |
| 소요 시간 | 77초 |
| PASS | 20 |
| FAIL | 0 |
| 최종 결과 | PASS |
4.2 인프라 검증
| 검증 항목 | 결과 | 상세 |
|---|---|---|
| DNS | PASS | DNS phase=after, Route53 레코드 검증 |
| ALB | PASS | Priority 5/20, V1=100%, V2=0% |
| V1 Target | PASS | Healthy |
| Write Gate | PASS | Disabled |
| ECS | PASS | FE/BE/AI Running 2개 이상 |
| ALB Target | PASS | Healthy |
| RDS | PASS | MySQL/PostgreSQL Available |
| DMS | PASS | Running, Full Load 100% |
| DMS Validation | PASS | Pending/Failed 없음 |
RDS Available 검증은 인스턴스 메타데이터 기반 상태 확인이다.
SQL 기반 데이터 정합성 검증과는 구분된다.
4.3 MySQL 데이터 검증
실제 데이터베이스 테이블명은 공개하지 않고 검증 대상의 의미만 기록한다.
| 검증 대상 | 검증값 | 결과 |
|---|---|---|
| 전체 테이블 수 | 22 | PASS |
| 친구 관계 데이터 | 438 | PASS |
| 인증 세션 데이터 | 155 | PASS |
| 취향 분석 데이터 | 0 | PASS |
| 상품 데이터 | 7,969 | PASS |
| AI 대화방 데이터 | 230 | PASS |
| 사용자 데이터 | 73 | PASS |
| 오류 보고 데이터 | 2 | PASS |
4.4 PostgreSQL 데이터 검증
| 검증 대상 | 검증값 | 결과 |
|---|---|---|
| 임베딩 모델 메타데이터 | 1 | PASS |
| 상품 문서 데이터 | 20,289 | PASS |
| 상품 Catalog 데이터 | 7,969 | PASS |
| Catalog 동기화 기록 | 0 | PASS |
| 임베딩 타입 | vector(1024) | PASS |
| HNSW Cosine Index | 1 | PASS |
전체 데이터 행 수:
1 + 20,289 + 7,969 + 0 = 28,259행
4.5 Data Reconciliation
Preflight Summary:
Data reconciliation: PASS
All target database checks passed.
정의된 대상 데이터베이스 검증 항목이 모두 통과했다.
다만 이 결과는 Cutover 직전 성공한 모든 쓰기가 V2에 반영됐다는 사실까지 입증하지는 않는다.
따라서 최종 RPO 0은 별도 증빙이 필요하다.
5. MySQL 마이그레이션 검증
5.1 DMS 상태
| 항목 | 결과 |
|---|---|
| DMS Task | Running |
| Full Load | 100% |
| Pending Validation | 없음 |
| Failed Validation | 없음 |
| CDC Lag | 별도 검토 필요 |
| Preflight | PASS |
5.2 CDC 지연 분석
기존 Production 모니터링에서는 DMS Source/Target Latency가 약 4초에서 0초까지 감소하는 구간이 관측됐다.
CDC Lag가 0초로 감소했다는 사실만으로 최종 RPO 0을 확정할 수는 없다.
최종 Cutover 직전의 복제 상태와 성공한 쓰기 요청의 반영 여부를 추가로 확인해야 한다.
5.3 5차 대비 데이터 변화
| 검증 대상 | 5차 | 6차 | 변화 |
|---|---|---|---|
| 전체 테이블 수 | 22 | 22 | 0 |
| 친구 관계 데이터 | 438 | 438 | 0 |
| 인증 세션 데이터 | 150 | 155 | +5 |
| 취향 분석 데이터 | 0 | 0 | 0 |
| 상품 데이터 | 7,969 | 7,969 | 0 |
| AI 대화방 데이터 | 229 | 230 | +1 |
| 사용자 데이터 | 73 | 73 | 0 |
| 오류 보고 데이터 | 2 | 2 | 0 |
두 회차 모두 Preflight 검증 결과는 PASS였다.
인증 세션 데이터와 AI 대화방 데이터의 행 수가 증가했으나, 이 차이만으로 데이터 유실이나 중복이 발생했다고 판단할 수는 없다.
6. PostgreSQL 마이그레이션 검증
6.1 이전 방식
PostgreSQL은 MySQL의 DMS CDC 방식과 달리 Dump/Restore 방식으로 이전했다.
주요 작업 순서는 다음과 같다.
- V2 RDS 스냅샷 생성
- 이전 대상 데이터 초기화
- V1 PostgreSQL Dump 생성
- S3 업로드
- Bastion 다운로드
- SHA-256 체크섬 비교
- V2 RDS Restore
- V1/V2 행 수 비교
- PK 및 스키마 비교
- 전체 데이터 해시 비교
6.2 데이터 정합성 검증
| 항목 | 5차 | 6차 | 결과 |
|---|---|---|---|
| 임베딩 모델 메타데이터 | 1 | 1 | 동일 |
| 상품 문서 데이터 | 20,289 | 20,289 | 동일 |
| 상품 Catalog 데이터 | 7,969 | 7,969 | 동일 |
| Catalog 동기화 기록 | 0 | 0 | 동일 |
| 전체 행 수 | 28,259 | 28,259 | 동일 |
| 임베딩 타입 | vector(1024) | vector(1024) | 동일 |
| HNSW Cosine Index | 1 | 1 | 동일 |
기존 이전 과정에서 V1/V2 데이터 행 수, PK, 스키마 및 전체 데이터 해시 비교를 수행했고 정합성 일치가 보고됐다.
6차 Preflight에서도 동일한 Catalog 데이터 행 수와 임베딩 구조가 확인됐다.
다만 6차 Preflight 자체에서 전체 데이터 해시 비교를 다시 수행했다고 볼 근거는 없다.
6.3 PostgreSQL RPO 0 검증
PostgreSQL은 Dump/Restore 방식이므로 Dump 이후 성공한 쓰기 요청이 존재하는지 확인해야 한다.
데이터 해시가 일치하더라도 Dump 이후 발생한 모든 쓰기 이력의 반영 여부를 자동으로 입증하지는 못한다.
따라서 최종 RPO 0은 추가 로그 증빙이 필요하다.
7. Production Cutover 검증
7.1 Cutover 실행 결과
| 항목 | 결과 |
|---|---|
| Workflow 단계 | Prod Migration Cutover |
| Result | SUCCESS |
| 소요 시간 | 2분 37초 |
| Gate ON | 15:53:49 KST |
| Gate OFF | 15:55:22 KST |
| Write Freeze | 1분 33초 |
7.2 Cutover 데이터 정리 작업
6차 Cutover Summary에는 다음 작업이 명시돼 있다.
- 일반 사용자 온보딩 상태 초기화
- 테스트 사용자 온보딩 상태 유지
- V2 취향 프로필 데이터 삭제
- V2 추천 데이터 삭제
- V2 AI 메시지 내용 삭제
- 진행 중인 AI 대화방 만료 처리
- 상품 카테고리 정규화
일반 사용자는 온보딩 상태를 ONBOARDING으로 초기화한다.
테스트 사용자(external_id < 0)는 기존 온보딩 상태를 유지한다.
7.3 실패 시 자동 복구 정책
Cutover Summary에는 다음 정책이 명시돼 있다.
On failure/cancellation before Gate OFF is confirmed:
1. Route to V1
2. Verify at least one healthy V1 target
3. Release the Gate
4. Attempt to restore V2 user flags
Gate OFF 확인 이전에 실패하거나 Workflow가 취소되면 다음 절차를 수행하도록 설계됐다.
- ALB 트래픽을 V1으로 복원
- V1 Healthy Target 최소 1개 확인
- Write Gate 해제
- V2 사용자 상태 플래그 복원 시도
7.4 자동 복구의 한계
Cutover Summary에는 다음 제한 사항이 명시돼 있다.
- V2 데이터 정리 결과는 자동 복원되지 않음
- 재시도 전 V2 데이터 재적재 또는 초기화 필요
- GitHub Actions Runner 손실 시 수동 복구 필요
- AWS Control Plane 장애 시 수동 복구 필요
- DMS 중지 이후 자동 재시작하지 않음
또한 다음 결과가 보고됐다.
V1 service recovery step:
not confirmed; inspect recovery step and evidence
따라서 Cutover SUCCESS와 실제 실패 상황에서 V1 복구가 성공했는지는 구분해야 한다.
8. k6 Cutover 중 조회 부하 테스트
8.1 테스트 목적
Production Cutover 중 조회 API의 연속 가용성을 확인하기 위해 k6를 사용했다.
8.2 기존 Production 테스트 구성
| 항목 | 설정 |
|---|---|
| 도구 | Grafana k6 |
| 대상 | https://needu.gift |
| 목표 RPS | 4 |
| 실행 시간 | 10분 |
| 초기 VUs | 5 |
| 최대 VUs | 10 |
| 테스트 유형 | 조회 API |
8.3 기존 테스트 결과
| 지표 | 결과 |
|---|---|
| 완료 Iterations | 2,399 |
| 중단 Iterations | 0 |
| Dropped Iterations | Threshold 초과 |
| HTTP 성공률 | 데이터 없음 |
| HTTP 실패율 | 데이터 없음 |
| HTTP p95 | 데이터 없음 |
| Grafana k6 지표 | No data |
기존 테스트에서는 k6 Summary 저장 경로가 존재하지 않았고 Prometheus Remote Write 출력 옵션이 적용되지 않았다.
따라서 HTTP 성공률과 응답시간을 확보하지 못했다.
8.4 6차 검증 판정
제공된 6차 Cutover Summary에는 별도 k6 실행 결과가 포함되지 않았다.
따라서 기존 k6 결과를 6차 Cutover의 실제 성능 결과로 사용하지 않는다.
- k6 기존 실행: 확인
- 6차 HTTP 성공률: 미확정
- 6차 HTTP p95: 미확정
- Cutover 중 조회 서비스 가용성: 추가 검증 필요
9. Production ALB 트래픽 및 오류 분석
9.1 ALB Request Rate
기존 Production Grafana에서 관측한 요청률은 다음과 같다.
| 시각 | 요청률 |
|---|---|
| 15:45~15:49 | 약 0 RPS |
| 15:51 | 약 1 RPS |
| 15:52 | 약 4 RPS |
| 15:55 | 약 5 RPS |
| 15:57 | 약 6.1 RPS |
| 16:01 | 약 3 RPS |
해당 자료는 Production ALB에 요청이 유입됐음을 보여준다.
다만 기존 보고서의 관측 자료이므로 6차 Cutover 중 모든 요청이 정상 처리됐다는 직접 증거로 사용하지 않는다.
9.2 ALB HTTP 5xx
기존 관측 자료에서는 15:53경 ALB 5xx가 1건 발생했다.
6차 Write Gate ON 시각은 15:53:49 KST다.
그러나 Grafana의 분 단위 관측 시각만으로 해당 5xx가 Write Gate 활성화 때문에 발생했다고 단정할 수 없다.
9.3 Target Response Time p95
기존 관측 자료에서는 15:55경 Target Response Time p95가 약 270ms까지 상승했다.
ALB Target Response Time은 클라이언트 전체 응답시간과 다르므로 k6 HTTP p95와 구분해야 한다.
9.4 검증 결과
- Production ALB 요청 유입: 확인
- ALB 5xx 일부 관측: 확인
- 6차 Cutover와 오류의 인과관계: 미확정
- 6차 전체 HTTP 오류율: 미확정
10. ECS 및 ALB Target Health 분석
10.1 ECS Running Task
6차 Preflight에서는 FE/BE/AI Running Task가 각각 2개 이상인지 확인했다.
| 서비스 | 결과 |
|---|---|
| Frontend | PASS |
| Backend | PASS |
| AI | PASS |
10.2 ALB Target Health
6차 Preflight에서는 ALB Target Health가 정상인지 확인했다.
기존 Grafana 자료에서는 다음 상태가 관측됐다.
| 서비스 | Healthy | Unhealthy |
|---|---|---|
| Frontend | 2 | 0 |
| Backend | 2 | 0 |
10.3 검증 판정
- ECS FE/BE/AI Running: PASS
- ALB Target Health: PASS
- Cutover 이후 장시간 안정성: 추가 관측 필요
11. V1 및 V2 트래픽 전환 검증
11.1 Cutover 이전 ALB 설정
6차 Preflight에서는 다음 상태를 확인했다.
ALB Priority 5/20
V1 = 100%
V2 = 0%
V1 Healthy
Write Gate Disabled
이는 Cutover 이전 V1으로 트래픽이 전달되도록 설정됐음을 보여준다.
11.2 V1 Nginx Request Rate
기존 Grafana 자료에서는 V1 Nginx Request Rate가 약 0.2 RPS로 관측됐다.
해당 요청률에 Health Check 또는 내부 요청이 포함됐는지는 확인되지 않았다.
따라서 V1 Nginx RPS가 0이 아니라는 이유만으로 트래픽 전환 실패를 판단할 수 없다.
11.3 Cutover 이후 ALB 설정
6차 Cutover Workflow는 SUCCESS로 완료됐다.
다만 제공된 Summary에는 Cutover 이후 Listener Rule의 최종 가중치가 직접 표시되지 않았다.
따라서 최종 V1=0%, V2=100% 여부는 Listener Rule 설정으로 별도 확인해야 한다.
12. 모니터링 및 관측성 검증
12.1 모니터링 항목
- Production ALB Request Rate
- Production ALB HTTP 4xx/5xx
- Production ALB Target Response Time p95
- ECS Running/Pending Task
- ALB Healthy/Unhealthy Host
- DMS CDC Source/Target Latency
- V1 Nginx Request Rate
- k6 HTTP 성공률 및 응답시간
- GitHub Actions Preflight/Cutover 결과
- Write Gate ON/OFF 타임스탬프
12.2 6차 자동화 검증
| 항목 | 결과 |
|---|---|
| Preflight | PASS |
| Preflight PASS/FAIL | 20 / 0 |
| Preflight 완료 | 15:52:28 KST |
| Cutover | SUCCESS |
| Gate ON | 15:53:49 KST |
| Gate OFF | 15:55:22 KST |
| Write Freeze | 93초 |
| Cutover 단계 | 157초 |
| 전체 Workflow | 281초 |
12.3 5차 대비 개선 사항
6차에서는 Cutover Summary에 다음 사항이 명확하게 기록됐다.
- 일반 사용자 온보딩 상태 초기화
- 테스트 사용자 온보딩 상태 유지
- V2 취향 프로필 및 추천 데이터 정리
- AI 메시지 삭제 및 진행 중 대화방 만료
- 상품 카테고리 정규화
- 실패 시 V1 Healthy Target 확인
- V2 사용자 상태 플래그 복원 시도
- V2 데이터 정리 결과의 자동 복원 제한
- DMS 자동 재시작 미지원
이를 통해 자동화 성공 여부뿐 아니라 데이터 변경 범위와 실패 복구 정책의 한계를 확인할 수 있었다.
13. 발견된 문제 및 원인 분석
13.1 전체 Workflow 시간 증가
13.1.1 현상
5차 전체 Workflow는 261초, 6차 전체 Workflow는 281초였다.
6차에서 전체 실행 시간은 20초 증가했다.
반면 Cutover 단계는 35초 단축됐다.
13.1.2 분석
Preflight 단계는 15초 증가했고, 개별 단계 합계 외 시간은 40초 증가했다.
따라서 Cutover 단계 단축에도 불구하고 전체 Workflow 시간이 증가했다.
13.1.3 개선 방향
- GitHub Actions Job별 시작·종료 시각 기록
- Preflight 완료 후 Cutover 시작까지의 대기 시간 측정
- AWS API 호출 및 상태 대기 시간 측정
- Workflow 전체 시간과 단계별 시간 분리
13.2 Write Freeze 지속 시간
13.2.1 현상
5차 Write Freeze는 129초, 6차는 93초였다.
13.2.2 분석
36초 단축됐으며 약 27.9% 감소했다.
Cutover 단계 역시 35초 단축됐다.
다만 어떤 내부 단계가 직접적으로 단축됐는지는 Workflow Step별 로그 확인이 필요하다.
13.2.3 개선 방향
Gate ON 이후 다음 단계의 소요 시간을 개별 측정한다.
- 활성 트랜잭션 종료 대기
- DMS CDC 최종 동기화
- DMS 중지
- V2 데이터 정리
- ALB Listener Rule 전환
- Target Health 확인
- Write Gate OFF
13.3 V2 데이터 정리의 복구 제한
13.3.1 현상
6차 Cutover에서는 V2 취향 프로필, 추천 데이터 및 AI 메시지 내용을 삭제한다.
진행 중인 AI 대화방도 만료 처리한다.
13.3.2 위험
Cutover 실패 후 V1으로 트래픽을 복원하더라도 삭제된 V2 데이터는 자동 복원되지 않는다.
13.3.3 개선 방향
- 데이터 정리 전 백업 확보
- 정리 대상 및 실행 결과 기록
- 재시도 전 V2 데이터 재적재 절차 마련
- 데이터 정리 이후 실패 시나리오 검증
13.4 V1 자동 복구 미검증
13.4.1 현상
6차 Cutover Summary에는 V1 Service Recovery Step이 확인되지 않았다고 명시됐다.
13.4.2 분석
Cutover 성공 여부와 실패 시 자동 복구 경로의 검증 여부는 다르다.
13.4.3 개선 방향
- Gate ON 이후 실패 주입
- ALB V1 복원 확인
- V1 Healthy Target 확인
- Write Gate OFF 확인
- V2 사용자 상태 복원 결과 확인
- Runner 손실 시 수동 복구 테스트
14. 한계 및 미검증 항목
14.1 최종 RPO 0
Preflight에서 Data Reconciliation PASS를 기록했다.
그러나 최종 Cutover 직전 성공한 모든 쓰기가 V2에 반영됐다는 사실까지 확정할 수는 없다.
14.2 Cutover 중 조회 가용성
6차의 k6 HTTP 성공률과 응답시간 결과가 확보되지 않았다.
따라서 Cutover 중 조회 서비스의 연속 가용성을 정량적으로 확정할 수 없다.
14.3 최종 ALB 라우팅
Preflight에서는 V1=100%, V2=0%를 확인했다.
Cutover 이후 최종 Listener Rule 가중치는 별도 확인이 필요하다.
14.4 V1 자동 복구
V1 Service Recovery Step의 실제 성공 여부는 미확정이다.
14.5 V2 데이터 복구
V2 데이터 정리 결과는 자동 복원되지 않는다.
재시도 전 V2 데이터 재적재 또는 초기화가 필요하다.
14.6 DMS 자동 재시작
DMS는 중지 이후 자동 재시작되지 않는다.
따라서 실패 시 수동 복구 절차가 필요하다.
15. 향후 개선 사항
| 개선 항목 | 적용 방향 | 검증 기준 |
|---|---|---|
| Workflow 실행 시간 | Preflight/Cutover/대기 시간 분리 | 단계별 병목 식별 |
| Preflight | 검증 결과 및 기준값 자동 저장 | PASS/FAIL 추적 |
| Write Freeze | Gate ON/OFF 자동 기록 | 지속 시간 측정 |
| MySQL | DMS 통계와 실제 데이터 비교 | 데이터 정합성 |
| PostgreSQL | Dump 이후 쓰기 이력 확인 | RPO 0 |
| ALB | 최종 Listener Rule 가중치 저장 | V1 0% / V2 100% |
| ECS | Cutover 이후 Health 확인 | Healthy 유지 |
| k6 | Summary 및 Remote Write 구성 | HTTP 성공률/p95 확보 |
| V2 데이터 정리 | 백업 및 재적재 절차 마련 | 재시도 가능 |
| V1 복구 | 장애 주입 테스트 | 자동 복구 검증 |
| Write Gate | 비상 해제 테스트 | 쓰기 정상 재개 |
| DMS 복구 | 수동 재시작 Runbook | 복제 재개 확인 |
16. 최종 결론
2026년 10월 19일 수행한 NeedU V1 → V2 6차 Production 마이그레이션에서는 Production Preflight 및 Cutover 자동화가 성공했다.
Preflight는 20개 검증 항목에서 PASS 20건, FAIL 0건을 기록했으며, DNS, ALB, ECS, RDS, DMS 및 대상 데이터베이스 검증이 모두 통과했다.
MySQL은 전체 22개 테이블과 주요 데이터 행 수를 검증했고, DMS Full Load 100% 및 Validation Pending/Failed 없음이 확인됐다.
PostgreSQL은 총 28,259행의 Catalog 데이터와 임베딩 타입 및 인덱스 구성을 검증했다.
6차 자동화 실행 시간은 다음과 같다.
- Preflight: 1분 17초(77초)
- Cutover: 2분 37초(157초)
- Preflight + Cutover 전체: 4분 41초(281초)
- Write Freeze: 1분 33초(93초)
5차와 비교하면 Cutover 단계는 35초, Write Freeze는 36초 단축됐다.
반면 전체 Workflow 실행 시간은 261초에서 281초로 20초 증가했다.
따라서 Cutover 단계와 Write Freeze의 개선은 확인됐지만, 전체 자동화 실행 시간까지 단축된 것은 아니다.
6차 Cutover에서는 실패 또는 취소가 Gate OFF 확인 전에 발생하면 ALB를 V1으로 복원하고 V1 Healthy Target을 확인한 뒤 Gate를 해제하는 복구 정책이 적용됐다.
또한 V2 사용자 상태 복원을 시도하도록 설계됐다.
그러나 V2 데이터 정리 결과는 자동 복원되지 않으며, DMS도 중지 이후 자동으로 재시작하지 않는다.
따라서 Cutover 실패 후 재시도하려면 V2 데이터 재적재 및 DMS 복구 절차가 필요하다.
최종 판정: Preflight 20/20 PASS / Cutover SUCCESS / 전체 Workflow 281초 / Cutover 단계 157초 / Write Freeze 93초 / 5차 대비 Cutover 35초 단축 및 Write Freeze 36초 단축 / 대상 데이터베이스 사전 검증 PASS / 최종 RPO 0 및 HTTP 가용성 추가 증빙 필요
이번 6차 Production 마이그레이션을 통해 V1에서 V2로 전환하는 자동화 절차의 성공과 실제 쓰기 제한 시간의 감소를 확인했다.
또한 전체 Workflow 실행 시간과 Cutover 단계 실행 시간을 분리해 분석하고, 데이터 정리 및 실패 복구 정책의 적용 범위와 한계를 확인했다.