장애보고서(COE)에 들어가야할 것.
🚨 장애 일지: CDB 마이그레이션 대참사
부제: "환경변수 그 녀석, 아직 살아있었다"
📌 사건 요약
- CDB 마이그레이션을 위해 호스트 환경변수를 고쳤다고 생각함
- 애플리케이션을 재배포했는데, 여전히 구 CDB 주소로 접속 중
- 구 CDB를 삭제하는 순간...
→ 모든 API: "나 이제 어디로 가야 하죠?!" → 5xx 퍼레이드 🎉
👉 고객 영향: 약 N분간 서비스 불가
👉 금전적 피해: 없음 (다행)
👉 CS 문의: 소량 발생 (살짝 불타는 불판 위 느낌)
🕒 타임라인
- [11:30] 새 DB로 마이그레이션 OK! 구 DB 삭제해도 되겠지~
- [11:35] 구 CDB 삭제 완료
- [11:41] 모든 API: "DB... DB가 없어...!" → 5xx 대폭발 💥
- [11:50] 장애 인지
- [12:01] 로그/메트릭 확인 → 애플리케이션 문제로 좁혀짐
- [12:10] 환경변수 확인 → "어? 왜 구 DB 주소 그대로지?" 😱
- [13:10] 배포 매니페스트에서 직접 수정 → 증상 해소
- [13:14] Github Actions 워크플로우 확인 → 원인 발견
- [13:19] 워크플로우 수정 후 재배포 → 정상 작동 🎉
❓ 5 Whys
- 왜 다운됐냐?
→ 여전히 구 DB 주소로 접속하고 있었음 🤦 - 왜 구 DB 주소였냐?
→ helm values는 고쳤는데 Github Actions가 옛날 값 우겨넣음 - 왜 Github Actions 안 고쳤냐?
→ 마이그레이션 플랜에서 그 부분은 그냥 "설마~" 하고 넘김 - 왜 검증 없이 했냐?
→ 체크리스트가 없었다 (즉, 감으로 함 😅) - 왜 몰랐냐?
→ API 몇 개 잘 되길래 "다 된 거네~" 하고 즐거워했음 → 착각
🛠️ 재발 방지 방안
단기 응급처치
- Deployment 환경변수 → 새 DB로 수정
- Github Actions 워크플로우 helm values 우선순위 수정
- 일단 불 끔 🚒
장기 대책
- 작업 플랜 템플릿 만들기: 순서, 검증 방법, 롤백 플랜까지 ✍️
- 체크리스트 도입: "Github Actions도 바뀌었나?" 같은 질문 포함
- 자동 검증/Failover 시스템 도입: "DB 안 살아있으면 바로 Failover!"
🎬 마무리
이번 사건을 통해 얻은 교훈:
"Pod가 정상적으로 뜬다고 해서, 서비스도 정상일 거라는 착각은 금물"
다음번에는 환경변수 하나 때문에 이불킥할 일은 없도록 합시다 🙏
(그리고 이 글은 후세에 ‘DB 마이그레이션 민속놀이’로 전해지겠지…)
