[페이스북 엔지니어링 블로그 번역] QUIC으로 수십억 트래픽을 대응하는 법. 번역자 방신우.

💡

페이스북 엔지니어링 블로그에 올라온 원문의 한국어 번역본입니다. 의역, 오역이 있을 수 있습니다. - 번역자 방신우

우리는 인터넷이 수십 년 동안 사용해온 사실상의 표준 프로토콜을 QUIC로 대체하고 있습니다. 더 나은 유저 경험을 만드려 네트워크 프로토콜을 최적화를 해왔는데, 이번 건은 우리가 해온 작업 중에 가장 최신의 것이자 급진적입니다. 현재 페이스북 인터넷 트래픽 75% 이상이 QUIC과 HTTP/3를 사용하고 있습니다. (HTTP/3도 그냥 QUIC이라고 부르겠습니다.)

QUIC이 불러온 긍정적인 효과들은 다음과 같습니다.

요청 오류 감소

꼬리 지연 시간 감소

응답 헤더 크기

이외에도 유저 경험에 의미있는 영향을 미치는 수많은 항목들

인터넷 TF(IETF)는 여전히 QUIC과 HTTP/3의 표준화 작업을 진행중입니다.

QUIC, HTTP/3란 무엇인가?

폭넓게 이야기하면 QUIC은 TCP의 대체재입니다. Google에서 개발했고 Google QUIC(gQUIC)이란 이름으로 2015년 IETF에서 공개됐죠. 그 이후로, IETF에서 개선과 재구성 작업을 거쳐 현재의 QUIC이 되었습니다. HTTP/3는 차세대 HTTP이죠. QUIC과 HTTP/3는 우리와 구글, IETF 커뮤니티가 인터넷 프로토콜을 사용해보며 얻은 수십년간의 모범 사례와 학습을 통해 만든 가장 최신이자 최고의 인터넷 프로토콜입니다.

TCP & HTTP/2 조합이 TCP & HTTP/1.1보다 성능이 뛰어난데, QUIC HTTP/3 조합은 그걸 한 번 더 뛰어넘습니다. TCP & HTTP/2는 스트림 멀티플렉싱을 통해 단일 네트워크 연결이 여러개의 데이터 스트림을 지원하는 기능을 처음으로 도입했죠. QUIC & HTTP/3는 유실 패킷들이 정체되고 연결 내 모든 스트림이 느려지는 TCP Head-Of-Line Blocking을 피함으로써 스트림들이 진정으로 독립적이게 하여 한 단계 더 앞으로 나아갑니다.

QUIC은 최첨단 손실 복구 기능을 채택하여, 악조건의 네트워크 상에서 대부분의 TCP 구현체들보다 더 나은 성능을 발휘합니다. TCP는 방화벽 같은 네트워크 미들박스가 패킷 형식을 일일이 체크하는 경우하는 경우가 많기 때문에, 호환성을 고려하다 보니 업그레이드 느리다는 점에서 골화된 경향이 있습니다. QUIC은 완전 암호화, 프로토콜 확장성 최고급화를 통해 미래에 이뤄질 개선을 보장함으로써 이러한 문제를 피합니다. 또한, QUIC을 위해 특별 디자인 된 JSON 기반 추적 형식 QLOG을 통해 전송 과정을 계측, 관찰, 시각화 할 수 있는 새로운 방법을 제공합니다.

경험을 기반으로한 프로토콜 개발

우리는 QUIC의 빠른 테스트와 배포를 위해 QUIC 구현체 mvfst를 자체 개발했습니다. 예전에도 여러 차례 프로토콜 구현체를 자체 개발한 적이 있었는데요, HTTP 서버/클라인트 라이브러리 Proxygen이 첫 작품이었고, Zero Protocol과 TLS 1.3 구현체 Fizz를 만들었습니다. 페이스북 앱은 Fizz와 Proxygen을 사용하여 Proxygen Mobile을 통해 서버와 상호작용 중입니다. 보안 인증을 위한 delegated credentials와 DNS over TLS는 TLS를 이용한 보안 솔루션이기도 합니다.

완전 처음부터 새 프로토콜을 개발하고 배포하기

우리는 새 프로토콜이 기존 소프트웨어와 매끄럽게 연동되고, 개발자들이 빠르게 일할 수 있게 해주길 바랐습니다. 첫 시험으론, 페이스북 트래픽에 큰 부분을 차지하는, 프록시 된 공개 트래픽을 포함하는 내부망을 택했습니다. QUIC이 내부 트래픽에서 작동하지 않는다면, 더 큰 인터넷 상에서도 마찬가지일 것이란 걸 알고 있었죠.

버그 및 문제들을 털어내는 것 이외에도, 이 전략을 실행하는 과정에서 네트워크 로드밸런서의 QUIC 호환과 무중단 배포를 보장하는 방법을 디자인하게 되었습니다.

이렇듯, 견고한 기반을 바탕으로 QUIC을 사람들에게 배포하는 쪽으로 나아갔습니다. mvfst의 디자인 덕분에, Proxygen Mobile에 매끄럽게 QUIC을 지원했습니다.

페이스북 앱

페이스북 앱은 우리의 첫번째 타겟이었습니다. 페이스북은 수십억 명의 사람들에게 앱을 출시하기 전에 제한된 방식으로 앱에 대한 변경사항을 안전하게 배포할 수 있는 성숙한 인프라를 가지고 있습니다. 앱 내 GraphQL 요청에 QUIC을 허용하는 실험으로 시작했습니다. 영상이나 사진 같은 정적 데이터가 없는 요청이었습니다.

해당 테스트로 페이스북 유저는 다음과 같은 개선을 경험했습니다.

요청 오류 6% 감소

꼬리 지연(Tail latency) 20% 감소

응답 헤더 크기 5% 감소(HTTP/2 대비)

다른 지표에도 계단식 효과를 주었으며, 이는 유저 경험이 QUIC으로 인해 급격히 개선되었다는 것을 시사합니다.

하지만 후퇴한 면도 있습니다. 동적인 요청에만 QUIC을 열었음에도 불구하고, TCP를 이용한 정적 컨텐츠 다운로드 오류율이 증가했다는 점입니다. 근본 원인은 트래픽을 QUIC으로 바꿀 때 흔히 접할 수 있는 문제였습니다. 앱 로직이 특정 형식 컨텐츠들에 대한 요청 형식과 요청량을, 다른 컨텐츠 요청에 대한 속도와 안정성에 기반해 바꿨다는 점. 즉, 하나의 요청 형식에 대한 개선이 다른 형식들에 대한 부작용을 야기했을 것 입니다.

예를 들어, 앱이 새로운 정적 컨텐츠를 서버로부터 얼만큼 공격적으로 요청하는 가를 반영한 휴리스틱이 QUIC 문제로 나타났을 것 입니다. 앱이 뉴스피드 내 텍스트 컨텐츠를 가져오라고 요청할 때, 앱은 해당 요청이 얼마나 걸리는지 확인하기 위해 기다리다가, 그 요청에서 얼마나 많은 이미지나 비디오를 가져올 지 결정합니다. 인위적인 임계점으로 휴리스틱이 설정되어있는 것을 발견한 것입니다. TCP에서는 해당 방식이 괜찮았지만 QUIC으로 바꿀 때는 이러한 임계점들이 부정확했고, 한 번에 너무 많은 데이터를 요청하니, 궁극적으로는 뉴스피드 로드 자체가 느려졌습니다.

확장하기(Making it scale)

다음 단계는 QUIC으로 정적 컨텐츠를 배포하는 것이었습니다. 하지만 이 단계 전에, 우리는 두 가지 우려를 풀어야했습니다.

mvsft의 CPU 효용

자체 혼잡 제어 구현체 BBR의 효과성

mvfst는 원래 개발자들이 빠르게 개발하고 QUIC의 변화무쌍한 성질을 따라잡을 수 있게 도와주는 용도의 라이브러리였습니다. 동적 요청들은 정적 컨텐츠에 비해 응답 사이즈가 작은 편이고, CPU 사용이 적으며, 혼잡 제어를 속도에 맞춰 사용하지도 않았습니다.

이 우려들을 다루기 위해, CPU 사용량과 혼잡 제어기의 효과를 따져주는 성능 측정 도구를 개발했습니다. 몇가지 개선을 위해 로드밸런서에 해당 도구와 Synthetic 부하 테스트를 활용했습니다. 매끄러운 데이터 전송을 위해 UDP 패킷 속도 조절 최적화를 했고 CPU 사용 문제는 GSO와 같은 기술을 채택하여 다량의 UDP 패킷을 한 번에 효율적으로 전송했습니다. 자료구조와 알고리즘을 최적화해 UNACK QUIC 데이터를 처리하기도 했습니다.

모든 컨텐츠를 위한 QUIC

QUIC으로 페이스북 앱 내 모든 컨텐츠를 지원하기 전까지는, 영상 엔지니어와 같은 팀 내 주요 관계자들과 협업을 했습니다. 다른 파트의 관계자들은 각 분야의 핵심 사항에 대해 깊은 전문성이 있었고 앱 내 QUIC 활성화, 실험 결과 분석에 도움을 주었습니다.

실혐 결과 QUIC이 앱 내 영상 지표들에 변형 효과를 미친 것으로 나타났습니다.

버퍼링 이벤트들 사이의 시간 측정 MTBR(Mean Time Between Rebuffering) → 플랫폼에 따라 총 22% 향상

영상 요청 오류 8% 감소

영상 지연율 20% 감소

다양한 요인, 특히 이상 조건을 고려한 메타 데이터를 포함해 여러 다른 지표들이 확실하게 개선되었습니다. 또한, 상대적으로 열악한 네트워크 환경을 갖는 신흥시장에 큰 영향을 끼치며 유저 영상 시청 경험을 개선했습니다.

하지만 여기까지 오는 데에 장애물이 여럿 있었습니다. 동적 컨텐츠 때 겪었던 문제와 마찬가지로, TCP 상황에 따라 휴리스틱 문제가 또 있었습니다. 예를 들어, 안드로이드와 iOS는 다운로드 가능한 대역폭을 측정할 때 서로 다른 메커니즘을 사용했습니다. QUIC 사용시에 가끔 대역폭의 크기를 과다측정했고, 네트워크가 버틸 수 있는 것보다 더 고화질 영상을 서빙하여 지연이 발생했습니다.

또한, 흐름 제어 파라미터를 튜닝해야 했습니다. 흐름 제어는 전송자로부터 받을 버퍼 데이터 양을 제한합니다. 페이스북 앱은 암묵적으로 TCP를 위해 튜닝된 HTTP/2용 흐름 제어 제한을 사용하고 있었고 이는 QUIC과 호환되지 않았습니다. 새롭게 최적화된 흐름 제어 값을 찾기 위해 몇 번의 실험 주기를 거쳤습니다.

인스타그램, 그 너머로

우리는 QUIC이 복잡하게 다뤄야 할 데이터가 많은 페이스북 앱에서 유저 경험을 향상시킬 수 있는지 테스트했습니다. 앞으로는 혼잡 제어와 손실 복구 개선에 투자하고 o-RTT나 연결 이주와 같은 QUIC의 현존 기능들을 활용해 볼 예정입니다.

페이스북 앱에 취했던 전략과 동일하게 인스타그램 앱에도 QUIC을 배포했습니다. 먼저 트래픽이 적은 곳에 먼저 배포하고 점점 확장시켰습니다. 인스타그램 안드로이드와 iOS 앱 모두 QUIC을 적용했습니다. 두 앱 모두 페이스북 앱 지표 이상의 성능을 보이고 있습니다. 구글 크롬과 애플 사파리 베타에서 QUIC을 지원함에 따라 페이스북, 인스타그램 웹 또한 QUIC이 활성화됐고, 더 많은 유저에게 나은 경험을 제공하고 있습니다. 인스타그램을 넘어, QUIC으로 메이저 서비스 뿐 아니라 모든 페이스북 인터넷 트래픽과 페이스북이 소유한 모든 앱에도 해당 경험을 제공할 수 있으리라 믿습니다.

IETF는 2021년 중으로 QUIC 프로토콜에 대한 RFC 작성을 마치려하고 있습니다. 이 작업이 끝나면, 더 많은 웹사이트, 앱, 네트워크 라이브러리에서 QUIC을 제공할 것 입니다. 가까운 미래에 QUIC과 같은 새로운 프로토콜이 인터넷 앱의 혁신을 풀어낼 필수 요소가 될 것 입니다. 우리에게 있어 QUIC은 페이스북 유저 경험을 개선하기 위한 시작점입니다.

페이스북 내외로 이 프로젝트에 도움을 주신 분이 많습니다. 지난 몇 년간 밤새도록 QUIC의 발전에 헌신한 IETF QUIC 팀에 감사를 드리고 싶습니다. IETF QUIC 팀은 짧은 시간 동안 엄청난 프로토콜을 만들어낸 다양한 배경을 가진 개개인들로 이루어져 있습니다.

방신우의 다른 글 보기

방신우 소개 페이지로 이동하기