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

증상

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

21일에는 ElastiCache 의 Redis 메모리가 바닥났고, Postgres 연결이 급증해 연결 풀이 감당하지 못했다. 이어서 Postgres 에서 Redis 로 대량의 데이터가 옮겨지고 있는 것이 보였다. 같은 Redis 를 쓰는 PostHog 본 애플리케이션까지 영향을 받았다.

10월 28일에는 플래그 코드를 바꾸지 않은 일상 배포가 US 리전의 플래그 파드 롤아웃을 일으켰다. 새 파드는 20초 시작 타임아웃 안에 Postgres 에 연결하지 못해 크래시 루프에 빠졌다. Redis 쓰기가 폭증해 키 축출이 일어나면서 캐시를 사실상 쓸 수 없게 됐고, US 요청의 약 34% 가 실패했다. 팀은 처음에 21일과 같은 대응을 시도했다.

10월 24일에는 IP 기반 레이트 리밋을 배포한 직후 전 세계 평가 요청의 약 97% 가 429 오류를 받았다. 429 경보가 없어서 고객 신고로 알았다. 10월 29일 22:30 UTC 부터 30일 05:39 UTC 까지는 오류율과 지연이 올라갔지만 Redis 와 Postgres 지표는 정상이었다. 실제 원인은 노드 CPU 사용률이 90% 를 넘은 것이었고, 응답 시간이 평소의 몇 배로 늘었다. CPU 경보가 아예 없어서 7시간 넘게 원인을 잡지 못했다.

증상 노드 CPU 고부하오류율 상승지연 시간 증가

원인

감지

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

출처

• https://posthog.com/handbook/company/post-mortems/2025-10-21-feature-flags-recurring-outages · blog

관련 사례

• IL-0202 갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다Honeycomb · 2023 · sev1

  같은 원인 · 공통 애플리케이션 데이터베이스, 인메모리 캐시

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

  같은 원인 · 공통 애플리케이션 데이터베이스, 파드 스케줄링과 배치

• IL-0102 배포와 워커 오토스케일링 폭주가 겹치자 크기를 고정해 둔 CoreDNS 가 메모리 한도를 넘겨 재시작된 뒤 회복하지 못했고, Buildkite 사이트 전체가 약 30분 멈췄다.Buildkite · 2026

  같은 원인 · 공통 노드 풀

• IL-0155 NYC1 의 일부 DOKS 클러스터에서 공유 CPU 노드 위의 CoreDNS 때문에 DNS 가 간헐적으로 실패하고 NodeNotReady 가 났다DigitalOcean · 2026

  같은 원인 · 공통 노드 풀

• IL-0067 Redis 마스터의 50Mi 영구 볼륨이 가득 차 AOF 가 깨졌고, Redis 파드가 크래시 루프에 빠져 Klamm 운영 서비스가 멈췄다BC Government · 2025 · sev1

  같은 원인 · 공통 인메모리 캐시

내 클러스터에도 있는지 확인하기

AI 도구와 스크립트용

• 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0100
• 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0100/similar
• MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.