Incident Library

IL-0367 Microsoft Azure · 2024-07-18azuredatabase

Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다

Azure VM 의 영구 디스크는 Azure Storage 에 있다. 다층 보안 방어의 하나로, 스토리지 스케일 유닛은 Azure VM 이 도는 물리 호스트에 속한다고 알려진 네트워크 주소 범위에서 온 디스크 읽기와 쓰기 요청만 받는다. VM 호스트가 늘고 줄면 이 주소가 바뀌고, 바뀐 주소를 허용 목록으로 만들어 리전의 모든 스토리지 스케일 유닛에 배포한다. 큰 리전에서는 보통 하루 한 번 이상 갱신한다.

2024년 7월 18일에는 일상적인 VM 호스트 변경에 맞춰 허용 목록을 새로 만들고 있었다. 목록의 원본은 인프라 파일 서버 여러 대에 데이터센터마다 파일 하나씩 있다. 최근 그 파일 서버들의 네트워크 설정이 바뀌어, 목록을 만드는 서버가 그중 일부에 접근하지 못했다. 목록을 만드는 워크플로는 빠진 원본 파일을 알아채지 못했고, VM 호스트 주소 범위가 덜 담긴 허용 목록을 리전의 모든 스토리지 스케일 유닛에 배포했다. 스토리지 서버는 정보가 빠진 VM 호스트에서 오는 VM 디스크 요청을 모두 거부했다. 배포는 묶음 단위였지만 보통 한 시간 안에 리전 전체에 퍼졌다. 이 배포 워크플로는 VM 가용성 하락을 확인하지 않았고 가용 영역 순서대로 배포하는 것 같은 Safe Deployment Practices 를 따르지 않아, 영향이 리전 전체로 번졌다.

VM 이 멈추자 Azure SQL Database 와 SQL Managed Instance 의 컨트롤 플레인과 데이터 플레인 클러스터가 비정상이 되어 서비스 관리 작업과 연결이 실패했다. 장애 1시간 안에 자동 장애 조치 정책이 있는 데이터베이스의 장애 조치를 시작했다. 하지만 서비스 관리자 구성 요소에 요청이 몰려 장애 조치 워크플로가 끊기거나 스로틀링됐고, 0.5% 미만은 손으로 마무리해야 했다. 스토리지 복구 뒤 데이터베이스 98%가 돌아왔고, 약 2%는 게이트웨이 노드의 메타데이터가 실제 복제본 위치와 어긋나 게이트웨이 노드를 재시작해야 했다. Cosmos DB 는 컨트롤 플레인과 데이터 플레인이 Azure Storage 에 OS 디스크를 둔 Azure Virtual Machine Scale Sets 위에 있어 같이 멈췄다. 다중 리전 쓰기 계정은 영향이 없었다. Central US 에 쓰기 리전이 있는 액티브-패시브 계정은 다른 리전으로 장애 조치될 때까지 쓰기를 못 했다. Central US 단일 리전 계정은 파티션이 영향받은 노드에 있으면 멈췄다. Cosmos DB 에 기대는 Azure Resource Manager 와 Privileged Identity Management 도 영향을 받았다.

원인을 확인한 뒤 허용 목록 갱신 워크플로를 전 세계에서 멈추고, Central US 의 모든 스토리지 스케일 유닛의 설정을 고쳐 7월 19일 02:55 UTC 에 스토리지 가용성을 되살렸다. 그 위의 서비스는 실패 규모가 커서 복구에 시간이 더 걸렸다. Cosmos DB 는 19:30 UTC 쯤 모든 데이터베이스의 영향을 완화했고, SQL DB 와 SQL Managed Instance 는 22:00 UTC 에 모든 데이터베이스의 복구를 확인했다.

심각도
–
영향 범위
VM availability in Central US and the services on those VMs, including SQL Database, SQL Managed Instance, Cosmos DB, Database for MariaDB, Database for MySQL and PostgreSQL flexible servers and Azure Resource Manager; new Azure NetApp Files volumes could not be created in any region
영향 사용자
–
지역
Central US
감지까지
26m
복구까지
24h 20m

증상

Central US 리전에서 VM 가용성이 떨어졌고, 그 VM 에 기대는 여러 Azure 서비스에서 연결 실패와 서비스 관리 작업 실패가 났다. 서비스 모니터링은 7월 18일 22:06 UTC 에 VM 가용성 하락을 잡았고, 22:14 UTC 에 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.

Azure Storage 의 스토리지 스케일 유닛이 VM 호스트에서 오는 디스크 읽기와 쓰기 요청을 거부했다. 처음 보인 주된 증상은 스토리지 스케일 유닛으로 가는 VM 디스크 트래픽이 줄어든 것이었다. Premium v2 와 Ultra Disk 를 제공하는 스토리지 스케일 유닛은 영향을 받지 않았다.

Azure SQL Database 와 SQL Managed Instance 에서는 SQL 모니터링이 장애 1분 안에 리전의 비정상 노드와 로그인 실패를 잡았다. 장애 조치를 한 데이터베이스 중 0.5% 미만은 장애 조치가 끝나지 않았다. 장애 조치 그룹 엔드포인트를 쓰지 않는 애플리케이션은 한동안 옛 프라이머리에 계속 쓰기를 보냈다. 스토리지가 돌아온 뒤에도 데이터베이스 약 2%는 게이트웨이 노드의 메타데이터가 실제 복제본 위치와 어긋나 계속 연결할 수 없었다.

Cosmos DB 는 Central US 리전 전체의 요청 성공률이 가장 낮을 때 82%까지 떨어졌고, 리전에서 Cosmos DB 를 돌리는 VM 의 약 50%가 내려갔다. 인프라는 여러 가용 영역에 걸쳐 68분 동안 차례로 내려갔다. 데이터베이스 계정이 다른 리전에서 트래픽을 받을 수 있었던 고객 일부도 연결 문제로 클라이언트 쪽 타임아웃이 났고, 애플리케이션 오류를 봤다.

영향은 다른 서비스로도 번졌다. Central US 의 Cosmos DB 에 백엔드 상태를 둔 Azure Resource Manager 는 미국의 다른 리전에서도 호출이 간헐적으로 실패했고, 재시도해서 다른 리전으로 가면 성공했다. Azure NetApp Files 는 모든 리전에서 새 볼륨 생성이 실패했다.

고객 영향은 21:40 UTC 에 시작됐고, 22:45 UTC 에 허용 목록 배포가 끝나면서 리전의 VM 가용성이 가장 낮아졌다. 스토리지는 7월 19일 02:55 UTC 에 복구됐지만 그 위의 서비스는 복구에 더 오래 걸렸다. SQL DB 와 SQL Managed Instance 는 19일 22:00 UTC 에 모든 데이터베이스의 복구가 확인됐다.

영향이 넓었고 주된 증상이 스토리지로 가는 VM 디스크 트래픽 감소로 보였기 때문에, 다른 원인을 하나씩 배제하고 불완전한 허용 목록을 원인으로 찾기까지 시간이 걸렸다. 22:30 UTC 에 SQL DB 영향이 조사 중이던 스토리지 장애와 관련 있다는 것을 알아냈고, 00:45 UTC 에 일부가 빠진 허용 목록이 근본 원인으로 확인됐다.

증상 스토리지 연결 끊김서비스 중단오류율 상승장애 조치 실패오래된 엔드포인트 라우팅

원인

원인 설정 변경

구성 요소 클라우드 블록 스토리지데이터베이스데이터베이스 장애 조치 관리자
기여 요인 안전하지 않은 실패 동작단계적 배포 부재과도한 영향 범위모니터링 사각지대
촉발
일상적인 VM 호스트 변경에 맞춰 스토리지 허용 목록을 새로 만들 때, 목록을 만드는 서버가 네트워크 설정이 바뀐 인프라 파일 서버 일부에 접근하지 못했다. 그래서 VM 호스트 주소 범위 일부가 빠진 목록이 Central US 의 모든 스토리지 스케일 유닛에 배포됐다.

감지

허용 목록이 Central US 에 배포되는 동안 서비스 모니터링이 VM 가용성 하락을 잡았고, 엔지니어링 팀이 투입됐다. VM 가용성 하락을 잡은 시각은 22:06 UTC 로, 고객 영향이 시작되고 26분 뒤였다. SQL 모니터링은 SQL 을 쓸 수 없게 된 지 1분 안에 비정상 노드와 로그인 실패를 잡았고, 22:14 UTC 에는 모니터링이 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 블록 스토리지, 데이터베이스, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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