사례4건

4건 중 1~4번째

1. IL-0005 새 텔레메트리 서비스가 모든 노드에서 무거운 쿠버네티스 API 요청을 보내 대형 클러스터의 컨트롤 플레인이 무너졌고, DNS 기반 서비스 디스커버리가 깨져 OpenAI 의 모든 서비스가 멈췄다

   OpenAI2024

   증상

   2024년 12월 11일 오후 3시 13분 PST 에 알림이 울려 엔지니어들에게 전달됐다. 3시 16분부터 ChatGPT, API, Sora 를 포함한 OpenAI 의 모든 서비스가 크게 느려지거나 완전히 멈췄다.

   서비스 중단오류율 상승컨트롤 플레인 무응답DNS 조회 실패

   촉발

   오후 3시 12분 PST 에 쿠버네티스 컨트롤 플레인 지표를 자세히 수집하는 새 텔레메트리 서비스를 배포했다. 이 서비스의 설정 때문에 각 클러스터의 모든 노드가 무거운 쿠버네티스 API 요청을 보냈다. 이 요청은 클러스터가 클수록 비용이 커진다. 변경은 오후 2시 51분부터 3시 20분 사이에 모든 클러스터에 적용됐다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버클라이언트 쪽 DNS 리졸버와 캐시텔레메트리 에이전트

   기여 요인

   스테이징 불일치단계적 배포 부재캐시로 가려진 장애모니터링 사각지대디버그 접근 제한

   감지

   변경이 모든 클러스터에 적용되던 오후 3시 13분 PST 에 알림이 울려 엔지니어들에게 전달됐다. 탐지 도구는 고객이 영향을 받기 몇 분 전에 문제를 잡았고, 엔지니어들은 3시 16분에 원인을 찾았다. 다만 노드의 DNS 캐시가 실제 실패를 늦춰, 문제의 전체 범위가 보이기 전에 배포가 계속 진행됐다.

   조치

   • 클러스터 규모를 줄여 쿠버네티스 API 부하의 총량을 낮췄다.
   • 쿠버네티스 관리 API 로 가는 네트워크 접근을 막아 새로 들어오는 무거운 요청을 차단하고 API 서버가 회복할 시간을 벌었다.
   • 쿠버네티스 API 서버를 증설해 밀린 요청을 처리할 자원을 늘리고 수정을 적용할 수 있게 했다.
   • 컨트롤 플레인 제어권을 되찾은 뒤 문제의 텔레메트리 서비스를 지웠다.
   • 오후 3시 27분부터 영향받은 클러스터에서 트래픽을 빼기 시작했고, 가능한 곳에서는 트래픽을 정상 클러스터로 옮겼다.
   • 많은 서비스가 동시에 자원을 내려받아 자원 한도가 찬 클러스터에는 추가로 수동 조치를 했다.

   후속 조치

   • 모든 인프라 설정 변경에 단계적 배포를 적용하고, 서비스 워크로드와 쿠버네티스 컨트롤 플레인을 포함한 클러스터 상태를 계속 감시한다.
   • 데이터 플레인이 컨트롤 플레인 없이 버티는 상황과 잘못된 변경을 일부러 배포하는 상황을 시험하는 장애 주입 테스트를 돌린다.
   • 데이터 플레인이 컨트롤 플레인을 지나치게 압박할 때도 엔지니어가 쿠버네티스 API 서버에 접근할 수 있는 비상 접근 수단을 만든다.
   • 데이터 플레인과 컨트롤 플레인을 분리한다. 서비스 디스커버리가 쿠버네티스 DNS 에 묶여 있는 구조를 풀어, 핵심 서비스가 요청을 처리할 때 컨트롤 플레인에 기대지 않게 한다.
   • 클러스터 기동에 필요한 자원에 캐시와 동적 속도 제한을 더하고, 클러스터 하나를 통째로 빠르게 교체하는 훈련을 정기적으로 한다.

   교훈

   이 장애는 여러 시스템과 절차가 동시에 실패하며 예상하지 못한 방식으로 얽혀 생겼다. 테스트는 이 변경이 쿠버네티스 컨트롤 플레인에 주는 영향을 잡지 못했다. DNS 캐시 때문에 변경과 서비스 실패 사이에 시간 차가 생겼다. 컨트롤 플레인에 접근할 수 없게 되면서 복구가 매우 느렸다. 데이터 플레인이 컨트롤 플레인과 따로 돌도록 설계되어 있어도, DNS 기반 서비스 디스커버리가 컨트롤 플레인에 기대면 컨트롤 플레인 장애가 서비스 장애로 번진다. 배포 전 점검은 클러스터의 CPU 와 메모리 사용량만 봤고 API 서버 부하는 보지 않았다.

   사례 보기
2. 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. IL-0034 메트릭 에이전트 사이드카가 업그레이드 중 크래시하자 클러스터의 모든 파드가 준비되지 않은 상태가 되어 서비스가 트래픽을 받지 못했다

   Airbnb2019

   증상

   쿠버네티스의 메트릭 에이전트를 업그레이드하는 작업이 예정되어 있다는 공지가 나갔다. 공지에는 몇 분 동안 서비스가 메트릭을 쓰지 못할 수 있다고 적혀 있었다. 몇 분 뒤 한 서비스 담당자가 자기 쿠버네티스 서비스가 지금 모두 내려간 것 같다는 메시지를 보냈다.

   프로브 실패서비스 중단

   촉발

   예정된 작업으로 쿠버네티스의 메트릭 에이전트를 업그레이드하던 중, 파드마다 들어 있던 메트릭 에이전트 사이드카 컨테이너가 크래시했다.

   원인

   배포 결함

   구성 요소

   텔레메트리 에이전트서비스 디스커버리

   기여 요인

   미검증 가정과도한 영향 범위

   감지

   작업 공지가 나가고 몇 분 뒤 서비스 담당자가 자기 쿠버네티스 서비스가 모두 내려간 것 같다는 메시지를 보내와서 알았다.

   후속 조치

   • 로깅, 트레이싱, 메트릭 에이전트처럼 파드 준비 상태 판단에 넣지 않을 컨테이너를 중요하지 않은 컨테이너로 표시하고, 서비스 메시 로직이 파드 준비 상태를 판단할 때 이 컨테이너들을 건너뛰게 했다. 발표자는 이것을 임시 해결책이라고 했고 다른 방법도 검토했다고 했다.

   교훈

   헬스 체크는 컨테이너마다 걸리므로 파드 안의 각 컨테이너가 파드 전체의 준비 상태에 어떻게 영향을 주는지 따져서 설정해야 한다. 프로브를 설정하지 않은 사이드카도 크래시하면 준비되지 않은 상태가 된다.

   사례 보기
4. IL-0051 외부 업체의 로그 클라이언트가 새 컨테이너가 뜰 때마다 파일 디스크립터를 다시 열고 이전 것을 닫지 않아 쿠버네티스 노드가 too many open files 로 내려갔다

   thredUP2018

   증상

   쿠버네티스 마이그레이션이 순조로워 보이던 중 Datadog 에서 노드의 열린 파일 수가 계속 늘어나는 것이 보였다.

   서비스 중단파일 디스크립터 고갈

   촉발

   로그 파일을 쓰는 컨테이너가 여럿 떠 있는 노드에 새 컨테이너가 뜰 때마다, 외부 업체의 로그 클라이언트가 기존 로그 파일의 파일 디스크립터까지 새로 열고 이전 디스크립터를 닫지 않았다.

   원인

   소프트웨어 결함

   구성 요소

   텔레메트리 에이전트

   기여 요인

   미검증 가정

   감지

   Datadog 에서 노드의 열린 파일 수가 계속 오르는 것을 보고 알았다.

   조치

   • 문제가 난 노드를 죽이고 새 노드를 띄운 뒤 서비스를 다시 배포해 복구했다.

   후속 조치

   • 업체와 함께 문제를 다뤘고, 결국 그 로그 수집 업체의 서비스를 쓰지 않게 됐다.

   교훈

   EC2 에서 믿고 쓰던 서비스와 라이브러리가 쿠버네티스에서도 똑같이 잘 동작한다고 가정하면 안 된다. 그런 도구는 배포 방식과 수명 주기가 다른 환경을 전제로 만들어졌을 수 있다. 쿠버네티스에서는 배포할 때마다 컨테이너가 생기고 사라지고 노드 사이를 옮겨 다니므로, 쓰는 서비스마다 이런 수명 주기에 맞게 만들어졌는지 의심하고 확인해야 한다.

   사례 보기

원인별3