사례18건

18건 중 1~5번째

1. IL-0438 CloudFront VPC Origins 장애로 Builder Work 가 504 오류를 내며 거의 모든 접속이 막혔다

   ANDPAD2026

   증상

   2026년 7월 16일 17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 CloudFront 에서 VPC Origins 연결을 쓰는 배포에 5xx 오류가 늘기 시작했다. CloudFront 자체는 정상으로 돌았지만 VPC Origins 기능에만 장애가 나서 504 Gateway Time-out 이 잇따랐다.

   서비스 중단오류율 상승

   촉발

   CloudFront 의 VPC Origins 연결을 관리하는 AWS 내부 공유 서브시스템에서 용량 제약이 생겼다.

   원인

   클라우드 제공자 장애

   구성 요소

   CDN 과 엣지 네트워크클라우드 로드 밸런서인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   단일 장애점

   감지

   17시쯤 Datadog 이 알림을 울렸고, 거의 같은 때 VPC Origins 연결을 쓰는 CloudFront 배포에서 5xx 오류가 늘고 있는 것을 알았다.

   조치

   • CloudFront 의 오리진이 VPC Origins 하나뿐이었으므로, CloudFront 를 거치지 않고 Internet-facing ALB 로만 라우팅하도록 임시로 바꾸기로 했다.
   • VPC Origins 도입 때 지운 Internet-facing Ingress 를 다시 만들고, Argo Rollouts 의 Rollout 리소스에 묶은 뒤 promote 했다.
   • 기존 WAF 는 us-east-1 글로벌 범위의 CloudFront 용이라 ALB 에 연결할 수 없어, 보안 팀과 함께 ALB 용 리전 WAF 를 따로 만들었다.
   • ACM 인증서, WAF, 액세스 로그 설정을 묶은 IngressClass 를 새로 만들었다.
   • 일반 트래픽용, Cognito 인증과 VPN 접근 제한을 건 관리 화면용, 리다이렉트용 Ingress 를 더해 라우팅을 되살렸다.

   후속 조치

   • VPC Origins 와 CloudFront 구성으로 돌아가면서, 다음 장애에 대비해 Internet-facing 으로 바꾸는 수단을 코드에 넣어 둔다.
   • 복구 때 만든 Internet-facing ALB 를 남기고, AWS Load Balancer Controller 의 IngressClassParams spec.inboundCIDRs 로 Security Group 인바운드를 사내 CIDR 과 제한 공개용 CIDR 에만 허용한다. values.yaml 의 securityGroupInboundCidrs 를 주석 처리하면 inboundCIDRs 가 빠져 0.0.0.0/0 으로 열리게 했다.
   • Terraform 으로 관리하는 Route53 A 레코드를 CloudFront 로 되돌렸다. ALB 로 가는 별칭 설정 route53_alias_name 은 주석 처리한 채 코드에 남겨, 주석을 풀고 apply 하면 Route53 을 ALB 로 돌릴 수 있게 했다.

   교훈

   VPC Origins 는 ALB 를 Private 서브넷에 두어 인터넷에서 오는 직접 접근을 막고 통신 경로를 단순하게 해 운영 부담을 줄인다. 그 대신 CloudFront 와 오리진 사이의 통신이 AWS 가 관리하는 공유 서브시스템을 거치므로, 그 서브시스템이 망가지면 CloudFront 전체가 정상이어도 통신이 끊긴다. ANDPAD 는 VPC Origins 의 이점을 버리지 않고 장애 때 쓸 우회 경로를 미리 마련해, 다음에 같은 위험이 드러날 때의 대응 비용을 낮추기로 했다. 상시 켜 둔 ALB 의 유지 비용은 치르지만, 이번에 Ingress 재생성과 Rollout 연결에 시간이 걸린 것을 반성해 주석만 풀면 전환할 수 있게 했다.

   사례 보기
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-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 클러스터마다 외부 프로브가 애플리케이션에 접속할 수 있는지 확인하고, 접속하지 못하면 알림을 보내게 한다.

   사례 보기
4. IL-0188 EKS 롤링 업데이트 때 Kubernetes 는 새 파드가 Ready 가 되자마자 옛 파드를 지웠지만 ALB 는 새 파드를 아직 healthy 로 보지 않아, 배포마다 약 30초 동안 502 가 났다.

   Yonghyun Kim2025

   증상

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지가 왔다. 모든 파드는 Ready 였고 Datadog 도 초록불이었지만, 사용자는 계속 오류 화면을 보고 있었다.

   오류율 상승서비스 중단

   촉발

   롤링 업데이트에서 새 파드가 readinessProbe 를 통과해 Ready 가 되자 Kubernetes 가 곧바로 옛 파드를 지웠다. 그때 ALB 는 새 파드 IP 를 대상 그룹에 막 등록해 initial 상태로 헬스 체크를 하고 있었다.

   원인

   배포 결함

   구성 요소

   클라우드 로드 밸런서인그레스 컨트롤러파드 종료 처리

   기여 요인

   미검증 가정기본 설정 방치모니터링 사각지대

   감지

   새벽 3시에 "배포는 성공했는데, 서비스는 죽었다"는 Slack 메시지로 알았다. 파드 상태와 Datadog 대시보드는 모두 정상이었고, 장애는 사용자가 보는 화면에만 나타났다.

   조치

   • 네임스페이스에 elbv2.k8s.aws/pod-readiness-gate-inject=enabled 레이블을 붙였다. AWS Load Balancer Controller 의 웹훅이 파드에 ReadinessGate 를 넣었다. 새 파드는 ALB 대상이 healthy 가 된 뒤에야 Ready 가 됐고, 그제야 옛 파드가 지워졌다.

   교훈

   Kubernetes 의 Ready 와 ALB 의 healthy 는 서로 다른 시점에 정해지므로, 둘을 잇는 장치가 없으면 롤링 업데이트 때 502 가 날 수 있다. 파드 상태와 대시보드가 모두 정상이어도 사용자는 오류를 볼 수 있다. terminationGracePeriodSeconds 를 늘려 시간을 버는 방식은 배포만 느리게 하고 새 파드가 뜰 때의 공백은 막지 못한다. ReadinessGate 는 ALB 대상 유형이 ip 일 때만 의미가 있고, instance 모드에서는 노드가 대상이라 쓸 수 없다. ReadinessGate 를 쓰면 파드가 Ready 가 되기까지 30초에서 40초가 더 걸리므로 급한 스케일 아웃에 대비해 레플리카나 HPA 를 넉넉히 잡는다. 웹훅의 failurePolicy 를 Ignore 로 두면 컨트롤러가 죽어도 배포가 막히지 않는다.

   사례 보기
5. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기

원인별7