Tailscale을 더 빠르게 만들기

요약

Tailscale은 패킷 메모리 처리 개선과 멀티 큐 도입을 통해 데이터 평면의 처리량을 높이고 지연을 줄이는 작업을 진행 중이다.
또한 netmap 캐싱 기능을 통해 제어 평면의 응답을 기다리지 않고 연결을 시작하여 데이터 전송 시작 시간을 크게 단축했다.

Tailscale이 패킷 메모리 처리와 병렬 처리를 개선해 앱 커넥터, 서브넷 라우터, 출구 노드의 처리량을 높이고 지연을 줄이는 작업을 진행 중임
Linux와 Android에서는 작은 패킷을 별도 64 KiB 버퍼로 복사하지 않고 수신 버퍼 안에서 처리해, 여러 네트워크 구성에서 약 5% 속도 향상을 얻음
멀티 큐는 각 패킷 스트림의 순서를 유지하면서 여러 CPU 코어로 작업을 분산하며, 다수 사용자의 짧은 연결을 처리하는 앱 커넥터와 출구 노드에서 특히 효과가 큼
netmap 캐싱은 이전에 저장한 장치와 접속 정보를 이용해 중앙 제어 서버의 응답을 기다리지 않고 연결을 시작하며, 서버 접근이 어려운 환경에서 데이터 전송 시작까지 걸리는 시간을 10~100배 단축함
버퍼 개선과 netmap 캐싱 기본 활성화는 v1.104, 멀티 큐와 추가 처리량 개선은 이후 릴리스에 적용할 예정

연결성에서 데이터 평면 성능으로

Tailscale은 NAT 통과 개선으로 다양한 네트워크 조건에서 연결 경로를 확보해 왔으며, 데이터 평면 성능에도 지속적으로 투자해 옴
- Linux 장치의 TCP 처리량 개선에 이어, wireguard-go 개선으로 베어메탈에서 10 Gb/s를 넘는 처리량을 달성함
- 세그멘테이션 오프로드를 활용해 UDP 기반 애플리케이션의 처리량을 4배 이상 높임
- Tailscale Peer Relays를 구축해 까다로운 네트워크 환경의 성능도 개선함
이러한 개선으로 성능에 민감한 워크로드에서 Tailscale을 활용하기 쉬워짐
- 지속적 통합, 에이전트 워크플로, 원격 개발 환경, 로봇 엣지 장치, 대규모 데이터 및 텔레메트리 작업 등이 해당함

작은 패킷의 메모리 낭비 줄이기

대부분의 네트워크 패킷은 1 KiB 정도로 작지만, Linux의 GRO(Generic Receive Offload) 같은 효율적인 처리 기능을 사용하려면 한 번에 64 KiB를 수신할 준비가 필요함
기존 wireguard-go 구현은 패킷을 풀어 담을 버퍼로 64 KiB 크기만 제공함
- 각 패킷을 개별적으로 복호화하고 전달해야 하므로, 1 KiB 패킷도 매번 별도의 64 KiB 버퍼로 복사됐음
Linux와 Android에서는 패킷을 다른 곳으로 복사하지 않고, 큰 수신 버퍼 안에서 각 패킷의 시작과 끝을 식별하도록 변경함
- 여러 작은 패킷이 하나의 메모리 할당을 공유하고 복사에 쓰는 시간도 줄어듦
- 이 변경만으로 여러 네트워크 구성에서 약 5% 속도 향상을 얻음
처리 단계 사이에서 트래픽 급증을 흡수하는 패킷 큐의 길이도 줄임
- 테스트에서 기존 큐 깊이의 대부분이 사용되지 않았으며, 더 짧은 큐는 대기 시간과 메모리 부담을 줄였음
- 확보한 메모리 여유를 서브넷 라우터와 앱 커넥터의 멀티 큐 처리에 활용함

멀티 큐로 패킷 순서를 지키며 병렬 처리

서브넷 라우터의 부하는 환경에 따라 크게 다름
- 소규모 홈랩에서는 Tailscale을 사용하지 않는 소수의 192.168.x.y 장치를 처리함
- 수백 개 피어를 가진 클라우드 배포 앞단에서는 훨씬 많은 트래픽을 전달함
기존 서브넷 라우터, 앱 커넥터, 출구 노드는 여러 독립 스트림을 순서가 보장되는 단일 스레드 파이프라인에서 처리함
- 수신 애플리케이션에 자기 스트림의 패킷이 순서대로 도착하도록 여러 연결이 하나의 처리 경로를 공유했음
새로운 멀티 큐는 피어 수가 아닌 장치 자원에 맞춰 여러 처리 경로를 구성함
- 각 패킷 스트림을 하나의 경로에 고정해 순서를 유지함
- 경로들을 병렬로 실행해 여러 CPU 코어에 작업을 분산함
서브넷 라우터와 앱 커넥터는 총처리 용량이 늘고 수신부터 전달까지의 지연이 줄어들며, 기존 하드웨어를 더 효율적으로 활용함
- 다수 사용자에게 짧게 유지되는 연결을 제공하는 앱 커넥터와 출구 노드에서 특히 효과가 큼
- 멀티 큐는 2026년 하반기 도입을 목표로 함

writev로 복사와 쓰기 작업 줄이기

Linux의 writev를 활용하면 여러 패킷 데이터 조각을 한 번의 작업으로 커널에 전달할 수 있음
writev의 v는 벡터를 뜻하며, 전달 전에 조각들을 복사해 합치는 대신 분리된 데이터의 위치를 기술할 수 있음
- 메모리 내 패킷 복사와 쓰기 작업 횟수가 줄고 처리량이 높아짐

netmap 캐싱으로 시작 지연 줄이기

앞선 성능 개선은 Linux와 해당 기능을 적용할 수 있는 Android에 한정되지만, netmap 캐싱은 다른 운영체제에도 적용할 예정임
일반적인 Tailscale 시작 과정에서는 장치가 제어 평면에 연결해 인증하고, 접근 가능한 장치와 접속 방법이 담긴 네트워크 지도인 netmap을 받음
- 보통 네트워크에서는 약 100밀리초가 걸리지만, 지연에 민감한 워크로드에는 이 시간도 길 수 있음
- 품질이 나쁜 기내 Wi-Fi나 필터링이 강한 호텔 네트워크에서는 제어 평면 접속이 오래 걸리거나 불가능해 다른 장치에 접근하지 못할 수 있음
캐싱을 활성화하면 각 장치가 netmap 사본을 디스크에 저장하고, 시작할 때 이를 이용해 tailnet의 다른 장치와 연결함
- 제어 평면에 접속해 최신 정보를 받을 때까지 캐시를 사용함
- 연결은 장치 간 직접 협상하며, 평소와 마찬가지로 Tailscale은 트래픽을 보지 않음
사용하려면 최소 한 번 tailnet에 연결한 이력과 영구 디스크 공간이 필요함
- 불필요한 디스크 쓰기를 최소화했지만, 매우 큰 tailnet에서는 캐시 갱신에 많은 디스크 입출력이 발생할 수 있음
- SD 카드처럼 느리거나 쓰기 마모에 민감한 저장장치를 쓰는 기기는 활성화하지 않는 편을 선택할 수 있음
제어 평면 접근성이 나쁜 tailnet에서는 캐시를 이용한 시작이 캐시 없는 시작보다 데이터 평면 전송 개시까지 10~100배 빨랐음
- 시작 지연이 들쭉날쭉하거나 DERP 서버 또는 제어 평면과 멀리 떨어진 장치에서 이점이 특히 뚜렷함

릴리스별 적용 계획

버퍼 변경에 따른 메모리 절감은 Linux와 Android용 v1.104 클라이언트에 적용할 예정임
멀티 큐를 통한 서브넷 라우터와 앱 커넥터 개선은 v1.104 이후 릴리스를 계획함
Linux와 Android의 처리량 개선은 2026년 봄에 일부 적용됐으며, 추가 메모리 및 처리량 개선은 v1.104 이후 릴리스를 목표로 함
netmap 캐싱은 현재 클라이언트에서 기능 플래그로 사용할 수 있음
- 추가 테스트를 거쳐 v1.104에서 기본 활성화할 예정임
- 모바일 클라이언트는 v1.104 이후 릴리스에 적용할 예정임

Tailscale 경로를 이해하는 성능 진단 도구

Tailscale은 사용자가 네트워크 구성을 직접 테스트하고 진단할 수 있도록 Tailscale을 인식하는 모니터링 및 테스트 도구를 탐색 중임
기존 성능 테스트 도구에는 네 가지 한계가 있음
- 배포 부담: 대부분 지점 간 테스트 방식이며 모든 엔드포인트에 도구를 설치해야 함
- 경직된 작업 흐름: 잘못된 테스트와 출력 때문에 실제로는 없는 문제를 추적하기 쉬움
- 프로토콜 지원 부족: QUIC과 HTTP/3 같은 최신 프로토콜을 지원하지 않는 도구가 많음
- Tailscale 인식 부족: DERP 경유인지 직접 연결인지, 피어 릴레이가 도움이 될지, 연결 경로가 시간에 따라 어떻게 바뀌는지 알려주지 못함
Tailscale 고유의 경로와 상태를 이해하는 도구를 검토하고 있으며, 성능 테스트 도구에 대한 의견을 받고 있음