앱의 응답성을 높이기 위한 네트워킹 지연 단축

♪ 부드러운 힙합 음악 ♪ ♪ 안녕하세요, Vidhi Goel입니다 이 영상에서 여러분의 앱의 네트워크 지연 현상을 줄이고 반응 속도를 높이는 방법을 얘기해 볼게요 먼저 대기 시간을 줄이는 게 앱의 응답성에 중요한 이유를 알려 드릴게요 다음으로 불필요한 대기 시간을 줄이기 위해 여러분의 앱과 서버에서 할 수 있는 여러 가지를 알려 드릴게요 마지막으로 네트워크 자체에서 대기 시간을 줄이는 방법도 설명해 드리죠 네트워크 대기 시간은 데이터가 하나의 엔드포인트에서 다른 엔드포인트로 가는 데 걸리는 시간을 말합니다 앱에 내용을 얼마나 빨리 전달하는지는 이 대기 시간이 결정하죠 네트워크를 사용하는 모든 앱은 네트워크 처리 속도에 영향을 받을 수 있어요 이 속도가 느리면 앱 사용 경험의 질이 떨어지죠 예를 들어 영상 통화가 가끔 멈추거나 응답이 느려지면 회의에 방해가 돼요 사람들은 이 문제를 해결하려고 서비스 사업자에게 전화해서 대역폭을 업그레이드하곤 하는데 그래도 문제는 여전히 존재하죠 문제의 근본 원인을 해결하려면 네트워크에서 앱의 데이터 패킷이 어떻게 이동하는지 이해하셔야 합니다 앱이나 프레임워크가 서버에서 데이터를 요청하면 네트워킹 스택에서 패킷이 전송됩니다 보통 패킷은 네트워크에서 지연되지 않고 바로 서버로 전송되는 것으로 가정하죠 하지만 현실에서는 네트워크상 가장 느린 연결에 패킷이 처리되지 못하고 길게 줄을 서 있죠 그래서 여러분 앱의 데이터 패킷은 실제로는 이 기나긴 줄의 뒤에서 앞의 패킷이 처리되길 기다리고 있어요 가장 느린 연결의 대기 줄이 여러분의 앱과 서버 간의 데이터 왕복 시간을 늘립니다 이 문제는 앱의 요청에 대한 첫 응답을 위해 데이터 왕복이 여러 번 일어날 때 악화됩니다 예를 들어 첫 응답 패킷을 받는 데 걸리는 시간은 TCP 기반의 TLS 1.2를 사용할 때 데이터가 한 번 왕복할 때 걸리는 시간의 4배가 되는 거죠 이미 네트워크의 대기 행렬로 각각의 왕복 시간이 늘어나 있으니 총 처리 시간은 엄청나게 길어집니다 앱의 응답성은 두 가지 계수의 곱으로 결정됩니다 1회 왕복 소요 시간과 왕복 횟수의 곱이죠 이 계수를 줄이면 앱의 대기 시간이 줄어들고 앱의 응답성이 커집니다 관련 연구도 있는데요 대역폭 증가와 대기 시간 축소가 각각 페이지 로딩 시간에 미치는 영향을 비교했죠 첫 번째 실험에서는 대기 시간을 고정하고 대역폭을 초당 1MB부터 10MB까지 늘려 봤습니다 처음에 대역폭을 1MB에서 2MB로 늘렸을 땐 페이지 로딩 시간이 거의 40% 가까이 감소했어요 훌륭한 효과죠 하지만 4MB 이상부터는 대역폭이 조금씩 증가해도 페이지 로딩 시간은 거의 개선되지 않았습니다 기가바이트 수준의 인터넷으로 업그레이드를 해도 앱이 느릴 수 있는 거죠 반면 대기 시간을 축소했을 때는 20밀리초가 줄어들 때마다 페이지 로딩 시간이 선형 감소하는 효과가 있었죠 이런 실험 결과는 앱의 모든 네트워크 활동에 적용됩니다 이제 대기 시간을 줄이고 앱의 반응 속도를 높이는 몇 가지 간단한 활동을 알려 드릴게요 최신 프로토콜을 적용하면 앱의 대기 시간을 상당히 줄일 수 있어요 IPv6나 TLS 1.3 HTTP/3 같은 거죠 여러분은 앱에서 URLSession과 Network.framework API를 사용하기만 하면 됩니다 여러분의 서버에서 실행되기만 하면 해당 프로토콜들도 자동으로 쓰일 거예요 HTTP/3는 출시 이후 사용량이 지속적으로 증가했어요 불과 1년 만에 웹 트래픽의 20%가 이미 HTTP/3를 사용하고 있고 그 비중은 계속 늘어나고 있죠 다른 HTTP 버전들과 사파리 트래픽을 비교하면 HTTP/3가 그중에서 가장 빨라요 HTTP/3 요청이 처리되는 시간은 HTTP/1과 비교하면 절반이 조금 넘는 수준이죠 왕복 시간의 배수를 요청 완료 시간의 중간값으로 봤을 때요 즉 여러분 앱의 요청이 훨씬 빠르게 완료된다는 거예요 장치가 Wi-Fi에서 셀룰러로 옮겨 갈 때 새 연결을 다시 설정하려면 시간이 걸려요 이때 앱이 멈출 수 있죠 커넥션 마이그레이션을 이용해 이런 멈춤 현상을 제거합니다 기능을 적용을 위해 URLSession 환경 설정이나 NWParameters의 multipathServiceType 프로퍼티를 .handover로 설정합니다 이 옵션을 활성화하고 앱에서 작동하는지 확인하세요 UDP 기반의 프로토콜을 직접 설계하셨나요? iOS 16과 macOS Ventura에선 데이터그램을 전송하는 더 나은 방법을 도입했어요 QUIC 데이터그램은 일반 UDP에 비해 이점이 많죠 가장 중요한 건 QUIC 데이터그램이 네트워크 혼잡에 반응할 수 있다는 건데요 네트워크 왕복 시간은 줄이고 패킷 손실은 줄일 수 있습니다 클라이언트에 적용하기 위해 QUIC 옵션에서 isDatagram을 true로 설정하고 여러분이 원하는 데이터그램의 최대 프레임 크기를 설정합니다 데이터그램 흐름을 만든 이후에는 다른 QUIC 스트림처럼 주고받을 수 있습니다 이제 대기 시간을 줄이려면 앱에서 어떤 작업을 해야 하는지 아셨죠? 다음으로 서버가 앱의 응답성에 어떻게 영향을 미치는지 알아보겠습니다 최신 하드웨어를 사용하고 있지만 서버 때문에 앱이 느려지는 경우가 종종 있습니다 우리는 macOS Monterey에 네트워크 품질 도구를 도입했죠 이 도구를 사용해서 여러분의 서버는 물론 서비스 공급자의 네트워크에서도 버퍼블로트 측정이 가능합니다 여러분의 서버를 네트워크 품질 도구의 대상 서버 역할로 구성해야 합니다 구성을 마치면 네트워크 품질 도구를 실행하세요 처음엔 Apple의 기본 서버를 측정하고 다음엔 여러분이 구성한 서버를 측정하세요 도구의 점수가 기본 서버에선 높은데 여러분의 서버에선 높지 않다면 여러분 서버의 응답성을 개선할 여지가 있습니다 자, 이제 이 기술을 이용해서 여러분 모두가 하고 있는 활동을 개선하는 예시를 보여 드릴게요 영상을 시청하는 거요

다들 이런 경험 있으실 거예요 영상 일부를 건너뛰고 다른 지점을 재생했을 때 버퍼링되느라 한참을 기다린 경험이요 이렇게 임의로 접근하면 왜 느려지는지 이유를 조사해 봤습니다 네트워크 품질 도구를 이용해 스트리밍 서버의 동작을 테스트했는데요 응답성 점수가 낮다는 걸 발견했습니다 오른쪽에서는 WWDC 영상을 틀었어요 그러다 영상을 뒤로 건너뛰었는데 영상의 버퍼링이 있는 동안 화면에는 아무것도 나오지 않았습니다 몇 초 후에야 영상이 나타났죠 macOS의 네트워크 품질 도구의 상세한 출력 데이터 덕분에 서버에 엄청난 대기열이 있다는 걸 발견했습니다 그래서 서버 구성을 살펴봤죠 그중에서도 TCP, TLS, HTTP의 버퍼 크기를 알아봤는데 각각 4MB, 256KB, 4MB로 구성되어 있었습니다 램 용량이 충분해서 버퍼의 크기가 거대했죠 하지만 좋은 버퍼링이 있다고 해서 버퍼링이 많은 게 늘 좋은 건 아니에요 응답성 측정 결과 부각된 문제가 있었는데요 큰 버퍼의 오래된 데이터 뒤에 새로 생성된 패킷이 대기하면서 이 새로운 패킷을 전달하는 데 추가적인 지연이 많이 발생한다는 거죠 그래서 우리는 버퍼 크기를 HTTP는 256KB로 TLS는 16KB로 TCP는 128KB로 줄였습니다

이건 Apache 트래픽 서버의 구성 파일로 구성한 옵션을 보여 줍니다 TCP 하위 워터마크 비전송 항목의 버퍼 크기는 128KB로 설정됐고 버퍼링을 낮추기 위해 다른 옵션들도 활성화했죠 TLS에서는 동적 레코드 크기 조절을 가능하게 했고 HTTP/2에선 하위 워터마크 값과 버퍼 크기를 줄였습니다 여러분의 Apache 트래픽 서버에도 이런 구성을 권장합니다 다른 웹 서버를 이용한다면 같은 조건의 옵션을 찾아보세요 이렇게 바꾸고 난 후에 네트워크 품질 도구를 다시 실행했습니다 이번에는 RPM 점수가 높았어요 오른쪽에서 같은 영상을 재생했는데 이번에는 영상을 뒤로 건너뛰어도 영상이 즉시 재생됐습니다 서버에서 불필요한 대기열을 없애면서 임의 접근 응답이 훨씬 빨라졌죠 여러분의 앱이 네트워크를 사용하는 방식에 관계 없이 서버를 이렇게 변경하면 앱의 응답성이 향상되고 사용자 환경이 나아질 거예요 지금까지 앱을 개선하고 서버를 업데이트하는 법을 설명했어요 응답성에 큰 영향을 미치는 세 번째 요소가 있는데요 네트워크 자체입니다 Apple은 iOS 15과 macOS Monterey에 네트워크 품질 도구를 도입했습니다 그 이후로 다른 곳에서도 동일한 방법론을 사용해 네트워크 품질 테스트를 개발했습니다 Waveform은 버퍼블로트 테스트를 출시했고 Go 언어로 쓰여 오픈 소스로 구현된 응답성 테스트가 있습니다 또 우클라는 속도 테스트 앱에 응답성 수치를 추가했죠 우클라의 앱은 왕복 시간을 밀리초 단위로 보여 줍니다 60,000을 해당 계수로 나누면 분당 왕복 횟수 혹은 RPM을 계산할 수 있습니다 이런 도구를 사용하면 네트워크의 성능을 측정할 수 있습니다 네트워크 지연을 파악하는 가장 좋은 방법은 지연에 민감한 앱을 사용해 보는 거예요 제가 원격 컴퓨터와 화면을 공유하는 걸 보여 드릴게요 저는 네트워크 환경을 대표 접속망과 유사하게 설정했어요 다른 장치의 트래픽도 이 접속망을 공유합니다 여기서 화면 공유 기능을 통해 원격 컴퓨터에 로그인했어요

Finder 메뉴 여러 가지를 클릭했는데 각 메뉴 화면이 매우 느리게 나왔어요 이 조작이 얼마나 지연되는지 확인하려고 시간을 표시하는 앱을 로컬 컴퓨터에 띄우고 원격 컴퓨터에서도 같은 앱을 켰습니다 두 컴퓨터의 시각이 동일하게 표시되는데도 원격 화면에선 제때 업데이트가 안 되고 시각이 몇 초 정도 지연돼서 표시됐죠 이렇게 업데이트가 지연되는 이유는 네트워크상에서 가장 느린 연결에 긴 대기열이 존재하고 화면 공유 앱의 패킷이 이 대기열에 막혔기 때문이에요

이 대기열 문제를 해결하려고 Apple은 네트워크 업계와 협업하여 L4S라는 신기술을 개발했습니다 iOS 16과 macOS Ventura에서 베타 버전을 사용할 수 있죠 L4S는 대기 지연 시간을 상당히 줄여 주고 네트워크 정체 중에 일어나는 손실도 없습니다 짧은 대기열을 계속 유지하기 위해 네트워크는 패킷을 삭제하는 대신 정체를 명시하여 알리고 이 네트워크 정체 피드백에 따라 송신자가 전송 속도를 조정합니다 이렇게 하면 패킷 손실 없이 네트워크의 대기열을 짧게 유지할 수 있고 덕분에 앱의 응답성이 높아집니다 L4S로 화면 공유가 어떻게 개선됐는지 보세요 아까랑 같은 컴퓨터와 같은 네트워크를 사용했지만 이번에는 L4S를 적용했죠 여러 Finder 메뉴를 클릭하면 즉시 열립니다 양쪽 컴퓨터에서 시계 앱을 켜면 이번엔 로컬 컴퓨터 화면과 원격 공유 화면의 시계가 완벽하게 일치하죠 이 기술은 화면 공유에만 적용되는 게 아니에요 L4S는 지금 나와 있는 모든 앱을 개선하고 현재는 실현할 수 없는 미래의 앱도 L4S를 통해 가능해질지 모릅니다 이 차트는 화면 공유 앱에서 관찰된 패킷의 평균 왕복 시간을 표시합니다 이 데이터 이동은 같은 네트워크를 공유하는 다른 장치의 트래픽과 동시에 발생하죠 기존의 대기열과 L4S를 비교했을 때 L4S를 적용하면 왕복 시간에서 엄청난 감소를 확인할 수 있습니다 이게 바로 저의 화면 공유 환경이 눈에 띄게 좋아진 주된 이유죠 HTTP/2나 QUIC를 사용하는 앱에서 L4S를 테스트해 보세요 iOS 16은 개발자 설정에서 L4S를 활성화할 수 있고 macOS Ventura에서는 defaults write 명령어로 가능하죠 Linux 서버를 사용하여 테스트할 때는 QUIC 구현이 정확한 ECN을 지원하고 확장 가능한 정체 제어 알고리즘을 지원해야 합니다 L4S가 가능한 네트워크가 구축되고 여러분이 준비가 되었는지 확인하기 위해 앱이 L4S와 호환되는지 테스트하고 발생할 수 있는 문제에 대한 피드백을 제공해 주세요 이제 여러분은 앱의 응답성을 개선하기 위해 대기 시간을 줄이는 게 중요하다는 걸 배웠습니다 HTTP/3와 QUIC를 적용해서 왕복 횟수를 줄이고 앱 콘텐츠를 빠르게 전달하세요 서버의 불필요한 대기열을 제거해서 더 응답이 빠른 조작을 제공하세요 개발자 설정에서 L4S를 활성화하고 앱과의 호환성을 테스트한 뒤 피드백을 보내 주세요 마지막으로 서버 공급자에게 L4S 활성화 지원을 문의해 보세요 봐 주셔서 감사합니다 ♪