--- title: "低レイテンシRPCインフラの構築方法" description: "RPCのレイテンシは単一のボトルネックではなく、システム全体の課題です。Alchemyがエッジ、ルーティング、スケーリング、ノード運用、計測の各面でレイテンシを削減した方法を紹介します。" --- # 低レイテンシRPCインフラの構築方法 ウォレットはユーザーの残高を読み込む。トレーディングアプリはスワップ前にgasを見積もる。インデクサーは数か月分の履歴を一度の処理で取り込む。これらの動作はすべてRPC呼び出しであり、その遅延の1ミリ秒ごとを、画面の前で待つ実際のユーザーが感じている。 RPCのレイテンシは単一の原因で起きるものではないため、単一の対策では解決できない。原因はリクエストパスのオーバーヘッド、避けられるはずの内部ネットワーク通信、非効率なルーティング、急激なトラフィックスパイク、チェーンおよびノードの運用上の遅れ、ワークロード固有のボトルネック、そして不完全な計測など多岐にわたる。ひとつを直しても残りを放置すれば、ボトルネックが移動するだけだ。そこで私たちはレイテンシをシステムの問題として扱い、私たちが制御できるあらゆるレイヤーに投資を行い、サポートする100以上のチェーン全体で99.99%の稼働率と平均50ms以下のレスポンスタイムを基準として維持している。 ## 私たちが構築したもの Alchemy Edge Proxy', tooltip: "", icon: "", }, benefit: { title: "Faster response at the tail, up to 7.5x", tooltip: "", icon: "", }, id: 0, }, { cause: { title: "Avoidable internal network travel", tooltip: "", icon: "", }, built: { title: 'Closer service placement within the cluster', tooltip: "", icon: "", }, benefit: { title: "Less time lost inside our infrastructure", tooltip: "", icon: "", }, id: 1, }, { cause: { title: "Inefficient routing", tooltip: "", icon: "" }, built: { title: 'Contextual smart routing', tooltip: "", icon: "", }, benefit: { title: "Shorter infrastructure paths, up to 2.5x faster queries", tooltip: "", icon: "", }, id: 2, }, { cause: { title: "Traffic spikes", tooltip: "", icon: "" }, built: { title: 'Predictive scaling', tooltip: "", icon: "", }, benefit: { title: "Capacity ready before the surge (Usual: 30K RPS)", tooltip: "", icon: "", }, id: 3, }, { cause: { title: "Predictable throughput under load", tooltip: "", icon: "" }, built: { title: 'Purpose-built, elastic throughput', tooltip: "", icon: "", }, benefit: { title: "Stable performance when volume climbs", tooltip: "", icon: "", }, id: 4, }, { cause: { title: "Chain and node operational lag", tooltip: "", icon: "", }, built: { title: 'AI-managed node fleet', tooltip: "", icon: "", }, benefit: { title: "Upgrades detected, tested, and rolled out with less delay", tooltip: "", icon: "", }, id: 5, }, { cause: { title: "Workload-specific bottlenecks", tooltip: "", icon: "", }, built: { title: 'Product-specific optimization', tooltip: "", icon: "", }, benefit: { title: "Full product flows (World: 44% faster to mine) and heavy queries (Solflare: up to 20x faster archive) stay fast", tooltip: "", icon: "", }, id: 6, }, { cause: { title: "Incomplete measurement", tooltip: "", icon: "" }, built: { title: 'Benchmark methodology', tooltip: "", icon: "", }, benefit: { title: "Latency measured with success rate and failed requests", tooltip: "", icon: "", }, id: 7, }, ], }} /> ## Alchemy Edge Proxyがリクエストパスのオーバーヘッドを削減する エッジとは正面玄関、つまりリクエストが最初に触れるAlchemy管理下のエントリポイントだ。呼び出しがどのノードに到達する前にも、接続の確立、TLSネゴシエーション、認証、ルーティングロジックを通過する。各ステップがミリ秒単位の時間を加算し、そのミリ秒はテール、つまりユーザーが実際に体感する最も遅いリクエストにおいて最も積み重なる。 Alchemy Edge Proxyは、このオーバーヘッドをリクエストパスから取り除くために構築したレイヤーだ。接続の再利用、認証、ルーティングの判断をスタックの奥深くではなく正面玄関で処理することで、すべてのリクエストが支払う固定コストを削減する。結果として、テールにおけるRPCが最大7.5倍高速化する。詳しくは[Alchemy Edge Proxy](/blog/alchemy-edge-proxy)を参照してほしい。 内部では、エッジは[Cortex](/cortex)の一部であるマイクロカーネル型のプロキシアーキテクチャ上で動作している。小さく安定したコアがクリティカルなリクエストパスを担い、認証、レート制限、ルーティングといったモジュールは独立して更新される。エッジは私たちがエンドツーエンドで制御するクリティカルなインフラレイヤーのひとつであるため、他社のネットワークの都合を待つことなく改善を続けられる。 ## インフラ内部：近接配置、賢いルーティング、安定したスループット リクエストがインフラの内部に入った後も、距離とハードウェアは依然として時間のコストになる。呼び出しを処理するサービス同士が離れた場所にあれば、実際の処理が始まる前に、それらの間を移動するだけでミリ秒単位の時間が費やされる。そして、トラフィック量が増えると、共有ハードウェアは不安定なレイテンシとして表れる類のばらつきを加える。 ここで力を発揮するのが、Alchemyのインテリジェントなブロックチェーンエンジンである[Cortex](/cortex)だ。Cortexは私たちの低レイテンシの数値を支える中核的なインフラ投資であり、そのうちいくつかの要素がここで特に重要になる。 - Kubernetesのアフィニティを用いたPodのコロケーションにより、互いに最も頻繁にやり取りするサービス同士を同一マシンに配置し、リクエストがラックをまたいで移動するのではなくローカルに留まるようにする。 - Istioのロケーション認識ルーティングは、内部トラフィックを最も近くにある利用可能なサービスインスタンスへ送り、それが実際に有効な場合にインフラ経路を短縮する。 - グローバルに展開された数千台のベアメタルサーバーが仮想化オーバーヘッドなしで専用ハードウェア上で直接動作し、高負荷下でもスループットが一貫して保たれる。 - Javaのバーチャルスレッドにより、1台のマシンが従来のスレッドのようなメモリおよびCPUのコストを払うことなく、はるかに多くの同時リクエストを処理できる。これが、レイテンシを悪化させることなく急増するトラフィックを吸収する仕組みだ。 これらが合わさることで、ユーザーが普段意識することはないが常に体感している移動時間を削減し、トラフィック量が増えてもパフォーマンスを安定させている。 ## 予測的スケーリングがスパイク前にキャパシティを準備する オンチェーンのトラフィックは穏やかには増えない。ローンチ、ミント、あるいは市場イベントによって負荷が数秒で何倍にも膨らむことがあり、スパイクの後に到着するキャパシティは、到着が遅すぎたキャパシティだ。 私たちの予測的スケーリングのロジックは、需要に反応するのではなく、需要に先立ってキャパシティを準備する。CPU、メモリ、ディスクI/O、トラフィックパターンといったシグナルを監視し、スパイクが到達する前にプロビジョニングを行う。Usualの事例がその証明だ。彼らはピーク時に毎秒30,000リクエストに達し、最初の1時間で3,800万リクエストを処理し、36時間で10億リクエストを超えたが、この急増の中でもレイテンシは崩れなかった。 > "Alchemy was able to give us a near perfect availability, serving massive amounts of requests per second (30k requests per seconds was our peak, and we still had buffer), without any hiccups or downtime. And all on short notice!" > > Adli Takkal-Bataille at [Usual](/case-studies/scaling-to-30000-requests-per-second) ## AI管理のフリート自動化がノード運用を常に最新に保つ ブロックチェーンは足元で常に変化し続けている。クライアントはアップデートをリリースし、ネットワークはハードフォークをスケジュールする。古いソフトウェアを動かしているノードは、遅い、あるいは誤った応答を返すノードだ。これを手作業で対応すれば、まさに精度が最も求められる場面で遅延とリスクが生じる。 私たちのノードフリートは、アップグレード、テスト、モニタリングを処理する完全自動化されたエージェント型システムによって管理されている。アップデートはリアルタイムで検知・適用され、パイプラインには自動テストが組み込まれているため、必須のネットワークアップグレードやハードフォークが見逃されることはない。私たちが運用するすべてのチェーンでこれを手作業で行い続けることは不可能だ。だからこそ私たちはこれを自動化し、一部のお気に入りのチェーンだけでなく100以上のチェーン全体で同じ低レイテンシの基準を維持している。この自動化は、Alchemyプラットフォームを支えるインテリジェントなブロックチェーンエンジンである[Cortex](/cortex)の一部であり、[RPC API](/rpc-api)、データAPI、ロールアップ、そのほかの開発者向けスタック全体を支えている。 ## プロダクト固有の最適化がユーザーフロー全体を改善する レイテンシは単一の呼び出しだけの問題ではない。実際のプロダクトは複数の呼び出しを連鎖させ、そのフローは最も遅いリンクの速さでしか進まない。ユーザーが実際に感じているのは全体の経路であり、単一のメソッドではない。 Tools for Humanityが構築し、World Chain上で稼働するWorldでは、マイニングにかかる時間が5.5秒から3.1秒へと44%短縮され、`alchemy_requestGasAndPaymasterAndData`におけるgas見積もりのレイテンシもおよそ380msから100msへと74%低下した。 > "When we were searching for infrastructure vendors, what mattered most was enterprise scale and support. Alchemy was hands down the clear leader across every product we needed-the only logical choice." > > Steven at [Tools For Humanity](/case-studies/world-onchain-performance) ## Solanaのアーカイブインフラが重いクエリのレイテンシを削減する 過去データやアーカイブへのクエリは、それ自体が難しい種類の処理だ。過去の状態を広範囲にわたって取得するのは重い処理であり、Solanaのようなハイスループットなチェーンでは、そのための専用インフラがなければ処理が遅々として進まなくなる。私たちは、Solanaプラットフォームの一部であるカスタムのマルチリージョンHBaseアーキテクチャの上に、Solana上で最速のアーカイブメソッドを構築した。 Solflareはまさにそのワークロードを実行し、アーカイブクエリが最大20倍高速化し、大規模な過去データへのクエリでもレスポンスタイムが200ms未満となり、ウォレットのバックフィルが1分未満で完了するようになった。 > "Alchemy's Archival RPC has kept up with Solflare's throughput while keeping a consistent <200ms response time." > > Dusan K. at [Solflare](/case-studies/solflare) ## ベンチマーク手法が速度と信頼性を同時に計測する すべてのリクエストに何が起きたかについて誠実でなければ、速度の数値には意味がない。失敗したリクエストや取りこぼされた呼び出しを隠す速い平均値は、速いのではなく、誤解を招くものだ。 私たちのベンチマーク手法は、レイテンシを成功率および失敗リクエスト数とあわせて計測し、その数値が実際のワークロードで体験される内容を反映するようにしている。これは私たち自身に課している基準であり、あなたにも同じ基準で私たちを評価してほしいと考えている。詳細は[ベンチマーク手法](/blog/how-we-benchmark-rpc-performance)全体を確認できる。 ## 目指すもの：意識されなくなるほど速いインフラ 最高のインフラとは、誰にも気づかれない類のものだ。レイテンシが十分に低く、信頼性が十分に高ければ、ウォレットはただ読み込まれ、スワップはただ確定し、バックフィルはただ完了する。このスタックのどのレイヤー単独でもレイテンシを解決することはできないが、すべてが合わさって、その体験を実現している。 数値は自分の目で確かめてほしい。[Alchemyのベンチマークページ](/benchmarks)でプロバイダーを比較し、[私たちがどのようにRPCパフォーマンスをベンチマークしているか](/blog/how-we-benchmark-rpc-performance)を正確に読んで、結果だけでなく手法そのものを判断してほしい。これをもとに構築する準備ができたら、[無料で始める](https://dashboard.alchemy.com/signup/)。 ## FAQ **RPCのレイテンシは何が原因で起きるのか？** RPCのレイテンシは、いくつかの独立した要因から生じる。エントリポイントにおけるリクエストパスのオーバーヘッド、内部サービス間の避けられるはずの通信、非効率なルーティング、トラフィックスパイク、チェーンおよびノードの運用上の遅れ、ワークロード固有のボトルネック、そして不完全な計測だ。これらの原因は互いに独立しているため、単一の対策ですべてを取り除くことはできない。 **1つの最適化でRPCのレイテンシを解決できるか？** できない。単一の原因を直しても、ボトルネックは次の箇所に移動するだけだ。レイテンシを確実に削減するには、エッジからノードインフラ、さらにパフォーマンスの計測方法に至るまで、リクエストパスのあらゆるレイヤーに投資する必要がある。 **RPCインフラにおけるエッジとは何か？** エッジとは、リクエストが到達する最初のプロバイダー管理下のエントリポイントであり、RPCトラフィックの正面玄関だ。接続の確立、認証、ルーティングをスタックの奥深くではなくそこで処理することで、すべてのリクエストが本来支払うはずの固定オーバーヘッドを取り除く。 **AlchemyはどのようにRPCのレイテンシを誠実に計測しているのか？** Alchemyは、レイテンシを単独の平均値としてではなく、成功率および失敗リクエスト数とあわせて計測している。これにより、見かけ上速く見える数値が取りこぼされたリクエストや失敗したリクエストを隠してしまうことを防ぎ、結果が実際の本番ワークロードで体験される内容を反映するようにしている。 **予測的スケーリングはトラフィックスパイクにどう対応するのか？** 予測的スケーリングは、スパイクが始まってから反応するのではなく、需要に先立ってキャパシティを準備する。これにより、Usualは急増中にレイテンシを悪化させることなく、毎秒30,000リクエストと36時間で10億リクエスト超を維持することができた。 **Solanaのアーカイブクエリのパフォーマンスが独立した問題であるのはなぜか？** アーカイブクエリは広範囲の過去の状態を取得するものであり、それ自体が重い処理だ。さらにSolanaの高いスループットによって、その範囲はさらに大きくなる。Solflareのアーカイブクエリが最大20倍高速化した事例が示すように、こうしたクエリを高速に保つのは、そのために作られた専用のアーカイブインフラだ。