사례5건

5건 중 1~5번째

1. IL-0092 ingress-nginx 를 1.12.0 에서 1.14.3 으로 올리자 새 ModSecurity 와 OWASP Core Rule Set 이 정상 요청을 오탐으로 막아 HMPPS 사용자가 인증하지 못했다.

   UK Ministry of Justice2026

   증상

   2026년 3월 30일 08:56 에 Cloud Platform 팀은 #hmpps-auth-audit-registers 슬랙 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤다. 같은 날 07:11 에 운영 인그레스 세 개에 새 ingress-nginx 를 배포하기 시작한 뒤였다.

   오류율 상승서비스 중단

   촉발

   Cloud Platform 팀이 ingress-nginx 1.14.3 을 운영 인그레스 세 개에 배포했다. 이 버전에는 새 ModSecurity WAF 와 새 OWASP Core Rule Set 이 들어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   스테이징 불일치

   감지

   Cloud Platform 팀은 HMPPS Auth 팀 슬랙 채널의 메시지로 장애를 알았다. 팀은 08:56 에 #hmpps-auth-audit-registers 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤고, 09:14 에 장애를 선언했다.

   조치

   • 09:14 에 ingress-nginx 롤백을 시작해 09:43 에 마쳤다.
   • HMPPS 개발자들이 HMPPS Auth 로 가는 트래픽을 막는 규칙을 자기 ModSecurity 설정에서 예외 처리했다.
   • Cloud Platform 팀이 posthog 쿠키가 걸리는 규칙을 플랫폼의 모든 서비스에서 임시로 예외 처리했다.
   • 두 예외를 둔 상태로 새 ingress-nginx 를 다시 배포해 14:00 에 마쳤다.

   후속 조치

   • posthog 쿠키의 범위를 줄여 모든 *.justice.gov.uk 서비스로 가는 요청에 실리지 않게 했다. 다만 이 변경과 CRS 규칙 배포 사이가 짧아 사용자 브라우저의 쿠키가 만료되거나 바뀔 시간이 모자랐다.
   • posthog 쿠키가 충분히 많은 사용자 브라우저에서 만료되면 플랫폼 전체에 넣은 임시 예외를 없앤다.
   • 서비스 팀들에게 개발과 테스트 워크로드에 비운영 인그레스 컨트롤러를 쓰라고 다시 강조해, 이후 ModSecurity 와 CRS 업데이트에서 생길 문제를 미리 찾게 한다.
   • Cloud Platform 3.0 에서는 운영과 비운영 워크로드를 다른 클러스터로 나눠 비운영 워크로드가 반드시 비운영 인그레스를 거치게 한다.

   교훈

   WAF 규칙 세트 업데이트는 보안을 높이려는 변경이어도 정상 트래픽을 막을 수 있다. 베타 인그레스와 비운영 배포로 시험 기회를 줬어도 서비스 팀들이 개발과 테스트에 비운영 인그레스를 실제로 쓰지 않으면 Expect 헤더 같은 오탐은 운영에서야 드러난다. 시험에서 찾은 문제라도 쿠키처럼 사용자 브라우저에 남는 값이면 대응이 효과를 내기까지 시간이 걸린다. 팀은 롤백으로 먼저 영향을 끊고 예외를 준비한 뒤 다시 배포해 같은 날 업그레이드를 마쳤다.

   사례 보기
2. IL-0120 클라우드 GPU 서버의 정기 OS 업데이트가 systemd-networkd 를 재시작해 자체 네트워크 에이전트와 충돌했고, 많은 GPU 노드의 라우트가 모두 지워져 ChatGPT 와 API 의 오류율이 크게 올랐다.

   OpenAI2025

   증상

   6월 9일 오후 11시 36분 PDT 에 여러 서비스에서 동시에 알림이 울렸다. 인프라가 네트워크 연결을 잃기 시작했고, 상황은 바로 엔지니어링 팀에 에스컬레이션됐다.

   오류율 상승GPU 인식 불가

   촉발

   매일 예약된 호스트 OS 업데이트가 영향받은 노드에서 네트워크 관리 서비스인 systemd-networkd 를 의도치 않게 재시작했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   systemd-networkd노드 운영체제 이미지

   기여 요인

   단계적 배포 부재디버그 접근 제한

   감지

   장애가 시작된 6월 9일 오후 11시 36분 PDT 에 인프라가 네트워크를 잃기 시작하면서 여러 서비스의 알림이 바로 울렸고, 상황은 즉시 엔지니어링 팀에 에스컬레이션됐다.

   조치

   • 6월 10일 오전 2시부터 영향받은 GPU VM 을 대규모로 다시 이미징했다.
   • 6월 10일 오전 6시 49분에 복구 자동화를 배포해 아직 영향받은 상태인 나머지 노드를 재시작했다.
   • 백그라운드에서 도는 업데이트를 멈췄다.

   후속 조치

   • GPU VM 의 매일 자동 업데이트를 끄고, 업데이트는 직접 정한 일정에 맞춰서만 하도록 바꿨다.
   • systemd-networkd 와 자체 네트워크 서비스가 충돌하지 않도록 시스템 설정을 고쳤다.
   • 전체 VM 설정을 감사해 비슷한 위험을 찾아 줄인다.
   • GPU VM 과 클러스터 같은 핵심 인프라의 복구 속도를 높이는 작업에 우선순위를 둔다.
   • 대응 능력을 높이려고 재해 복구 훈련을 정기적으로 계획한다.

   교훈

   호스트 OS 의 자동 업데이트가 네트워크 관리 서비스를 재시작하면, 같은 노드에서 라우트를 관리하는 다른 에이전트와 충돌해 노드 전체가 네트워크를 잃을 수 있다. 매일 도는 업데이트는 모든 노드에 거의 같은 시각에 적용된다. 네트워크가 끊긴 노드를 빠르게 되살릴 비상 도구가 없으면 노드를 다시 이미징할 수밖에 없고 복구가 길어진다.

   사례 보기
3. 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 의 성능 저하 신고를 조사 중이라는 내용이었다.

   조치

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

   후속 조치

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

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

   OpenAI2024

   증상

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

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

   촉발

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

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

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

   후속 조치

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

   교훈

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

   사례 보기
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