사례21건

21건 중 6~10번째

1. IL-0201 프레임워크 업그레이드가 쿠버네티스 인프라에서 커널 패닉을 일으켜 GitHub.com 의 웹과 API 요청이 15시간 넘게 간헐적으로 실패했다

   GitHub2025

   증상

   2025년 3월 17일 18:05 UTC 부터 GitHub.com 의 웹 요청과 API 요청이 간헐적으로 실패했다. 실패는 주로 풀 리퀘스트와 이슈 관련 요청에서 났고, 영향을 받은 사용자는 일부였다. 18:39 UTC 에 상태 페이지에 Issues 의 성능 저하 신고를 조사 중이라는 첫 공지가 올라왔다.

   오류율 상승간헐적 타임아웃

   촉발

   GitHub 이 쿠버네티스 인프라에 프레임워크 업그레이드를 적용했고, 이 업그레이드가 커널 패닉을 일으켰다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   리눅스 커널

   기여 요인

   –

   감지

   상태 페이지 첫 공지는 장애 시작 34분 뒤인 18:39 UTC 에 올라왔고, Issues 의 성능 저하 신고를 조사 중이라는 내용이었다.

   조치

   • 업그레이드한 프레임워크를 이전 버전으로 다운그레이드해 영향을 줄였다.
   • 문제를 일으킨 기능을 끌 수 있게 된 뒤 그 기능을 껐다.

   후속 조치

   • 업그레이드가 왜 예상하지 못한 문제를 일으켰는지 조사했다.
   • 같은 문제가 다시 나지 않도록 임시 조치를 했다.
   • 장기적인 패치 계획을 세운다.
   • 비슷한 종류의 문제에 빨리 대응할 수 있도록 관측성을 높인다.

   사례 보기
2. IL-0081 ingress-nginx 의 enable-serial-reloads 옵션이 NGINX 리로드 중에 엔드포인트 동적 갱신을 막아, 배포 중 트래픽이 이미 없는 파드로 가면서 API 요청이 타임아웃됐다.

   Cresta2025

   증상

   배포 도중 쿠버네티스로 들어오는 트래픽이 갈 곳을 잃기 시작했다. 일부 API 요청이 타임아웃됐다.

   간헐적 타임아웃오래된 엔드포인트 라우팅지연 시간 증가

   촉발

   오래 걸리는 NGINX 전체 리로드가 진행되는 동안 배포 롤아웃으로 백엔드 엔드포인트가 바뀌었다. ingress-nginx 컨트롤러에는 enable-serial-reloads 옵션이 켜져 있었다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러

   기여 요인

   –

   조치

   • 문제를 풀어 보려고 NGINX Ingress 컨트롤러를 재시작했다.

   후속 조치

   • enable-serial-reloads 가 엔드포인트 동적 갱신을 막는 문제를 kubernetes/ingress-nginx 에 이슈로 올린다.

   교훈

   자원 소모를 막으려고 켠 무해해 보이는 플래그 하나가, 라우팅이 실제 배포 상태와 어긋나는 구간을 만들 수 있다. 엔드포인트 동적 갱신이 리로드에 묶이면 배포 중 트래픽이 사라진 파드로 간다.

   사례 보기
3. IL-0131 새로운 형태의 GenerateContent 요청이 Vertex AI 예측 API 서버에 세그폴트를 일으켰고, 동시에 재시작하는 서버가 늘자 서빙 용량이 모자라 여러 리전에서 오류가 치솟았다.

   Google Cloud2024

   증상

   2024년 6월 12일 12:06 US/Pacific 부터 Vertex AI Online Prediction, Dialogflow CX, Agent Assist 에서 여러 리전에 걸쳐 오류율이 올라갔다. 영향을 받은 리전은 us-central1, asia-southeast1, europe-west3, europe-west4, us-east1, us-west1, northamerica-northeast1, us-east4 였다.

   오류율 상승지연 시간 증가간헐적 타임아웃

   촉발

   6월 8일부터 새로운 형태의 GenerateContent API 요청이 Vertex Serving Prediction API 서버에 간헐적인 세그폴트를 일으켰고, 6월 12일 이런 요청의 비율이 늘었다.

   원인

   소프트웨어 결함

   구성 요소

   모델 추론 서버클라우드 로드 밸런서

   기여 요인

   부분 배포여유 용량 부재

   감지

   6월 10일 07:35 US/Pacific 에 내부 운영 모니터링이 엔지니어들에게 세그폴트 문제를 알렸다. 이때는 고객 영향이 없었다. 6월 12일 12:06 에는 Vertex Prediction 위에 만든 여러 서비스에서 운영 중인 사용자 요청이 영향을 받았다는 보고가 올라왔다.

   조치

   • 6월 12일의 새 장애가 6월 10일에 찾은 세그폴트와 원인이 같다는 것을 확인했다.
   • 이미 진행 중이던 수정본 배포를 앞당겨 15:59 US/Pacific 에 마쳤다.

   후속 조치

   • 서버 바이너리 문제의 초기 신호를 운영 상태 분석에서 잡아내고 제때 조사하게 한다.
   • 기능 변경과 업데이트를 운영에 내보낼 때 릴리스 검증을 거치게 한다.

   교훈

   로드밸런서가 크래시로 내려간 서버를 피해 요청을 보내는 동안에는 고객 영향이 보이지 않는다. 하지만 크래시를 일으키는 요청이 늘면 동시에 빠지는 서버가 늘어 서빙 용량이 부하를 감당하지 못하게 된다. 이번에는 6월 10일에 원인과 수정본이 이미 있었지만 단계적 배포가 끝나기 전에 고객 영향이 시작됐다. 서버 바이너리의 초기 이상 신호는 고객 영향이 없을 때도 운영 상태 분석에서 잡고 제때 조사해야 한다.

   사례 보기
4. IL-0161 앞선 API 업데이트가 의도대로 동작하지 않아 토론토 데이터센터에서 새 LKE 클러스터 프로비저닝이 타임아웃으로 사흘 넘게 실패했다.

   Linode2024

   증상

   2024년 4월 22일 14:05 UTC 쯤 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않았다.

   클러스터·노드 생성 정체간헐적 타임아웃

   촉발

   앞서 배포한 API 업데이트가 의도대로 동작하지 않았고, 새 LKE 클러스터를 프로비저닝할 때 타임아웃을 일으켰다.

   원인

   소프트웨어 결함

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   2024년 4월 22일 14:05 UTC 쯤 Linode 팀이 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 알아채고 조사를 시작했다.

   조치

   • 4월 23일 15:03 UTC 에 문제가 된 토론토 데이터센터의 인프라를 새 LKE 클러스터 프로비저닝에 쓰지 않도록 껐다.
   • 4월 25일 16:45 UTC 쯤 의도대로 동작하지 않던 API 업데이트를 바로잡는 수정을 적용했고, 18:05 UTC 에 새 클러스터 생성이 완전히 돌아온 것을 확인했다.
   • 수정을 적용한 뒤 잠시 빼 두었던 인프라를 다시 프로비저닝에 넣었다.

   교훈

   원인은 오류가 드러난 인프라가 아니라 앞서 배포한 API 업데이트에 있었다. 그런데도 실패는 대부분 한 데이터센터의 백엔드 자원 하나에 몰렸다. 그 자원을 새 클러스터 프로비저닝에서 빼서, 근본 원인을 찾는 데 걸린 사흘 동안 고객 영향을 줄였다.

   사례 보기
5. IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.

   Scaleway2024

   증상

   2024-01-24 23:48 CET, FR-PAR 리전에서 Kapsule 과 Kosmos 고객 클러스터의 일부 노드가 NotReady 로 바뀌었다. 같은 시각 API Gateway 로 들어오는 요청이 크게 치솟았다.

   노드 NotReadyOOMKilled간헐적 타임아웃모니터링 중단

   촉발

   FR-PAR 에서 동시에 몰린 배포가 Scaleway Kubernetes API 의 메모리를 바닥냈다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도kubelet

   기여 요인

   단일 장애점재시도 폭주

   감지

   23:48 에 API Gateway 부하가 늘어난 것이 감지됐고, 00:00:10 에 내부 에스컬레이션을 거쳐 당직 엔지니어가 맡았다.

   조치

   • 관리형 Kubernetes 서비스의 메모리 한도와 가비지 컬렉션 임계값을 곧바로 올렸다.
   • 늘어난 부하를 받도록 주요 서비스에 복제본을 추가로 배포했다.
   • 레지스트리 캐시를 비우고, 클러스터가 안정되는 동안 지켜봤다.
   • 장애 뒤에도 계속 모니터링하며 서비스 설정을 조정했다.

   후속 조치

   • 로컬 인증 캐시를 구현한다.
   • 노드 인증 방식을 더 개선한다.
   • 모니터링을 강화하고 레이트 리밋 전략을 조정했으며 장애 대응 절차를 개선했다.

   교훈

   탄탄한 모니터링과 빠른 대응 체계가 중요하다. Kubernetes API 가 노드 인증까지 맡고 있어서 API 의 메모리 부족이 곧장 노드 NotReady 로 번졌다. Scaleway 는 이를 막으려고 로컬 인증 캐시와 노드 인증 개선을 계획했다.

   사례 보기

원인별7