このドキュメントでは、幅広いアーキテクチャの費用、パフォーマンスおよび復元力の比較に加え、サービスの可用性を高めるさまざまなオプションも比較することで、リージョン永続ディスクを使用して高可用性（HA）サービスを構築する方法について説明します。また、障害の種類と復旧アクションについても説明します。これによって、リージョン永続ディスクが HA サービスに適したソリューションかどうかを判断できます。
リージョン永続ディスクは、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行うストレージ オプションです。リージョン永続ディスクは、Compute Engine で HA サービスを実装する際の優れた構成要素となりえます。
リージョン永続ディスクのメリットは、ゾーン全体が停止し、VM インスタンスが使用できなくなった場合、リージョン永続ディスクを同じリージョン内のセカンダリ ゾーンの VM インスタンスに強制接続できることです。このタスクを行うには、強制接続するリージョン永続ディスクと同じゾーン内で別の VM インスタンスを起動するか、そのゾーン内でホット スタンバイの VM インスタンスを維持する必要があります。「ホット スタンバイ」は、使用中の VM インスタンスと同一の、実行中の VM インスタンスです。2 つのインスタンスは同じデータを所有します。
強制接続操作は 1 分以内に実行されるため、数分で復旧時間目標（RTO）が達成されます。RTO の合計時間は、ストレージのフェイルオーバー（リージョン永続ディスクの強制接続）だけでなく、セカンダリ VM インスタンスをまず作成する必要があるかどうか、基盤のファイルシステムがホットアタッチされたディスクの検出にかける時間、対応するアプリケーションの復旧時間、その他の要因にも依存します。
設計上の考慮事項
HA サービスの設計を開始する前に、アプリケーション、ファイルシステム、オペレーティング システムの特性を理解しておく必要があります。これらの特性は設計の基本であり、さまざまなアプローチが排除されます。たとえば、アプリケーションレベルのレプリケーションをサポートしていないアプリケーションの場合、対応する設計オプションが適用できないことがあります。
同様に、アプリケーション、ファイルシステム、またはオペレーティング システムにクラッシュに対する耐性がない場合、リージョン永続ディスクまたはゾーン永続ディスクのスナップショットを使用することができない場合があります。クラッシュに対する耐性は、クラッシュ前に永続ディスクに保存済みのデータを消失、破損することなく、突然の終了から復旧すること、と定義されます。
次の点を考慮してください。
- アプリケーションと書き込みパフォーマンスへの影響を把握します。
- サービス復旧時間の目標を決定します。ゾーン停止からのサービス復旧にかけられる時間と SLA の要件を把握します。
復元力と信頼性の高いサービス アーキテクチャを構築するための費用を把握します。費用面での、アプリケーション同期レプリケーションとアプリケーション非同期レプリケーションのオプションは次のとおりです。
データベースと VM の 2 つのインスタンスの使用。この場合、以下の項目により費用の合計額が決定されます。
- VM インスタンスの費用
- 永続ディスクの費用
- アプリケーションのレプリケーションを維持するための費用
リージョン永続ディスクで高可用性を実現するには、同じ VM インスタンスと永続ディスク コンポーネントを使用するとともに、リージョン永続ディスクも使用します。リージョン永続ディスクは 2 つのゾーンで複製されるため、ゾーン永続ディスクと比べてバイトあたりのコストが倍になります。
ですが、リージョン永続ディスクの使用でメンテナンス費用を削減できる場合があります。これは、アプリケーションのレプリケーションを維持せずとも自動的に 2 つのレプリカにデータが複製されるためです。
（VM をホット スタンバイとして維持するのではなく）フェイルオーバー時にバックアップ VM オンデマンドを起動するだけで、さらにホスト費用を削減できます。
費用、パフォーマンス、復元力の比較
次の表は、さまざまなサービス アーキテクチャの費用、パフォーマンス、復元力に関するトレードオフを示しています。
| HA サービス アーキテクチャ |
ゾーン永続ディスク スナップショット |
アプリケーション レベル 同期 |
アプリケーション レベル 非同期 |
リージョン永続 ディスクを用いた HA ソリューション |
|---|---|---|---|---|
| アプリケーション、VM、ゾーン障害からの保護 1 | ||||
| アプリケーションの破損の軽減（例: アプリケーションのクラッシュの耐性）2 | ||||
| 費用 | $ | $$ データベース / VM の 2 つのインスタンスの実行 + アプリケーションのレプリケーションの維持と設定にかかる費用 + クロスゾーン ネットワーク |
$$ データベース / VM の 2 つのインスタンスの実行 + アプリケーションのレプリケーションの維持と設定にかかる費用 + クロスゾーン ネットワーク |
$1.5x～$$ ホット スタンバイを使用する場合、費用はアプリケーションのレプリケーションと同じです。フェイルオーバー時にバックアップ VM オンデマンドを起動することで、コストを低減できます。 |
| アプリケーションのパフォーマンス | 影響なし |
アプリケーション パフォーマンスと同期レプリケーション間のトレードオフ |
影響なし |
ほとんどのアプリケーションに影響なし |
| RPO 要件が低いアプリケーション向け（データ消失に対する耐性なし） | スナップショット取得日時によってはデータ損失あり |
データ損失なし 3 |
レプリケーションが非同期のため、データ損失あり |
データ損失なし |
| 障害からのストレージ復旧時間 4 | O（分） | O（秒） | O（秒） | O（秒） - スタンバイ VM インスタンスにディスクを強制接続するための時間 |
1 リージョン永続ディスクやスナップショットを使用するだけでは、障害、破損からの保護、緩和はできません。アプリケーション、ファイルシステムなどのソフトウェア コンポーネントがクラッシュ整合性を持つ必要があるか、なんらかの静止を使用する必要があります。
2 アプリケーションを複製することで、破損リスクが軽減されるアプリケーションもあります。たとえば、MySQL マスター アプリケーションが破損しても、レプリカ インスタンスは破損しません。詳しくは、アプリケーションのドキュメントをご覧ください。
3 データ損失とは、永続ストレージに保存されたデータの回復不能な消失を意味します。保存されていないデータはすべて失われます。
4 フェイルオーバーのパフォーマンスには、フェイルオーバー後のファイル システムのチェック、アプリケーションの復旧および読み込みは含まれません。
リージョン永続ディスクを使用した HA データベース サービスの構築
このセクションでは、リージョン永続ディスクと Compute Engine を使用して、ステートフルなデータベース サービス（MySQL、Postgres など）向けの HA ソリューションを構築する全体的なコンセプトについて説明します。
ここでは、1 つのゾーンでの停止の緩和について説明します。たとえば、リージョン全体が使用できなくなるなど、広範な停止が発生した場合でも、アプリケーションが使用できなくなる可能性があります。必要に応じてクロス リージョン レプリケーションを使用すると、可用性をさらに高めることができます。
通常、データベース HA の構成には少なくとも 2 つの VM インスタンスが必要です。これらのインスタンスは可能であれば、以下のとおり、1 つ以上のマネージド インスタンス グループに所属するインスタンスにします。
- プライマリ ゾーン内のプライマリ VM インスタンス
- セカンダリ ゾーン内のスタンバイ VM インスタンス
プライマリ VM インスタンスには、ブートディスクとリージョン永続ディスクの少なくとも 2 つの永続ディスクがあります。リージョン永続ディスクには、システム停止に備えて別のゾーンに保存する必要があるデータベースのデータとその他の変更可能なデータが含まれます。
スタンバイ VM インスタンスでは、オペレーティング システムのアップグレードなど、構成関連の停止から復旧するための別のブートディスクが必要です。フェイルオーバー中はブートディスクを別の VM に強制接続できません。
プライマリ VM インスタンスとスタンバイ VM インスタンスは、ヘルスチェック シグナルに基づいてプライマリ VM に転送されるトラフィックに対してロードバランサを使用します。この構成は、ホット スタンバイとも呼ばれます。データの障害復旧シナリオでは、他のフェイルオーバー構成の概要を示しています。目的のシナリオによっては、こちらの方が適している場合があります。
ヘルスチェック
ヘルスチェックは、ヘルスチェック エージェントによって実装され、次の 2 つの目的に使用されます。
- ヘルスチェック エージェントは、プライマリ VM とセカンダリ VM 内に置かれ、インスタンスをモニタし、ロードバランサと通信してトラフィックを誘導します。これはインスタンス グループで特に役立ちます。
ヘルスチェック エージェントは、アプリケーション固有のリージョンのコントロール プレーンと同期し、コントロール プレーンの動作に基づいてフェイルオーバーを決定します。コントロール プレーンは、稼働状況をモニタされているインスタンスとは異なるゾーンにある必要があります。
ヘルスチェック エージェント自体はフォールト トレラントである必要があります。たとえば下の図では、ゾーン
us-central1-aにあるプライマリ インスタンスからコントロール プレーンは分離されていて、スタンバイ VM もゾーンus-central1-fにあります。
フェイルオーバー
プライマリ VM またはデータベース内で障害が検出されると、アプリケーションのコントロール プレーンはセカンダリ ゾーン内のスタンバイ VM へのフェイルオーバーを開始できます。フェイルオーバー中、セカンダリ ゾーンに同期的に複製されたリージョン永続ディスクは、アプリケーションのコントロール プレーンによってスタンバイ VM に強制接続され、すべてのトラフィックがヘルスチェック シグナルに基づいて VM に転送されます。
障害検出時間を除いたフェイルオーバー レイテンシの合計時間は、次のレイテンシの合計です。
- リージョン永続ディスクのスタンバイ VM への強制接続にかかる 0 秒間
- アプリケーションの初期化と障害復旧にかかる時間
障害復旧の構成要素ページでは、Compute Engine で現在使用可能な構成要素について説明しています。リージョン永続ディスクは、ディスクレベルのレプリケーションを実現することから、HA ソリューションを構築するための新たな主要構成要素となっています。
障害モード
次の表は、リージョン永続ディスクを使用するサービスのさまざまな障害モードと推奨される対応を示しています。
| 障害のカテゴリ（および確率） | 障害の種類 | アクション |
|---|---|---|
| ゾーン障害（中） | ローカルゾーン内でディスクにのみ障害が発生します。障害は、一時的もしくは長期的です。 Compute Engine コントロール プレーン 停電 ネットワーク障害 |
リージョン ディスク操作の一時的な問題は、リージョン永続ディスクによって透過的に処理され、フェイルオーバーは不要です。リージョン永続ディスクが自動的にエラーと遅延を検出し、レプリケーション モードを切り替え、1 つのゾーンにのみ複製されたデータの状態に追い付きます。 プライマリ ゾーン内のストレージに問題が発生した場合、セカンダリ ゾーンから自動的に読み取りが行われます。これにより、読み取り操作のレイテンシが増加する可能性があります。このような場合、アプリケーションはパフォーマンスへの影響に基づいてフェイルオーバーをトリガーする可能性があります。 アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。 |
| アプリケーション障害（高） | アプリケーションが反応しない アプリケーション管理者によるアクション（たとえば、アップグレードなど） ヒューマン エラー （たとえば、SSL、ACL などのパラメータの構成ミス） |
アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。 |
| VM 障害（中） | インフラストラクチャ/ハードウェア障害 CPU の競合のため VM が応答しない、中間ネットワークの中断 |
VM は通常、自動修復されます。アプリケーションのコントロール プレーンは、ヘルスチェックのしきい値に基づいてフェイルオーバーをトリガーできます。 |
| アプリケーションの破損（低～中） | アプリケーション データの破損 （たとえば、アプリケーションのバグや OS のアップグレードが要因） |
アプリケーションの復旧:
|
データベース レプリケーションの課題
次の表は、アプリケーション同期レプリケーションと準同期レプリケーション（MySQL など）の設定と管理に関する一般的な課題と、リージョン永続ディスクを用いたブロック レプリケーションとの比較を示しています。
| 課題 | アプリケーション同期 または準同期レプリケーション |
リージョン永続ディスクを用いた ブロック レプリケーション |
|---|---|---|
| マスターとフェイルオーバー レプリカ間の安定したレプリケーションの維持。 | インスタンスが HA モードから外れる原因はいくつかあります。
|
ストレージ障害は、リージョン永続ディスクによって処理されます。この処理は、ディスクのパフォーマンスに変動が生じる可能性を除いて、アプリケーションに対して透過的に行われます。 アプリケーションや VM の問題を特定し、フェイルオーバーをトリガーするユーザー定義のヘルスチェックが必要です。 |
| エンドツーエンドのフェイルオーバー時間が必要以上に長い。 | フェイルオーバー操作にかかる時間に上限はありません。すべてのトランザクションがリプレイされる（上記ステップ 2）まで待機すると、スキーマとデータベースの負荷によってはかなりの時間がかかる可能性があります。 | リージョン永続ディスクが同期レプリケーションを提供するため、フェイルオーバー時間は以下のレイテンシの合計時間に制限されます。
|
| スプリット ブレイン | スプリット ブレインを回避するには、どちらの手法でも、マスターが 1 度に 1 つしか存在しないようにするためのプロビジョニングが必要となります。 | |
次のステップ