コンテンツへスキップ
0%

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

著者: Uttam Singh

最終更新日: 2026年5月13日1分で読めます
Alchemy Edge Proxy: ブロックチェーンRPCを高速化するベアメタルのエッジ層

現在、年間数兆ドル規模の価値がブロックチェーンインフラを通じて動いている。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層の保護機能をすべて、ネットワークごとに調整可能な同等以上の層に置き換え、クリティカルなサービング経路からサードパーティ依存を完全に取り除く。

その結果、現在稼働中のブロックチェーンRPCイングレス層として最速のものが生まれた。

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が担当)、一方でルーティングロジックは柔軟に動的設定できる。

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

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

Alchemy Edge Proxyのリクエストライフサイクル: クライアントからGeo DNS、Istio Ingress Gateway、EPCPを経てIstioに戻り、宛先クラスタへ到達する流れ
  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自体が内部で処理する。

GeoベースのDNSルーティング図: ターゲットチェーンに関わらず、リクエストは最も近いAlchemy Edge Proxyのリージョンに解決される

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

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

動的な設定

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

yaml
Copied
regions: us-east: enabled: true routes: "/v2": verbs: ["POST"] destination: archive-cluster fallbackRegions: - us-west - eu-central - apac-southeast security: ipsBanned: ["..."] pathsBanned: ["..."]

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

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

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

Security layer
Previous (CDN)
Edge Proxy
OFAC / locality compliance
CDN WAF rules
Maxmind geolocation with application-level enforcement
DNS DDoS
CDN
DNS provider (standard protection)
Volumetric DDoS (UDP / ICMP floods)
CDN
Infrastructure provider with built-in anti-DDoS protection
Protocol DDoS (SYN floods, IP fragmentation)
CDN
Infrastructure provider for IP fragmentation; Envoy for SYN floods (connection limits, timeouts)
L7 DDoS (application-layer attacks)
CDN WAF
Envoy configuration with path allowlisting, IP-based rate limiting, max request time limits

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

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

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

レイテンシー

Metric
Before (CDN)
After (Edge Proxy)
Improvement
P99 (APAC)
150ms
20ms
7.5x faster
P50 (median)
~35ms
~5ms
7x faster
P95 (all networks)
~200ms
~100ms
~100ms reduction

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

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

信頼性

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

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

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

CDN-proxied
Direct connection
Custom edge proxy (Alchemy)
Latency
100+ms overhead at p95
Lowest possible
Matches direct connection
Traffic types supported
All (HTTP, WSS, frontend, backend)
RPC / WSS backend only
All (HTTP, WSS, frontend, backend)
DDoS protection
Built-in
None
Built-in (infrastructure provider + Envoy)
OFAC compliance
CDN WAF rules
Not compliant
Application-level enforcement
Customer migration required
No
Yes
No
Vendor dependency
CDN vendor
None
Own infrastructure
Cost scaling
Scales with traffic
Minimal
Fixed infrastructure cost

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

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

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

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

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

Alchemy Newsletter

リリース情報をいち早く受け取る

ニュースレターに登録する

Alchemyの最新のプロダクト情報とリソースをお届けします

A
O
D
+
80,000人以上が購読中

メールアドレスを入力すると、当社のマーケティング情報およびプロダクト最新情報の受信に同意したことになります。Alchemyが受け取った情報をプライバシー通知に従って取り扱うことに同意するものとします。購読はいつでも解除できます。