なぜ ERPC の VPS はハイパフォーマンスを発揮できるのか
なぜ ERPC の VPS はハイパフォーマンスを発揮できるのか
Solana を使ってアプリケーションや bot を構築し始める段階では、多くの開発者の皆様が、これまでの慣習どおり多用途向けの大規模クラウドを選択されます。
Web2 の世界では、これらのクラウドが事実上の標準であり、十分な性能を発揮してきたため、Solana でも同じ方法が適切だと考えることは自然です。
Web2 の世界では、これらのクラウドが事実上の標準であり、十分な性能を発揮してきたため、Solana でも同じ方法が適切だと考えることは自然です。
しかし、Solana の用途ではこの前提が大きく崩れます。
多用途向けの大規模クラウドは汎用性と柔軟性を優先する設計であるため、高速性が結果に直結する Solana のような用途では、構造の違いが最初から明確に現れます。
多用途向けの大規模クラウドは汎用性と柔軟性を優先する設計であるため、高速性が結果に直結する Solana のような用途では、構造の違いが最初から明確に現れます。
本記事では、多用途向けの大規模クラウドではなぜ Solana の性能が期待通りに出ないのか、そして ERPC の VPS がどのような構造でそれを解消しているのかを、段階的に丁寧に整理します。
Web2 では「大規模クラウドの遅さ」に気づく場面がほとんどない理由
まず前提として、Web2 の多くのアプリケーションは金融アプリケーションほどミッションクリティカルではありません。
SNS、EC、業務ツール、コンテンツ配信などは、多少の遅延があってもサービスとして成立します。
SNS、EC、業務ツール、コンテンツ配信などは、多少の遅延があってもサービスとして成立します。
そのため、多用途向けの大規模クラウドが内部で持つ以下のような構造的な遅さは、問題として表面化しませんでした。
- 多段の仮想化レイヤー（仮想 NIC、仮想スイッチなど）
- 共通の内部帯域を複数ユーザーで共有する構造
- CPU のオーバーコミット（物理コア以上の仮想コアを割り当てる運用）
- 課金・監視ソフトウェアによる追加処理
- 古い CPU 世代の一般開放
これらは多用途向け大規模クラウドでは必要とされる仕組みですが、Web2 の用途では影響が小さく、気づくきっかけがありませんでした。
しかし Solana の用途は全く異なります。
Web3 アプリは「金融の隣」にあり、すべてがミッションクリティカルになりうる
Solana 等ブロックチェーン上のアプリケーションは、金融領域と隣接しています。
資産の移動、清算条件、価格の変動、トランザクションの並び順など、あらゆる処理が直接結果に結びつきます。
資産の移動、清算条件、価格の変動、トランザクションの並び順など、あらゆる処理が直接結果に結びつきます。
特にマーケット関連の処理では、従来のクレジットカード決済と比較にならないほど多い取引量と速度が求められます。
「数ミリ秒遅い」が、そのまま「約定しない」「不利なレートになる」といった結果につながります。
「数ミリ秒遅い」が、そのまま「約定しない」「不利なレートになる」といった結果につながります。
また、Solana のチェーンデータは非常に大きく、Shreds、ログ、gRPC イベントなどをきちんと購読しようとすると、一日に数 TB のデータ量になることがあります。
これは多用途向けの大規模クラウドが想定してきた典型的な Web2 のトラフィック量とは根本的に異なります。
これは多用途向けの大規模クラウドが想定してきた典型的な Web2 のトラフィック量とは根本的に異なります。
このように、Solana は「クラウド内部に存在していた構造的な遅さや料金構造」を隠す余地がなく、
最初の段階から、それらがそのまま不利やコストとして表面化します。
最初の段階から、それらがそのまま不利やコストとして表面化します。
多用途向けの大規模クラウドが Solana に向かない理由
ここからは、多用途向けの大規模クラウドが Solana の高速用途に向かない理由を、個別の要素に分けて説明します。
1. 一般開放される CPU が数世代古い
多用途向けの大規模クラウドが提供するベアメタルサーバー及び VPS (VM) は、一般ユーザーが利用できる範囲では数世代前の CPU が中心です。
最新の高クロック CPU は、データセンター側の運用効率や在庫管理と整合しないため、一般向けにはほとんど選択肢として現れません。
最新の高クロック CPU は、データセンター側の運用効率や在庫管理と整合しないため、一般向けにはほとんど選択肢として現れません。
Solana の用途では単一スレッド性能やキャッシュ構造が重要になり、CPU 世代の差はそのまま
- どれだけのトランザクション処理に耐えられるか
- どれだけのストリームを取りこぼさず処理できるか
- どれだけ高速に処理を行うか
といった結果に影響します。
2. 仮想化レイヤーが多く、通信経路が長い（ネットワークレイテンシが大きくなる）
多用途向け大規模クラウドでは、単一の物理サーバーを多数の利用者で共有し、さまざまな用途を同時に成立させる必要があります。
そのために、仮想化や内部ネットワークのレイヤーがいくつも追加されています。
そのために、仮想化や内部ネットワークのレイヤーがいくつも追加されています。
例えば次のようなレイヤーです。
- 仮想サーバーを動かすためのハイパーバイザー
- 仮想 NIC や仮想スイッチ
- 内部ファイアウォールやロードバランサー
- 課金や監視のためのエージェント
これらはクラウド全体を安全かつ柔軟に運用するためには必要ですが、Solana の用途から見ると、
- どれも通信経路・処理経路を長くする
- どれもレイテンシと揺れの要因になる
という側面があります。
Shreds や gRPC のように、常時流れ続けるストリームを扱う用途では、この「余計な通過点」がすべてそのまま不利として積み上がります。
3. オーバーコミットによる性能の不安定化
多用途向け大規模クラウドでは、1 台の物理サーバーの上に、多数の仮想マシンを載せることで効率を上げています。
物理的には 64 コアの CPU を搭載したサーバーであっても、その上で 8 コアや 16 コアの VM を多数動かし、合計すると 128 コア以上の仮想コアが割り当てられるような構成は珍しくありません。
物理的には 64 コアの CPU を搭載したサーバーであっても、その上で 8 コアや 16 コアの VM を多数動かし、合計すると 128 コア以上の仮想コアが割り当てられるような構成は珍しくありません。
この「物理コア以上の仮想コアを割り当てる」運用がオーバーコミットです。
前提になっているのは、
- すべての VM が同時に CPU を全力で使うわけではない
- 誰かがアイドルのときに、別の誰かが CPU を使えればよい
という考え方です。
Web2 の用途では、この前提はそれなりに妥当です。
Web2 の用途では、この前提はそれなりに妥当です。
オーバーコミットされたサーバーでは、CPU の取り合いが頻繁に発生し、そのたびに OS がスケジューリングで『順番待ち』をさせることになります。
その結果として、
- ベンチマークでは速く見えるのに
- 実運用では時間帯や他利用者の負荷によってレイテンシが揺れる
という挙動になります。
Solana のように、トランザクション送信タイミングやストリーム処理のタイミングが結果に直結する用途では、この「揺れ」そのものが大きな不利になります。
4. データ転送量が多いと高額な従量課金が発生する
Solana のチェーンデータを真面目に監視しようとすると、Shreds、ログ、gRPC イベントなどを通じて、一日に数 TB のデータを扱うことが珍しくありません。
多用途向けの大規模クラウドは、サーバー本体の料金とは別に、
- 外向きネットワーク転送
- 場合によっては内部ネットワーク転送
- ストレージ I/O
といった項目を細かく従量課金する料金体系になっています。
Web2 の用途では、通信量自体が小さいため、こうした従量課金はほとんど目立ちません。
しかし Solana の用途では、ストリームを購読しているだけでネットワーク料金が数百ドル／日に達することもあり、「高速化以前に料金面で現実的ではない」という状況に陥ります。
しかし Solana の用途では、ストリームを購読しているだけでネットワーク料金が数百ドル／日に達することもあり、「高速化以前に料金面で現実的ではない」という状況に陥ります。
このように、多用途向けの大規模クラウドは、構造的にも料金的にも Solana の用途と噛み合っていません。
ERPC が世界中のデータセンターを検証してきた理由
こうした制約を理解したうえで、私たちはまず自分たちの Solana 用途に適したインフラを探す必要がありました。
その過程で行ったのが、世界中のデータセンターを実際に借り、Solana の実際のワークロードを流して検証するという作業です。
同じ都市にあるデータセンターであっても、
- 建屋構造
- ラック位置
- 内部配線
- どの IX やトランジットを利用しているか
- ネットワーク機器の性能や設定
- ISP キャパシティとルーティング品質
- 引き込まれている光ファイバー（敷設ルート）の量と品質
- 混雑時の帯域保証の方針
といった要素によって、Solana の用途に対する相性は大きく変わります。
検証を重ねるなかで、
- Solana 用途に安定して協力的な拠点
- スペック表や宣伝とは裏腹に、高速用途には向かない拠点
が明確に分かれていきました。
私たちは後者を切り捨て、前者に絞り込む作業を何度も繰り返し、現在のインフラ・ネットワーク構成に至っています。
この検証過程で得られた知見が、そのまま ERPC の VPS や RPC インフラの土台になっています。
この検証過程で得られた知見が、そのまま ERPC の VPS や RPC インフラの土台になっています。
ERPC の VPS がハイパフォーマンスを発揮する理由
ここからは、ERPC の VPS がどのような設計方針と構造で、Solana 用途のハイパフォーマンスを実現しているのかを説明します。
Solana の用途に限定して不要なレイヤーを削り込んでいる
多用途向け大規模クラウドは、あらゆるアプリケーションが動作できるよう複雑なレイヤーを備えています。
しかし Solana の用途では、その多くが直接的な価値を持たず、むしろレイテンシの原因になります。
しかし Solana の用途では、その多くが直接的な価値を持たず、むしろレイテンシの原因になります。
ERPC の VPS は Solana 用途に絞ることで、
- Solana のトラフィック処理には不要なレイヤー
- 多用途向け運用の都合だけで存在している処理
を一つずつ丁寧に取り除き、Solana の高速要求に適した構造へと削り込んでいます。
これは「単に簡略化した」という意味ではなく、Solana にとって意味のある部分だけを残すための設計方針です。
最新世代の CPU と ECC DDR5 メモリ
多用途向け大規模クラウドでは一般開放されない最新世代 CPU を採用し、
Solana RPC や Shredstream と同等の構成を VPS として提供しています。
Solana RPC や Shredstream と同等の構成を VPS として提供しています。
これにより、CPU 世代の差に起因するボトルネックを避けつつ、インデックス構築やトレードロジック、リアルタイム解析など、Solana 特有の負荷に耐えうる土台を提供しています。
オーバーコミットを行わない
特に Premium VPS では、物理コアに対して仮想コアを水増しするオーバーコミットを一切行っていません。
割り当てられたコアは、そのまま利用者のプロセスのために確保されます。
割り当てられたコアは、そのまま利用者のプロセスのために確保されます。
これにより、
- 他の利用者の負荷状況によって性能がぶれる
- 高負荷時に CPU の取り合いが発生する
といった問題を避け、Solana の用途に必要な安定した CPU 利用を実現しています。
一方、通常の VPS においても、オーバーコミット率を非常に低く抑え、安定した CPU 利用ができるよう配慮しています。
CPU は常時最大ターボで動作。省電力設定をしない設計
サーバー用途では、省電力や発熱抑制のために、負荷に応じてクロックを調整する設定が用いられることが一般的です。
ERPC の VPS では、Solana の用途においては最大性能を優先し、CPU が常時高いクロックで安定動作するようチューニングを行っています。
これにより、負荷の変動時にも性能が下振れしにくく、継続的な高パフォーマンスを維持します。
これにより、負荷の変動時にも性能が下振れしにくく、継続的な高パフォーマンスを維持します。
Solana の重要拠点ネットワーク上で動作している
ERPC の VPS は、単に「自社インフラに近い場所」にあるだけではありません。
Solana バリデータやステークが世界的に集中している、重要なネットワーク拠点そのものの上で動作しています。
Solana バリデータやステークが世界的に集中している、重要なネットワーク拠点そのものの上で動作しています。
標準 VPS は、バリデータ数およびステーク量が世界2位となっているネットワーク上に配置されています。
Premium VPS は、バリデータ数・ステーク量ともに世界1位の非常に高い集中度を持つネットワーク上で動作しており、Solana のリーダーや主要バリデータがもっとも集まるハブの一つと直結した構成です。
Premium VPS は、バリデータ数・ステーク量ともに世界1位の非常に高い集中度を持つネットワーク上で動作しており、Solana のリーダーや主要バリデータがもっとも集まるハブの一つと直結した構成です。
つまり ERPC の VPS は、
- ERPC 自身の RPC / gRPC / Shredstream インフラと同一ネットワークであることに加えて
- そもそもバリデータとステークがもっとも集中している Solana の重要拠点ネットワーク上で稼働している
という二重の意味で、リーダーに物理的・論理的に近い位置にあります。
その結果として、同じロジック・同じ実装のアプリケーションであっても、多用途向けの大規模クラウド上に置いた場合と比べて、リーダー近傍での検知や送信において構造的な優位性を持つことができます。
RAID0 を採用したストレージ構成
一般的なクラウドや VPS ベンダーは、ユーザーのデータ保護を最優先とするため、RAID10 や RAID4/5/6 といった冗長構成を採用することが多くあります。
ユーザーデータがサーバー内に強く依存している Web2 のシステムでは、これは正しい選択です。
ユーザーデータがサーバー内に強く依存している Web2 のシステムでは、これは正しい選択です。
一方で、多くの Web3 アプリケーションや Solana ノードは、アプリケーション層に「失われてはいけない唯一のデータ」を持たない構造になっており、
ブロックチェーン自体が分散台帳として機能し、必要に応じて同期や再構築が可能です。
ブロックチェーン自体が分散台帳として機能し、必要に応じて同期や再構築が可能です。
データのミラーリングよりもむしろパフォーマンスを好むお客様が多いこと、また Solana ノードの特性上、ストレージ I/O 性能が全体のパフォーマンスに大きく影響することから、ERPC の VPS ではストレージ構成として RAID0 を採用し、I/O 性能を最大限に引き出す設計としています。
Web3 時代のインフラでは、どの層にどのレベルの冗長性を持たせるかを適切に切り分けることで、性能と安全性のバランスを最適化することが可能です。
Web3 時代のインフラでは、どの層にどのレベルの冗長性を持たせるかを適切に切り分けることで、性能と安全性のバランスを最適化することが可能です。
参考データ - Real-World Speed Tests for Different SSD RAID Levels: https://larryjordan.com/articles/real-world-speed-results-for-different-raid-levels/
まとめ
ERPC の VPS がハイパフォーマンスを発揮する理由は、一つの要素だけでは説明できません。
CPU の世代、オーバーコミットの有無、省電力設定の徹底排除と最大ターボ化、データセンターの選定、ネットワーク経路、RAID 構成、Solana 用途に不要なレイヤーをどこまで削るかといった、一つひとつは小さく見える要素をすべて徹底的に突き詰めた結果として、現在の性能が出ています。
こうした積み重ねにより、多用途向けの大規模クラウドとはまったく異なる特性を持つ Web3・ブロックチェーン特化型インフラが成立し、Solana の用途において大きな差として現れます。
構成や導入についてのご相談、具体的なユースケースに応じた構成検討などは、Validators DAO 公式 Discord よりお問い合わせいただけます。
- ERPC 公式サイト: https://erpc.global/ja
- Validators DAO 公式 Discord: https://discord.gg/C7ZQSrCkYR
