Delivery Hero가 HTTP/3로 앱 응답 지연을 줄였다

Delivery Hero는 대부분의 이용자를 HTTP/3로 옮겨 앱 홈 화면의 전체 응답 시간을 17% 줄였다. 다만 안드로이드 초기화 지연과 일부 네트워크의 패킷 손실 문제가 남아 Cloudflare와 해결을 추진하고 있다.

독일에 본사를 둔 글로벌 음식 배달 기업 Delivery Hero는 유럽, 라틴아메리카, 아프리카, 중동, 아시아에서 약 6,000만 명의 이용자를 보유한 것으로 추정된다. 이 회사의 스태프 엔지니어 엘비스 치데라(Elvis Chidera)는 P99 2026 가상 콘퍼런스에서 HTTP/3 도입 경험을 소개했다. Delivery Hero는 Uber에 148억 달러에 인수될 예정이다.

Delivery Hero는 지역별로 Foodpanda, Yemeksepeti, Glovo, PedidosYa 등 여러 앱을 운영한다. 지역마다 네트워크 환경이 달라 서버 연결에 걸리는 시간이 병목이 되곤 했다. 파키스탄에서는 보안 핸드셰이크를 설정하는 데 p90 기준 거의 1초가 걸리는 경우도 있었다.

HTTP/3는 TCP 대신 QUIC을 사용한다. 앱은 세션 티켓을 캐시한 뒤 다음 연결에서 QUIC의 0-RTT 기능을 이용해 핸드셰이크가 끝나기 전부터 전송 가능한 데이터를 보낼 수 있다. 또 HTTP/2와 달리 패킷 손실이나 지연이 발생해도 여러 스트림으로 데이터를 보내므로 한 패킷의 지연이 다른 데이터 전송을 막는 현상이 없다.

도입과 남은 과제

Delivery Hero는 Cloudflare의 콘텐츠 전송 네트워크(CDN)를 사용하고 있어 서버 측 HTTP/3 전환은 간단한 재설정으로 이뤄졌다. iOS 15부터 HTTP/3를 지원하는 애플 기기와 대부분의 네이티브 브라우저도 적용이 수월했다.

안드로이드에서는 Google의 Cronet 라이브러리를 OkHttp용 래퍼와 함께 사용했다. 하지만 Cronet 엔진 초기화에 p90 기준 약 800밀리초가 걸려 HTTP/3의 0-RTT 이점을 일부 상쇄했다. 이에 엔지니어들은 OKCronet을 이용해 자체 브리지를 만들고, 다른 백그라운드 작업과 Cronet 초기화를 겹쳐 진행하도록 조정했다.

그 결과 읽기 지연 시간은 p95 기준 1.2초에서 120밀리초로 줄었다. 전체 이용자의 95%가 HTTP/3로 전환됐고, UDP 트래픽 차단 등으로 프로토콜을 사용할 수 없는 기기는 HTTP/2로 자동 전환됐다. 앱과 서버 사이의 핸드셰이크 지연은 51% 감소했으며 파키스탄의 응답 시간은 절반으로 줄었다.

일부 시장의 보조 화면에서는 패킷 손실에 따른 지연 문제가 계속됐다. Delivery Hero 엔지니어들은 Cloudflare가 HTTP/3에 사용하는 혼잡 제어 알고리즘 Cubic을 원인으로 지목했다. Google의 BBR 혼잡 제어를 사용하는 HTTP/3 서버에 일부 트래픽을 보내 시험했을 때는 패킷 손실로 인한 정체가 발생하지 않았다. 치데라는 Delivery Hero가 이 알고리즘 문제를 해결하기 위해 Cloudflare와 협력 중이라고 밝혔다.