사례5건

5건 중 1~5번째

1. IL-0405 AWS Load Balancer Controller 의 webhook 인증서가 만료돼 US·Canada 지역의 BSEE SaaS 인스턴스가 전부 멈췄다

   PortSwigger2026

   증상

   US 와 Canada 지역 고객이 BSEE SaaS 인스턴스의 Web UI 에 들어가지 못했고 스캔도 시작하지 못했다. 엔지니어는 고객이 지원 창구로 알려 온 뒤에야 장애를 알았다.

   서비스 중단TLS 인증서 오류

   촉발

   PortSwigger 는 2025년 11월 28일 AWS Load Balancer Controller 를 v1.14.1 에서 v1.16.0 으로 올렸다. v1.15.0 의 Helm 차트가 인증서를 관리하는 방식을 바꿨고, 이 업그레이드 뒤에 소유자가 사라진 webhook 용 TLS Secret 이 남았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅cert-managerHelm컨피그맵과 시크릿클라우드 로드 밸런서

   기여 요인

   늦게 드러난 변경모니터링 사각지대

   감지

   엔지니어는 고객이 지원 창구로 신고한 뒤에야 장애를 알았다. 신고는 2026년 1월 12일 09:52 UTC 에 들어왔고, 영향이 시작되고 23시간 52분이 지난 때였다.

   조치

   • US 와 Canada 클러스터에서 소유자가 사라진 aws-load-balancer-tls Secret 을 지웠다.
   • Helm 으로 AWS Load Balancer Controller 설정을 다시 배포했다.
   • 인증서가 새로 만들어졌는지, webhook 이 제대로 동작하는지 확인했다.

   후속 조치

   • 모든 클러스터에서 소유자인 Certificate 리소스가 사라진 Secret 을 찾아 정리한다.
   • SaaS 클러스터마다 외부 프로브가 애플리케이션에 접속할 수 있는지 확인하고, 접속하지 못하면 알림을 보내게 한다.

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

   사례 보기
3. IL-0513 쿠버네티스 노드 순차 재시작 중 Ingress 가 관리하는 ELB 의 HTTPS 리스너가 꺼져 PyPI 백엔드에 HTTPS 로 닿지 못했다

   Python Software Foundation2022

   증상

   2022-10-24 14:43 UTC 부터 15:03 UTC 까지 PyPI 백엔드에 HTTPS 로 접속할 수 없었다. CDN 이 페이지를 가져오지 못했고, uploads.pypi.org 로 올리기가 막혔으며, 옛 파일 리디렉션 서비스도 끊겼다.

   서비스 중단

   촉발

   업그레이드와 새 설정을 모든 노드에 나눠 주려고 쿠버네티스 클러스터의 모든 노드를 순차 재시작했다. 새 쿠버네티스 API 서버가 올라오면서 기존에 정의한 Ingress 설정을 다시 검증하고 갱신했다.

   원인

   설정 변경

   구성 요소

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

   기여 요인

   코드로 관리되지 않는 설정늦게 드러난 변경

   조치

   • PyPI 관리자들이 Ingress 설정을 새 ACM TLS 인증서를 가리키도록 고쳤다. 쿠버네티스가 Ingress 가 관리하는 ELB 에 HTTPS 리스너를 되살렸고 모든 서비스에 다시 접속할 수 있게 됐다.

   후속 조치

   • PyPI Ingress 설정에 필요한 ACM TLS 인증서의 호스트 이름을 AWS 콘솔에서 손으로 관리하지 않고 쿠버네티스 자원으로 관리할 방법을 찾는다.

   교훈

   자원을 모두 쿠버네티스 API 로 관리하면 원하는 상태와 실제 상태가 어긋나는 일이 줄고, 그런 어긋남이 다음 유지 보수 때 장애로 드러날 가능성도 줄어든다고 PSF 인프라 팀은 정리했다.

   사례 보기
4. IL-0177 다른 팀의 설정 배포로 공유 L7 HAProxy 가 재로드될 때마다 messaging-hub 의 웹소켓 연결이 한꺼번에 끊겼다.

   LINE Plus2022

   증상

   LINE 의 messaging-hub 는 일본 음식 배달 서비스 Demaecan 의 Merchant 앱과 Driver 앱에 웹소켓으로 메시지를 보낸다. 어느 날 최대 트래픽 시간이 아닌데도 웹소켓 연결 수 그래프가 순간적으로 크게 떨어졌다. 이 현상은 한 번으로 끝나지 않고 불규칙하게 계속 일어났다.

   연결 리셋데이터베이스 과부하간헐적 연결 실패지연 시간 증가

   촉발

   같은 L7 로드밸런서를 공유하는 다른 서비스 담당자가 자기 LB 설정을 배포하면 HAProxy 가 재로드됐다. hard-stop-after 로 정한 30분이 지나 이전 프로세스가 종료되면서 거기 붙어 있던 웹소켓 연결이 모두 끊겼다.

   원인

   설정 변경

   구성 요소

   HAProxy클라우드 로드 밸런서conntrack 테이블인그레스 컨트롤러

   기여 요인

   늦게 드러난 변경과도한 영향 범위재시도 폭주미검증 가정

   감지

   웹소켓 연결 수 그래프에서 최대 트래픽 시간이 아닌데도 연결 수가 순간적으로 뚝 떨어지는 것을 보고 알았다. Nginx 패킷 드롭은 네트워크 모니터링으로 원인을 찾았다.

   조치

   • Merchant 팀이 토큰 발급 API 를 따로 떼어 배포해 토큰 요청이 몰려도 다른 Merchant API 가 지연되지 않게 했다.
   • Nginx 를 늘리고 파드 안티 어피니티와 레이블 셀렉터로 Nginx 파드가 서로 다른 노드에 뜨게 해서 NF_CONNTRACK 테이블 포화로 생기던 패킷 드롭을 없앴다.
   • Ingress Nginx 의 proxy-read-timeout 과 proxy-send-timeout 을 300s 에서 3600s 로, LB timeout 도 3600s 로 올렸지만 웹소켓 드롭은 멈추지 않았다.
   • 공유하던 L7 LB 를 L4 LB 로 바꿔 웹소켓 드롭을 없앴다.

   교훈

   문제의 범위를 미리 단정해 스스로 제한하면 안 된다. 인프라 팀과 네트워크 팀이 문제없다고 답했다는 이유로 직접 다룰 수 있는 영역만 뒤지다가 공유 L7 LB 를 늦게 의심했다. LB 같은 기술 리소스를 다른 서비스와 공유하면 다른 팀의 배포가 내 서비스의 연결을 끊을 수 있다. Nginx 를 늘려 NF_CONNTRACK 부담을 나눌 때는 파드가 서로 다른 노드에 뜨게 해야 하고, 노드 수보다 많이 늘리면 Pending 상태로 남는 파드가 생긴다는 점도 알아야 한다.

   사례 보기
5. IL-0106 잘못된 IngressRoute 매니페스트가 Traefik v2 버그를 건드려 Traefik 파드가 모두 재시작된 뒤 Kubernetes 의 모든 서비스가 404 를 냈다

   DFDS2021

   증상

   2021-09-06 08:00 UTC 에 Kubernetes 의 모든 서비스가 404 를 내기 시작했다. 30분 전인 07:30 에는 노드를 자동으로 교체하는 롤오버가 시작됐다.

   서비스 중단오류율 상승프로브 실패

   촉발

   2021-09-01 11:34 UTC 에 형식이 잘못된 IngressRoute 가 Kubernetes 에 적용됐다. 이 매니페스트는 2.5 미만 Traefik v2 의 버그를 건드렸지만, 버그는 Traefik v2 파드가 모두 재시작된 뒤에야 드러났다. 2021-09-06 07:30 에 자동 노드 롤오버가 시작됐고, 08:00 에 모든 서비스가 404 를 냈다.

   원인

   소프트웨어 결함

   구성 요소

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

   기여 요인

   늦게 드러난 변경설정 테스트 부재과도한 영향 범위

   감지

   08:00 UTC 에 모든 서비스가 404 를 내기 시작했고 08:05 에 원인 조사를 시작했다. 감지까지 5분이 걸렸다.

   조치

   • ALB 헬스체크 경로를 바꿔 08:15 에 ALB 대상을 healthy 로 되돌렸지만 404 는 멈추지 않았다.
   • 08:50 에 주 인그레스 컨트롤러를 Traefik v1 으로 되돌리기로 하고, 09:00 에 손으로 롤백했다.
   • 09:10 에 잘못된 IngressRoute 를 손으로 지워 근본 원인과 Traefik v2 버그를 확인했다.
   • 09:20 에 바꾼 내용을 업스트림에도 반영했다.

   후속 조치

   • 버그가 고쳐진 Traefik v2.5 로 올리고 버그가 사라졌는지 확인한다.
   • Traefik v2 헬스체크 경로를 더 믿을 만한 경로로 바꾼다.
   • 인그레스 컨트롤러를 클러스터 바깥에서 확인하는 liveness 점검을 둔다.
   • 워크로드를 나눠 장애가 번지는 범위를 줄이는 방안을 검토한다.
   • Traefik v2 API 에서 짧은 시간에 많은 변경이 일어나는지 모니터링하는 방법을 알아본다.
   • 노드 롤오버 중과 롤오버 뒤에 스모크 테스트를 돌리는 방법을 알아본다.

   교훈

   Traefik v2 는 오류를 드러내지 않고 실패해서 조사를 ALB 쪽으로 잘못 이끌었다. 공식 API 스키마도 잘못된 매니페스트 적용을 막지 못했다. 팀은 대응 과정에서 장애 관리자를 정했다면 도움이 됐을 것으로 봤다. 그리고 워룸 회의를 녹화하고, 대응에 참여하지 않는 사람은 글로만 제안하고, 일지를 남기자고 정리했다. 대응 초반에 각자의 생각과 직감을 짧게 나누는 시간도 갖자고 했다.

   사례 보기

원인별3