사례2건

2건 중 1~2번째

1. IL-0437 카나리 배포가 끝나지 않은 상태에서 구 버전 파드가 새 ConfigMap 으로는 시작하지 못해 연쇄적으로 죽었다

   Gunosy2023

   증상

   뉴스 속보로 트래픽이 늘어 파드가 자동으로 늘어나던 중, 새로 뜨는 파드가 설정을 읽지 못해 시작하지 못했다. 컨테이너가 재시작을 거듭하며 파드가 차례로 죽어 장애가 났다.

   컨테이너 재시작 반복

   촉발

   옛 DB 를 폐기하려고 ConfigMap 과 코드에서 그 설정을 지운 릴리스가 Argo Rollouts 카나리로 파드 하나에만 나갔고, 전체 롤아웃을 잊은 상태였다. 그때 뉴스 속보로 트래픽이 늘어 구 버전 파드가 늘어났다.

   원인

   배포 결함

   구성 요소

   컨피그맵과 시크릿Helm점진적 배포 컨트롤러

   기여 요인

   부분 배포자동화 증폭

   후속 조치

   • 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 를 거치지 않고 빠르게 롤백할 수 있게 되었다.

   사례 보기
2. 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개가 넘는 웹사이트가 영향을 받았다.

   컨테이너 재시작 반복DNS 조회 실패서비스 중단요청 오라우팅부하 불균형

   촉발

   2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.

   원인

   배포 결함

   구성 요소

   DNS 서버와 레코드CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   순환 의존단일 장애점자동화 증폭롤백 무효수동 조치 악화

   감지

   팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 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 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.

   사례 보기

원인별1