사례5건

5건 중 1~5번째

1. 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 로 가는 전송 급증도 경보 대상이다. 재시도, 캐시 채우기, 연결 생성에 한도가 없으면 장애가 커진다. 과부하 패턴은 운영 트래픽에서만 드러났으므로 부하 시험이 필요하고, 중요한 설정은 배포 없이 바꿀 수 있어야 한다.

   사례 보기
2. IL-0148 클러스터에 없는 노드를 가리키는 노드 어피니티를 가진 파드 하나 때문에 kube-scheduler 가 패닉에 빠져 AKS 클러스터에서 파드가 하나도 스케줄되지 않았다

   Microsoft2024

   증상

   Kubernetes v1.27.14, v1.28.10, v1.29.5 를 쓰는 AKS 클러스터에서 kube-scheduler 가 패닉에 빠졌다. 그 뒤로 클러스터의 어떤 파드도 스케줄되지 않았다.

   파드 Pending

   촉발

   클러스터에 없는 노드를 가리키는 노드 어피니티를 가진 파드가 생겼다.

   원인

   소프트웨어 결함

   구성 요소

   파드 스케줄링과 배치

   기여 요인

   –

   감지

   AKS 팀이 직접 버그를 찾았고, 2024년 7월 24일 Azure/AKS 깃허브 이슈로 고객에게 알렸다.

   조치

   • Azure Kubernetes Service 엔지니어들이 영향을 받은 클러스터를 모두 고쳤다.
   • 고친 kube-scheduler 를 모든 리전에 배포해 고객 클러스터에 자동으로 적용했다.

   사례 보기
3. IL-0182 트래픽이 급변할 때 수가 모자란 CoreDNS 가 과부하로 지연과 간헐적 네트워크 끊김을 일으켰고, 나중에는 과하게 늘린 CoreDNS 파드가 Karpenter 의 노드 통합을 막았다

   이언철2024

   증상

   트래픽이 급하게 오르내리는 환경에서 CoreDNS 에 부하가 몰렸다. 네트워크 문제가 생기고 응답 지연이 크게 늘었다.

   지연 시간 증가간헐적 연결 실패오토스케일러 오동작

   촉발

   트래픽이 급변하면서 수가 적은 CoreDNS 파드에 처리할 수 있는 양보다 많은 부하가 몰렸다.

   원인

   용량 한계

   구성 요소

   CoreDNSKarpenter수평 파드 오토스케일러파드 스케줄링과 배치

   기여 요인

   자동화 증폭수동 조치 악화

   조치

   • 클러스터 크기에 맞춰 CoreDNS replica 를 늘리도록 CPA 를 설정하고, 인스턴스 타입에 맞게 nodesPerReplica, coresPerReplica, replica 최솟값과 최댓값을 조정했다.
   • CoreDNS 에 anti-affinity 대신 ScheduleAnyway 로 느슨하게 한 topologySpreadConstraints 를 걸어, Karpenter 의 Consolidation 과 Drift 가 CoreDNS 에 막히지 않게 했다.
   • CoreDNS 의 Error Rate, Panics, Request Duration, Request Rate 에 임곗값 알림을 걸었다.
   • NodeLocal DNSCache 를 적용해 노드마다 DNS 캐시를 두고 메인 CoreDNS 의 부하를 낮췄다.

   교훈

   CoreDNS 가 감당할 수 있는 양은 파드에 준 리소스에 따라 다르고, 그에 따라 평균 지연과 초당 질의 수인 QPS 도 달라진다. CoreDNS replica 를 무작정 늘리면 taint 와 topologySpreadConstraints 때문에 파드가 몇몇 노드에 몰려 Karpenter 의 Consolidation 을 막을 수 있다. 노드 하나가 드레인될 때 그 노드의 CoreDNS 가 한꺼번에 많이 종료되면 서비스에 영향이 갈 수 있다. NodeLocal DNSCache 를 쓰면 메인 CoreDNS 로 가는 DNS 질의가 크게 줄고 스파이크를 다루기 쉬워진다. 어느 노드에서 문제가 생겨도 메인 CoreDNS 는 영향을 받지 않는다. 그래서 서비스 전체 장애로 번질 일이 노드 하나의 문제로 그친다. 글쓴이는 CPA 와 NodeLocal DNSCache 를 함께 적용해 CoreDNS 부하 문제를 거의 없앴다고 보았다.

   사례 보기
4. IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.

   Moonlight2019

   증상

   1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.

   오류율 상승간헐적 연결 실패노드 NotReady서비스 중단노드 CPU 고부하

   촉발

   쿠버네티스 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 같은 노드에 배치했다. 이 파드들이 노드 CPU 를 100% 쓰자 노드 VM 이 커널 패닉으로 죽었다.

   원인

   용량 한계

   구성 요소

   파드 스케줄링과 배치리눅스 커널애플리케이션 데이터베이스

   기여 요인

   단일 장애점미검증 가정자동화 증폭

   감지

   API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다.

   조치

   • 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드에 흩어 놓았다.

   후속 조치

   • Google Cloud 지원팀과 함께 노드 커널 패닉의 근본 원인을 찾아 고친다.

   교훈

   복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다.

   사례 보기
5. IL-0036 재시도를 멈추지 않는 쿠버네티스 Job 이 노드 자원을 다 써 버려 클러스터의 노드가 차례로 죽고 검색과 리포트가 멈췄다.

   Universe2017

   증상

   재색인 Job 을 띄운 직후 Universe 의 리포트 API 와 검색 API 에 문제가 생겼다. 쿠버네티스 클러스터 UI 도 함께 영향을 받았다.

   서비스 중단노드 NotReady노드 재생성 반복

   촉발

   Discover 검색 색인에서 일부 데이터 필드를 빼는 변경을 배포하고, 새 설정을 적용하려고 쿠버네티스 Job 으로 재색인 작업을 띄웠다.

   원인

   용량 한계

   구성 요소

   잡과 크론잡파드 스케줄링과 배치

   기여 요인

   미검증 가정자동화 증폭과도한 영향 범위

   감지

   재색인 Job 을 띄운 직후 팀이 리포트 API, 검색 API, 쿠버네티스 클러스터 UI 의 문제를 알아챘다. 팀은 상태 페이지에 검색과 리포트를 쓸 수 없다는 보고를 조사하고 있다고 올렸다.

   조치

   • 문제의 재색인 Job 을 스케줄러에서 지웠다.
   • 노드들이 자동으로 회복해 모두 정상으로 돌아왔다.

   교훈

   RestartPolicy=Never 는 파드에만 적용되고 Job 에는 적용되지 않는다. Job 은 실패하면 항상 다시 시작되고 두 번 이상 실행될 수 있다. 노드 자원을 다 쓰는 작업을 Job 으로 돌리면 그 Job 이 노드를 옮겨 다니며 클러스터의 노드를 모두 쓰러뜨릴 수 있다.

   사례 보기

원인별2