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

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

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

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

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

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

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

設計上の考慮事項

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

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

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

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

    データベースと VM の 2 つのインスタンスの使用。この場合、以下の項目により費用の合計額が決定されます。

    • VM インスタンスの費用
    • 永続ディスクの費用
    • アプリケーションのレプリケーションを維持するための費用

    リージョン永続ディスクで高可用性を実現するには、同じ VM インスタンスと永続ディスク コンポーネントを使用するとともに、リージョン永続ディスクも使用します。リージョン永続ディスクは 2 つのゾーンで複製されるため、ゾーン永続ディスクと比べてバイトあたりのコストが倍になります。

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

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

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

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

HA サービス
アーキテクチャ
ゾーン永続ディスク
スナップショット
アプリケーション レベル
同期
アプリケーション レベル
非同期
リージョン永続
ディスクを用いた
HA ソリューション
アプリケーション、VM、ゾーン障害からの保護 1
アプリケーションの破損の軽減(例: アプリケーションのクラッシュの耐性)2
費用 $ $$

  • 実行中のデータベースまたは VM の 2 つのインスタンス、アプリケーションのレプリケーションの設定とメンテナンス、ゾーン間のネットワーク。
$$

  • 実行中のデータベースまたは VM の 2 つのインスタンス、アプリケーションのレプリケーションの設定とメンテナンス、ゾーン間のネットワーク。
$1.5x~$$

  • ホット スタンバイを使用する場合、費用はアプリケーションのレプリケーションと同じです。フェイルオーバー時にバックアップ VM オンデマンドを起動することで、コストを低減できます。リージョン永続ディスクのレプリカ間のクロスゾーン ネットワークには課金されません。
アプリケーションのパフォーマンス

  • 影響なし


  • アプリケーション パフォーマンスと同期レプリケーション間のトレードオフ


  • 影響なし


  • ほとんどのアプリケーションに影響なし
RPO 要件が低いアプリケーション向け(データ損失に対する耐性が非常に低い)

  • スナップショット取得日時によってはデータ損失あり


  • データ損失なし 3


  • レプリケーションが非同期のため、データ損失あり


  • データ損失なし
障害からのストレージ復旧時間 4
  • 0(分)
  • 0(秒)
  • 0(秒)
  • 0(秒)- ディスクのスタンバイ 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 つの目的に使用されます。

  1. ヘルスチェック エージェントは、プライマリ VM とセカンダリ VM 内に置かれ、インスタンスをモニタリングし、ロードバランサと通信してトラフィックを誘導します。これはインスタンス グループで特に役立ちます。
  2. ヘルスチェック エージェントは、アプリケーション固有のリージョンのコントロール プレーンと同期し、コントロール プレーンの動作に基づいてフェイルオーバーを決定します。コントロール プレーンは、稼働状況をモニタリングされているインスタンスとは異なるゾーンにある必要があります。

ヘルスチェック エージェント自体はフォールト トレラントである必要があります。たとえば下の図では、ゾーン us-central1-a にあるプライマリ インスタンスからコントロール プレーンは分離されていて、スタンバイ VM もゾーン us-central1-f にあります。

VM 内のヘルスチェック エージェントのロール

プライマリおよびスタンバイ VM インスタンス内のヘルスチェック エージェントのロール

フェイルオーバー

プライマリ VM またはデータベース内で障害が検出されると、アプリケーションのコントロール プレーンはセカンダリ ゾーン内のスタンバイ VM へのフェイルオーバーを開始できます。フェイルオーバー中、セカンダリ ゾーンに同期的に複製されたリージョン永続ディスクは、アプリケーションのコントロール プレーンによってスタンバイ VM に強制接続され、すべてのトラフィックがヘルスチェック シグナルに基づいて VM に転送されます。

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

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

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

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

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

課題 アプリケーション同期
または準同期レプリケーション
リージョン永続ディスクを用いた
ブロック レプリケーション
プライマリ レプリカとフェイルオーバー レプリカ間の安定したレプリケーションの維持。 インスタンスが HA モードから外れる原因はいくつかあります。
  1. SSL 証明書の不一致、プライマリ側での ACL の不足など、レプリケーション パラメータの構成ミス。
  2. プライマリ インスタンスの負荷が高すぎるため、フェイルオーバー レプリカが追い付かない。
  3. アプリケーションの問題、OS の構成ミス、Docker の障害など、レプリケーションの問題を引き起こすバグ。
  4. CPU の競合、VM のフリーズ、中間ネットワークの中断などのインフラストラクチャの障害。
ストレージ障害は、リージョン永続ディスクによって処理されます。この処理は、ディスクのパフォーマンスに変動が生じる可能性を除いて、アプリケーションに対して透過的に行われます。

アプリケーションや VM の問題を特定し、フェイルオーバーをトリガーするユーザー定義のヘルスチェックが必要です。
エンドツーエンドのフェイルオーバー時間が必要以上に長い。 フェイルオーバー オペレーションにかかる時間に上限はありません。すべてのトランザクションがリプレイされる(上記ステップ 2)まで待機すると、スキーマとデータベースの負荷によっては相当な時間がかかる可能性があります。 リージョン永続ディスクが同期レプリケーションを提供するため、フェイルオーバー時間は以下のレイテンシの合計時間に制限されます。
  1. セカンダリ VM の作成(ホット スタンバイ VM インスタンスがすでに存在する場合を除く)。
  2. リージョン永続ディスクの強制接続。
  3. アプリケーションの初期化。
スプリット ブレイン スプリット ブレインを回避するには、どちらの手法でも、プライマリが 1 度に 1 つしか存在しないようにするためのプロビジョニングが必要となります。

次のステップ