Roblox Cloud에서의 네트워크 패킷 손실 및 지연 시간 모니터링

Roblox 네트워크 엔지니어링 팀은 전 세계에 데이터 센터와 접속 지점(POP)을 분산 배치하여 대규모의 빠르게 성장하는 네트워크를 운영하고 있습니다. Roblox 플랫폼에서 뛰어난 사용자 경험을 제공하는 것은 이 네트워크의 성능과 안정성에 달려 있습니다. 네트워크 운영자가 네트워크 문제를 진단 및 탐지하고, 네트워크 성능을 파악할 수 있는 것은 매우 중요합니다. 네트워크 모니터링은 일반적으로 장치 통계, 오류 메트릭 및 시스템 로그를 주기적으로 수집하여 시계열 또는 로그 데이터베이스에 저장하는 방식으로 이루어집니다. 데이터는 SNMP, Netconf, REST API 또는 스트리밍 텔레메트리(Streaming Telemetry)와 같은 표준 프로토콜을 사용하여 푸시(push) 또는 풀(pull) 모델로 수집됩니다.

단순히 장치 텔레메트리만을 통한 네트워크 장애 탐지는 수동적인 모니터링 기법이기 때문에 몇 가지 단점이 있습니다. 이는 비정상적인 상황이 발생하자마자 이를 식별하고 보고할 수 있는 네트워크 노드의 능력에 의존합니다. 장치가 항상 데이터를 보고하지 않을 수도 있으며, 경우에 따라 일반적인 텔레메트리 수집 방법에 노출되는 모든 상태 통계가 없을 수도 있습니다. 또한, 네트워크 장치가 때때로 잘못된 데이터를 제공하거나 트래픽을 조용히 블랙홀로 처리할 수도 있습니다. 장치 텔레메트리의 주요 한계는 네트워크의 종단 간 연결성, 패킷 손실 및 지연 시간 통계에 대한 가시성을 거의 제공하지 못한다는 점입니다.

네트워크를 능동적으로 모니터링하는 훌륭한 방법은 아래 그림에 표시된 것처럼 메쉬 네트워크 전반에 걸쳐 합성된 프로브를 정기적으로 전송하는 것입니다.

운영 중단을 해결하는 과정에서 네트워크 운영자는 “네트워크에서 패킷 손실이 발생하고 있습니까?” 또는 “서비스 연결에 영향을 미치는 네트워크 장애가 진행 중입니까?”와 같은 질문을 자주 받습니다. 과거 패킷 손실 및 지연 시간 데이터에 접근할 수 없는 상태에서 이러한 질문에 답변하려면, 네트워크 내의 방대한 링크와 노드를 조사해야 합니다.

신뢰할 수 있고 확장 가능한 네트워크 메쉬 모니터링 시스템 설계

블랙박스 방식의 네트워크 모니터링 시스템이 패킷 손실이나 지연 시간 급증을 효과적으로 감지하려면, 네트워크의 다양한 부분에 대해 지속적인 프로빙이 필요합니다. 데이터 센터 네트워크는 사용자 트래픽을 위해 노드 간 모든 링크를 활용합니다. 운영 네트워크 장치는 BGP를 실행하며, 여러 동등 비용 경로를 통해 트래픽을 부하 분산합니다. 정상적인 상황에서는 라우팅 테이블 업데이트를 통해 네트워크 토폴로지의 변화가 보통 몇 초 내에 반영됩니다. 네트워크 패킷 손실을 정확하게 측정하려면 테스트 프로브가 모든 네트워크 노드와 링크를 포괄하는 가능한 한 많은 경로를 통과해야 합니다. 전 세계 여러 사이트에 걸쳐 있는 당사와 같은 대규모 네트워크의 경우, 모든 노드 또는 랙 쌍을 대상으로 프로빙하는 것은 확장성이 떨어집니다. 가시성 수준을 저하시키지 않으면서도 지속 가능한 해결책으로, 우리는 각 사이트 내 랙 간 N² 메쉬와 모든 사이트 간 또 다른 N² 메쉬를 프로빙하는 방식을 선택했습니다.

네트워크 프로빙에는 무엇을 사용하나요?

테스트 프로브는 실제 운영 네트워크를 통과하는 트래픽을 모방해야 합니다. 우리 네트워크의 트래픽 대부분은 TCP, UDP 또는 HTTP이며, 이들 각각은 프로브로 사용될 수 있습니다. TCP 프로빙의 문제점 중 하나는 대규모 네트워크를 모니터링하는 데 필요한 연결 수만큼 확장하기에는 충분히 가볍지 않다는 점입니다. TCP의 또 다른 문제점은 내장된 흐름 제어 및 슬라이딩 윈도우 기반 전송으로 인해 프로브 전송 속도가 변동적이라는 점이며, 이는 순간적인 패킷 손실의 정량화나 탐지에 적합하지 않습니다. ping 및 traceroute에 사용되는 ICMP는 일반적으로 서버나 네트워크 노드에서 전송 속도가 제한됩니다. 이로 인해 사용할 수 있는 ICMP 프로브의 총 전송 속도가 제한됩니다. HTTP 요청은 애플리케이션 계층의 상위 계층에 위치하며, 서버나 애플리케이션 성능과 같은 네트워크 외부의 요인에 의존합니다. HTTP는 결과에 분리하기 어려운 추가적인 변수 요소를 더합니다. 이 시스템의 목표는 주로 OSI 계층 4 및 그 이하에서 작동하는 기반 네트워크 인프라의 성능을 모니터링하는 것입니다. 이러한 이유와 더불어 UDP가 우리 네트워크의 주요 전송 계층 프로토콜이라는 점 때문에 UDP 프로브를 선택했습니다.

어디에서 프로브를 전송할까요?

대규모 집계 프로브 속도를 달성하고 동시에 다수의 네트워크 경로를 커버하는 한 가지 방법은 가능한 한 많은 컴퓨팅 노드를 활용하여 프로브를 전송하는 것입니다. 여기에는 두 가지 장점이 있습니다. 첫째, 프로브를 생성하는 시스템의 부하를 분산시키는 데 도움이 되며, 둘째, 프로브를 전송하는 네트워크 포트 수를 늘릴 수 있습니다. 그러나 이를 위해서는 호스트 시스템의 리소스를 최대한 적게 차지하면서도 매우 안정적인 에이전트가 필요합니다. 동시에, 에이전트는 호스트 시스템의 CPU, 메모리 또는 I/O 사용률 변동에 영향을 받지 않으면서도 여러 경로에서 패킷 손실과 지연 시간을 정확하게 측정할 수 있어야 합니다. 에이전트는 경량성과 높은 성능 사이의 이 미묘한 균형을 지속적으로 유지해야 합니다.

네트워크 손실과 지연 시간을 어떻게 측정할까요?

이는 단일 프로브 스트림에 대한 사소한 계산처럼 보일 수 있지만, 대규모 환경에서는 즉각적으로 드러나지 않는 몇 가지 과제가 발생합니다. 이러한 대규모 메쉬로 확장하기 위해서는 에이전트가 수많은 스트림에 걸쳐 타임스탬프가 포함된 송신(Tx) 및 수신(Rx) 패킷 수를 동시에 빠르고 정확하게 계산해야 합니다. 네트워크 손실 지표에는 에이전트가 실행 중인 호스트의 CPU가 바쁘거나 네트워크 버퍼가 넘치는 상황에서 손실된 패킷이 포함되지 않도록 하는 것이 중요합니다. 네트워크 지연 시간은 I/O 버퍼에서 대기하거나 OS 스케줄링을 기다리는 에이전트 프로세스 대기 시간을 제외하고, 프로브가 유선 또는 중간 네트워크 노드에 머문 총 시간을 기준으로 계산해야 합니다.

Roblox의 Ping Mesh 시스템

퍼블릭 및 프라이빗 클라우드 인프라가 성장함에 따라 블랙박스 방식의 네트워크 패킷 손실 및 지연 시간 모니터링에 대한 필요성이 대두되었습니다. 그러나 당사의 대규모 네트워크에 확장 가능한 상용 솔루션을 찾기는 어려웠습니다. 여러 대형 클라우드 사업자와 네트워크 도구 제공업체들은 네트워크 패킷 손실 및 지연 시간을 모니터링하기 위해 자체 솔루션을 설계했습니다. 공개된 도구를 몇 가지 시도해 보았으나, 안정성과 확장성 문제를 겪었을 뿐만 아니라 네트워크 성능에 대한 가시성도 제한적이었습니다. 이에 따라 우리는 낮은 오버헤드로 저주파 오류를 더 잘 감지할 수 있는 자체 메쉬 모니터링 시스템을 구축하게 되었습니다. 우리 시스템의 주요 특징은 다음과 같습니다:

• 시스템의 모든 구성 요소를 구현하기 위해 Go 언어를 선택했으며, 이를 통해 최소한의 시스템 리소스를 사용하면서도 높은 수준의 성능을 달성할 수 있었습니다.
• 저희 에이전트는 매우 안정적이며, 트래픽, 캐싱, 애플리케이션 서버 등 Roblox 플랫폼에서 핵심 서비스를 수행하는 호스트를 포함하여 다양한 프로덕션 호스트에서 실행될 수 있습니다.
• 에이전트는 Linux의 sendmmsg() 및 recvmmsg() 시스템 호출을 Go 래퍼 함수로 묶어 패킷 I/O 작업을 일괄 처리하도록 최적화되어 있어, 낮은 오버헤드로 높은 속도의 프로브를 전송할 수 있습니다. 배포된 모든 에이전트는 초당 100패킷(PPS)의 속도로 최대 100개의 다른 호스트에 동시에 프로브를 전송합니다. 에이전트는 매초 각 대상에 패킷 버스트를 전송합니다.
• 프로브는 각 대상에 대해 IP 헤더에 서로 다른 서비스 유형(TOS) 필드 값을 포함하며, 네트워크상의 패킷 손실 및 지연 시간을 별도로 집계합니다. 각 패킷 버스트에는 다른 모든 대상에 대해 여러 TOS 값이 혼합되어 포함됩니다. 이는 다양한 서비스 품질(QoS) 클래스에 대한 네트워크 성능을 모니터링하는 데 도움이 됩니다.
• 에이전트는 각 프로브 경로에서 분당 6,000개 패킷 중 1개에 해당하는 낮은 수준의 네트워크 패킷 손실도 감지할 수 있습니다. BGP 플랩(flap) 발생 시와 같이 네트워크 코어 또는 에지에서 1초 미만으로 지속되는 패킷 손실도 감지할 수 있습니다.
• 프로브 패킷 손실 차트는 오류가 손실의 원인일 때 네트워크 장치 인터페이스 오류율 차트와 유사합니다. 이를 통해 탐지하기 어려운 네트워크 내 트래픽 블랙홀링 버그를 발견할 수 있었습니다.
• 에이전트는 NIC 커널 읽기 타임스탬프를 사용하여 네트워크 지연 시간 측정에서 높은 정확도를 달성합니다. 호스트 OS 스케줄링 지연 시간과 네트워크 클럭 드리프트를 배제하면서도, 사이트 내 일관된 왕복 지연 시간을 50~100마이크로초로 측정할 수 있습니다.
• 낮은 CPU 사용률과 메모리 점유율. 에이전트는 최대 송수신 속도(각 5 kpps)에서도 단일 코어의 25% 미만을 사용합니다. 배포된 대부분의 에이전트는 코어의 약 5%만 사용합니다. 에이전트의 송수신 패킷 버퍼와 카운터를 관리하는 데 필요한 힙 메모리는 10MB에 불과합니다. 네트워크가 확장될 경우, 제한값을 조정하거나 에이전트를 추가하여 수직 또는 수평 확장이 가능합니다.
• 호스트 시스템이 부하를 받을 때 에이전트가 영향을 받는 경우는 거의 없습니다. 호스트 CPU 부하가 99%에 근접한 상황에서도 여러 차례 정확한 결과를 얻었습니다.
• 각 에이전트로부터 텔레메트리 데이터를 수집하여 상태를 모니터링합니다. 에이전트는 호스트 시스템 재부팅, 에이전트 프로세스 재시작, 소켓 버퍼 오버플로로 인한 패킷 손실과 같은 문제 상황을 식별할 수 있습니다.

에이전트는 네트워크 프로빙에 참여하는 노드 수를 충분히 확보하기 위해 Chef를 사용하여 광범위한 서버 클러스터에 배포됩니다. 에이전트 바이너리는 Linux에서 systemd를 통해 실행 및 관리되므로, 호스트 재부팅이나 에이전트 업그레이드 후 자동으로 재시작됩니다. 메쉬 스케줄러는 에이전트 중 하나가 다운되거나 새로운 에이전트가 가동될 때 필요에 따라 스트림을 동적으로 감지하고 조정합니다. 저희 스케줄러 애플리케이션은 Intra-Pod, Intra-Site 및 Inter-Site 프로빙을 위한 대상을 할당하기 전에, 새로운 에이전트와 서버의 상태 정보를 감지하기 위해 장치 인벤토리와 서비스 디스커버리 시스템을 주기적으로 폴링합니다. 메시지 버스를 사용하여 테스트 프로브를 전송하는 각 에이전트에 대상 호스트 목록을 전달합니다. 특정 랙에서 시작하거나 종료되는 개별 스트림은 해당 랙 내의 사용 가능한 모든 에이전트에 분산됩니다. 이를 통해 아래 그림에서 볼 수 있듯이 네트워크 패브릭 내에서 대량의 동등 비용 경로를 효과적으로 활용할 수 있습니다.

첫 배포 당시 150개의 에이전트로 시작하여, 현재는 그 규모를 10배로 성공적으로 확장했습니다. 이 메시 네트워크는 전 세계에 분산된 25개 사이트를 연결하는 백본을 포괄합니다. 주요 데이터 센터 사이트 중 한 곳에는 200개 이상의 랙을 아우르는 사이트 내 메시가 구축되어 있으며, 약 33,000개의 스트림이 집계되어 1.65 Mpps의 프로브 속도를 기록합니다. 각 랙은 다른 랙으로부터 5~10 kpps의 프로브를 수신합니다. 스케줄러 애플리케이션은 35,000개 이상의 타깃을 계산하여 서로 다른 사이트에 위치한 모든 에이전트에 고르게 분배합니다.

데이터 수집 및 시각화

저희는 별도의 수집기 애플리케이션을 운영하여 모든 Ping Mesh 에이전트로부터 패킷 손실 및 지연 시간 결과를 주기적으로 폴링합니다. 이 데이터는 수집기에 로컬로 캐시된 상태 정보를 기반으로 무효한 결과를 자동으로 필터링하여 제외합니다. 예를 들어, 상태 점검에 응답하지 않은 서버나 방금 재부팅된 서버에서 실행 중인 에이전트의 결과는 제외합니다. 당사의 수집기는 1,500개 이상의 노드에서 결과를 동기식으로 폴링 및 필터링한 후, 2초 이내에 시계열 데이터베이스로 데이터를 수집할 수 있습니다.

집계된 결과와 스트림별 결과 모두 Grafana 대시보드를 통해 시각화됩니다. 히트맵 그리드는 특히 대규모 데이터 센터 사이트와 같이 방대한 데이터 세트의 경우 활용하기 어려울 수 있습니다. 따라서 당사는 Prometheus의 topk() 쿼리를 활용하여 수천 개의 결과 중 개별 패킷 손실이 가장 높은 경로를 표시하며, 일반적으로 이러한 경로는 극소수에 불과합니다. 결과는 수집기가 빈번하게 폴링하는 에이전트 및 호스트 시스템 상태 통계와 대조하여 광범위하게 검증됩니다. 이를 통해 패킷 손실 변동 폭이 얼마나 크든 상관없이 각 개별 결과에 대해 높은 신뢰도를 확보할 수 있습니다. 개별 결과를 종합적으로 살펴보면 네트워크 장애가 발생한 위치를 파악하는 데 단서를 얻을 수 있습니다. 당사의 메쉬 모니터링 시스템이 포착한 패킷 손실 사례 몇 가지를 아래에 보여드립니다.

요약 및 향후 계획

당사의 Ping Mesh 시스템은 네트워크 엔지니어링 팀이 종단 간 패킷 손실 및 지연 시간을 모니터링하는 데 있어 강력한 도구로 활용되어 왔습니다. 이 데이터를 통해 "네트워크에서 패킷이 손실되고 있는가?"라는 질문에 즉각적으로 답할 수 있습니다. 당사의 경험에 따르면, 고객에게 중대한 영향을 미치는 주요 네트워크 사고는 대개 장치 원격 측정 모니터링 시스템을 통해 탐지되고 경고됩니다. 네트워크 버퍼링이나 고립된 트래픽 블랙홀링과 같이 영향은 적지만 잠재적으로 문제가 될 수 있는 사안들은 이 시스템을 통해 드러납니다.

또한 당사의 시스템은 Roblox 클라우드 네트워크의 전반적인 안정성에 대한 통찰력을 제공합니다. 주요 데이터 센터 사이트 중 한 곳에서는 분당 1억 개 이상의 프로브가 네트워크 상태를 모니터링하고 있으며, 분당 50개 이상의 패킷 손실이 발생하는 경우는 거의 없습니다. 이는 당사 데이터 센터 네트워크의 안정성이 약 6개의 9(99.9999%) 수준임을 나타냅니다. 1억 개의 패킷 중에서 패킷 손실이 전혀 감지되지 않는 경우도 매우 흔합니다. 상당량의 패킷이 손실될 경우, 이 시스템은 패킷 손실이 발생한 위치와 지속 시간을 파악할 수 있게 해줍니다. 자동 복구 엔진은 네트워크를 자체적으로 복구하며, 사용자 트래픽을 네트워크 내 다른 경로로 재전송함으로써 추가적인 패킷 손실을 방지합니다. 로블록스의 네트워킹 팀은 매우 신뢰할 수 있는 클라우드 네트워크를 구축했습니다.

향후에는 분석 엔진을 활용하여 디바이스 텔레메트리, 시스템 로그 및 기타 데이터 세트의 정보를 상호 연관시킬 계획입니다. 이를 Ping Mesh 데이터와 비교하여 네트워크 장애 발생 지점을 정확히 파악할 수 있도록 지원할 예정입니다. Roblox의 클라우드 네트워크가 지속적으로 확장 및 발전함에 따라, IPv6 및 점보 프레임을 포함하도록 프로빙 메커니즘을 강화하고, 사이트 간 커버리지를 높이기 위해 더 많은 에이전트를 추가할 계획입니다.