사례19건

19건 중 2~6번째

1. IL-0246 Cilium 에이전트가 엔드포인트를 만들지 못해 빅데이터 쿠버네티스 노드에서 새 파드가 뜨지 못했다

   Adyen2026

   증상

   Adyen 의 운영 빅데이터 쿠버네티스 클러스터에서 새 파드가 네트워크 설정 단계에서 타임아웃으로 실패했다. 한 파드가 실패하면 같은 노드에 뜨려는 다른 파드도 모두 타임아웃을 냈다.

   파드 ContainerCreating 정체

   촉발

   몇 달 전 Helm 차트에 cilium_bpf_map_dynamic_size_ratio: 0.0050 을 설정해, 2TB RAM 노드의 TCP 연결 추적 테이블 최대 크기가 기본값의 두 배인 16,777,216 개가 됐다. 이 큰 테이블이 연결 추적 가비지 컬렉션의 주기 자동 조정과 맞물려, 연결이 적던 노드에 무거운 데이터 작업이 올라오면 만료된 항목이 몇 시간 동안 쌓였다.

   원인

   설정 변경

   구성 요소

   Cilium

   기여 요인

   늦게 드러난 변경기본 설정 방치재시도 폭주한계 경보 부재

   조치

   • Cilium 설정에 conntrackGCInterval: 60s 를 넣어 가비지 컬렉션 주기가 자동으로 늘어나지 않게 고정했다. 오전 9:00 에 적용해 10:00 에 DaemonSet 배포를 마쳤고, 연결 추적 테이블 크기와 엔드포인트 API 처리 시간이 정상으로 돌아왔다.

   후속 조치

   • 워크로드가 동적으로 바뀌는 Cilium 환경에서는 conntrackGCInterval: 60s 설정과 함께, 가비지 컬렉션 시간 cilium_datapath_conntrack_gc_duration_seconds 와 테이블 크기 cilium_datapath_conntrack_gc_entries 에 미리 알림을 건다. 이 장애 때 가비지 컬렉션 시간은 1초에서 80초로 뛰었고 테이블에는 대부분 만료된 항목 700만 개가 있었다.

   교훈

   규모에 맞춰 바꾼 값은 트래픽이 늘면서 몇 달 뒤에야 전체 영향을 드러낼 수 있다. 512GB 노드를 위해 바꾼 bpf_map_dynamic_size_ratio 는 처음 문제를 풀었지만, 2TB 노드에서 커진 테이블이 가비지 컬렉션 주기 자동 조정과 맞물렸다. 로그는 증상만 보여 줬고, 원인은 프로파일링과 추적으로 컨테이너 런타임, CNI 플러그인, Cilium 에이전트, 리눅스 커널까지 훑어야 보였다. 실제 숫자로 어림셈을 하자 전체 흐름을 이해하기 전에 원인을 짚을 수 있었다. 자동 조정 알고리즘에는 한계가 있어야 한다. Cilium 의 주기 자동 조정은 오래 연결이 적다가 파드 하나로 연결이 크게 늘어나는 노드나, 5% 가 아주 큰 수가 되는 큰 테이블을 고려하지 않았다. 최대 12시간이라는 주기도 이 작업에는 너무 길었다. 타임아웃은 호출한 쪽만 보호할 뿐 작업을 멈추지 않는다. 필요하면 작업을 취소하는 처리를 명시적으로 넣어야 한다. 연결 추적 상태는 핵심 운영 지표로 다뤄야 하고, 한가한 시간의 CPU 절약을 위해 바쁜 시간의 파드 생성 타임아웃을 감수해서는 안 된다.

   사례 보기
2. IL-0470 알림 처리 워커가 모자라 Buildkite 알림 전달이 두 차례 늦어졌다

   Buildkite2026

   증상

   2026-05-28 20:01 UTC 부터 알림 처리 워커가 모자라 Buildkite 의 알림 전달 지연이 늘었다. 내부 큐 지연 모니터링이 이를 잡았다.

   지연 시간 증가오토스케일러 오동작

   촉발

   EKS 의 오토스케일링이 쓰는 Prometheus 서비스의 저장 공간이 다 찼다. 그래서 큐가 쌓이는 동안 EKS 위의 알림 처리 워커 일부가 제대로 늘지 못했다.

   원인

   용량 한계

   구성 요소

   Prometheus

   기여 요인

   한계 경보 부재부분 배포롤백 무효미검증 가정수동 조치 악화

   감지

   팀은 내부 큐 지연 모니터링으로 장애를 알아챘다. 공개 상태 페이지에는 20:20 UTC 에 첫 공지가 올라왔다.

   조치

   • 영향받은 워크로드를 EKS 에서 이전의 ECS 인프라로 옮기기 시작했다.
   • ECS 서비스가 전체 부하를 바로 받지 못해 엔지니어가 장애 중에 스케일링 설정과 워커 수를 손으로 조정했다.
   • 두 번째 지연은 롤백을 마저 끝내고 남은 ECS 서비스를 늘려 해소했다.
   • Prometheus 저장 공간을 늘리고, 같은 변경을 인프라 코드에도 반영했다.

   후속 조치

   • Prometheus 저장 공간이 바닥나 오토스케일링에 영향을 주기 전에 알림이 오도록 모니터링을 더한다.
   • 특정 종류의 오류에서 GitHub 알림 재시도가 되풀이되어 알림 지연을 늘리는 동작을 고친다.
   • EKS 에서 ECS 로 되돌리는 롤백 절차를 보강해, 롤백 전과 도중에 옮겨 갈 쪽의 용량, 오토스케일링 설정, 트래픽 이동을 확인하게 한다.
   • KEDA 와 Karpenter 를 비롯해 EKS 컨트롤 플레인이 의존하는 다른 구성 요소를 검토하고, CPU, 메모리, 저장 공간 할당이 운영 부하에 맞는지 확인한다.
   • 앞으로 EKS 로 옮기는 순서와 속도를 다시 따져, 고객에게 중요한 워크로드는 더 천천히 옮기고 안정될 시간을 분명히 둔다.
   • 고객 단위로 알림 전달 지연을 보는 모니터링을 개선해 고객에게 영향을 주는 회귀를 더 일찍 잡는다.
   • 어떤 알림 종류가 고객의 스케줄링이나 CI 의 핵심 경로에 있는지 검토한다. 그런 알림에는 더 엄격한 지연 기준, 별도 큐, 일반 알림 작업보다 구체적인 모니터링 경보가 필요한지 따진다.
   • 알림 지연이 고객의 작업 흐름에 영향을 줄 것 같으면 상태 페이지를 더 일찍 갱신한다.
   • 상태 페이지에 영향받은 내부 서비스만이 아니라 고객이 겪는 영향을 분명하게 적는다.
   • 장애를 다 파악하기 전이라도 심각한 CI 영향을 알려 오는 고객의 문의가 내부에서 빨리 올라가도록 에스컬레이션 경로를 개선한다.

   교훈

   Buildkite 는 롤백 경로가 이번 상황을 다 다루지 못해 복구가 예상보다 오래 걸렸다고 보았다. 알림 지연의 영향은 고객이 알림을 CI 와 배포 흐름에 어떻게 쓰는지에 따라 다르게 나타난다. Buildkite 는 공개 상태 페이지가 고객이 겪는 영향을 제때 분명하게 보여 주지 못했다고 밝혔다.

   사례 보기
3. IL-0465 IONOS Container Registry 에서 이미지 푸시와 풀이 504 Gateway Timeout 으로 실패했다

   IONOS Cloud2026

   증상

   2026-03-04 에 IONOS Container Registry 고객이 컨테이너 이미지를 푸시하거나 풀할 때 504 Gateway Timeout 오류를 받았다. 레지스트리에 기대는 배포가 막혔다. 상태 페이지에는 09:23 UTC 에 레지스트리의 오류 수가 늘었고 고객이 이미지를 풀하지 못할 수 있다고 처음 올라왔다.

   이미지 풀 실패오류율 상승

   촉발

   마이그레이션 중 일시적인 용량 제약 때문에 중요한 컨트롤 플레인 구성 요소 둘이 같은 프록시 인스턴스에 놓였다. 직접적인 계기는 그 프록시가 동시 연결 한도에 닿아 새 연결을 받지 않은 것이었다.

   원인

   용량 한계

   구성 요소

   컨테이너 레지스트리와 자격 증명관리형 쿠버네티스 컨트롤 플레인과 제공자 API파드 스케줄링과 배치

   기여 요인

   여유 용량 부재단일 장애점한계 경보 부재

   조치

   • 12:22 UTC 에 쿠버네티스 팀이 쿠버네티스 컨트롤 플레인 구성 요소 하나의 버전을 롤백하는 완화책을 배포했다.
   • 프록시 용량을 더 마련했다.
   • 영향받은 컨트롤 플레인 구성 요소를 서로 다른 프록시 인스턴스로 옮겨 부하를 고르게 되돌렸고, 504 오류가 끝났다.

   후속 조치

   • 노드마다 전용 로컬 프록시를 쓰도록 레지스트리와 쿠버네티스 API 사이의 연결을 다시 설계해 공유 프록시 병목을 없앤다. 운영 적용은 2026년 2분기로 잡았다.
   • 프록시 연결 사용률이 한도에 다가가기 전에 경고가 울리도록 알림 기준을 조정한다. 2026년 2분기에 끝낼 예정이다.
   • 인프라 클러스터를 더 배포하고 기존 레지스트리를 다시 나눠, 어느 클러스터도 안전한 운영 용량을 넘지 않게 한다. 사용량이 늘면 자동화가 부하를 계속 고르게 맞춘다.

   사례 보기
4. IL-0100 노드가 파드의 CPU 요청에 비해 작아 CPU 가 포화되면서 PostHog 기능 플래그 서비스에 열흘 사이 장애가 세 번 났다.

   PostHog2025

   증상

   2025-10-21 21:45 UTC, 타임아웃 오류를 줄이려는 배포 직후 자동 모니터링이 기능 플래그 서비스의 오류율 상승을 잡았다. 2분 만에 롤백했지만 오류율은 내려가지 않았고, US 데이터센터에서 평가 요청의 약 38% 가 오류를 냈다.

   노드 CPU 고부하오류율 상승지연 시간 증가컨테이너 재시작 반복데이터베이스 과부하

   촉발

   10월 21일에는 증상만 고치려던 타임아웃 처리 배포가 장애를 일으켰다. 28일에는 플래그 서비스와 무관한 일상 배포가 파드 롤아웃을 일으켰고, 이 롤아웃이 장애로 이어졌다. 24일에는 로드밸런서 뒤에서 모든 트래픽을 IP 하나에서 온 것으로 본 레이트 리밋 배포가 장애를 일으켰다.

   원인

   용량 한계

   구성 요소

   노드 풀파드 스케줄링과 배치인메모리 캐시데이터베이스

   기여 요인

   한계 경보 부재재시도 폭주롤백 무효단일 장애점단계적 배포 부재스테이징 불일치

   감지

   21일에는 배포 2분 뒤 자동 모니터링이 오류율 상승을 잡았고, 28일에는 온콜이 높은 오류 수 경보를 받았다. PostHog 는 대부분의 경우 2분 안에 감지했다고 정리했다. 24일에는 429 오류 경보가 없어서 18:10 UTC 부터 들어온 고객 신고로 알았고, 감지까지 62분이 걸렸다. CPU 경보가 아예 없어서 공통 원인인 CPU 포화는 오래 드러나지 않았고, 29일에서 30일 사이 장애는 7시간 넘게 이어졌다.

   조치

   • 10월 21일 타임아웃 처리를 바꾼 배포를 2분 안에 롤백했지만 오류는 멈추지 않았다.
   • 10월 21일 23:00 UTC 부터 연결과 Redis 쓰기를 조절해 23:28 UTC 에 서비스를 복구했다.
   • 10월 28일 롤아웃을 멈추고 US 플래그 파드를 0개로 줄여 Redis 가 회복되기를 기다린 뒤, 파드를 차례로 다시 올렸다.
   • 10월 30일 00:03 UTC 에 하드웨어 변경을 롤백해 오류는 대부분 가라앉혔지만 지연은 남았다.
   • 파드 리소스 요청을 늘리고 쿠버네티스 플릿 크기를 조정해 노드당 파드 수를 줄였다.
   • 로드밸런서와 서비스 사이 Envoy 재시도에 한도를 걸었다.
   • 데이터베이스 연결 타임아웃과 다른 중요한 설정을 런타임 설정으로 옮기고, 타임아웃 값을 피크 부하에 맞게 늘렸다.
   • 노드마다, 파드마다 CPU 사용률이 80% 를 5분 동안 넘으면 온콜을 호출하는 CPU 경보를 추가했다.

   후속 조치

   • 플래그, 수집, 인프라 팀 엔지니어로 전담 팀을 꾸려 애플리케이션과 인프라 전체를 살피고 남은 병목을 찾는다.
   • 플래그 서비스의 Redis 를 본 애플리케이션의 Redis 와 분리하는 방안을 검토한다.
   • ArgoCD 동기화를 다시 켜기 전에 플래그 서비스 차트 설정을 ArgoCD 의 현재 값에 맞추고, 배포 전략과 Redis 전략을 정한다.
   • 플래그 관련 코드의 필수 코드 오너를 기능 플래그 팀으로 정한다.
   • 중요한 플래그 지표와 런북 링크를 한데 모은 대시보드를 만들고, 기능 플래그 런북을 고친다.
   • 기존 서비스 지표와 인프라 지표에 빠져 있는 경보를 추가한다.
   • readiness 검사가 liveness 검사를 그대로 따라 하지 않고, 데이터베이스에 ping 을 보내는 식으로 부하가 걸렸을 때 약해졌던 의존성을 확인하게 바꾼다.
   • 캐시 채우기 작업에 레이트 리밋을 걸어 Redis 에 감당하지 못할 만큼 작업이 몰리지 않게 한다.
   • 연결 풀을 모니터링해 풀이 바닥에 가까워지면 자동으로 요청을 조절하고, 동시 연결 수에 상한을 둔다.
   • 운영 규모의 부하 시험 체계를 만든다.
   • 점진적 롤아웃 기반을 만들어 배포가 미치는 범위를 줄인다.
   • Postgres 에서 Redis 로 가는 데이터 흐름을 문서로 정리하고, 데이터 전송이 한꺼번에 몰릴 때 쓸 런북을 만든다.

   교훈

   가장 큰 교훈은 CPU 크기 산정이었다. 노드가 파드 요청에 비해 작으면 노드 하나에 파드가 너무 많이 몰리고, CPU 포화가 과도한 병렬 처리, 연결 풀 고갈, 느린 쿼리처럼 서로 다른 모습으로 나타난다. 증상만 고친 수정 때문에 21일의 장애가 28일에 되풀이됐다. PostHog 는 CPU 를 넉넉히 받은 파드를 적은 수로 돌리는 편이 낫다고 정리했다. 기능 플래그 서비스와 본 애플리케이션이 Redis 를 같이 쓰면 한쪽 과부하가 다른 쪽을 쓰러뜨리는 단일 장애 지점이 된다. CPU 지표는 처음부터 경보로 걸어야 하고, Postgres 에서 Redis 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

   사례 보기
5. IL-0020 EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 한꺼번에 쫓아내 운영 서비스가 멈췄다

   UK Ministry of Justice2025

   증상

   2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.

   파드 축출파드 Pending서비스 중단업그레이드 정체

   촉발

   EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.

   원인

   배포 결함

   구성 요소

   디스케줄러노드 풀클러스터 오토스케일러

   기여 요인

   여유 용량 부재한계 경보 부재기본 설정 방치

   감지

   팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.

   조치

   • cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
   • 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
   • 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
   • 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.

   후속 조치

   • AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
   • 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
   • 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
   • 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
   • 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
   • Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.

   사례 보기

원인별6