롤백 후 시스템 복구: 버튼 클릭 그 이상
프로덕션 환경의 배포 변경에 문제가 있는 경우 가장 일반적인 대응은 롤백입니다. 그러나 롤백은 코드나 구성을 이전 버전으로 복원할 뿐이며 자동 시스템 복구가 가능하다는 것을 보장하지는 않습니다. 데이터베이스 마이그레이션, 캐시의 더티 데이터, 다운스트림 종속성의 상태 변경으로 인해 발생하는 비호환성으로 인해 롤백 후에도 시스템이 하위 상태 또는 사용할 수 없는 상태로 유지될 수 있습니다. 실제로 필요한 것은 완전한 복구 플레이북을 실행하여 시스템 보안을 다시 안정성으로 되돌리고 사용 가능한지 확인하는 것입니다.
가장 가능성이 높은 실패 시나리오: 복구되지 않은 변수 및 더티 데이터가 남아 있음
시나리오: 데이터베이스 마이그레이션 롤백이 데이터와 일치하지 않습니다.
일반적인 실패 시나리오를 생각해 보십시오. 데이터베이스 마이그레이션, 새 테이블 추가 및 이전 테이블 구조 수정이 포함된 배포를 수행합니다. 온라인 접속 후 성능이 저하되는 것으로 확인되어 실행코드를 이전 버전으로 롤백하였습니다. 그러나 마이그레이션 작업은 롤백되지 않고 새 테이블이 여전히 존재하며 이전 테이블 구조가 수정되었습니다. 이전 코드가 이전 구조에 쓰려고 하면 직접 오류를 보고하거나 불일치가 발생할 수 있습니다. 더욱 위험한 것은 마이그레이션 중에 작성된 새 데이터가 이전 비즈니스 논리와 충돌하여 사용자에게 표시되는 오류가 발생한다는 것입니다.
실패 지점: 롤백 스크립트에 데이터 마이그레이션의 역방향 작업이 포함되어 있지 않거나 잘못된 순서로 역방향 작업이 수행됩니다(예: 새 테이블이 먼저 삭제되지만 새 구조에 의존하는 기존 테이블에 이미 레코드가 있는 경우).
또 다른 일반적인 시나리오: 구성 센터와 롤백이 동기화되지 않음
구성 항목은 구성 센터를 통해 제공됩니다. 이 배포에서는 코드와 구성이 모두 변경됩니다. 코드가 롤백된 후 구성이 롤백되지 않아 이전 코드가 새 구성을 사용하게 됩니다(예: 연결 문자열이 잘못된 클러스터를 가리킴).
롤백 복구 단계: 중지부터 확인까지 7가지 주요 조치
다음은 프로덕션에서 입증된 복구 플레이북의 핵심 단계입니다. 각 단계에는 명확한 판단 조건과 실패 대응이 있습니다.
- 변경 사항 확산 즉시 중지: 변경 사항이 여전히 회색조 또는 일괄적으로 릴리스되는 경우 후속 트래픽 액세스를 중지합니다. 롤백을 확인하기 전에 오류 영역을 계속 확장하지 마십시오.
- 코드/구성 롤백 실행: git revert를 사용하여 이전 릴리스 커밋으로 롤백하거나 CI/CD를 통해 이전 빌드로 롤백합니다. 구성의 경우 구성 센터도 동기식으로 롤백되는지 확인하십시오(기록 버전에 따라 롤백).
- 데이터 마이그레이션 역방향 작업 실행: 이 변경에 데이터베이스 마이그레이션이 포함된 경우 역방향 마이그레이션을 수행합니다(예: Flyway 또는 Liquibase의 실행 취소 스크립트 사용). 역이주가 준비되지 않은 경우 SQL을 수동으로 실행하여 이전 구조를 복원해야 합니다. (이때 백업에서 복원하는 것이 우선시되어야 합니다.)
- 캐시 정리: 이전 코드로 작성된 호환되지 않는 형식의 데이터는 롤백 후에도 캐시에 남아 있을 수 있습니다. 관련 캐싱 계층(Redis, Memcached 또는 CDN 캐시)을 지웁니다. 참고: 캐시가 완전히 지워지면 눈사태가 발생할 수 있습니다. 비즈니스 규모에 따라 단계적으로 폐지하거나 워밍업하는 것이 좋습니다.
- 종속성 상태 확인: 다운스트림 서비스(API, 메시지 큐, 데이터베이스)가 예상 버전인지 확인합니다. 예를 들어 서비스 A를 롤백했지만 A에 의존하는 서비스 B가 A가 더 이상 올바르게 처리할 수 없는 새로운 형식을 기반으로 요청을 보냈을 수 있습니다. 이때 B의 소비를 중단하거나 하향 조정해야 한다.
- 점진적 볼륨 검증: 소규모 사용자 그룹(예: 1%)에게 트래픽을 복원하고 오류율, 대기 시간 및 주요 비즈니스 지표를 모니터링합니다. 롤백 전과 후의 기준 데이터를 비교합니다.
- 지속적인 관찰: 최소 30분(또는 전체 경기주기) 동안 관찰하고, 이상이 없는지 확인한 후 점차적으로 전체 용량을 회복합니다.
실수하기 쉬운 단계는 3단계입니다: 많은 팀은 코드 롤백에만 집중하고 데이터 롤백을 무시하므로 "이전 코드, 새 데이터"라는 일관성 없는 상태가 발생합니다. 모든 데이터베이스 변경 사항에는 되돌릴 수 있는 스크립트가 수반되어야 하며 시험판 환경에서 확인되어야 한다는 점에 미리 동의해야 합니다.
권한 경계: 롤백 복구를 수행할 권한은 누구에게 있습니까?
롤백 복구는 스트레스가 많은 작업이며 부적절한 권한 제어로 인해 추가적인 위험이 발생할 수 있습니다.
- 실행 롤백 결정: 일반적으로 런북을 기반으로 당직 엔지니어 또는 SRE가 판단하지만, 주요 변경 사항(예: 전체 사이트에 영향을 미치는 경우)은 확인을 위해 팀 리더에게 알려야 합니다.
- 코드 롤백: CI/CD 서비스 또는 승인된 관리자만 롤백 파이프라인을 트리거할 수 있습니다. 각 개발자가 프로덕션 환경으로 직접 롤백하지 않도록 하세요.
- 데이터 롤백: 데이터베이스 롤백 스크립트는 DBA 또는 백업 복구 권한이 있는 역할만 실행해야 합니다. "dry-run" 모드에 자동 롤백 스크립트를 추가해야 하며, 실행할 SQL을 먼저 출력한 후 수동으로 확인해야 한다.
- 구성 롤백: 구성 센터는 변경 감사 및 빠른 롤백을 지원해야 하며 롤백 작업은 감사 로그에 기록되어야 합니다.
경계 사례: 오류가 사용자의 핵심 작업에 심각한 영향을 미치는 경우 권한 정책은 지정된 역할이 특정 승인 단계를 건너뛰고 나중에 이유를 기록할 수 있도록 '긴급 우회 메커니즘'을 설정해야 합니다.
롤백 실패 시 대체 경로: 롤백 자체가 신뢰할 수 없는 경우
완전한 복구 플레이북을 사용해도 롤백이 실패하는 경우가 있습니다. 예를 들면:
- 롤백 후 서비스를 시작할 수 없습니다(이전 코드는 제거된 라이브러리 또는 만료된 인증서에 의존함).
- 데이터 역마이그레이션으로 인해 불일치가 더 많이 발생했습니다.
- 롤백 프로세스 중 네트워크 중단으로 인해 일부 노드가 혼합 상태가 되었습니다.
대안 1: 스냅샷에서 복원
가장 최근의 전체 백업(전체 스냅샷)에서 복원합니다. 이는 일반적으로 롤백보다 더 철저하지만 복구 시간(RTO)이 더 깁니다. 데이터 계층에 오류가 발생하고 역마이그레이션을 통해 복구할 수 없는 시나리오에 적합합니다. 스냅샷 복구 프로세스를 정기적으로 연습하십시오.
대안 2: 대체 환경으로의 병렬 전환
아키텍처가 블루-그린 배포를 지원하는 경우 롤백이 실패하면 트래픽이 그린 환경(이전 버전)으로 직접 전환될 수 있습니다. 친환경 환경이 여전히 최신 데이터 동기화를 유지하고 있는지 주목하세요. 그렇지 않은 경우 먼저 데이터 마이그레이션을 수행하거나 부분적인 데이터 손실을 허용해야 합니다.
대안 3: 다운그레이드 및 회로 차단기
전체 복구가 불가능할 경우 다운그레이드 기능을 활성화할 수 있습니다. 즉, 비핵심 기능을 꺼서 핵심 링크를 사용할 수 있는지 확인하세요. 예를 들어 추천 알고리즘을 일시적으로 끄고 인기 있는 데이터만 반환합니다. 직접적인 실패를 방지하려면 쓰기 작업을 비동기 대기열로 변경하세요. 다운그레이드한 후에는 성공적인 복구가 수행될 때까지 기본 문제를 계속해서 해결하세요.
주요 결정: 롤백 실패 후 롤백을 반복적으로 시도하지 마십시오. 이렇게 하면 더 심각한 데이터 손상이 발생할 수 있습니다. 먼저 대체 솔루션으로 전환하는 것이 적절한지 평가하고 비상 대응 프로세스에 들어가도록 팀에 알려야 합니다.
다음 단계: 복구 방식을 자동화 및 팀 역량으로 전환
본 글에서 제공하는 플레이북은 기본 프레임워크로 각 팀의 시스템 특성에 맞게 커스터마이징해야 합니다. 중요한 것은 단계를 암기하는 것이 아니라 해당 단계를 예행 연습하고 배포 프로세스에 내재화하는 것입니다.
AI의 도움을 받아 이러한 유형의 복구 메커니즘을 설계하고 작성하는 방법과 일반 개발자에서 엔지니어링 판단을 갖춘 에이전트 엔지니어로 전환하는 방법을 보다 체계적으로 배우고 싶다면 관련 과정을 더 탐색해 볼 수 있습니다.
아직 댓글이 없습니다