IL-0336 Amazon Web Services · 2021-09-02awsnetworking
도쿄 리전으로 가는 Direct Connect 트래픽에 패킷 손실과 간헐적인 연결 끊김이 6시간 넘게 이어졌다
Direct Connect 는 고객 데이터 센터와 VPC 를 사설 연결로 잇는다. 트래픽은 AWS 가 고객과 만나는 에지 로케이션에서 여러 네트워크 계층을 거쳐 리전까지 간다. 계층마다 이중화된 장비가 많다. 일본 시간 2021년 9월 2일 오전 7시 30분, 도쿄 리전으로 가는 경로의 한 계층에서 장비 일부가 트래픽을 제대로 전달하지 못하기 시작했다. 고장 난 장비를 자동으로 빼내는 절차는 이 장비들을 빼내지 않았다. 엔지니어가 장비를 서비스에서 빼고 리셋했지만 다른 장비들이 계속 같은 고장을 일으켜 정상 용량을 지키지 못했다.
낮 12시쯤 엔지니어는 장애 전환 시간을 줄이려고 넣은 새 프로토콜을 의심했다. 엔지니어는 한 가용 영역에서 먼저 이 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 고객은 낮 12시 30분부터 애플리케이션이 회복되는 것을 보기 시작했고, 오후 1시 42분에 장비들이 안정을 되찾아 Direct Connect 가 정상으로 돌아왔다.
이후 조사에서 원인은 네트워크 장비 운영체제의 잠재 결함으로 확인됐다. 새 프로토콜은 이 버전의 운영체제에서 켜지는 기능이었다. 운영체제를 바꾸고 새 프로토콜을 들일 때 AWS 는 전용 실험실에서 정상 패킷과 형식이 잘못된 패킷으로 스트레스 테스트를 먼저 한다. 운영 환경에는 업그레이드한 장비에서 업그레이드하지 않은 장비로 트래픽을 쉽게 돌릴 수 있는 곳부터 천천히 배포한다. 새 운영체제와 프로토콜은 2021년 1월 처음 운영에 들어가 8개월 동안 모든 AWS 리전에 차례로 배포됐고, 그동안 결함의 징후는 없었다. 결함은 아주 특정한 패킷 속성과 내용이 있어야 드러났다. 그런데 고객 트래픽이 이 조건에 맞는 패킷을 꾸준히 만들어 냈다.
- 심각도
- –
- 영향 범위
- Direct Connect traffic from customer data centers to VPCs in the Tokyo Region; traffic between Availability Zones, internet connectivity to the Region, AWS VPN and Direct Connect traffic to other Regions were not affected
- 영향 사용자
- Direct Connect customers connecting to the Tokyo Region
- 지역
- Tokyo (AP-NORTHEAST-1)
- 감지까지
- 0m
- 복구까지
- 6h 12m
증상
일본 시간 2021년 9월 2일 오전 7시 30분부터 Direct Connect 로 도쿄 리전에 접속하는 고객의 트래픽에 간헐적인 연결 문제와 패킷 손실 증가가 나타났다. 같은 시각 AWS 엔지니어는 패킷 손실 증가를 알리는 내부 알람을 받았다.
알람은 Direct Connect 네트워크의 한 계층에서 장비 여러 대가 고장 난 것을 가리켰다. 이 장비들은 트래픽을 제대로 전달하지 못했는데도, 고장 난 네트워크 장비를 감시해 빼내는 평소의 자동화 절차가 이 장비들을 네트워크에서 빼내지 않았다. 자동화는 대신 고장 난 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어를 불렀다.
엔지니어가 영향받은 장비를 빼자 잠시 나아졌지만, 다른 장비들이 차례로 같은 고장을 일으켰다. 고객 쪽에서는 네트워크 혼잡, 연결 문제, 패킷 손실 증가가 이어졌다. 고장 난 장비를 리셋해 천천히 서비스에 되돌려도 고장은 계속됐고, 엔지니어는 고객 영향을 막을 만큼 정상 용량을 유지하지 못했다.
엔지니어는 고장을 일으켰을 만한 최근 배포를 찾았다. 낮 12시쯤 엔지니어는 드물게 일어나는 네트워크 수렴 이벤트와 광섬유 절단에 네트워크가 더 빨리 반응하도록 넣은 새 프로토콜을 의심했다. 이 프로토콜은 몇 달 전에 들어와 그동안 문제없이 돌고 있었다. 엔지니어는 이 프로토콜이 이 계층 장비들에 나타난 새 트래픽 패턴과 맞물려 고장이 났다고 봤다.
가용 영역 사이의 트래픽, 리전으로 가는 인터넷 연결, 일부 고객이 Direct Connect 의 백업으로 쓰는 AWS VPN 연결은 영향을 받지 않았다. 다른 AWS 리전으로 가는 Direct Connect 트래픽도 멀쩡했다.
원인
원인 소프트웨어 결함
- 촉발
- 네트워크 장비 운영체제에 결함이 있었고, 이 결함은 아주 특정한 패킷 속성과 내용이 맞아야만 드러났다. 고객 트래픽이 그 조건에 맞는 패킷을 꾸준히 만들어 내 결함을 건드렸다. AWS 는 악의를 의심할 이유가 없다고 밝혔다.
감지
오전 7시 30분, 도쿄 리전에 접속하는 Direct Connect 고객의 패킷 손실 증가를 알리는 내부 알람이 AWS 엔지니어에게 울렸다. 고장 난 장비를 감시하는 자동화도 고장 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어에게 조사와 조치를 요청했다.
조치
- 이 계층에 이중화가 충분하다고 보고 영향받은 장비를 서비스에서 빼, 정상 장비가 트래픽을 처리하게 했다. 잠시 나아졌지만 다른 장비들이 같은 고장을 일으켰다.
- 고장 난 장비를 리셋하고 천천히 서비스에 되돌려 봤지만 고장은 이어졌다.
- 한 가용 영역에서 먼저 새 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 그 뒤 도쿄 리전에서 새 프로토콜을 껐다.
후속 조치
- 고객 영향이 나기 전에 이 결함을 찾아 고치는 개선된 방법을 갖추고, 나머지 모든 AWS 리전에 이 변경을 조심스럽게 적용한다.
교훈
–
출처
- https://aws.amazon.com/message/17908/ · official-status · 보관본
관련 사례
IL-0223us-east-1 에서 AWS 내부 네트워크와 주 네트워크를 잇는 장비가 연결 폭주로 혼잡해져 EC2 API 와 여러 AWS 서비스의 제어 평면이 몇 시간 동안 오류를 냈다.Amazon Web Services · 2021같은 원인 · 공통 트랜짓 게이트웨이와 네트워크 연결 장비
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0336
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0336/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.