멀티 리전 상태 체크 애그리게이터 구축하기
상파울루의 한 사용자가 작동하지 않는 에지 노드에 접속합니다. 사용자는 버그 리포트를 제출하지 않습니다. 그냥 탭을 닫고 다른 것을 시청합니다.
일반적인 업타임 모니터는 이를 놓칩니다. 대부분의 모니터는 단일 위치에서 프로브(probe)를 수행합니다. 그 한 지점에서는 모든 것이 정상(green)으로 보입니다.
우리의 상태 페이지는 실제 사용자가 타임아웃을 겪는 동안에도 100% 업타임을 표시하곤 했습니다. 하나의 글로벌 상태 체크가 우리를 속이고 있었던 것입니다.
진실을 말해주는 시스템을 어떻게 구축했는지 소개합니다.
문제점: 샘플링 편향(Sampling Bias) 모니터가 하나의 데이터 센터에만 있다면, 오직 하나의 현실만 보게 됩니다. 싱가포르와 상파울루의 에지에서 연결이 끊기고 있더라도 정상이라고 보고할 수 있습니다.
비디오 트래픽은 이 문제를 더 악화시킵니다. 일반적인 지역적 장애 사례는 다음과 같습니다:
- 한 대륙에 영향을 미치는 잘못된 BGP 경로.
- 느린 오리진 폴백(origin fallback)을 강제하는 캐시 제거(cache eviction).
- TLS 핸드셰이크 타임아웃을 유발하는 디스크 오류.
- 특정 로컬 리졸버의 DNS 문제.
단순한 "200 OK" 응답만으로는 거의 아무것도 알 수 없습니다.
상태 체크를 위한 세 가지 규칙: 우리는 상태 코드를 넘어섰습니다. 세 가지 지표를 사용하여 상태를 정의합니다:
- 도달 가능성(Reachability): TCP 및 TLS 핸드셰이크가 800ms 이내에 완료되어야 합니다.
- 지연 시간(Latency): p95 TTFB(Time-to-First-Byte)를 추적합니다. 평균값은 사용자를 불만스럽게 만드는 느린 테일(tail) 부분을 가려버립니다.
- 정확성(Correctness): 응답 본문에 예상되는 마커가 포함되어야 합니다. 에러 페이지를 반환하는 200 OK는 실패입니다.
해결책: 멀티 리전 프로빙(Multi-Region Probing) 우리는 하나의 거대한 모니터를 사용하는 것을 중단했습니다. 대신, 저렴한 지역 VPS 인스턴스에 작은 Go 바이너리를 배포합니다.
각 프로버(prober)는:
- 로컬 관점에서 에지를 체크합니다.
- 실제 TTFB 데이터를 얻기 위해
httptrace를 사용합니다. - 결과를 중앙 애그리게이터로 전송합니다.
저장소로는 SQLite를 사용합니다. 단순하며 오버헤드 없이 우리의 워크로드를 처리할 수 있습니다. 우리는 사전 집계된 데이터 대신 원시 샘플을 저장합니다. 이를 통해 나중에 과거 데이터를 재점수화하거나 특정 장애를 디버깅할 수 있습니다.
비결: 쿼럼(Quorum) 네트워크는 노이즈가 많습니다. 패킷 하나가 유실되었다고 해서 장애는 아닙니다.
우리는 오탐을 방지하기 위해 쿼럼(quorum) 시스템을 사용합니다. 여러 리전이 동의할 때만 에지가 "다운"되었다고 선언합니다. 한 리전에서 장애가 발생했지만 다른 리전에서 발생하지 않았다면, 팀에 페이징(page)을 하지 않습니다. 이 설계 선택 덕분에 오탐 알람의 90%를 제거했습니다.
핵심 교훈:
- 합성 경로(synthetic path)가 아닌 사용자가 접속하는 경로를 프로브하세요.
- 평균값이 아닌 테일 레이턴시(p95)를 추적하세요.
- 여러 리전에 일회용의 저렴한 프로버를 사용하세요.
- 페이저 피로(pager fatigue)를 피하기 위해 쿼럼을 사용하세요.
- 스토리지 스택을 단순하게 유지하세요.
무거운 관측성 플랫폼이 필요한 것이 아닙니다. 필요한 것은 로컬 프로브, 로우 데이터, 그리고 노이즈에 과잉 반응하지 않는 규칙입니다.