사례3건

3건 중 1~3번째

1. IL-0379 Azure West Europe 의 InfluxDB Cloud 에서 9월 27일부터 30일까지 쿼리가 느려지고 타임아웃됐다

   InfluxData2026

   증상

   9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울렸다. Azure West Europe 리전 고객의 쿼리가 느려지고 타임아웃됐다. 쓰기는 계속 받았지만 일부 파티션에서는 새 데이터를 바로 조회할 수 없었다.

   지연 시간 증가간헐적 타임아웃복제 지연프로브 실패

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제라이브니스·레디니스 프로브파드 스케줄링과 배치

   기여 요인

   모니터링 사각지대자동화 증폭

   감지

   9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울려 장애 대응이 시작됐다.

   조치

   • 쿼리 계층 용량을 두 배로 늘렸다.
   • 9월 28일 아침에 멈춘 스토리지 파드를 하나씩 재시작했다.
   • 9월 29일 08:58 UTC 에 readiness 검사 타임아웃을 올려 전체에 배포했다.
   • 재시작 뒤 복구 동시성을 두 배로 늘렸다.
   • 9월 30일 00:25 UTC 에 정리 타임아웃을 24시간으로 올려 안전장치가 일으키던 강제 재시작을 멈췄다.
   • 스토리지 파드마다 자원 요청을 올려 호스트에 올라가는 파드 수를 줄였고, 파드마다 페이지 캐시용 메모리와 디스크 처리량이 두 배가 됐다.

   후속 조치

   • 페이지 폴트 비율, 캐시 커버리지, 스토리지 볼륨의 디스크 읽기, 쿼리 중단 비율에 경고 알림을 더했다. 알림은 캐시 압박이 고객에게 보이기 전에 울리도록 만들었다.
   • 런북에 major page fault 를 스토리지 성능 저하의 선행 지표로 적고, 조정할 수 있는 완화 설정을 자세히 적었다.
   • 스토리지 엔진의 참조 누수를 계속 추적한다.
   • 디스크 검사를 상태 검사 경로에서 뺀다.

   교훈

   캐시가 모자란 상태는 메모리 지표에 드러나지 않았다. 스토리지 프로세스가 메모리를 적게 쓰고 나머지를 페이지 캐시가 차지하기 때문이다. InfluxData 는 major page fault 를 스토리지 성능 저하의 선행 지표로 본다. InfluxData 는 스토리지 엔진의 참조 누수와 상태 검사 경로의 디스크 검사가 이런 장애를 일으키는 위험 요인은 아니며, 진단과 복구 중에 눈에 띄어 조사할 만한 현상이라고 밝혔다.

   사례 보기
2. IL-0430 Redis 장애 조치 뒤 Mackerel 전체가 느려지고 생존 여부 감시가 4시간 넘게 멈췄다

   Hatena2018

   증상

   10시 51분 Redis 에 장애 조치가 일어난 뒤 애플리케이션 서버가 Redis 에 접속하지 못해 Mackerel 이 요청에 제대로 응답하지 못했다. Mackerel 시스템 전체가 불안정해졌고 생존 여부 감시가 멈췄다.

   모니터링 중단지연 시간 증가간헐적 타임아웃

   촉발

   감시 데이터를 담는 Redis 를 스케일업하려고 복제를 구성하는 작업을 했다. 복제 구성에 시간이 걸리는 동안 Redis 가 응답하지 않았고, keepalived 가 이를 노드 고장으로 판단해 의도하지 않은 장애 조치를 일으켰다.

   원인

   설정 변경

   구성 요소

   인메모리 캐시데이터베이스 복제데이터베이스 장애 조치 관리자

   기여 요인

   자동화 증폭장애 중첩

   조치

   • Redis 를 올바른 쪽으로 다시 전환하고 애플리케이션이 돌아온 것을 잠시 확인했다.
   • 애플리케이션 서버를 차례로 재시작했지만 증상은 나아지지 않았다.
   • 부적절한 메트릭을 보내는 Mackerel 조직을 찾아 그 요청을 차단했다.
   • 애플리케이션 서버의 타임아웃 간격을 조정했다.
   • TSDB 인 Diamond 를 임시로 증설했다.
   • Kinesis 샤드 수와 Redis Cluster 샤드 수를 늘렸다.
   • API 용 애플리케이션 서버를 스케일아웃했다.
   • 잠시 점검 모드로 바꿔 사내에서 확인한 뒤 외부 요청을 조금씩 되돌렸다.

   후속 조치

   • 짧은 부하 증가로는 장애 조치가 일어나지 않도록 Redis 의 keepalived 헬스 체크 횟수를 늘렸다.
   • 애플리케이션 성능에 여유를 두려고 Redis 를 스케일업했다.
   • 애플리케이션 서버 대수를 늘렸다.
   • 애플리케이션을 고쳐 필요한 감시 데이터만 Redis 에 저장하게 해 Redis 메모리 사용량을 줄였다.
   • 부적절한 API 요청을 빨리 찾아내 대시보드에서 볼 수 있는 체계를 만들었다.
   • 부적절한 요청을 보내는 조직을 빨리 차단하는 기능을 만들었다.
   • 부적절한 요청을 더 정확히 찾아내고 API Limit 같은 기능을 더하는 것을 검토한다.
   • 애플리케이션 서버의 내부 처리 모니터링을 강화해 장애가 나기 전에 대응할 수 있게 한다.

   교훈

   Hatena 는 상세한 원인을 밝히지 못했다. 그래도 장애 조치 오작동을 막고, 애플리케이션 성능에 여유를 더 두고, Redis 에 저장하는 데이터를 줄이고, 부적절한 요청을 빨리 찾아 막으면 이번처럼 긴 장애는 막을 수 있다고 보았다. 장애가 나더라도 영향이 좁은 범위에 그치도록 하는 작업을 이어 가겠다고 했다.

   사례 보기
3. IL-0590 Rackspace ORD 재부팅 뒤 Mailgun 연결이 간헐적으로 실패하고 이벤트 유실과 이메일 중복 발송이 났다

   Mailgun2014

   증상

   2014년 9월 27일 토요일 18:50 UTC 에 Mailgun 은 모든 데이터베이스 복제와 모든 리전의 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 알아챘다. 그때 Mailgun 은 Rackspace 의 ORD 재부팅을 앞두고 트래픽을 다른 환경으로 옮길 준비를 하고 있었다.

   간헐적 연결 실패간헐적 타임아웃패킷 손실

   촉발

   Rackspace 가 시카고 데이터 센터 ORD 의 클라우드 인스턴스를 재부팅한 유지 보수가 Mailgun 의 F5 서버에 오류 상태를 일으켰다.

   원인

   DNS·네트워크 장애

   구성 요소

   클라우드 로드 밸런서데이터베이스 복제

   기여 요인

   –

   감지

   9월 27일 18:50 UTC 에 ORD 트래픽 전환을 준비하던 Mailgun 이 모든 데이터베이스 복제와 환경 사이 내부 트래픽이 끊기고 타임아웃이 보고되는 것을 발견했다.

   조치

   • Rackspace 네트워크 팀이 Mailgun 의 F5 와 일부 Rackspace 전용 고객의 F5 에서 캐시를 지웠다.
   • Rackspace 네트워크 팀이 Mailgun 서비스용 새 virtual IP 를 만들었다.
   • Mailgun 이 DNS 설정을 바꿔 원격 F5 의 캐시가 강제로 비워지게 했다.

   후속 조치

   • Rackspace 와 함께 F5 문제의 근본 원인을 계속 조사한다.
   • 근본 원인 분석을 마치면 클라우드 인프라 유지 보수가 Mailgun 고객에게 영향을 주지 않도록 조치한다.

   사례 보기

원인별3