rollback 보다 forward fix 가 빠를 때
복구 전략을 고를 때, rollback 이 정답이 아닌 상황과 그 판단 기준
rollback 이 당연하다는 착각
배포가 터지면 반사적으로 rollback 부터 떠올린다. 나도 그랬다. 팀 위키에도 “장애 발생 시 즉시 이전 버전으로 복구”라고 적혀 있었고, 그게 맞다고 믿었다.
막상 해보면 다르다. rollback 이 forward fix 보다 느린 경우가 생각보다 많다.
그 날 사건
최근 결제 서비스에서 특정 카드사 응답 파싱이 깨졌다. 전체 결제 실패율이 3분 만에 12%를 넘어갔다. 온콜이 울렸고, 바로 롤백을 시도했다.
- 문제는 그 배포에 DB 스키마 마이그레이션이 함께 들어가 있었다. 컬럼 하나가 추가된 상태였고, 이전 버전 코드는 그 컬럼을 모른다. rollback 하면 코드는 되살아나는데 스키마는 앞으로 간 상태. 결국 다른 경로에서 다시 오류가 터진다.
- 롤백 파이프라인 자체도 문제였다. 우리 CD 구성이 이미지 태그 기준이라 “이전 버전”을 명시적으로 지정해야 했는데, 그 커밋 SHA 를 찾아 입력하는 데만 4분이 걸렸다. 장애 중 4분이면 체감으로는 20분이다.
- 그 4분 동안 같이 보던 동료가 파싱 오류 로그를 파고들어 원인을 찾았다. 카드사 응답 필드명이
authCode에서auth_code로 바뀐 것. 한 줄 수정이었다.
결국 rollback 완료 전에 forward fix 가 먼저 배포됐다. 실제 다운타임은 forward fix 기준 11분. rollback 이 끝났다면 아마 17~18분이었을 거다.
언제 forward fix 가 빠른가
판단 기준을 그 사건 이후 팀 내에서 정리했다.
- 스키마가 이미 변경됐을 때. 새 스키마를 전제로 짠 코드가 깨진 거라면, 이전 코드를 올려봐야 스키마 충돌이 기다린다. 오히려 새 스키마에 맞게 코드를 고치는 편이 안전하다. 이 경우 forward 방향이 유일한 선택지인 경우도 있다.
- 원인이 단순할 때. 로그 한 페이지 안에 원인이 보인다면 fix 시간이 10분을 넘지 않는다. rollback 파이프라인 실행 시간과 비슷하거나 더 짧다.
- 외부 의존성이 이미 앞으로 이동했을 때. 카드사 API 처럼 우리가 통제 못 하는 쪽이 바뀌어서 생긴 장애라면, rollback 해도 그 의존성은 되돌아오지 않는다. forward fix 밖에 없다.
rollback 이 맞는 상황도 있다
당연히 forward fix 가 항상 빠른 건 아니다.
- 원인 파악에 30분 이상 걸릴 것 같을 때. 이 판단 자체가 어렵긴 하지만, 로그에 명확한 스택트레이스가 없고 재현 경로가 불분명하면 일단 rollback 으로 안정화하는 게 낫다. 고치는 동안 사용자는 계속 실패를 보고 있으니까.
- 배포 범위가 클 때. 커밋이 200줄 넘고 변경 파일이 20개면, 어디서 터진 건지 좁히는 데만 시간을 쓴다. 이 때는 rollback 이 정직하게 빠르다. 원인 분석은 rollback 후 staging 에서 천천히 하면 된다.
- 데이터 정합성이 의심될 때. 코드 버그가 잘못된 데이터를 쌓고 있다면 rollback 보다 먼저 쓰기를 막아야 한다. forward fix 를 서두르다 오염 범위가 늘어난 경험이 있어서, 이 경우는 rollback 전에 write 엔드포인트 차단부터 한다.
준비가 판단 시간을 줄인다
사건 당일 가장 느렸던 건 rollback 파이프라인도 아니고, forward fix 속도도 아니었다. 둘 중 뭘 할지 결정하는 데 쓴 3분이었다.
그 3분을 없애려고 팀 런북에 딱 두 가지 질문을 추가했다.
“스키마 마이그레이션이 이 배포에 포함됐는가?” 와 “원인이 지금 로그에 보이는가?”
첫 질문이 Yes면 forward fix 를 기본으로, 둘 다 No면 rollback 을 기본으로 간다. 단순하지만 장애 중에 판단 에너지를 아끼는 효과가 있다. 올해 4월 장애 두 건에서 이 질문이 실제로 작동했고, 결정 시간이 1분 이내로 줄었다.
런북에 글을 쓰는 건 쉽다. 어려운 건 장애 중에 그 런북을 열게 만드는 습관이다. 그래서 알림 채널에 장애 공지가 올라오면 온콜 봇이 런북 링크를 자동으로 스레드에 달도록 바꿨다. 별 것 아닌 것 같은데, 막상 터졌을 때 링크 하나가 꽤 도움이 된다.
다음 한 가지
forward fix 경로가 빠르려면 배포 파이프라인이 충분히 짧아야 한다. 지금 우리 파이프라인은 이미지 빌드부터 배포까지 평균 8분인데, 이걸 5분 이내로 줄이는 작업을 다음 스프린트에 올린다. 그게 안 되면 어떤 복구 전략도 결국 느리다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.