ターミナル、コード、またはAIエージェントからQuicknodeを管理できます。 CLI、Admin API、MCP、SDKが利用可能になりました。
作成を開始する フェイルオーバーとは：シームレスなRPCおよびノードの切り替え | Quicknode
当社のニュースレターには、無料のリソース、Quicknodeの最新情報、Web3に関するインサイトなどが満載です。
83以上のブロックチェーンに対応したCLI、Admin API、MCP、SDK、およびAIネイティブツール。開発者によって、開発者のために構築されました。
Python、Ruby、JavaScriptにわたる最新のコード例。スマートコントラクト、NFT、dAppに関する詳細なガイド。
SOC 2 タイプ II 認証取得 · ISO 27001
回答 > 信頼性と稼働時間について > フェイルオーバーとは？ // Tags
フェイルオーバー 自動フェイルオーバー
要約：フェイルオーバーとは、 サービスを中断させることなく、障害が発生したコンポーネントから正常なバックアップへ自動的に切り替えるプロセスです。 ブロックチェーンインフラにおいて、フェイルオーバーにより、ノード、サーバー、またはデータセンターがダウンした場合でも、アプリケーションのRPCリクエストが別の正常なエンドポイントへシームレスにリダイレクトされることが保証されます。
基本概念 高速道路を走行中に、メインの車線が突然通行止めになったと想像してみてください。迂回路がなければ、その場から動けなくなってしまいます。しかし、ドライバーが気づかないうちに、高速道路システムが自動的に並行する車線へ迂回させてくれるなら、それこそがフェイルオーバーの実例です。
インフラストラクチャの観点から言えば、フェイルオーバーとは、何らかの障害が発生したことを検知し、直ちにトラフィックをバックアップに切り替える仕組みのことです。その目的は、中断をゼロ（あるいはほぼゼロ）にすることです。リクエストを処理しているコンポーネントが裏側で切り替わったとしても、アプリケーションは引き続きリクエストを送信し、レスポンスを受け取り、通常通り動作し続けます。
ブロックチェーンインフラにおけるフェイルオーバーの仕組み ブロックチェーンのインフラストラクチャには、障害が発生する可能性のある特定のコンポーネントがあります。最も一般的なのは、個々のノード、地域やデータセンター全体、そして特定のブロックチェーンクライアントの実装です。優れたフェイルオーバーシステムは、これら3つすべてに対応しています。
ノードレベルでは、フェイルオーバーは比較的単純です。ロードバランサーは、プール内のすべてのノードの健全性を継続的に監視し、応答時間、エラー率、ブロックの高さをチェックします。あるノードがエラーを返すようになったり、同期に遅れが生じたりした場合、ロードバランサーはそのノードへのトラフィックの送信を停止し、残りの正常なノードにリクエストを分散させます。
リージョンレベルになると、事態はさらに興味深いものになります。データセンター全体やクラウドの可用性ゾーンで障害が発生した場合、DNS ベースのフェイルオーバーが作動します。通常はそのリージョンにルーティングされるリクエストは、自動的に次に近い正常なリージョンにリダイレクトされます。これが、地理的な分散が重要である理由です。1つのリージョンでのみノードを運用しているプロバイダーは、そのリージョンがダウンした場合、代替手段がありません。
クライアントレベルでは、一部のプロバイダーが複数のブロックチェーン・クライアント実装（例えば、イーサリアムの場合、GethとErigonの両方）を運用しています。あるクライアント実装にバグやパフォーマンス上の問題が発生した場合、トラフィックは代替クライアントを実行しているノードへと移行することができます。この種の冗長性はそれほど一般的ではありませんが、その重要性はますます高まっています。
アクティブ・フェイルオーバーとパッシブ・フェイルオーバー フェイルオーバーには大きく分けて2つのアプローチがあり、この違いはパフォーマンスに重要な影響を及ぼします。
アクティブ・アクティブ構成では、すべてのバックアップコンポーネントがすでに稼働しており、トラフィックを処理しています。いずれかが障害を起こしても、他のコンポーネントがその分担していた負荷を単に引き継ぐだけです。すべてがすでに稼働状態にあるため、「コールドスタート」による遅延は発生しません。ノードはチェーンとの同期を維持する必要があるため、これはブロックチェーンインフラストラクチャにおいて推奨されるモデルです。ブロックの処理を積極的に行っていないノードは、ブロック高で遅れをとってしまい、追いつくまでは機能しなくなります。
アクティブ・パッシブ構成では、バックアップコンポーネントは必要な時まで待機状態にあります。プライマリが障害を起こすと、パッシブなバックアップが起動して処理を引き継ぎます。この方式は運用コストが安くなりますが、遅延が生じます。ブロックチェーンノードの場合、パッシブノードは正確なデータを提供する前にブロックの同期を行う必要があるため、この遅延は大きな問題となる可能性があります。
まさにこの理由から、実稼働中のブロックチェーンインフラのほとんどは「アクティブ・アクティブ・フェイルオーバー」を採用しています。DeFiプロトコルが1秒未満のデータ精度を必要とする場合、コールドノードが追いつくのを待っている余裕などないからです。
以下の表は、ブロックチェーンのワークロードにおける2つのフェイルオーバーモデルの比較をまとめたものです：
アスペクト
アクティブ-アクティブ
能動・受動
バックアップ状態
すべてのノードが稼働しており、トラフィックを処理している
スタンバイノードは、必要になるまでアイドル状態のままです
フェイルオーバーの遅延
ゼロ付近、コールドスタートなし
注目すべき点として、バックアップはウォームアップと同期を行う必要があります
運営コスト
より高いプランでは、フル容量分の料金を支払うことになります
低消費電力モードでは、リソースの使用量が少なくなります
ブロック高さの同期
常に最新の状態
遅れが生じ、追いつく必要がある場合があります
こんな方に最適
本番環境のRPCおよびリアルタイムデータ
コスト重視または重要度の低いワークロード
ブロックチェーンアプリにおいてフェイルオーバーが不可欠な理由 従来のウェブアプリケーションは、多くの場合、一時的な中断に耐えることができます。ユーザーがページを更新すれば、すべてが再び正常に動作するからです。しかし、ブロックチェーンアプリケーションには、いくつかの理由からそのような余裕がありません。
トランザクションは時間依存性があります。アプリケーションがトランザクションを送信中にRPCエンドポイントでリクエストが失敗した場合、そのトランザクションが失われたり、2回送信されたりする可能性があります。古いデータは危険です。 ブロック高が最新の状態に追いついていないノードは、古い情報を返します。アプリケーションが古い残高を読み取り、それに基づいて処理を行った場合、金銭的な損失につながる可能性があります。イベントは取り消せません。再試行やロールバックが可能な従来のシステムとは異なり、オンチェーンでの操作は不可逆的です。障害が発生したノードからの誤ったデータに基づいて資金を送金した場合、その操作を元に戻すことはできません。
だからこそ、フェイルオーバーは「あれば便利」な機能というわけではありません。本番環境でブロックチェーンと連携するあらゆるアプリケーションにとって、これは不可欠な要件なのです。
Quicknodeによるフェイルオーバーの処理方法 Quicknodeのインフラストラクチャは、14以上のリージョンおよび複数のクラウドプロバイダーにまたがるアクティブ・アクティブ・フェイルオーバーを採用しています。すべてのリクエストは、ブロックの高さの同期状況、応答遅延、エラー率など、ノードの健全性を継続的に評価するグローバルなロードバランシング層を経由してルーティングされます。いずれかのノードやリージョンのパフォーマンスが低下した場合、開発者が何らかの操作を行う必要なく、トラフィックは自動的に次善の選択肢へと切り替わります。
最も強力な保証を必要とするチームには、専用クラスターが、カスタムフェイルオーバー構成と稼働時間を保証するSLAを備えた、隔離されたインフラストラクチャを提供します。
フェイルオーバーとロードバランシングの違いは何ですか？ フェイルオーバーとロードバランシングは密接に関連していますが、解決する課題は異なります。ロードバランシングは、着信リクエストを正常なノードのプール全体に分散させることで、個々のノードに過大な負荷がかからないようにします。フェイルオーバーとは、それらのノードのいずれかが正常でなくなった際に発生する処理であり、障害が発生したノードからのトラフィックを引き離し、残りのノードに再分配します。実際には、この2つは連携して機能しており、堅牢な高可用性環境 を構築するには、両方を並行して運用する必要があります。
機能
負荷分散
フェイルオーバー
主な仕事
トラフィックを均等に分散させる
障害箇所からトラフィックを迂回させる
それが作用するとき
すべてのリクエストに対して、継続的に
コンポーネントが劣化または故障した場合にのみ
主な目標
パフォーマンスおよび利用率
継続性と稼働率
トリガー
リクエスト数
ヘルスチェックの失敗
何が「単一障害点」と見なされるのでしょうか？ 単一障害点とは、故障するとシステム全体がダウンしてしまうコンポーネントのことです。単一のノード、単一のクラウドリージョン、あるいは単一のクライアント実装のいずれもが、単一障害点となり得ます。フェイルオーバーは、常に正常な代替手段を準備して引き継ぎできるようにすることで、こうした脆弱な部分を排除します。ブロックチェーンの一般的な障害モード を確認することは、スタック内に潜む単一障害点を見つける最も手っ取り早い方法です。
フェイルオーバーが正常に機能しているかどうかを、どのように確認すればよいでしょうか？ フェイルオーバーは、いくつかの具体的な指標を用いて測定します。稼働率はサービスが利用可能だった頻度を示し、復旧時間は障害発生後にトラフィックが切り替わるまでに要した時間を示し、インシデント発生中のエラー率は、切り替えが完了するまでに影響を受けたリクエストの数を示します。ブロックチェーンインフラを 継続的に監視することで 、これらの数値が明らかになり、フェイルオーバーが正常に機能していることを確認できます。
実際の障害が発生する前に、フェイルオーバーをどのようにテストすればよいでしょうか？ フェイルオーバーを信頼する唯一の方法は、事前のリハーサルを行うことです。チームは、管理された時間帯に意図的にノードやリージョンをオフラインにし、トラフィックがエラーなく迂回されることを確認します。このアプローチは、しばしば「カオステスト」と呼ばれます。独自のノードを運用している場合は、プロセスを停止させて、リクエストがどこに送られるかを確認することができます。QuicknodeCore API などのマネージドプロバイダーを利用している場合は、フェイルオーバーは自動的に処理されますが、リージョン間の負荷テストを行ってその動作を検証することは可能です。
よくある質問
フェイルオーバーとは、簡単に言うと何ですか？ フェイルオーバーとは、サービスが継続して稼働できるよう、故障したコンポーネントから正常に動作しているバックアップへ自動的に切り替えることです。ほとんどの場合、ユーザーは切り替えが行われたことに気づくことはありません。
フェイルオーバーと冗長性は同じものですか？ いいえ。冗長性とは予備のコンポーネントを用意しておくことを指しますが、フェイルオーバーとは、何かが故障した際にトラフィックをそれらの予備に移行させるプロセスのことです。フェイルオーバーを機能させるには、インフラの冗長性が 整備されている必要があります。
フェイルオーバーにはどのくらいの時間がかかりますか？ アクティブ・アクティブ方式では、バックアップシステムがすでにトラフィックを処理しているため、フェイルオーバーはほぼ瞬時に行われることがよくあります。一方、アクティブ・パッシブ方式では、スタンバイシステムが起動して同期を行うまで、数秒から数分かかる場合があります。
フェイルオーバーによって、すべてのダウンタイムを防ぐことができるのでしょうか？ フェイルオーバーはダウンタイムを大幅に短縮しますが、あらゆる状況において中断を完全にゼロにできるとは限りません。多くのリージョンにまたがる、適切に設計されたアクティブ・アクティブ型のインフラストラクチャであれば、その状態に非常に近づくことができるため、本番環境のブロックチェーンアプリケーションにおける標準となっています。
なぜブロックチェーンアプリにとってフェイルオーバーがそれほど重要なのでしょうか？ ブロックチェーン上の処理は時間的制約があり、多くの場合取り消すことができないため、エンドポイントに障害が発生すると、トランザクションが失われたり、古いデータが返されたりすることがあります。自動フェイルオーバーは、信頼性とユーザーの資金の両方を保護するものであり、リアルタイムのデータストリームを 基盤とするサービスにとって極めて重要です。
参考資料 // Tags
フェイルオーバー 自動フェイルオーバー
// Publisher
Quicknode
2026年6月2日更新
2026年4月1日 — 読了時間7分
