Incident Library

IL-0531 Microsoft Azure · 2024-04-19azuredatabasenetworking

West US 의 Azure Database for MySQL Single Server 와 MariaDB 일부 서버로 가는 새 연결이 모두 거부됐다

Azure Database for MySQL - Single Server 와 Azure Database for MariaDB 로 가는 모든 연결은 들어오는 연결을 각 서버로 보내는 게이트웨이를 거친다. 게이트웨이는 IP 주소 하나 뒤에 있는 상태 없는 컴퓨트 노드 묶음이다. 게이트웨이 하드웨어를 교체할 때는 IP 주소가 다른 새 게이트웨이 링을 먼저 만들고, 새 링이 완전히 동작하면 DNS 를 바꿔 기존 서버의 새 연결을 새 링으로 보낸다.

2024-04-19 West US 리전에서 기존 서버의 트래픽을 새 게이트웨이 링으로 옮기는 계획된 유지보수가 있었다. 04:26 UTC 에 MySQL 과 MariaDB 서버 한 묶음의 DNS 를 바꿨다. 절차상의 실수로 새 연결이 새 게이트웨이 링으로 갔는데, 이 링은 설정이 덜 끝나 아직 연결을 받을 준비가 되지 않았다. 이 링에서 로그인 요청이 실패해 게이트웨이가 이 서버들로 가는 새 연결을 모두 거부했다. 새 링에는 텔레메트리와 모니터링도 아직 설정되지 않아 서비스 텔레메트리로는 실패를 잡지 못했다. 이 데이터베이스에 기대는 Azure Databricks 는 West US, West US 2, South Central US 에서 로그인, 인증, 클러스터 작업, 잡, 쿼리가 실패했다.

04:46 UTC 에 Azure Databricks 가 MySQL 팀에 여러 데이터베이스에 닿을 수 없다고 알렸다. MySQL 당번 엔지니어들은 05:14 UTC 에 데이터베이스는 정상이지만 연결이 맺어지지 않는다는 것을 확인했고, 05:44 UTC 에 네트워크 팀이 합류했다. 엔지니어들은 06:46 UTC 에 문제를 새 게이트웨이 링으로 트래픽을 옮긴 작업과 연결 지었고 롤백을 시작했다. 07:30 UTC 에 변경이 완전히 롤백됐다. 검증을 거쳐 모든 연결이 정상 동작하던 이전 게이트웨이 링으로 돌아가면서 장애가 완화됐다.

심각도
–
영향 범위
All new connections to a subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB servers failed; Azure Databricks workspace logins, authentication, cluster operations, jobs, UI and Databricks SQL queries, SQL Serverless Warehouses and UC APIs failed or timed out
영향 사용자
A subset of Azure Database for MySQL - Single Server and Azure Database for MariaDB customers, and Azure Databricks customers
지역
West US; Azure Databricks in West US, West US 2 and South Central US
감지까지
20m
복구까지
3h 4m

증상

West US 리전에서 Azure Database for MySQL - Single Server 와 Azure Database for MariaDB 의 일부 고객은 데이터베이스로 가는 연결이 모두 실패했고, 재시도해도 성공하지 못했다. 데이터베이스 자체는 정상이었지만 연결이 하나도 맺어지지 않았다.

이 데이터베이스에 기대는 Azure Databricks 는 West US, West US 2, South Central US 에서 함께 실패했다. 워크스페이스 로그인과 인증 요청이 실패하거나 타임아웃이 났다. 클러스터 CRUD 요청과 클러스터 시작, 크기 조정, 종료에 기대는 작업이 실행되지 않았다. API 나 스케줄러로 제출한 작업도 실행되지 않았다. UI 와 Databricks SQL 쿼리는 타임아웃이 났다. Databricks SQL Serverless Warehouses 를 띄우지 못했고 UC API 에 접근하지 못했다. 고객은 "Authentication is temporarily unavailable" 또는 "TEMPORARILY_UNAVAILABLE" 오류를 보았다.

새 게이트웨이 링은 준비가 덜 끝난 상태여서 텔레메트리와 모니터링도 아직 설정되지 않았다. 그래서 서비스 텔레메트리에는 실패가 보이지 않았고, 내부 팀이 데이터베이스에 닿을 수 없다고 알려 올 때까지 문제가 드러나지 않았다.

MySQL 당번 엔지니어들은 05:14 UTC 에 데이터베이스는 정상인데 연결이 맺어지지 않는다는 것까지 확인했고, 05:44 UTC 에 네트워크 팀을 조사에 불렀다. 문제를 새 게이트웨이 링으로 트래픽을 옮기려던 작업과 연결한 것은 06:46 UTC 였다.

증상 서비스 중단간헐적 타임아웃

원인

촉발
계획된 게이트웨이 하드웨어 교체 작업에서 2024-04-19 04:26 UTC 에 Azure Database for MySQL 과 MariaDB 서버 한 묶음의 DNS 를 바꿨다. 절차상의 실수로 새 연결이 설정이 덜 끝난 새 게이트웨이 링으로 보내졌다.

감지

새 게이트웨이 링에 텔레메트리와 모니터링이 없어 서비스 텔레메트리는 실패를 잡지 못했다. MySQL 팀은 04:46 UTC 에 Azure Databricks 가 여러 데이터베이스에 닿을 수 없다고 알려 와서 장애를 알았다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

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

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

AI 도구와 스크립트용

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