同期的に複製されたディスクを使用して HA サービスを構築する


リージョン Persistent Disk と Hyperdisk Balanced の高可用性は、Compute Engine に高可用性(HA)サービスを実装できるストレージ オプションです。リージョン Persistent Disk と Hyperdisk Balanced の高可用性は、同じリージョン内の 2 つのゾーン間でデータを同期的に複製し、1 つのゾーンの障害に対してディスクデータの HA を確保します。

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

このセクションでは、リージョン Persistent Disk またはHyperdisk Balanced の高可用性ディスクを使用して HA サービスを構築する方法について説明します。

設計上の考慮事項

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

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

高可用性の設計をする際は、次の点を考慮してください。

  • Hyperdisk Balanced の高可用性、リージョン Persistent Disk 、またはその他のソリューションの使用がアプリケーションに与える影響。
  • ディスク書き込みのパフォーマンス。
  • サービスの目標復旧時間 - ゾーン停止からのサービス復旧にかけられる時間と SLA の要件
  • 回復力のある信頼性の高いサービス アーキテクチャを構築するための費用。
  • メキシコ、大阪、モントリオールは、1 つまたは 2 つの 物理的なデータセンターに 3 つのゾーンがあります。これらのリージョンに保存されたデータは、まれなケースですが、データセンターの破壊によって失われる可能性があります。データ保護を強化するため、ビジネスに不可欠なデータを別のリージョンにバックアップすることを検討してください。

費用に関しては、同期的および非同期的なアプリケーション レプリケーションのために次のオプションを使用します。

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

    • VM インスタンスの費用
    • Persistent Disk またはHyperdisk の費用
    • アプリケーションのレプリケーションを維持するための費用
  • 同期的に複製されたディスクを持つ単一の VM を使用する。リージョン Persistent Disk または Hyperdisk Balanced の高可用性ディスクで高可用性を実現するには、前のオプションと同じ VM インスタンスとディスク コンポーネントを使用するとともに、同期的に複製されたディスクも使用します。 リージョン Persistent Disk と Hyperdisk Balanced 高可用性ディスクは 2 つのゾーンで複製されるため、ゾーンディスクと比べてバイトあたりのコストが倍になります。

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

  • フェイルオーバーが必要になるまで、セカンダリ VM を起動しないでください。 VM をアクティブなスタンバイ VM として維持するのではなくフェイルオーバー時にセカンダリ VM オンデマンドを起動するだけで、さらにホスト費用を削減できます。

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

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

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

  • Two instances of the database or VM running, application replication setup and maintenance, cross zone networking.
$$

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

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

  • 影響なし


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


  • 影響なし


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

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


  • データ損失なし


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


  • データ損失なし
障害からのストレージ復旧時間 #
  • O(分)
  • 0(秒)
  • 0(秒)
  • 0(秒)- ディスクのスタンバイ VM インスタンスへの強制接続にかかる時間

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

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

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

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

リージョン ディスクを使用した HA データベース サービスの構築

このセクションでは、リージョン Persistent Disk と Hyperdisk Balanced の高可用性ディスクを使用して、Compute Engine でステートフルなデータベース サービス(MySQL、Postgres など)向けの HA ソリューションを構築する全体的なコンセプトについて説明します。

たとえば、Google Cloud で広範囲に停止が発生した場合、リージョン全体が使用できなくなると、アプリケーションを使用できなくなる可能性があります。必要に応じて、可用性をさらに高めるためにクロスリージョン レプリケーションの手法またはPersistent Disk の非同期レプリケーション(PD 非同期レプリケーション) を検討してください。

通常、データベース HA の構成には少なくとも 2 つの VM インスタンスが必要です。これらの VM インスタンスは可能であれば、以下のとおり、1 つ以上のマネージド インスタンス グループに所属するインスタンスにします。

  • プライマリ ゾーン内のプライマリ VM インスタンス
  • セカンダリ ゾーン内のスタンバイ VM インスタンス

プライマリ VM インスタンスには、ブートディスクとリージョンディスクの少なくとも 2 つのディスクがあります。リージョン ディスクには、システム停止に備えて別のゾーンに保存する必要があるデータベースのデータとその他の変更可能なデータが含まれます。

スタンバイ VM インスタンスでは、オペレーティング システムのアップグレードなど、構成関連の停止から復旧するための別のブートディスクが必要です。また、フェイルオーバー中はブートディスクを別の VM に強制接続できません。

プライマリ VM インスタンスとスタンバイ VM インスタンスは、ヘルスチェック シグナルに基づいてプライマリ VM に転送されるトラフィックに対してロードバランサを使用します。データの障害復旧シナリオでは、他のフェイルオーバー構成の概要を示しています。目的のシナリオによっては、こちらの方が適している場合があります。

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

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

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

ストレージ障害は、 リージョン Persistent Disk と Hyperdisk Balanced の高可用性ディスクによって処理されます。この処理は、ディスクのパフォーマンスに変動が生じる可能性を除いて、アプリケーションに対して透過的に行われます。

アプリケーションや VM の問題を特定し、フェイルオーバーをトリガーするユーザー定義のヘルスチェックが必要です。

エンドツーエンドのフェイルオーバー時間が必要以上に長い。 フェイルオーバー オペレーションにかかる時間に上限はありません。すべてのトランザクションがリプレイされる(上記ステップ 2)まで待機すると、スキーマとデータベースの負荷によっては相当な時間がかかる可能性があります。

リージョン Persistent Disk と Hyperdisk Balanced 高可用性ディスクは同期レプリケーションを提供するため、フェイルオーバー時間は以下のレイテンシの合計時間に制限されます。

  1. セカンダリ VM の作成(スタンバイ VM インスタンスがすでに存在する場合を除く)。
  2. リージョン ディスクの強制接続。
  3. アプリケーションの初期化。
スプリット ブレイン スプリット ブレインを回避するには、どちらの手法でも、プライマリが 1 度に 1 つしか存在しないようにするためのプロビジョニングが必要となります。

ディスクに対する読み取り / 書き込みオペレーションのシーケンス

読み取りと書き込みシーケンス、つまりデータがディスクに読み書きされる順序を決定する際に、作業の大部分は VM 内のディスク ドライバによって行われます。ユーザーはレプリケーションのセマンティクスを処理する必要はなく、通常どおりファイル システムを操作できます。基盤ドライバが読み取りと書き込みのシーケンスを処理します。

デフォルトでは、リージョン Persistent Disk またはHyperdisk Balanced の高可用性を使用する Compute Engine VM は完全レプリケーション モードで動作します。このモードでは、ディスクからの読み取りまたは書き込みのリクエストが両方のレプリカに送信されます。

完全レプリケーション モードでは、次の処理が発生します。

  • 書き込み時、書き込みリクエストは両方のレプリカへの書き込みを試行し、両方の書き込みが成功したことを確認します。
  • 読み取り時、VM は両方のレプリカに読み取りリクエストを送信し、成功したレプリカからの結果を返します。読み取りリクエストがタイムアウトすると、別の読み取りリクエストが送信されます。

レプリカが処理に遅れ、読み取りまたは書き込みリクエストの完了の確認応答に失敗した場合、レプリカの状態が更新されます。

ヘルスチェック

ロードバランサによって使用されるヘルスチェックは、ヘルスチェック エージェントによって実装されます。ヘルスチェック エージェントは、次の 2 つの目的で使用します。

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

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

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

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

次のステップ