사례5건

5건 중 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-0170 설날 이벤트 트래픽이 평소의 3배를 넘자 Istio ingressGateway 가 있는 EKS 노드의 nf_conntrack 테이블이 가득 차 패킷이 버려졌고, 웹과 앱 서비스 전체가 멈췄다.

   Backpackr2025

   증상

   2024년 1월 설날 이벤트 중에 개발자 한 명이 Slack 에 장애가 의심된다고 알렸다. 여러 사람이 상황을 확인하는 사이에 웹과 앱 서비스 전체가 멈췄고, 백패커는 이벤트를 중단하기로 했다.

   서비스 중단

   촉발

   2024년 1월 설날 이벤트로 트래픽이 평소보다 3배 넘게 몰렸다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블인그레스 컨트롤러Istio

   기여 요인

   단일 장애점기본 설정 방치모니터링 사각지대

   감지

   개발자 한 명이 Slack 에 장애가 의심된다고 제보했다. 여러 사람이 확인하는 동안 장애가 웹과 앱 서비스 전체로 번졌다.

   조치

   • 서비스 전체가 멈추자 설날 이벤트를 중단했다.

   후속 조치

   • 모든 노드의 nf_conntrack_max 를 올렸다. 일반 노드는 인스턴스 전체 메모리 바이트를 16384 로 나누고 다시 2로 나눈 값, istio 노드는 그 값의 3배를 쓴다. 메모리 16GB 인스턴스라면 net.netfilter.nf_conntrack_max 가 약 50만이 된다. 이 설정은 nodeOptimizer 데몬셋에 넣어 모든 노드에 자동으로 적용했다.
   • VirtualService 의 gateways 에 mesh 를 넣어 사이드카끼리 ingressGateway 를 거치지 않고 직접 통신하게 했다. HTTPS 로 도메인을 호출하면 TLS 오프로딩 때문에 여전히 ingressGateway 나 NLB 를 거쳐야 하므로, 메시 통신은 HTTP 호출에서 쓴다.
   • istio 노드를 12.5Gbps 의 c6.xlarge 에서 최대 25Gbps 대역폭을 내는 n 타입 인스턴스로 바꿨다.
   • 모니터링을 늘렸다. ENA 의 네트워크 대역폭과 패킷 드롭, ingressGateway 와 사이드카 프로세스 상태, CPU 와 메모리 사용률과 포화 상태를 지켜본다.

   교훈

   모든 트래픽이 노드 하나의 ingressGateway 를 거치면 그 노드가 단일 장애점이 된다. nf_conntrack 테이블은 기본 크기로 두면 트래픽이 갑자기 몇 배로 늘 때 가득 차고, 그 순간부터 패킷이 버려진다. 게이트웨이 노드는 일반 노드보다 conntrack 한도와 네트워크 대역폭을 넉넉하게 잡고, 네트워크 대역폭과 패킷 드롭 지표를 따로 지켜봐야 한다.

   사례 보기
3. IL-0088 팀별 ingress 컨트롤러 모듈 0.1.0 이 만든 검증 웹훅이 live-1 클러스터에서 새 Ingress 생성을 모두 x509 오류로 막았다

   UK Ministry of Justice2020

   증상

   2020-09-07 12:39 에 Cloud Platform 의 live-1 클러스터에서 새 Ingress 규칙이 만들어지지 않는 문제가 처음 감지되었다. Ingress API 가 POST 요청을 100% 거부하고 있었다.

   배포 실패

   촉발

   팀별 ingress 컨트롤러 모듈 0.1.0 은 ValidatingWebhookConfiguration 리소스를 만들도록 바뀌었다. live-1 클러스터에서는 새 0.1.0 컨트롤러 하나가 AWS 리소스 한도에 걸려 만들어지지 않았다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   단일 장애점

   감지

   문제는 2020-09-07 12:39 에 처음 감지되었다. 확인해 보니 Ingress API 가 POST 요청을 100% 거부하고 있었다. 팀은 Slack 스레드에서 조사를 시작했고 12:54 에 장애를 선언했다.

   조치

   • 0.1.0 이 만든 추가 admission 컨트롤러를 손으로 모두 지웠다.
   • 모듈에서 admission 웹훅을 빼고 새 릴리스 0.1.1 을 냈다.
   • 0.1.0 을 쓰던 ingress 모듈을 모두 0.1.1 로 올렸다.

   교훈

   검증 웹훅을 켜는 옵션 하나가 네임스페이스에 있는 ingress 컨트롤러 파드 전체의 단일 장애점이 되었다. 컨트롤러 하나가 뜨지 못하자 그 웹훅이 클러스터 전체의 새 Ingress 생성을 막았다.

   사례 보기
4. IL-0093 리더 ingress 컨트롤러 파드가 공유 메모리를 다 써서 ingress 컨트롤러 파드 6개 중 4개가 크래시 루프에 빠졌다

   UK Ministry of Justice2020

   증상

   2020-08-14 10:43 에 클러스터의 ingress 컨트롤러 파드 복제본 6개 중 2개가 크래시 루프에 빠진 것이 감지되었다.

   컨테이너 재시작 반복

   원인

   용량 한계

   구성 요소

   인그레스 컨트롤러

   기여 요인

   수동 조치 악화단일 장애점

   감지

   2020-08-14 10:43 에 ingress 컨트롤러 파드 6개 중 2개가 크래시 루프에 빠진 것이 감지되었다.

   조치

   • 리더 ingress 컨트롤러 파드를 재시작했다. 그러자 다른 파드들이 리더에 연결해 최신 nginx.config 파일을 받았다.

   사례 보기
5. IL-0031 API 서버가 OOMKill로 죽자 Skipper 인그레스가 라우트를 잃었고, 고객 트래픽이 끊기며 IAM 서비스에서 404 오류가 났다

   Zalando2018

   증상

   고객에게 영향이 간 장애였다. IAM 서비스에서 404 오류가 나기 시작했다.

   오류율 상승컨트롤 플레인 무응답OOMKilled

   촉발

   발표는 문제의 출발점으로 CronJob 매니페스트 하나를 보여 주었다. 이 매니페스트에는 concurrencyPolicy, successfulJobsHistoryLimit, failedJobsHistoryLimit 필드가 CronJob spec이 아니라 파드 템플릿 spec 안에 들어 있었다. 실행 일정은 평일 9시부터 19시까지 15분마다였다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버인그레스 컨트롤러

   기여 요인

   단일 장애점과도한 영향 범위

   조치

   • CronJob 매니페스트를 고쳤다. concurrencyPolicy와 이력 보존 개수 필드를 CronJob spec으로 옮기고, Job에 activeDeadlineSeconds: 120을 넣고, 실행 일정을 바꿨다.

   후속 조치

   • API 서버에 문제가 생겨도 인그레스가 healthy 상태를 유지하도록 고친다.
   • API 서버가 응답하지 않아도 인그레스가 마지막으로 받은 라우트 목록을 계속 쓰도록 고친다.
   • ResourceQuota로 파드 수 상한을 1500개로 둔다.

   교훈

   ALB는 등록된 호스트가 모두 unhealthy를 보고하면 모든 호스트로 트래픽을 보낸다. 인그레스는 API 서버에 문제가 생겨도 healthy 상태를 유지해야 하고, 마지막으로 받은 라우트 목록을 계속 써야 한다. 파드 수에는 ResourceQuota로 상한을 걸어 둔다.

   사례 보기

원인별3