エッジレイヤーがAlchemyのRPCを高速化する仕組み

Alchemyは、RPCトラフィックの前段にサードパーティCDNを置くのではなく、ベアメタル上で独自のエッジ層を運用している。地理的近接性に基づくDNSが各リクエストを最寄りのAlchemyリージョン(US East、US West、EU Central、Southeast Asia)に解決し、リージョンのヘルスチェックが、あなたの側で何もしなくても、トラフィックを次に近いリージョンへ自動的にフェイルオーバーさせる。2025年10月の展開後、APACのP99レイテンシーは150ミリ秒から20ミリ秒に低下した。

現在、年間数兆ドル規模の価値がブロックチェーンインフラを通じて動いている。Solana上のDeFiスワップ、Ethereum上のステーブルコイン送金、Polygon上の予測市場の決済——これらの取引はいずれも、複数のネットワーク層を経てノードに到達するRPC呼び出しに依存している。金融活動がオンチェーンで行われる場合、その経路上の1ミリ秒1ミリ秒がリスクにさらされる資金を意味する。

100以上のブロックチェーンネットワークにわたって数兆件のリクエストを処理するインフラプロバイダーにとって、ユーザーとデータセンターの間にある層こそが、パフォーマンスの勝敗を分ける場所だ。この層がエッジである。そして2025年後半、Alchemyはこれをゼロから作り直した。

オンチェーン金融にとってRPCレイテンシーがなぜ重要なのか

ブロックチェーンのユーザーとアプリケーションは世界中に分散している。シンガポールのトレーディングボット、フランクフルトのウォレットアプリ、バージニアにあるDeFiプロトコルのバックエンド——これらはすべて、ブロックチェーンの状態を読み取り、トランザクションを送信するためにRPC呼び出しを行う。これらの呼び出しが速く解決するほど、体験は良くなる。

DeFiにおいて、レイテンシーは実行品質に直結する。eth_callが遅ければ、価格データは古くなる。トランザクション送信が遅れれば、約定は悪化し、取引は失敗しやすくなる。ウォレットアプリケーションにとっては、読み込み時間が100ミリ秒増えるごとに、ユーザーをオンチェーンに留めておく体験が損なわれる。

しかし、レイテンシーは方程式の半分に過ぎない。信頼性も同様に重要だ。RPCプロバイダーがすべてのトラフィックを単一のサードパーティCDNにルーティングしている場合、そのCDNが単一障害点となる。障害が発生すれば、すべてのネットワーク、すべての顧客、すべてのリクエストがそれに巻き込まれる。

Alchemy Edge Proxyとは何か

Edge Proxyは、AlchemyのRPCインフラへの玄関口だと考えてほしい。Ethereumの状態を読み取る場合でも、Solanaのアカウントをクエリする場合でも、Base上でトランザクションを送信する場合でも、すべてのAPIリクエストは、背後のサービング基盤に到達する前にこのイングレス層を通過する。

Alchemyは長年、大手CDNをこの玄関口として使ってきた。CDNが業界で広く選ばれてきたのには理由がある。DDoS対策、地理的ルーティング、WAFルール、SSL終端が標準で組み込まれているからだ。ほとんどのウェブアプリケーションにとって、その組み合わせで十分だ。CDNはこの20年間、eコマースからストリーミングまであらゆるもののデフォルトのイングレス層であり続けており、その地位には相応の理由がある。

オンチェーン金融の要求はそれとは異なる。RPCトラフィックはバースト性が高く、レイテンシーに敏感で、地理的にグローバルで、通常のウェブトラフィックにはない形でセキュリティが重要になる。3つのチェーンを並行して状態読み取りするトレーディングボットは、CDNがマーケティングページを50都市でキャッシュできるかどうかなど気にしない。気にするのは、eth_callを発行してからレスポンスを受け取るまでの時間だ。残高を同期するウォレットは、SQLインジェクション対策のWAFルールを必要としない。必要なのは、できる限り近いエッジノードと、1桁ミリ秒で完了するTLSハンドシェイクだ。デリバティブ取引所でポジションを決済するプロトコルは、サードパーティCDNのインシデント対応時間を自社の稼働率の上限として受け入れることはできない。

こうした要求に応えるため、Alchemyはベアメタル上にカスタムのエッジプロキシを構築した。高スループット・低レイテンシーのブロックチェーンRPCトラフィック向けに、ゼロから設計された専用のイングレス層だ。これはAlchemyが管理する複数のグローバルリージョンのインフラ上で動作し、CDN層の保護機能をすべて、ネットワークごとに調整可能な同等以上の層に置き換え、クリティカルなサービング経路からサードパーティ依存を完全に取り除く。

2025年10月の展開では、100以上のネットワークで測定した結果、APACのP99レイテンシーは150ミリ秒から20ミリ秒に、中央値のレイテンシーは約35ミリ秒から約5ミリ秒に低下した。

Alchemy Edge Proxyはどのように動作するのか

Edge Proxyのアーキテクチャは、複数のグローバルリージョン(US East、US West、EU Central、Southeast Asiaなど)にまたがる専用のベアメタルサーバー上で動作する2つのコアコンポーネントから成る。

Istio Ingress Gateway

最初のコンポーネントは、Envoyをデータプレーンとして動かすIstio Ingress Gatewayだ。これがTLS終端、コネクション管理、リクエストプロキシングを担う。Envoyは、Lyft、Google Cloud、AWS App Meshを高負荷下で支えているのと同じプロキシだ。非同期・ノンブロッキングなC++コア、HTTP/2マルチプレクシング、事前にウォームアップされたアップストリームコネクションプールにより、高スループット・低レイテンシーのイングレスに適している。

Edge Proxy Control Plane (EPCP)

2つ目のコンポーネントは、ext_authzフィルタとしてEnvoyと並行して動くカスタムコントロールプレーンだ。受信するリクエストごとに、EPCPは以下を評価する。

• URL、ヘッダー、対象のブロックチェーンネットワークに基づき、リクエストをどこにルーティングするか
• そのリクエストに対してどのバックエンドクラスターが利用可能か(アーカイブノードクラスター、AWSでホストされているサービス、リージョン固有のエンドポイントなど)
• セキュリティやコンプライアンス上の理由でリクエストをブロックすべきか
• ローカルリージョンでどのネットワークが健全な状態か(ヘルスチェック経由)

その後、EPCPはEnvoyにリクエストの転送先を伝えるルーティングヘッダーを注入する。この設計により、ホットパスは高速に保たれ(プロキシングはEnvoyが担当)、一方でルーティングロジックは柔軟に動的設定できる。

リクエストのライフサイクル

典型的な成功リクエストがシステムを通過する流れは次の通りだ。

1. クライアントが*.g.alchemy.comにRPCリクエストを送信する。
2. 地理ベースのDNSが、リクエストを最寄りのEdge Proxyリージョンに解決する。
3. Istio Ingress Gatewayがリクエストを受け取り、ext_authz経由でEPCPに渡す。
4. EPCPがリクエストを検証し(OFACチェック、セキュリティルール)、送信先クラスターを決定して、ルーティングヘッダーを返す。
5. Istioがリクエストを適切なバックエンドに転送する。
6. レスポンスがクライアントに直接返される。

地理ベースDNSルーティング

Edge Proxyは地理的近接性に基づくDNS解決を使用している。これは、DNS層がチェーンやネットワークを問わず共通であることを意味する。Ethereum mainnetへのリクエストとSolana mainnetへのリクエストは、どちらも同じリージョンのEdge Proxyに解決される。ネットワークを意識したルーティングは、Edge Proxy自体が内部で処理する。

この設計にはいくつかの利点がある。

• DNS解決とTLSハンドシェイクは、最終的にどのブロックチェーンネットワークが必要かに関わらず、最も近いエッジロケーションで行われる。
• 新しいブロックチェーンネットワークを追加してもDNSの変更は一切不要になる。
• リージョンのヘルスチェックはEdge Proxyレベルで実行される。あるEdge Proxyリージョンが不健全になった場合、DNSは自動的に次に近いリージョンにフェイルオーバーする。

動的な設定

Edge Proxyは、社内の設定プラットフォームからルーティング設定を取得する。これにより、再デプロイなしでランタイム中に変更が可能になる。

リージョンのドレインが必要な場合、ネットワークの再ルーティングが必要な場合、新しいセキュリティルールの適用が必要な場合でも、設定の更新は稼働中のプロキシに手を加えることなく反映される。

CDNなしでセキュリティモデルはどう機能するのか

CDN依存をなくすということは、あらゆるセキュリティ保護をゼロから作り直すことを意味した。Edge ProxyはCDNの保護機能を、層状のアプローチで置き換えている。

重要な点は、これらの保護がCDNのものより弱いわけではないということだ。むしろより対象を絞ったものになっている。Alchemyはすべての層を管理下に置き、ネットワークごとにしきい値を調整でき、何か問題が起きた際にサードパーティのインシデント対応時間に依存することもない。

Alchemy Edge Proxyはどのような成果をもたらしたか

Edge Proxyは2025年10月の3週間にわたり、100以上のブロックチェーンネットワークに展開され、顧客側の移行作業は一切不要だった。成果は即座に現れた。

レイテンシー

顧客側のテレメトリでも、多様なワークロードにわたって同程度の改善が見られ、特にレイテンシーに敏感なワークロードほど大きな効果が見られた。

現時点での公開プロバイダーデータについては、チェーン、リージョン、一般的なメソッドごとのRPCレイテンシーベンチマークを参照してほしい。

信頼性

以前のCDN前段構成であればアップストリームのインシデントの影響を受けていたであろう同じ期間において、Alchemyのインフラは影響を受けることなく稼働し続けた。

これは他のインフラアプローチとどう比較されるか

ブロックチェーンAPIインフラのイングレスを扱うアプローチには、一般的に3種類ある。

カスタムエッジプロキシは、直接接続が持つレイテンシー面の優位性と、CDNが持つ保護機能・トラフィックの柔軟性を組み合わせながら、どちらのベンダー依存やコストスケーリングも伴わない。

一部のRPCプロバイダーはCDNレスのエッジソリューションを提供してきたが、それらの展開では通常、顧客が廃止期限付きで新しいエンドポイントに移行することが求められた。Alchemy Edge Proxyは、顧客側のアクションを一切必要とせずに、同等かそれ以上のパフォーマンス向上を実現した。

よくある質問

グローバルなエッジネットワークが最も優れているRPCプロバイダーはどこか

それはトラフィックの発生元によって異なるため、有用な比較はランキングではなく仕組みの比較だ。どのプロバイダーについても確認すべき点は4つある。イングレス層がプロバイダー自身のインフラか、借り物のサードパーティCDNか。いくつのリージョンをどこで運用しているか。リージョン間のフェイルオーバーが自動か、自分で設定するものか。そして、グローバルな数値ではなく、自分のリージョンから測定したレイテンシーがどうか。

Alchemyは、US East、US West、EU Central、Southeast Asiaにまたがる専用のベアメタルサーバー上でカスタムのエッジプロキシを運用しており、以前サービング経路にあったサードパーティCDNを置き換えている。この依存をなくしたことで、外部ベンダーのインシデント対応時間がAlchemy自身の稼働率の上限になることはない。リージョンごとの最新の測定値については、ライブRPCレイテンシーベンチマークを参照してほしい。

標準でマルチリージョンのRPCフェイルオーバーを提供しているプロバイダーはどこか

確認する価値があるのは「標準で」という部分だ。設定すればフェイルオーバーに対応するプロバイダーは多いが、それは最初から機能するフェイルオーバーとは別の製品だ。

Alchemyでは、フェイルオーバーは自動であり、セットアップは不要だ。リージョンのヘルスチェックはEdge Proxyレベルで実行され、あるリージョンが不健全になると、DNSがトラフィックを次に近いリージョンにフェイルオーバーさせる。各リージョンには明示的な順序付きのフォールバックリストがあるため、トラフィックは任意に解決されるのではなく、定められた経路をたどる。これはDNSとイングレスの層で行われるため、アプリケーション側で設定するものは何もなく、2025年10月にこの層が100以上のネットワークに展開された際にも移行作業は不要だった。

RPCにおける地理ベースのDNSルーティングはどのように機能するのか

Alchemyは地理的近接性に基づくDNS解決を使用している。*.g.alchemy.comへのリクエストは最寄りのエッジリージョンに解決され、DNS層は意図的にチェーンを問わない設計になっている。Ethereum mainnetへのリクエストとSolana mainnetへのリクエストは同じリージョンのエッジプロキシに解決され、ネットワークを意識したルーティングはそのプロキシが内部で処理する。

ここから2つの帰結が生まれる。DNS解決とTLSハンドシェイクは、リクエストが最終的にどのチェーンを必要とするかに関わらず最寄りのエッジロケーションで行われ、往復時間の削減の大部分はここから生まれる。そして、新しいブロックチェーンネットワークを追加してもDNSの変更は一切不要なため、ネットワークのカバレッジとルーティングは互いに独立してスケールする。

リージョンに障害が発生したとき、トラフィックはどうなるのか

リージョンのヘルスチェックはEdge Proxyレベルで継続的に実行されている。あるリージョンが不健全と判定されると、DNSはそのリージョンへの解決を止め、トラフィックを次に近いリージョンに送る。その際は任意に選ぶのではなく、リージョンごとに設定された順序付きのフォールバックリストに従う。

ルーティング設定はランタイムに社内の設定プラットフォームから取得されるため、プロキシを再デプロイしたり再起動したりすることなく、リージョンのドレイン、ネットワークの再ルーティング、セキュリティルールの適用を行える。アプリケーション側から見れば何も変わらない。同じエンドポイントが、別のリージョンから提供されながら動き続ける。

最速のブロックチェーンインフラの上に構築する

AlchemyのEdge Proxyは、グローバルな金融活動の要求に応えるために構築されたプラットフォームの一部分にすぎない。テール部分で最大7.5倍高速なRPC、100以上のサポートネットワーク、複数大陸にまたがるマルチリージョン展開、そしてアクション不要のパフォーマンス向上——これらすべてがAlchemyのRPCエンドポイントに標準で備わっている。

DeFiプロトコル、ウォレット、決済アプリケーション、あるいは金融機関向けのオンチェーンインフラを構築するにせよ、パフォーマンスと信頼性は前提条件だ。サポートされているチェーンの全リストを確認するか、Alchemyの開発者ドキュメントを読むか、あるいは無料アカウントを作成して構築を始めてほしい。