사례14건

14건 중 7~11번째

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-0117 인그레스 업그레이드가 네트워크 컨트롤 플레인 회귀를 일으켜 데이터 플레인이 잠깐 끊겼고, 한꺼번에 재시작한 서비스들이 백엔드 저장소에 과부하를 일으켜 OpenAI API 오류가 늘었다

   OpenAI2024

   증상

   2024년 8월 16일 태평양 시간 오전 11시 38분부터 오후 1시 16분까지 OpenAI 기본 API 의 안정성이 크게 떨어졌다. ChatGPT 대화의 성공률이 낮아졌고 로그인과 계정 생성도 영향을 받았다. 장애는 두 번에 걸쳐 일어났고, 각각 44분과 15분 동안 이어졌다.

   오류율 상승데이터베이스 과부하

   촉발

   예정된 유지 보수와 함께 OpenAI 의 사용자 요청을 받는 클러스터에서 인그레스를 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러애플리케이션 데이터베이스

   기여 요인

   단계적 배포 부재자동화 증폭

   후속 조치

   • 네트워크 컨트롤 플레인 회귀를 완화했고, 컨트롤 플레인을 재시작해도 클러스터의 데이터 플레인에 영향이 없음을 확인했다.
   • 서비스 시작 시간을 줄이고 초기화 쿼리를 없애는 소프트웨어 변경을 넣어, 저장 계층의 부담을 덜고 서비스 시작과 재시작을 빠르게 했다.
   • 네트워크 컨트롤 플레인이 클러스터의 트래픽 처리 능력에 주는 영향을 줄이는 설정 변경을 배포했다.
   • 중요한 시작 경로에서 비용이 큰 데이터베이스 쿼리를 뺐다.
   • 네트워크 컨트롤 플레인 관련 문제를 잡는 모니터링과 알림을 추가했다.
   • 인프라 변경에 단계적 롤아웃과 더 긴 관찰 기간을 도입해, 회귀를 최대한 일찍 잡고 영향을 받는 시스템과 사용자를 줄인다.
   • 서비스 시작 시간에 영향을 줄 수 있는 다른 느린 쿼리가 있는지 시스템을 점검한다.

   교훈

   짧은 연결 끊김이 긴 장애로 번진 것은 복구 자체가 무거웠기 때문이었다. 다시 뜨는 서비스들이 무거운 초기화 쿼리로 백엔드 저장소 하나에 과부하를 주었다. 시작 경로에서 비용이 큰 쿼리를 빼면 복구가 짧아진다. 인프라 변경을 단계적으로 내보내고 관찰 기간을 길게 두면 회귀가 잡히기 전에 영향을 받는 시스템 수를 줄일 수 있다.

   사례 보기
3. IL-0203 클러스터 시스템 업데이트 뒤 AWS Load Balancer Controller 가 실패해 새 파드가 ALB 에 등록되지 않았고, Honeycomb EU1 의 수집과 UI 가 11분 동안 멈췄다

   Honeycomb2024

   증상

   4월 9일 22:00:10 UTC 에 Honeycomb EU1 의 이벤트 수집과 웹 UI 가 갑자기 멈췄다. 두 서비스가 거의 같은 시각에 끊겼다. 22:08 UTC 에 상태 페이지에 EU1 인스턴스가 다운됐다는 공지가 올라왔다.

   서비스 중단오래된 엔드포인트 라우팅

   촉발

   그날 앞서 쿠버네티스 클러스터에 배포한 일상적인 시스템 업데이트가 AWS Load Balancer Controller 를 간헐적으로 실패하게 만들었고, 그 뒤 이어진 서비스 배포가 마지막 옛 파드를 내렸다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러클라우드 로드 밸런서

   기여 요인

   모니터링 사각지대스테이징 불일치늦게 드러난 변경

   감지

   상태 페이지 첫 공지는 장애 시작 8분 뒤인 22:08 UTC 에 올라왔고, EU1 인스턴스가 다운돼 조사 중이라는 내용이었다. AWS Load Balancer Controller 에는 알림이 없었다.

   조치

   • AWS Load Balancer Controller 를 재시작해 서비스를 되살렸다.
   • 재발을 막으려고 시스템 업데이트를 롤백했다.

   후속 조치

   • 재발을 막고 시스템 업데이트를 안전하게 다시 배포할 수 있도록 실패의 정확한 원인을 밝힌다.
   • AWS Load Balancer Controller 에 모니터링과 알림을 추가해, 실패하면 온콜 엔지니어가 바로 알고 배포를 미리 멈출 수 있게 한다.

   교훈

   AWS Load Balancer Controller 는 배포 때마다 새 파드를 ALB 에 등록하는 핵심 구성 요소였다. 이 컨트롤러가 실패해도 서비스는 바로 멈추지 않았고, 다음 배포에서 마지막 옛 파드가 내려갈 때 끊겼다. 개발 환경과 스테이징 환경에서 충분히 시험한 시스템 업데이트도 운영 클러스터의 다른 구성 요소와 부딪칠 수 있다.

   사례 보기
4. IL-0180 GKE 컨트롤 플레인이 1.22 에서 1.23 으로 자동 업그레이드되면서 v1beta1 API 를 쓰던 Istio 1.7.4 가 제대로 동작하지 않았다

   Sunwoo Park2023

   증상

   2023-05-18 20:01 에 Slack 알림이 왔고, 운영 GKE 클러스터의 Istio 가 제대로 동작하지 않았다.

   서비스 중단

   촉발

   2023-05-18 19:52 에 GKE 컨트롤 플레인이 1.22.17-gke.7500 에서 1.23.17-gke.1700 으로 자동 업그레이드됐다. 클러스터의 Istio 1.7.4 는 networking.k8s.io/v1beta1 과 admissionregistration.k8s.io/v1beta1 API 를 쓰고 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   IstioGKE 컨트롤 플레인어드미션 웹훅

   기여 요인

   미뤄 둔 업그레이드

   감지

   GKE 자동 업그레이드 9분 뒤인 20:01 에 Slack 알림이 왔다.

   조치

   • Istio 를 1.7.4 에서 1.13.3 으로 업그레이드해 GKE 1.23 과 호환되게 맞췄다.

   교훈

   Kubernetes, Istio 처럼 함께 쓰는 패키지는 버전 호환성 매트릭스를 GitHub 이나 문서에서 확인한다. 업그레이드는 운영 환경에 올리기 전에 테스트 환경에서 먼저 해 본다. ArgoCD 같은 자동화 도구로 배포와 버전을 관리한다. 운영 환경은 버전을 최소 6개월 유지하되 지원 종료 3개월 전에는 업그레이드한다. 업그레이드 전에는 항상 백업한다. 처음에는 Istio 지원 종료를 원인으로 봤지만, GKE 업그레이드 기록을 다시 보고 나서야 진짜 원인을 찾았다.

   사례 보기
5. IL-0060 쿠버네티스 1.24 업그레이드로 node-role.kubernetes.io/master 레이블이 사라지자 이 레이블에 기대던 Calico 라우트 리플렉터가 동작을 멈춰 레거시 클러스터의 네트워크가 모두 끊기고 Reddit 이 314분 동안 멈췄다

   Reddit2023

   증상

   2023년 3월 14일 19시 UTC 직후 엔지니어가 Old Reddit 이라 불리는 레거시 스택을 돌리는 클러스터의 업그레이드를 시작했다. 2분쯤은 괜찮아 보였지만 곧 사이트 전체가 갑자기 멈췄다. CDN 엣지의 상태 코드별 RPS 그래프가 이를 보여 주었다. 사용자는 오류 페이지나 글이 하나도 없는 홈페이지를 보았다.

   서비스 중단오류율 상승DNS 조회 실패모니터링 중단파드 ContainerCreating 정체컨트롤 플레인 지연

   촉발

   Reddit 에서 가장 중요한 클러스터 가운데 하나인 레거시 클러스터를 쿠버네티스 1.23 에서 1.24 로 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   Calico쿠버네티스 API 서버어드미션 웹훅etcd

   기여 요인

   코드로 관리되지 않는 설정스테이징 불일치미검증 백업모니터링 사각지대단일 장애점

   감지

   업그레이드를 시작하고 2분쯤 뒤 CDN 엣지의 상태 코드별 RPS 그래프에서 사이트가 멈춘 것이 보였다. 팀은 곧바로 장애를 선언했고 3분 안에 대응 인원이 통화에 모였다. 엣지 지표는 일부러 클러스터와 분리되어 있어 살아 있었지만, 클러스터 자체의 지표는 모두 사라졌다.

   조치

   • API 서버에서 타임아웃을 내던 Open Policy Agent 의 웹훅 설정을 지웠다.
   • 복원 뒤 어차피 쓸 수 없게 될 워커 노드를 모두 종료했다.
   • 컨트롤 플레인 노드 두 대를 종료하고, 남은 한 대의 구성 요소를 다운그레이드한 뒤 그 노드에 백업 데이터를 복원했다.
   • 단일 노드 컨트롤 플레인이 부하에 무너지지 않도록 클러스터 오토스케일러를 껐다.
   • 새 컨트롤 플레인 노드를 띄우고, 호스트명이 맞지 않던 TLS 인증서를 새로 만들어 노드들을 합류시켰다.
   • 트래픽을 1% 에서 시작해 5%, 10%, 20%, 35%, 55%, 80%, 100% 로 조금씩 늘렸다.
   • 트래픽이 돌아올 때 문제를 일으키지 않도록 손으로 멈춰 두었던 민감한 레거시 서비스를 조심스럽게 다시 켰다.

   후속 조치

   • 클러스터 구성을 코드로 관리해 모든 선택에 기록이 남게 하고, 코드로 만들 수 없는 것은 자세히 문서로 남긴다.
   • 클러스터마다 다른 맞춤형 구성을 걷어 내고 모든 클러스터의 구성 요소를 표준화한다.
   • 모든 클러스터를 최대한 같은 모습으로 유지하고 필요하면 다시 만들거나 복제할 수 있도록 클러스터 전체의 수명 주기를 관리하는 도구를 만든다.
   • 믿고 테스트에 쓸 수 있는 프리프로덕션 클러스터를 더 둔다.
   • 백업 복원 절차를 개선하고 클러스터 업그레이드를 안전하게 만든다.

   교훈

   쿠버네티스 버전과 구성 요소 업그레이드는 여전히 위험하다. 미리 테스트하고 검증해도 이번처럼 처음 보는 방식으로 깨질 수 있다. 쿠버네티스에는 공식 다운그레이드 절차가 없어, 롤백하는 방법은 백업에서 복원하는 것뿐이다. 복원 절차가 환경 변화를 따라가지 못하면 실제 장애 때 그 자리에서 고쳐 써야 하고, 복원을 결정하기까지 오래 망설이게 된다. 이번 복원은 결국 성공했지만 절차는 개선해야 한다. 코드로 남기지 않은 설정은 아는 사람이 떠나면 아무 기록도 남지 않는다. 라우트 리플렉터 설정이 어디에도 커밋되어 있지 않아 장애 중에 누구도 의심하지 못했다. 지표가 클러스터 안에서만 수집되면 클러스터가 망가질 때 함께 사라진다. 이번에는 로그 수집 에이전트가 영향을 받지 않아 원인을 추적할 수 있었다. 클러스터마다 다른 맞춤형 구성이 쌓이면 장애가 잦아진다. 직접 원인은 노드 레이블이었지만 근본 원인은 일관성 부족이었다.

   사례 보기

원인별1