Discord 음성을 엣지로 이전한 방법 (새 탭에서 열림)
Discord는 음성·영상 트래픽을 기존 약 30개 클라우드 리전에서 Cloudflare의 300개 이상 엣지 PoP로 이전해 사용자와 가까운 서버를 제공하려 했다. 그 결과 전체 트래픽의 80% 이상이 Cloudflare에서 처리되고, 프랑크푸르트에서는 평균 핑이 34%, 패킷 손실이 42% 감소했다. 그러나 단순히 가까운 PoP를 추가하는 것만으로는 충분하지 않았으며, 통화 호스트 배치와 ISP 간 네트워크 경로·피어링 상태가 품질을 좌우했다. ## 클라우드 리전에서 엣지 네트워크로 - 기존 인프라는 주요 클라우드 사업자의 데이터센터가 있는 약 30개 도시 중심으로 구성됐다. - Reykjavik, Auckland, Lagos 등 일부 지역은 가까운 음성 서버가 없어 수백 km 떨어진 리전으로 트래픽이 우회했다. - Cloudflare는 300개 이상의 도시에서 소규모 PoP를 운영하므로 사용자와 더 가까운 위치에 Discord의 음성·영상 서버를 배치할 수 있었다. - CDN은 주로 정적 콘텐츠 캐싱에 사용되지만, Discord는 Cloudflare 네트워크에서 실시간 UDP 패킷을 처리하는 방식을 적용했다. - 이전보다 지리적 커버리지는 크게 넓어졌지만, 각 PoP에 Discord 소프트웨어를 배포하고 운영해야 하는 부담은 남았다. ## 아이슬란드: 가까운 서버가 항상 최선은 아니다 - 2025년 2월, Reykjavik PoP에 음성 서버를 배치해 첫 실험을 진행했다. - 아이슬란드 사용자끼리 통화할 때는: - 핑 9% 감소 - 패킷 손실 11% 감소 - 그러나 아이슬란드와 독일처럼 여러 지역의 사용자가 섞인 통화에서는: - 비아이슬란드 사용자 핑이 2.7배 증가 - 패킷 손실 9% 증가 - Discord는 하나의 SFU가 통화 전체를 호스팅하고, 모든 참가자가 통화가 끝날 때까지 해당 SFU에 연결되는 구조다. - 따라서 독일 사용자 3명과 아이슬란드 사용자 1명의 통화가 Reykjavik에 배정되면, 독일 사용자들의 패킷이 아이슬란드까지 갔다가 돌아와야 했다. - 이 경험을 통해 새로운 PoP를 추가하는 것보다, 통화가 실제로 지역적으로 유지되도록 호스트 배치 로직을 개선하는 것이 중요하다는 점을 확인했다. ## 로테르담: ISP 피어링이 병목이 되다 - 2025년 4월, 기존 로테르담 트래픽을 Cloudflare의 암스테르담 PoP로 이전했다. - 대부분의 ISP에서는 문제가 없었지만, 프랑스 ISP Orange 사용자에게 심각한 품질 저하가 발생했다. - 피크 시간대 Orange 사용자의 통화 지연은 1초를 넘었고, 음성 프리즈 비율은 30% 악화됐다. - 원인은 Cloudflare 자체가 아니라 Orange와 암스테르담 사이의 네트워크 경로였다. - Orange와 Cloudflare의 연결은 Telia의 중계망을 거쳤으며, 피크 시간대 Telia와 Orange 간 인계 구간이 이미 포화 상태였다. - Cloudflare로 트래픽을 더 많이 옮길수록 해당 구간의 혼잡이 심해지는 구조였다. ## 롤백과 피어링 중심의 배포 전략 - Discord는 약 10일 후 암스테르담 이전을 되돌리고, 기존 공급자의 용량으로 Orange 트래픽을 처리했다. - 이후 Cloudflare는 Orange와 직접 피어링을 협상했다. - Orange 트래픽에 더 짧은 경로를 제공하기 위해 파리와 런던 PoP에 SFU를 배치했다. - 이 사건 이후 지역 이전 여부를 단순한 서버 용량이 아니라 ISP별 피어링 여유 공간을 기준으로 판단했다. - 주요 ISP와 Cloudflare 사이의 경로가 포화되어 있으면 해당 지역의 마이그레이션을 보류하는 방식으로 배포 절차를 변경했다. ## 마이그레이션에서 얻은 교훈 - 가까운 PoP는 일반적으로 지연 시간을 줄이지만, 통화 참가자가 여러 지역에 분산되어 있으면 전체 품질을 악화시킬 수 있다. - 최적의 서버 위치는 사용자와의 물리적 거리만으로 결정되지 않는다. - SFU 호스트 배치, 참가자 분포, ISP 간 라우팅, 트랜짓 사업자의 용량을 함께 고려해야 한다. - 초기에는 대규모 지역을 빠르게 이전하려 했지만, 아이슬란드와 로테르담 사례 이후 지역별·단계별 rollout으로 전환했다. - 결과적으로 배포 속도는 느려졌지만, 피어링 분석과 점진적인 트래픽 전환을 통해 장애 위험을 줄일 수 있었다. 실무적으로는 엣지 서버를 늘리는 것보다 먼저 통화·세션의 호스트 배치 정책과 ISP별 네트워크 경로를 분석해야 한다. 특히 글로벌 실시간 서비스는 서버 위치, 사용자 분포, 피어링 용량을 함께 검증한 뒤 소규모 트래픽으로 단계적으로 이전하는 전략이 안전하다.
