Node RPC vs. Dedicated Clusters: ワークロードに合ったインフラの選び方

ほとんどのオンチェーンワークロードは、マルチテナントインフラで問題なく動作します。しかし、チームの規模が大きくなるにつれ、次のような疑問が出てきます。専用ノードは必要か。特定のワークロードを分離すべきか。実際のトレードオフは何か。

このガイドでは、Alchemyの2つのインフラモデル—共有インフラソリューションであるNode RPCと、Dedicated Clusters—がそれぞれどのように動作するか、どちらが適しているか、そしてチームとしてどう判断すべきかを解説します。

Node RPC: ほとんどのワークロードにおけるデフォルト

Node RPCは、弾力性と運用のシンプルさを重視して最適化された、Alchemyの本番運用グレードのマルチテナントインフラです。これは共有フリート上のキー付きプライベートエンドポイントです。各層の比較はパブリック、プライベート、専用RPCエンドポイントを参照してください。Node RPCは、Robinhood、Stripe、Coinbase、Circle、Chainlink、Polymarketなどのチームで年間1兆ドル超のトランザクション量を支えているのと同じエンジン、Cortexによって動いています。

Node RPCでは、スケーリングはほぼ即時です。トラフィックの急増はノードフリート全体で自動的に吸収されます。フェイルオーバーは複数のリージョンにまたがって組み込まれています。料金は利用量ベースなので、コストはプロビジョニングした容量ではなく実際のトラフィックに応じて変動します。

各プロバイダーの現在の共有RPCパフォーマンスについては、AlchemyのRPCプロバイダーベンチマークを参照してください。

Dedicated Clusters: 無限のカスタマイズと完全なマネージド運用

Dedicated Clustersは、Alchemyがプロビジョニング・運用・保守を行いながら、要件に合わせて正確に構成された、専用のノードインフラを提供します。単一ノードの専用オファリングとは異なり、各クラスタはチェーンごとに冗長なノード群をプロビジョニングし、Node RPCと同じエンジンであるCortex上で動作します。シングルテナント環境でありながら、同じAPIと信頼性の保証を得られます。シングルテナントのクラスタがどのように動くかについては、専用ブロックチェーンインフラの仕組みを参照してください。

すべてのクラスタはダウンタイムゼロを前提に構築されています。リージョンごとにチェーンあたり2台以上のノードを配置することで、中断なしにローリングメンテナンスが可能です。ブロック単位で完全な整合性により、すべてのノードがチェーン状態について同じビューを返すため、古い読み取りや矛盾する読み取りによるエラーを排除します。また、リアルタイムのGrafanaダッシュボードにより、ノードの健全性、リクエストパターン、パフォーマンスを完全に可視化できます。

トラフィックの増加に応じて、クラスタも拡張していきます—自動化されたスナップショット・デプロイ機能により、業界で最も速く新しい容量を稼働させることができます。契約容量を超える予期しないスパイクについては、Alchemyの共有フリートへの自動フォールバックをオプトインで利用でき、リクエストの取りこぼしも手動対応も不要です。

すべてのクラスタは、要件に合わせて正確に構成されます。

• カスタムトレーサーとバイナリをノードに直接デプロイし、シミュレーション、トレーシング、インデックス作成をより高速かつコスト効率よく実行
• シングルテナント分離—SOC 2 Type II準拠で、他の顧客のトラフィック、コード、データが環境内に一切存在しない
• リージョンデプロイにより、自社スタック、チェーンインフラ、ユーザーとの低レイテンシーな近接性を実現
• カスタムハードウェア構成をトラフィックに合わせて調整し、最適なパフォーマンスを実現
• 月額固定料金—リクエストごとの課金なし、サプライズなし

Dedicated Clustersが適した選択となる場合

Node RPCは大多数のワークロードをうまく処理します。Dedicated Clustersは、マルチテナントインフラでは満たせない特定の要件を持つチーム向けに設計されています。ここでは4つの一般的なシナリオを紹介します。

カスタムトレーサーまたはバイナリ。 カスタムEVMトレーサー、クライアント、バイナリなど、標準外のノードソフトウェアに依存するワークロードには、ノードへのカスタムコードのプッシュ機能が必要です。Dedicated Clustersはこれをネイティブにサポートしており、インデックス作成やイベント処理でカスタムトレーサーに依存するセキュリティ・フォレンジックチームに適しています。

規制または社内の分離要件。 一部のコンプライアンスフレームワークや社内セキュリティポリシーでは、他の顧客のトラフィック、コード、データが環境に一切触れないことが求められます。Dedicated Clustersは、監査対応が可能な統制とSOC 2 Type II準拠によるシングルテナント分離を提供します—これは規制対象の金融機関にとって標準的な要件です。

リージョンデプロイ要件。 Node RPCはすでに幅広いリージョンで低レイテンシーのカバレッジを提供しています。しかし、その範囲外の特定の地域—自社スタック、シーケンサー、バリデーターとの併設—でのデプロイが必要な場合、Dedicated Clustersは必要な正確なリージョンにデプロイできます。これは、1ミリ秒が重要な取引会社、DeFiプロトコル、高頻度取引業務にとって特に重要です。

容量ベースの料金の方が効率的な大規模ワークロード。 非常にスループットの高いマルチチェーンワークロードでは、プロビジョニングした容量に基づく月額固定コストの方が、リクエストごとの課金よりも予測しやすい場合があります。

これらの要件がいずれも当てはまらない場合、Node RPCは追加のセットアップなしで、同等の最高水準のパフォーマンスと信頼性を提供します。

なぜノードを自社運用しないのか

私たちが関わってきた多くのチームは、自社でノードインフラを運用することを検討した、あるいは現在運用しています。その経験はよくある展開をたどる傾向があります。採用、ツール整備、モニタリングへの多大な投資に続き、クライアントのアップグレード、ネットワークの変更、対応するすべてのチェーンにわたるオンコール対応といった継続的な運用負荷が発生します。このトレードオフについての詳しい考察は、自社でノードを運用することの利点と欠点の概要をご覧ください。

このリスクは時間とともに積み重なっていきます。アップグレードを1回見逃すだけでノードが遅れを取り、リクエストが失敗し始め、顧客向けのトランザクションが壊れます—ユーザーは取引できなくなり、不満が募り、ダウンタイムの1分1分が収益と信頼の損失につながります。また、製品開発に集中できるはずのエンジニアリングリソースが、事業の差別化にならないインフラの保守に費やされることになります。

自社運用のノードとマネージドクラスターの比較

AlchemyのマネージドクラスターはDedicated Clustersです。両者の比較は次のとおりです。

これがDedicated Clustersが解決するために設計された問題です。Alchemyがデプロイ、アップグレード、モニタリング、インシデント対応をエンドツーエンドで担います。

ハイブリッドアプローチ

一部のワークロードでDedicated Clustersが必要なチームでも、通常はすべてのワークロードで必要とするわけではありません。最も一般的な本番構成はハイブリッドです。シングルテナント制御が必要なチェーンやワークロードにはDedicated Clustersを、それ以外にはNode RPCを使用します。

両者間の移行は簡単です。どちらも同じAlchemy APIを使用しているため、ワークロードをDedicatedにルーティングするのは、リクエストを別のエンドポイントURLに向けるだけです。コード変更や再アーキテクチャは不要です。

このアプローチにより、必要な部分ではシングルテナント制御を確保しつつ、残りのトラフィックについてはNode RPCの弾力性とコスト効率を維持できます。

比較

判断方法

判断は4つのトリガーに集約されます。次のいずれかが当てはまる場合、ワークロードを共有（Node RPC）からdedicatedへ移します。

• カスタムトレーサーまたはバイナリ: ワークロードが、デプロイする必要のある非標準のノードソフトウェアに依存している。
• 規制または分離の義務: コンプライアンスフレームワークまたは社内ポリシーがシングルテナントのコンピュートを要求している。
• Node RPCのカバー範囲外のリージョン: 共有インフラがカバーしない地理で、スタック、シーケンサー、またはバリデーターと同じ場所にノードが必要。
• 持続的な高ボリューム: 自社のスループットでは、リクエスト単位の課金より容量ベースの料金の方が効率的。

これらのいずれかに「はい」と答えるのであれば、Dedicated Clustersまたはハイブリッド構成を検討する価値があります。すべてに「いいえ」であれば、Node RPCが適しています。

いずれの場合も、その後の進め方は柔軟です。チームはNode RPCから始めて、既存のインフラを崩すことなく、後から特定のワークロードをDedicatedに移行できます。

よくある質問

Alchemy Node RPCとは何ですか?

Node RPCは、Cortexを基盤としたAlchemyのマルチテナントインフラです。弾力性と運用のシンプルさを重視して最適化されており、スケーリングはほぼ即時、フェイルオーバーは複数リージョンに組み込まれ、料金は利用量ベースです。

Alchemy Dedicated Clustersとは何ですか?

Dedicated Clustersは、Alchemyによって完全に管理されながらも、要件に合わせて正確に構成された専用のノードインフラを提供します。シングルテナント環境で動作し、カスタムトレーサー、リージョンデプロイ、カスタムハードウェア、月額固定料金をサポートします。

Node RPCとDedicated Clustersの主な違いは何ですか?

Node RPCは共有インフラで利用量ベースの料金体系であり、ほとんどのワークロード向けに構築されています。Dedicated Clustersは、特定のコンプライアンス、パフォーマンス、カスタマイズ制御が必要なチーム向けに、カスタム構成によるシングルテナント分離を提供します。

Node RPCよりDedicated Clustersを選ぶべきなのはどのような場合ですか?

カスタムトレーサーやバイナリが必要な場合、規制または社内の分離要件がある場合、特定のリージョンへのデプロイが必要な場合、あるいは容量ベースの料金の方が効率的な大規模ワークロードを運用している場合は、Dedicated Clustersが適しています。

Node RPCとDedicated Clustersを併用できますか?

はい。一般的な本番構成はハイブリッドです。シングルテナント制御が必要なワークロードにはDedicated Clustersを、それ以外にはNode RPCを使用します。移行はエンドポイントURLを変更するだけで完了し、コード変更は不要です。

Dedicated ClustersはNode RPCより保守が難しいですか?

いいえ。どちらもAlchemyによって完全に管理されています。デプロイ、アップグレード、モニタリング、インシデント対応はすべてエンドツーエンドで処理されます。お客様側での保守は一切不要です。

Node RPCとDedicated Clustersは同じAPIをサポートしていますか?

はい。どちらも同じAlchemy API上で動作するため、両者間でワークロードをルーティングする際にコード変更や再アーキテクチャは不要です。

自社でノードを運用すべきか、それともマネージドクラスターを使うべきか?

自社でノードを運用するということは、採用、ツール整備への多大な投資と、クライアントのアップグレード、ネットワークの変更、対応するすべてのチェーンにわたるオンコール対応といった継続的な運用負荷を意味します。本当に重要なコストはサーバーそのものではなく、エンジニアリングの時間と、その時間が奪う製品開発です。マネージドなDedicated Clusterは、デプロイ、アップグレード、モニタリング、インシデント対応を固定月額でAlchemyに移すため、チームはインフラの保守ではなく製品を出荷できます。詳しい内訳は上の比較を参照してください。

はじめに

主要なオンチェーンアプリケーションの70%以上がAlchemy上で稼働しています。インフラの選択肢を検討している方—プロバイダーの統合、自社運用からの移行、スケールに向けた計画のいずれであっても—営業チームにお問い合わせください。ワークロードに最適な構成をご提案します。