사례96건

96건 중 4~8번째

1. IL-0512 xPRO 의 쿠버네티스 APISIX 오리진 인증서가 갱신되지 못하고 만료되어 xpro.mit.edu 가 한 시간 동안 503 을 냈다

   MIT Open Learning2026sev1

   증상

   2026-06-03 오후 3시 38분 EDT 에 xPRO 운영 CMS 와 xPRO 본 애플리케이션이 503 을 낸다는 알림이 함께 울렸다. 공개 사이트 https://xpro.mit.edu 에 고객이 제대로 접속하지 못했다.

   서비스 중단TLS 인증서 오류

   촉발

   cert-manager 가 2026-05-04 에 xpro-web.odl.mit.edu 인증서의 갱신 구간에 들어가 DNS-01 검증을 시작했다. 이 검증이 Fastly 가 만든 _acme-challenge.xpro-web.odl.mit.edu CNAME 과 부딪혀 끝나지 못했고, 기존 오리진 인증서가 2026-06-03 오후 3시 29분 EDT 에 만료됐다.

   원인

   설정 변경

   구성 요소

   cert-managerCDN 과 엣지 네트워크DNS 서버와 레코드

   기여 요인

   설정 테스트 부재모니터링 사각지대늦게 드러난 변경

   감지

   오후 3시 38분 EDT 에 xPRO 운영 CMS 와 xPRO 본 사이트가 503 을 낸다는 알림이 울렸다. 인증서가 만료된 지 9분 뒤였다.

   조치

   • 오래된 cert-manager 자원을 지우고 다시 만들어 cert-manager 가 백엔드 오리진의 새 인증서를 발급하게 했다. 이것으로 서비스가 돌아왔다.

   후속 조치

   • OpenEdX 가 아닌 xPRO 의 Fastly TLS 구독에서 백엔드 오리진 도메인을 뺐다.
   • src/ol_infrastructure/applications/xpro 의 Production 스택에 Pulumi 변경을 배포했다.
   • Fastly 의 검증 CNAME 을 뺀 뒤, xpro 네임스페이스에 있는 OpenEdX 가 아닌 xPRO 인증서를 cert-manager 로 직접 갱신하거나 cert-manager 가 저절로 갱신하게 했다.
   • cert-manager 가 관리하는 오리진 도메인이 Fastly TLS 구독에 들어가지 못하게 막는 테스트나 정책 검사를 넣는 방안을 검토한다.
   • cert-manager 의 CertificateRequest 와 Order 가 실패하면 더 일찍 알림을 보내, 인증서가 만료되기 전에 오래된 ACME 실패를 찾는 방안을 검토한다.

   교훈

   이 장애는 처음에 cert-manager 의 ACME 갱신 실패로 이해됐다. 그 이해는 맞았지만 모자랐고, 빠진 진단은 Fastly 가 cert-manager 의 몫인 백엔드 오리진 도메인의 검증까지 관리하도록 설정돼 있었다는 점이었다. 갱신 실패를 일찍 잡지 못한 것은 cert-manager 가 관리하는 백엔드 오리진 도메인이 Fastly TLS 구독에 들어가면 안 된다는 것을 검사하는 장치나 테스트가 없었기 때문이다. 팀은 TLS 인증서와 DNS 검증 레코드를 누가 맡는지 경계를 분명히 정하고 그 경계를 지키는 장치를 둬야 한다고 정리했다. 특히 TLS 자동화를 설정할 때 Fastly 의 공개 프런트엔드 도메인과 쿠버네티스 APISIX 백엔드 오리진 도메인을 바꿔 써도 되는 같은 서비스 도메인으로 다루면 안 된다.

   사례 보기
2. IL-0237 us-southcarolina 리전에서 Lucidworks AI 의 호스팅 LLM 이 약 1시간 반 동안 500 과 429 오류를 내며 멈췄다

   Lucidworks2026sev1

   증상

   2026-05-28 16:18 UTC 부터 us-southcarolina 리전에서 Lucidworks AI 가 호스팅하는 LLM 인 llama-3-8b-instruct, llama-3v2-3b-instruct, phi-4-multimodal-instruct 에 보낸 질의가 500 이나 429 오류로 실패했다. 검색, 임베딩 모델, Lucidworks Platform UI, passthrough LLM 호출은 정상이었다.

   서비스 중단파드 축출이미지 풀 실패

   촉발

   us-southcarolina 리전 클러스터의 정기 쿠버네티스 패치 업그레이드가 노드 풀을 차례로 교체했다. surge 방식의 노드 풀 업그레이드는 파드가 옛 노드에서 쫓겨나기만 하면 다음 노드로 넘어갔다. 그래서 Ray Serve 의 head 파드와 worker 파드가 새 노드에서 뜨기 전에 모두 쫓겨났다.

   원인

   배포 결함

   구성 요소

   노드 풀모델 추론 서버

   기여 요인

   단계적 배포 부재장애 중첩

   조치

   • 상태가 나빠 컨테이너 이미지를 받지 못하던 교체 head 노드를 손으로 지웠다.
   • 교체 노드에서 LLM 이미지 받기가 끝나기를 기다렸고, 모든 호스팅 모델이 질의에 응답하는 것을 확인했다.
   • 필요한 LLM 이미지가 든 새 노드를 띄우고 Lucidworks AI 트래픽을 그 노드로 돌렸다. 예측 엔드포인트의 200 응답으로 안정을 확인했다.

   후속 조치

   • LLM 워크로드를 돌리는 클러스터의 쿠버네티스 업그레이드를 순서대로 진행해, 한 노드 풀이 완전히 정상이 된 뒤에 다음 노드 풀을 올리게 한다.
   • 큰 ML 모델 이미지를 받는 데 오래 걸리지 않도록 이미지를 노드에 미리 올려 두는 방법을 조사한다. 후보는 디스크 이미지에 컨테이너 이미지를 미리 넣어 두는 방법과 이미지 스트리밍이다.
   • 비정상적으로 느린 Docker 이미지 받기를 조사하도록 클라우드 사업자에게 지원 티켓을 연다.
   • 진행 중인 배포와 겹치지 않도록 쿠버네티스 유지 보수 시간을 LLM 서비스 담당자와 맞추는 알림 절차를 만든다.
   • Ray 가 새 배포와 옛 배포를 스스로 정리하기를 기다리지 않고 Lucidworks Engineering 이 blue 나 green 으로 강제 전환할 수 있도록 Ray 클러스터 도구를 개선한다.

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

   사례 보기
4. IL-0499 세션 서버가 대량으로 내려간 뒤 음성 통화 라우팅 서비스가 과부하로 멈춰 음성·영상 통화가 세 시간 넘게 연결되지 않았다

   Discord2026

   증상

   2026년 3월 25일 12:13 PDT부터 15:30 PDT까지 Discord 의 음성·영상 기능이 크게 망가졌다. 사용자 대부분이 통화를 시작하거나 참여하지 못했고, 통화 상태에는 “Awaiting Endpoint” 메시지가 떴다.

   서비스 중단

   촉발

   Elixir 서비스를 쿠버네티스로 옮기던 중, 주말 CPU 사용률을 낮추려고 sessions 서비스 파드의 CPU 와 메모리를 늘리고 파드 수를 그만큼 줄이는 변경을 배포했다. 레플리카 수가 줄자 쿠버네티스가 첫 번째 존의 파드 50% 를 종료했고, 진행 중인 다른 작업을 기다리는 안전 검사 때문에 핸드오프가 시작되기 전에 종료 유예 시간이 끝났다.

   원인

   설정 변경

   구성 요소

   파드 종료 처리코디네이션 키-값 저장소데이터베이스 프록시와 커넥션 풀러

   기여 요인

   재시도 폭주한계 미인지

   조치

   • 13:43 PDT까지 calls, streams, guilds 서비스에 낮은 syncer 생성 제한을 넣고 voice syncers 클러스터를 다시 재시작했다. 막히는 supervisor 가 gun supervisor 로 바뀌면서 인스턴스들이 etcd 등록을 유지했고 일부 syncer 의 RPC 를 SFU 로 보냈다.
   • 인스턴스를 골라 하나씩 다시 재시작했고, 14:03에 재시작한 인스턴스 2-3 처럼 일부 인스턴스가 완전히 회복했다.
   • 인스턴스 15대를 추가로 올려 voice syncers 클러스터의 용량을 두 배로 늘렸다. 새 인스턴스들은 메일박스 대기열 문제 없이 syncer 를 받았고, 인스턴스당 syncer 수가 절반이 됐다.
   • 14:26에 마지막으로 막혀 있던 인스턴스를 재시작해 두 배로 늘어난 클러스터가 완전히 정상이 됐다.

   후속 조치

   • Elixir 워크로드용 validating admission webhook 을 쿠버네티스 클러스터에 넣어, 파드가 프로세스를 다 넘기기 전에는 워크로드를 줄이는 업데이트를 거부한다.
   • 부하 테스트 뒤 Holster.Pool 의 supervisor 를 PartitionSupervisor 로 바꿔, 연결 풀 요청을 독립된 여러 supervisor 에 나누고 나가는 연결을 동시에 만들거나 꺼낼 수 있게 했다.
   • gun 연결 프로세스의 생명주기 관리를 그 프로세스를 만드는 Holster.Pool 로 옮겨 gun 연결 supervisor 를 아예 쓰지 않게 했다.
   • voice syncers 를 호출하는 상위 서비스의 속도 제한을 다시 조정해 더 정확히 걸리게 했다. 필요하면 로드 셰딩 도구로 이 제한을 강제로 적용해 voice syncer 를 다시 만들게 할 수도 있다.
   • voice syncers 의 엔드포인트 선택에 새 속도 제한을 넣고 조정해, 나가는 연결 생성을 제한하는 수단을 하나 더 뒀다.
   • HTTP 연결 풀링 메일박스에 감시를 더해 언제 문제가 되고 언제 아닌지 더 분명히 알 수 있게 했다.
   • 서비스 디스커버리 등록과 voice syncer 에서 SFU 로 가는 RPC 트래픽의 계측과 로그를 전부 검토하고 넓혔다.
   • 메일박스 상태 합계 같은 간접 지표 대신, 모든 서비스에서 가장 중요한 프로세스를 직접 감시하도록 넓혀 간다.
   • 더 많은 워크로드를 쿠버네티스로 옮겨, VM 을 손으로 준비하는 대신 명령 하나로 파드를 늘릴 수 있게 한다.
   • A/V 인프라의 컨트롤 플레인 서비스를 여러 리전에 수평 확장해 신뢰성과 리전 장애 내성을 얻고, 나가는 연결 급증을 전 세계에 고르게 흩는다.

   교훈

   충분히 큰 트래픽 급증은 시스템 어딘가의 병목을 찾아낸다. 이전의 큰 부하 장애에서는 여러 ScyllaDB 데이터베이스가 복구를 막았지만, 이번에는 데이터베이스가 잘 버텼고 병목이 음성 서비스로 옮겨 갔다. 용량 한계를 만나면 공급을 늘리거나 수요를 줄이는 두 길이 있고, Discord 는 장애 대응과 사후 조치를 정할 때 이 질문을 분명히 던진다. 장애 중에는 쓸 수 있는 도구를 알아야 한다. Elixir 와 BEAM 가상 머신에서는 어떤 프로세스의 상태든 꺼내 볼 수 있고 핫패치로 관측을 더할 수도 있다. 분산 시스템에서는 장애 모드를 따져야 한다. Elixir 프로세스는 메시지를 하나씩 처리하므로 바쁜 프로세스의 핵심 루프가 느려지면 서비스와 사용자 경험이 함께 나빠진다. Discord 는 사후 검토에서 장애를 어떻게 피할지뿐 아니라 일어난 뒤 어떻게 더 빨리 풀지도 물었고, 복구 시간을 줄이면 관계없는 장애에서도 더 빨리 회복할 수 있다고 봤다.

   사례 보기
5. IL-0350 TXL 클러스터 한 곳의 호스트 네트워크가 끊기고 프로비저닝 대기열이 밀려 여러 서비스가 오래 나빠졌다

   IONOS Cloud2026

   증상

   2026-03-03 11:36 UTC 에 상태 페이지가 TXL 의 모니터링 알림을 조사하고 있다고 알렸다. 정비 중이던 클러스터 한 곳의 호스트가 연결을 잃었고, 고객은 간헐적인 네트워크 서비스 저하나 중단을 겪었다.

   네트워크 도달 불가링크 플래핑서비스 중단

   촉발

   TXL 데이터 센터 클러스터의 고장 난 스위치를 바꾸는 정비로 두 토폴로지 가운데 Topology 2 를 계획대로 껐다. 그동안 남은 Topology 1 에서 스위치 하나의 링크 흔들림이 패브릭 resweep 을 일으켰다.

   원인

   용량 한계

   구성 요소

   InfiniBand 패브릭네트워크 컨트롤 플레인BGP 라우팅NIC·케이블·스위치 포트 링크모델 허브데이터베이스

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   IONOS Cloud 는 TXL 에서 울린 모니터링 알림으로 장애를 알아챘고, 11:36 UTC 에 상태 페이지에 이 알림을 조사하고 있다고 올렸다.

   조치

   • 문제가 난 컨트롤 플레인을 대기 장비로 전환했다.
   • 멈춘 게이트웨이를 재부팅했다.
   • 예정된 정비 상태에서 Topology 1 을 복구했다.
   • 작업이 밀린 클러스터의 프로비저닝을 잠시 멈췄다. 실행 중인 서비스는 영향이 없었지만 기존 자원의 변경은 다시 켤 때까지 처리되지 않았다.
   • 네트워크 연결이 나아지자 프로비저닝을 다시 켜고 작업 실행을 지켜봤다.
   • DCD 를 받치는 시스템들의 연결을 다시 세워 DCD 서비스를 되살렸다.

   후속 조치

   • 컨트롤 플레인 구성에서 failover 타이머를 덜 민감하게 바꾸고 무거운 sweep 작업을 줄여 전달 테이블의 부하를 낮췄다.
   • 멀티캐스트 그룹 가입 수를 줄여 전달 테이블의 부담을 더 덜었다.
   • 전달 테이블 사용률과 컨트롤 플레인 메모리를 계속 감시해 용량 한도에 닿기 전에 알림이 오게 했다.
   • 네트워크 관리와 데이터 플레인 트래픽이 자원을 다투지 않도록 컨트롤 플레인을 전용 고성능 서버로 옮긴다. 2025년 4분기에 시작했고 2026년 2분기 완료가 목표다.
   • IPv6 구성과 IPoIB 드라이버 설정을 깊이 감사한다. 2026년 2분기 완료가 목표다.
   • 스위치, 게이트웨이, 드라이버를 포함한 인터커넥트 패브릭을 현대화해 복원력과 성능을 높인다. 2026년 3분기 완료가 목표다.
   • 주요 Cloud API 를 잠시 쓸 수 없어도 핵심 신원 서비스가 동작하도록 IAM 정비 절차를 강화했다.
   • IAM 을 전용 플랫폼으로 옮기는 작업을 앞당겨 IAM 이 일반 Managed Kubernetes 클러스터에 기대지 않게 한다. 목표 시점은 2026년 3분기다.
   • DBaaS 와 Managed Kubernetes 에 전용 프로비저닝 공급자를 두어 자가 치유 같은 변경 중에 서비스가 끊기는 일을 줄인다. 목표 시점은 2026년 3분기다.
   • 자가 치유 서비스 때문에 과부하가 나거나 대기열이 끝없이 쌓이지 않도록 프로비저닝 엔진에 자동 서킷 브레이커를 넣는다. 목표 시점은 2026년 1분기다.
   • 프로비저닝 대기열에서 작업 실행과 우선순위를 더 잘 보고 다룰 수 있도록 QoS 를 개선한다.
   • 서비스 사이의 파급을 줄이도록 프로비저닝 대기열의 결합을 푸는 구조 변경을 한다.

   교훈

   IONOS Cloud 는 서비스들이 프로비저닝 대기열로 서로 얽혀 있던 점이 서비스 저하를 길게 만든 핵심 요인이었다고 봤다. 앞으로는 서비스마다 견고하게 만드는 것과 함께 프로비저닝 대기열의 결합을 풀어 이번과 같은 파급을 줄이겠다고 했다. 서비스 사이의 의존도 찾아 풀어서 앞으로의 장애가 미치는 범위를 줄이겠다고 했다.

   사례 보기

원인별11