Incident Library

IL-0253 Mozilla · 2022-01-13gcpnetworking

Firefox 가 네트워크 스레드의 무한 루프에 빠져 전 세계에서 2시간 가까이 웹 페이지를 열지 못했다

Firefox 의 업데이트, 텔레메트리, 인증서 관리, 크래시 보고 같은 내부 서비스는 여러 클라우드 제공자에 올라가 있고 로드 밸런서가 부하를 나눈다. GCP 로드 밸런서의 HTTP/3 지원 설정은 "Enabled", "Disabled", "Automatic (default)" 셋 가운데 하나를 고르게 되어 있고, Mozilla 는 "Automatic (default)" 로 두었다. 2022년 1월 13일 07:28 UTC 에 GCP 가 예고 없이 HTTP/3 를 기본으로 바꿨고, Firefox 는 서버가 지원하면 HTTP/3 를 쓰므로 내부 서비스로 가는 연결 일부가 HTTP/2 대신 HTTP/3 를 쓰게 됐다. 업데이트처럼 아주 중요한 서비스는 beConservative 플래그를 써서 HTTP/3 같은 실험적인 기술을 연결에 쓰지 않는다.

Firefox 의 HTTP/3 연결은 모두 네트워크 스택 Necko 를 거친다. 네트워크에 직접 접근해야 하는 Rust 구성 요소는 viaduct 라는 중간 라이브러리를 통해 Necko 를 부른다. Necko 의 상위 API 는 업로드 요청에 Content-Length 헤더가 있는지 대소문자를 가리지 않고 확인하고 없으면 넣는다. 하위 HTTP/3 코드는 이 헤더로 요청 크기를 정하는데 대소문자를 가려서 찾는다. viaduct 는 헤더를 모두 소문자로 바꿔 넘기므로, viaduct 를 거친 요청은 상위 확인은 통과하지만 HTTP/3 코드는 헤더를 찾지 못한다. Firefox Desktop 에서 네트워크 스택을 쓰면서 Content-Length 헤더를 넣는 Rust 구성 요소는 지금 Telemetry 하나뿐이다.

헤더를 찾지 못한 HTTP/3 코드는 요청이 끝났다고 보고 실제 본문을 보내지 않았다. 그런데 이 코드는 보낼 내용이 남지 않아야 끝나기 때문에 오류를 내지 않고 끝없이 돌았다. 모든 네트워크 요청이 소켓 스레드 하나를 거치므로 이 루프가 다른 통신을 모두 막아 Firefox 가 응답하지 않았다. Mozilla 는 09:12 UTC 에 GCP 에서 HTTP/3 를 명시적으로 껐고 사용자들이 다시 브라우저를 쓸 수 있게 됐다.

심각도
–
영향 범위
Firefox could not load web content; the browser hung on its single network socket thread
영향 사용자
Firefox users worldwide
지역
worldwide
감지까지
–
복구까지
1h 44m

증상

2022년 1월 13일 07:28 UTC 직후 크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다. 전 세계 사용자의 Firefox 가 2시간 가까이 웹 콘텐츠를 불러오지 못하고 쓸 수 없는 상태가 됐다.

처리되지 않은 크래시 보고가 쌓여 30만 건 가까이 됐다.

조사해 보니 Firefox 는 내부 서비스 하나로 가는 네트워크 요청 안에서 멈춰 있었다. 모든 네트워크 요청이 소켓 스레드 하나를 거치기 때문에 이 스레드가 막히자 다른 네트워크 통신도 모두 막혔다.

팀은 문제를 일으킨 변경을 찾아보았지만 Mozilla 쪽에서는 원인이 될 만한 업데이트나 설정 변경을 내보낸 적이 없었다. HTTP/3 는 Firefox 88 부터 켜져 있었고 인기 있는 웹사이트 몇 곳도 이미 쓰고 있었다. 팀은 클라우드 제공자 쪽에서 로드 밸런서 동작을 바꾸는 변경이 눈에 띄지 않게 나갔다고 의심했다. 자세히 살펴보니 Mozilla 의 설정은 하나도 바뀌지 않았다. 그러다 로그에서 Telemetry 서비스의 로드 밸런서가 전에 없던 HTTP/3 연결을 받고 있는 것을 찾았다.

Telemetry 를 끈 사용자는 증상이 사라졌다. 여러 도구와 원격 서비스로 시험해도 재현되지 않았고, 원래 설정 그대로 둔 Telemetry 스테이징 서버에 평범하게 연결해도 재현되지 않았다. Firefox 자체로 스테이징 서버에 연결했을 때만 재현됐다.

증상 서비스 중단

원인

원인 소프트웨어 결함

구성 요소 클라우드 로드 밸런서HTTP·RPC 클라이언트 라이브러리
기여 요인 기본 설정 방치자동 테스트 공백
촉발
2022년 1월 13일 07:28 UTC 에 GCP 가 예고 없이 로드 밸런서의 HTTP/3 를 기본으로 켰다. Mozilla 의 로드 밸런서는 "Automatic (default)" 설정이어서 Firefox 가 Telemetry 서비스로 여는 연결 일부가 HTTP/2 대신 HTTP/3 를 쓰게 됐다.

감지

크래시 리포터로 들어오는 크래시가 갑자기 늘었고, Mozilla 안팎에서 브라우저가 멈춘다는 신고가 여럿 들어왔다.

조치

후속 조치

교훈

문제는 처음 보기보다 훨씬 복잡했고 여러 요인이 함께 작용했다. GCP 가 HTTP/3 기본값 변경을 예고했다면 사고를 완전히 막지는 못했어도 스테이징 환경 같은 곳에서 더 통제된 실험과 배포를 할 수 있었을 것이다. 로드 밸런서를 명시적인 값 대신 "Automatic (default)" 로 둔 탓에 변경이 저절로 적용됐다. Firefox Desktop 에서 HTTP/3 와 viaduct 를 함께 쓰는 조합은 CI 가 시험하지 않았다. 모든 조합을 시험할 수는 없어도 HTTP 버전 선택이나 viaduct 같은 추가 네트워크 계층은 시험했어야 했다. HTTP 버전을 바꿔 가며 시스템 테스트를 더 돌렸다면 이 문제를 찾았을 것이다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 로드 밸런서, HTTP·RPC 클라이언트 라이브러리. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.