마이그레이션 플레이 북
1) 이주 분류
DB 체계: 열 추가/변경, 색인, 샤딩, 키 유형 변경.
데이터: 대량 백필/정리, 정규화, 유지/보관.
서비스 및 API: 엔드 포인트 변경, 버전 설정, 계약 리팩토링.
대기열/버스: 주제 이동, 회원 키 변경, 이벤트 형식.
인프라: 새로운 클러스터/K8/클라우드/지역으로 이동하여 비밀/KMS를 변경합니다.
저장 및 분석: 엔진 변경 (OLTP/OLAP), 데이터 세트의 형식/분할.
보안/규정 준수: 키 회전, 즉시 암호화, 데이터의 지리적 현지화.
2) 성공적인 이주 원칙
1. → Migrate → 계약을 확장하십시오. 먼저 체계/동작 (호환) 을 확장 한 다음 데이터/트래픽을 전송 한 다음 이전 버전을 제거합니다.
2. 그림자 및 이중. 검증을위한 그림자 읽기/쓰기 및 이중 항목.
3. 깃발과 "빨간색 버튼 '이 특징입니다. "빠른 종료, 단계별 활성화 (백분위 수/테넌트/지역).
4. 이념과 반복성. 부작용없이 스크립트와 작업을 다시 시작할 수 있습니다.
5. 변경 전 관찰 가능성. 미리 대시 보드/알림, 로그/트랙의 마이그레이션 마커.
6. 롤백 문서화. 롤백 런북은 계획대로 자세히 설명되어 있습니다.
7. 미니 게임 및 일시 중지. 우리는 SLI와 비즈니스 불변량을 확인하면서 작은 부분으로 마이그레이션합니다.
3) 재고 및 의존성 분석
소비자지도: 서비스, 작업, 보고서, 외부 파트너, BI/ETL, 웹 후크.
계약 및 스키마: API/이벤트 버전, 이전/전방 호환성.
액세스/비밀: 캐시/큐가있는 곳을 읽거나 쓰는 사람.
도메인 불변: 독창성, 균형, dempotency, 보고 일.
볼륨/속도: 데이터 크기, RPS, 피크 창, RPO/RTO.
4) 정식 플레이 북 템플릿 (YAML 골격)
yaml playbook: "migrate-orders-to-v2"
owner: "orders-team"
stakeholders: ["platform", "data", "security", "support"]
change_type: ["schema", "data", "api"]
risk_level: "high"
preconditions:
- "Dashboards ready: latency/error/lag"
- "Runbook rollback validated on stage"
- "Backups verified (restore tested)"
plan:
phase_1_prepare:
steps:
- "Add new nullable columns (expand)"
- "Deploy code with dual-write (flag off)"
- "Enable CDC stream to target"
phase_2_shadow:
steps:
- "Shadow-read v2, compare with v1 (1%)"
- "Fix discrepancies; iterate"
phase_3_dual_write:
steps:
- "Enable dual-write (10%→50%→100%)"
- "Start backfill in batches (size=10k, sleep=200ms)"
phase_4_cutover:
steps:
- "Switch reads to v2 by tenants (canary)"
- "Monitor SLI 30m; expand scope"
phase_5_contract:
steps:
- "Drop old indices/columns after T+14d"
- "Disable old topic/api; update docs/SDK"
guardrails:
abort_if:
- "error_rate > 0. 5% for 5m"
- "p95 > baseline1. 5 for 10m"
- "data_mismatch > 0. 01%"
rollback:
steps:
- "Flip flag: reads back to v1"
- "Stop backfill; continue dual-write to v1"
- "Replay missed events (DLQ→v1)"
validation:
checks:
- "Row counts match within epsilon"
- "Business invariants hold (balances, limits)"
comms:
- channel: "on-call-bridge"
- status_updates: "T-24h, T-1h, start, cutover, finish"
window: "low-traffic Sun 02:00–05:00 UTC"5) 마이그레이션 패턴
5. 1 DB 스키마 (RDBMS/NoSQL)
추가-변경하지 마십시오. 새로운 널링 열/인덱스 → 코드는 오래되고 새로운 것을 읽습니다.
온라인 재건. 온라인 색인/동시 DDL을 사용하십시오.
직렬화 버전. JSON/Proto/Avro 열의 페이로드 버전.
주요 마이그레이션 PK-서신의 시간표 + 트리거/CDC를 변경할 때.
5. 2 데이터 (백필/정리)
CDC + 백필. 먼저, 변화의 흐름이 (유지하기 위해) 배치 백필입니다.
당사자 및 마감일. 지연 제어, 체크 포인트 및 재시작이있는 작은 배치.
Idempotent 업데이트. 자연스러운 키/버전에 의해 강화됩니다.
5. 3 개의 이벤트 및 대기열
이벤트 검증. '이벤트 _ 유형 @ vN', 소비자는 익숙하지 않은 필드를 무시합니다.
움직이는 주제. 이중 게시물, 소비자는 안정화하기 전에 둘 다를 읽습니다. 그런 다음 오래된 것을 "절단" 합니다.
파티션 키. 주요 마이그레이션-통신 및 demempotency 맵으로 재발행을 통해.
5. 4 개의 서비스 및 API
파란색/녹색/카나리아. 수영장 예열, 부분 트래픽, 빠른 롤백.
피카 깃발. 세입자/지역/백분율에 따라 포함이 관찰되었습니다.
계약. CDC 계약 및 호환성 테스트-전환 전.
5. 5 개 지역/클래드
지오 더블 레코딩. 데이터는 두 영역에서 기록됩니다. 근접성으로 읽습니다.
국가 이전. 스냅 샷 + 복제; RPO "빨간 선", DNA/Anycast 환적.
관할권. 데이터의 동의/현지화, 키트 제거를위한 "금지 된" 목록.
6) 실행 단계 (자세한 내용)
1. 준비
대시 보드, 경고, 한계, 기능 플래그, 복구 테스트를 통한 백업, 무대에서 실행됩니다.
2. 그림자 (그림자 확인)
사용자에게 영향을 미치지 않으면 서 새로운 시스템에 미러 요청/쓰기. 응답/상태를 비교하십시오
3. 이중 쓰기/이중 읽기
우리는 양방향으로 씁니다. 읽기-점차 새로운 시스템으로 전송됩니다. 부적합 로그가 분석됩니다.
4. 백필
우리는 과거 데이터를 일괄 적으로로드합니다. CDC 지연을 제어하고 스토리/캐시의 부하를 모니터링합니다.
5. 컷 오버 (전환)
세그먼트 별 카나림 (세입자/지역/백분율). 빠른 롤백을 지원합니다.
6. 계약 (청소)
"보안 기간" 이후 오래된 경로를 잘라 내고 오래된 필드/인덱스/주제를 삭제하십시오.
7. 검증 및 복고풍
보고, 메트릭, 레슨, 업데이트 플레이 북/체크리스트.
7) 마이그레이션 중 관찰 및 SLO
기술 SLI: p50/p95/p99, 오류율, 재 시도/시간 초과, 활용, 지연 CDC, 대기열 깊이.
비즈니스 SLI: 거래/전환의 성공, 불변 (잔액, 한계, 중복).
특수 레이블: '마이그레이션 _ id', '위상', '테넌트', '플래그 _ state'.
경보 장치: 꼬리 및 오류에 대한 임계 값, SLO에 대한 "자동 정지" (중단).
비교 패널: v1 vs v2, 주요 지표 별 델타.
8) 롤백 및 비상 시나리오
논리적 롤백: 플래그/트래픽 라우팅, 백필 동결.
데이터: "보상" (Saga), 이벤트 재생, DLQ → 소스 시스템.
비밀/키: 이전 키/인증서 (이중 키) 로 돌아갑니다.
DNA/트래픽: "역 드리프트" Anycast/ALB, 마이그레이션 창에서 TTL 부족.
커뮤니케이션: 사전 합의 된 채널 및 상태 형식.
9) 보안, 개인 정보 보호, 규정 준수
데이터 최소화. 우리는 필요한 필드 만 옮깁니다. 사본의 익명화 프로파일.
암호화. KMS 회전 "와이어" 및 "휴식 중" 암호화; 키 작업 로그.
시간 접근. 마이그레이션 작업을위한 임시 역할, 완료 후 권리 선택.
발자국. 로그/트레이스의 PD 마스킹, 내보내기 제한.
10) 관리 및 커뮤니케이션 변경
RACI: 누가 수행하는지, 누가 정보를 받는지 주장합니다.
동결 기간: 마이그레이션 창에서 관련없는 릴리스를 금지합니
상태: T-24h, T-1h, 시작, 카나리아, 컷 오버, 마무리, 바다 후.
외부 파트너: 호환성 창, 계약 문자, 테스트 샌드 박스.
11) 런북 템플릿
11. 백필 1 개 (의사 코드)
for batch in paginate(ids, size=10_000):
try:
rows = read_v1(batch)
upsert_v2 (rows) # idempotently mark_checkpoint (batch. end)
sleep(jitter_ms(100..300))
except Throttle:
sleep (5s) # backpressure respect except Fatal as e:
alert("backfill-failed", e, context=batch)
abort_if_needed()11. 2 프로 베르 카 하노 스티 (스냅 샷/샘플)
sample = random_ids(n=10_000, stratify=tenant,timestamp)
v1 = fetch_v1(sample); v2 = fetch_v2(sample)
assert schema_compatible(v2)
assert key_invariants_hold (v1, v2) # sum, statuses, versions mismatch_rate = diff (v1, v2). rate()
abort_if(mismatch_rate > 0. 0001)11. 3 전환 판독 값
flag. enable("read_from_v2", segment="tenants: cohort_A")
monitor(30m)
if SLO_ok(): expand_segment()
else: rollback_segment()12) 반 패턴
확장 마이그레이션 계약 대신 "빅뱅".
CDC가없는 백필 → 영원한 캐치 업 및 드리프트.
demempotency → 중복/더러운 데이터가 없습니다.
스크립트가없는 수동 단계 → 인적 오류.
대시 보드/가드가없는 마이그레이션 → "맹인 비행".
인정되지 않은 롤백 → 롤백은 필요할 때 작동하지 않습니다.
소비자 무시 (BI/파트너) → 보고서/통합 중단
13) 건축가 점검표
1. 목표, 경계, 마이그레이션 유형 및 결과 불변량이 정의 되었습니까
2. 소비자 및 계약 맵 작성, 호환성 테스트 녹색?
3. 준비된 대시 보드, 경고, 태그 'migration _ id', SLO/guardrails 세트?
4. 그림자 및/또는 이중 쓰기, 백필 demempotent?
5. 연습 된 롤백 런북이 있습니까? 백업에서 복구를 확인하십니까?
6. 창/조정/통신 동의, 동결?
7. 카나리아 및 확장/정지 기준이 준비된 단계별 계획?
8. 보안/준수: 키, 액세스, PII 위생?
9. 문서/SDK/사양이 동일한 릴리스주기에서 업데이트됩니까?
10. 완료 후 바다 및 플레이 북 업데이트?
결론
마이그레이션 플레이 북은 작은 가역적 단계, 투명한 지표, 준비된 롤백 및 "확장 마이그레이션 계약" 분야와 같은 위험 관리의 아키텍처 관행입니다. 설명 된 템플릿에 따라 비즈니스 불변량과 사용자 신뢰를 유지하면서 다운 타임 및 놀라움없이 체계, 데이터, 서비스 및 지역을 마이그레이션합니다.