사례39건

39건 중 19~23번째

1. IL-0259 Fastmail 에서 나가는 패킷이 인터넷 일부에 닿지 않아 고객 3~5% 가 약 19시간 동안 Fastmail 을 쓰지 못했다

   Fastmail2023

   증상

   2023년 6월 30일 03:00 UTC 무렵부터 Fastmail 과 인터넷 일부가 서로 통신하지 못했다. 문제는 약 19시간 이어졌고, 고객의 3~5% 로 추정되는 사용자와 일부 메일 서버가 영향을 받았다.

   네트워크 도달 불가

   원인

   의존성 장애

   구성 요소

   ISP·트랜짓 망

   기여 요인

   단일 장애점모니터링 사각지대

   감지

   고객들이 지원 티켓과 소셜 미디어로 알려 와서 처음 알았다. 세계 여러 곳에 둔 모니터링 장비도, 직원들도 문제가 있는 네트워크에 있지 않아 장애를 보지 못했다.

   후속 조치

   • 서버에 직접 들어오는 두 번째 트랜짓 회선을 둘 공급사를 고른다. Megaport 를 거치거나 365 의 New Jersey 데이터센터에 직접 들어와 있는 업체를 쓰고, 나가는 트래픽 경로를 직접 골라 문제 있는 네트워크를 피해 간다.

   교훈

   나가는 트래픽의 경로가 하나뿐이어서 Fastmail 은 공급사 네트워크의 문제를 피해 갈 수 없었고 스스로 고칠 수도 없었다. 나가는 경로를 여러 개 중에서 고를 수 있으면 모든 사용자를 더 빨리 다시 접속하게 할 수 있다.

   사례 보기
2. IL-0541 Twingate 의 us-east4 와 europe-west6 Relay 클러스터에 Client 와 Connector 가 접속하지 못했다

   Twingate2023

   증상

   Terraform 변경을 전 세계 Relay 클러스터에 적용하던 중 01:40 UTC 에 us-east4 와 europe-west6 두 클러스터의 연결 수가 줄어드는 것이 보였다. Client 와 Connector 는 두 클러스터를 찾을 수는 있었지만 접속할 수는 없어 교착 상태에 빠졌다.

   네트워크 도달 불가

   촉발

   2023년 2월 14일 01:00 UTC 에 Relay 클러스터 인프라에 스팟 인스턴스 스케일링을 넣는 Terraform 변경을 전 세계 모든 Relay 클러스터에 적용하기 시작했다. 적용에는 약 45분이 걸렸다.

   원인

   설정 변경

   구성 요소

   TerraformVPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   스테이징 불일치단계적 배포 부재

   감지

   01:40 UTC 에 엔지니어들이 us-east4 와 europe-west6 두 클러스터의 연결 수가 줄어든 것을 보고 조사를 시작했다.

   조치

   • 02:04 UTC 에 영향을 받은 두 클러스터의 파드를 꺼서 Client 와 Connector 가 다음으로 가까운 Relay 클러스터로 다시 붙게 했다.
   • 03:30 UTC 에 Terraform 설정 오류를 고치고 영향을 받은 클러스터를 다시 배포했다.

   후속 조치

   • 스테이징 환경에 Relay 클러스터의 크기 차이와 설정 차이를 정확히 반영한다.
   • 기능 개발 브랜치에서 운영의 모든 설정 변형을 포함해 모든 환경의 Terraform plan 을 자동으로 만든다.
   • 필요한 네트워크 방화벽 태그가 없으면 Connector 와 Client 가 그 클러스터를 발견하지 못하도록 Relay 헬스 체크를 강화한다.
   • Relay 클러스터 인프라에 Terraform 으로 단계적 롤아웃을 하는 방법을 조사하고 도입한다.
   • 중기 계획으로 Connector 가 여러 클러스터에 연결할 수 있게 해 리전 단위의 Relay 클러스터 문제를 자동으로 처리한다.

   사례 보기
3. IL-0344 Linode US-West 의 Fremont 와 Santa Clara 데이터 센터가 인터넷 연결과 두 사이트 사이 연결을 잃었다

   Linode2023

   증상

   2023년 2월 12일 Linode US-West 리전의 고객이 자기 Linode 에 접속하지 못했다. 상태 페이지는 10:22 UTC 에 US-West 의 연결 문제 신고를 조사 중이라고 알렸고, 12:52 에 다시 연결 문제 신고가 들어왔다고 알렸다.

   네트워크 도달 불가

   촉발

   2월 11일 17:45 UTC 에 US-West 두 데이터 센터를 잇는 A 쪽 다중 광섬유 회선의 링크 하나가 끊겼고, 2월 12일 2:45 UTC 에 이중화 짝인 B 쪽 회선 전체가 끊겼다. 하드웨어 업체와 함께 원인을 조사하던 중에는 시스템에 영향을 주지 않는 명령 하나가 드문 버그를 건드려 A 쪽 링크가 모두 끊겼다.

   원인

   소프트웨어 결함

   구성 요소

   백본망NIC·케이블·스위치 포트 링크

   기여 요인

   장애 중첩수동 조치 악화

   감지

   2월 12일 10:22 UTC 상태 페이지에 US-West 리전의 연결 문제 신고를 조사 중이라는 공지가 올라왔다. 12:52 UTC 에는 연결 문제 신고가 더 들어와 다시 살펴보기 시작했다.

   조치

   • 2월 12일 10:13 UTC, Santa Clara 보더 라우터에서 인터넷 트래픽을 모두 뺀 변경을 되돌려 서비스를 살렸다.
   • 버그를 피하려고 두 회선의 코드를 긴급히 업그레이드했다. 업그레이드는 16:25 UTC 에 끝나 연결이 돌아왔고, 17:29 UTC 까지 트래픽이 A 쪽 경로로 돌아왔다.
   • 하드웨어 업체, 광섬유 제공자와 함께 B 쪽 고장 지점을 찾아, 2월 14일 18:30 UTC 에 B 쪽 경로를 살리고 US-West 두 사이트 사이 이중화를 모두 되찾았다.

   사례 보기
4. 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월에 끝낼 예정이다.

   사례 보기
5. IL-0267 싱가포르 캐시 거점 eqsin 의 전송 회선 두 개가 함께 끊겨 BGP 가 내려가고 eqsin 의 호스트에 닿을 수 없게 됐다

   Wikimedia Foundation2023

   증상

   16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태가 CRITICAL 이라고 알렸고, 몇 분 뒤 eqsin 의 호스트들이 한꺼번에 DOWN 으로 떴다. 호출 알림 세 건이 동시에 울렸고 그중 두 건은 batphone 으로 올라갔다.

   네트워크 도달 불가

   촉발

   eqsin 을 코어 데이터센터에 잇는 전송 회선 두 개 중 하나는 오래 이어진 광케이블 절단으로 끊겨 있었다. 남은 하나가 전송 회선 공급사 Arelion 의 계획 작업 PWIC225900 으로 내려갔다.

   원인

   의존성 장애

   구성 요소

   백본망BGP 라우팅CDN 과 엣지 네트워크

   기여 요인

   단일 장애점초기 신호 무시

   감지

   자동 모니터링이 먼저 잡았다. 16시 37분 UTC 에 Icinga 가 cr3-eqsin 의 BGP 상태 CRITICAL 을 알렸고, 이어서 cr2-eqsin 의 BGP 상태와 eqsin 호스트들의 DOWN 알림이 울렸다. 호출 알림 세 건이 동시에 울렸고 그중 두 건이 batphone 으로 올라갔다.

   조치

   • 16시 48분 UTC 에 eqsin 을 DNS 에서 뺐다.
   • 나중에 eqsin 을 다시 DNS 에 넣었다.

   후속 조치

   • 백업 GRE 터널을 만든다. 작업은 T327265 이다.
   • 오래 끊겨 있던 전송 회선이 수리된 뒤 제대로 다시 올라오는지 확인한다. 작업은 T322529 이다.
   • 공급사의 점검 알림을 자동으로 읽어 들여 점검 일정이 서로 겹치면 알린다. 작업은 T230835 이다.

   교훈

   eqsin 을 DNS 에서 빨리 뺀 것이 잘됐고, 먼저 빼고 나중에 조사한다는 태도가 맞았다. 잘못된 것은 세 가지였다. eqsin 이 너무 오래 전송 회선 하나로만 버텼다. 두 전송 회선이 겹쳐서 내려가는 것을 SRE 들이 잡지 못했다. 공급사의 계획 작업이 작업 티켓이나 알림으로 남지 않았다. 알림은 맞게 울렸지만 IRC 에서 감당하기 어려울 만큼 많았다.

   사례 보기

원인별10