사례2건

2건 중 1~2번째

1. IL-0452 한 나라의 한 통신사 3G IP 대역을 쓰는 Azar 사용자가 STOMP 로 통신하는 컴포넌트에 연결하지 못하고 read timed out 을 반복해서 겪었다

   Hyperconnect2024

   증상

   2024년 1월 내부 CS 논의 채널에 XY 국가의 극히 일부 사용자가 Azar 에서 컴포넌트 A 와 관련된 오류를 겪는다는 제보가 들어왔다. 클라이언트에서는 몇 가지 에러 메시지가 꽤 많이 나고 있었다. 그러나 그 무렵 컴포넌트 A 에는 바뀐 것이 없었고 서비스 지표도 눈에 띄게 나빠지지 않았다.

   간헐적 타임아웃

   촉발

   STOMP 통신에 쓰던 라이브러리는 기본 설정에서 TLS Client Hello 에 SNI 를 넣지 않았다. SRE 팀은 통신사 Z 가 SNI 유무에 따라 QoS pool 을 조절하는 설정을 조금씩 rolling update 로 적용하면서 오류가 늘었다고 추정했다.

   원인

   DNS·네트워크 장애

   구성 요소

   ISP·트랜짓 망

   기여 요인

   기본 설정 방치모니터링 사각지대

   감지

   XY 국가의 일부 사용자가 보낸 CS 가 내부 CS 논의 채널로 들어오면서 알게 됐다. 처음에는 원인을 못 찾고 넘어갔고, 관련 CS 가 계속 늘어난다는 리포트가 올라온 뒤에야 본격적으로 조사했다.

   조치

   • Android 팀과 iOS 팀이 STOMP 통신의 TLS 연결에 SNI 를 넣는 핫픽스를 만들었다. SNI 를 넣은 버전과 넣지 않은 버전을 Android 는 tun2socks, iOS 는 ShadowRocket 으로 SOCKS 프록시에 연결해 두 버전의 동작 차이를 확인한 뒤 배포했다.
   • iOS 에서 timeout 오류를 리포팅하는 로직의 버그를 같은 핫픽스에서 고쳤다.

   후속 조치

   • Oxylabs 같은 모바일 프록시 솔루션으로 여러 나라의 네트워크 환경에서 핵심 컴포넌트의 연결성을 자동으로 시험하고 메트릭을 모은다. 장애가 나면 이 메트릭으로 더 빨리 대처한다.

   교훈

   SRE 팀은 회고에서, 첫 문제가 생기고 최소 3개월이 지나 CS 가 쌓인 뒤에야 문제를 보기 시작했다는 점을 짚었다. 글로벌 서비스에서는 예상하지 못한 지역 네트워크의 변화 때문에 일부 사용자가 회사 인프라에 제대로 연결하지 못할 수 있다. 팀은 이 문제를 다음 순서로 풀었다. 데이터 분석으로 볼 곳을 정하고, 문제 구간을 좁혀 모바일 프록시로 재현하고, 원인을 찾아 테스트한 뒤 핫픽스를 배포했다.

   사례 보기
2. 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