このドキュメントでは、ステートフル アプリケーション、ヘルスチェック エージェント、リージョン永続ディスクをデプロイしてゾーン フェイルオーバーのモニタリングとオーケストレートを行うアプリケーション固有のリージョン コントロール プレーンと間の動作とインタラクションについて説明します。
このドキュメントは、リージョン永続ディスクを使用した高可用性オプションの続編としてアプリケーション デベロッパー向けに作成したもので、リージョン永続ディスクを使用した HA データベース サービスの構築で説明している設計とアーキテクチャを拡張しています。このドキュメントの設計上の考慮事項と費用比較、パフォーマンス、復元力のセクションを最初にお読みになることをおすすめします。
ステートレス アプリケーションは、別の Compute Engine ゾーンで少なくとも 1 つのセカンダリ仮想マシン（VM）インスタンスを実行することで復元力を高めています。プライマリ VM で障害が発生しても、アプリケーションはセカンダリ VM で引き続き動作します。ステートフル アプリケーションは、VM インスタンスを再起動してその状態を復元するために、アプリケーションの状態をゾーン永続ディスクに保持します。復元性を確保するには、ステートフル アプリケーションがアプリケーションの状態をセカンダリ VM に保持する必要があります。
次の図に、2 つのゾーンで複製される一般的な 2 ノード ステートフル アプリケーションを示します。各ゾーンのアプリケーションは、ゾーン永続ディスクにアプリケーションの状態を保存し、VM インスタンス間のネットワーク接続により、アプリケーションの状態変更をノード間で同期します。
リージョン永続ディスクの追加
ステートフル アプリケーションのアプリケーション状態を同期する場合、リージョン永続ディスクを追加する方法もあります。アプリケーションがアプリケーションの状態をリージョン永続ディスクに書き込むと、Google Cloud がブロック ストレージを別のゾーンと自動的に同期します。
次の図に、ステートフル データベース アプリケーションのアーキテクチャを示します。
上の図では、2 つのゾーンに 2 つのアプリケーション VM インスタンス（プライマリ VM インスタンスとセカンダリ VM インスタンス）がデプロイされています。ここでは、アプリケーションの状態を保存するリージョン永続ディスクのほかに、アプリケーション固有のリージョン コントロール プレーンという別のエンティティも存在します。アプリケーション固有のリージョン コントロール プレーンは、リージョン永続ディスクがアタッチされている VM インスタンスと、現在プライマリ VM インスタンスになっている VM インスタンスを特定します。このアーキテクチャはアクティブ / パッシブ構成です。プライマリ VM インスタンスのみがリージョン永続ディスクにアプリケーションの状態を commit できます。
VM インスタンスとステートフル アプリケーション
前述のアーキテクチャ図は、稼働中のアクティブ / パッシブ データベース アプリケーションを示していますが、次の構成も可能です。
- 目標復旧時間（RTO）にセカンダリ VM インスタンスの起動時に追加のレイテンシを許容できる余裕がある場合は、アクティブ VM インスタンスのみを実行することで、Compute Engine の費用を抑えることができます。フェイルオーバーでは、アプリケーション固有のリージョン コントロール プレーンがセカンダリ VM インスタンスを開始し、リージョン永続ディスクをアタッチします。
- リージョン永続ディスクに対する進行状況を確認するバッチ処理またはストリーム処理のワークロード。フェイルオーバーが行われると、アプリケーションはその最後のチェックポイントから処理を再開します。
VM インスタンスのスタートアップの管理
リージョン永続ディスクに同時にアタッチできる VM インスタンスは 1 つだけです。このため、VM インスタンスを起動して、リージョン永続ディスクを体系的にアタッチする必要があります。VM インスタンスとアプリケーションの起動をリージョン永続ディスクのアタッチから分離することをおすすめします。VM インスタンスの起動スクリプトで、リージョン永続ディスクのアタッチを開始することはできません。代わりに、起動スクリプトでヘルスチェック エージェントを起動し、リージョン永続ディスクがアタッチされるまで待機する必要があります。
起動時に、VM インスタンスが次の手順を順番に行う必要があります。
- ヘルスチェック エージェントを起動する。
- リージョン永続ディスクがアタッチされるまで待機する。
- リージョン永続ディスクのアタッチ後、ファイル システムをマウントする。
- ファイル システムをマウントしたら、アプリケーションを起動する。
この手順でシステムを起動できますが、フェイルオーバーも発生します。フェイルオーバー中、リージョン永続ディスクはセカンダリ VM インスタンスに強制的にアタッチされます。また、リージョン永続ディスクがプライマリ VM インスタンスから強制的に削除され、ファイル システムに対する入出力オペレーションが失敗します。この時点で、VM インスタンスをシャットダウンまたは再起動する必要があります。
ヘルスチェック エージェントとヘルスチェックの実行
前のセクションで説明したとおり、VM インスタンスは、アプリケーションの開始前にリージョン永続ディスクがアタッチされるのを待機します。アプリケーション固有のリージョン コントロール プレーンは、ディスクのアタッチを待機している VM インスタンスにのみリージョン永続ディスクをアタッチします。ディスクがアタッチされると、アプリケーション固有のコントロール プレーンがアプリケーションの正常性をモニタリングします。アプリケーションが異常な状態になると、フェイルオーバーを開始します。
各 VM インスタンスは、次のいずれかの状態になります。
- 停止中
- 開始中
- ディスク待機中
- アプリケーション実行中
ヘルスチェック エージェントは、VM インスタンスの現在の状態を報告します。2 つの状態を 1 回のヘルスチェックで報告するのではなく、2 回のバイナリ ヘルスチェックを実行できます。VM インスタンスでリージョン永続ディスクをアタッチする準備ができている場合、またはリージョン永続ディスクがアタッチされ、書き込み可能である場合、VM インスタンスのヘルスチェックにより正常なステータスが報告されます。アプリケーションが動作中で、アプリケーションの状態をリージョン永続ディスクに書き込める場合、アプリケーションのヘルスチェックにより正常なステータスが報告されます。
2 つのバイナリ ヘルスチェックを使用すると、次のような利点があります。
- Compute Engine のマネージド ヘルスチェック サービスを使用できます。このサービスでは、ヘルスチェック エージェントがポーリングされ、しきい値カウントを使用して一時的なエラーが解消されます。
- マネージド インスタンス グループ（MIG）は、インスタンスのヘルスチェックをモニタリングして、異常な VM インスタンスを自動修復できます。
- ロードバランサは、アプリケーションのヘルスチェックをモニタリングし、トラフィックをアクティブなアプリケーション インスタンスにルーティングできます。
システムが一時的な障害に反応するのを防ぐには、ヘルスチェック レポートの頻度を下げるか、レベル間の移行に必要な繰り返しシグナルのしきい値を増やします。どちらの手法でも、システムが障害に反応するのを遅らせ、復旧までの時間を延長できます。これらのパラメータをテストして測定することで、システムの復旧時間のバランスをとれるようにヘルスチェックのパラメータを調整できます。
アプリケーション固有のリージョン コントロール プレーンについて
アーキテクチャの最後の部分はアプリケーション固有のリージョン コントロール プレーンです。これは次の 2 つの機能を担います。
- プライマリ VM インスタンスとセカンダリ VM インスタンスのライフサイクルを管理する。
- アプリケーションのヘルスチェックのステータスをモニタリングすることで、フェイルオーバーが必要かどうかを判断する。
フェイルオーバーが必要な場合、アプリケーション固有のリージョン コントロール プレーンによってフェイルオーバーの調整が行われます。
- セカンダリ VM インスタンスが動作中で、リージョン永続ディスクのアタッチを待機しているかを確認する。
- リージョン永続ディスクをセカンダリ VM インスタンスに強制的にアタッチする。
- 障害が発生したプライマリ VM インスタンスをモニタリングして再起動する。VM インスタンスが再起動されると、必要に応じてコントロール プレーンがフェイルバックを開始します。
アプリケーション固有のリージョン コントロール プレーン自体は、アプリケーションが動作している 2 つのゾーン間で高可用性を維持する必要があります。多くの場合、オンプレミスのデータセンターでは追加のサーバーをデプロイしてクォーラムを構築し、どの VM インスタンスがプライマリ VM インスタンスかを特定してフェイルオーバーをオーケストレートすることで、高可用性（HA）を確保できます。この場合、Heartbeat、Pacemaker、Keepalived などの HA モニタリング ツールがよく使用されています。
アプリケーション固有のリージョン コントロール プレーンはクラウドのどこででも使用できますが、Google Cloud では、リージョンで以下のマネージド サービスを利用できるため、この手法を簡単に実施できます。
- App Engine、Cloud Run、Cloud Run 関数などの Google Cloud サーバーレス プロダクト。管理やデプロイが簡単です。
- アプリケーション インスタンスのモニタリングの負荷を軽減するマネージド ヘルスチェック。
- サーバー インスタンスのライフサイクルを管理するマネージド インスタンス グループ。
次の図では、ステートフル マネージド インスタンス グループとマネージド ヘルスチェックに加え、アプリケーション固有のリージョン コントロール プレーンに Cloud Run functions を使用しています。
上の図には、アプリケーションの VM インスタンスが 2 つあります（プライマリとセカンダリ）。VM インスタンスはそれぞれ別のゾーンで実行され、ステートフル リージョン MIG によって管理されます。同じリージョン永続ディスクが 2 つのゾーンで使用されています。2 つのマネージド ヘルスチェック サービスが実行されています。マネージド ヘルスチェック サービスの 1 つは VM インスタンスのヘルス ステータスをモニタリングします。このサービスは、ステートフル MIG によって使用されます。他のヘルスチェック サービスはアプリケーションのヘルス ステータスをモニタリングし、ロードバランサのターゲット プールによって使用されます。
アプリケーション固有のリージョン コントロール プレーンは、アプリケーションのステータスをモニタリングし、リージョン永続ディスクを現在の正常な VM インスタンスにアタッチするため、ターゲット プール アプリケーションのヘルス ステータスとステートフル リージョン MIG を使用します。
次のステップ
- Google Kubernetes Engine でのリージョン永続ディスクのプロビジョニングを確認する。
- オンプレミスの HA ツールを Google Cloud で使用する方法については、フローティング IP アドレスの使用のパターンを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。