Home 기술 문서 대규모 CDN에서의 BBR 평가
Applications

About The Author

Outline

BBR(Bottleneck Bandwidth and Round-Trip Propagation Time)은 TCP 혼잡 제어 알고리즘으로, 많은 콘텐츠 제공업체에서 보고한 바와 같이 더 높은 처리량을 제공할 수 있기 때문에 시장의 주목을 받고 있습니다. 이 게시물에서는 BBR(버전 1)을 Verizon Media의 현재 Edgio의 CDN(콘텐츠 전송 네트워크) 워크로드의 맥락에서 평가하여 대용량(수 Tbps)의 소프트웨어 업데이트와 스트리밍 비디오를 제공하고 트래픽에 미치는 이점과 영향을 수치화합니다. Akamai는 대규모 CDN에서 이러한 평가를 실시함으로써 다른 콘텐츠 제공업체가 트래픽에 적합한 정체 제어 프로토콜을 선택하는 데 도움이 되기를 바랍니다.

배경

많은 콘텐츠 제공업체와 학술 연구자들은 BBR이 TCP-Cubic과 같은 다른 프로토콜보다 더 큰 처리량을 제공한다는 사실을 발견했습니다. 유비쿼터스 TCP-Cubic과 같은 손실 기반 정체 제어 알고리즘과 달리 BBR은 다른 작동 패러다임을 가지고 있습니다. 즉, 버퍼블로트를 피하기 위해 세션에서 지금까지 관찰한 최소 RTT를 기반으로 얼마나 많은 데이터가 전송될 수 있는지를 지속적으로 업데이트합니다. BBR의 작동에 대한 자세한 내용은 Google의 원본 출판물을 살펴 보시기 바랍니다 .

측정 및 분석

CDN에서 BBR의 잠재력을 파악하기 위해 여러 단계에서 BBR을 평가하여 몇 가지 PoP(Points of Presence)에서 TCP 흐름에 미치는 영향을 측정했습니다. POP는 대규모 대도시 지역에 위치한 캐싱 서버의 집중도를 나타냅니다. 처음에는 POP에서 소규모 BBR 테스트를 수행했으며 BBR을 실행하는 클라이언트로의 모든 흐름을 포함하여 전체 POP 테스트를 수행했습니다. 클라이언트가 경험할 수 있는 이점을 파악하기 위해 테스트 중에 사내 프록시 웹 서버 로그와 소켓 수준 분석을 통해 처리량을 측정했습니다.

평가할 메트릭

주니퍼의 멀티 테넌트 CDN은 매우 다양한 클라이언트 트래픽을 감지합니다. 많은 고객들이 작은 개체를 많이 가지고 있는 반면, 다른 고객들은 훨씬 더 큰 수 기가바이트 개체를 가지고 있습니다. 따라서 다양한 트래픽 패턴에서 실제 성능 향상을 포착하는 성공 지표를 파악하는 것이 중요합니다. 특히 이 평가를 위해 성공 매개 변수로 처리량과 TCP 흐름 완료 시간을 식별했습니다. 그림 1에서는 CDN에서 요청한 일반적인 개체 크기와 이를 제공하는 데 걸린 시간의 열 지도를 보여 줍니다. 색 그라데이션은 각 범주의 요청 수를 나타냅니다. 이러한 숫자는 일반적인 동작만 포착하기에 충분한 소규모 서버 집합의 대표적인 숫자입니다.

그림 1. 일반적인 개체 크기를 보여 주는 열 지도

Heat Map을 통해 다양한 요청 패턴을 파악할 수 있습니다. 일반적으로 더 높은 처리량을 얻는 것이 성능 향상을 나타내는 가장 좋은 지표입니다. 그러나 측정으로서의 처리량은 특히 개체 크기가 작은 경우(몇 MB 미만) 매우 노이즈가 발생할 수 있습니다. 따라서 어떤 크기가 가장 안정적인 처리량 평가를 제공하는지에 대한 별도의 평가에 기초하여 처리량 평가에는 3MB보다 큰 개체 크기만 사용합니다. 개체 크기가 3MB 미만인 경우 흐름 완료 시간을 추적하는 것이 더 나은 메트릭입니다.

평가의 첫 번째 단계로, 로스앤젤레스의 POP에서 몇몇 서버에서 BBR을 활성화하고 모든 TCP 흐름의 처리량과 흐름 완료 시간을 모니터링했습니다. 다음 결과는 몇 가지 인터넷 서비스 제공업체별 사례 연구를 검토합니다.

대규모 무선 통신 사업자

그림 2는 BBR을 켠 후의 차이를 보여줍니다.

그림 2. BBR을 켜면(테스트) 입방 흐름(제어) 대비 대형 무선 공급자의 클라이언트에 대한 처리량 영향 왼쪽: 2일 동안의 처리량 측정. 파란색 수직선은 BBR이 활성화되었음을 나타냅니다. 여기서는 BBR 사용 시 전체적으로 약 6-8%의 개선을 확인할 수 있습니다. 오른쪽: 5백분위수 처리량의 CDF입니다. BBR 흐름은 현저한 개선을 보여준다.

이 무선 공급자의 경우 BBR을 활성화하자마자 평균 6-8% 처리량이 개선되었습니다. 전체적으로 TCP 흐름 완료 시간도 낮았습니다. 이 결과는 Spotify, Dropbox 및 YouTube의 다른 보고서와 일치하며, 패킷 손실이 흔한 무선 네트워크에서 처리량이 명확하게 증가하지만 이것이 반드시 혼잡의 지표는 아닙니다.

대규모 유선 공급자

다음으로 대규모 유선 서비스 제공업체의 성능을 조사했습니다. 여기서도 처리량(대형 객체의 경우)과 흐름 완료 시간(그림 3 참조)을 모두 확인했습니다. BBR 사용 개선.

그림 3. 대형 유선 공급자의 흐름을 완료하는 데 걸린 평균 시간입니다. BBR(테스트) 흐름은 지터가 적고 데이터 전송을 완료하는 데 걸리는 시간이 적습니다. 이점은 큰 물체에 더 큰 영향을 미칩니다. 그러나 입방 및 BBR 모두에 대해 큰 파일 크기에 대해 유사한 지터가 나타납니다.

이러한 테스트에서 보고된 이득은 클라이언트 측 트래픽에 매우 유망한 결과를 보여줍니다.

이러한 이득은 집계된 관점에서 볼 수 있기 때문에, 우리는 POP의 모든 TCP 흐름이 BBR을 사용하는 이점이 있는지, 또는 일부 TCP 흐름이 손상되었는지, 그리고 어떤 것들이 발생했는지를 확인하기 위해 좀 더 깊이 파고들기로 결정했습니다.

CDN 엣지에서는 네 가지 유형의 TCP 세션을 수행합니다.

  • 클라이언트 팝업(위 그림 참조)
  • POP-to-POP(데이터 센터 간)
  • POP 내 통신(동일한 POP의 캐시 간)
  • POP-to-Origin(고객 오리진 데이터 센터에 대한 POP)

본 연구에서는 에지-투-오리진(edge-to-origin)이 다른 세 가지 유형만큼 볼륨이 크지 않기 때문에 POP-to-Client, POP-POP 및 인트라-POP 흐름을 고려했습니다.

팝-팝 및 인트라-팝 트래픽

대부분의 경우 이러한 흐름은 동적 콘텐츠와 같은 클라이언트 전송을 차단하기 때문에 이러한 TCP 흐름에 미치는 영향을 평가하는 것이 중요합니다.

Pop-to-Pop 및 Intra-Pop 트래픽 처리량의 경우 성능이 크게 저하되었습니다. 그림 4는 동일한 기간 동안 POP 및 POP 간 트래픽에 미치는 영향을 보여줍니다.

그림 4. BBR을 켜면(테스트) 입방 흐름(제어) 대비 인트라 팝 및 팝-팝 트래픽의 처리량 영향 2일 동안의 처리량 측정 파란색 수직선은 BBR이 활성화되었음을 나타냅니다. BBR 사용 시 처리량이 절반 가량 감소했습니다.

최종 사용자에게 전달되는 플로우와 데이터 센터 간의 이러한 분명한 성능 차이는 이전 연구 결과에서 보고되지 않았습니다. 우리는 이러한 특정 TCP 흐름이 왜 발생했는지, 이것이 CDN의 하드웨어 또는 구성 아티팩트인지, 그렇다면 어떤 튜닝을 변경해야 하는지 평가해야 합니다.

웹 서버 액세스 로그와 서버 측 소켓 데이터로부터의 평가를 사용한 추가 조사에서, 높은 RTT 흐름과 낮은 RTT 흐름이 존재할 때 매우 낮은 RTT를 가진 TCP 흐름이 BBR을 사용함으로써 고생하는 것으로 나타났습니다. 0.5KB 미만의 데이터가 전송된 사례를 추가로 평가한 결과, 대부분의 경우 BBR이 Cubic과 유사하게 수행되는 것으로 나타났습니다.

이러한 결과를 바탕으로 트래픽 패턴의 경우 RTT 및 손실이 낮은 인트라 팝 및 팝 대 팝 통신에 Cubic을 사용하는 것이 더 낫다는 결론을 내렸습니다. 클라이언트 측 트래픽의 경우 BBR을 사용하는 것이 좋습니다.

풀 POP 테스트

BBR의 성능 이점을 대규모로 평가하기 위해 리우데자네이루의 POP에서 해당 POP에서 네트워크에서 클라이언트와 대면하는 모든 트래픽에 대해 풀 POP 테스트를 실시했습니다. 이 POP는 지역의 위치 및 피어링 제약으로 인해 다른 지역보다 고객이 경험하는 평균 RTT가 더 높기 때문에 흥미로운 사례 연구를 만들었습니다.

그림 5. 높은 재전송(ASN1)을 보여 주는 클라이언트용 BBR을 사용한 처리량 개선

정체 제어 알고리즘의 변경 사항을 배포하고 성능을 모니터링했습니다. RIO에서 상위 2개 ASE(Autonomous Systems)에 대해 BBR과 Cubic을 사용하여 관찰된 처리량의 CDF가 나와 있습니다. 그림 5에서 보는 바와 같이, A는 전체적으로 BBR의 장점을 보았고 다른 AS는 그렇지 않았다.

그 근거를 조사하기 위해 ss 유틸리티를 사용하여 테스트 중에 수집된 다른 TCP 메트릭을 찾아보았습니다. 이러한 두 ASE 간의 재전송 속도에서는 명확한 차이가 나타납니다. RTT가 높은 ASE라 하더라도 재전송 횟수가 많은 경우에만 BBR이 잘 수행됩니다. 즉, Cubic 손실이 적은 ASE는 BBR보다 Back-off 할 이유가 없고 성능이 더 좋다. 그러나 TCP Cubic의 많은 매개 변수가 CDN에서 신중하게 조정되었다는 점에 유의해야합니다.

다음으로, 그림 5에 표시된 ASN1의 모든 연결이 처리량이 개선되었는지 조사했습니다. 그림 6은 서로 다른 개체 크기에 대해 BBR 및 큐빅 연결에 걸린 시간(낮을수록 처리량이 높음)을 나타낸 것입니다. 여기서 우리는 BBR이 MB 순서대로 더 큰 객체에 대해 눈에 띄는 이점을 보여주기 시작했다는 것을 알 수 있습니다. BBR을 사용하는 한 가지 변칙적인 사례가 발견되었지만 특정 혼잡 제어 프로토콜 관련 문제로 귀속시킬 수는 없었습니다.

그림 6. 개선을 보인 ASE의 경우 BBR의 이점은 대용량 파일이 있는 장기 실행 플로우에서 확인할 수 있습니다.

왜 이런 일이 발생합니까?

이러한 결과에는 입방 대 BBR 및 BBR과 BBR의 두 가지 차원이 있습니다.

큐빅 vs. BBR

BBR은 병목 현상 대역폭을 예측할 때 버퍼 크기와 RTT에 매우 반응합니다. 미들박스가 대기열을 형성할 수 있는 큰 버퍼의 경우 BBR의 추정 RTT가 증가합니다. 패킷 손실이 없기 때문에 큐빅은 이러한 경우, 즉 팝투팝 스타일의 트래픽을 취소하지 않으므로 큐빅은 더 높은 처리량을 달성합니다. 무선 클라이언트와 같은 작은 버퍼의 경우 버퍼가 빠르게 채워져 손실이 발생하므로 입방 흐름이 역류하고 BBR 흐름이 더 잘 수행됩니다.

BBR과 BBR 비교

이 시나리오에서는 손실이 있을 때 흐름이 역행하지 않습니다. 그러나 서로 다른 RTT를 가진 두 개의 흐름이 대역폭 공유를 위해 경쟁할 때, 더 높은 RTT를 갖는 흐름은 또한 더 큰 최소 RTT를 가지므로 더 높은 대역폭-지연 산물을 갖게 된다. 따라서 이 흐름은 RTT가 낮은 흐름보다 훨씬 빠른 속도로 기내 데이터를 증가시킵니다. 이로 인해 RTT의 내림차순으로 흐름에 대역폭이 재할당되고 RTT가 높은 흐름은 작은 RTT를 가진 흐름보다 버퍼를 빠르게 채웁니다.

실험실 환경에서 결과 재현

플로우 간의 상호 작용에 대한 이해를 높이기 위해 운영 환경에서 관찰한 동작을 캡처하는 테스트 베드 환경을 가상 시스템에 만들었습니다. 다음과 같이 엣지 서버에서 다양한 트래픽 클래스를 시뮬레이션하는 방법을 파악했습니다.

클라이언트 트래픽 지연은 0.001 ~ 0.1 범위의 손실과 50Mbps의 병목 현상 대역폭을 포함하여 ~50ms로 설정되었습니다. 마찬가지로, 팝-투-팝 전용 손실 및 지연은 ~15ms 및 0.0001 ~ 0.01로 설정되었습니다. POP 내 트래픽의 경우 VM의 가용 용량을 최대로 제한합니다. 마지막으로, 트래픽의 멀티 테넌트 특성을 캡처하기 위해 다양한 객체 크기를 사용하여 시뮬레이션을 실행했습니다. 세 가지 트래픽 패턴을 모두 기하급수적인 흐름의 도착과 병렬로 실행하여 포아송 스타일의 흐름 도착 분포를 캡처합니다. 그림 7은 테스트 베드 설정을 보여줍니다.

이 테스트의 목표는 프로덕션 테스트에서 발견되는 문제, 특히 인트라 팝 트래픽 및 팝-팝 간 트래픽에 대한 작은 RTT 흐름의 처리량 감소를 재현하는 것이었습니다.

그림 7. KVM, iperf, netem 및 tc 유틸리티를 사용한 랩 설정

이 설정을 사용하여 시뮬레이션을 백그라운드 트래픽(입방 및 BBR 모두)으로 수백 번 실행하고 흐름을 완료하는 데 걸린 시간을 측정했습니다. 백그라운드 트래픽의 목표는 프로덕션과 유사한 환경을 시뮬레이션하는 것입니다. 기존의 많은 연구는 몇 가지 큐빅 및 BBR 흐름을 실행하고 그들의 행동을 평가하는 데 중점을 두었습니다. 이러한 경우에는 플로우당 동작을 이해하는 것이 유용하지만 대용량 CDN의 복잡성을 제대로 나타내지 못합니다. 파일 크기가 작을 경우 처리량에 노이즈가 발생할 수 있으므로 클라이언트 측 흐름 완료 시간을 신뢰할 수 있는 지표로 사용했습니다.

그림 8. iperf 흐름에 걸리는 시간. 왼쪽: 클라이언트 흐름. 오른쪽: 팝투팝 플로우. 개체 크기: 3MB. 시뮬레이션된 클라이언트 흐름에 대해 BBR이 큐빅보다 더 잘 수행되었습니다.

우리는 우리의 테스트 베드에서도 패턴이 다시 나타나는 것을 보았습니다. 그림 8에서는 클라이언트 트래픽과 3MB(중간 크기) 파일의 POP-to-POP 트래픽이라는 두 가지 시나리오에서 BBR 및 Cubic iperf 흐름에 걸린 시간의 CDF를 보여 줍니다. 저손실 고대역폭 설정에서 BBR 흐름이 큐빅을 따라잡지 못합니다. 클라이언트 트래픽(낮은 대역폭)이 개선되었습니다. 즉, BBR 흐름에 걸리는 시간이 줄어들었습니다. 그러나 작은 파일에 대한 개선은 미미합니다. 테스트 환경에서 이러한 동작을 재현하면 서로 다른 흐름 유형 간의 상호 작용의 결과라는 확신을 가질 수 있습니다. 따라서 CDN에 BBR을 배포하는 경우 혼합 흐름 유형에 미치는 영향이 더 광범위하다는 점을 인식해야 합니다.

결론

평가에서 BBR 흐름은 모든 시나리오에서 잘 수행되지 않는다는 것을 관찰했습니다. 특히 BBR 사용 시 데이터 센터/POP(Point of Presence) 내의 트래픽과 데이터 센터(POP-to-POP) 트래픽의 트래픽이 발생합니다. 극단적인 경우에는 처리량이 절반으로 줄어듭니다. 그러나 Pop-to-Client 트래픽 처리량은 6-8% 개선되었습니다.

이 게시물에서는 CDN의 맥락에서 BBR(버전 1)에 대한 평가를 간략하게 설명했습니다. 우리는 단일 POP에서 몇 개의 서버를 작은 테스트로 시작하여 대규모 콘텐츠 제공자로서 우리에게 관심이있는 다양한 변수를 평가했습니다. 대규모 풀 POP 테스트에서 BBR은 재전송이 많은 ASE의 경우 가장 큰 도움이 된다는 것을 발견했으며 대용량 파일에 BBR을 사용할 가치가 있다고 제안했습니다.

여기서 어디로 갈까요?

시스템 수준(모든 흐름)에서 BBR을 활성화하면 인트라 팝 및 팝 투 팝 트래픽이 처리량 감소에 어려움을 겪을 위험이 있습니다.

그러나 BBR은 잠재력을 보였으며 클라이언트 측 트래픽에 대해 잘 수행되고 있습니다. 이것은 잠재적으로 무선 공급자로부터 시작하여 고객을 위해 BBR을 선택적으로 활성화하도록 동기를 부여합니다. 더욱이, 이러한 경로는 얕은 버퍼와 무선 손실을 가지며, BBR이 다른 입방 흐름보다 더 잘 수행하기에 이상적인 상황이다.

이 개요를 통해 대규모 콘텐츠 제공업체에서 BBR을 사용하는 것과 병목 현상을 공유할 수 있는 다양한 유형의 트래픽에 미치는 영향에 대해 어느 정도 명확하게 알 수 있기를 바랍니다. 이제 BBRv2의 알파 릴리스를 사용할 수 있으며 이러한 문제 중 일부를 해결해야합니다. 우리는 BBR의 최신 버전을 계속 평가하고 올바른 유형의 흐름에 적합한 혼잡 제어를 선택하는 지능형 전송 컨트롤러를 사용할 계획입니다. 우리는 미래에 이것에 대해 더 많은 세부 사항을 공유 할 것입니다.

이 분석을 가능하게 한 조직 전체의 다양한 팀의 기여에 감사드립니다!