서버간 지연 시간을 줄이기 위한 Tailscale Relay Server 구축기

배경

Upcoin 모의투자 거래소의 암호화폐 시세 데이터는 Upbit로부터 제공받아 전남고등학교 실시간 시세처리 서버에서 적절한 처리를 거친후 사용자에게 웹소켓을 통해 시세 데이터를 전송한다.

그런데 2025년 1월 후반에 사용자에게 시세 데이터가 전송되지 않는 중대한 서비스 장애가 발생하여 확인해보니 학교 서버와 업비트 서버 간의 연결이 되지 않고 있었다.
curl로 http 패킷을 보내어 확인해본 결과 학교 방화벽 장비의 심층 패킷 분석(DPI)를 통해 Upbit로 접속하는 것을 감지하고 패킷을 드랍하는 것을 발견하였다.
원인을 추측하자면, 새학기가 되어 학교 방화벽 정책이 강화되며 모든 증권, 주식, 암호화폐, 게임 등 관련 사이트가 접속이 차단되도록 방화벽 정책이 적용되어 문제가 발생한 것으로 추측이 된다.그래서 Oracle Cloud Infrastructure의 춘천 데이터센터의 서버 한대를 빌려 업비트에 대신 접속할 수 있는 메시지 브로커 서버를 만들고, 업비트의 시세 정보 데이터를 메시지 브로커 서버가 대신 받고 전남고등학교 실시간 시세 처리 서버에 전송하도록 하여 해결하였다.

각 서버 간의 통신은 tailscale이라는 프로그램을 통해 통신을 하게 되는데, 서버들 간의 통신은 P2P 통신을 한다. 그러나 미상의 이유(방화벽 차단 등등)로 인해, 서버들 간의 P2P 연결이 설립되지 않았다면, 연결을 유지하기 위해 Relay Server를 거쳐서 통신하게 된다.
Relay Server는 일본 도쿄, 대만, 홍콩 등 전세계에 골고루 분표하여 28개가 있다. 전세계에 골고루 분표한 이유는 서버 위치가 어디인지 상관없이 현재 위치에서 가장 가까운 Relay Server를 연결하여 지연 시간을 단축 하기 위함이다.

그러나,

메시지 브로커 서버는 앞서 말했듯이, 강원도 춘천 삼성 SDS 데이터센터에 위치해 있다. 메시지 브로커 서버가 업비트로부터 시세데이터를 받고 전남고 실시간 시세처리 서버에 전달을 해주어야 하는데 P2P 연결이 설립이 안되었을 경우를 생각해보자.
그럼 메시지 브로커 서버는 춘천 삼성 SDS 데이터 센터와 가장 가까운 일본 도쿄 데이터센터의 Relay Server로 연결 될 것이다. 그럼 메시지 브로커에서 시세데이터가 나가서 바다를 건너기 위해 해저 광케이블을 타고 일본 데이터 센터의 Relay Server에서 처리가 되고 다시 또, 바다를 건너기 위해 해저 광케이블을 타고 전남고등학교로 처리된 시세 데이터가 도착할 것 이다.
이 과정은 60ms ~ 140ms(0.06~ 0.14초)가 걸린다. 물론, Tokyo에 위치한 Relay Server가 혼잡, 즉 사용량이 많으면, 도쿄 다음으로 가까운 대만에 위치한 Relay Server를 이용할 수 있다. 이렇게 되면, 100ms(0.1초)가 넘게 된다.

0.1초면 짧은거 아닌가요?

1초에 수천건거래가 되는데 암호화폐 시장에서 사용자에게 0.1초 시세데이터를 늦게 전송한다는 것은 다른 거래소를 이용하는 사용자보다 0.1초 늦게 받는다는 것이다. 그럼 매수/매도 타이밍을 놓쳐 손실을 볼 수 있다. 그래서 보다 사용자에게 더 빠르게 시세데이터를 제공하게 위해 대한민국에 중앙에 Tailscale Relay Server를 구축하는 이야기를 해보고자 한다.

서버 위치 선정

서버위치는 위 지도처럼 선정하였다. GPS Mark 색의 의미는 다음과 같다.

파란색: 전남고등학교 서버
빨간색: Tailscale Relay Server
녹색: 춘천 메시지 브로커 서버

메시지 브로커 서버 위치인 강원도 춘천과 광주 전남고등학교의 위치를 표시하고 직선으로 연결해보았더니, 중앙에 위치한 지역이 대전이었다. 그래서 대전에 위치한 데이터센터를 인터넷 검색을 통해 알아본 결과, 네이버의 각 세종 데이터센터였다. 지어진지 2년 밖에 되지않은 새 데이터센터 였다.
바로, 네이터클라우드의 VM 인스턴스를 생성하여 네이버클라우드의 각 세종 데이터센터의 서버 1대를 빌렸다.

Tailscale Relay Server 구축 방법 & 문제 해결

Github Repository: https://github.com/fredliang44/derper-docker

결론부터 말하자면, 도커 컨테이너라는 기술을 이용하여 쉽게 구축하였다.
도커 컨테이너는 Relay Server를 실행하는데 필요한 모든 것을 담고 있는 이동식 컨테이너 같은 것으로, 독립된 공간을 생성하고 모든 컴퓨터에서 작동시키게 하는 가상환경이다.
독립된 공간을 생성하고 모든 컴퓨터에서 작동시키게하는 가상환경이라는 말이 중요한데, 이것은 개발한 컴퓨터와 서버 컴퓨터의 환경이 달라고 컨테이너라는 기술이 있다면 어디든지 오류없이 실행하여 구축 시간을 단축시킬수 있었다!

설치 방법은 다음과 같다. (Ubuntu 24.04 LTS 기준)

sudo apt install docker.io docker-compose

위 명령어로 Docker와 Docker Compose를 설치한다.

sudo docker run -e DERP_DOMAIN=derper.your-domain.com -p 80:80 -p 443:443 -p 3478:3478/udp fredliang/derper

이 명령어로 tailscale relay server 도커 컨테이너 이미지를 다운받고 실행한다.
여기서 주의할 점이고, 헤맸던 부분이기도 한데, DERP_DOMAIN값에 IP주소를 입력하면 안된다.
Relay Server는 종단간 암호화 통신을 하는데, 이때 SSL 인증서가 필요하다.
SSL 인증서를 발급하려면 Let's Encrypt라는 무료 SSL 인증서 발급이 필요한데, 발급할때 도메인 인증을 필요로한다.
그래서 도메인 인증을 하기위해 DERP_DOMAIN값이 필요하다.
나는 도메인을 구입하여 DERP_DOMAIN에 구입한 도메인 값을 넣어 해결하였다!
컨테이너 이미지를 만들며, 서버의 다양한 옵션을 추가였는데 다음 표와 같다.

env	required	description	default value
DERP_DOMAIN	true	derper 서버 호스트 이름	your-hostname.com
DERP_CERT_DIR	false	LetsEncrypt 인증서를 저장할 디렉토리 (주소의 포트가 :443일 경우)	/app/certs
DERP_CERT_MODE	false	인증서 획득 모드. 가능한 옵션: manual, letsencrypt	letsencrypt
DERP_ADDR	false	서버가 리스닝할 주소	:443
DERP_STUN	false	STUN 서버도 함께 실행할지 여부	true
DERP_STUN_PORT	false	STUN 서비스를 제공할 UDP 포트	3478
DERP_HTTP_PORT	false	HTTP 서비스를 제공할 포트. -1로 설정하면 비활성화됨	80
DERP_VERIFY_CLIENTS	false	이 DERP 서버의 클라이언트를 로컬 tailscaled 인스턴스를 통해 검증할지 여부	false
DERP_VERIFY_CLIENT_URL	false	비어있지 않다면, 클라이언트 연결을 허용할지 여부를 판단하는 승인 컨트롤러 URL	""

성과

성능향상은 다음과 같다

기존에 구축된 공용 Relay Server (도쿄): 60ms ~ 140ms
새롭게 세종특별자치시에 위치한 네이버 클라우드의 각 세종 데이터센터에 구축한 Relay Server: 20ms ~ 30ms
P2P 연결: 7ms ~ 13ms

기존보다 지연시간이 3배 가량 단축되었다. 또한 P2P 연결과 거의 근사하게 지연시간이 짧아져서 Relay Server 연결과 P2P 연결의 성능차이가 사라졌다고 볼 수 있었다.

마무리

사용자들에게 0.1초라도 빠르게 시세데이터를 전달하려고 하다 보니, 학생이 아니라 인프라 엔지니어가 된 기분이었다.
문제점이 서버간의 통신에 지연이 발생한다는 점이었는데, 이것의 원인을 파악하기 위해서 각 서버에서 서버로 데이터를 보내서 지연시간을 측정한 후, 어디서 지연시간이 크게 측정하는지 분석하였었다.
이때 공용 Relay Server가 해외에 있어 지연시간을 긴 것을 보고 원인을 파악하였다.
원인이 해외 있는 공용 Relay Server 떄문이니, 국내에 Relay Server를 구축하면 해결되지 않을까? 라는 아이디어로 문제가 해결되기 시작했다.
그래서 Relay Server를 구축하기 위해 Tailscale 공식 문서를 찾아보고, 개발자들이 인터넷에 올린 블로그 등 수 많은 정보를 탐색한 결과 도커 컨테이너 기술을 이용하면 빠르게 구축할 수 있다는 것을 알 수 있었다.
Relay Server를 구축하기 위해 Docker Container 이미지를 생성하는 방법을 배우고, 구축하였다.
이렇게, 문제가 발생하면 문제가 발생한 지점을 발견하여 역으로 따라가는 방법을 생각하여 사용하였는데, 이게 문제 해결에 도움이 많이 되었다.
또한 원인을 파악하고 문제를 해결하기위해 새로운 기술을 알고 배워서 사용하는거 까지 포기하지않고 한 내가 한 단계 성장한 것 같았다.

이제 대학에 가서도 수 많은 컴퓨터 관련 문제들을 부딫히고, 해결할텐데 이번 탐구에서 얻는 문제가 발생한 지점에서 역으로 따라가는 방법으로 문제를 해결해야겠다.