사례24건

24건 중 14~18번째

1. IL-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.

   Microsoft Azure2023

   증상

   2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.

   지연 시간 증가간헐적 타임아웃간헐적 연결 실패패킷 손실네트워크 도달 불가

   촉발

   07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

   원인

   설정 변경

   구성 요소

   백본망내부 라우팅BGP 라우팅

   기여 요인

   설정 테스트 부재미검증 가정과도한 영향 범위수동 조치 악화

   감지

   모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다.

   조치

   • WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다.

   후속 조치

   • 세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다.
   • 승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다.
   • 정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다.
   • 아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다.

   사례 보기
2. IL-0532 Azure Software Load Balancer 뒤의 백엔드가 15개를 넘는 로드 밸런서에서 연결이 간헐적으로 끊기고 패킷이 사라졌다

   Microsoft Azure2022

   증상

   고객 일부가 Software Load Balancer 뒤의 리소스에 연결할 때 네트워크 실패와 패킷 손실이 간헐적으로 났다. 장애는 2022-06-28 05:26 UTC 부터 2022-07-01 04:00 UTC 까지 이어졌다.

   간헐적 연결 실패패킷 손실요청 오라우팅

   촉발

   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 로 배포하는 동안 더 철저한 종단 간 모니터링이 필요하다는 것이 확인됐다.

   사례 보기
3. IL-0461 메트릭 질의 서비스를 롤아웃할 때마다 DNS 오류가 나며 질의가 실패했다

   Datadog2022

   증상

   2021년 9월부터 메트릭 질의 서비스의 업데이트를 롤아웃할 때마다 오류가 늘었다. 서비스 로그에는 DNS 오류 때문에 메트릭 데이터 저장소에 연결하지 못했다는 내용이 찍혔다. 클라이언트가 실패한 질의를 자동으로 재시도해 사용자에게 보이는 오류는 적었지만, 재시도 때문에 대시보드와 모니터의 지연이 늘었다.

   오류율 상승DNS 조회 실패지연 시간 증가OOMKilled패킷 손실오래된 엔드포인트 라우팅

   촉발

   2021년 8월 메트릭 질의 클라이언트의 업데이트를 롤아웃하면서 새 기본값인 gRPC round_robin 부하 분산 정책이 처음 적용됐다. round_robin 은 끊긴 채널을 자동으로 다시 연결하는데, 오래전에 넣어 둔 매우 공격적인 gRPC 재연결 타임아웃과 겹쳐 서비스 롤아웃 때마다 사라진 파드 IP 로 SYN 이 쏟아졌다.

   원인

   설정 변경

   구성 요소

   conntrack 테이블Cilium리눅스 커널CoreDNS클라이언트 쪽 DNS 리졸버와 캐시external-dnsHTTP·RPC 클라이언트 라이브러리

   기여 요인

   늦게 드러난 변경재시도 폭주한계 미인지모니터링 사각지대

   감지

   2021년 9월부터 메트릭 질의 서비스 롤아웃 때 오류가 늘어나는 것을 보았고, 서비스 로그에서 DNS 오류가 데이터 저장소 연결을 막는 것을 확인했다.

   조치

   • node-local-dns 파드의 메모리를 64 MB 에서 256 MB 로 올렸다. OOM 오류는 멈췄지만 DNS 오류는 계속됐다.
   • AWS 가 더 많은 연결을 추적할 수 있다고 한 더 큰 인스턴스 유형으로 서비스 인프라를 올려 보았고, 그것만으로 문제가 사라지는 것을 확인했다.
   • SYN 폭주를 일으킨 사용자 지정 gRPC 재연결 파라미터를 지우고 기본값으로 되돌리는 PR 을 만들었다. 다음 롤아웃에서는 오류가 나지 않았다.

   후속 조치

   • Cilium 프로젝트에 PR 을 기여한다. 이 PR 은 옛 파드 IP 에 unreachable 경로를 더해, 지워진 파드로 가는 요청이 martian 패킷이 되지 않게 한다. 그러면 역경로 필터가 SYN 을 버리지 않고, 클라이언트는 분명한 ICMP 오류를 받는다.

   교훈

   gRPC, 쿠버네티스, AWS 같은 강력한 추상화도 엣지 케이스에서는 평소에 숨어 있던 복잡함이 오류로 드러난다. 몇 달을 조사한 끝에, 이번 장애의 뿌리가 팀이 직접 한 변경에 있다는 것을 찾았다. 의존성의 버그를 피해 가려던 변경, 이전 장애를 고치려던 변경, 기본 재연결 파라미터를 덮어쓴 변경이었다. 이 변경들은 당시에는 안전해 보였지만 한참 뒤에 상관관계를 찾기 어려운 때에 뜻밖의 결과를 냈다. DNS 문제처럼 보여도 DNS 문제가 아닐 때가 있다. AWS ENA 지표와 VPC Flow Logs 는 연결 추적을 들여다보는 데 중요하다. DNS 전파 시간은 여러 요인에 좌우된다.

   사례 보기
4. IL-0361 VPC 피어링을 Transit Gateway 로 옮기던 중 seek.com.au 의 구직 검색이 16분 동안 오류를 냈다

   SEEK2021

   증상

   2021년 5월 seek.com.au 에서 구직 검색을 하던 일부 사용자가 오류를 받았고, 장애는 16분 이어졌다. SEEK 는 검색 트래픽을 처리하던 피어링 연결을 Transit Gateway 로 옮기던 중이었고, 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.

   오류율 상승패킷 손실간헐적 타임아웃

   촉발

   SEEK 는 VPC 피어링 연결에서 Transit Gateway 로 옮기는 절차의 둘째 단계로 첫 VPC 의 라우팅 테이블만 Transit Gateway 를 쓰게 바꿨다. 이 상태에서는 VPC A 에서 나가는 패킷은 피어링 연결로, VPC B 에서 나가는 패킷은 Transit Gateway 로 가서 오가는 경로가 달라졌다.

   원인

   설정 변경

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비

   기여 요인

   한계 미인지기본 설정 방치모니터링 사각지대

   감지

   마이그레이션 도중 SEEK 는 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.

   조치

   • 검색이 동작하지 않는 것을 보고 피어링 연결에서 Transit Gateway 로 옮기던 마이그레이션을 롤백했다.

   후속 조치

   • SEEK 환경의 EC2 인스턴스 MTU 를 8500 으로 낮춰 8500 바이트보다 큰 패킷을 보내지 않게 한다. Amazon Linux 2 에서는 네트워크 인터페이스가 올라올 때마다 인터페이스 이름을 인자로 받아 실행되는 /sbin/ifup-local 스크립트를 두어 인스턴스의 기본 MTU 를 8500 으로 덮어쓴다.

   교훈

   SEEK 는 피어링 연결과 Transit Gateway 의 MTU 가 다르다는 중요한 정보를 마이그레이션 전에 알지 못했다. Transit Gateway 가 큰 패킷을 알리지 않고 버린다는 사실은 AWS 의 Transit Gateway 할당량 문서에 적혀 있었지만, SEEK 는 이것이 할당량이라기보다 더 찾기 쉬운 곳에 있어야 할 기본 정보라고 봤다. SEEK 는 이 장애로 MTU, MSS, AWS 관리형 네트워크 장비의 세부 동작을 많이 배웠다. 장애에서 얼마나 배우는지는 장애의 심각도보다 근본 원인을 이해하려는 호기심과 의지에 달려 있다고 보았다.

   사례 보기
5. IL-0336 도쿄 리전으로 가는 Direct Connect 트래픽에 패킷 손실과 간헐적인 연결 끊김이 6시간 넘게 이어졌다

   Amazon Web Services2021

   증상

   일본 시간 2021년 9월 2일 오전 7시 30분부터 Direct Connect 로 도쿄 리전에 접속하는 고객의 트래픽에 간헐적인 연결 문제와 패킷 손실 증가가 나타났다. 같은 시각 AWS 엔지니어는 패킷 손실 증가를 알리는 내부 알람을 받았다.

   패킷 손실간헐적 연결 실패

   촉발

   네트워크 장비 운영체제에 결함이 있었고, 이 결함은 아주 특정한 패킷 속성과 내용이 맞아야만 드러났다. 고객 트래픽이 그 조건에 맞는 패킷을 꾸준히 만들어 내 결함을 건드렸다. AWS 는 악의를 의심할 이유가 없다고 밝혔다.

   원인

   소프트웨어 결함

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비

   기여 요인

   늦게 드러난 변경스테이징 불일치

   감지

   오전 7시 30분, 도쿄 리전에 접속하는 Direct Connect 고객의 패킷 손실 증가를 알리는 내부 알람이 AWS 엔지니어에게 울렸다. 고장 난 장비를 감시하는 자동화도 고장 장비의 비율이 평소보다 높다는 것을 알아채고 엔지니어에게 조사와 조치를 요청했다.

   조치

   • 이 계층에 이중화가 충분하다고 보고 영향받은 장비를 서비스에서 빼, 정상 장비가 트래픽을 처리하게 했다. 잠시 나아졌지만 다른 장비들이 같은 고장을 일으켰다.
   • 고장 난 장비를 리셋하고 천천히 서비스에 되돌려 봤지만 고장은 이어졌다.
   • 한 가용 영역에서 먼저 새 프로토콜을 끄고 회복이 유지되는지 지켜보면서 도쿄 리전 전체에 적용할 변경을 준비했다. 그 뒤 도쿄 리전에서 새 프로토콜을 껐다.

   후속 조치

   • 고객 영향이 나기 전에 이 결함을 찾아 고치는 개선된 방법을 갖추고, 나머지 모든 AWS 리전에 이 변경을 조심스럽게 적용한다.

   사례 보기

원인별9