Home 기술 문서 RTT 메트릭을 사용하여 스트리밍 성능을 개선하는 방법
Applications

RTT 메트릭을 사용하여 스트리밍 성능을 개선하는 방법

About The Author

Outline

비디오의 고품질 스트리밍은 끊임없이 변동하는 워크로드를 관리하거나 다수의 시청자가 동시에 스트림에 진입할 때 “플래시 크라우드”를 처리하는 등 수백만 가지의 문제가 제대로 진행되고 있는지에 달려 있습니다. 시청자가 TV와 같은 경험을 기대하는 유료 서비스의 일부로 안정적인 고품질 비디오 스트림을 전송하려면 성능 문제를 세밀하게 설명할 수 있는 도구와 지표가 필요하기 때문에 문제 해결 방법과 위치를 파악할 수 있어야 합니다.

CDN은 전 세계적으로 지연 시간이 짧은 온디맨드 확장성을 제공하므로 비디오 스트리밍에 필수적인 솔루션입니다. CDN은 방식을 개선하는 최적화 기능 외에도 라이브 스트림을 동반할 수 있는 혼란스러운 시청자 증가에 균형을 맞추기 때문에 최종 사용자에게 우수한 성능을 제공하려면 가시성, 메트릭, 도구 및 자동화의 추가 계층이 필요합니다.

이 게시물에서는 다음을 비롯하여 대규모 북미 vMVPD 스트리밍 서비스에 대해 최근에 수행한 성능 최적화의 예를 살펴보겠습니다.

  • 성능 문제를 개선/수정하는 데 사용하는 메트릭
  • 성능 정의 방법 및 측정 방법
  • 비디오 성능 향상을 위해 지속적인 최적화 수행

자율 시스템 번호 : 커튼 뒤의 복잡성

최신 웹은 ASN(자율 시스템 번호)이라고 하는 여러 개의 상호 연결된 네트워크 계층을 기반으로 구축되며, 각 계층은 대규모 IP 주소 그룹과 CDN(콘텐츠 전송 네트워크)으로 구성되어엣지에서 콘텐츠를 제공함으로써 혼잡을 줄입니다. 본질적으로 아래 그림과 같이 인터넷은 각각 고유한 비즈니스 모델과 우선 순위를 가진 네트워크 네트워크로 구성됩니다.

출처: 연구 문

서로 상호 작용하는 ASN의 내재적 복잡성과 결합하여 범위와 규모가 매우 넓습니다. vizAS 도구는 여러 ASN 간의 상호 연결을 국가별로 시각화하려고 시도합니다. 예를 들어, 미국에서만 네트워크 전반에 걸쳐 16,979개의 ASN과 24,905개의 피어링 관계가 있습니다. 전 세계적으로 90,000개 이상의 ASN이 있습니다.

https://stats.apnic.net/vizas/index.html

CDN 제공업체로서 주니퍼의 관점에서 볼 때, 수천 개의 ASN에 연결하는 데 수반되는 복잡성은 각 고객의 성능 요구 사항, 사용 프로필, 트래픽 유형 및 기타 여러 요인을 수용해야 하는 필요성으로 인해 더욱 복잡해집니다. 예를 들어, 트위터와 같은 서비스는 주요 업데이트를 추진하는 게임 회사와 훨씬 다른 사용 프로필 또는 풋프린트를 갖습니다. 마찬가지로 라이브 스포츠 이벤트를 스트리밍하는 방송사는 주문형 스트리밍 서비스와 프로필이 다릅니다. 두 개의 라이브 스트리밍 서비스조차도 프로필이 다를 수 있으며 각 서비스마다 맞춤형 성능 최적화가 필요합니다.

백그라운드에는 고객이 성능 목표와 요구 사항을 달성할 수 있도록 조정하고 조정할 수 있는 다양한 구성 설정이 있습니다. 어떤 사람들에게는 처음부터 기대했던 성능(또는 더 나은 성능)이 될 수 있으며, 우리는 아무것도 변경할 필요가 없습니다. 스트리밍 서비스에 대한 중요한 메트릭인 Faster TTFB(Time to First Byte)와 같은 특정 목표가 있을 수 있습니다.

인터넷의 복잡성과 크기를 감안할 때, “두더지”또는 산란 접근 방식을 통해 유용하고 일관된 성능 향상을 제공하는 것은 불가능합니다. 문제의 근본 원인을 파악하거나 네트워크 구성 변경 사항에 대한 사전 통찰력을 확보하기 위해 포괄적인 데이터 수집 및 집중적인 데이터 분석을 통해 실질적인 이득을 얻을 수 있습니다.

Stargazer를 통한 RTT 인사이트 제공

네트워크 지연 시간과 전반적인 성능 상태를 결정하는 가장 중요한 지표 중 하나는 RTT(왕복 시간)입니다. 이것은 밀리초 단위로 측정되는 지속 시간으로 정의되며, 소스에서 대상으로 전달되는 패킷과 소스로 다시 전송되는 응답을 사용합니다. 정체, 하드웨어 문제, 구성 오류, 라우팅 문제 등 여러 벡터에 걸쳐 네트워크 성능을 진단하고 개선하는 데 사용할 수 있습니다.

이 지표의 중요성을 감안할 때, 우리는 Stargazer라는 내부 시스템을 구축하여 센서, 고객으로부터 가져온 데이터 및 RTT 정보를 모니터링하는 제3자를 포함한 다양한 소스의 RTT 데이터를 집계합니다. Stargazer는 클라이언트로의 아웃바운드 응답 시간을 모니터링합니다. 다른 데이터 소스로는 라우터의 BGP(Border Gateway Protocol) 테이블, 지리적 위치에 라우터 매핑, 클라이언트 연결을 위한 RTT 로그, 트래픽 볼륨 정보 등이 있습니다. 또한 필요한 경우 시스템에서 트레이스 루트 및 핑 같은 활성 프로브를 수행할 수 있습니다.

모니터링 활동의 이면에서는 Stargazer가 개발한 다른 도구와 함께 수집한 모든 데이터를 쿼리하고 심층적인 분석을 수행하여 지속적인 개선의 문을 열 수 있습니다. 네트워크 관리자는 이 정보를 사용하여 문제를 격리하고 네트워크 경로 또는 구성을 식별하여 특정 고객 목표와 요구 사항에 맞게 성능을 최적화할 수 있습니다. 또한 BBR(Bottleneck Bandwidth and Round-Trip Propagation Time) 프로토콜과 같은 신기술이 성능에 미치는 영향을 이해하는 데에도 유용합니다.

오리진 서버 최적화

성능 최적화가 실제로 어떻게 작동하는지에 대한 더 많은 통찰력을 제공하기 위해, 멀티 CDN 아키텍처 에 맞게 최적화해야 하는 최근 추가된 라이브 비디오 스트리밍 고객을 대상으로 한 예를 살펴보겠습니다. 기존 CDN 클라이언트 아키텍처에서는 클라이언트가 PoP 중 하나에 요청을 보내고 POP 캐시는 아래와 같이 오리진에서 채워집니다.

그러나 이 고객은 중복성과 복원력을 높이고 잠재적으로 성능을 높이기 위해 멀티 CDN 아키텍처를 활용하기로 결정했습니다. 이 기능은 그림 4에 표시된 오리진 쉴드 아키텍처에 의해 활성화됩니다. Origin Shield는 최상의 성능을 위해 다양한 클라이언트의 트래픽을 라우팅할 수 있는 방법을 보다 세밀하게 제어합니다.

기존의 CDN 관계와는 달리, 두 번째 CDN에서 처리되는 트래픽을 포함한 모든 트래픽은 캐시 채우기를 위해 애틀랜타에 위치한 PoP(AGA) 중 하나로 다시 전송됩니다. 그런 다음 AGA POP는 오리진 또는 더 구체적으로 오리진 쉴드로 작동하여 고객의 오리진 서버에서 상당한 부담을 덜어줍니다. AGA POP는 두 번째 CDN보다 캐시 적중률과 성능이 높아 오리진 쉴드 위치로 선택되었습니다. 그러나 두 CDN 간의 성능을 최적화하는 것이 가장 큰 문제였습니다.

이 프로세스의 첫 번째 단계는 두 번째 CDN이 AGA로의 경로를 최적화하여 오리진 쉴드 역할을 하는 것입니다. CDN 간의 성능 저하와 TTFB에 영향을 주는 많은 연결 시간 초과가 바로 눈에 띄는 문제 중 하나였습니다. 성능 문제를 조사하기 위해 Stargazer를 사용하여 AGA에서 원하는 목적지로 추적 루트를 전송하고 모든 홉에 사용되는 ASN을 캡처했습니다.

아래 요약에 표시된 것처럼 클라이언트의 경로를 시뮬레이션하여 AGA에서 두 번째 CDN의 IP 주소로 traceroute가 전송되었습니다.

우리는 ASN 7018 내에 여러 홉이 있음을 발견했는데, 이는 더 많은 홉을 포함하고 더 많은 혼잡을 가지고 있기 때문에 선호되는 경로가 아니었습니다. Stargazer를 사용하여 신속하게 문제를 확인하고 적절한 네트워크 변경을 수행했습니다. 아래의 traceroute 요약에서 알 수 있듯이, 네트워크 변경 후 ASN 7922로 전환하여 홉 수를 줄이고 RTT를 개선하여 TTFB 시간 초과와 관련된 문제를 해결했습니다.

다른 예에서는 Stargazer 도구를 사용하여 동부 해안에 위치한 고객의 오리진 서버에 대한 최상의 오리진 차폐 경로를 결정했습니다. 고객의 오리진에 대한 부하를 효과적으로 줄이고 배송 성능을 향상시키려면 오리진 쉴드 POP가 오리진 가까이에 있어야 합니다. 때로는 가장 잘 작동하는 가장 가까운 물리적 팝이 아닐 수도 있습니다. 가장 적은 ASN, 가장 적은 정체, 낮은 RTT 시간의 조합입니다. 아래 차트에서 볼 수 있듯이, Stargazer 추적 루트는 NYA (뉴욕) POP에서 DCC (워싱턴 D.C.) POP로 이동하면 홉 수가 3 개로 감소하여 RTT 성능이 전반적으로 향상되었습니다.

Sweeper Fish를 사용한 심층 분석

전 세계 CDN에서 7,000개 이상의 인터커넥트와 300개 이상의 PoP를 통해 수많은 최적화 작업이 진행되고 있습니다. 큰 차이를 가져오지 않을 수 있는 업무에서 바퀴가 회전하지 않도록 하기 위해 우리는 운영 팀이 취하는 조치의 우선 순위를 결정할 수 있는 효율적인 방법이 필요했습니다. 이러한 필요성은 Stargazer의 동반자 도구인 Sweeper Fish를 개발하여 문제가 존재하는 장소를 점수하고 우선 순위를 정하여 버블업할 수 있게 했습니다.

Sweeper Fish는 경로가 혼잡한지 여부와 문제를 일으킬 가능성이 있는지를 결정하는 데에도 유용합니다. 다중 CDN 예로 돌아가서 Sweeper Fish를 사용하여 정체가 발생한 경로를 파악했습니다. 이를 위해 Sweeper Fish는 AGA POP에 대한 모든 경로에 대한 모든 클라이언트의 RUM(Real User Measurement) 데이터에 대해 25-75번째 백분위수 사이의 델타를 측정하여 두 번째 CDN의 경로 ASN7922에 초점을 맞췄습니다. 이 ASN을 통한 모든 트래픽의 표준 편차는 다음과 같습니다.

또한 ASN7018을 통한 이전 구성이 올바른 방법이 아니었음을 확인했습니다. 스위퍼 피쉬(Sweeper Fish) 분석에 따르면 IQR(사분위 범위)은 이 경로의 정체로 인해 20-60에서 밀리초까지 급증했습니다(그림 9 참조). 미드스프레드 또는 중간 50%라고도 하는 IQR은 경로를 분석하고 문제를 신속하게 플래그할 수 있는 유용한 방법을 제공합니다. IQR이 낮을수록 좋습니다.

반면, AGA POP는 아래 그림과 같이 ASN7922를 사용한 경로에서 지속적으로 10-22밀리초 사이였습니다. Sweeper Fish는 서로 다른 ASN을 비교함으로써 가장 적고 혼잡한 경로를 선택하거나 교정을 위한 문제를 식별할 수 있게 해줍니다.

TCP 튜닝

또한 정체는 패킷을 삭제하고 재전송하도록 합니다. POP 사이의 경로가 멀리 있고 TCP 알고리즘이 최적화되지 않은 경우에 발생합니다. AGA가 우리 예의 근원이었기 때문에 AGA에 도달한 원거리 팝이 이 문제를 가질 수 있었습니다. 여러 POP에 분산되어 있지만 아래에 집계된 CDN 로그를 통해 상자에 표시된 문제 영역을 식별할 수 있습니다.

그림 11. 집계된 서버 로그는 패킷이 삭제되고 재전송되는 문제 영역을 신속하게 식별합니다.

BBR 평가

BBR(Bottleneck Bandwidth and Round-Trip Propagation Time)은 Google에서 개발한 대체 TCP 혼잡 제어 알고리즘으로, 견인력을 얻기 시작했습니다. 유비쿼터스 TCP-Cubic과 같은 손실 기반 정체 제어 알고리즘과 다르며 다른 운영 패러다임을 도입합니다. 버퍼 팽창을 방지하기 위해 세션에서 지금까지 확인한 최소 RTT를 기반으로 전송 가능한 데이터 양을 지속적으로 업데이트합니다.

분석에 따르면 BBR은 RTT 성능을 개선하는 데 유용하지만 보편적인 솔루션에는 미치지 못하는 것으로 나타났습니다. 당신이 그것을 사용하고 싶을 때도 있고, 그렇지 않을 때도 있다. Stargazer는 일정 기간 동안 목적지에 대한 일관된 RTT 프로필을 추적하여 언제 사용할지 결정하는 데 도움이 됩니다. 이를 통해 BBR을 적용할 최적의 장소를 결정하여 재전송을 줄이고 흐름 제어를 개선할 수 있습니다.

아래 차트에 나타난 분석 결과를 토대로 BBR로 전환하면 두 번째 CDN 및 고객 오리진에 대한 AGA POP의 성능이 약간 향상될 수 있다는 결론을 내렸습니다. 첫 번째 그래프 세트는 TCP-Cubic에서 TCP BBR로 변경하면 재전송이 감소함을 보여 주며, 두 번째 그래프 세트는 BBR로의 변경으로 평균 처리량이 약간 증가했음을 나타냅니다.

그림 12. 이 예에서 TCP-Cubic에서 TCP BBR로 변경하면 재전송이 감소했습니다.

그림 13. 이 예에서 AGA POP를 위해 TCP-Cubic에서 흐름 제어를 위해 BBR로 전환하면 재전송이 감소하고 평균 처리량이 약간 개선되었습니다.

결론

인터넷은 광대하고 복잡하며 본질적으로 네트워크의 네트워크입니다. 현재 Edgio인 Edgecast의 경우, 문제 영역에 대한 통찰력을 얻고 가능한 구성 변경을 테스트하기 위한 심층적인 분석이 없이는 고객 사용 사례에 대한 성능 최적화가 거의 불가능에 가깝습니다. 고객의 성능을 개선하기 위해 RTT를 지속적으로 모니터링할 수 있는 강력한 도구 모음을 개발하여 네트워크 전반을 빠르고 효율적으로 개선할 수 있습니다. 라이브 비디오 스트리밍 서비스의 경우 고유한 요구 사항에 맞게 성능을 최적화하는 동시에 애플리케이션에 대한 BBR 사용을 평가할 수 있는 방법을 찾았습니다. 그 결과 두 개의 CDN을 활용하는 고성능 스트리밍 솔루션이 탄생했습니다. 그리고 아직 끝나지 않았습니다. 네트워크 혼잡이 계속 증가함에 따라 고객과 고객이 가능한 최상의 온라인 경험을 누릴 수 있도록 네트워크 최적화를 중단하지 않을 것입니다.