사례3건
3건 중 1~3번째
- 증상
뉴스 속보로 트래픽이 늘어 파드가 자동으로 늘어나던 중, 새로 뜨는 파드가 설정을 읽지 못해 시작하지 못했다. 컨테이너가 재시작을 거듭하며 파드가 차례로 죽어 장애가 났다.
- 촉발
옛 DB 를 폐기하려고 ConfigMap 과 코드에서 그 설정을 지운 릴리스가 Argo Rollouts 카나리로 파드 하나에만 나갔고, 전체 롤아웃을 잊은 상태였다. 그때 뉴스 속보로 트래픽이 늘어 구 버전 파드가 늘어났다.
- 원인
- 구성 요소
- 기여 요인
- 후속 조치
- Argo Rollouts 의 canary 단계를 setWeight: 1 뒤 pause duration: 1h 를 거쳐 setWeight: 100 으로 자동 롤아웃하도록 설정을 바꿨다.
- Helm 리소스에 "helm.sh/resource-policy": keep 주석을 달아 지난 버전의 ConfigMap 을 남기는 설정을 도입한다.
- ConfigMap 이름에 넣은 리비전 번호로 최신부터 순서를 확인해 지난 버전을 정리하는 Helm 플러그인 helm-clear 를 만들었다. CD 에서 helm clear configmap 에 --history 5 를 주어 지난 다섯 버전만 남기게 했다.
- 교훈
옛 DB 를 없애는 일은 드무니 다음에 조심하자는 회고로는 장애가 곧 다시 난다. 사람의 주의력은 믿을 수 없으므로, 재발을 막으려면 사람의 주의에 기대지 않는 장치를 만들어야 한다. Argo Rollouts 도입 초기에는 사람의 손을 거치지 않고 자동으로 롤아웃되는 것을 걱정했다. 그러나 몇 년 운영해 보니 오히려 롤아웃을 잊는 일이 더 많았고, 큰 릴리스는 어차피 Datadog 같은 감시 화면을 지켜보므로 거의 잊지 않았다. 지난 ConfigMap 을 남기자 ConfigMap 이 바뀐 릴리스도 CI/CD 를 거치지 않고 빠르게 롤백할 수 있게 되었다.
IL-0229손상된 SmartEdge 데이터 파일을 받은 bunny.net 의 전 세계 DNS 서버가 크래시를 되풀이해 플랫폼 대부분이 2시간 넘게 멈췄다.bunny.net2021- 증상
2021-06-22 UTC 8:25 에 업데이트를 내보내고 몇 분 만에 전 세계에 있는 100대 가까운 bunny.net DNS 서버가 거의 모두 죽었다. bunny.net 은 트래픽의 60% 넘게 잃었고, 수백 Gbit 의 처리량이 사라졌으며, 750,000개가 넘는 웹사이트가 영향을 받았다.
- 촉발
2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 10분 뒤에야 DNS 서버가 다시 시작했다가 죽기를 되풀이하고 있고, 이 상태로는 되살릴 방법이 없다는 것을 알았다.
- 조치
- UTC 8:45 에 SmartEdge 시스템을 끄는 업데이트를 DNS 노드에 손으로 배포했다. 하지만 손상된 GeoDNS 데이터베이스 때문에 요청이 Madrid 로 몰렸다.
- 9:40 무렵 임시 조치로 모든 요청을 가장 큰 리전인 Frankfurt 로 보내는 라우팅 업데이트를 준비해 DNS 서버 몇 대에 손으로 배포했다. 트래픽의 상당 부분이 돌아왔다.
- 자체 시스템을 쓰지 않으려고 배포 시스템과 파일을 모두 외부 클라우드 스토리지 서비스로 옮겼다.
- 10:15 에 배포 시스템과 DNS 소프트웨어를 새 스토리지에 연결하도록 바꾸고 배포했다. 10:30 에 트래픽이 돌아왔지만 잘못된 GeoDNS 데이터베이스 버전 때문에 요청은 여전히 Madrid 로 갔다.
- 10:45 에 외부 서비스를 거쳐 데이터베이스를 동기화하고 최신 파일 세트를 배포해 서비스를 되살렸다. 11:00 에 상황이 안정되기 시작했다.
- 후속 조치
- 긴급 수정으로 BinaryPack 라이브러리를 단계적으로 걷어 낸다.
- 앞으로 쓰는 외부 라이브러리를 더 폭넓게 시험한다.
- 내부 API 를 외부의 독립 서비스로 완전히 옮긴다. 그 서비스가 내려가면 업데이트를 못 하지만, bunny.net 시스템이 내려가도 무너지는 인프라에 갇히지 않고 빠르게 대응할 수 있다.
- 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 걸친 단일 장애 지점이 되지 않게 하는 방법을 조사한다.
- DNS 시스템이 모든 백업 데이터의 로컬 사본을 갖추고 장애를 자동으로 감지하게 해, 시스템끼리 최대한 독립시키고 장애가 연쇄로 번지지 않게 한다.
- 교훈
bunny.net 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.
- 증상
Boskos 에서 GCP 프로젝트를 받아야 하는 Prow 테스트 작업이 밤사이 전부 실패했다. kubernetes/kubernetes 의 모든 PR 에 필수인 pull-kubernetes-e2e-gce 가 계속 실패해서 PR 을 하나도 병합할 수 없었다.
- 촉발
Prow 클러스터를 쿠버네티스 1.11 에서 1.13 으로 올리는 노드 업그레이드 중 23:04 에 Boskos 파드 하나가 돌던 노드가 drain 됐다. 새 노드에서 다시 만들어진 Boskos 파드는 StatefulSet 스펙에 적힌 새 이미지로 시작했는데, 이 이미지에 버그가 있었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
알림은 울리지 않았다. Boskos 대시보드에는 실패가 뚜렷하게 보였지만 이를 잡는 알림이 없었다. 사용자들이 02:50 에 GitHub 로, 05:16 과 06:27 에 Slack 으로 장애를 알렸고, 담당자는 07:16 에 일어나 Slack 의 보고를 보고서야 알았다.
- 조치
- 버그를 찾은 뒤 고친 Boskos 이미지를 새로 빌드해 배포했고, Boskos 는 곧바로 살아났다.
- 장애 동안 반납되지 않고 열린 채로 남은 GCP 프로젝트들을 그 뒤 몇 분에 걸쳐 정리했다.
- 후속 조치
- Boskos 설정을 고쳐 배포하면 실제로 파드가 교체되게 한다.
- Boskos 배포를 자동화한다.
- Boskos 상태를 지켜보는 알림을 개선한다.
- 교훈
팀은 당직자가 오후 6시까지만 있는 날 오후 5시가 넘어 10시간짜리 배포를 시작하지 말았어야 했다고 보았다. 배포는 실제로 무언가가 바뀌었는지 확인할 수 있게 지켜봐야 하고, 그럴 수 없으면 아예 하지 않아야 한다고 정리했다. Boskos 의 StatefulSet 은 업데이트하도록 설정되어 있지 않아서 배포해도 아무것도 바뀌지 않았다. 12월의 변경은 한 번도 시험되지 않은 것으로 보였다. Prow 의 다른 부분과 달리 Boskos 는 손으로 배포해서 실수할 여지가 컸다. 담당자가 대응을 시작한 뒤로는 문제를 비교적 빨리 풀었다.
이 3건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, CI 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.