Snapchat의 QUIC 적용
Snap에서 공유한 QUIC 프로토콜 적용 경험
프로그래밍을 공부한다면 거의 필수적으로 배우는 내용이 있습니다. 네트워킹, 그 중에서도 OSI 7 layer와 같은 개념들이죠. 웹 개발 등에 필수적인 HTTP 와 같은 프로토콜도 배우는데, 일반적으로는 HTTP는 TCP 위에서 동작한다고 배울 것입니다. 아 물론 이건 HTTP/2까지는 맞는 이야기입니다. 근데 HTTP 3.0 은 UDP에서 동작한다는 걸 알고 계셨나요?
이렇게 기술은 빠르게 변화하기 때문에 계속해서 공부해야 합니다. 이런 것은 개발자의 숙명이니 받아들여야 합니다..ㅎㅎ 아무튼 구글의 SPDY + HTTP/2 프로토콜이 표준으로 자리잡고 널리 사용된지 얼마나 되었다고 벌써 HTTP/3 를 적용한 케이스가 꽤 많아지고 있습니다. HTTP/3 에 사용되는 핵심 프로토콜인 QUIC 을 개발한 구글 뿐 아니라 많은 회사들이 이제 HTTP/3을 꽤 열심히 적용하는 추세인 것 같습니다.
HTTP의 발전 과정과 QUIC프로토콜 자체에 대해서는 잘 설명한 글들 (참고1, 참고2, 참고3, 참고4, 참고5)이 너무 많기 때문에 넘어가고, Snap의 블로그에 스냅챗 앱에 QUIC을 적용한 글이 올라왔길래 간단히 정리해 보았습니다.
Snapchat에서의 문제점
스냅챗 뿐 아니라 많은 기업들은 사용자의 UX 향상을 위해서 딜레이를 최대한 줄이려고 노력합니다. 근데 UI update나 Disk write와 같은 작업들이 milliseconds 수준인 것에 비해서, Network latency 는 seconds 수준인 경우가 많다고 합니다. 그리고 이로 인한 Error rate또한 높다고 합니다.
사용자가 불편함을 느끼는 latency따라서, Network latency 와 관련 Error rate을 줄이고 Request/Response양도 줄이기 위해서 스냅챗에 QUIC (Quick UDP Internet Connection) 프로토콜을 도입하게 되었다고 합니다.
QUIC의 장점과 적용결과
아래는 QUIC 프로토콜을 설명할 때 자주 등장하는 그림입니다. 기존에는 TCP + TLS + HTTP2 방식으로 통신이 이뤄졌습니다. 잘 쓰였던 방식이고 신뢰성 있지만, Mobile 환경에서 발생하는 문제가 있습니다. 모바일의 경우 움직이게 되면 기지국이 변경되어 접속 네트워크가 바뀔 수 있는데 그 때 연결이 끊기거나 하는 문제 등이 있습니다.
Application layer interface는 동일하게 HTTP/2 기반입니다.QUIC에서는 이러한 문제를 해결할 수 있습니다. 또 하나의 장점은 TCP를 UDP 로 바꾸고 그 위의 프로토콜을 QUIC을 사용하는 것이고, 가장 상위 application layer에는 HTTP/2 기반의 프로토콜을 사용하기 때문에 기존의 프로그램 구현에서 거의 변화 없이 적용이 가능하게 됩니다. 스냅챗에서는 QUIC을 적용한 결과 아래와 같은 장점들을 얻게 되었다고 합니다.
Connection establishment 개선
기존 TCP+TLS 방식에서는 payload 를 보내기 전 handshake 할 때 1~3 round trip을 하게 되는데 QUIC은 zero round trip 을 지원하므로 빠르게 connection을 맺을 수 있습니다. 스냅챗에서는 기존에 P90이 300ms 정도 되었는데 이를 개선하였다고 합니다.
Congestion control 개선
스냅챗의 경우 미디어 파일 전송 시 10MB까지 되는 경우가 있는데, congestion control 이 개선되어서 속도도 개선되었으며 error rate도 개선되었다고 합니다.
Multiplexing 개선
기존의 HTTP/2까지는 TCP 패킷 전송 시 순차적으로 전송되게 됩니다. 근데 중간에 패킷을 잃어버려서 재송신되면 해당 값을 다시 받기 전까지 스트림 처리가 안됩니다. 이는 사용자 입장에서 불편할 수 있지요. QUIC에서는 이렇게 멈추는 것을 여러 스트림에서 multiplexing 되도록 하여 해결합니다. 또한 스냅챗에서는 여러가지의 미디어 타입을 다루고 동일한 커넥션에서 스트림을 여러가지 다운로드하는 경우도 있는데 이런 경우에도 multiplexing 하도록 하여 개선하였다고 합니다. (참고로 QUIC에서는 이렇게 스트림의 순서와 상관없이 처리를 할 수 있는 장점이 있기는 하지만 serial 하게 처리해야 하느 경우에는 별 수 없이 stall 되는 걸로 알고 있습니다. 스냅챗의 경우 핵심은 영상전송이기 때문에 이런 경우에 좀 더 유연하게 대처 가능한 걸로 보입니다.)
IP 변경 대응
TCP 기반에서는 IP 가 변경되면 전송이 실패됩니다. 하지만, QUIC은 랜덤하게 생성한 64 bit identifier를 사용하기 때문에 이런 문제를 줄일 수 있습니다.
Connection lost 대응
일반적으로 Connection이 끊기면 이를 알아채는 데 시간이 좀 걸립니다. 앱을 예로 들면 spinner가 한참 돌게 되고 사용자 입장에서는 굉장히 불편하죠. QUIC은 connection lost를 빠르게 알아챌 수 있기 때문에 retry를 더 빠르게 시도하거나 좀 더 빠르게 알아채고 user-friendly 한UI를 보여줄 수 있습니다.
Snap 에서는 모바일 앱의 client network stack 을 Cronet을 이용하여 QUIC을 적용했다고 합니다. (Cronet같은 stack을 사용하면 QUIC을 사용하는 것 뿐 아니라 metric 측정, 로깅 등에서도 장점이 많다고 하네요.) 다양한 나라, 플랫폼 상에서 테스트를 진행했고 P90/P99의 network latency 를 6~20% 가량 개선했으며, network error는 3~8% 가량 개선했다고 합니다. 특히나 네트웍이 느린 경우 더 좋은 결과를 보였다고 합니다.
일반적인 network latency 개선
payload 크기에 따른 network latency 개선참고로, 위에 나온 P50, P90, P99 와 같은 것들은 퍼센트 지표로, 이 글에서는 request에 대한 network latency 속도를 일렬로 쭉 늘어놨을 때 50%느린 속도, 90% 느린속도, 99% 느린 속도를 의미합니다. 예를들어 P99.9 는 99.9% 느린 속도를 의미합니다. 즉, 1000개 요청이 들어왔을 때 젤 느린 마지막 1개 요청의 latency입니다. 큰 규모 서비스일수록 이런 서비스 안정성이 중요하기 latency 를 이러한 지표로 나타냅니다. P99.99 까지 낮은 latency 를 보이는 서비스를 만들 수록 좋은 성능 좋은 서비스라는 의미입니다만, 이를 달성하기 위해 희생해야 할 것이 많기 때문에 항상 그렇듯 trade-off가 있습니다. 그래서 일반적으로는 P99.99 이상은 잘 쓰이지 않습니다.
몇 년 전만해도 QUIC을 적용하는 것은 아직 시기상조로 보였는데요, 이제 구현체도 꽤 많아졌고 쓸만해 진 것 같습니다. 다만 구현체가 없는 플랫폼이라면 직접 구현해야 하므로 아직은 시기상조겠죠. 하지만 Network latency 등이 중요하고 QUIC 적용이 가능한 환경이라면 적용해 보는 것도 좋을 것 같네요.
HTTP/3은 아직 완전한 표준 단계는 아니고, 표준화를 하는 작업이 열심히 진행중인 걸로 알고 있습니다만 곧 표준이 발표될 것입니다. 여러모로 QUIC은 모바일 시대, 그리고 트래픽이 폭증하는 요즘같은 때에 걸맞는 프로토콜인 것 같습니다. 오늘도 다양한 분야에서 뛰어난 분들이 기술 발전을 위해 열심히 힘써주고 있네요!
