このドキュメントでは、マネージド インスタンス グループ（MIG）がグループ内で障害が発生した VM と異常な VM を修復して、アプリケーションの高可用性を実現する方法について説明します。
MIG は、グループ内で実行中の VM の数をプロアクティブに維持することで、アプリケーションの可用性を維持します。グループ内の VM が停止すると、MIG では次の方法で VM を再作成して修復し、VM をサービスに復帰させます。
- 障害が発生した VM を自動的に修復: VM に障害が発生した場合、または MIG によって開始されていないアクションによって VM が削除された場合、MIG では障害が発生した VM が自動的に修復されます。このドキュメント内の障害が発生した VM の自動修復をご覧ください。
- アプリケーションのヘルスチェックに基づいて VM を修復する: 異常な VM を修復することで高可用性を向上させる省略可能な方法。アプリケーション ベースのヘルスチェックを構成して、アプリケーションがヘルスチェックに失敗した場合、MIG は��の VM を異常としてマークし、修復します。アプリケーションのヘルスチェックに基づいて VM を修復することを「自動修復」ともいいます。このドキュメント内のアプリケーションのヘルスチェックに基づいて VM を修復するをご覧ください。
障害が発生した VM の自動修復
MIG で VM に障害が発生した場合、MIG では障害が発生した VM が再作成されて自動的に修復されます。VM では、次の理由で障害が発生する可能性があります。
- ハードウェア障害などの予期しない理由。
- MIG によって開始されていないアクション。
- Spot VM のプリエンプション。
- VM インスタンスがライブ マイグレーションに設定されていない場合のインフラストラクチャ メンテナンス イベント。
- VM インスタンスの [コンソール] ページ、
instancesgcloud CLI コマンド、またはinstancesAPI リソースを使用して VM に対して直接実行されるアクション。たとえば、instances.stopメソッドまたはgcloud compute instances stopコマンドを使用してグループ内の VM を停止すると、修復がトリガーされます。
MIG が VM を意図的に停止した場合（たとえばオートスケーラーが VM を削除した場合）、その VM は修復されません。
アプリケーションのヘルスチェックに基づいて VM を修復する
障害が発生した VM の自動修復に加えて、VM 上で動作しているアプリケーションがフリーズまたはクラッシュした場合や、メモリ不足になった場合に、VM の修復が必要になる場合があります。アプリケーションが期待どおりに応答していることを確認するために、アプリケーション ベースのヘルスチェックを構成できます。
アプリケーション ベースのヘルスチェックでは、MIG 内の各 VM のアプリケーションが期待どおりに応答していることを定期的に確認します。VM 上のアプリケーションが応答しない場合、MIG は VM を「異常」とマークします。MIG はその後、異常な VM を修復します。アプリケーションのヘルスチェックに基づいて VM を修復することを「自動修復」といいます。
MIG で VM のサブセットが継続して実行されるようにするため、グループ内のすべての VM が同時に自動修復されることはありません。これは、たとえば、誤ったヘルスチェックによって不要な修復がトリガーされる場合や、ファイアウォール ルールの構成ミスによってヘルスチェックが VM をプローブできない場合、ネットワーク接続やインフラストラクチャの問題で健全な VM が誤ってい異常と認識される場合に便利です。ただし、ゾーン MIG に VM が 1 つしかない場合や、リージョン MIG にゾーンあたり 1 つの VM しかない場合は、そのような VM が異常になると MIG によって自動修復されます。
自動修復ポリシー
各 MIG には自動修復ポリシーがあり、ヘルスチェックを構成し、初期遅延を設定することもできます。初期遅延は新しい VM が起動スクリプトを初期化して実行するのにかかる時間です。初期遅延タイマーは MIG が VM の currentAction フィールドが VERIFYING に変わると開始されます。VM の初期遅延期間中、MIG は VM が起動プロセス中にある可能性があるため、失敗したヘルスチェックを無視します。これにより MIG が VM を早期に再作成するのを防ぐことができます。初期遅延中にヘルスチェックが正常なレスポンスを受信した場合、起動プロセスが完了し、VM の準備が整っていることを示します。
自動修復ポリシーの構成の詳細については、アプリケーションのヘルスチェックと自動修復を設定するをご覧ください。
アプリケーションの健全性の変化をモニタリングする
MIG を対象としたアプリケーション ベースのヘルスチェックが構成済みである場合は、MIG 内の各 VM の健全性を確認できます。詳細については、ステータスの確認をご覧ください。
VM の健全性の変化をモニタリングすることもできます。詳細については、健全性の変更をモニタリングするをご覧ください。
料金
アプリケーション ベースのヘルスチェックを設定すると、デフォルトでは、マネージド インスタンスの健全性が変化するたびに、Compute Engine によってログエントリが書き込まれます。 Cloud Logging には毎月の無料割り当て量があり、この割り当て量を超過するとロギングのデータ量に応じて課金されます。コストが発生しないようにするには、健全性の変更ログを無効にしてください。
修復中の動作
以降のセクションでは、アプリケーションのヘルスチェックに基づく自動修復および修復中の動作について説明します。
修復に関する最新情報
デフォルトでは、修復中に MIG は VM の作成に使用した元のインスタンス テンプレートを使用して VM を再作成します。たとえば、VM が instance-template-a で作成された後、OPPORTUNISTIC モードで instance-template-b を使用するように MIG を更新した場合、MIG は引き続き instance-template-a を使用して VM を再作成します。
VM の修復中に、MIG に最新のインスタンス テンプレートとインスタンスごとの構成を使用する必要がある場合は、修復中に構成の更新を適用するようにグループを構成できます。
ディスクの取り扱い
修復中にテンプレートに基づいて VM を再作成する際、MIG の処理方法はディスクタイプごとに異なります。ディスク構成によっては、VM を再作成しようとしたときに修復が失敗することがあります。
| ディスクタイプ | autodelete |
修復中の動作 |
|---|---|---|
| 新しい永続ディスク | true |
インスタンス テンプレートの指定に従ってディスクが再作成されます。ディスクとその VM が再作成されると、過去にそのディスクに書き込まれたデータは失われます。 |
| 新しい永続ディスク | false |
MIG で VM が再作成される際、ディスクは保持され、再接続されます。 |
| 既存の永続ディスク | true |
元のディスクは削除されます。Compute Engine は削除されたディスクを VM に再度アタッチできないため、VM の再作成オペレーションは失敗します。ただし、既存の読み取り / 書き込みディスクでは、単一の永続ディスクを読み取り / 書き込みモードで複数の VM にアタッチできないため、MIG は 1 つの VM しか持つことができません。 |
| 既存の永続ディスク | false |
元のディスクは、インスタンス テンプレートで指定されたとおりに再度アタッチされます。ディスクのデータは保持されます。ただし、既存の読み取り / 書き込みディスクでは、単一の永続ディスクを読み取り / 書き込みモードで複数の VM にアタッチできないため、MIG は 1 つの VM しか持つことができません。 |
| 新しいローカル SSD | なし | インスタンス テンプレートの指定に従ってディスクが再作成されます。ローカル SSD のデータは、VM の再作成または削除の際に失われます。 |
MIG では、インスタンス テンプレートまたはインスタンスごとの構成で指定されていないディスク（VM の作成後に手動で VM にアタッチしたディスクなど）は再度アタッチされません。
ディスクに書き込まれた重要なデータを保持するには、次のような予防措置を講じます。
- 定期的に永続ディスクのスナップショットを作成します。
- データを別のソース（Cloud Storage など）にエクスポートします。
- ステートフル永続ディスクを構成します。
VM の重要な設定を保持する必要がある場合は、インスタンス テンプレート内のカスタム イメージを使用することをおすすめします。カスタム イメージには、必要なカスタム設定が含まれます。インスタンス テンプレートのカスタム イメージを指定すると、MIG は、必要なカスタム設定を含むカスタム イメージを使用して VM を再作成��ます。
修復を無効にする
MIG によって自動的に行われる修復をオフにできます。修復を無効にすると、障害が発生した VM の修復とアプリケーションのヘルスチェックに基づく修復が無効になります。
次のようなシナリオでは、MIG で修復を無効にすることをおすすめします。
- 自動修復による中断を発生��せ���こと����、障害が発生した VM �����査またはデバッグする。
- VM を手動で修復するか、独自の修復ロジックを実装する。
- バッチジョブの進行中に新しい VM が登録されないようにする。
- 異常な VM を修復せずにアプリケーションの健全性をモニタリングする。
- 修復が誤ってトリガーされることなく、ヘルスチェックの構成を微調整する。
修復を無効にすると、グループ内の VM に障害が発生したり、異常となった場合でも、MIG は何も実行しません。障害が起こった VM や異常な VM は引き続きグループに含まれ、MIG 内の実行中の VM のターゲット数（targetSize）は変わりません。
MIG の更新タイプが proactive に設定され、新しいインスタンス テンプレートが使用可能な場合、MIG は障害が発生した VM と異常な VM の更新を試みます。
アプリケーション ベースのヘルスチェックを構成している場合、修復を無効にしてもヘルスチェックの機能には影響しません。ヘルスチェックは引き続きアプリケーションをプローブし、VM の健全性を確認します。これにより、MIG が異常な VM を修復するのを防ぎながら、アプリケーションの健全性をモニタリングできます。
MIG がロードバランサのバックエンド サービスの一部であり、MIG で修復を無効にすると、修復されていない障害と異常な VM はロードバランサのヘルスチェックに応答しません。MIG 内の障害または異常な VM の数が増えると、ロードバランサはその MIG へのトラフィックを減らすか、別のバックエンド（構成されている場合）に切り替えることがあります。障害が発生した VM が再び使用可能になると、ロードバランサは MIG へのトラフィックを再開します。
詳細については、MIG の修復を無効にするをご覧ください。