IL-0532 Microsoft Azure · 2022-06-28azurenetworking
Azure Software Load Balancer 뒤의 백엔드가 15개를 넘는 로드 밸런서에서 연결이 간헐적으로 끊기고 패킷이 사라졌다
Software Load Balancer 는 Azure 데이터센터와 클러스터 안의 모든 네트워크 트래픽의 라우팅과 부하 분산을 맡는 소프트웨어 서비스다. 멀티플렉서, 줄여서 MUX 라고 부르는 서버들이 모여 스케일 단위 하나를 이룬다. 스케일 단위마다 로드 밸런서의 프런트엔드 IP 인 VIP 를 많이 두고, MUX 가 각 VIP 뒤의 목적지 IP 들로 트래픽을 보낸다. 목적지 IP 의 순서는 어떤 연결을 어느 백엔드 서버가 받을지 고르는 과정과 바로 묶여 있다.
최신 코드 배포에 든 변경 하나 때문에, 백엔드 풀에 목적지 IP 가 15개를 넘는 로드 밸런서에서 일부 MUX 인스턴스가 목적지 IP 를 다른 순서로 저장했다. 이 순서 차이는 MUX 를 둘 이상 거치는 트래픽에 영향을 주었다. 하나는 들어오는 길과 돌아가는 길 모두 방화벽을 거치는 트래픽이었다. Azure Firewall 은 Azure Load Balancer 를 써서 수평으로 늘어나는 상태 기반 방화벽이다. 방화벽은 흐름을 인스턴스에 고정하기 때문에, 한 흐름의 패킷이 다른 인스턴스에 닿으면 버려졌다. 다른 하나는 물리 네트워크의 경로가 바뀌어 연결이 다른 MUX 로 옮겨 가는 경우였다. Private Link 와 서비스 엔드포인트 트래픽이 쓰는 IPv6 패킷 라우팅 헤더의 흐름 식별자가 바뀌었다. 그래서 연결이 MUX 사이를 옮겨 갈 때 새 MUX 가 백엔드 풀의 다른 서버로 연결을 보냈고, 그 서버가 요청을 거부했다.
Azure 는 Safe Deployment Practices 라는 단계별 배포 체계로 변경을 내보낸다. 텔레메트리에서 오류가 조금 늘고 고객 지원 요청이 들어왔지만, 실패가 간헐적이어서 헬스 체크가 이 신호를 최근 변경과 연결하지 못했다. 그사이 코드는 60개가 넘는 리전 가운데 14개 리전에 퍼졌다. 엔지니어들은 여러 조사와 완화 작업을 나란히 진행했다. 먼저 영향을 받은 것으로 확인된 고객의 VIP 를 손으로 완화했다. 이어서 고객 트래픽에 영향을 주지 않고 적용할 수 있는 핫픽스를 만들어 테스트한 뒤 단계적으로 배포했다. 핫픽스가 퍼지는 동안에는 5분마다 모든 VIP 를 검사해 상태가 어긋난 VIP 를 완화하는 자동화를 돌렸다. 백엔드 인스턴스의 순서는 장애 전처럼 일관되게 되돌렸다. 장애는 2022-07-01 04:00 UTC 에 끝났다.
- 심각도
- –
- 영향 범위
- Connections to resources behind the Software Load Balancer for Azure Firewall deployments with more than 15 backend instances and for service endpoint and Private Link connections to services with more than 15 DIPs, such as SQL and Storage
- 영향 사용자
- A subset of Azure customers
- 지역
- 14 regions for the Azure Firewall scenario, three regions for the service endpoint and Private Link scenario
- 감지까지
- –
- 복구까지
- 70h 34m
증상
고객 일부가 Software Load Balancer 뒤의 리소스에 연결할 때 네트워크 실패와 패킷 손실이 간헐적으로 났다. 장애는 2022-06-28 05:26 UTC 부터 2022-07-01 04:00 UTC 까지 이어졌다.
영향은 두 경우에 몰렸다. 첫째는 Azure Firewall 고객이었다. 이 고객의 방화벽은 Azure Load Balancer 뒤에 목적지 IP 가 15개를 넘었고, 한 흐름의 오가는 패킷이 늘 같은 목적지 IP 에 닿아야 했다. 이 경우는 14개 리전에서 났다. 둘째는 SQL 이나 Storage 처럼 리전 안에서 목적지 IP 가 15개를 넘는 서비스에 서비스 엔드포인트나 Private Link 엔드포인트로 연결하는 고객이었다. 이 경우는 세 리전에서 났다.
MUX 는 Software Load Balancer 를 이루는 멀티플렉서 서버다. Azure Firewall 의 경우에는 한 흐름의 패킷이 서로 다른 방화벽 인스턴스에 닿아 버려졌다. Private Link 와 서비스 엔드포인트의 경우에는 연결이 한 MUX 에서 다른 MUX 로 옮겨 가면 새 MUX 가 연결을 백엔드 풀의 다른 서버로 보냈고, 그 서버가 요청을 거부했다.
텔레메트리에서는 오류가 조금 늘었고 고객 지원 요청도 여러 건 들어왔다. 실패가 간헐적이어서 헬스 체크는 이 신호를 최근 배포와 연결하지 못했다. 방화벽 내부 로드 밸런서 뒤의 인스턴스 수는 고객의 트래픽 패턴에 따라 정해지고, 모든 방화벽이 15개를 넘지는 않는다. 그래서 고객이 알린 문제와 플랫폼 동작을 연결하는 데도 시간이 걸렸다.
원인
원인 배포 결함
- 촉발
- Software Load Balancer 에 배포한 최신 코드의 변경 하나 때문에, 백엔드 풀에 목적지 IP 가 15개를 넘는 로드 밸런서에서 일부 MUX 인스턴스가 목적지 IP 를 다른 순서로 저장했다.
감지
텔레메트리에서 오류가 조금 늘었고 고객 지원 요청도 여러 건 들어왔지만, 실패가 간헐적이어서 헬스 체크가 이 신호를 최근 배포와 연결하지 못했다. 고객 영향을 이 배포와 연결했을 때 코드는 이미 14개 리전에 퍼져 있었다.
조치
- 원인을 파악하는 동안 먼저 영향을 받은 것으로 확인된 고객의 VIP 를 골라 손으로 완화했다.
- 고객 트래픽에 더 영향을 주지 않고 적용할 수 있는 핫픽스를 만들어 테스트했고, Safe Deployment Practices 에 따라 단계적으로 배포했다.
- 핫픽스가 퍼지는 동안 5분마다 모든 VIP 를 검사해 상태가 어긋난 VIP 를 완화하는 자동화를 만들어, 오래 유지할 완화책이 다 배포될 때까지 돌렸다.
- 백엔드 인스턴스의 순서를 장애 전처럼 일관되게 되돌렸다.
후속 조치
- Azure Firewall 에서 한 흐름의 오가는 패킷이 같은 목적지 IP 에 닿지 않는 경우를 잡는 모니터링을 더한다.
- IPv6 흐름 식별자가 연결이 이어지는 동안 바뀌지 않도록 고쳐서 한 연결의 모든 패킷이 MUX 하나에 닿게 한다.
- Azure Firewall 에 방화벽 전용 패킷 캡처 지원을 더해 이런 문제를 더 빨리 찾고 완화하게 한다.
- Azure Firewall 의 TCP 흐름 로그를 늘려 잘못된 패킷과 RST, FIN, FIN-ACK 패킷을 기록해 문제를 더 잘 좁히게 한다.
- Safe Deployment Practices 로 배포하는 동안 종단 간 모니터링을 늘리려고 더 많은 Azure 서비스가 내부 AIOps 도구인 Gandalf 를 쓰도록 서두른다.
교훈
이번 장애로 Safe Deployment Practices 로 배포하는 동안 더 철저한 종단 간 모니터링이 필요하다는 것이 확인됐다.
출처
- https://azure.status.microsoft/en-us/status/history/?trackingId=YVTL-RS0 · official-status
참고 문서
관련 사례
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0532
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0532/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.