Migration 운영 성능 진단

3줄 요약

  • DB Migration은 스키마를 바꾸는 작업이 아니라 운영 데이터를 가진 시스템을 멈추지 않고 진화시키는 절차다.
  • 성능 진단은 느린 쿼리 하나만 보는 것이 아니라 연결, 락, I/O, 통계, 실행 계획, 배포 시점, 데이터 증가 추세를 함께 보는 일이다.
  • 기업 운영 수준에서는 변경 전 영향 분석, 무중단 배포 순서, backfill, 롤백, 백업, 모니터링, 인프라 협업이 모두 필요하다.

핵심 정리

  • 마이그레이션 파일은 애플리케이션 코드처럼 버전 관리되어야 한다. 누가, 언제, 어떤 스키마 변경을 했는지 추적 가능해야 한다.
  • 무중단 스키마 변경은 보통 expand and contract 방식으로 접근한다. 새 컬럼 추가, 양쪽 쓰기, backfill, 읽기 전환, 옛 컬럼 제거 순서를 나눈다.
  • 대량 backfill은 작은 배치, sleep, 재시작 가능성, 진행률 기록, 락 범위 제한, 장애 시 중단 기준이 필요하다.
  • 인덱스 생성, 컬럼 타입 변경, NOT NULL 추가, 대형 테이블 ALTER는 DB별 락과 온라인 DDL 지원 범위를 확인해야 한다.
  • 성능 진단은 slow query log, pg_stat_activity, pg_stat_statements, MySQL Performance Schema, 애플리케이션 APM, 커넥션 풀 메트릭을 연결해서 본다.
  • 백업과 복구는 “백업이 있다”가 아니라 “복구 리허설을 해봤다”까지 가야 한다. PITR은 장애 시점 직전으로 되돌리는 중요한 운영 수단이다.
  • 운영 migration은 실행 SQL만이 아니라 runbook이다. 실행 시간대, 담당자, 중단 조건, lock timeout, replica lag 기준, 롤백 또는 forward fix, 검증 쿼리를 함께 정한다.
  • 개인 프로젝트도 Flyway나 Liquibase로 스키마 이력을 남기고, staging 데이터로 migration 시간을 측정하면 기업 운영 감각에 가까워진다.
  • 성능 진단은 배포 전후 비교가 중요하다. “느리다”가 아니라 어느 배포 뒤에 어떤 SQL fingerprint, lock wait, I/O, pool pending이 변했는지 찾아야 한다.

헷갈리는 지점

  • 컬럼 하나 추가는 안전하다고 생각하기 쉽다. 개발 DB에서는 즉시 끝나기 때문이다.
    • 핵심은 운영 대형 테이블에서는 DDL이 락, 테이블 rewrite, 복제 지연을 만들 수 있다는 점이다.
    • DB 버전과 엔진별 온라인 DDL 동작을 확인해야 한다.
  • Migration rollback은 down 스크립트만 있으면 된다고 오해하기 쉽다. 스키마만 되돌리면 된다고 생각하기 때문이다.
    • 핵심은 데이터 변환은 되돌리기 어렵거나 불가능할 수 있다는 점이다.
    • 롤백보다 forward fix, 백업 복구, 호환 배포를 우선 설계한다.
  • Flyway/Liquibase를 쓰면 migration이 자동으로 안전해진다고 오해하기 쉽다. 도구가 적용 순서를 관리해주기 때문이다.
    • 핵심은 도구가 위험한 DDL의 lock, rewrite, replica lag를 없애주지는 않는다는 점이다.
    • 도구는 이력 관리 수단이고, 운영 안전성은 migration 설계와 검증으로 만든다.
  • 성능 진단은 DBA나 인프라의 일이라고 생각하기 쉽다. DB 서버 지표가 애플리케이션 밖에 있기 때문이다.
    • 핵심은 백엔드 배포와 쿼리 패턴이 DB 지표를 바꾼다는 점이다.
    • 개발자는 어떤 코드 변경이 어떤 SQL과 지표로 나타나는지 설명해야 한다.

확인 질문

  • 무중단 마이그레이션에서 expand and contract가 필요한 이유는 무엇인가?
    • 이전 버전과 새 버전의 애플리케이션이 동시에 떠 있어도 스키마 호환성을 유지하며 점진적으로 전환하기 위해서다.
  • Backfill 작업에서 반드시 고려해야 할 것은 무엇인가?
    • 배치 크기, 진행률 저장, 재시작 가능성, 락과 I/O 부하, 복제 지연, 중단 조건, 검증 쿼리다.
  • 백업 전략이 충분한지 확인하는 방법은 무엇인가?
    • 백업 존재 여부가 아니라 실제 복구 시간, 데이터 손실 범위, 복구 리허설 결과로 확인해야 한다.
  • 운영 migration runbook에 들어가야 할 것은 무엇인가?
    • 실행 순서, 예상 시간, lock과 replica lag 기준, 중단 조건, 담당자, 검증 쿼리, 장애 시 forward fix 또는 복구 계획이다.