디스코드(Discord) 음성 통화 장애, 그 숨겨진 이야기

사고의 시작은 세션 관리 서버(Session Management Server)의 설정 변경으로, 이로 인해 세션의 17%가 동시 종료되었다. 기술적으로 보면, Kubernetes가 pod를 종료하는 과정에서 graceful shutdown(우아한 종료)을 위한 안전 장치가 제대로 작동하지 않아, 세션 데이터가 유실되었다. 이로 인해 다수의 사용자가 재접속을 시도하면서 게이트웨이 서비스(Gateway Service)에 과부하가 걸렸고, 이는 다시 음성 동기화 서비스(Voice Syncers Service)의 병목 현상으로 이어졌다. 특히, us-east1-b 존에서 발생한 문제는 다른 존으로의 장애 전파(Failure Propagation)를 가속화했다.

디스코드(Discord)는 Elixir의 GenServer 프로세스(GenServer Process)를 활용하여 실시간 시스템을 구축했다. 기술적으로 보면, GenServer는 단일 스레드로 작동하여 동시성 문제를 피할 수 있지만, HTTP 연결 풀(HTTP Connection Pool)과 같은 공유 자원에 대한 경쟁을 유발할 수 있다. 이번 사고에서는, 다수의 음성 동기화 서비스(Voice Syncers Service) 인스턴스가 새로운 연결을 생성하면서 Holster.Pool DynamicSupervisor의 큐가 증가했고, 이로 인해 연결 생성 시간이 지연되어 병목 현상이 발생했다. 이는 Elixir의 actor model의 한계점을 보여주는 사례이다.

음성 동기화 서비스(Voice Syncers Service)에서 발생하는 HTTP 연결 풀(HTTP Connection Pool)의 병목 현상은, Holster.Pool DynamicSupervisor의 큐가 과도하게 증가하면서 발생했다. 디스코드(Discord)는 이 문제를 해결하기 위해, PartitionSupervisor를 도입하여 연결 풀에 대한 요청을 분산시키고, gun connection process의 생명 주기를 Holster.Pool로 이전했다. 또한, 레이트 리미팅(Rate Limiting)을 조정하여 아웃바운드 연결 생성을 제어하고, 서버 용량을 증설하여 부하를 분산하는 등 다각적인 노력을 기울였다.

사고 이후, 디스코드(Discord)는 Kubernetes 클러스터(Kubernetes Cluster)에 대한 validating admissions webhook을 도입하여, pod 종료 시 graceful draining(우아한 종료)을 보장하도록 했다. 또한, 모니터링 시스템(Monitoring System)을 강화하여 HTTP 연결 풀(HTTP Connection Pool)의 상태를 더 정확하게 파악하고, 서비스 디스커버리(Service Discovery) 및 RPC 트래픽에 대한 로깅을 개선했다. 장기적으로는, Elixir 기반의 모든 서비스에 대한 일반적인 모니터링(Generic Monitoring)을 구축하고, Kubernetes를 활용하여 서버 확장을 자동화할 계획이다.