---
title: "セルフホストノードから専用インフラへの移行方法"
description: "セルフホストノードから専用インフラへの移行は、再構築ではなくエンドポイントの置き換えです。移行する理由、得られるメリット、その仕組みを解説します。"
---

# セルフホストノードから専用インフラへの移行方法

<ImageBlock
  src="https://media.alchemy.com/blog/migrate-self-hosted-nodes-dedicated-infrastructure.png"
  alt="セルフホスト型ノードから専用インフラへ移行"
  width={1920}
  height={900}
  priority
/>

社内でブロックチェーンノードを運用すると、作業量は増える一方です。対応するチェーンが増えるたびに、追跡すべきアップグレード、拡張が必要なストレージ、検知すべき同期問題が増えていきますが、その作業を行うエンジニアは本来プロダクト開発に携わるべき人材です。ある時点で、メンテナンスにかかるエンジニアリング時間が、得られる見返りを上回ります。マネージドな[dedicated infrastructure](https://www.alchemy.com/dedicated-clusters)は、制御を犠牲にすることなくこの状況を脱する方法です。現在セルフホストで実現しているのと同じカスタマイズ性、分離性、リージョン配置を備えたシングルテナントのクラスタを、こちらで運用します。

移行自体は、多くのチームが予想するよりも単純です。Dedicated Clusterはアプリケーションがすでに呼び出しているのと同じAPIで動作するため、移行は本質的にエンドポイントの切り替えであり、作り直しではありません。本ガイドでは、チームがセルフホスティングから離れる理由、移行後も維持できるもの、実際の切り替え方法、そしてそもそもこの移行が自分たちにとって適切な選択かどうかの見極め方を説明します。

## チームがセルフホストノードから移行する理由

自分のノードを運用していて起こる問題は、大きな1つの失敗であることは稀です。小さな失敗が着実に積み重なっていき、それぞれがあなたよりも先にユーザーに届く傾向があります。移行の大半を引き起こす要因は、次の3つです。

1つ目は、チェーンの最新ブロックに追いつけなくなることです。同期が遅れたセルフホストノードは、古いデータのままリクエストへの応答を続けます。ユーザーには数分前の残高が表示され、すでに確定しているはずの取引が表示されず、理由の分からないルックアップの失敗に遭遇します。サポートチケットが発生し、それとともに、時折予測不能に誤動作するアプリに対する信頼が静かに失われていきます。これはセルフホスティングで最もよく起こる障害であり、内部からは最も検知しにくいものです。ノードは誤った応答を返している間も、見かけ上は正常に稼働しているからです。

2つ目は、運用するすべてのチェーンでクライアントのアップグレードに追随することです。各ネットワークは独自のアップグレード周期を設定し、独自のチャネルで告知します。GitHubで告知するところもあれば、ドキュメント、Discord、Telegram、あるいは非公開のパートナー向けSlackで告知するところもあり、統一された確認先はありません。最新の状態を維持するには、数十もの独立したエコシステムを監視する必要があり、マルチチェーン構成全体では週に数十件のアップグレードに相当します。1つでも見逃すと、単なる体験の劣化では済まず、ダウンタイムになります。ノードが遅れ、リクエストが失敗し始め、顧客の取引が壊れます。[Ethereum's Fusaka upgrade](https://www.alchemy.com/blog/ethereum-fusaka-upgrade-dev-guide-to-12-eips)は2025年末の約5週間で3つの変更を投入しましたが、それは1つのチェーンだけの話です。これをアプリケーションが対応するすべてのチェーンにわたって掛け合わせると、インフラを健全に保つことは「ノードを動かす」ことではなく、フルタイムの仕事になります。

3つ目は、増え続けるストレージです。Ethereumのアーカイブノードはすでに[multiple terabytes of fast NVMe storage](https://reth.rs/run/system-requirements)を必要としており、その容量は時間とともに増え続けるだけです。キャパシティプランニングは一度きりのセットアップではなく、継続的な運用責任であり、ストレージが不足するとノードは同期も最新のチェーンデータの提供もできなくなります。

以下は、それぞれの問題がどのくらいの頻度で発生するか、そしてマネージド化によって何が変わるかを一目でまとめたものです。

<EmbeddedTable
  table={{
    columns: [
      {
        key: "1",
        width: 200,
        title: "What slips on self-hosted",
        dataType: "object",
      },
      { key: "2", width: 190, title: "How often", dataType: "object" },
      { key: "3", width: 250, title: "What it costs you", dataType: "object" },
      {
        key: "4",
        width: 250,
        title: "How Dedicated Clusters prevents it",
        dataType: "object",
      },
    ],
    data: [
      {
        "1": {
          title: "<p>Nodes fall behind the chain tip</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>The most common self-host failure</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Users see stale balances and missing transactions; support tickets climb and trust erodes</p>",
          tooltip: "",
          icon: "",
        },
        "4": {
          title:
            "<p>Redundant nodes, routing that sends traffic to healthy nodes, and a consistency manager keep every read block-perfect and prevent stale reads</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": {
          title: "<p>A mandatory client upgrade gets missed</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Dozens of upgrades across chains every week</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Downtime: the node falls behind and requests start failing</p>",
          tooltip: "",
          icon: "",
        },
        "4": {
          title:
            "<p>We run and upgrade the clients, so the upgrade calendar is never your problem</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        "1": {
          title: "<p>Archive storage outgrows the disk</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Grows continuously unless monitored</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>A full disk crashes the node and takes the app down</p>",
          tooltip: "",
          icon: "",
        },
        "4": {
          title: "<p>We provision and scale the hardware for you</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": {
          title: "<p>Peers drop, memory leaks, CPU spikes</p>",
          tooltip: "",
          icon: "",
        },
        "2": {
          title: "<p>Intermittent, and always at the wrong hour</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title:
            "<p>Latency spikes and flaky errors degrade UX, and someone is permanently on call</p>",
          tooltip: "",
          icon: "",
        },
        "4": {
          title:
            "<p>Fully managed and monitored, sized to your workload, automatic failover to shared infrastructure</p>",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

## 維持できるものと、引き渡すもの

チームがセルフホストを選ぶのには正当な理由があり、マネージドクラスタへの移行は、それらを維持できて初めて意味を持ちます。実際に維持できます。

- **カスタムトレーサーとバイナリ。** セキュリティやフォレンジックのチーム、カスタムシミュレーションやインデックス作成を行う人たちと同様に、独自のロジックをノード上で直接実行できます。
- **カスタムハードウェア。** クラスタはあなたのワークロードに合わせてサイズと構成が決まります。
- **シングルテナントの分離。** SOC 2 Type II準拠のインフラで、環境が完全に分離されています。これは規制対象や金融系のチームの多くが、そもそも自前のノード運用に踏み切る要因となる要件です。
- **リージョン配置。** クラスタは[deploy close to your stack and your users](https://www.alchemy.com/blog/alchemy-edge-proxy)、これはレイテンシに敏感な取引やリアルタイムのワークロードにとって重要な違いとなります。

引き渡すのはオペレーション部分です。冗長性、すべてのノードにわたるブロック単位での完全な一貫性、クライアントのアップグレード、ハードウェアのスケーリング、モニタリング。これらすべてがマネージドで提供され、リアルタイムのGrafanaダッシュボードによって、自分では何も運用しなくてもすべてを可視化できます。これが取引の全体像です。セルフホストで得ていた制御を、その運用負担なしに手に入れられるのです。

## 移行はどのように進むのか

Dedicated Clusterは[same APIs as our shared Node RPC](https://www.alchemy.com/rpc-api)を公開しているため、移行のほとんどは設定変更であり、コードの書き換えではありません。アプリケーションをクラスタのエンドポイントに向けるだけで、すでに使っているリクエストパターンはそのまま動作し続けます。SDKの入れ替えもリクエスト形式の書き直しも必要ありません。

まずはサイジングから始まります。トラフィックの数値を共有していただければ、推測ではなく実際のピークに合わせてクラスタをプロビジョニングします。ノードの運用はこちらで行うため、キャパシティプランニングは初日からあなたの仕事ではなくなります。

その後、多くのチームは新しいクラスタを既存のノードと並行して短期間運用し、両者を比較したうえで、納得できた時点でトラフィックを移行します。自分たちのノードは、停止を決めるまでフォールバックとして稼働し続け、さらにこちらの共有フリートへの自動フェイルオーバーがプロセス全体を下支えするため、切り替えの瞬間に何かが左右されることはありません。実際には、多くのチームが覚悟していたような数週間分のフルタイムの作業ではなく、数日程度の期間で完了します。

移行後は、ハードウェアを解放し、オンコール当番を廃止し、クライアントのアップグレードを追う必要もなくなります。独立したリファレンスとして1台だけノードを残すチームもありますが、多くはその必要すらないと気づきます。[how dedicated blockchain infrastructure works](https://www.alchemy.com/blog/how-dedicated-blockchain-infrastructure-works)について詳しく解説したこちらの記事もご覧ください。

## Dedicated infrastructureは自分たちに適しているか

Dedicatedは誰もが目指すべきアップグレードではありません。ワークロードがマネージドな共有プランで問題なく動いているなら、そちらの方が適しています。伸縮性があり、使った分だけ支払い、プロビジョニング済みの容量にコミットすることなくスケーリングは相手任せにできます。Dedicatedから恩恵を受けるのは、具体的で持続的な理由を持つチームです。カスタム実行、シングルテナントの分離、他では手が届かないリージョン、あるいはプロビジョニング済み容量の方が経済的になるほどの継続的なボリュームです。

自分がどちらに当てはまるか分からない場合は、[choosing between Node RPC and Dedicated Clusters](https://www.alchemy.com/overviews/dedicated-vs-shared-nodes)についてのガイドが率直に判断の道筋を示します。目指すべきは最大のインフラではなく、正しいインフラです。

## セルフホストノードからの移行を始める準備はできましたか

[Dedicated Clusters](https://www.alchemy.com/dedicated-clusters)は、オペレーションの負担なしにシングルテナントの制御を提供します。カスタムトレーサー、バイナリ、ハードウェア、ブロック単位での完全な一貫性、そして[99.99% uptime through the largest liquidation event in crypto](https://www.alchemy.com/blog/best-uptime-biggest-liquidation-event-in-crypto)を実現した同じ共有フリートへの自動フェイルオーバーです。詳しくは[Dedicated Clusters launch announcement](https://www.alchemy.com/blog/introducing-dedicated-clusters)をご覧ください。

[Talk to our Dedicated Clusters team](https://www.alchemy.com/dedicated-clusters)にワークロードをお伝えいただくか、現在の構成のトラフィック数値をお持ちください。こちらでクラスタのサイジングを行います。すでに構築済みのAPIはそのまま使え、ノードの運用はこちらが担い、共有インフラへのフェイルオーバーは初日から用意されています。