サービスのヘルスチェックを設定して、そのバックエンドサービスのステータスをモニターできます。サービスインスタンスノードが異常になった場合、オフラインにするか、隔離することができます。このプラクティスにより、サービスにルーティングされるインターフェイスの可用性が確保されます。また、パニックしきい値を設定して、極端な状況下でシステムの基本的なサービス能力を維持することもできます。このトピックでは、サービスヘルスチェック機能について説明し、その設定方法を解説します。
シナリオ
アクティブヘルスチェック: この機能は、個々の異常なインスタンスノードを自動的にオフラインにします。アクティブヘルスチェックは、TCP 接続や HTTP GET リクエストなどのリクエストを送信して、サービスノードが生存しているかどうかを調査し、その可用性を判断します。ノードは回復後に自動的にオンラインに戻ります。この機能は、バックエンドサービスが複数のレプリカでデプロイされている場合に、サービスにルーティングされるインターフェイスの可用性を向上させます。
パッシブヘルスチェック: この機能は、実際のトラフィックリクエストの失敗率に基づいて、ノードのヘルス状態を動的に分析します。ノードが高い失敗率を持つなど異常な動作をした場合、一時的に隔離されます。ノードは回復後に自動的に再度有効になります。
パニックしきい値: この機能は、システム負荷が増加したり、一部のノードが失敗した場合に、クラスター全体でのエラーの伝播を防ぎます。これにより、サービスのシステム的な障害を回避できます。
手順
サービスを作成すると、デフォルトで TCP ヘルスチェックが有効になります。
AI Gateway コンソールにログインします。
左側のナビゲーションウィンドウで、 をクリックします。上部のナビゲーションバーで、リージョンを選択します。
[インスタンス] ページで、管理したいゲートウェイインスタンスの ID をクリックします。
左側のナビゲーションウィンドウで、[サービス] をクリックします。次に、[サービス] タブをクリックします。
対象サービスの [アクション] 列で、[ヘルスチェック設定] をクリックします。関連するヘルスチェックタイプについて、[有効] を選択し、設定を完了します。
アクティブヘルスチェックの設定
[ヘルスチェックの設定] パネルで、[アクティブヘルスチェックを有効にする] スイッチをオンにし、パラメーターを設定してから、[OK] をクリックします。次の表に設定項目を示します。
設定項目
値の例
説明
ヘルスチェックプロトコル
HTTP
TCP ヘルスチェックは SYN ハンドシェイクメッセージを送信して、サーバーポートが生存しているかどうかを検出します。
HTTP ヘルスチェックは、ブラウザのアクセスをシミュレートするリクエストを送信して、サーバーアプリケーションが正常であるかどうかを確認します。
ヘルスチェックパス
/
ヘルスチェック用のページファイルの URI。チェックには静的ページを使用します。
正常ステータスコード
http_2xx
ヘルスチェックが成功したことを示す HTTP ステータスコード。
ヘルスチェック応答タイムアウト期間
2
各ヘルスチェック応答の最大タイムアウト期間。タイムアウトは異常なステータスを示します。
ヘルスチェック間隔
2
2 つの連続したヘルスチェックの時間間隔。
正常しきい値
2
異常な Elastic Compute Service (ECS) インスタンスが正常と見なされるために必要な、連続した成功したヘルスチェックの回数。
異常しきい値
2
正常な ECS インスタンスが異常と見なされるために必要な、連続した失敗したヘルスチェックの回数。
パッシブヘルスチェックの設定
[ヘルスチェックの設定] パネルで、[パッシブヘルスチェックを有効にする] スイッチをオンにし、パラメーターを設定してから、[OK] をクリックします。次の表に設定項目を示します。
設定項目
値の例
説明
失敗率のしきい値
80
ノードの失敗したリクエストの割合がこのしきい値に達すると、システムはそのノードの排除メカニズムをトリガーします。
検出間隔
30
システムは、30 秒ごとなど、指定された間隔でノードのリクエスト失敗率を計算します。
初期隔離期間
30
ノードが排除された後に隔離される初期期間 (30 秒など)。隔離期間は、数式 k × base_ejection_time を使用して計算されます。k の初期値は 1 です。各排除は k を増分することで隔離期間を延長します。連続したチェックが成功した場合、k を減分することで隔離期間は徐々に短縮されます。
説明パッシブヘルスチェック機能を使用するには、エンジンをバージョン 2.1.10 以降にスペックアップする必要があります。
パッシブヘルスチェックの構成を更新すると、パッシブヘルスチェックのステータスがリセットされ、隔離されたすべてのノードが再度有効になります。
パニックしきい値
パニックしきい値は、システム負荷が増加したり、一部のノードが失敗した場合に、クラスター全体でのエラーの伝播を防ぎます。これにより、サービスのシステム的な障害を回避できます。このメカニズムは、可用性と正確性のバランスを取り、極端な状況下で基本的なサービス能力を確保します。
動作は次のとおりです。
クラスター内の正常なノードの割合がパニックしきい値を上回る場合、ヘルスチェックメカニズムは期待どおりに機能します。リクエストは、正常とマークされたノードにのみルーティングされます。失敗したノードや排除されたノードは、トラフィックを受信しなくなります。
クラスター内の正常なノードの割合がパニックしきい値以下の場合、システムは「パニックモード」に入ります。ヘルスチェックメカニズムは一時的にバイパスされ、リクエストは異常または排除されたとマークされたノードを含むすべてのノードに均等に転送されます。
この構成は、多くのノードが異常になったときに、残りの少数の正常なノードがすべてのトラフィックで過負荷になるのを防ぐように設計されており、カスケード障害を回避するのに役立ちます。一部の「異常な」ノードへの呼び出しを再開することで、サービスの全体的なフォールトトレランスと可用性が向上します。
極端なシナリオでサービスの可用性を最大化するために、デフォルトのパニックしきい値は 1% に設定されています。正常なノードの割合がこのしきい値以下に低下すると、システムはパニックモードに切り替わり、すべてのノードにリクエストを転送します。
ビジネスシナリオとディザスタリカバリ能力に基づいて、このしきい値を調整できます。これにより、安定性とサービスの正確性の間で最適なバランスを達成できます。
ヘルスチェック例外のトラブルシューティング
一般的なヘルスチェック例外
トラブルシューティングを行うには、次のステップに従います。
TCP ヘルスチェックが失敗した場合、対応するノードとの接続を確立できないことを意味します。以下を確認してください。
ノードが存在するかどうか。
同時接続数が多すぎてノードが処理できないかどうか。
HTTP ヘルスチェックが失敗した場合は、TCP ヘルスチェックに切り替えて、接続を確立できるかどうかを確認します。TCP ヘルスチェックが成功した場合は、設定されたヘルスチェックパスが正しいことを確認します。curl や Postman などのツールを使用してアクセスをテストできます。
初めてサービスを追加するときのヘルスチェック例外
トラブルシューティングを行うには、次のステップに従います。
購入したゲートウェイの VPC がサービスインスタンスの VPC と同じであることを確認します。または、サービス環境が Cloud Enterprise Network (CEN) または専用回線を介してゲートウェイ VPC に接続されていることを確認します。VPC が異なり、接続されていない場合、ゲートウェイはインスタンスの IP アドレスにアクセスできません。
説明ゲートウェイは、Nacos および ZooKeeper インスタンスに登録されているオンプレミスサービスをサポートしていません。
ゲートウェイとサービスインスタンスが同じ VPC 内にあることを確認します。VPC が異なり、接続されていない場合、ゲートウェイはインスタンスの IP アドレスにアクセスできません。
セキュリティグループの権限付与が行われていることを確認します。サービスソースが ACK サービスの場合は、コンテナークラスターのセキュリティグループに権限を付与します。詳細については、「セキュリティグループルールを設定する」をご参照ください。
異常なインスタンスの IP アドレスがインターネット IP アドレスである場合は、ゲートウェイが存在する VPC でインターネット NAT ゲートウェイが有効になっているかどうかを確認します。