Kubernetes ConfigMap 반영 누락으로 생긴 장애를 40분 안에 복구한 운영 플레이북

배포 파이프라인은 초록불인데 서비스 응답 헤더가 이전 값으로 계속 나오던 밤이 있었습니다. 팀은 처음에 캐시 문제로 보고 CDN 무효화를 먼저 돌렸지만, 10분이 지나도 지표가 그대로라서 접근을 바꿨습니다. 실제 원인은 ConfigMap이 갱신됐어도 파드가 재기동되지 않아 새 설정을 읽지 못한 상태였고, 일부 워커는 수동 재시작으로 새 값을 쓰는 반면 나머지는 옛 값을 쓰면서 트래픽 분산이 꼬였습니다. 이때 가장 위험한 선택은 감으로 kubectl rollout restart를 전체 네임스페이스에 날리는 것입니다. 우리도 예전에 그렇게 했다가 연쇄 재시작으로 큐 지연이 커졌습니다. 그래서 이번에는 장애 범위를 먼저 수치로 줄였습니다. 에러율이 아니라 설정 버전 불일치 비율, 파드 세대(revision) 분포, 요청 지연 p95를 기준으로 “어느 디플로이먼트부터 손댈지”를 정하고, 영향도가 큰 API 게이트웨이와 인증 서비스 두 곳만 1차 복구 대상으로 잠갔습니다. 이 선별만으로 불필요한 재시작을 피해서 복구 시간을 크게 줄였습니다.

판단 기준은 네 가지로 고정했습니다. 첫째, kubectl get deploy -o wide와 파드 애노테이션을 비교해 원하는 설정 해시와 실제 실행 해시가 다른지 확인합니다. 둘째, readiness 실패 원인이 이미지 풀이나 리소스 부족이 아닌 설정 파싱 오류인지 로그 100줄로 즉시 분류합니다. 셋째, 동일 서비스라도 트래픽 상단 20퍼센트를 담당하는 파드군만 먼저 교체해 체감 장애를 줄입니다. 넷째, 재시작 후 5분 동안 p95와 5xx가 기준선을 벗어나면 즉시 중단합니다. 여기서 중요한 건 “모든 파드를 동시에 맞추는 것”보다 “사용자 영향이 큰 경로를 먼저 안정화”하는 순서였습니다. 실제 현장에서는 한 엔지니어가 ConfigMap 수정, 다른 엔지니어가 SLO 대시보드 감시를 전담했는데, 역할이 분리되니 의사결정이 빨라졌습니다. 예전처럼 한 사람이 명령과 모니터링을 같이 잡으면 확인 공백이 생겨 잘못된 롤아웃을 늦게 발견하게 됩니다.

실행 절차는 준비 10분, 제한 롤아웃 20분, 검증 10분으로 끊었습니다. 준비 단계에서 현재 ConfigMap을 백업하고, 디플로이먼트 템플릿에 설정 체크섬 애노테이션이 있는지 확인했습니다. 체크섬 주입이 없던 서비스는 임시로 checksum/config 값을 강제 변경해 파드 교체를 유도했고, 이미 주입이 있던 서비스는 해시 계산 스크립트만 다시 실행했습니다. 제한 롤아웃 단계에서는 카나리 10퍼센트만 먼저 교체한 뒤 신규 파드 로그에서 설정 버전 문자열이 기대값과 일치하는지 확인했습니다. 이때 CPU나 메모리가 멀쩡해 보여도 연결 풀 재초기화 때문에 응답 지연이 튈 수 있어서 HPA 확장은 보류하고 트래픽만 천천히 늘렸습니다. 한 번은 복구 욕심에 replica를 먼저 늘렸다가 DB 세션이 급증해 장애가 길어진 적이 있었기 때문입니다. 검증 단계에서는 단순히 “파드 수가 정상”이 아니라, 15분 윈도우에서 오류 버전 요청 비율이 1퍼센트 미만으로 떨어졌는지까지 확인하고 종료했습니다.

운영 체크리스트는 복구 이후가 핵심입니다. 첫째, 배포 파이프라인에 “ConfigMap 변경 시 체크섬 누락이면 실패” 규칙을 추가해야 같은 사고를 끊을 수 있습니다. 둘째, 런북에 중단 조건을 명시해 두세요. 예를 들면 5xx가 기준 대비 2배 상승 3분 지속, p95가 800ms 초과 5분 지속, 인증 실패율 급증 같은 조건입니다. 셋째, 장애 회고에서는 기술 원인만 보지 말고 결정 흐름을 남겨야 합니다. 이번에도 초반 7분을 CDN 탓으로 소비했는데, 다음부터는 “설정 반영 여부 확인”을 1순위 진단으로 올리기로 합의했습니다. 마지막으로, 핫픽스 커맨드를 문서에 그대로 붙여 두지 말고 환경별 변수 템플릿으로 바꿔야 야간 당직자가 안전하게 재사용할 수 있습니다. ConfigMap 장애는 자주 작게 시작하지만, 반영 보장 장치와 판단 순서를 팀 규칙으로 고정해 두면 대형 장애로 번지는 것을 막을 수 있습니다.