사례7건

7건 중 1~5번째

1. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기
2. IL-0078 EKS 업그레이드 중 Terraform 으로 KMS 시크릿 암호화를 켜자 워커 노드의 IAM 권한이 빠져 운영 ZenML Pro 워크스페이스에 모두 접속할 수 없게 됐다

   ZenML2025

   증상

   2025-05-11 0시부터 8시 사이, 중부유럽 서머타임인 CEST 기준으로 ZenML Pro 워크스페이스 서버에 모두 접속할 수 없었다.

   서비스 중단

   촉발

   EKS 모듈을 업그레이드하면서 Terraform 으로 AWS KMS 시크릿 암호화를 켰다. 이 작업이 문서에 없는 버그에 걸려 워커 노드의 IAM 권한이 빠졌다.

   원인

   소프트웨어 결함

   구성 요소

   Terraform노드 풀

   기여 요인

   스테이징 불일치미뤄 둔 업그레이드

   감지

   팀은 밤새 돌게 둔 업그레이드를 이어서 보려고 5월 11일 06:00 에 클러스터를 다시 보다가 비정상 상태를 발견했다.

   조치

   • 영향받은 EKS 노드 그룹을 올바른 IAM 권한과 설정으로 다시 만들었다.
   • 영향받은 모든 ZenML Pro 환경에서 서비스 접근을 복구했다.

   후속 조치

   • EKS 와 VPC Terraform 모듈을 모두 현재 지원되는 버전으로 올렸다.
   • 계획한 EKS 클러스터 업그레이드를 마쳤다.
   • 재발을 막도록 쿠버네티스와 인프라의 정기 업그레이드 전략을 검토한다.

   교훈

   팀은 규모가 훨씬 작은 스테이징 클러스터에서 업그레이드가 성공한 것을 보고 운영에서 같은 변경의 위험을 낮게 봤다. 쿠버네티스와 모듈 버전을 건너뛰는 사이 업그레이드 복잡도가 쌓여, 업그레이드 한 번에 많은 변경이 한꺼번에 실렸다.

   사례 보기
3. IL-0244 EKS 서브넷의 라우팅 테이블 연결이 사라져 live 클러스터의 Cloud Platform 서비스에 접근할 수 없었다

   UK Ministry of Justice2024

   증상

   2024년 9월 20일 11:24 에 live 클러스터 서비스를 감시하는 Pingdom 에서 우선순위 높은 알림이 울렸고, 사용자들은 서비스 주소를 찾을 수 없다고 알려 왔다.

   서비스 중단네트워크 도달 불가리소스 삭제

   촉발

   11:21 에 infrastructure-vpc-live-1 파이프라인의 일시 정지를 풀자, 팀이 미처 알아보지 못한 채 대기열에 있던 PR 이 자동으로 실행돼 EKS 서브넷 라우팅 테이블 연결을 지웠다.

   원인

   운영 실수

   구성 요소

   TerraformCI 시스템VPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   11:24 에 live 클러스터 서비스를 감시하는 Pingdom 이 Cloud Platform 팀에 우선순위 높은 알림을 보냈다. 11:26 부터는 사용자들이 #ask 채널에 서비스를 쓸 수 없다고 알려 왔다.

   조치

   • 11:32 에 Cloud Platform 팀이 로컬에서 terraform apply 를 다시 실행해 서브넷 라우팅 테이블 연결을 다시 만들었고, 서비스를 쓸 수 있게 됐다.

   후속 조치

   • 인프라 파이프라인을 멈추고 다시 켜는 절차를 검토하고 고쳐, 팀원 모두가 파이프라인을 멈추고 다시 켰을 때의 영향을 알게 한다.
   • 인프라를 손으로 고치는 동안 대기열의 PR 실행을 멈출 방법을 찾는다.
   • 인프라 파이프라인의 plan 작업과 apply 작업을 더 잘 격리할 방법을 찾는다.

   사례 보기
4. IL-0091 Terraform 으로 노드 인스턴스 타입을 바꾸자 노드가 한꺼번에 교체되어 사용자 운영 파드가 모두 지워지고 서비스가 내려갔다

   UK Ministry of Justice2023

   증상

   2023-06-06 10:23 에 한 사용자가 운영 파드가 한꺼번에 지워졌다고 알렸다. 여러 사용자가 같은 문제를 알렸고, 애플리케이션이 몇 분 동안 내려갔다는 Pingdom 알림을 받았다고 했다.

   서비스 중단

   촉발

   팀이 Terraform 으로 노드 인스턴스 타입을 바꾸었다.

   원인

   설정 변경

   구성 요소

   노드 풀Terraform

   기여 요인

   과도한 영향 범위런북 부재

   감지

   사용자들이 운영 파드가 한꺼번에 지워졌다고 알렸고, 애플리케이션이 내려갔다는 Pingdom 알림을 받았다고 전했다. 첫 감지 시각은 10:26 이다.

   후속 조치

   • 중단 없이 노드 인스턴스 타입을 바꾸는 절차를 묻는 티켓을 AWS 에 열었다.
   • Terraform 으로 하는 노드 인스턴스 타입 변경을 중단 없이 할 방법을 정하고, 그 절차를 런북으로 만든다.

   사례 보기
5. IL-0109 로그 수집을 고치려던 EKS 노드 롤오버가 꼬이면서 Auto Scaling 그룹이 정상 워커 노드를 모두 종료해 클러스터에 노드가 하나도 남지 않았다.

   DFDS2023sev1

   증상

   2023-02-14 09:33 UTC, 최종 사용자들이 CloudWatch 로그가 제대로 들어오지 않는다고 알려 왔다. 팀은 fluentd 를 조사하다가 컨테이너 런타임이 docker-shim 이 아니라 containerd 로 바뀌어 있다는 것을 찾았다. 전날 07:30 UTC 의 정기 노드 롤오버 때 containerd 가 실수로 기본 런타임으로 설정돼 있었다.

   서비스 중단리소스 삭제모니터링 중단

   촉발

   쿠버네티스 로그가 CloudWatch 로 가지 않는 문제를 고치려고 예정에 없던 노드 롤오버를 시작했다.

   원인

   설정 변경

   구성 요소

   컨테이너 런타임노드 런치 템플릿노드 풀Terraform텔레메트리 에이전트

   기여 요인

   자동화 증폭기본 설정 방치스테이징 불일치설정 테스트 부재런북 부재수동 조치 악화

   감지

   로그 문제는 최종 사용자들이 CloudWatch 로그가 이상하다고 알려 오면서 드러났다. 노드가 사라진 장애는 사후 분석 기준으로 2분 만에 감지됐다.

   조치

   • 10:49 UTC 에 노드 롤오버 스크립트로 새 노드를 추가하려 했지만 Docker Hub 타임아웃으로 실패했다.
   • 10:52 UTC 에 노드 롤오버 스크립트를 다시 돌려 새 노드를 추가했고, 11:01 UTC 에 로드밸런서가 새 노드를 정상으로 판단해 트래픽을 다시 보냈다.

   후속 조치

   • 롤오버 절차를 문서로 남기고, 특히 롤오버가 잘못됐을 때 할 수 있는 일을 적는다.
   • 롤오버 절차를 개선할 방법을 찾는다.
   • QA 시험에 fluentd 로그 수집을 넣어 로그가 처음부터 끝까지 전달되는지 확인한다.
   • fluentd 가 보내는 로그 데이터가 부족하거나 없을 때 울리는 경보를 추가한다.
   • 스테이징 환경을 만든다.
   • 잘못된 컨테이너 런타임을 고르지 못하게 막는 장치를 넣었다.

   교훈

   상황이 심각해져도 침착해야 한다. 서둘러 고치다 피해를 키우기보다 알려진 정상 설정으로 롤백하는 편이 낫다. 새 워커 노드를 띄우는 일은 cloudinit 스크립트의 어느 단계도 실패하지 않는다는 전제에 크게 기대고 있다.

   사례 보기

원인별3