Discord 음성을 엣지로 옮긴 방법

출처: Discord 엔지니어링

엔지니어링 및 개발자

Discord에서는 사용자가 가장 가까운 음성 서버까지의 거리가 중요합니다. 네트워크 거리가 1밀리초만 늘어나도 모든 패킷에 지연이 추가되고, 어느 정도 지점에 도달하면 통화가 마치 친구가 같은 방에 있는 것처럼 느껴지지 않게 됩니다.

Discord 역사의 대부분 동안, 우리가 사용자를 배정할 수 있는 가장 가까운 음성 서버는 전 세계 약 30개 도시, 즉 주요 클라우드 제공업체가 데이터 센터를 보유한 곳에 있었습니다. 이는 샌프란시스코 베이 지역이나 프랑크푸르트에 사는 사람에게는 충분했지만, 레이캬비크, 오클랜드, 혹은 하이퍼스케일러 커버리지가 얇은 다른 지역에 사는 사람에게는 그리 좋지 않았습니다.

작년 우리는 Discord 음성·영상 트래픽을 Cloudflare의 엣지 네트워크(300개가 넘는 도시에서 운영)로 이전하기 시작했습니다. 현재 음성·영상 트래픽의 80% 이상이 그곳을 통해 흐르고 있으며, 70%의 지역에서 연간 품질이 개선되었습니다. 프랑크푸르트는 평균 핑이 34% 감소하고 패킷 손실이 42% 감소하는 등 가장 큰 개선을 보였습니다.

이 글은 우리가 어떻게 여기까지 왔는지, 왜 그렇게 했는지, 이를 위해 어떤 시스템을 구축했는지, 그리고 올해 초 유럽에서 발생한 품질 문제를 어떻게 조사했는지를 다룹니다.

네트워크의 다른 형태

대부분의 클라우드 인프라는 소수의 대형 데이터 센터를 중심으로 구축됩니다. Cloudflare는 반대로 300개가 넘는 도시에서 작은 포인트 오브 프레즌스(PoP)를 운영하며, Discord의 음성·영상 소프트웨어를 모든 PoP에서 실행한다는 전략을 제시했습니다.

CDN은 정적 콘텐츠를 사용자 가까이에서 캐시하도록 설계되었지만, Discord의 음성·영상 서비스는 실시간으로 저지연 UDP 패킷을 통화에 참여하는 모든 사람에게 라우팅합니다. Cloudflare는 CDN 아키텍처에서 시작했으며, 다양한 트래픽을 처리할 수 있는 플랫폼을 충분히 구축했기 때문에 우리 워크플로에도 적용될 수 있을 것이라 판단했습니다.

이 변화는 지리적 제약을 크게 완화했습니다. 기존에는 아이슬란드 사용자의 통화가 수백 킬로미터 떨어진 로테르담을 거쳐야 했습니다. Cloudflare는 레이캬비크에 PoP를 보유하고 있어, 이제는 그런 중간 경로가 필요 없습니다. 뉴질랜드, 하와이, 라고스 등 이전에 가장 가까운 하이퍼스케일러 지역을 통해 라우팅되던 곳도 마찬가지입니다. 비교하자면, 다른 하이퍼스케일 클라우드 제공업체는 전 세계에 약 30~40개의 리전만 운영해 일부 국가가 커버되지 않는 반면, Cloudflare는 300개 이상의 PoP를 주요 도시 전역에 두고 있습니다.

두 지역, 두 가지 놀라움

어떠한 엔지니어링 작업을 시작하기 전에, 기본적인 지리 가정이 실제로 통하는지 테스트해야 했습니다. 우리는 기존 공급자의 리전을 대체하기 위해 Cloudflare PoP를 배치하고 트래픽이 자연스럽게 이동하길 기대했습니다. 하지만 처음 두 차례 롤아웃에서 그 가정이 깨졌습니다.

Phase 0: 아이슬란드

2025년 2월 말, 아이슬란드가 첫 테스트 대상이었습니다. 기존 음성·영상 공급자는 아이슬란드에 인프라가 없었기 때문에 아이슬란드 사용자는 로테르담을 경유했습니다. Cloudflare는 레이캬비크에 PoP를 보유하고 있었으므로, 그곳에 음성 서버를 설치하고 결과를 관찰했습니다.

아이슬란드 전용 통화에서는 기대대로 수치가 개선되었습니다. 핑이 9% 감소하고 패킷 손실이 11% 감소했습니다. 현지 사용자는 현지 서버에 접속하게 된 것이죠.

하지만 혼합 지역 통화에서는 상황이 반대로 흘렀습니다. 아이슬란드에 호스팅된 통화에 참여한 비아이슬란드 사용자의 핑이 2.7배 상승했고, 패킷 손실은 9% 증가했습니다.

이는 Discord가 통화를 서버에 할당하는 방식 때문이었습니다. 우리는 하나의 SFU 인스턴스를 선택해 전체 통화를 호스팅하고, 모든 참가자는 그 하나의 호스트에 통화가 끝날 때까지 연결됩니다(Discord가 수백만 동시 음성 통화를 어떻게 처리하는지는 이전 블로그 포스트에서 확인할 수 있습니다). 따라서 아이슬란드 사용자가 독일에 있는 세 명과 통화를 시작하면, 통화가 레이캬비크 서버에 배정될 수 있고 독일 사용자는 패킷을 아이슬란드로 보내고 다시 돌아와야 했습니다. “현지” PoP가 오히려 현지가 아닌 사람들에게는 상황을 악화시킨 것이죠.

전략을 수정해야 했습니다. 새로운 PoP는 통화가 그곳에 머무를 때만 도움이 되었습니다. 즉, 혼합 지역 통화에서는 호스트 배치가 커버리지보다 더 중요했습니다. 그래서 우리는 커버리지 격차를 메우는 대신 기존 리전을 하나씩 교체하는 방향으로 전환했으며, 레이캬비크와 같은 지역은 장기 로드맵에 포함시키고, 더 스마트한 통화 배치 로직을 도입했습니다.

Phase 1: 로테르담

Phase 1은 2025년 4월 말에 시작되어 로테르담 트래픽을 Cloudflare의 암스테르담 PoP로 전환했습니다. 해당 지역 대부분의 ISP는 정상적으로 작동했으며, 핑과 품질 지표도 유지되었습니다.

하지만 몇 시간 안에 프랑스 최대 ISP 중 하나인 Orange를 통해 접속한 사용자들의 통화 지연이 피크 시간에 1초를 넘는 현상이 발생했습니다. Orange 통화의 음성 품질이 30% 악화되었고, 프리즈 비율이 크게 상승했습니다. Orange는 레드 상태가 되었습니다.

문제 원인을 파악하기 위해 조사에 들어갔습니다. 지역 내 다른 ISP와 다른 Cloudflare PoP는 정상적이었으니, 원인은 어디에? 문제는 Orange‑Amsterdam 경로에 있었습니다. 모든 ISP가 인터넷 상의 모든 네트워크와 직접 연결되는 것은 아니며, 트랜짓 제공자를 통해 연결됩니다. 이번 경우 Orange의 Cloudflare 엣지 연결은 Telia의 트랜짓 백본을 거쳤고, Telia‑Orange 간 핸드오프는 피크 시점에 이미 포화 상태였습니다. 우리가 Cloudflare로 옮긴 추가 메가비트마다 상황은 더 악화되었습니다.

약 10일 후, 우리는 롤백을 진행했습니다. 로테르담의 Cloudflare 인스턴스를 비우고 기존 공급자의 용량으로 Orange 트래픽을 흡수했습니다. 이후 Cloudflare는 Orange와 직접 피어링 협상을 시작했고, Orange 트래픽이 Cloudflare 엣지까지 더 짧은 경로를 가도록 파리와 런던 PoP에 SFU를 배치하도록 권고했습니다. 해당 PoP는 이후 몇 달에 걸쳐 가동되었으며, 관련된 모든 사용자에게 혜택을 주었습니다!

이 경험은 롤아웃 프로세스에도 영향을 주었습니다. 로테르담 이전까지는 용량 준비 상황에 따라 롤