--- title: "API7 Enterprise 3.2.9 の新機能：アップグレードされた Health Check 設定 - API7.ai" description: "在API7 Enterprise 3.2.9版本中，健康检查功能经过了全面优化，提供了更加直观和语义化的配置选项，帮助用户轻松管理上游节点，实现高效的负载均衡。" url: "https://api7.ai/ja/blog/api7-3.2.9-upgraded-health-check-configuration" --- [Blog](https://api7.ai/ja/blog) [Products](https://api7.ai/ja/category/products)[Technology](https://api7.ai/ja/category/technology)[Ecosystem](https://api7.ai/ja/category/ecosystem)[Case Study](https://api7.ai/ja/category/usercase)[Team & Community](https://api7.ai/ja/category/community) Search ⌘ + K [Blog](https://api7.ai/blog) Products # API7 Enterprise 3.2.9 の新機能：アップグレードされた Health Check 設定 [![Zhihuang Lin](https://github.com/oil-oil.png)](https://github.com/oil-oil) [Zhihuang Lin](https://github.com/oil-oil) April 16, 2024 [Products](https://api7.ai/category/products) ## 新ヘルスチェック機能の紹介 [API7 Enterprise](https://api7.ai/enterprise)のバージョン3.2.9では、ヘルスチェックの設定インタラクション体験が全面的に最適化されました。 1. 以前は散在していた設定項目が、プローブ設定や正常/異常ノードの判定基準など、論理的に集約され、**より構造化**されました。 2. 一部の抽象的な設定項目名が、**より直感的**で意味のある表現に変換され、ユーザーは穴埋め形式で関連パラメータを直接入力できるようになり、設定の実践的な効果をより明確に理解できるようになりました。 3. アップストリームノードとヘルスチェックプロセスの設定中に、より多くのプロンプトメッセージが追加され、ユーザーがアップストリームノードとヘルスチェックの内在的な関連性をよりよく理解し、設定タスクを**より簡単に**完了できるよう支援します。 ![API7 Enterprise 3.2.9のヘルスチェック設定比較](https://static.api7.ai/uploads/2024/04/16/bWfDV00e_3.2.9-health-check-1.png?imageMogr2/format/webp) ## ヘルスチェックの基本概念 API7 Enterpriseでは、アップストリームノードの優先度設定は、ロードバランシングとヘルスチェックのメカニズムと密接に関連しています。ユーザーがゲートウェイに異なる優先度を持つ複数のアップストリームノードを設定すると、ゲートウェイはロードバランシング中に最も優先度の高いノードを優先します。つまり、最も優先度の高いノードが正常である限り、ゲートウェイはこれらのノードにトラフィックをルーティングし続けます。 最も優先度の高いノードがすべてヘルスチェックの失敗により利用不能と判断された場合にのみ、ゲートウェイは自動的に降格し、トラフィックを次に優先度の高いアップストリームノードにリダイレクトします。この設計により、トラフィックの効率的な利用とシステムの高可用性が確保されます。 なお、サービスに複数の優先度レベルのアップストリームノードが設定されているが、ヘルスチェック機能が無効になっている場合、すべてのクライアントリクエストは、実際のヘルスステータスに関係なく、常に最も優先度の高いノードにルーティングされます。 ## ヘルスチェックの設定方法 ### プローブ設定 プローブは、アップストリームノードの活性とサービスステータスを検出するために使用されます。[APISIX](https://api7.ai/apisix)では、プローブは「検査官」のようなもので、定期的にドアをノックしてアップストリームサービスが正常に機能しているかどうかを確認します。問題が見つかった場合やサービスが「利用不能」である場合、APISIXに「このサービスは現在利用不能なので、ここにリクエストを送るのを控えてください」と通知します。この「ドアをノックする」プロセスは、プローブを通じて実行されます。 **プローブには主に以下の設定項目が含まれます：** ![API7 Enterprise 3.2.9のプローブ設定](https://static.api7.ai/uploads/2024/04/16/kCS79sWQ_3.2.9-health-check-2.png?imageMogr2/format/webp) - **プローブスキーム**: ヘルスチェックプローブが使用するプロトコルタイプで、TCP、HTTP、HTTPSをサポートします。 - **並行性**: この設定項目では、ヘルスチェックリクエストの並行数を設定できます。つまり、アップストリームサービスの応答性を確認するために同時に「ドアをノックする」回数を設定します。並行性を調整することで、実際のシナリオでの可能な並行リクエストをシミュレートし、アップストリームサービスのパフォーマンスと安定性をよりよく評価できます。 - **ホスト**: チェックするアップストリームサーバーのホストアドレスを指定します。これは、どの家の「ドアをノックする」かを決定するようなものです。 - **ポート**: アップストリームサービスのポート番号です。プローブ中にどのドアをノックするかを知るようなものです。 - **パス**: HTTPプローブを使用する場合、この設定項目はアクセスしたいURLパスを指定します。プローブに、中に入ったら正確な部屋をチェックするように指示するようなものです。 ### 正常ノードの判定基準 ![API7 Enterpriseの正常判定](https://static.api7.ai/uploads/2024/04/16/RAAxOPaF_3.2.9-health-check-3.png?imageMogr2/format/webp) 正常ノードの判定に関して、システムはユーザーが設定した間隔（秒単位）で、以前に異常とマークされたノードを定期的にチェックし、一時的なノード異常をタイムリーに検出して適切に処理できるようにします。 プローブがTCPプロトコルを使用する場合、プローブがユーザーが設定した回数だけアップストリームノードに正常に接続した後、ノードは正常と見なされます。 プローブがHTTP/HTTPSプロトコルを使用する場合、システムはノードから指定されたステータスコード（`200`や`302`など）を含むプローブリクエストを連続して受信した場合にのみ、ノードを正常と見なします。つまり、ノードがこれらの特定のステータスコードを連続して返す場合にのみ、ノードが正常に動作していると見なされます。 ### 異常ノードの判定基準 ![API7 Enterpriseの異常判定](https://static.api7.ai/uploads/2024/04/16/4GXUqB8C_3.2.9-health-check-4.png?imageMogr2/format/webp) 異常ノードの判定に関して、設定方法は正常ノードの判定と似ています。システムはユーザーが設定した間隔で、正常とマークされたノードを定期的にチェックします。これらのノードが事前に設定された異常条件を満たすと、再分類されて異常と見なされます。 正常ノードの判定とは少し異なり、異常ノードの判定プロセス中に、クライアントリクエスト検証という追加の設定項目が追加されます。この機能が有効になると、ゲートウェイはプローブの検査結果に依存するだけでなく、クライアントからのリクエストとアップストリームサービスの実際の応答を深く観察し分析します。これらのデータとユーザー定義の判定基準に基づいて、ゲートウェイはアップストリームサービスの実行ステータスをより正確に評価できます。 ## ヘルスチェックのベストプラクティス ### 適切なプローブタイプの選択 - **TCPプローブ**: サービスポートが開いているかどうか、アクセス可能かどうかの確認のみが必要なシナリオに適しています。例えば、データベースサービスでは、TCPプローブを使用してポートが開いていることを確認するだけで十分な場合があります。 - **HTTP/HTTPSプローブ**: ネットワーク接続が正常であるだけでなく、サービスがリクエストを正しく処理できることを確認する必要があるシナリオにより適しています。例えば、WebサーバーやAPIサービスの場合、接続を受け取るだけでなく、正しいページやデータを返すことができることを確認する必要があります。 ### ヘルスチェックの合理的なパラメータ設定 ヘルスチェックを設定する際には、いくつかの重要なパラメータに注意を払う必要があります： - **チェック間隔**: 短すぎると不要なオーバーヘッドが発生し、長すぎると問題が発生した場合の応答が遅くなります。例えば、高トラフィックのECサイトの場合、30秒ごとにチェックするのが比較的合理的な選択です。この間隔は、システムリソースを過度に消費せず、サイトの問題の検出と処理を遅らせません。 もちろん、この間隔は絶対的なものではなく、サイトの実際の状況に基づいて調整する必要があります。例えば、サイトのトラフィックが大きく変動する場合や特定の期間（プロモーションキャンペーン中など）にトラフィックが急増する場合、これらの変化に対応するためにチェック間隔を調整する必要があるかもしれません。 - **タイムアウト**: プローブがサービスの応答を待つ時間です。サービスがこの時間内に応答しない場合、プローブはサービスを異常と見なします。この値は、サービスの実際の応答時間に応じて設定する必要があります。 - **リトライ回数**: プローブがサービスを異常と判断する前に接続を試行する回数です。この値は適度である必要があり、誤判定を避けるために適切に設定する必要があります。 ### ビジネスに基づいた戦略の調整 ヘルスチェック戦略は、実際のビジネス状況に基づいて調整する必要があります。特定の時間帯にサービスが通常高い負荷を受ける場合、これらの期間中にヘルスチェック間隔を増やしたり、リトライ回数を減らしたりして、サービスに追加の圧力をかけないようにすることができます。 ### 適切なクライアントリクエスト検証の有効化 クライアントリクエスト検証は、実際のビジネスリクエストに基づいてサービスのステータスを効果的に判断できます。特に、ビジネスロジックに密接に関連する問題を特定するのに役立ちます。ただし、すべてのビジネスシナリオに適しているわけではありません。 1. **低トラフィックサービス**: サービストラフィックが低い場合、クライアントリクエストに基づく受動的なヘルスチェックでは、サービスのステータスを正確に評価するための十分なデータポイントが得られない可能性があります。このような場合、アクティブなプローブチェックに依存する方がより信頼性が高いかもしれません。 2. **高並行環境でのパフォーマンス考慮**: 受動的なヘルスチェックでは、すべてのクライアントリクエストを監視および処理する必要があり、高並行環境では追加のパフォーマンスオーバーヘッドが発生する可能性があります。パフォーマンスが主な懸念事項であり、他の手段でサービスが十分に監視されている場合、受動的なヘルスチェックを閉じることを検討できます。 3. **他の監視システムの存在**: 企業内ですでに成熟した監視システムが展開されており、サービスのステータスをリアルタイムで捕捉および分析できる場合、データの冗長性と追加の複雑さを避けるために、受動的なヘルスチェックは必要ないかもしれません。 ## 結論 [ヘルスチェック](https://api7.ai/blog/health-check-ensures-high-availability)は、APIゲートウェイの高可用性を確保するための重要な側面です。API7 Enterpriseのバージョン3.2.9では、ヘルスチェックのインタラクティブな設定を全面的に最適化し、操作を簡素化し、ユーザーエクスペリエンスを向上させました。 プローブを適切に設定し、正常/異常ノードの判定基準を設定し、実際のビジネスニーズに基づいて戦略を調整することで、ユーザーはアップストリームサービスのステータスをより効果的に監視し、トラフィックが常に正常なノードにルーティングされるようにすることができます。これにより、システムの安定性と可用性が向上し、ユーザーのリクエストがタイムリーかつ正確に応答されることが保証されます。 Tags: [API7 Enterprise](https://api7.ai/tags/api7-enterprise) [Health Check](https://api7.ai/tags/health-check) Share article link Share Related Posts [![API7 Enterprise v3.2.16.4 支持 Webhook/电子邮件警报通知](https://static.api7.ai/uploads/2024/11/14/MZsGTMyQ_alert.png)](https://api7.ai/blog/api7-3.2.16.4-supports-email-webhook-alert-notification) ## [API7 Enterprise v3.2.16.4 支持 Webhook/电子邮件警报通知](https://api7.ai/blog/api7-3.2.16.4-supports-email-webhook-alert-notification) [![API7 Enterprise v3.2.16.3 与 AWS Secrets Manager 集成](https://static.api7.ai/uploads/2025/02/13/nrkyTz2U_3.2.16.3-aws-secrets-manager.png)](https://api7.ai/blog/api7-3.2.16.3-supports-aws-secrets-manager) ## [API7 Enterprise v3.2.16.3 与 AWS Secrets Manager 集成](https://api7.ai/blog/api7-3.2.16.3-supports-aws-secrets-manager) Table of Contents - [新ヘルスチェック機能の紹介](#%E6%96%B0%E3%83%98%E3%83%AB%E3%82%B9%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E6%A9%9F%E8%83%BD%E3%81%AE%E7%B4%B9%E4%BB%8B) - [ヘルスチェックの基本概念](#%E3%83%98%E3%83%AB%E3%82%B9%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%81%AE%E5%9F%BA%E6%9C%AC%E6%A6%82%E5%BF%B5) - [ヘルスチェックの設定方法](#%E3%83%98%E3%83%AB%E3%82%B9%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95) - [プローブ設定](#%E3%83%97%E3%83%AD%E3%83%BC%E3%83%96%E8%A8%AD%E5%AE%9A) - [正常ノードの判定基準](#%E6%AD%A3%E5%B8%B8%E3%83%8E%E3%83%BC%E3%83%89%E3%81%AE%E5%88%A4%E5%AE%9A%E5%9F%BA%E6%BA%96) - [異常ノードの判定基準](#%E7%95%B0%E5%B8%B8%E3%83%8E%E3%83%BC%E3%83%89%E3%81%AE%E5%88%A4%E5%AE%9A%E5%9F%BA%E6%BA%96) - [ヘルスチェックのベストプラクティス](#%E3%83%98%E3%83%AB%E3%82%B9%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9) - [適切なプローブタイプの選択](#%E9%81%A9%E5%88%87%E3%81%AA%E3%83%97%E3%83%AD%E3%83%BC%E3%83%96%E3%82%BF%E3%82%A4%E3%83%97%E3%81%AE%E9%81%B8%E6%8A%9E) - [ヘルスチェックの合理的なパラメータ設定](#%E3%83%98%E3%83%AB%E3%82%B9%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF%E3%81%AE%E5%90%88%E7%90%86%E7%9A%84%E3%81%AA%E3%83%91%E3%83%A9%E3%83%A1%E3%83%BC%E3%82%BF%E8%A8%AD%E5%AE%9A) - [ビジネスに基づいた戦略の調整](#%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%81%AB%E5%9F%BA%E3%81%A5%E3%81%84%E3%81%9F%E6%88%A6%E7%95%A5%E3%81%AE%E8%AA%BF%E6%95%B4) - [適切なクライアントリクエスト検証の有効化](#%E9%81%A9%E5%88%87%E3%81%AA%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E6%A4%9C%E8%A8%BC%E3%81%AE%E6%9C%89%E5%8A%B9%E5%8C%96) - [結論](#%E7%B5%90%E8%AB%96) ## Related Posts [![API7 Enterprise v3.5.0：マルチアップストリーム構成](https://static.api7.ai/uploads/2025/02/19/mQ8cStKu_multi-upstream-configuration.png)](https://api7.ai/ja/blog/api7-3.5.0-mutli-upstream-for-traffic-management) Products February 19, 2025 #### [API7 Enterprise v3.5.0：マルチアップストリーム構成](https://api7.ai/ja/blog/api7-3.5.0-mutli-upstream-for-traffic-management) API7 Enterprise v3.5.0では、柔軟で信頼性の高いトラフィック管理を実現するためのマルチアップストリーム設定が導入されました。 [Traffic Managment](https://api7.ai/tags/traffic-managment) [API7 Enterprise](https://api7.ai/tags/api7-enterprise) [![API7 Enterprise v3.4.0：通过SNI简化证书管理](https://static.api7.ai/uploads/2025/02/13/Q7IIQt7d_sni-certificate-management.png)](https://api7.ai/ja/blog/api7-3.4.0-sni-certificate-management) Products February 13, 2025 #### [API7 Enterprise v3.4.0：通过SNI简化证书管理](https://api7.ai/ja/blog/api7-3.4.0-sni-certificate-management) API7 Enterprise v3.4.0では、直感的で効率的な証明書管理を実現するためのSNIリソース管理機能が導入されました。 [Certificate Management](https://api7.ai/tags/certificate-management) [API7 Enterprise](https://api7.ai/tags/api7-enterprise) [![API7 Enterprise v3.3.0 支持 API Portal](https://static.api7.ai/uploads/2024/12/26/y70oTHfl_api-portal-cover.png)](https://api7.ai/ja/blog/api7-3.3.0-api-portal) Products December 26, 2024 #### [API7 Enterprise v3.3.0 支持 API Portal](https://api7.ai/ja/blog/api7-3.3.0-api-portal) API7 Enterprise 支持 API Portal，提升 API 的可访问性，简化集成流程，并增强平台的 API 生命周期管理能力。 [API Portal](https://api7.ai/tags/api-portal) [API7 Enterprise](https://api7.ai/tags/api7-enterprise)