アクティブまたはパッシブヘルスチェック: あなたにぴったりなのはどれですか?

健康を維持するために医師による定期的な健康診断が重要であるのと同様に、アプリの状態を定期的にチェックすることは、信頼性の高いパフォーマンスを維持するために不可欠です。 NGINX は、リバース プロキシとトラフィックの負荷分散を行う際に、パッシブ ヘルス チェックを使用して、リクエストに応答しないサーバーからトラフィックを自動的に迂回させることで、アプリケーション ユーザーを停止から保護します。 NGINX Plus はアクティブ ヘルス チェックを追加し、リクエストの処理に失敗する前でも不健全なサーバーを検出できる特別なプローブを送信します。 どのタイプのヘルスチェックがアプリケーションに適していますか? この投稿では、その決定を下すために必要な情報を提供します。

健康診断とは何ですか?

最も基本的な意味では、ヘルス チェックとは、サーバーがトラフィックを処理できるかどうかを判断する方法です。 NGINX はヘルス チェックを使用して、リバース プロキシまたはトラフィックの負荷分散を行っているサーバー (アップストリーム サーバーと呼ばれる) を監視します。

パッシブヘルスチェック

パッシブ ヘルス チェックは、NGINX Open Source と NGINX Plus の両方で利用可能で、接続とトラフィックの処理中にサーバーがどのように動作するかを観察することに依存しています。 NGINX は、サーバーが正常でないことを検出すると、すぐにリクエストを別のサーバーに転送し、異常なサーバーへのリクエストの送信を停止し、今後のリクエストを上流グループ内の残りの正常なサーバーに分散するため、サーバーのタイムアウトによる停止をユーザーが経験するのを防ぐのに役立ちます。

パッシブ ヘルス チェックは、アップストリーム グループに複数のメンバーが定義されている場合にのみ有効であることに注意してください。 アップストリーム サーバーが 1 つだけ定義されている場合、そのサーバーは利用不可としてマークされることはなく、サーバーが正常でない場合にユーザーには停止が表示されます。

パッシブヘルスチェックの仕組み

ここではパッシブ ヘルス チェックの仕組みについて詳しく説明しますが、興味がない場合はアクティブ ヘルス チェックに進んでください。

デフォルトでは、NGINX は、TCP/UDP (ストリーム) サーバーとの接続を確立中に単一のエラーまたはタイムアウトが発生した場合、そのサーバーを異常と見なします。

NGINX は、HTTP サーバーとの接続を確立しているとき、HTTP サーバーにリクエストを渡しているとき、またはレスポンス ヘッダーを読み取っているときにエラーまたはタイムアウトが 1 つでも発生すると、 HTTP サーバーが正常でないと見なします (レスポンスがまったく受信されない場合もこのタイプのエラーとしてカウントされます)。 proxy_next_upstreamディレクティブを使用して、 HTTPプロキシのこれらの条件をカスタマイズできます。また、 FastCGI 、 gRPC 、 memcached 、 SCGI 、 TCP/UDP 、およびuwsgiプロトコル用の並列ディレクティブがあります。

HTTP と TCP/UDP の両方において、NGINX は、正常でないサーバーに再度接続してリクエストを送信する前に、デフォルトで 10 秒間待機します。 この時間を変更するには、サーバーの [ HTTP ][ Stream ]ディレクティブのfail_timeoutパラメータを使用できます。

serverディレクティブのmax_failsパラメータを使用すると、NGINX がサーバーを異常と判断するために発生する必要があるエラーまたはタイムアウトの数を増やすことができます。この場合、 fail_timeoutパラメータは、その数のエラーまたはタイムアウトが発生する必要がある期間と、NGINX がサーバーを異常とマークした後に再試行するまでの待機時間を設定します。

アクティブヘルスチェック

アクティブ ヘルス チェック (NGINX Plus 専用) は、アプリケーション エンドポイントが正しく応答していることを確認するために定期的に送信される特別なリクエストです。 これらはパッシブ ヘルス チェックとは別個のものであり、パッシブ ヘルス チェックに追加されるものです。 たとえば、NGINX Plus は、有効な応答コードと正しいコンテンツで応答することを確認するために、アプリケーションの Web サーバーに定期的に HTTP リクエストを送信する場合があります。 アクティブ ヘルス チェックにより、特定のアプリケーション コンポーネントとプロセスのヘルスを継続的に監視できます。 これはアプリケーションの可用性を直接測定するものですが、指定されたヘルスチェックがアプリケーション全体のヘルスをどの程度代表しているかによって異なります。

アクティブ ヘルス チェックのさまざまな側面をカスタマイズできます。 「アクティブ ヘルス チェックのユース ケース」を参照してください。

パッシブヘルスチェックのユースケース

パッシブヘルスチェックは必須です。 すべてのアプリケーション開発、DevOps、DevSecOps、プラットフォーム運用チームにとって、運用インフラストラクチャの監視プログラムの一環としてパッシブヘルスチェックを実行することがベストプラクティスです。 NGINX は、HTTP、TCP、UDP 構成を含む、負荷分散されたトラフィックに対してデフォルトでパッシブ ヘルス チェックを実行します。

パッシブヘルスチェックの利点は次のとおりです。

• NGINXオープンソースで利用可能
• アップストリーム{}構成ブロックに含まれるサーバーではデフォルトで有効になります
• 上流サーバーに追加の負荷がかからない
• パッシブヘルスチェックの仕組みで説明されているように、一定期間内の失敗の最小数に関して設定可能
• 設定可能なスロースタート（NGINX Plus 限定） - サーバーが正常に戻ると、NGINX Plus は転送されるトラフィックの量を徐々に増やし、「ウォームアップ」の時間を与えます。

NGINX オープンソースの利点は、コスト (当然ですが無料)、構成可能性、およびサードパーティ モジュールの膨大なライブラリです。 ソース コードが公開されているため、開発者は特定のニーズに合わせて機能を変更および拡張できます。

多くのアプリケーション (およびその開発者) にとっては、パッシブ ヘルス チェックで十分です。 たとえば、顧客と直接やり取りせず、より小さなタスクを実行するマイクロサービスの場合、アクティブなヘルスチェックは過剰になる可能性があります。 同様に、キャッシュによってレイテンシの問題が発生する可能性が低減されるアプリケーションや、コンテンツ配信ネットワーク (CDN) がアプリケーション タスクの一部を引き継ぐことができるアプリケーションでは、キャッシュは必要ない場合もあります。 要約すると、パッシブヘルスチェックのみの場合、次の場合に最適です。

• HTTPトラフィックの監視
• アプリケーションとは別にインフラストラクチャを監視する
• 遅延が許容されるアプリケーションの監視
• 高いパフォーマンスが重要でない内部アプリケーションの監視

アクティブヘルスチェックのユースケース

ミッションクリティカルなアプリケーションの場合、顧客と主要プロセスが問題によって直接影響を受けるため、アクティブなヘルスチェックが重要になることがよくあります。 これらのアプリケーションでは、基本的にアプリケーションの顧客または消費者と同じようにアプリケーションをテストすることが重要であり、そのためにはアクティブなヘルス チェックが必要です。 アクティブ ヘルス チェックは、アウトオブバンドチェックを使用してアプリケーションのレイテンシと応答を測定する、New Relic や AppDynamics などのアプリケーション パフォーマンス監視ツールに似ています。 アクティブ ヘルス チェックについては、NGINX Plus には NGINX Open Source には含まれていない多くの機能が含まれています。

• アプリケーションの可用性に関する帯域外ヘルスチェック
• 設定されたエンドポイントをテストし、特定の応答を探す
• 実際のアプリケーショントラフィックを処理するポートとは異なるポートをテストする
• ヘルスチェック用のキープアライブ HTTP 接続により、チェックごとに新しい接続を設定する必要がなくなります。
• 不合格と合格の条件をより細かく制御
• オプションで、新しく追加されたサーバーを実際のアプリケーショントラフィックを受信する前にテストします。

アクティブ ヘルス チェックを使用すると、開発者は NGINX Plus を設定して、バックエンド サーバーがダウンしているか問題が発生している場合に自動的に検出し、問題が解決するまでトラフィックを正常なサーバーにルーティングできます。 アクティブ ヘルス チェックの構成可能性が広がることで、より高度なヘルス チェックを実行できるようになり、実際のアプリケーション ユーザーに影響が及ぶ前にアプリケーションの問題を検出できるようになります。 これにより、ダウンタイムを最小限に抑え、ユーザーによるアプリケーションへのアクセスの中断を防ぐことができます。

ヘルスチェックの設定方法

パッシブ ヘルス チェックはデフォルトで有効になっていますが、 「パッシブ ヘルス チェックの仕組み」で説明されているように、パッシブ ヘルス チェックの頻度と、サービスが異常とマークされるまでに発生する障害の数をカスタマイズできます。 パッシブ ヘルス チェックとアクティブ ヘルス チェックの両方の完全な構成手順については、次のドキュメントを参照してください。

• HTTP ヘルスチェック
• TCPヘルスチェック
• UDPヘルスチェック
• gRPC ヘルスチェック

結論： アプリケーション要件に合ったヘルスチェックを選択する

ヘルス チェックは、運用アプリケーションをスムーズかつ応答性の高い状態で実行し続けるための重要な要素です。 これらは、エンド ユーザーに影響が及ぶ前に問題を検出し、レイテンシの増加の原因を特定するための最良の方法です。 多くのアプリケーションでは、パッシブヘルスチェックで十分です。

ユーザー レベルでのアプリケーションの動作を直接把握する必要がある、より重要なアプリケーションの場合は、アクティブ チェックの方が適しています。 NGINX Open Source は無料で使用でき、設定可能なパッシブ ヘルス チェックを提供します。 NGINX Plus は、高度なアクティブ ヘルス チェック機能と商用サポートを提供します。

NGINX Plus でアクティブヘルスチェックを試してみませんか? 今すぐ30 日間の無料トライアルを開始するか、使用事例についてご相談ください。