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