DB 메이저 버전 업그레이드는 보통 “주말 점검 작업”으로 취급되지만, 실제 실패 원인은 점검 시간이 짧아서가 아닙니다. 호환성 가정이 문서에만 있고 런타임 검증이 약한 상태로 전환하기 때문입니다. 업그레이드 직후 기능은 정상처럼 보여도, 24~72시간 내 쿼리 플랜 회귀·복제 지연·락 대기 증가가 순차적으로 터지는 패턴이 반복됩니다.

그래서 실무에서는 업그레이드를 “버전 교체”가 아니라 검증 가능한 트래픽 이전 프로젝트로 다뤄야 합니다. 이 글은 PostgreSQL/MySQL 모두에 적용 가능한 공통 플레이북을 기준으로, 무중단 업그레이드의 현실적인 의사결정 기준을 정리합니다.

이 글에서 얻는 것

  • DB 메이저 업그레이드의 핵심 리스크(호환성, 성능 회귀, 복구 실패)를 전환 단계별 기준으로 나눠 관리할 수 있습니다.
  • 단순 사전 테스트가 아니라, 실제 트래픽 기반으로 “승격/중단/롤백”을 판단하는 수치 임계치를 설정할 수 있습니다.
  • 업그레이드 이후 1주일 동안 반드시 추적해야 할 지표와 운영 런북 항목을 바로 적용할 수 있습니다.

핵심 개념/이슈

1) 업그레이드 실패의 본질은 버그보다 “가정 불일치”다

대부분의 장애는 엔진 자체 버그보다, 팀이 암묵적으로 갖고 있던 가정이 깨지면서 발생합니다.

  • 옵티마이저 통계 해석 변화로 실행 계획이 바뀜
  • 기본 파라미터 값 변화(메모리, 병렬도, autovacuum/flush 정책)
  • 드라이버·ORM과의 호환성 경계(타입 매핑, 시간대, 트랜잭션 동작)
  • 확장(Extension/Plugin) 버전 불일치

즉 “애플리케이션 테스트 통과”만으로는 부족합니다. 업그레이드 전에는 쿼리 플랜 회귀 가드레일을 같이 준비해야 하고, 스키마 변경이 얽혀 있다면 Online DDL Expand-Contract 원칙으로 분리해야 합니다.

2) 무중단의 핵심은 in-place가 아니라 “병렬 검증 경로”다

운영에서 가장 안전한 방식은 기존/신규 DB를 일정 기간 병렬 운영하고, 읽기 또는 일부 쓰기를 점진적으로 전환하는 모델입니다. 구현 방식은 환경마다 다르지만 원칙은 같습니다.

  1. 신규 버전을 별도 클러스터로 준비
  2. 초기 데이터 동기화(backfill) 수행
  3. 변경분을 복제/CDC로 연속 동기화
  4. 읽기 트래픽부터 카나리 전환
  5. 쓰기 전환 후 짧은 안정화 구간 운영

이 패턴은 DB 복제와 Read/Write 분리와 트래픽 컷오버 전략의 조합으로 이해하면 설계가 쉬워집니다.

3) 승격 기준은 “성능 + 정합성 + 복구 가능성” 3축으로 고정한다

업그레이드 당일에 가장 흔한 실수는 성능 지표만 보고 승격하는 것입니다. 실제론 정합성과 복구 가능성을 같이 봐야 합니다.

권장 게이트(10분 이동 창 기준):

  • 성능: latency_p95 증가율 20% 이하, error_rate +0.2%p 이하
  • 정합성: 샘플 검증 1만 건 기준 불일치율 0.01% 이하
  • 복구 가능성: 롤백 리허설 예상 RTO 15분 이내, 자동 전환 스크립트 성공률 100%

3축 중 하나라도 실패하면 “관찰 연장” 또는 “즉시 롤백”이 원칙입니다. 조건을 문장으로만 두지 말고 파이프라인/런북에서 강제해야 합니다.

4) 쿼리 회귀는 평균이 아니라 상위 퍼센타일과 플랜 변화로 본다

메이저 업그레이드에서 가장 늦게 드러나는 문제는 상위 1~5% 느린 쿼리입니다. 평균 TPS가 유지돼도 P99가 악화되면 배치/피크 시간대에 먼저 터집니다.

실무 점검 기준 예시:

  • 상위 50개 핵심 쿼리의 P95/P99 비교
  • 신규 플랜에서 Full Scan/Hash Join 급증 여부
  • DB wait event 분포 변화(lock, io, cpu)
  • Autovacuum/Checkpoint 빈도 변화

핵심은 “느린 쿼리 리스트”가 아니라 플랜 변화 원인을 남기는 것입니다. 그래야 튜닝 우선순위(인덱스 보완 vs 통계 갱신 vs 파라미터 조정)를 빠르게 정할 수 있습니다.

실무 적용

1) 4단계 실행 순서(현실적인 기본 템플릿)

1단계 — 사전 고정(1~2주)

  • 드라이버/ORM/확장 호환성 매트릭스 작성
  • 금지 작업 지정: 업그레이드 주간 대규모 DDL 금지
  • 백업 + 복구 리허설 완료(백업/DR 전략)

2단계 — 병렬 검증(3~7일)

  • 트래픽 샘플 리플레이 또는 미러링
  • 핵심 쿼리 50~100개 회귀 자동 점검
  • 정합성 샘플링(주문/정산/권한 등 고위험 도메인 우선)

3단계 — 점진 전환(당일)

  • 읽기 5% → 20% → 50% → 100%
  • 쓰기 전환은 마지막 1회만, 전환 전 30분 동안 에러율/지연 안정 확인
  • 단계마다 최소 10~15분 관찰 창 확보

4단계 — 사후 안정화(전환 후 7일)

  • 매일 동일 시각에 플랜 회귀 재점검
  • 배치/정산/리포트 쿼리 별도 관측
  • 장애 런북 보정 및 임계치 업데이트

2) 의사결정 기준(숫자·조건·우선순위)

우선순위는 데이터 신뢰도 > 복구 가능성 > 평균 성능으로 둡니다.

즉시 중단/롤백 조건:

  • 정합성 불일치율 0.05% 초과(핵심 엔터티 기준)
  • 복제 지연 P95 5초 초과 10분 지속
  • 쓰기 에러율 +0.5%p 이상 또는 데드락 2배 증가
  • 온콜 1명 기준 수동 복구 예상 20분 초과

승격 지속 조건:

  • P95 증가율 20% 이하, P99 증가율 30% 이하
  • 고위험 쿼리(상위 20개) 중 회귀 없음
  • 롤백 절차 dry-run 성공 + 담당자 이중 확인 완료

3) 팀 운영에서 자주 놓치는 항목

  • “DBA만 아는 파라미터 변경”을 남기지 말고 앱팀과 공유
  • 배치/리포트는 API 지표와 분리해 따로 본다
  • 전환 당일 신규 기능 배포를 묶지 않는다(변수 분리)
  • 장애 커뮤니케이션 문안을 미리 준비한다(배포 런북)

트레이드오프/주의점

  1. 무중단 업그레이드는 인프라 비용이 늘어난다
    병렬 클러스터, 리플레이 환경, 검증 파이프라인이 필요해 단기 비용은 증가합니다.

  2. 검증 범위를 넓힐수록 일정이 길어진다
    하지만 이 시간을 줄이면 장애 후 복구 비용이 더 크게 돌아옵니다.

  3. 완전 자동 전환은 아직 위험할 수 있다
    자동화는 필요하지만, 최종 쓰기 전환 순간은 사람 승인과 이중 확인이 안전합니다.

  4. 성능 최적화와 업그레이드 작업을 동시에 하면 원인 분리가 깨진다
    업그레이드 기간에는 구조적 튜닝보다 회귀 방지에 집중해야 합니다.

체크리스트 또는 연습

체크리스트

  • 호환성 매트릭스(드라이버/ORM/확장/운영도구)가 최신 상태다.
  • 상위 핵심 쿼리의 플랜 회귀 점검 자동화가 있다.
  • 승격/중단/롤백 기준이 수치로 문서화되어 있고 런북에서 강제된다.
  • 정합성 샘플링 항목(핵심 엔터티)이 사전에 정의돼 있다.
  • 롤백 리허설이 최근 30일 내 최소 1회 성공했다.

연습 과제

  1. 현재 서비스 기준으로 “업그레이드 당일 중단 조건 5개”를 숫자로 정의해보세요.
  2. 상위 20개 쿼리에 대해 업그레이드 전/후 P95/P99 + plan hash 비교표를 만들어보세요.
  3. 전환 후 7일 관측 항목을 API/배치/정산으로 나눠 대시보드 구성을 설계해보세요.

관련 글