IL-0202 Honeycomb · 2023-11-05kubernetes
11월 5일 일요일 Honeycomb 의 US1 이벤트 수집은 1시간 10분 남짓 일부만 동작했고, 약 5분 동안은 완전히 멈췄다. 몇 분 사이에 흩어진 연결에서 비정상적으로 많은 쿼리가 들어왔고, 이 요청들이 데이터베이스 쓰기를 대량으로 일으켰다. 쓰기들이 서로 부딪치면서 커넥션 풀이 막혔다. 이 작업을 건너뛰게 해 주는 캐시가 쓰기 결과를 아직 모든 호스트에 전파하지 못한 때였다. 그 결과 수집 호스트의 메모리 사용량이 빠르게 늘었고, 호스트들이 죽었다. 오토스케일링은 그보다 늦게 반응했다. 최근 수집 코드를 최적화하면서 워크로드 특성이 조금 바뀐 것이 오토스케일링을 늦췄을 수 있다.
로드 셰딩이 있었는데도 수집 호스트들은 재시작을 되풀이했다. 엔지니어들이 호스트 수를 수동으로 크게 늘렸지만, 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남아 용량이 모자랐다. 일부 발신처의 공격적인 재시도도 겹쳤다. 엔지니어들은 몇 분 동안 수집 트래픽 대부분을 끊고 수집 호스트 용량을 다시 확보했다. 그 뒤 시스템은 빠르게 회복했다.
호스트가 모두 돌아왔을 때는 쓰기가 끝났고 캐시도 스스로 갱신된 상태였다. 그래도 일부 고객이 평소의 20배가 넘는 트래픽을 보내 클러스터가 안정되지 못했다. OTel 프로토콜은 스팬 배치 전체에 성공이나 실패 하나로만 응답한다. Honeycomb 은 배치 가운데 일부만 버려도 클라이언트가 빠진 부분을 채우려고 배치 전체를 다시 보냈을 것으로 추정했다. 이 고객들의 트래픽에 걸린 속도 제한을 트래픽이 가라앉을 때까지 임시로 낮추자 수집 파이프라인 전체가 안정됐다.
02:15 UTC 무렵부터 API 수집 엔드포인트의 이벤트 처리가 느려졌다. 실패는 났다가 멎기를 되풀이했고, 끝내 몇 분 동안 수집이 완전히 멈췄다. 기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 상태 페이지 첫 공지는 수집 서비스의 오류율과 응답 시간이 평소보다 높다는 알림을 조사하고 있다는 내용이었다.
시스템을 지키려는 자동 로드 셰딩도 작동해 알림을 더 보냈다. 로드 셰딩은 트래픽 일부를 일부러 버려 수집 호스트가 연쇄로 죽는 것을 막는 장치다. 트래픽을 더 공격적으로 버리도록 로드 셰딩이 걸려 있었는데도 수집 호스트들은 재시작을 되풀이했다. 18:45 PST 에는 버려지는 수집 트래픽이 늘어 장애 등급을 critical 로 올렸다.
엔지니어들은 용량을 확보하려고 수집 호스트 수를 수동으로 크게 늘렸다. 그런데 앞서 실패한 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 계속 오프라인으로 남았고, 클러스터 전체 용량은 여전히 모자랐다. 트래픽을 보내던 일부 발신처는 공격적인 재시도를 한꺼번에 쏟아냈다.
02:50 UTC 에 시스템이 잠깐 회복했지만 완전히 안정된 것은 03:30 UTC 였다. 호스트가 모두 돌아온 뒤에도 클러스터는 안정되지 않았다. 일부 고객이 평소의 20배가 넘는 트래픽을 보내고 있었다. 엔지니어들은 처음에 과거 데이터를 한꺼번에 다시 보내는 백필로 생각했지만, 곧 예상하지 못한 재시도 동작을 의심했다.
원인 용량 한계
기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 자동 로드 셰딩 장치도 작동하면서 알림을 더 보냈다. 상태 페이지 첫 공지는 18:28 PST 에 올라왔다.
Honeycomb 은 이번 장애를 이미 대비책이 있던 장애의 변형으로 보았다. 이번 장애는 그 대비책 일부를 비켜 가는 방식으로 일어났다. 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남으면서 급하게 늘린 용량을 깎아 먹었다. OTel 처럼 배치 단위로 성공과 실패를 알리는 프로토콜에서는 서버가 일부만 버려도 클라이언트가 배치 전체를 다시 보내 트래픽이 크게 불어날 수 있다.
같은 원인 · 공통 인메모리 캐시, 애플리케이션 데이터베이스
IL-0067 Redis 마스터의 50Mi 영구 볼륨이 가득 차 AOF 가 깨졌고, Redis 파드가 크래시 루프에 빠져 Klamm 운영 서비스가 멈췄다BC Government · 2025 · sev1같은 원인 · 공통 인메모리 캐시
IL-0110 Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.DFDS · 2024같은 원인 · 공통 애플리케이션 데이터베이스
IL-0206 GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab · 2022같은 원인 · 공통 애플리케이션 데이터베이스
IL-0037 imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다Datadog · 2019같은 원인 · 공통 애플리케이션 데이터베이스
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
IL-0064 CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 애플리케이션 데이터베이스