--- title: "エッジレイヤーがAlchemyのRPCを高速化する仕組み" description: "Alchemy Edge Proxyの内部:カスタムベアメタルのイングレスレイヤーが、100以上のネットワークでブロックチェーンRPCを最大7.5倍高速化する仕組み。顧客側の移行作業は不要。" --- # エッジレイヤーがAlchemyのRPCを高速化する仕組み 現在、年間数兆ドル規模の価値がブロックチェーンインフラを通じて動いている。Solana上のDeFiスワップ、Ethereum上のステーブルコイン送金、Polygon上の予測市場の決済——これらの取引はいずれも、複数のネットワーク層を経てノードに到達するRPC呼び出しに依存している。金融活動がオンチェーンで行われる場合、その経路上の1ミリ秒1ミリ秒がリスクにさらされる資金を意味する。 [100以上のブロックチェーンネットワーク](https://www.alchemy.com/rpc)にわたって数兆件のリクエストを処理するインフラプロバイダーにとって、ユーザーとデータセンターの間にある層こそが、パフォーマンスの勝敗を分ける場所だ。この層がエッジである。そして2025年後半、Alchemyはこれをゼロから作り直した。 ## オンチェーン金融にとってRPCレイテンシーがなぜ重要なのか ブロックチェーンのユーザーとアプリケーションは世界中に分散している。シンガポールのトレーディングボット、フランクフルトのウォレットアプリ、バージニアにあるDeFiプロトコルのバックエンド——これらはすべて、ブロックチェーンの状態を読み取り、トランザクションを送信するために[RPC呼び出し](https://www.alchemy.com/overviews/rpc-node)を行う。これらの呼び出しが速く解決するほど、体験は良くなる。 DeFiにおいて、レイテンシーは実行品質に直結する。`eth_call`が遅ければ、価格データは古くなる。トランザクション送信が遅れれば、約定は悪化し、取引は失敗しやすくなる。ウォレットアプリケーションにとっては、読み込み時間が100ミリ秒増えるごとに、ユーザーをオンチェーンに留めておく体験が損なわれる。 しかし、レイテンシーは方程式の半分に過ぎない。信頼性も同様に重要だ。RPCプロバイダーがすべてのトラフィックを単一のサードパーティCDNにルーティングしている場合、そのCDNが単一障害点となる。障害が発生すれば、すべてのネットワーク、すべての顧客、すべてのリクエストがそれに巻き込まれる。 ## Alchemy Edge Proxyとは何か Edge Proxyは、[AlchemyのRPCインフラ](https://www.alchemy.com/rpc-api)への玄関口だと考えてほしい。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層の保護機能をすべて、ネットワークごとに調整可能な同等以上の層に置き換え、クリティカルなサービング経路からサードパーティ依存を完全に取り除く。 その結果、現在稼働中のブロックチェーンRPCイングレス層として最速のものが生まれた。 ## Alchemy Edge Proxyはどのように動作するのか Edge Proxyのアーキテクチャは、複数のグローバルリージョン(US East、US West、EU Central、Southeast Asiaなど)にまたがる専用のベアメタルサーバー上で動作する2つのコアコンポーネントから成る。 ### Istio Ingress Gateway 最初のコンポーネントは、Envoyをデータプレーンとして動かす[Istio](https://istio.io/) Ingress Gatewayだ。これがTLS終端、コネクション管理、リクエストプロキシングを担う。Envoyは、Lyft、Google Cloud、AWS App Meshを高負荷下で支えているのと同じプロキシだ。非同期・ノンブロッキングなC++コア、HTTP/2マルチプレクシング、事前にウォームアップされたアップストリームコネクションプールにより、高スループット・低レイテンシーのイングレスに適している。 ### Edge Proxy Control Plane (EPCP) 2つ目のコンポーネントは、[ext_authzフィルタ](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter)として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レイテンシーベンチマーク](https://www.alchemy.com/benchmarks)を参照してほしい。 ### 信頼性 以前のCDN前段構成であればアップストリームのインシデントの影響を受けていたであろう同じ期間において、Alchemyのインフラは影響を受けることなく稼働し続けた。 ## これは他のインフラアプローチとどう比較されるか ブロックチェーンAPIインフラのイングレスを扱うアプローチには、一般的に3種類ある。 カスタムエッジプロキシは、直接接続が持つレイテンシー面の優位性と、CDNが持つ保護機能・トラフィックの柔軟性を組み合わせながら、どちらのベンダー依存やコストスケーリングも伴わない。 一部のRPCプロバイダーはCDNレスのエッジソリューションを提供してきたが、それらの展開では通常、顧客が廃止期限付きで新しいエンドポイントに移行することが求められた。Alchemy Edge Proxyは、顧客側のアクションを一切必要とせずに、同等かそれ以上のパフォーマンス向上を実現した。 ## 最速のブロックチェーンインフラの上に構築する AlchemyのEdge Proxyは、グローバルな金融活動の要求に応えるために構築されたプラットフォームの一部分にすぎない。テール部分で最大7.5倍高速なRPC、100以上のサポートネットワーク、複数大陸にまたがるマルチリージョン展開、そしてアクション不要のパフォーマンス向上——これらすべてが[AlchemyのRPCエンドポイント](https://www.alchemy.com/rpc-api)に標準で備わっている。 DeFiプロトコル、ウォレット、決済アプリケーション、あるいは金融機関向けのオンチェーンインフラを構築するにせよ、パフォーマンスと信頼性は前提条件だ。[サポートされているチェーンの全リスト](https://www.alchemy.com/rpc)を確認するか、[Alchemyの開発者ドキュメント](https://www.alchemy.com/docs)を読むか、あるいは[無料アカウントを作成](https://dashboard.alchemy.com/signup)して構築を始めてほしい。