사례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-0082 EKS 노드 교체 중 CoreDNS 파드 하나가 종료되자 남은 CoreDNS 파드가 늘어난 부하를 버티지 못해 DNS 조회가 느려지고 타임아웃이 났다.

   RebelMouse2025

   증상

   2025년 5월 19일 13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다.

   DNS 조회 실패지연 시간 증가오류율 상승서비스 중단

   촉발

   보안 패치를 적용하는 정기 EKS 노드 교체 중에 계획된 EC2 인스턴스 종료가 자동으로 실행됐고, 그 인스턴스에서 돌던 CoreDNS 파드 하나도 함께 종료됐다.

   원인

   용량 한계

   구성 요소

   CoreDNS노드 풀

   기여 요인

   피크 시간 변경

   감지

   13:42 UTC 에 RebelMouse 모니터링 도구가 오류율 상승과 서비스 성능 저하를 잡아냈다. 노드 교체를 시작한 지 27분 뒤였다. 기술팀은 2분 뒤인 13:44 UTC 에 조사를 시작했다.

   조치

   • 영향을 받은 CoreDNS 파드를 새 EC2 인스턴스로 다시 스케줄했다.
   • CoreDNS 디플로이먼트를 스케일 업해 레플리카 수를 늘리고, 부하가 모든 파드에 고르게 나뉘게 했다.

   후속 조치

   • 부하가 몰리는 시간대에 CoreDNS 파드가 예기치 않게 종료되지 않도록 스케일 인 보호 장치를 넣는다.
   • CoreDNS 파드의 수직 확장이 제대로 되도록 CoreDNS 설정을 다시 살펴본다.
   • CoreDNS 디플로이먼트가 최대 부하를 감당할 만큼 준비돼 있는지 정기적으로 용량을 점검한다.

   사례 보기
3. IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.

   Grafana Labs2020

   증상

   2020년 3월 16일 11:31 UTC에 SLO 기반 알림이 당직 엔지니어를 호출했다. 런던 리전 Hosted Prometheus 로 들어오는 쓰기의 약 20%가 실패하고 있었다. 문제는 이미 11분 전에 시작된 상태였다.

   오류율 상승간헐적 타임아웃

   촉발

   예약된 쿠버네티스 버전 업그레이드가 etcd 리더가 돌던 노드를 정상 종료 절차 없이 갑자기 종료했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd노드 풀

   기여 요인

   기본 설정 방치파괴적 변경 보호 장치 부재

   감지

   SLO 기반 알림이 11:31 UTC에 당직 엔지니어를 호출했다. 장애가 시작되고 11분이 지난 시점이었다. 오류율이 20% 수준이었기 때문에 이대로 두었다면 월간 SLA 를 넘기기까지 약 18시간이 걸렸을 것이다.

   조치

   • 11:32 UTC에 영향받은 distributor 를 재시작했고, 오류가 멈췄다.

   후속 조치

   • Cortex 의 etcd 클라이언트 설정에 gRPC keepalive 프로브를 켠다. DialKeepAliveTime 은 10초, DialKeepAliveTimeout 은 DialTimeout 의 두 배로 두고 PermitWithoutStream 을 true 로 한다.
   • 쿠버네티스 업그레이드 절차를 고쳐, etcd operator 가 관리하는 etcd 파드까지 포함해 파드와 머신을 정상 종료 절차로 내리게 한다.

   교훈

   노드가 죽으면 TCP 연결이 정상적으로 닫히지 않고 멈춘 채 남을 수 있다. etcd 클라이언트에 keepalive 를 설정하지 않으면 새 리더가 뽑힌 뒤에도 클라이언트는 죽은 연결을 계속 쓴다. 노드를 내리는 업그레이드 스크립트는 operator 가 관리하는 파드까지 정상 종료할 수 있어야 한다. 장애 대응과 복구, 사후 분석 동안 Grafana Loki 로 로그를 빠르게 뒤질 수 있어서 복구 시간이 줄었다.

   사례 보기
4. IL-0013 노드 RAM 을 절반으로 줄이자 conntrack 테이블이 가득 차 집계 서비스에 연결 리셋과 오류가 늘었다

   loveholidays2020

   증상

   서비스 구조를 바꾸고 노드 풀 크기를 조정하고 하위 서비스를 샤딩한 직후, 집계 서비스에 여러 연결 문제가 생기고 오류율이 올라갔다.

   연결 리셋오류율 상승간헐적 연결 실패

   촉발

   집계 서비스가 도는 노드의 RAM 을 절반으로 줄였고, 하위 서비스를 샤딩하면서 추적해야 할 연결 수는 두 배가 됐다. conntrack_max 는 노드 RAM 에 비례하므로 노드가 추적할 수 있는 연결 수는 줄고 추적할 연결은 늘었다.

   원인

   용량 한계

   구성 요소

   conntrack 테이블kube-proxy노드 풀HAProxy

   기여 요인

   한계 미인지용량 계획 부재한계 경보 부재

   감지

   팀은 먼저 서비스의 연결 문제와 오류율 상승을 알아챘다. HAProxy 가 보고하는 연결 리셋 오류가 계속 늘었고, 팀은 node_nf_conntrack_entries 를 node_nf_conntrack_entries_limit 과 겹쳐 보고 일부 노드의 conntrack 테이블이 바닥난 것을 확인했다.

   조치

   • 집계 서비스를 RAM 이 더 큰 노드에 배치했다.
   • 노드 하나에 뜨는 집계 서비스 파드 수를 제한했다.

   후속 조치

   • conntrack 사용률이 75% 를 넘으면 경보가 가도록 Prometheus 쿼리 (node_nf_conntrack_entries / on (pod) node_nf_conntrack_entries_limit / on (pod) group_right kube_pod_info) > 0.75 로 경보 규칙을 만들었다.

   교훈

   쿠버네티스 노드의 conntrack_max 는 노드 RAM 에 비례해 정해진다. 부하가 큰 애플리케이션은 특히 작은 노드에서 conntrack_max 를 쉽게 넘겨 연결 리셋과 타임아웃을 일으킨다. 노드를 작게 바꾸면 추적할 수 있는 연결 수도 함께 줄어든다. conntrack 사용률은 지표로 보고 경보를 걸어 둬야 한다.

   사례 보기
5. IL-0468 노드당 볼륨 개수 한도에 걸려 새 학생 서버 파드가 Pending 에 머물고 학생들이 500 오류를 받았다

   UC Berkeley2017

   증상

   2017-03-20 12:44 에 새 학생 서버가 500 오류를 내며 로그인을 막는다는 보고가 들어왔다. 한 사람의 문제가 아니라 널리 퍼진 증상이었다.

   파드 Pending오류율 상승

   촉발

   2017-03-18 16:30 에 자원을 아끼려고 학생 한 명에게 주는 메모리를 2G 에서 1G 로 줄였지만, 노드 크기는 26G RAM 그대로 두었다. 그 결과 Google Cloud 의 노드당 디스크 개수 한도에 닿았다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도클라우드 블록 스토리지노드 풀

   기여 요인

   한계 미인지

   감지

   12:44 에 새 학생 서버가 500 오류로 로그인을 막는다는 보고가 들어왔고, 팀은 이것이 한 사람의 문제가 아니라 널리 퍼진 장애라고 판단했다.

   조치

   • Google Container Engine 이 쓰는 인스턴스 템플릿을 복사해 n1-highmem-4 대신 더 작은 n1-highmem-2 노드를 띄우도록 고쳤다.
   • Google Container Engine 의 관리형 인스턴스 그룹이 새 템플릿을 쓰게 바꿨다.
   • 새 인스턴스 그룹을 30노드 늘렸다. 노드 하나에 학생 12명쯤이 들어가는 용량이었다.
   • populate.bash 를 돌려 새 노드에서 학생 파드가 제때 뜨게 했다.
   • 노드가 섞인 낯선 상태에서 오작동할까 봐 간단한 오토스케일러를 멈췄다.
   • 'redirected too many times' 오류를 알려 온 사용자마다 관리자가 제어판에서 그 사용자의 파드를 멈췄다가 다시 켰다.
   • 'redirected too many times' 오류가 많이 나서 허브 파드와 프록시 파드를 재시작했다.

   후속 조치

   • 이번에 부딪힌 쿠버네티스 버그인 kubernetes/kubernetes 이슈 24317 의 진행을 지켜본다.
   • JupyterHub 의 'too many redirects' 문제를 근원에서 찾아 고친다.
   • 더 이상 쓰지 않는 예전의 큰 노드를 모두 지운다.
   • 파드가 Pending 상태로 무시할 수 없을 만큼 오래 머물면 개수와 상관없이 알림을 보낸다.

   사례 보기

원인별2