사례5건

5건 중 1~5번째

1. IL-0098 ingress-nginx 에서 nginx-ingress 로 옮긴 뒤 같은 호스트를 나눠 쓰는 인그레스들의 동작이 바뀌어 cert-manager 가 새 TLS 인증서를 받지 못했다.

   2i2c2026

   증상

   새 허브를 띄우려 했는데 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 얼마 전 다른 허브에서도 같은 일이 있었다.

   요청 오라우팅배포 실패

   촉발

   nginx-ingress 로 옮긴 클러스터에서 새 TLS 인증서가 필요한 허브를 새로 배포했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러cert-manager

   기여 요인

   늦게 드러난 변경

   감지

   새 허브를 띄우다 인그레스가 새 TLS 인증서를 받지 못해 실패했다. 전날 다른 허브에서도 같은 현상을 봤기 때문에 엔지니어가 웹사이트에서 장애를 직접 선언했다.

   조치

   • TLS 가 필요한 인그레스 객체에 어노테이션을 달아 cert-manager 가 edit-in-place 방식으로 인그레스를 고칠 수 있게 했다.

   후속 조치

   • 후속 작업을 2i2c-org/infrastructure 이슈 8016 으로 남겼다.
   • 후속 작업을 2i2c-org/infrastructure 이슈 3278 로 남겼다.

   교훈

   인그레스 컨트롤러를 바꾸면 같은 호스트를 나눠 쓰는 인그레스들 사이의 우선순위가 바뀔 수 있고, cert-manager 의 ACME 임시 인그레스처럼 그 동작에 기대는 구성 요소가 깨진다. 이 문제는 새 인증서가 필요한 배포에서 드러났다. 2i2c 는 내부 클러스터를 시험하면서 이 원인을 이미 알고 있었고, cert-manager 설정을 고치는 일도 빨랐다.

   사례 보기
2. 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 헤더 같은 오탐은 운영에서야 드러난다. 시험에서 찾은 문제라도 쿠키처럼 사용자 브라우저에 남는 값이면 대응이 효과를 내기까지 시간이 걸린다. 팀은 롤백으로 먼저 영향을 끊고 예외를 준비한 뒤 다시 배포해 같은 날 업그레이드를 마쳤다.

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

   OpenAI2024

   증상

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

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

   촉발

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

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

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

   후속 조치

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

   교훈

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

   사례 보기
4. 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 에 등록하는 핵심 구성 요소였다. 이 컨트롤러가 실패해도 서비스는 바로 멈추지 않았고, 다음 배포에서 마지막 옛 파드가 내려갈 때 끊겼다. 개발 환경과 스테이징 환경에서 충분히 시험한 시스템 업데이트도 운영 클러스터의 다른 구성 요소와 부딪칠 수 있다.

   사례 보기
5. IL-0090 ModSec 인그레스 컨트롤러 모듈을 v3.33.0 으로 올린 뒤 검증 웹훅 호출이 x509 인증서 오류로 실패해, 모든 인그레스 생성과 변경이 막히고 사용자 애플리케이션 배포가 멈췄다.

   UK Ministry of Justice2021

   증상

   2021년 6월 9일 13:15 에 한 사용자가 #ask-cloud-platform 채널에 UAT 애플리케이션을 배포하다가 오류가 났다고 알렸다.

   배포 실패

   촉발

   ModSec 인그레스 컨트롤러 모듈을 v3.33.0 으로 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   어드미션 웹훅인그레스 컨트롤러

   기여 요인

   스테이징 불일치

   감지

   13:15 에 한 사용자가 #ask-cloud-platform 채널에 UAT 애플리케이션 배포 오류를 올리면서 장애가 드러났다. 장애 선언은 13:54 였다.

   조치

   • ModSec 인그레스 컨트롤러 모듈을 v0.0.7 로 롤백했다.

   후속 조치

   • 이 문제가 테스트 클러스터에서 왜 걸러지지 않았는지 알아본다. 문제를 재현해 보고 테스트를 하나 더 둘지 판단한다. 티켓 #2972.
   • 스모크 테스트에 Alertmanager 의 알림을 확인하는 테스트를 더한다. 티켓 #2973.
   • ModSec 컨트롤러를 쓰는 helloworld 앱을 두고, 스모크 테스트로 트래픽이 실제로 흐르는지 확인한다. 티켓 #2974.
   • 새 버전의 ModSec 모듈이 EKS 의 live-1 과 live 에서 동작하게 만든다. 지금은 옛 버전과 새 버전 모두 live 에서 동작하지 않는다. 티켓 #2975.

   사례 보기

원인별1