Solana VPS와 베어메탈 선택 | CPU·UDP·네트워크 측정 | ERPC

Solana 스트림만큼 실행 서버가 중요한 이유

Solana 스트림이 빠르다고 애플리케이션에 필요한 데이터까지 즉시 도착하는 것은 아닙니다. CPU 사용률이 낮고 1Gbps 포트가 있어도 Shreds가 누락되거나 gRPC 지연이 쌓일 수 있습니다. 원인을 특정 기업에 돌리기보다, 데이터 소스부터 처리 단계까지 측정해야 합니다. 이 글은 익명화된 조사 기록과 독립 테스트, 공개 벤치마크를 바탕으로 선택 기준을 설명합니다.

빠른 Solana에는 많은 패킷과 순간 부하가 따릅니다

Shreds와 Yellowstone Geyser gRPC는 데이터를 지속적으로 전송하고 짧은 버스트를 만들 수 있습니다. 대역폭, 초당 패킷 수(PPS), RTT, 지터, 손실, 앱 처리 시간은 서로 다른 지표입니다. 4MB/s를 30일 유지하면 약 10.4TB지만 평균은 32Mbps입니다. 따라서 1Gbps가 부족하다고 단정할 수 없으며 UDP 제한, 공유 업링크, 버스트 처리와 수신 큐를 확인해야 합니다.

스트림은 살아 있어도 데이터는 완성되지 않을 수 있습니다

익명화된 사례에서 송신 측은 약 3,400~3,900 UDP 패킷/초를 기록했고, 다른 시점의 수신 측 보고는 약 13패킷/초였습니다. 수신한 Shreds는 유효했으나 복원에 필요한 데이터가 부족했습니다. 같은 서버에서 gRPC는 동작했습니다. 두 측정은 시간과 위치가 달라 정확한 손실률이나 원인을 추론할 수 없습니다. 수천 PPS가 일반 서버에 무조건 과도한 부하도 아닙니다.

서버를 바꾸기 전에 패킷의 관측 지점을 찾으세요

UDP는 DDoS 보호, 네트워크 정책, 가상화 호스트에서 게스트 도착 전 제한될 수 있습니다. NIC에 도달한 뒤에도 커널, 소켓 버퍼, 앱에서 드롭될 수 있습니다. tcpdump로 수신 인터페이스를 먼저 확인하고 NIC 카운터, UDP 오류, 큐를 점검하세요. XDP는 tcpdump 전에 패킷을 버릴 수 있습니다. 송신·수신의 목적지, 포트, 시간 창을 맞춰야 합니다.

같은 도시에 있어도 네트워크 경로는 멀 수 있습니다

Frankfurt에 있는 두 서버도 서로 다른 시설과 외부 transit 경로를 이용할 수 있습니다. 실제 조사에서 서로 약 0.1ms 떨어진 Amsterdam 엔드포인트 두 곳으로 외부 서버에서 측정한 RTT는 약 11ms와 23ms였습니다. 다른 시간에는 상위 경로에서 5~8% 손실과 약 5ms의 추가 지연도 보고됐습니다. 이는 특정 경로의 관측값이지 모든 사업자의 일반적 특성은 아닙니다.

데이터 소스 가까이에서 실행하세요

보통 RPC 제공자와 컴퓨팅 호스팅 업체는 별도로 운영됩니다. ERPC는 Shreds, Geyser gRPC, RPC와 VPS·베어메탈을 함께 설계합니다. 지원되는 거점에서는 가까운 랙 간 로컬 네트워크로 불필요한 외부 우회를 줄입니다. Zero-Distance Communication은 물리적 거리나 지연이 문자 그대로 0이라는 뜻이 아닙니다. 실제 경로를 측정해야 합니다.

실제로 수신한 데이터를 비교하세요

같은 Amsterdam 엔드포인트의 유사한 Geyser gRPC 구독에서 외부 호스팅은 3.7~4.2MiB/s로 수신하며 lag가 증가했습니다. ERPC Frankfurt VPS에서 CPU 1코어로 제한한 독립 테스트는 60초 동안 평균 9.396MiB/s와 약 1,910tx/s를 수신하고 지연이 누적되지 않았습니다. 문제 경로의 TCP 재전송도 관측됐습니다. 하지만 호스트와 클라이언트 구현이 달라 엄격한 A/B 테스트가 아닙니다. 별도의 HTTP/2 시험에서는 16KiB 수신 창에서 2.7MB/s, 더 큰 창에서 최대 7.1MB/s였습니다.

CPU 이름만으로는 숨겨진 제한을 알 수 없습니다

같은 CPU 세대와 vCPU 수라도 부스트, 전력, 냉각, 스케줄링 정책이 다릅니다. AMD Core Performance Boost와 Intel Turbo Boost는 호스트·BIOS에서 비활성화할 수 있습니다. 활성화돼도 최고 클럭을 지속할 보장은 없습니다. 게스트 VM에는 호스트 정책이 표시되지 않을 수 있습니다. 실제 워크로드의 지속 성능을 측정하세요.

4 vCPU에서 확인된 1.93배 벤치마크 차이

ERPC의 Amsterdam AMD Turin 4-vCPU Ubuntu 24.04 공개 비교에서는 sysbench CPU가 ERPC 7,850 events/s, 비교 클라우드 VM 4,062 events/s로 약 1.93배였습니다. 같은 공개 자료에는 메모리 대역폭 약 3.2배, 4K 랜덤 읽기 IOPS 약 16.6배 차이도 있습니다. 이는 특정 테스트의 결과이며 부스트만의 효과나 모든 앱의 속도를 보장하지 않습니다.

데이터센터의 경제성이 성능 설계를 바꿉니다

전력, 냉각, 랙, 스위치, 회선, 운영 비용은 공유 자원을 합리적으로 만듭니다. 일반적인 앱에서는 경제적이지만 높은 부하의 Solana 스트림에는 지속적인 CPU, PPS, 업링크 여유가 필요할 수 있습니다. 공유 대역폭, 흐름별 제한, DDoS 보호, 절전 정책은 용도에 따라 적절할 수도 있습니다. 특정 업체를 비난하지 말고 자신의 워크로드와 맞는지 확인하세요.

클라우드 전송 비용도 계산하세요

지속적인 스트림은 시간이 지나면 TB 단위 데이터가 됩니다. 일부 클라우드는 인터넷 유입은 무료이지만 외부 송신, 존 간 이동, 서비스 간 전송에 요금을 부과합니다. 해당 ERPC 플랜은 플랫폼 내부 트래픽을 외부 전송량과 구분합니다. 최신 요금 조건을 확인하고 VM 월 요금뿐 아니라 전체 데이터 경로의 비용을 비교하세요.

워크로드에 맞게 VPS와 베어메탈을 선택하세요

가벼운 RPC에는 EPYC VPS가 충분할 수 있고, 지속적인 gRPC 분석에는 CPU·메모리 여유가 필요합니다. UDP Shreds·저지연 거래에는 UDP 정책, PPS, 버스트, 근접 배치, 감지 지연을 측정해야 합니다. 물리 코어·NIC를 독점해야 한다면 베어메탈을 검토하되 모든 앱에서 항상 빠른 것은 아닙니다. 여러 VPS로 분산하는 방법도 있습니다. 같은 필터, 앱, 시간대로 유효 Shreds, 복원, lag, 재전송, p95/p99를 비교하세요.

계약 전 실제로 측정하세요

Linux에서 tcpdump, nstat, ip -s link, ethtool -S, ss -tin, lscpu로 설정을 바꾸지 않는 초기 점검을 할 수 있습니다. 예시 IP와 인터페이스를 실제 값으로 바꾸고 카운터 증가량을 확인하세요. lscpu만으로 하이퍼바이저 부스트 정책을 알 수 없습니다. ERPC는 재고와 플랜에 따라 VPS·베어메탈 시간 과금을 제공합니다. 필요한 데이터를 제시간에 사용할 수 있는 환경을 선택하세요.

bash

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu