ゼロダウンタイム、ゼロギャップ：フォールトトレラントなSolana gRPCストリーミングの構築方法

最終更新日: 2026年5月6日1分で読めます

トレーディングインフラ、MEVサーチャー、清算ボット、リアルタイムインデクサーを構築するチームにとって、プロダクトの速度はそれに供給されるデータの速度に依存する。ストリームにスパイクやドロップが発生すれば、取引の見逃しやインデックスの欠落につながる。

そのため、私たちはSolana gRPCストリーミングプロダクトをマルチノード冗長レイヤー上に構築した。スパイクやドロップオフはパイプラインに到達する前に吸収され、マネージドサービスであるはずのものの上にフェイルオーバーロジックを自前で実装する必要はない。以下がそのアーキテクチャの詳細である。

SolanaでgRPCが重要な理由

Solanaのデータ出力量は膨大で、ピーク速度では年間4ペタバイトを超える。JSON-RPCによる従来のポーリングには不要なオーバーヘッドが伴う——繰り返しのリクエスト、帯域の浪費、リクエスト・レスポンスサイクル特有のレイテンシだ。アカウントの更新やトランザクションを確定した瞬間に取得する必要のあるワークロードにとって、ポーリングでは不十分である。

Protobuf/HTTP2上のgRPCストリーミングはこのモデルを逆転させる。サーバーはデータが生成されるとクライアントにプッシュする。ビルダーは特定のアカウント、プログラム、トランザクションパターンなど、必要なデータのみを購読し、ポーリングによるレイテンシなしで継続的にフィルタリングされたストリームを受け取れる。ブロックタイムが1秒未満でデータ量が膨大なSolanaにおいて、これは最新のデータをユーザーに届けることを優先するアプリにとって理想的なソリューションだ。

Yellowstone gRPCインターフェースは、Solanaストリーミングの事実上の標準となっている。ビルダーはRust、TypeScript、Go、そして.protoファイルをコンパイルできる任意の言語向けの既存クライアントライブラリを利用できる。私たちはこの標準を活用したため、Yellowstone互換のプロバイダーからの移行はURLの変更のみで済み、書き直しは不要だ。

アーキテクチャ：shredからストリームまで

私たちのストリーミングパイプラインは4つのレイヤーで構成されており、それぞれが規模に応じた信頼性のあるパフォーマンスのために冗長性を組み込んで設計されている。

Shredの取り込み

ShredはSolanaにおけるデータ伝播の基本単位であり、ブロックエントリの断片を含むMTUサイズ（約1,280バイト）のフレームだ。ネットワークはTurbineというマルチホッププロトコルを介してshredをブロードキャストし、バリデータが階層化された近傍を通じてデータをリレーする。Turbineは高速だが確率的な性質を持つ。パケットロスはホップを重ねるごとに蓄積し、ツリーの深い位置にあるノードは完全なブロックを組み立てる前にギャップ修復を数百ミリ秒待つ必要が生じることがある。

私たちは複数の独立したソースから同時にshredを取り込んでいる——高ステークバリデータから直接shredを収集し、Turbineのマルチホップレイテンシを回避するサービスも含まれる。各ソースは異なる地理的経路とバリデータの近傍をカバーする。あるストリームのギャップは別のストリームで埋められるため、修復サイクルが減り、ブロックの組み立てが速くなる。

これが重要なのは、ノードが各スロットを組み立てるために最低限必要な数のshredがあるためだ。約250ミリ秒以内に十分な数を受信できなければ、修復プロトコルにフォールバックし、ピアに欠落したshredをリクエストすることになり、相当なレイテンシが加わる。修復が発動する前に十分なshredを確保することが重要だ。だからこそ私たちは複数の独立したソースから取り込んでいる——カバレッジが広いほど、ノードがその閾値に早く到達し、エントリをより早く組み立て、Geyser通知をより早く発火できる。ここで節約される1ミリ秒ごとに、下流全体に波及していく。

Richatエンジン

私たちのストリーミングサービスの中核にあるのがRichatだ。これはSolanaノード上でGeyserプラグインとして動作するオープンソースエンジンである。Agaveクライアントによって生成されるアカウント更新、トランザクション通知、スロットステータス、ブロックメタデータ、エントリ更新を取得し、集約とファンアウトのレイヤーとして機能するRichatサーバーへストリーミングする。

重要な設計判断は、各Richatサーバーが複数のアップストリームSolanaノードに同時接続することだ。ソース間で更新を重複排除し、下流に最も速い健全な結果を配信する。あるアップストリームノードがスロットで遅れを取った場合、集約レイヤーは次に速いノードからデータを提供する。

これがレイテンシスパイクの減衰を実現している。シングルノード構成ではp99やp999レイテンシのロングテールが発生する。アップストリームノードで生じる悪い瞬間がすべてのコンシューマーにそのまま伝わってしまうためだ。マルチノード集約はそのテールを平坦化する——ビルダーのストリームは、その時点で唯一のノードではなく、最も性能の良いノードを反映するようになる。

ビルダー側のストリーム

ビルダーは標準のYellowstoneクライアントライブラリで接続する。接続後は、アカウント更新（プログラム、オーナー、データスライスによるフィルタ付き）、トランザクション更新（アカウントのinclude/excludeおよびシグネチャフィルタ付き）、スロット、ブロック、ブロックメタ、エントリの更新を購読できる。コミットメントレベル（processed、confirmed、finalized）、Zstd圧縮、サーバーサイドのkeepaliveはすべてネイティブでサポートされている。

複数の同時購読を、単一の接続上でAND/OR条件を組み合わせて構成できる。双方向ストリーミングにより、ビルダーは再接続せずに購読、変更、キャンセルを行える。

再接続時のリプレイ

短時間の切断やクライアントの再起動は避けられない。問題は、それによってビルダーがデータを失うかどうかだ。

私たちはRichatのリングバッファに直近の更新を一定期間分保持している。クライアントが再接続する際は、from_slotパラメータを指定して購読することで、見逃した分をバックフィルしてからライブストリームに追いつくことができる。別途バックフィルパイプラインを用意する必要はない。維持すべきギャップ検出ロジックもない。コンシューマーと並行して稼働させる照合サービスも不要だ。

これは、長期間にわたってギャップのないストリームを必要とするビルダー——インデクサー、分析プラットフォーム、更新の見逃しが許されないステートフルなコンシューマーを運用する人々にとって、よりシンプルな運用モデルとなる。