V1 → V2 Staging 마이그레이션 1차 리허설 결과 보고서 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki

개요
마이그레이션 구성
리허설 타임라인
MySQL 마이그레이션 검증
PostgreSQL 마이그레이션 검증
Write Freeze 동작 검증
k6 조회 부하 테스트
V2 ECS 기동 및 직접 Smoke Test
DNS 전환 및 전환 후 검증
V2 쓰기 검증
Write Freeze 지속 시간 및 병목 분석
모니터링 및 관측성 이슈
한계 및 미검증 항목
2차 리허설 개선 계획
최종 결론

1. 개요

1.1 목적

V1에서 V2 Staging 환경으로 서비스를 이전하는 과정에서 데이터 정합성, 서비스 가용성, 조회 성능, 쓰기 차단, 트래픽 전환 및 전환 이후 정상 동작 여부를 검증한다.

주요 검증 목표는 다음과 같다.

MySQL DMS Full Load 및 CDC 기반 데이터 이전 검증
PostgreSQL Dump/Restore 기반 데이터 이전 검증
Write Freeze 이후 V1 조회 서비스의 정상 동작 확인
V2 ECS 기동 및 통합 검증
DNS 전환 이후 V2 서비스 정상 동작 확인
V2 쓰기 요청 및 RDS 데이터 반영 검증
전환 소요 시간 측정 및 병목 분석

1.2 리허설 환경

항목	내용
수행 일자	2026-10-17
대상	V1 → V2 Staging
전환 방식	DNS 전환
V1	EC2 + Nginx + MySQL + PostgreSQL
V2	ALB + ECS(FE/BE/AI) + RDS MySQL/PostgreSQL
MySQL 이전	AWS DMS Full Load + CDC
PostgreSQL 이전	pg_dump / pg_restore
쓰기 차단	V1 Nginx Write Freeze
트래픽 전환	staging.needu.gift DNS 변경
부하 테스트	k6, V1 직접 조회, 10 RPS / 90분
A 담당	Cindy — DMS, MySQL, ECS, ALB, DNS
B 담당	Mond — k6, Write Freeze, PostgreSQL, Smoke Test

1.3 최종 검증 결과

검증 항목	결과	판정
MySQL DMS 이전	7개 테이블 Completed / Validated	PASS
DMS Validation	실패·대기·중단 0건	PASS
PostgreSQL 이전	4개 테이블 행 수 일치	PASS
PostgreSQL 구조	pgvector, PK/FK, HNSW 확인	PASS
V1 조회 부하	54,001/54,001 성공	PASS
V1 조회 p95	17.67ms	PASS
CSRF 발급 차단	HTTP 503 확인	PASS
기타 쓰기 API 차단	Nginx 설정 확인, 실제 요청 검증 없음	미검증
V2 직접 Smoke	61/61 성공	PASS
DNS 전환 후 Smoke	60/60 성공	PASS
V2 쓰기 검증	인증 세션 2건 INSERT	PASS
전환 후 ALB/Target 5xx	0건	PASS
ECS 및 Target Group	Running / Healthy	PASS
Freeze → DNS 전환	약 23분 35초	목표 미달
RPO 0	성공한 원본 쓰기와 대상 데이터의 전수 대조 미수행	미검증

종합 판정: 기능 및 인프라 전환 검증 PASS / 전환 시간 목표 미달 / RPO 0 및 쓰기 차단 완전성 추가 검증 필요

2. 마이그레이션 구성

2.1 V1 환경

단일 EC2 기반 서비스
Nginx HTTP 라우팅
Frontend, Backend, AI Server 실행
MySQL 및 PostgreSQL 직접 설치
Nginx에서 Write Freeze 적용
k6로 V1 직접 조회 API에 지속 부하 발생

2.2 V2 Staging 환경

ALB 기반 트래픽 수신
ECS Frontend / Backend / AI Server
RDS MySQL 및 PostgreSQL
MySQL DMS Full Load + CDC
PostgreSQL Dump/Restore

2.3 데이터 이전 방식

데이터베이스	이전 방식	최종 동기화
MySQL	DMS Full Load + CDC	Freeze 이후 CDC 지연·Validation 확인 후 중지
PostgreSQL	pg_dump / pg_restore	Freeze 이후 최종 Dump 및 V2 Restore

MySQL과 PostgreSQL은 서로 다른 마이그레이션 방식을 적용했다.

MySQL은 CDC를 통해 변경 데이터를 지속적으로 복제했으며, PostgreSQL은 최종 Dump를 생성한 뒤 대상 RDS에 복원했다.

따라서 두 데이터베이스의 이전 소요 시간과 정합성 검증 절차를 구분하여 분석한다.

3. 리허설 타임라인

모든 시각은 KST 기준이다.

시각	단계	작업 및 결과
16:51:10	DMS	Full Load 완료, CDC 진행
16:55	k6	V1 직접 조회 부하 테스트 시작
16:58:25	T0	V1 Nginx Write Freeze 적용
16:59경	트랜잭션	MySQL innodb_trx 0건, PostgreSQL 활성 트랜잭션 0건
17:03:22	PostgreSQL	최종 Dump 완료, 85MB, 아카이브 검사 성공
17:04경	DMS	7개 테이블 Validation 완료, 중지 GO
17:06:00	DMS	StopReplicationTask API 호출
17:06:20	DMS	Stopped 상태 확인
17:06 이후	MySQL	V2 정책 변환 및 COMMIT
17:08 이전	PostgreSQL	V2 Restore 완료
17:13	PostgreSQL	행 수 및 구조 검증 완료
17:13	ECS	FE/BE/AI 기동 시작
17:16	ECS	기동 및 Health Check 완료
17:20	Smoke	V2 직접 Smoke 61/61 성공
17:22경	DNS	staging.needu.gift V2 전환 완료
17:24	Smoke	DNS 전환 후 Smoke 60/60 성공
17:27~17:28	ALB	전환 후 5xx 0건, RequestCount 증가 확인
17:29	T10	V2 쓰기 검증 GO
17:41:06	MySQL	첫 인증 세션 INSERT 확인
17:41:31	MySQL	두 번째 인증 세션 INSERT 확인
17:44	T10	ALB/ECS 최종 정상 상태 확인
17:45	완료	전체 리허설 완료
약 18:25	k6	V1 직접 조회 90분 테스트 종료

3.1 주요 소요 시간

측정 구간	소요 시간
Write Freeze → PostgreSQL Dump 완료	4분 57초
Write Freeze → DMS 중지 요청	7분 35초
DMS 중지 요청 → Stopped 확인	20초
Write Freeze → DMS Stopped 확인	7분 55초
DMS Stopped 확인 → DNS 전환	약 15분 40초
Write Freeze → DNS 전환	약 23분 35초
Write Freeze → V2 첫 쓰기 성공 확인	약 42분 42초

DNS 전환까지의 시간은 실제 사용자 관점의 쓰기 중단 시간과 동일하지 않다. 첫 쓰기 성공 시각 역시 쓰기 허용 시작 시각을 의미하지 않는다.

4. MySQL 마이그레이션 검증

4.1 DMS Full Load 및 CDC

16:51:10 KST에 DMS Full Load가 완료됐으며 이후 CDC 복제를 유지했다.

Write Freeze 이후 CDC 지연과 Validation 상태를 확인한 뒤 DMS 중지를 진행했다.

검증 항목	결과
대상 테이블	7개
Full Load	완료
Table 상태	Completed
Validation	Validated
Validation 실패	0건
Validation 대기·중단	0건
Full Load 오류	0건
미적용 변경	보고된 값 0건
CDC Source Latency	약 0~4초
CDC Target Latency	약 0~4초
CDC 지연 누적 상승	없음

판정: PASS

4.2 DMS 중지 소요 시간

CloudTrail에서 StopReplicationTask 호출 시각을 확인했다.

이벤트	시각
Write Freeze 적용	16:58:25
DMS 중지 요청	17:06:00
DMS Stopped 확인	17:06:20

Freeze → DMS 중지 요청: 7분 35초
DMS 중지 요청 → Stopped 확인: 20초
Freeze → DMS 중지 완료 확인: 7분 55초

DMS 중지 자체보다는 Freeze 이후 수행한 안정화 대기, 최종 데이터 검증 및 승인 절차가 전체 시간을 증가시킨 것으로 분석된다.

4.3 V2 MySQL 정책 변환

DMS 중지 이후 V2 MySQL에서 정책 변환 및 COMMIT을 완료했다.

항목	결과
일반 사용자 53명	ONBOARDING
테스트 사용자 20명	ACTIVE
진행 중 AI 대화방	0건
정책 위반 사용자	0명

판정: PASS

4.4 모니터링 증빙

[Grafana/CloudWatch 캡처 ① — DMS CDC Latency]

조회 구간: 2026-10-17 16:50~17:10 KST
지표: CDCLatencySource, CDCLatencyTarget
CDCLatencySource: V1 MySQL에서 발생한 변경 사항을 DMS가 읽어오는 데 얼마나 지연되는지
CDCLatencyTarget: V1 MySQL의 변경 사항이 V2 RDS에 반영되기까지 얼마나 지연되는지
확인 목적: CDC 지연이 0~4초 수준으로 안정적으로 유지됐는지 확인
DMS 지표가 Grafana에 없다면 CloudWatch 화면 사용

[DMS 콘솔 캡처 ② — Table Statistics / Validation]

7개 테이블 Completed / Validated
Validation 실패·대기·중단 0건
DMS Stopped 상태

5. PostgreSQL 마이그레이션 검증

5.1 Dump 및 Restore

항목	결과
Dump 완료	17:03:22
Dump 파일 크기	약 85MB
pg_restore --list	exit_code=0
V2 Restore	17:08 이전 완료
Restore 결과	exit_code=0
최종 검증	17:13 완료

5.2 데이터 정합성 검증

테이블	V1	V2	결과
catalog_embedding_models	1	1	일치
catalog_product_documents	20,289	20,289	일치
catalog_products	7,969	7,969	일치
catalog_sync_runs	0	0	일치

4개 테이블 모두 V1/V2 행 수가 일치했다.

5.3 DB 구조 검증

다음 항목의 복원 결과를 확인했다.

pgvector 확장
Primary Key
Foreign Key
HNSW 인덱스

판정: PASS

행 수 일치만으로 모든 행의 값이 동일하다고 판단할 수는 없다. 이번 리허설에서는 행 수와 주요 DB 구조의 정상 복원을 확인했다.

6. Write Freeze 동작 검증

6.1 적용 방식

16:58:25 KST에 V1 Nginx에 Write Freeze를 적용했다.

지정된 조회 API만 허용하고 CSRF 발급 및 기타 API 요청은 HTTP 503으로 차단하도록 구성했다.

요청	처리
GET 친구 목록	허용
GET 친구 상세	허용
GET 개인 추천	허용
GET 선물 추천	허용
GET /api/v1/auth/csrf	503
기타 /api/*	503
/ai-test/*	503

6.2 Nginx Access Log 결과

검증 구간: 16:58:25~17:22:00 KST

HTTP 상태	요청 수
200	14,150
307	1
400	2
401	1
503	1
합계	14,155

HTTP 503 로그:

[17/Oct/2026:07:58:31 +0000]
GET /api/v1/auth/csrf HTTP/1.1
503
User-Agent: curl/8.18.0

Write Freeze 적용 6초 후 CSRF 발급 요청이 503을 반환했다.

확인된 Nginx 설정에서도 해당 경로에 대한 명시적인 503 차단 규칙이 존재한다.

6.3 트랜잭션 상태

항목	결과
MySQL innodb_trx	0건
PostgreSQL 활성 트랜잭션	0건
DMS Binlog Dump 연결	유지

이는 점검 시점에 진행 중인 트랜잭션이 없었다는 근거다.

6.4 검증 판정

항목	판정
CSRF 발급 차단	PASS
지정된 조회 API 정상 동작	PASS
기타 쓰기 API 차단	설정 확인, 실제 요청 미검증
DB 전체 쓰기 차단 완전성	미검증

6.5 모니터링 증빙

[Grafana/Loki 캡처 ④ — Nginx HTTP 상태 코드 및 요청량]

조회 구간: 16:55~17:25 KST
지표: HTTP 2xx/4xx/5xx, RPS
기준선: Write Freeze 16:58:25
확인 목적: 조회 요청 유지 및 503 차단 응답 확인

7. k6 조회 부하 테스트

7.1 테스트 구성

항목	설정
도구	Grafana k6
대상	V1 직접 주소
유형	조회 부하
목표 RPS	10
지속 시간	90분
API	친구 목록, 친구 상세, 개인 추천, 선물 추천
부하 유지	Freeze 전후, DMS 중지, DNS 전환 이후

DNS 전환 이후에도 k6는 V1 직접 주소를 대상으로 실행됐다. 따라서 해당 구간의 측정값은 V2 성능이 아니라 V1 성능이다.

7.2 전체 결과

지표	결과
총 요청	54,001건
평균 RPS	약 10
HTTP 200	54,001건
HTTP 실패	0건
JSON 응답 검증 실패	0건
Dropped iterations	0건
평균 응답시간	13.58ms
Median	12.67ms
p90	16.13ms
p95	17.67ms
p99	26.63ms
최대 응답시간	388.60ms

판정: PASS

7.3 구간별 성능 비교

구간	요청 수	평균	p95	p99
Freeze 이전	2,092	14.36ms	18.30ms	42.33ms
Freeze~DMS 중지	4,750	13.56ms	17.94ms	26.70ms
DMS 중지~DNS 전환	9,400	13.39ms	17.55ms	25.51ms
DNS 전환 이후	37,759	13.58ms	17.63ms	26.38ms

7.4 결과 분석

Write Freeze 이전 p95는 18.30ms였으며, Freeze 적용 이후 DMS 중지 전까지는 17.94ms로 측정됐다.

DMS 중지 이후 p95는 17.55ms, DNS 전환 이후 V1 직접 요청의 p95는 17.63ms였다.

전 구간에서 HTTP 오류와 Dropped iterations는 발생하지 않았다.

따라서 이번 10 RPS 조회 부하 조건에서는 Write Freeze와 DMS 중지가 V1 조회 API의 응답 성능에 뚜렷한 악영향을 주지 않은 것으로 판단한다.

다만 본 결과는 해당 부하 수준에서의 관측 결과이며, 쓰기 요청이나 더 높은 부하 조건에서의 동작을 보장하지 않는다.

7.5 Grafana 증빙

[Grafana 캡처 ⑤ — V1 HTTP RPS]

조회 구간: 16:55~18:25 KST
지표: 초당 HTTP 요청 수
확인 목적: 90분간 10 RPS 유지 여부
기준선: Freeze / DMS 중지 / DNS 전환

[Grafana 캡처 ⑥ — V1 HTTP p95/p99]

조회 구간: 16:55~18:25 KST
지표: HTTP 응답시간 p95, p99
확인 목적: 전환 단계별 지연 증가 여부

[Grafana 캡처 ⑦ — V1 HTTP 실패율]

조회 구간: 16:55~18:25 KST
지표: HTTP 실패율 또는 5xx
확인 목적: 조회 부하 중 오류 발생 여부

Grafana 메트릭이 누락됐다면 k6 Summary JSON 및 metrics.jsonl 분석 결과를 측정 근거로 사용한다.

8. V2 ECS 기동 및 직접 Smoke Test

8.1 ECS 기동

PostgreSQL 검증 완료 이후 ECS 기동을 시작했다.

항목	결과
기동 시작	17:13경
Health Check 완료	17:16경
Frontend	정상
Backend	정상
AI Server	정상

8.2 V2 직접 Smoke Test

DNS 전환 이전 v2.needu.gift를 대상으로 Smoke Test를 실행했다.

항목	결과
완료 시각	17:20
Iterations	61
성공	61
실패	0
Dropped	0
HTTP 실패율	0%

판정: PASS

8.3 Grafana 증빙

[Grafana 캡처 ⑧ — ECS Running/Pending Task]

조회 구간: 17:10~17:45 KST
지표: RunningTaskCount, PendingTaskCount
확인 목적: ECS 정상 기동 및 유지 여부

[Grafana 캡처 ⑨ — ALB Target Group Healthy Host]

조회 구간: 17:10~17:45 KST
지표: HealthyHostCount, UnHealthyHostCount
확인 목적: 전환 전 Healthy Target 확보 여부

9. DNS 전환 및 전환 후 검증

9.1 DNS 전환

17:22경 staging.needu.gift의 트래픽 대상을 V2로 전환했다.

V1 Nginx Write Freeze와 V1 직접 k6 조회 부하는 계속 유지했다.

9.2 DNS 전환 후 Smoke Test

항목	결과
대상	staging.needu.gift
완료 시각	17:24
Iterations	60
성공	60
실패	0
Dropped	0
HTTP 실패율	0%

판정: PASS

9.3 V2 ALB RequestCount

시각	RequestCount
17:23	46
17:24	15
합계	61

DNS 전환 이후 V2 ALB RequestCount 증가를 확인했다.

9.4 ALB 오류 분석

시각	ALB 5xx
16:50	1
17:09	2
17:13	2
전환 후 확인 구간	0

전체 확인 구간 Target 5xx: 0건
전환 이전 ALB 5xx: ECS 기동 및 Healthy Target 확보 이전 발생으로 추정
전환 이후 ALB/Target 5xx: 0건

판정: PASS

9.5 Grafana 증빙

[Grafana 캡처 ⑩ — V2 ALB RequestCount]

조회 구간: 17:15~17:45 KST
지표: RequestCount
기준선: DNS 전환 17:22
확인 목적: V2로 실제 트래픽이 유입됐는지 검증

[Grafana 캡처 ⑪ — V2 ALB/Target 5xx]

조회 구간: 16:45~17:45 KST
지표: HTTPCode_ELB_5XX_Count, HTTPCode_Target_5XX_Count
확인 목적: 전환 전 오류와 전환 후 정상 상태 구분

10. V2 쓰기 검증

10.1 검증 방식

T9 전환 검증 완료 후 테스트 계정으로 Kakao 로그인을 수행했다.

로그인 과정에서 생성되는 인증 세션이 V2 RDS MySQL에 정상 반영되는지 확인했다.

10.2 V2 MySQL 결과

세션 ID	사용자 ID	생성 시각(KST)	revoked_at
1	19	17:41:06.876709	NULL
2	20	17:41:31.322718	NULL

검증 내용:

Kakao 로그인 성공
auth_sessions 0건 → 2건
신규 세션 INSERT 확인
users JOIN 정상
사용자 상태 ONBOARDING / ACTIVE 확인
revoked_at 모두 NULL

판정: PASS

10.3 최종 인프라 상태

항목	결과
ALB RequestCount	증가 확인
ALB 5xx	0건
Target 5xx	0건
FE/BE/AI Running	각 2/2
Pending	0
ECS Deployment	COMPLETED / Steady State
FE/BE Target Group	각 2/2 Healthy

T10 판정: PASS

10.4 증빙 이미지

[SQL 캡처 ⑫ — V2 MySQL auth_sessions]

세션 ID 1, 2
user_id 19, 20
created_at
revoked_at

[Grafana 캡처 ⑬ — 로그인 구간 ALB RequestCount 및 5xx]

조회 구간: 17:35~17:45 KST
확인 목적: 로그인 요청 시 ALB 트래픽 증가 및 오류 부재 확인

11. Write Freeze 지속 시간 및 병목 분석

11.1 전환 시간 분석

이벤트	시각
V1 Write Freeze 적용	16:58:25
DMS 중지 요청	17:06:00
DMS Stopped 확인	17:06:20
DNS 전환	약 17:22
V2 첫 쓰기 성공	17:41:06

Write Freeze 적용부터 DNS 전환까지 약 23분 35초가 소요됐다.

V2에 별도의 Write Freeze 해제 절차는 기록되지 않았으며, DNS 전환 이후 첫 쓰기 성공이 확인됐다.

단, DNS 전환 시각과 첫 쓰기 성공 시각만으로 실제 사용자 관점의 쓰기 중단 시간을 정확하게 산정할 수는 없다.

11.2 병목 구간

구간	소요 시간	주요 작업
Freeze → DMS 중지 요청	7분 35초	안정화 대기, PG Dump, CDC·Validation 확인
DMS 중지 요청 → Stopped	20초	DMS 중지
DMS Stopped → DNS 전환	약 15분 40초	PG Restore·검증, ECS 기동, Smoke, 전환

주요 병목은 DMS 중지 명령 자체보다 Write Freeze 이후에 집중된 데이터 이전, 인프라 기동 및 검증 절차였다.

11.3 개선 방향

11.3.1 PostgreSQL 사전 준비

PostgreSQL Dump/Restore를 Freeze 이후에 처음 수행하는 방식에서 사전 복원 및 최종 변경분 반영 방식으로 개선한다.

단, 사전 복원 이후 발생하는 PostgreSQL 변경 데이터를 최종적으로 반영하는 절차가 필요하다.

11.3.2 ECS 사전 기동

V2 ECS FE/BE/AI를 Freeze 이전에 기동하고 Health Check를 완료한다.

11.3.3 DMS 검증 절차 단축

Freeze 이후에는 CDC 지연 해소, Validation 및 쓰기 중단 상태 확인을 중심으로 최소한의 검증을 수행한다.

11.3.4 트래픽 전환 방식 변경

DNS 전환 대신 공통 ALB 기반 Target Group 전환을 적용해 DNS 전파에 따른 불확실성을 줄인다.

11.3.5 Write Gate 계측

다음 시각을 각각 기록한다.

V1 Write Freeze ON
V2 Write Gate OFF
트래픽 전환 완료
V2 첫 쓰기 성공

11.4 목표 비교

지표	1차 결과	2차 목표
Freeze → 트래픽 전환	약 23분 35초	5분 이내
DMS 중지 요청 → 완료 확인	20초	지속 측정
V1 조회 성공률	100%	유지
V2 Smoke 성공률	100%	유지
데이터 정합성	주요 검증 통과	최종 변경분까지 검증
쓰기 차단 완전성	일부 검증	대표 쓰기 API별 확인

12. 모니터링 및 관측성 이슈

12.1 Prometheus Remote Write 오류

DNS 전환 후 k6 Smoke Test 종료 시 Prometheus Remote Write HTTP 400 오류가 발생했다.

하지만 Smoke Test 결과는 다음과 같았다.

60/60 성공
HTTP 실패율 0%
Dropped iterations 0건

따라서 서비스 API 오류가 아닌 메트릭 전송 경로의 오류로 분리해 기록한다.

12.2 개선 사항

k6 Remote Write 수신 설정 확인
Prometheus 수신 엔드포인트 및 프로토콜 점검
k6 메트릭 로컬 백업 유지
Grafana와 k6 Summary 결과 비교
Grafana에 Freeze / DMS 중지 / DNS 전환 시각 표시

13. 한계 및 미검증 항목

13.1 RPO 0 미확정

DMS Validation과 PostgreSQL 행 수 일치는 확인했지만, V1에서 성공 응답을 받은 모든 쓰기 요청이 V2에 존재하는지 전수 대조하지 않았다.

따라서 RPO 0을 확정할 수 없다.

13.2 쓰기 차단 완전성

Nginx 설정 및 CSRF 503 응답은 확인했으나, 대표 POST/PUT/PATCH/DELETE 요청에 대한 실제 차단 테스트는 수행 여부가 확인되지 않았다.

GET 방식의 상태 변경 API, 내부 서비스의 직접 DB 쓰기, 비동기 작업 등도 별도 검증이 필요하다.

13.3 실제 쓰기 중단 시간

DNS 전환 시각과 V2 첫 쓰기 성공 시각은 확인됐지만, V2의 정확한 쓰기 허용 시작 시각은 계측되지 않았다.

따라서 실제 사용자 관점의 쓰기 중단 시간은 미확정이다.

13.4 롤백 제한

V2에서 신규 인증 세션 INSERT가 발생했으므로, 단순 DNS 롤백은 데이터 유실 또는 불일치를 초래할 수 있다.

롤백을 위해서는 V2 신규 데이터의 재동기화 및 충돌 처리 계획이 필요하다.

14. 2차 리허설 개선 계획

개선 항목	적용 방향	검증 기준
PostgreSQL	사전 준비 및 최종 변경분 반영	최종 데이터 정합성
ECS	Freeze 이전 기동	Healthy Target 확보
MySQL DMS	CDC 지연·Validation 확인 후 중지	미적용 변경 0건
트래픽 전환	공통 ALB 기반 전환	V2 유입 및 오류 없음
Write Freeze	V1/V2 Write Gate 구분	차단·재개 시각 기록
조회 부하	k6 지속 실행	성공률 및 p95 유지
쓰기 검증	대표 API 차단·재개 테스트	상태 코드 및 DB 반영
모니터링	Grafana/Loki/CloudWatch 검증	이벤트별 지표 확보
롤백	V2 쓰기 전후 정책 분리	데이터 불일치 방지

15. 최종 결론

2026년 10월 17일 V1 → V2 Staging 마이그레이션 1차 리허설에서 MySQL DMS 이전, PostgreSQL Dump/Restore, V1 조회 부하 유지, V2 ECS 기동, DNS 전환, 전환 후 Smoke Test 및 V2 쓰기 검증을 완료했다.

k6 90분 부하 테스트에서는 총 54,001건의 요청이 모두 성공했으며, 전체 p95는 17.67ms로 측정됐다. Write Freeze와 DMS 중지 전후에도 V1 조회 API의 뚜렷한 성능 저하는 관찰되지 않았다.

MySQL DMS는 7개 테이블의 Validation을 완료했고, PostgreSQL은 4개 테이블의 행 수 및 주요 DB 구조 복원을 확인했다.

DNS 전환 이후 V2 Smoke Test 60/60 성공, 인증 세션 2건 INSERT, ALB/Target 5xx 0건 및 ECS 정상 상태를 확인했다.

다만 Write Freeze 적용부터 DNS 전환까지 약 23분 35초가 소요돼 목표인 5분 이내 전환에는 도달하지 못했다.

최종 판정: 기능·인프라 검증 PASS / 전환 시간 목표 미달 / RPO 0 및 쓰기 차단 완전성 추가 검증 필요

2차 리허설에서는 PostgreSQL 사전 준비, ECS 사전 기동, 공통 ALB 기반 트래픽 전환을 적용해 전환 시간을 단축하고, 쓰기 차단·재개 및 데이터 무손실 검증을 강화한다.

V1 → V2 Staging 마이그레이션 1차 리허설 결과 보고서 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki

목차

1. 개요

1.1 목적

1.2 리허설 환경

1.3 최종 검증 결과

2. 마이그레이션 구성

2.1 V1 환경

2.2 V2 Staging 환경

2.3 데이터 이전 방식

3. 리허설 타임라인

3.1 주요 소요 시간

4. MySQL 마이그레이션 검증

4.1 DMS Full Load 및 CDC

4.2 DMS 중지 소요 시간

4.3 V2 MySQL 정책 변환

4.4 모니터링 증빙

5. PostgreSQL 마이그레이션 검증

5.1 Dump 및 Restore

5.2 데이터 정합성 검증

5.3 DB 구조 검증

6. Write Freeze 동작 검증

6.1 적용 방식

6.2 Nginx Access Log 결과

6.3 트랜잭션 상태

6.4 검증 판정

6.5 모니터링 증빙

7. k6 조회 부하 테스트

7.1 테스트 구성

7.2 전체 결과

7.3 구간별 성능 비교

7.4 결과 분석

7.5 Grafana 증빙

8. V2 ECS 기동 및 직접 Smoke Test

8.1 ECS 기동

8.2 V2 직접 Smoke Test

8.3 Grafana 증빙

9. DNS 전환 및 전환 후 검증

9.1 DNS 전환

9.2 DNS 전환 후 Smoke Test

9.3 V2 ALB RequestCount

9.4 ALB 오류 분석

9.5 Grafana 증빙

10. V2 쓰기 검증

10.1 검증 방식

10.2 V2 MySQL 결과

10.3 최종 인프라 상태

10.4 증빙 이미지

11. Write Freeze 지속 시간 및 병목 분석

11.1 전환 시간 분석

11.2 병목 구간

11.3 개선 방향

11.3.1 PostgreSQL 사전 준비

11.3.2 ECS 사전 기동

11.3.3 DMS 검증 절차 단축

11.3.4 트래픽 전환 방식 변경

11.3.5 Write Gate 계측

11.4 목표 비교

12. 모니터링 및 관측성 이슈

12.1 Prometheus Remote Write 오류

12.2 개선 사항

13. 한계 및 미검증 항목

13.1 RPO 0 미확정

13.2 쓰기 차단 완전성

13.3 실제 쓰기 중단 시간

13.4 롤백 제한

14. 2차 리허설 개선 계획

15. 최종 결론