---
title: "専用ブロックチェーンインフラの仕組み"
description: "専用ブロックチェーンインフラは、RPCとインデックス処理のワークロードをシングルテナントクラスタ上で実行する。分離、リージョン、冗長性、フェイルオーバーの仕組みを解説する。"
---

# 専用ブロックチェーンインフラの仕組み

<ImageBlock
  src="https://media.alchemy.com/blog/dedicated-infra-blog-2026-06-11.png"
  alt="専用インフラの仕組みを示すタイトルカード"
  width={5760}
  height={2700}
  priority
/>

多くの本番ワークロードは共有のブロックチェーン[RPCインフラ](/rpc-api)で問題なく動作する。だが一部のワークロードはそうはいかない。シーケンサー(ロールアップのトランザクション順序付けサービス)への往復レイテンシが、注文が次のブロックに入るかどうかを左右するトレーディングデスク。共有プロバイダーではホストできないカスタムEVMトレーサーを実行するシミュレーションエンジンを持つセキュリティ企業。他社のワークロードと共有されるハードウェア上での稼働をコンプライアンスチームが承認しない規制対象のフィンテック企業。

こうしたワークロードに対する答えが[専用ブロックチェーンインフラ](/dedicated-clusters)だ。

Dedicatedは同じインフラを1テナントに限定して提供するものだ。RPCスタック、データサービス、APIはすべて同じだが、キャパシティ、ホスト、ランタイムは自社専用となる。BlockaidのようなチームはAlchemy Dedicated Clustersを利用し、顧客が求めるパフォーマンスと一貫性を保ちながら3120億ドル以上の資産を保護している。

この違いこそが、限られたワークロードに対してdedicatedが価格に見合う理由であり、それ以外すべてに対してsharedが適切なデフォルトである理由だ。問うべきなのはdedicatedがより優れているかどうかではなく、自分のワークロードがsharedインフラの想定範囲を超えてしまったかどうかである。

## 専用ブロックチェーンインフラとは何か

[専用ブロックチェーンインフラ](/dedicated-clusters)とは、シングルテナントのRPCおよびインデックスクラスタであり、ブロックチェーンノード群、ルーティングインフラ、データサービスを1つのワークロードのために確保されたハードウェア上で稼働させるものだ。APIサーフェスはデフォルトでshared infrastructureと同一なので、既存のインテグレーションはコード変更なしで移行できる。カスタマイズはこのサーフェスを置き換えるのではなく拡張する形をとる。カスタムトレーサーとバイナリ、選択可能なリージョン、リクエスト単位課金ではなくキャパシティベースの価格設定がその内容だ。

一般的なクラスタには以下が含まれる。

- チェーン用の[フルノード群](/overviews/what-is-an-ethereum-node)のプール。顧客のピークリクエストレートに合わせてサイジングされ、ノード再起動時にトラフィックが落ちないよう予備の1ノードを追加する、いわゆるN+1パターンを採用する。
- 過去の状態にアクセスするためのオプションのアーカイブノード。直近のブロックだけでなく、genesisからのフルステートを提供する。
- ノードプールの手前に置かれる[エッジプロキシ](/blog/alchemy-edge-proxy)とロードバランサー。すべてのリクエストを受け取り、どのノードに処理させるかを決めるルーティング層として機能する。
- 可観測性スタック。通常はノードの状態、リクエストレイテンシ、エラー率を可視化するGrafanaダッシュボード。
- クラスタが想定していないトラフィックスパイクに対して、shared infrastructureへフェイルオーバーする経路。

このインフラの形はshared providerが内部で運用しているものと同じである。違うのはリース(貸与)だ。dedicatedとは、キャパシティが1顧客に専有され、ランタイムをその顧客が自由に設定でき、データパスが他の誰のワークロードとも共有されないことを意味する。

## ワークロードが専用インフラを必要とするのはどんな時か

shared infrastructureの限界を超える4つのワークロードパターンがある。

### カスタムトレーサーとバイナリ

EVMトレーサーとは、トランザクション実行を計装する関数である。内部コールトレース、ストレージの読み取り、struct log、revertの理由を抽出する。`callTracer`や`prestateTracer`のような標準トレーサーはほとんどの分析用途をカバーする。セキュリティツール、シミュレーションエンジン、フォレンジックプラットフォームにはそれ以上が必要となる。自社の内部スキーマに合わせたカスタムJavaScriptトレーサーや、shared providerが決して公開しない実行状態を露出させる改造版の`geth`や`erigon`バイナリだ。

これらをshared host上で動かすことはホストにとってもテナントにとっても安全ではない。だからこそシミュレーションやセキュリティのベンダーはdedicated clustersを運用する。

### リージョンに縛られるレイテンシ

ほとんどのアプリケーショントラフィックにとって、数ホップ程度のネットワーク遅延は問題にならない。だが1秒あたり数十件のリクエストを発行し、その1件1件を重視するワークロードでは、クライアント、ノード、シーケンサー間の物理的な距離がトランザクションが間に合うかどうかを左右しうる。

高頻度取引、オラクルフィード、そしてトランザクションのブロックへの組み込まれ方から価値を抽出するボットであるMEVサーチャーは、こうしたわずかな差を巡って競い合う。dedicated clustersを使えば、顧客はノードプールをシーケンサーやコンシューマーと同じリージョンに配置できる。

### 規制上の分離要件

一部のコンプライアンスフレームワークはシングルテナントの計算資源を要求する。顧客データの分離に関するSOC 2 Type IIの統制、特定の銀行・証券業の規制、大手金融機関の内部リスクレビューは、しばしば同じ要件に行き着く。すなわち、他の顧客のワークロードと同一ホスト上で稼働してはならないというものだ。

shared infrastructureは設計上、多数の顧客を同一ホスト上で稼働させる。dedicated infrastructureはそうではない。

### 上限のないクエリ範囲

shared RPCプロバイダーはクエリ爆弾からクラスタを守るため`eth_getLogs`の範囲に上限を設けている。ユーザーの直近のトランザクションを読み取るウォレットにとっては問題ないし、だからこそほとんどの分析ワークロードは生の`eth_getLogs`ではなくインデックス化された[Data API](/docs/data)にルーティングされる。

だがエクスプローラー、インデクサー、チェーン分析チームのように生ログの膨大な過去範囲をスキャンする必要がある場合、この上限がボトルネックとなる。dedicated clustersではこの上限を撤廃できる。上限が存在するのは他のテナントを守るためであり、シングルテナントのクラスタには守るべき他のテナントが存在しないからだ。

判断の参考として:

<EmbeddedTable
  table={{
    columns: [
      {
        key: "need",
        width: 420,
        title: "ワークロードが必要としているもの",
        dataType: "object",
      },
      { key: "use", width: 180, title: "使うべきもの", dataType: "object" },
    ],
    data: [
      {
        id: 0,
        need: {
          title: "カスタムトレーサー、カスタムバイナリ、または改造クライアント",
          tooltip: "",
          icon: "",
        },
        use: { title: "Dedicated", tooltip: "", icon: "" },
      },
      {
        id: 1,
        need: {
          title: "特定リージョンのシーケンサーやユーザーへの低レイテンシ",
          tooltip: "",
          icon: "",
        },
        use: { title: "Dedicated", tooltip: "", icon: "" },
      },
      {
        id: 2,
        need: {
          title:
            "SOC 2、銀行業務、社内分離要件のためのシングルテナント計算資源",
          tooltip: "",
          icon: "",
        },
        use: { title: "Dedicated", tooltip: "", icon: "" },
      },
      {
        id: 3,
        need: {
          title: "1回の呼び出しで数千ブロックを超えるクエリ範囲",
          tooltip: "",
          icon: "",
        },
        use: { title: "Dedicated", tooltip: "", icon: "" },
      },
      {
        id: 4,
        need: { title: "それ以外", tooltip: "", icon: "" },
        use: { title: "Shared", tooltip: "", icon: "" },
      },
    ],
  }}
/>

ワークロードが4つのdedicatedパターンのいずれにも当てはまらない場合、shared infrastructureの方がほぼ常に安く、シンプルで、迅速に出荷できる。

## Dedicated clustersはどう動くのか

dedicated clusterのアーキテクチャは6つの選択に集約される。他に誰がその箱の上で動くか、その箱がどこにあるか、いくつあるか、ステートについてどう合意するか、どのソフトウェアを実行するか、そしてどう課金するかだ。

### シングルテナント分離

シングルテナントとは、顧客のノードがその顧客のワークロード専用に確保された計算資源上で稼働することを意味する。実務上、コンプライアンスレビューではワークロードの分離、アクセス制御、監査可能性、鍵の取り扱いに関する文書が求められることが多い。

この分離が実際にもたらすのは、除外されるリスクだ。shared host上のノイジーネイバーが顧客のテールレイテンシを悪化させることはない。なぜなら隣人がいないからだ。他のテナントからのサイドチャネルリークが顧客のプロセスに届くこともない。コンプライアンスレビュアーは「プロバイダーがワークロードを分離してくれると信頼している」ではなく、文書化された統制を提示できる。

### リージョン展開

クライアントからRPCノードまでのレイテンシはネットワーク上の距離に制約される。ほとんどのアプリケーショントラフィックにとってこれは問題にならない。だがレイテンシに敏感なリクエストを頻繁に発行するワークロードでは、ノードをスタック、ユーザー、シーケンサー、バリデータに近づけて配置することが、競争力のあるプロダクトと遅いプロダクトの分かれ目になりうる。

dedicated clustersでは顧客がリージョンを選択できる。よくあるパターンは主要なユーザー地域ごとに1つのクラスタを置くか、特定のロールアップのシーケンサーと同じ場所に1つのクラスタを配置するというものだ。トレードオフは運用面にある。リージョンが増えるほど監視、パッチ適用、費用負担が必要なクラスタも増える。ほとんどのワークロードは1つか2つで十分だ。

### N+1冗長性とフェイルオーバー

dedicated clusterは顧客の目標キャパシティに加えて予備ノードを1台余分に稼働させる。あるノードが劣化したり再起動したりしても、顧客が気づくことなくトラフィックは予備ノードへ移る。これがN+1パターンであり、単一ノードの障害があっても可用性を失わずに生き延びる必要のあるあらゆるサービスの標準的な形である。

より難しい問いは、負荷がクラスタを超えたときに何が起こるかだ。これを引き起こす実際のケースは2つある。1つはチェーンの混雑で、チェーンが忙しくなることでクラスタのリクエスト量が急増するケース。もう1つは、キャンペーンやイベント、あるいはインテグレーションのローンチによる顧客トラフィックの急増だ。定常負荷向けにサイジングされたクラスタは、大きなスパイクの下でレート制限がかかることがある。

アーキテクチャ上の答えは2つある。1つはクラスタをピークに合わせてサイジングすることで、この場合ほとんどの時間はアイドルキャパシティに対して費用を払うことになる。もう1つはshared infrastructureへの自動フェイルオーバーだ。クラスタが飽和すると、429を返す代わりにトラフィックがプロバイダーのshared fleetへあふれ出る。顧客は同じAPI、同じ認証、同じレスポンス形式のままだ。フェイルオーバーの方が効率的なパターンだが、dedicatedプロバイダーが一級品のshared infrastructureも運用している必要がある。

### ブロック単位での完全な一貫性

ロードバランスされたプール内の異なるノードは、最新ブロックについて数百ミリ秒のあいだ食い違うことがある。最速のノードはブロックNを見ているが、最遅のノードはまだN-1のままだ。残高を確認するウォレットにとってこれは問題にならない。だが同じブロックを異なるノード経由で2回読み取り、一貫性のないステートを得てしまうトレーディングボットにとっては、これは実際のバグとなる。

ブロック単位での完全な一貫性とは、クラスタがノードプール全体で一貫したチェーンステートのビューを返すことを意味し、ステートフルなクライアントが古い読み取りや矛盾した読み取りを見ることがないようにするものだ。トレードオフは、クラスタが速度だけでなく正確性のためにも最適化される点にある。これは、ワークロードが最新のチェーンステートから意思決定を行う場合にもっとも重要になる。

### カスタムトレーサーとバイナリ

dedicated runtimeを使えば、顧客はカスタムJavaScriptトレーサーを実行したり、パッチ済みの`geth`ビルドをデプロイしたり、クライアントを差し替えたり、shared providerがグローバルに固定しているクライアント設定を変更したりできる。shared providerがこのサーフェスを公開できないのは、クライアントのバージョンや設定を変更するとホスト上のすべてのテナントに影響が及ぶためだ。

これはシミュレーション、フォレンジック、分析プロダクトが依拠している能力である。これらのプロダクトの価値は、標準的なトレーサーインターフェースが公開しない実行状態を抽出することから生まれる。dedicated runtimeなしでは、そのプロダクト自体が成立しない。

### キャパシティベースの価格設定

shared infrastructureはリクエスト単位で課金され、通常は呼び出しごとのcompute unitとして計算され、より重い処理には倍率がかかる。dedicated infrastructureはクラスタ単位で課金され、確保されたキャパシティに対して固定の月額料金がかかり、顧客がそれに対してどれだけリクエストを送るかとは無関係だ。

このモデルは、予測可能なピーク負荷を持ち、そうでなければ大規模にshared compute unitを消費してしまうワークロードに適している。dedicated clusterでは、追加リクエストの限界費用は、ワークロードがクラスタの上限に達するまでゼロだ。ワークロード固有の閾値を超えると、dedicatedがもたらす他の能力を考慮する前の時点でも、キャパシティベースの価格設定はリクエスト単位課金より安くなりうる。

## Sharedが適切なデフォルトとなるのはどんな時か

sharedとdedicatedのどちらを選ぶかを決める際に重要なのは3点だ。トレードオフについてより詳しい解説は、[Node RPCとDedicated Clustersの選び方](/overviews/dedicated-vs-shared-nodes)の概要を参照してほしい。

### Dedicatedそれ自体はRPCスタックを本質的に速くするわけではない

下層のRPCスタックは同じなので、静かなシステム上での単発リクエストのベンチマークだけでは全体像はわからない。dedicatedがレイテンシを改善するのは、クラスタがワークロードに近い場所に配置されている場合であり、また持続的な負荷の下でP99(もっとも遅い1%のリクエスト)を分離によって保護できる場合には予測可能性が向上する。

各プロバイダーにおけるshared RPCパフォーマンスの現時点での公開データについては、Alchemyの[RPC provider benchmarks](https://www.alchemy.com/benchmarks)を参照してほしい。

### マルチリージョンのsharedはシングルリージョンのdedicatedより生き残りやすいことがある

シングルリージョンのクラスタをダウンさせるリージョナルなクラウド障害は、[グローバルに分散されたshared fleet](/blog/best-uptime-biggest-liquidation-event-in-crypto)ではほとんど問題にならない。現実的なデプロイでは、主要リージョンにdedicatedを配置しつつ、グローバルなデフォルトとしてsharedを組み合わせる。

### 4パターンのテストは厳格である

ワークロードがカスタムランタイム、リージョン要件、規制上の分離、クエリ範囲上限のいずれにも当てはまらない場合、sharedの方が安く、シンプルで、たいてい信頼性も高い。dedicatedへの移行は通常、好みではなく必要に迫られてのものだ。

## Alchemyはどのように専用ブロックチェーンインフラをサポートしているのか

ほとんどのワークロードはsharedから始まり、そのままsharedにとどまる。当社の[RPC API](/rpc-api)と[Data API](/docs/data)は、dedicatedを支えているのと同じCortexプラットフォーム上で稼働しており、無料枠があり、契約も最低利用料も不要だ。[dashboard](https://dashboard.alchemy.com)からAPIキーを取得すれば、数分でリクエストの送信を開始できる。

ワークロードがカスタムトレーサー、リージョン要件、規制上の分離、クエリ範囲上限という4つのパターンのいずれかに該当した場合、[Alchemy Dedicated Clusters](/dedicated-clusters)が同じインフラ上でシングルテナントのキャパシティを提供する。当社はカスタムトレーサーとバイナリ、リージョン展開、sharedへの自動フェイルオーバーを備えたN+1冗長性、ブロック単位での完全な一貫性、初日から使えるGrafanaダッシュボード、そして規制対象環境向けのSOC 2 Type II準拠インフラをサポートしている。価格設定はリクエスト単位の利用量ではなく、プロビジョニングされたキャパシティに基づくため、予測可能な負荷を持つチームは固定の月額インフラ費用をもとに計画を立てられる。

Dedicated clustersは同じインフラを、あなたのワークロードに合わせて限定したものにすぎない。sharedで十分なら、sharedを使い続ければよい。もしあなたのワークロードがそれではまかなえない少数の例に当てはまるなら、[当社のチームに相談してほしい](/dedicated-clusters)。

## FAQ

### 専用ブロックチェーンインフラとshared RPCの違いは何か

shared RPCは管理されたfleetで多数の顧客を稼働させる。専用ブロックチェーンインフラはランタイム、キャパシティ、データパスを1つのワークロードのために確保する。APIサーフェスは同一のままにできるが、dedicatedにはシングルテナント分離、カスタムランタイムのオプション、リージョン配置、キャパシティベースの価格設定が加わる。

### 専用インフラはプライベートRPCエンドポイントと同じものか

必ずしもそうではない。プライベートRPCエンドポイントとは、shared infrastructure上での顧客固有のURLやアクセスポリシーを指すことがある。dedicated infrastructureはさらに踏み込んでおり、ノードプールとそれを支えるランタイムが1顧客のワークピケント専用に確保される。

### チームが専用インフラを避けるべきなのはどんな時か

ワークロードがカスタムバイナリ、規制上の分離、リージョン固有の配置、あるいは異常に大きな生クエリ範囲を必要としない場合はdedicated infrastructureを避けるべきだ。そうした場合、shared RPCの方がたいていシンプルで、安く、弾力性があり、迅速に出荷できる。

### DedicatedとSharedのインフラを併用できるか

できる。Dedicated Clustersを使うほとんどのチームはハイブリッド構成で運用している。厳格な要件があるチェーンやワークロードにはdedicatedを、それ以外にはshared RPCを使う。APIが一致しているため、ワークロードを両者の間で移動させることは主にエンドポイントとルーティングの選択の問題にすぎない。

### Dedicated clustersの価格設定はどうなっているか

Dedicated clustersはリクエスト単位の利用量ではなく、プロビジョニングされたキャパシティに基づいて価格設定される。価格はチェーン、ノードタイプ、スループット、リージョン、含まれる機能によって決まる。持続的に高い負荷のあるワークロードでは、固定キャパシティ課金の方がリクエスト単位課金より予測しやすいことがある。

### Dedicated clusterはどれくらい早くプロビジョニングできるか

プロビジョニングにかかる時間はチェーン、クライアント、リージョン、構成によって異なる。要件が標準的な場合、一部のクラスタは迅速にデプロイできる。カスタムバイナリ、特殊なハードウェア、新しいリージョンといったより複雑な構成には、より多くの計画が必要となる。