Incident Library

IL-0379 InfluxData · 2026-09-27databaseazure

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

Azure West Europe 리전의 InfluxDB Cloud 클러스터는 모든 데이터를 여러 물리 노드에 흩어진 중복 파드에 저장한다. 이 파드들은 메모리 매핑 파일로 시계열 데이터를 읽고, 호스트 운영체제는 파드가 쓰지 않는 메모리로 만든 페이지 캐시에 그 파일에서 자주 읽는 부분을 둔다. 이 리전에서는 파드 하나가 약 365 GB 를 들고 있었고, 호스트의 캐시가 파드들이 조회하는 데이터를 다 담지 못했다. 그래서 캐시에서 나와야 할 읽기가 페이지 폴트가 되어 디스크에서 읽혔다. 파드 하나가 디스크에서 약 90 MB/s 를 읽어 파드 열 개가 있는 호스트는 약 990 MB/s 에 이르렀고, 이 값은 호스트 하나의 처리량 상한에 가까웠다. 상한에 닿자 쓰기 경로의 인덱스 조회가 디스크 읽기를 기다리느라 늦어졌고, 쓰기가 밀리면서 파드가 복제 지연 상태 검사에 실패했다. 이 리전의 파드는 하루의 8.9% 를 지연 기준 밖에서 보냈고, 비슷한 다른 리전은 0.09% 였다. 가장 바쁠 때는 가장 붐비는 파티션의 두 복제본이 함께 뒤처져 쿼리 경로에서 지연이 가장 크게 드러났다. 느린 디스크 때문에 상태 검사와 readiness 검사가 타임아웃돼 정상 파드가 재시작됐고, 재시작마다 30분에서 85분 동안 짝 파드가 혼자 부하를 졌고, 재구축이 디스크 부하를 더 올렸다. 파일 참조 안전장치도 하루 50번 넘게 재시작을 일으켰다.

9월 27일 22:58 UTC 에 쿼리 큐 깊이 알림이 울려 장애 대응이 시작됐다. 팀은 쿼리 계층 용량을 두 배로 늘리고, 파드를 재시작하고, 9월 29일 08:58 UTC 에 readiness 타임아웃을 올려 전체에 배포하고, 재시작 뒤 복구 동시성을 두 배로 늘렸다. 9월 30일 00:25 UTC 에 정리 타임아웃을 24시간으로 올리자 강제 재시작이 멈췄다. 그래도 아침마다 성능이 떨어졌다. 9월 30일 11:59 UTC 에 팀은 분석으로 파드당 캐시 용량이 너무 작고 디스크 읽기가 호스트 상한에 닿았다는 것을 밝혔다. 12:43 UTC 에 스토리지 파드의 자원 요청을 올려 호스트마다 파드 수를 줄이고 파드를 더 많은 노드에 펼치는 배포를 시작했다. 파드마다 페이지 캐시용 메모리와 디스크 처리량이 두 배가 됐고, 1시간 안에 쿼리 중단 비율이 31% 에서 0.1% 로 떨어졌다. 10월 1일 아침 사용량이 몰린 시간의 중단 비율은 0.06% 였고, 09:48 UTC 에 내부에서 해결을 선언했다. InfluxData 는 이 상태가 앞서 9월 7일, 11일, 15일, 16일에 난 장애 모두의 근본 원인이었다고 본다.

심각도
–
영향 범위
Queries in InfluxDB Cloud Serverless on Azure West Europe were slow and timed out, with about 55% abandoned at the worst peak; writes were accepted, but new data on some partitions was not immediately queryable
영향 사용자
Customers in the Azure West Europe region
지역
Azure West Europe
감지까지
–
복구까지
–

증상

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

증상은 아침 사용량이 몰릴 때마다 심해졌다. 9월 28일 07:00 UTC 에 스토리지 파드가 쓰기를 따라가지 못하고 복제 지연 상태 검사에 실패했다. 9월 29일에는 쿼리의 36% 가, 9월 30일 아침에는 약 55% 가 중단됐다.

메모리 사용량은 InfluxData 가 감시하는 모든 지표에서 정상으로 보였다. 스토리지 프로세스는 메모리를 적게 쓰고 남는 메모리는 페이지 캐시가 차지하므로, 캐시가 모자라도 메모리 압박이나 부족으로 드러나지 않았다.

디스크가 느려지자 상태 검사와 readiness 검사가 타임아웃됐고, 정상인 파드가 서비스에서 빠지고 재시작됐다. 재시작한 파드는 회복하는 데 한 번에 30분에서 85분이 걸렸다. 그동안 짝 파드가 혼자 부하를 졌고, 재구축이 디스크 부하를 더 올렸다. 파일 참조를 지키는 안전장치도 하루에 50번 넘게 파드를 재시작시켰다. 정상이라면 0번이다.

팀은 처음에 쿼리 계층 용량을 늘렸지만 효과가 오래가지 않았다. 멈춘 파드를 하나씩 재시작했고, readiness 타임아웃과 정리 타임아웃을 올렸고, 재시작 뒤 복구 동시성을 두 배로 늘렸다. 컨트롤러 잠금, 디스크당 한도, 한 테넌트의 부하는 원인 후보에서 뺐다. 이 조치들은 여러 이상 신호를 없앴지만 근본 원인을 풀지는 못했다.

이 클러스터에서 9월 7일, 11일, 15일, 16일에 난 장애도 촉발 요인은 달랐지만 같은 증상을 보였다.

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

원인

원인 용량 한계

구성 요소 데이터베이스데이터베이스 복제라이브니스·레디니스 프로브파드 스케줄링과 배치
기여 요인 모니터링 사각지대자동화 증폭
촉발
–

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 복제, 라이브니스·레디니스 프로브. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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