Envoy가 조용히 느려졌다? 구글의 새 HTTP/2 코덱 oghttp2 성능 논쟁

프록시의 심장이 바뀌었는데, 더 느려졌다는 측정 결과

Envoy(엔보이)라는 이름, 쿠버네티스나 서비스 메시를 다뤄보셨다면 익숙하실 텐데요. 이게 뭐냐면, 마이크로서비스들 사이의 트래픽을 대신 받아 전달해주는 고성능 프록시예요. Istio 같은 서비스 메시에서 각 서비스 옆에 사이드카로 붙는 바로 그 프로그램이죠. 그런데 최근 Apoxy라는 인프라 회사가 벤치마크를 돌려봤더니, Envoy의 HTTP/2 처리 성능이 예전만 못하다는 결과가 나왔어요. 원인으로 지목된 건 Envoy가 HTTP/2 코덱을 오랫동안 써온 nghttp2에서 구글이 만든 oghttp2로 갈아탄 변경이었고요.

HTTP/2 코덱이 뭐길래 이렇게 중요한가요

이게 뭐냐면, HTTP/2는 HTTP/1.1처럼 사람이 읽을 수 있는 텍스트가 아니라 바이너리 프로토콜이에요. 하나의 연결 위에서 여러 요청을 스트림으로 다중화하고, 헤더는 HPACK이라는 방식으로 압축해서 주고받거든요. 이 바이너리 프레임을 만들고 해석하고, 압축을 풀고, 흐름 제어(상대가 감당할 만큼만 데이터를 보내는 규칙) 상태를 관리하는 부품이 바로 코덱이에요. 프록시를 지나는 모든 요청과 응답이 이 코덱을 통과하니까, 코덱이 조금만 느려져도 전체 처리량과 CPU 사용량에 그대로 영향이 가요.

nghttp2는 이 분야의 터줏대감이에요. C로 작성돼 10년 넘게 다듬어졌고, curl이나 Node.js 같은 유명 프로젝트들이 채택할 만큼 검증된 라이브러리거든요. 반면 oghttp2는 구글이 QUICHE(크롬의 QUIC과 HTTP/3 구현을 담고 있는 프로젝트) 안에서 C++로 새로 만든 구현이에요. 구글 입장에서는 외부 C 라이브러리 대신 자기들이 직접 유지보수하는 코드를 쓰고, HTTP/3 스택과 코드베이스를 통일하고, 퍼징 같은 테스트 인프라도 일원화할 수 있다는 장점이 있죠. 그래서 Envoy도 얼마 전부터 oghttp2를 기본 코덱으로 바꿨어요. 그런데 이번 벤치마크에서 oghttp2가 nghttp2 대비 처리량이 떨어지고 자원을 더 쓰는 걸로 측정된 거예요. 다행히 되돌릴 스위치는 남아 있어요. envoy.reloadable_features.http2_use_oghttp2 런타임 플래그를 끄면 예전처럼 nghttp2로 동작하거든요.

성능이냐, 유지보수성이냐 — 업계의 오래된 저울질

이 사건을 조금 넓게 보면, 오래된 C 라이브러리를 자체 구현이나 더 안전한 언어로 교체하는 업계 흐름의 한 장면이에요. Cloudflare가 nginx를 러스트로 만든 Pingora로 대체한 것, OpenSSL 대신 rustls를 쓰려는 움직임 같은 것들요. 새로 만든 구현은 코드 소유권과 안전성 면에서는 이득이지만, 수십 년간 최적화가 쌓인 기존 구현을 성능으로 바로 이기기는 어려운 경우가 많거든요. 물론 마이크로벤치마크가 실제 서비스 부하를 그대로 대변하지는 않는다는 점도 감안해야 해요. 하지만 대규모 트래픽을 받는 환경에서는 사이드카가 쓰는 CPU 몇 퍼센트가 곧 서버 비용 몇 대 차이로 이어지니까, 무시할 수 있는 숫자는 아니에요.

한국 개발자에게 주는 시사점

Istio나 Envoy를 직접 운영하는 팀이라면 실용적인 체크포인트가 생긴 셈이에요. 최근 업그레이드 이후 게이트웨이나 사이드카의 CPU 사용률, p99 지연 시간이 미묘하게 올랐다면 코덱 변경이 원인일 수 있으니, 자기 워크로드로 직접 벤치마크를 돌려보고 플래그로 두 코덱을 비교해보는 거죠. 더 일반적인 교훈도 있어요. 인프라 소프트웨어의 '기본값 변경'은 릴리스 노트 한 줄로 조용히 들어와서 성능을 바꿔놓는다는 거예요. 그래서 버전 업그레이드 전에 릴리스 노트의 동작 변경 항목을 읽고, 성능 회귀 테스트를 배포 파이프라인에 넣어두는 습관이 이런 상황에서 진가를 발휘해요.