롤백 설계, 되돌리는 시간을 먼저 재어 둡니다

되돌리는 시간을 재지 않으면 계획이 아닙니다

배포 계획에 '문제가 생기면 되돌린다'고 적혀 있는 경우가 많지만, 그 되돌림이 몇 분 걸리는지 적혀 있는 경우는 드뭅니다. 시간을 모르면 장애 중에 되돌릴지 고칠지 판단할 수 없습니다. 그래서 되돌림 시간을 실제로 재야 합니다. 재는 방법은 평시에 한 번 실행해 보는 것입니다. 시험 환경에서 이전 버전으로 되돌리고 서비스가 정상 응답할 때까지의 시간을 기록합니다. 그 숫자가 장애 대응의 기준선이 됩니다. 기준선이 있으면 '10분 안에 원인을 못 찾으면 되돌린다'처럼 판단 규칙을 숫자로 정할 수 있습니다.

데이터 변경은 되돌림에서 분리합니다

코드를 되돌리는 것은 대개 쉽지만 데이터 구조 변경은 되돌리기 어렵습니다. 열을 지우는 변경을 적용한 뒤 코드를 되돌리면, 예전 코드가 없는 열을 찾아 오류가 납니다. 그래서 두 작업을 분리합니다. 1단계로 데이터 구조를 추가만 하는 방향으로 변경합니다. 2단계로 새 코드를 배포합니다. 3단계로 안정화된 뒤 쓰지 않는 구조를 제거합니다. 이렇게 하면 2단계에서 문제가 생겨도 코드만 되돌리면 되고 데이터는 손대지 않습니다. 3단계를 2단계와 같은 배포에 넣으면 되돌림이 불가능해지므로, 두 배포 사이에 기간을 둡니다.

실패 비용을 되돌림 시간으로 계산합니다

학습용 가정으로 계산합니다. 가정값은 월 배포가 40회이고 그중 5퍼센트가 되돌림이 필요하며, 되돌림에 12분이 걸리고 중단 1분 손실이 5,000원이라고 두겠습니다. 되돌림이 필요한 배포는 2회이고, 중단 시간은 24분이며 손실은 120,000원입니다. 이것이 중간 계산값입니다. 최종 판단은 개선 효과로 합니다. 되돌림 시간을 12분에서 3분으로 줄이면 중단은 6분이 되어 손실이 30,000원으로 내려갑니다. 그래서 되돌림 자동화에 들이는 비용은 이 차액과 비교해 판단할 수 있습니다. 시간을 재 두지 않으면 이 비교가 불가능합니다.

되돌릴 수 없는 변경이 섞이면 전제가 깨집니다

결론을 뒤집는 조건은 되돌릴 수 없는 작업입니다. 외부로 보낸 메일, 결제 승인, 외부 시스템에 전달한 주문은 되돌림으로 취소되지 않습니다. 그래서 이런 작업이 포함된 배포는 되돌림만으로 복구가 끝나지 않고 보상 처리가 필요합니다. 배포 계획에 보상 절차를 함께 적어야 합니다. 두 번째 조건은 캐시입니다. 되돌린 뒤에도 앞단에 새 버전 응답이 남아 있으면 사용자는 계속 새 버전을 봅니다. 그래서 되돌림 절차에 캐시 무효화를 포함하고, 그 시간까지 되돌림 시간에 포함해 측정합니다. 측정값은 배포 계획서에 분 단위로 적습니다.

서버 운영 실행 전 점검표

• 시험 환경에서 되돌림을 실행해 시간을 측정했다
• 데이터 구조 변경을 추가 방향으로만 하고 제거는 분리했다
• 되돌림 판단 규칙을 숫자로 정했다
• 되돌릴 수 없는 작업의 보상 절차와 캐시 무효화를 포함했다