사례11건

11건 중 4~8번째

1. IL-0118 쿠버네티스 네임스페이스 라벨을 전역으로 바꾸자 네트워크 계층이 메타데이터를 다시 계산하면서 가장 큰 GPU 클러스터들 가운데 세 곳의 컨트롤 플레인이 과부하에 빠졌고, ChatGPT 와 API 가 타임아웃과 503 오류를 냈다.

   OpenAI2024

   증상

   2024년 11월 25일 태평양 시각 오전 10시 15분부터 API 와 ChatGPT 트래픽의 상당 부분이 타임아웃과 503 오류로 실패했다.

   오류율 상승지연 시간 증가컨트롤 플레인 무응답

   촉발

   쿠버네티스 네임스페이스 라벨을 전역으로 바꿨고, 이 변경 때문에 네트워크 계층이 의도치 않게 메타데이터를 다시 계산했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위디버그 접근 제한

   조치

   • 영향받은 클러스터에서 워크로드를 손으로 빼냈다. 컨트롤 플레인이 응답하지 않아 이 작업이 더 복잡했다.
   • 클라우드 업체와 함께 컨트롤 플레인 노드 수를 늘리고 동시에 데이터 플레인 노드 수를 줄여 컨트롤 플레인을 회복시켰다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 네임스페이스 변경을 잠갔다.
   • 일부 종류의 인프라 배포를 동결했다.
   • 같은 종류의 장애가 반복되지 않도록 신원을 허용 목록으로 관리한다.
   • 가능한 경우에는 트래픽이 자동으로 다른 곳으로 더 잘 옮겨 가도록 GPU 로드 밸런싱 로직을 고친다.
   • 플릿 전체에 걸친 인프라 변경을 관리하는 방식을 개선한다.

   사례 보기
2. IL-0152 정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정이 들어가 그 위에서 돌던 DOKS 클러스터 200개의 컨트롤 플레인이 자동으로 삭제됐다.

   DigitalOcean2024

   증상

   2024-01-23 13:02 UTC 에 DigitalOcean 은 12:18 UTC 부터 FRA1 리전의 쿠버네티스 클러스터 문제를 조사하고 있다고 공지했다. 사용자는 FRA1 클러스터와 통신할 때 오류를 겪을 수 있었다.

   리소스 삭제컨트롤 플레인 무응답

   촉발

   정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정 변경이 실수로 적용됐다.

   원인

   설정 변경

   구성 요소

   etcd쿠버네티스 API 서버

   기여 요인

   자동화 증폭파괴적 변경 보호 장치 부재과도한 영향 범위

   감지

   13:02 UTC 의 첫 상태 페이지 공지는 12:18 UTC 부터 조사 중이라고 했다. 사후 보고서의 타임라인에서는 12:36 에 잘못된 설정을 원인으로 확인했다.

   조치

   • 영향받은 클러스터마다 가장 최근 백업으로 etcd 클러스터를 되살렸다.
   • etcd 를 되살린 뒤 상태가 없는 컨트롤 플레인 컴포넌트를 다시 올려 컨트롤 플레인 복구를 마쳤다.
   • 13:00 에 복구 중 예상하지 못한 문제가 생기자 복구 메커니즘을 추가로 패치했고, 15:00 에 문제를 모두 해결했다.
   • 복구 도중 추가로 발견한 작은 버그를 고쳤다.
   • 고객지원팀이 영향받은 고객에게 직접 연락해 다음 조치를 안내했다.

   후속 조치

   • 운영 환경에서 어떤 경우에도 인프라 클러스터 자원이 자동으로 삭제되지 않게 막는 수정을 배포했다.

   교훈

   컨트롤 플레인을 받치는 인프라 클러스터의 설정 변경 하나가 한 리전의 DOKS 클러스터 200개의 컨트롤 플레인을 한꺼번에 지웠다. 하루 두 번 받아 둔 etcd 백업으로 클러스터를 되살릴 수 있었지만, 컨트롤 플레인 데이터는 백업 주기만큼, 최대 12시간 전 상태로 돌아갔다. 컨트롤 플레인이 사라진 동안에도 노드의 워크로드는 계속 돌았다.

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

   UK Ministry of Justice2023

   증상

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

   서비스 중단

   촉발

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

   원인

   설정 변경

   구성 요소

   노드 풀Terraform

   기여 요인

   과도한 영향 범위런북 부재

   감지

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

   후속 조치

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

   사례 보기
4. IL-0177 다른 팀의 설정 배포로 공유 L7 HAProxy 가 재로드될 때마다 messaging-hub 의 웹소켓 연결이 한꺼번에 끊겼다.

   LINE+2022

   증상

   LINE 의 messaging-hub 는 일본 음식 배달 서비스 Demaecan 의 Merchant 앱과 Driver 앱에 웹소켓으로 메시지를 보낸다. 어느 날 최대 트래픽 시간이 아닌데도 웹소켓 연결 수 그래프가 순간적으로 크게 떨어졌다. 이 현상은 한 번으로 끝나지 않고 불규칙하게 계속 일어났다.

   연결 리셋데이터베이스 과부하간헐적 연결 실패지연 시간 증가

   촉발

   같은 L7 로드밸런서를 공유하는 다른 서비스 담당자가 자기 LB 설정을 배포하면 HAProxy 가 재로드됐다. hard-stop-after 로 정한 30분이 지나 이전 프로세스가 종료되면서 거기 붙어 있던 웹소켓 연결이 모두 끊겼다.

   원인

   설정 변경

   구성 요소

   HAProxy클라우드 로드 밸런서conntrack 테이블인그레스 컨트롤러

   기여 요인

   늦게 드러난 변경과도한 영향 범위재시도 폭주미검증 가정

   감지

   웹소켓 연결 수 그래프에서 최대 트래픽 시간이 아닌데도 연결 수가 순간적으로 뚝 떨어지는 것을 보고 알았다. Nginx 패킷 드롭은 네트워크 모니터링으로 원인을 찾았다.

   조치

   • Merchant 팀이 토큰 발급 API 를 따로 떼어 배포해 토큰 요청이 몰려도 다른 Merchant API 가 지연되지 않게 했다.
   • Nginx 를 늘리고 파드 안티 어피니티와 레이블 셀렉터로 Nginx 파드가 서로 다른 노드에 뜨게 해서 NF_CONNTRACK 테이블 포화로 생기던 패킷 드롭을 없앴다.
   • Ingress Nginx 의 proxy-read-timeout 과 proxy-send-timeout 을 300s 에서 3600s 로, LB timeout 도 3600s 로 올렸지만 웹소켓 드롭은 멈추지 않았다.
   • 공유하던 L7 LB 를 L4 LB 로 바꿔 웹소켓 드롭을 없앴다.

   교훈

   문제의 범위를 미리 단정해 스스로 제한하면 안 된다. 인프라 팀과 네트워크 팀이 문제없다고 답했다는 이유로 직접 다룰 수 있는 영역만 뒤지다가 공유 L7 LB 를 늦게 의심했다. LB 같은 기술 리소스를 다른 서비스와 공유하면 다른 팀의 배포가 내 서비스의 연결을 끊을 수 있다. Nginx 를 늘려 NF_CONNTRACK 부담을 나눌 때는 파드가 서로 다른 노드에 뜨게 해야 하고, 노드 수보다 많이 늘리면 Pending 상태로 남는 파드가 생긴다는 점도 알아야 한다.

   사례 보기
5. IL-0010 템플릿 중괄호가 빠진 설정 변경으로 ArgoCD 가 전 세계 모든 클러스터의 서비스를 지웠다

   Skyscanner2021

   증상

   2021년 8월 25일 Skyscanner 는 네 시간 반 동안 전 세계에서 완전히 멈췄다. skyscanner.net 웹사이트에 접속할 수 없었고 모바일 앱도 동작하지 않았다. 여행자와 비즈니스 파트너 모두 Skyscanner 를 쓸 수 없었다.

   서비스 중단리소스 삭제

   촉발

   GMT 15:30 무렵 한 엔지니어가 앞으로 할 큰 변경을 준비하면서 템플릿 시스템에 변경을 올렸다. 시스템 동작은 바꾸지 않으려던 변경이었다. 셀 설정 루트 파일의 cell: {{ default $cluster.name $cluster.unique_name }} 줄을 cell: $cluster.name 으로 바꿨다. 변경은 동료 리뷰를 거쳐 master 에 머지됐고 자동으로 배포됐다.

   원인

   설정 변경

   구성 요소

   Argo CD설정 템플릿

   기여 요인

   리뷰 누락단계적 배포 부재설정 테스트 부재미검증 백업자동화 증폭과도한 영향 범위

   조치

   • 클러스터마다 올바른 설정을 되돌려 놓고, GitOps 로 클러스터가 스스로 올바른 상태로 돌아오게 했다.
   • 팀이 익숙하게 다루던 백업과 복원 절차로 서비스를 복원했다.
   • 리전 하나와 핵심 서비스를 먼저 복구해 GMT 20:30 무렵 리전 하나에서 모든 트래픽을 받았다.
   • 목요일과 금요일에 걸쳐 나머지 리전과 핵심이 아닌 서비스를 되살리고 확인했다.

   후속 조치

   • 이번처럼 드물게 쓰이는 변경 경로에서도 설정 변경을 전 세계에 한꺼번에 배포하지 않게 한다.
   • 템플릿과 로직이 들어간 설정을 코드로 다루고, 테스트와 린트를 도입한다.
   • 시나리오와 런북이 최악의 재해 규모까지 다루게 하고, 더 극단적인 상황을 워게임으로 연습한다.
   • 백업과 복원 절차를 검증한다. 필요할 때 백업을 실제로 꺼낼 수 있는지, 리전 하나가 내려간 경우에도 되는지 확인한다.
   • 새벽에 긴장한 엔지니어가 읽어도 맥락과 단계가 분명하고, 필요하면 여러 번 실행해도 결과가 같도록 런북을 고쳐 쓴다.
   • 이 설정을 리전마다 템플릿으로 찍어 낼 필요가 있었는지 다시 따지고, 리전마다 설정이 어긋날 위험과 자동화로 변경이 여러 리전에 한꺼번에 퍼질 위험 사이에서 균형을 찾는다.

   교훈

   설정에 템플릿과 로직을 넣는 순간 그 설정은 코드가 된다. 팀은 설정의 복잡도를 높이면서도 이 파일을 설정으로만 여겨 테스트도 린트도 두지 않았다. 전역 설정 배포를 막으려고 오래 공을 들였지만, 이 경로로 변경이 나가는 일은 아주 드물어서 미처 떠올리지 못했다. 시나리오와 런북은 이 정도 규모의 장애를 상정하지 않았다. 백업은 복원해 보기 전까지 백업이 아니다. 장애 대응을 지휘하는 인시던트 커맨더를 가장 경험 많은 사람이 맡아 누구도 탓하지 않고 상황을 이끈 것이 복구에 큰 도움이 됐다.

   사례 보기

원인별1