동블

그래프 뷰

04. Rollback Restore 의사결정 Runbook 상세

9 min read

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

  • Rollback, Restore, Forward Fix는 어떤 상황에서 선택해야 하는가?
  • 데이터 변경이 있는 장애에서 바로 Rollback하면 왜 위험한가?
  • 복구 의사결정 전에 반드시 확인할 정보는 무엇인가?

목적

이 Runbook은 장애 중 Rollback, Restore, Forward Fix, 기능 차단 중 어떤 복구 방식을 선택할지 정하는 절차다.

Rollback은 애플리케이션 버전이나 설정을 이전 상태로 되돌리는 것이다.

Restore는 데이터를 백업이나 특정 시점으로 되돌리는 것이다.

Forward Fix는 현재 상태에서 보정 코드, SQL, 설정으로 문제를 앞으로 고치는 것이다.

세 가지는 영향 범위와 위험이 다르므로 같은 “복구”로 묶어 실행하면 안 된다.

첫 질문

복구 방식을 고르기 전에 다음 질문에 답한다.

  1. 사용자 영향은 무엇인가?
  2. 데이터 변경이 이미 발생했는가?
  3. schema migration이 실행되었는가?
  4. 사고 이후 정상 쓰기가 있었는가?
  5. 백업 기준 시각과 RPO/RTO는 무엇인가?
  6. 외부 결제, 알림, 포인트 같은 부작용이 있었는가?
  7. 기능 차단이나 read-only 전환으로 시간을 벌 수 있는가?

이 질문에 답하지 못하면 운영 DB에 되돌림 명령을 실행하지 않는다.

선택 기준

문제 유형                         우선 검토
코드만 문제, 데이터 변경 없음       Rollback
설정 오타, 즉시 되돌림 가능         설정 Rollback
schema 변경 후 이전 버전 불호환      Forward Fix 또는 기능 차단
대량 잘못된 update                 Restore 비교 후 Forward Fix
전체 DB 손상                       Restore
일부 사용자 데이터 오류             Forward Fix 또는 replay
외부 부작용 동반                   DB 복구 전에 외부 상태 확인

이 표는 출발점이다.

최종 결정은 영향 범위, 정상 쓰기 보존 필요성, 복구 시간, 검증 가능성으로 정한다.

Rollback 절차

Rollback이 안전한 조건:

  • 새 코드나 설정만 문제다.
  • 데이터 구조나 데이터 값 변경이 없다.
  • 이전 버전 artifact가 남아 있다.
  • 이전 버전이 현재 DB schema와 호환된다.
  • Rollback 후 검증할 API가 정해져 있다.

확인할 것:

git log --oneline -5
kubectl rollout history deploy/order-api
kubectl rollout status deploy/order-api

VM 기반이면 이전 jar, systemd 환경 변수, 배포 시각을 확인한다.

Rollback 후에는 핵심 API와 사용자 영향 지표를 관찰한다.

Restore 절차

Restore는 데이터 상태를 되돌리는 작업이므로 가장 조심해야 한다.

Restore 전 확인할 것:

  • 마지막 정상 시각
  • 백업 기준 시각
  • 사고 이후 정상 쓰기 범위
  • 복원 대상: 전체 DB, 특정 table, 특정 object
  • 복원 위치: 운영 DB인지 별도 DB인지
  • 복원 검증 SQL과 애플리케이션 검증 방법

원칙은 운영 DB에 바로 덮어쓰지 않는 것이다.

먼저 별도 DB나 별도 prefix에 복원해 손실 범위를 비교한다.

Forward Fix 절차

Forward Fix가 적합한 경우:

  • 잘못된 변경 범위가 좁다.
  • 어떤 row가 잘못됐는지 명확하다.
  • 사고 이후 정상 쓰기를 보존해야 한다.
  • Rollback하면 schema나 데이터 호환성이 더 깨진다.
  • 보정 SQL이나 배치를 dry-run으로 검증할 수 있다.

Forward Fix는 빠를 수 있지만 더 위험할 수도 있다.

항상 dry-run, 승인, 작은 batch, 검증 SQL 순서를 둔다.

기능 차단과 시간 벌기

복구 방식을 바로 고르기 어렵다면 시간을 벌어야 한다.

  • 문제가 된 기능만 feature flag로 끈다.
  • 쓰기 기능을 read-only로 제한한다.
  • 배치나 consumer를 멈춘다.
  • 외부 API 재시도를 줄인다.
  • 신규 배포를 멈춘다.

시간을 버는 조치는 원인 분석을 지연시키는 것이 아니라 손실 범위를 고정하기 위한 것이다.

하지 말아야 할 대응

  • 데이터 변경 여부를 모른 채 Rollback하지 않는다.
  • 운영 DB에 백업을 바로 덮어쓰지 않는다.
  • 사고 이후 정상 생성된 데이터를 무시하지 않는다.
  • 외부 결제나 알림 상태를 확인하지 않고 DB만 되돌리지 않는다.
  • 보정 SQL을 dry-run 없이 실행하지 않는다.
  • 복구 방식의 선택 이유를 기록하지 않은 채 실행하지 않는다.

인프라 담당자와 공유할 자료

  • 장애 시작 시각, 발견 시각, 마지막 정상 시각
  • 새 배포 또는 설정 변경 시각
  • migration 실행 여부와 버전
  • 백업 기준 시각과 복구 가능한 시점
  • 사고 이후 정상 쓰기 여부
  • 외부 부작용 여부
  • 선택한 복구 방식과 선택하지 않은 방식의 이유
  • 복구 후 검증 SQL과 API

종료 조건

  • 선택한 복구 방식의 실행 결과가 기록됐다.
  • 사용자 영향이 회복됐거나 임시 완화 상태가 안정적이다.
  • 데이터 정합성 검증이 끝났거나 별도 후속 작업으로 분리됐다.
  • 복구 방식 선택 이유가 장애 보고서에 남았다.
  • 다시 같은 복구를 실행하지 않도록 원인 경로가 차단됐다.

확인 질문

확인 질문

  • Rollback과 Restore의 차이는 무엇인가?
    • Rollback은 코드나 설정을 되돌리는 것이고, Restore는 데이터를 되돌리는 것이다.
  • 데이터 변경이 있는 장애에서 바로 Rollback하면 위험한 이유는 무엇인가?
    • 이전 코드가 변경된 schema나 데이터와 호환되지 않거나 사고 이후 정상 데이터를 잃을 수 있기 때문이다.
  • Forward Fix를 선택하려면 무엇이 필요한다?
    • 잘못된 범위가 명확하고 dry-run과 검증 SQL로 보정 대상을 확인할 수 있어야 한다.

리뷰 체크포인트

  • 복구 방식을 고르기 전 질문이 명확한가?
  • Rollback, Restore, Forward Fix의 선택 기준이 분리되어 있는가?
  • 데이터 변경과 외부 부작용 확인이 포함되어 있는가?
  • 운영 DB 직접 복원 금지가 명시되어 있는가?
  • 선택하지 않은 복구 방식의 이유를 남기게 되어 있는가?

관련 문서

백링크