Bluesky 2026년 4월 장애 사고 분석 보고서
(pckt.blog)
블루스카이(Bluesky)가 최근 겪은 대규모 서비스 중단은 특정 RPC 엔드포인트의 동시성 제한(Concurrency Limit) 누락으로 인해 발생했습니다. 대량의 요청이 한꺼번에 몰리며 TCP 포트가 고갈되었고, 과도한 에러 로그 생성이 시스템을 붕괴시키는 '데스 스파이럴(Death Spiral)'로 이어졌습니다.
- 1특정 RPC 엔드포인트(`GetPostRecord`)에서 동시성 제한(`errgroup.SetLimit`) 누락
- 215,000~20,000개의 URI를 포함한 대규모 배치 요청이 발생하며 TCP 포트 고갈 유발
- 3과도한 에러 로그 생성으로 인한 Blocking Syscall 발생 및 Go 런타임의 OS 스레드 폭증
- 4에러 로그가 시스템 부하를 가중시키는 '데스 스파이럴(Death Spiral)' 현상 발생
- 5클라이언트별 메트릭 부족으로 인해 장애 원인 파악 및 복구에 상당 시간 소요
왜 중요한가
배경과 맥락
업계 영향
한국 시장 시사점
스타트업 창업자와 CTO 관점에서 이번 장애는 '기술 부채의 무서움'을 극명하게 보여줍니다. 코드 한 줄(`group.SetLimit(50)`)의 누락이 서비스 전체의 8시간 중단을 초래했습니다. 이는 시스템의 확장성(Scalability)을 논하기 전에, 각 컴포넌트의 '안전 장치(Guardrails)'가 완벽하게 작동하고 있는지 검증하는 프로세스가 얼마나 중요한지를 일깨워줍니다.
특히 주목해야 할 점은 '데스 스파이럴' 구간입니다. 에러를 잡기 위해 남긴 로그가 오히려 시스템을 죽이는 무기가 되었습니다. 이는 대규모 트래픽을 다루는 개발자들에게 '에러 핸들링은 단순히 에러를 기록하는 것이 아니라, 시스템의 가용성을 유지하는 전략적 행위'라는 인사이트를 줍니다. 로그 샘플링이나 에러 발생 시의 서킷 브레이커 도입은 이제 선택이 아닌 필수입니다.
따라서 개발 팀은 '모든 요청은 작고 빠를 것'이라는 낙관적인 가정을 버리고, '가장 비정상적인 요청이 들어와도 시스템은 버텨야 한다'는 방어적 설계(Defensive Design)를 기본 원칙으로 삼아야 합니다.
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.