Solana向けVPS・ベアメタルの選び方：CPU・UDP・ネットワーク性能を実測から解説
Solanaの高速性を活かすには、サーバーから考える
高速なSolanaストリームを使っている。CPUには余裕があり、ネットワークも1Gbpsある。それなのにShredsが揃わず、Geyser gRPCの受信遅延が増えていく。そんな経験はありませんか。
サーバーの仕様表だけを見ても、原因がわからないことがあります。データソースからアプリケーションまで、どこで時間やパケットが失われているのか。ERPCのインフラ運用と技術サポートで得た匿名化した観測記録、独立検証、公開ベンチマークから、Solana向けVPS・ベアメタルの選び方を解説します。事業者の良し悪しではなく、実行環境が用途に適しているかを考えます。
高速なSolanaは、大量のデータを生み出す
Raw ShredsやYellowstone Geyser gRPCではデータが継続的に届き、短時間のバーストが発生することもあります。帯域幅（bps）、PPS（毎秒のパケット数）、RTT、ジッター、損失率、アプリケーションの処理時間はそれぞれ異なる指標です。
仮に毎秒4MBのストリームが30日間続けば約10.4TBですが、平均速度は32Mbpsです。それだけで1Gbps回線が不足すると決めつけることはできません。必要なのは瞬間的な通信量、UDPに適用される制限、共有アップリンク、受信処理の能力まで測ることです。
ストリームは動いている。それでもデータが揃わない
ある匿名化したUDPの調査では、送信側で約3,400〜3,900パケット/秒、別の時間帯に受信側から約13パケット/秒が報告されました。届いたShredsは正常に解析できましたが、必要な断片が不足し、スロットを復元できませんでした。同じホストではgRPCを利用できていました。
重要なのは測定した日時と地点が異なることです。これらの値から厳密な損失率を出したり、原因の事業者を特定したりはできません。数千PPSという数字だけで一般的なサーバーには高すぎる負荷だとも言えません。TCP/gRPCが動いていても、UDPの通信と受信アプリケーションが正常な証明にはならないのです。
機械を替える前に、パケットの観測地点を確かめる
UDPはホスト到達前に、上位ネットワークの通信ポリシー、DDoS対策、仮想化ホストなどで制限されることがあります。NICへ届いた後も、カーネルやソケットのバッファ、アプリケーションの処理が追いつかず破棄される場合があります。
最初に受信インターフェースをキャプチャし、NIC・UDPのカウンタ、受信ループを照合します。XDPなど、tcpdumpで確認する前の段階で動作する処理もあります。宛先・ポート・測定時間を両端で揃え、別々の時間帯の値を配信成功率として扱わないことが重要です。
近いはずなのに、遠回り
配信元と実行サーバーが両方Frankfurtにあっても、別の施設やネットワークであれば外部へ迂回する場合があります。別の調査では、互いに約0.1msしか離れていないAmsterdamのエンドポイントに対し、同じ外部ホストから約11msと23msのRTTを観測しました。ある時間帯には上位経路で5〜8%の損失と約5msの追加遅延も報告されています。
都市名だけではネットワーク品質はわかりません。接続相手までの経路、RTTとジッターのばらつきを測定してください。ただし、すべての外部経路に問題があるわけではありません。
データソースのそばに、実行環境を
一般的にRPCプロバイダーはデータ配信を、ホスティング事業者は実行サーバーを提供します。別々に契約しても近接ラックになるとは限りません。ERPCはShreds・Geyser gRPC・RPCとVPS・ベアメタルを一体として設計し、対応拠点では同じ施設や近接ラックでローカルネットワーク経由の通信を可能にしています。
これがZero-Distance Communicationの発想です。遅延や物理距離が文字どおりゼロになるのではなく、不要な外部経路を減らす考え方です。プライベートIPを使えば必ず速くなるという意味でもありません。
比べるのは、届いたデータ
別のGeyser gRPCの調査では、同じAmsterdamの配信先と同等の購読条件で、外部ホスティング環境が3.7〜4.2MiB/sにとどまり、受信遅延が蓄積しました。ERPC側のFrankfurt VPSでCPUを1コアに制限した独立検証では、平均9.396MiB/s、約1,910tx/sを60秒間受信し、遅延の蓄積は見られませんでした。問題の経路ではTCP再送も観測されています。
ただし受信ホストとアプリケーション実装が異なるため、厳密な同一アプリA/Bテストではありません。差のすべてをERPC VPSの性能に帰属させることもできません。
別のHTTP/2受信ウィンドウ検証では、16KiBで約2.7MB/s、より大きなウィンドウで最大7.1MB/sを確認しました。物理ポートの速度だけではフロー制御による制限を解消できません。
CPUにも、見えない上限がある
同じCPU世代とvCPU数でも、ブースト、電力、温度、CPU時間の共有方針は異なります。AMD Core Performance BoostやIntel Turbo BoostはBIOS・ホスト側で無効化でき、許可されても電力・冷却、動作コア数によって最高クロックを維持できるとは限りません。仮想環境ではホストの設定を確認できない場合もあります。
短時間の最高値ではなく、実際のワークロードで継続的な処理性能を測定しましょう。
4 vCPU。実測で1.93倍
ERPC公開のnode_bench比較では、AmsterdamでAMD Turin世代、4 vCPU、Ubuntu 24.04の環境を測定しています。sysbench CPUの4スレッド試験で、ERPCは7,850events/s、比較対象のクラウドVMは4,062events/s。特定条件で約1.93倍でした。同じ公開比較ではメモリ帯域約3.2倍、4KランダムリードIOPS約16.6倍の差も記録されています。
すべてのアプリでこの差が出るわけではなく、CPUブーストだけが原因である証明にもなりません。大切なのはカタログの型番だけで判断しないことです。
データセンターの経済性を考える
サーバーを提供するには、電力、冷却、ラック、NIC、スイッチ、上位回線、保守に費用がかかります。平均負荷を想定して設備を共有し、省電力を優先することは一般的なアプリケーションを安く提供する合理的な方法です。一方、Solanaの高負荷処理では、CPUクロック、PPS、ネットワーク、メモリ、ストレージへ継続的な余裕が求められることがあります。
共有・ベストエフォートの帯域、フロー制限、DDoS対策、ブーストの設定は事業者の運用方針です。コストを抑える設計が悪いのではなく、自分の用途に合うか確かめましょう。
クラウドの転送料金も忘れない
継続するストリームは平均帯域が小さくても総通信量が積み上がります。クラウドではインターネットからの受信が無料でも、外部への送信やゾーン間・サービス間転送に費用が発生する場合があります。ERPCの対象製品ではプラットフォーム内の通信と外部転送枠を区別しています。最新のプラン・リージョンごとの条件を確認してください。
VM単体の月額ではなく、データが通る経路全体のコストが重要です。
自分の用途に合う構成を選ぶ
軽いRPCならEPYC VPS、継続的なgRPC分析にはCPUとメモリに余裕のあるVPSやSUPER VPSが適する場合があります。低遅延のShreds UDPや取引向けの処理では近接配置、UDPポリシー、到達PPS、バースト耐性、検出遅延を優先します。物理CPUやNICの専有が必要ならベアメタルを検討しますが、必ずしもすべての用途でVPSより高速とは限りません。処理を2台のVPSへ分散する方法もあります。
同じ購読条件、アプリ、測定時間で、有効なShreds、再構成できたデータ、到達PPS、gRPC lag、TCP再送、CPU使用率、p95/p99遅延を比較してください。ホスト間で時刻を比べる場合は時計の同期精度にも注意します。
長期契約の前に、実測する
Linuxでは次の読み取り中心のコマンドから始められます。文書用IPとNIC名を実際の値に置き換え、本番環境では短時間のキャプチャに留め、取得データと負荷に注意してください。
bash
IFACE=ens3
SRC_IP=203.0.113.10 # 文書用アドレス。実際の送信元へ変更
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
lscpuIFACE=ens3
SRC_IP=203.0.113.10 # 文書用アドレス。実際の送信元へ変更
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カウンタがホスト全体を示す場合は時間差分を取り、tcpdump自身の取りこぼしも確認します。lscpuだけではホストのブースト設定は判定できません。
ERPCでは対象となるVPS・ベアメタルを時間課金で試せます。在庫・料金・注文条件はDashboardで確認してください。大切なのは仕様表の最大値ではなく、必要なデータを必要な時間内に使えることです。
