일본 게임 서버 네트워크 튜닝 — 지연을 1ms 줄이는 실전 설정

게임 서버는 일반 웹 서비스와 다릅니다. 처리량보다 지연(latency) 과 지터(jitter) 가 사용자 체감에 직결되며, 1프레임(16.7ms)을 늘리는 순간 캐릭터가 미끄러지듯 보이기 시작합니다. 이 글에서는 일본 도쿄 IDC에 위치한 게임 서버에서 적용할 수 있는 네트워크 튜닝 포인트를 정리합니다.

게임 서버에서 중요한 지표

지표	의미	목표
지연(Latency)	RTT의 절반, 일방향 시간	한국→일본 ≤ 30ms
지터(Jitter)	RTT의 변동폭	≤ 5ms
패킷 손실	사라진 패킷 비율	≤ 0.1%
처리량(Throughput)	초당 패킷 수	게임에 따라

웹은 1초가 빠르고 늦고에 민감하지만, 게임은 5ms와 10ms의 차이가 곧 승패에 영향을 줍니다.

1단계 — 데이터센터 위치 선택

같은 일본이라도 도쿄/오사카/후쿠오카에 따라 한국 사용자와의 RTT가 다릅니다.

위치	한국(서울)→일본 RTT	비고
도쿄 (KIX-NRT 우회 경로)	25~35ms	가장 보편적, 가성비
오사카	30~40ms	도쿄보다 약간 길지만 안정적
후쿠오카	20~25ms	한국과 가장 가까움, 한국 게이머 대상 게임에 유리

다만 후쿠오카는 IDC 선택지가 좁아 가용성이 떨어질 수 있습니다. 글로벌 사용자도 함께 받는다면 도쿄가 균형이 좋습니다.

2단계 — NIC 큐와 IRQ 분산

게임 서버처럼 패킷이 많은 워크로드는 단일 CPU에 인터럽트가 몰리면 그 코어만 100%가 되고 다른 코어는 놀게 됩니다. RSS(Receive Side Scaling)로 큐를 늘리고 IRQ를 분산해야 합니다.

# NIC가 지원하는 큐 개수 확인
ethtool -l eth0

# 큐 개수를 코어 수 만큼 설정
sudo ethtool -L eth0 combined 8

# IRQ를 각 코어에 분산
sudo systemctl enable --now irqbalance

수동으로 IRQ를 고정하고 싶다면 set_irq_affinity.sh 스크립트를 사용하거나 /proc/irq/<번호>/smp_affinity를 직접 편집합니다.

3단계 — TCP/UDP 버퍼 튜닝

게임이 UDP를 쓰더라도 백엔드 통신(DB, 인증)은 대부분 TCP입니다. 양쪽 모두 튜닝합니다.

# /etc/sysctl.d/99-game.conf
# 수신/송신 버퍼 (최소 / 기본 / 최대)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# UDP 수신 버퍼 (대형 게임 패킷에 중요)
net.core.netdev_max_backlog = 5000

# TIME_WAIT 빠르게 재사용
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# 동시 연결 백로그
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096

# 임시 포트 범위 확장 (클라이언트 연결이 많을 때)
net.ipv4.ip_local_port_range = 10240 65535

sudo sysctl --system

주의: tcp_tw_recycle은 더 이상 권장되지 않으며 NAT 환경에서 문제를 일으킵니다. tcp_tw_reuse만 사용하세요.

4단계 — 혼잡 제어 알고리즘

기본 알고리즘은 cubic이지만, 한국-일본처럼 RTT가 짧은 회선에서는 BBR이 더 좋은 결과를 내는 경우가 많습니다.

# 현재 알고리즘 확인
sysctl net.ipv4.tcp_congestion_control

# 사용 가능한 알고리즘 확인
sysctl net.ipv4.tcp_available_congestion_control

# BBR 활성화
echo "net.core.default_qdisc = fq" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control = bbr" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

BBR은 패킷 손실이 아니라 대역폭과 RTT 측정으로 혼잡을 판단해, 짧은 RTT 환경에서 cubic보다 응답성이 좋습니다.

5단계 — UDP 게임 서버 최적화

대부분의 실시간 게임(FPS, MOBA 등)은 UDP를 사용합니다. UDP 특유의 튜닝 포인트가 있습니다.

# UDP 메모리 풀 (16MB)
sysctl -w net.ipv4.udp_mem="65536 131072 262144"

# UDP 수신 큐 깊이
sysctl -w net.core.netdev_max_backlog=10000

게임 서버 프로세스의 소켓 버퍼 크기도 코드에서 직접 늘려야 합니다.

int size = 4 * 1024 * 1024;  // 4MB
setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size));
setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));

6단계 — MTU와 패킷 단편화

기본 MTU는 1500입니다. PPPoE 회선이 섞이면 1492로 떨어지며, 단편화가 일어나면 한 패킷의 손실이 두 배 영향을 줍니다.

# MTU 확인
ip link show eth0

# 경로상 단편화가 일어나는지 테스트
ping -c 3 -M do -s 1472 example.com   # 1472 + 28 = 1500

Frag needed가 보이면 경로상 MTU가 1500보다 작은 구간이 있습니다. 게임 서버에서는 페이로드를 1400 이하로 유지하는 것이 안전합니다.

7단계 — DDoS 보호

게임 서버는 일반 사이트보다 DDoS 표적이 되기 쉽습니다. 특히 UDP 서비스는 reflection 공격 발생 시 응답을 못 보내게 됩니다.

# UDP 응답 속도 제한 (서비스 포트 외)
iptables -A INPUT -p udp -m limit --limit 1000/s --limit-burst 2000 -j ACCEPT
iptables -A INPUT -p udp -j DROP

# SYN Flood 방어
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_synack_retries=2

L3/L4 단의 대형 공격은 호스팅사 네트워크에서 막아야 합니다. TCP-80.NET의 전용서버는 모두 L3/L4 DDoS 방어가 무료 기본 포함이며, 전용 DDoS 보호 서비스로 L7까지 강화할 수 있습니다.

8단계 — 모니터링

지연/손실은 자주 측정해야 의미가 있습니다.

# 실시간 RTT/손실
mtr --report --report-cycles 100 client-ip

# 인터페이스 패킷 통계
ip -s link show eth0

# 드롭 발생 여부
netstat -s | grep -i drop

# softirq 부하 (특정 코어가 100%인지)
mpstat -P ALL 1

지속적인 모니터링은 모니터링 가이드를 참고하세요. Netdata로 NIC 큐별 RX/TX, softirq, CPU 분포까지 한 화면에서 볼 수 있습니다.

마무리

게임 서버 튜닝은 “어느 한 가지 설정으로 모든 게 빨라지는” 마법이 없습니다. 위치 선정 → 인터럽트 분산 → 버퍼/혼잡제어 → DDoS 보호 의 단계를 차례로 점검하면, 같은 하드웨어에서 1~3ms를 줄일 수 있습니다.

TCP-80.NET은 도쿄 IDC 직영으로 한국 회선까지의 경로가 짧고 안정적입니다. 게임 서버용 전용서버 구성에 대한 문의는 @tcp80net으로 부탁드립니다.