リージョン PD を使用した高可用性オプション

このドキュメントでは、幅広いアーキテクチャの費用、パフォーマンス、復元力の比較に加え、サービスの可用性を高めるさまざまなオプションも比較することで、リージョン永続ディスクを使用して高可用性（HA）サービスをビルドする方法について説明します。

リージョン永続ディスクは、リージョン内の 2 つのゾーン間でデータの同期レプリケーションを行うストレージオプションです。リージョン永続ディスクは、Compute Engine で HA サービスを実装する際の優れた構成要素となりえます。

リージョン永続ディスクのメリットは、ゾーンの停止が発生し仮想マシン（VM）インスタンスが使用できなくなった場合に、通常は同じリージョン内のセカンダリゾーンにある VM インスタンスにリージョン永続ディスクを強制接続できることです。このタスクを行うには、強制接続するリージョン永続ディスクと同じゾーン内で別の VM インスタンスを起動するか、そのゾーン内でホットスタンバイの VM インスタンスを維持する必要があります。ホットスタンバイは、使用中の VM インスタンスと同一の、実行中の VM インスタンスです。2 つのインスタンスは同じデータを所有します。

強制接続オペレーションは 1 分以内に実行されます。目標復旧時間（RTO）の合計時間は、ストレージのフェイルオーバー（リージョン永続ディスクの強制接続）だけでなく、セカンダリ VM インスタンスをまず作成する必要があるかどうか、基盤のファイルシステムがホットアタッチされたディスクの検出にかける時間、対応するアプリケーションの復旧時間、その他の要因にも依存します。

リージョン永続ディスクはワークロードの可用性を優先します。つまり、まれに両方のディスクレプリカが同時に使用できなくなった場合に、データ保護のトレードオフが発生します。詳しくは、リージョン永続ディスクのフェイルオーバーをご覧ください。

リージョン永続ディスクを使用した高可用性サービスの構築

設計上の考慮事項

HA サービスの設計を開始する前に、アプリケーション、ファイルシステム、オペレーティングシステムの特性を理解しておく必要があります。これらの特性は設計の基本であり、さまざまなアプローチが排除されます。たとえば、アプリケーションレベルのレプリケーションをサポートしていないアプリケーションの場合、対応する設計オプションが適用できないことがあります。

同様に、アプリケーション、ファイルシステム、またはオペレーティングシステムにクラッシュに対する耐性がない場合、リージョン永続ディスクまたはゾーン永続ディスクのスナップショットを使用できない場合があります。クラッシュに対する耐性は、クラッシュ前に永続ディスクに保存済みのデータを消失、破損することなく、突然の終了から復旧すること、と定義されます。

次の点を考慮してください。

アプリケーションと書き込みパフォーマンスへの影響を把握します。
サービス復旧時間の目標を決定します。ゾーン停止からのサービス復旧にかけられる時間と SLA の要件を把握します。
復元力と信頼性の高いサービスアーキテクチャを構築するための費用を把握します。アプリケーション同期レプリケーションとアプリケーション非同期レプリケーションの費用面でのオプションは次のとおりです。

データベースと VM の 2 つのインスタンスの使用。この場合、以下の項目により費用の合計額が決定されます。
- VM インスタンスの費用
- 永続ディスクの費用
- アプリケーションのレプリケーションを維持するための費用
リージョン永続ディスクで高可用性を実現するには、同じ VM インスタンスと永続ディスクコンポーネントを使用するとともに、リージョン永続ディスクも使用します。リージョン永続ディスクは 2 つのゾーンで複製されるため、ゾーン永続ディスクと比べてバイトあたりのコストが倍になります。

ですが、リージョン永続ディスクの使用でメンテナンス費用を削減できる場合があります。これは、アプリケーションのレプリケーションを維持せずとも自動的に 2 つのレプリカにデータが複製されるためです。

VM をホットスタンバイとして維持するのではなくフェイルオーバー時にバックアップ VM オンデマンドを起動するだけで、さらにホスト費用を削減できます。

費用、パフォーマンス、復元力の比較

次の表は、さまざまなサービスアーキテクチャの費用、パフォーマンス、復元力に関するトレードオフを示しています。

HA サービスアーキテクチャ	ゾーン永続ディスクスナップショット	アプリケーションレベル同期	アプリケーションレベル非同期	リージョン永続ディスクを用いた HA ソリューション
アプリケーション、VM、ゾーン障害からの保護 ¹
アプリケーションの破損の軽減（例: アプリケーションのクラッシュの耐性）²
費用	$	$$ 実行中のデータベースまたは VM の 2 つのインスタンス、アプリケーションのレプリケーションの設定とメンテナンス、ゾーン間のネットワーク。	$$ 実行中のデータベースまたは VM の 2 つのインスタンス、アプリケーションのレプリケーションの設定とメンテナンス、ゾーン間のネットワーク。	$1.5x～$$ ホットスタンバイを使用する場合、費用はアプリケーションのレプリケーションと同じです。フェイルオーバー時にバックアップ VM オンデマンドを起動することで、コストを低減できます。リージョン永続ディスクのレプリカ間のクロスゾーンネットワークには課金されません。
アプリケーションのパフォーマンス	影響なし	アプリケーションパフォーマンスと同期レプリケーション間のトレードオフ	影響なし	ほとんどのアプリケーションに影響なし
RPO 要件が低いアプリケーション向け（データ損失に対する耐性が非常に低い）	スナップショット取得日時によってはデータ損失あり	データ損失なし ³	レプリケーションが非同期のため、データ損失あり	データ損失なし
障害からのストレージ復旧時間 ⁴	0（分）	0（秒）	0（秒）	0（秒）- ディスクのスタンバイ VM インスタンスへの強制接続にかかる時間

¹ リージョン永続ディスクやスナップショットを使用するだけでは、障害、破損からの保護、緩和はできません。アプリケーション、ファイルシステムなどのソフトウェアコンポーネントがクラッシュ整合性を持つ必要があるか、なんらかの静止を使用する必要があります。

² アプリケーションを複製することで、破損リスクが軽減されるアプリケーションもあります。たとえば、MySQL プライマリアプリケーションが破損しても、レプリカインスタンスは破損しません。詳しくは、アプリケーションのドキュメントをご覧ください。

³ データ損失とは、永続ストレージに保存されたデータの回復不能な消失を意味します。保存されていないデータはすべて失われます。

⁴ フェイルオーバーのパフォーマンスには、フェイルオーバー後のファイルシステムのチェック、アプリケーションの復旧および読み込みは含まれません。

リージョン永続ディスクを使用した 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 に強制接続され、すべてのトラフィックがヘルスチェックシグナルに基づいて VM に転送されます。

障害検出時間を除いたフェイルオーバーレイテンシの合計時間は、次のレイテンシの合計です。

0 秒。リージョン永続ディスクのスタンバイ VM への強制接続にかかる時間。
アプリケーションの初期化と障害復旧にかかる時間

障害復旧の構成要素のページでは、Compute Engine で現在使用可能な構成要素について説明しています。

データベースレプリケーションの課題

次の表は、アプリケーション同期レプリケーションと準同期レプリケーション（MySQL など）の設定と管理に関する一般的な課題と、リージョン永続ディスクを用いたブロックレプリケーションとの比較を示しています。

課題	アプリケーション同期または準同期レプリケーション	リージョン永続ディスクを用いたブロックレプリケーション
プライマリレプリカとフェイルオーバーレプリカ間の安定したレプリケーションの維持。	インスタンスが HA モードから外れる原因はいくつかあります。 SSL 証明書の不一致、プライマリ側での ACL の不足など、レプリケーションパラメータの構成ミス。プライマリインスタンスの負荷が高すぎるため、フェイルオーバーレプリカが追い付かない。アプリケーションの問題、OS の構成ミス、Docker の障害など、レプリケーションの問題を引き起こすバグ。 CPU の競合、VM のフリーズ、中間ネットワークの中断などのインフラストラクチャの障害。	ストレージ障害は、リージョン永続ディスクによって処理されます。この処理は、ディスクのパフォーマンスに変動が生じる可能性を除いて、アプリケーションに対して透過的に行われます。アプリケーションや VM の問題を特定し、フェイルオーバーをトリガーするユーザー定義のヘルスチェックが必要です。
エンドツーエンドのフェイルオーバー時間が必要以上に長い。	フェイルオーバーオペレーションにかかる時間に上限はありません。すべてのトランザクションがリプレイされる（上記ステップ 2）まで待機すると、スキーマとデータベースの負荷によっては相当な時間がかかる可能性があります。	リージョン永続ディスクが同期レプリケーションを提供するため、フェイルオーバー時間は以下のレイテンシの合計時間に制限されます。セカンダリ VM の作成（ホットスタンバイ VM インスタンスがすでに存在する場合を除く）。リージョン永続ディスクの強制接続。アプリケーションの初期化。
スプリットブレイン	スプリットブレインを回避するには、どちらの手法でも、プライマリが 1 度に 1 つしか存在しないようにするためのプロビジョニングが必要となります。