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