사례2건

2건 중 1~2번째

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

   BC Government2025sev1

   증상

   2025년 7월 9일 OpenShift 위의 Klamm 캐시 Redis 클러스터가 멈췄다. Redis 로그에는 "Fail to fsync the AOF file: No space left on device" 오류가 남았다. AOF 는 Redis 가 쓰기 명령을 차례로 덧붙여 저장하는 파일이다.

   서비스 중단컨테이너 재시작 반복영구 볼륨 가득 참

   촉발

   Klamm Laravel 워커 하나에서 I/O 작업이 예상하지 못하게 급증해 Redis 캐시 요청이 크게 늘었고, AOF 가 빠르게 커지면서 Redis 마스터의 영구 볼륨을 채웠다.

   원인

   용량 한계

   구성 요소

   영구 볼륨과 스테이트풀셋인메모리 캐시

   기여 요인

   용량 계획 부재

   조치

   • Redis 스테이트풀셋과 디플로이먼트를 멈췄다.
   • 깨진 PVC 를 지우고 다시 만들었다. 이 과정에서 Redis 볼륨의 데이터를 잃었다.
   • 스테이트풀셋과 디플로이먼트를 다시 시작했다.

   후속 조치

   • Klamm Redis 캐시 볼륨을 100Mi 로 늘린다.
   • 네임스페이스에 Sysdig 모니터링을 설정한다.
   • Redis 클러스터에서 레플리카 파드를 쓰도록 설정한다.

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

   Honeycomb2023sev1

   증상

   02:15 UTC 무렵부터 API 수집 엔드포인트의 이벤트 처리가 느려졌다. 실패는 났다가 멎기를 되풀이했고, 끝내 몇 분 동안 수집이 완전히 멈췄다. 기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 상태 페이지 첫 공지는 수집 서비스의 오류율과 응답 시간이 평소보다 높다는 알림을 조사하고 있다는 내용이었다.

   오류율 상승지연 시간 증가컨테이너 재시작 반복서비스 중단데이터베이스 과부하

   촉발

   몇 분 사이에 여러 곳에 흩어진 연결에서 비정상적으로 많은 쿼리가 들어왔다.

   원인

   용량 한계

   구성 요소

   애플리케이션 데이터베이스인메모리 캐시

   기여 요인

   재시도 폭주자동화 증폭

   감지

   기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 자동 로드 셰딩 장치도 작동하면서 알림을 더 보냈다. 상태 페이지 첫 공지는 18:28 PST 에 올라왔다.

   조치

   • 엔지니어들이 용량을 확보하려고 수집 호스트 수를 수동으로 크게 늘렸다.
   • 몇 분 동안 수집 트래픽 대부분을 끊고 수집 호스트 용량을 다시 확보했다.
   • 가장 공격적으로 트래픽을 보내던 발신처의 속도 제한을 트래픽이 가라앉을 때까지 임시로 낮춰 클러스터를 안정시켰다.

   후속 조치

   • 장기 해결책을 마련하는 동안 같은 장애가 반복되지 않도록 수집 호스트 수를 늘려 두었다.
   • 이번 장애 경로를 막을 프로젝트를 정하는 일에 집중한다.

   교훈

   Honeycomb 은 이번 장애를 이미 대비책이 있던 장애의 변형으로 보았다. 이번 장애는 그 대비책 일부를 비켜 가는 방식으로 일어났다. 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남으면서 급하게 늘린 용량을 깎아 먹었다. OTel 처럼 배치 단위로 성공과 실패를 알리는 프로토콜에서는 서버가 일부만 버려도 클라이언트가 배치 전체를 다시 보내 트래픽이 크게 불어날 수 있다.

   사례 보기

원인별1