正常性エンドポイントの監視パターン

Traffic Manager
Monitor

公開されたエンドポイントを通じて外部ツールが定期的にアクセスできる機能チェックをアプリケーションに実装します。 これは、アプリケーションとサービスが正常に実行されていることを確認するのに役立ちます。

コンテキストと問題

Web アプリケーションとバックエンド サービスを監視して、それらが利用可能で正しく実行されるようにすることは、望ましい取り組みであり、多くの場合、ビジネスの要件でもあります。 しかし、ときにはクラウドで実行されているサービスを監視する方が、オンプレミスのサービスを監視するよりも難しいことがあります。 たとえば、ホスティング環境は完全に制御することができません。また、サービスは通常、プラットフォーム ベンダーなどが提供する他のサービスに依存しています。

クラウドでホストされているアプリケーションに影響する要素は、ネットワーク待ち時間、基盤となるコンピューティング システムおよびストレージ システムのパフォーマンスと可用性、それらの間のネットワーク帯域幅など、多数あります。 サービスは、これらの要素のいずれかが原因で、完全に失敗することもあれば、部分的に失敗することもあります。 そのため、必要なレベルの可用性が確保されるよう、サービスが正常に実行されていることを定期的に確認する必要があります。これは、場合によってはサービス レベル アグリーメント (SLA) に含まれています。

解決策

アプリケーションのエンドポイントに要求を送信して、正常性の監視を実装します。 アプリケーションによって必要なチェックが実行され、その状態を示す値が返されます。

通常、正常性の監視のチェックでは 2 つの要素が組み合わされます。

  • 正常性確認エンドポイントへの要求に応じて、アプリケーションまたはサービスによって実行されるチェック (ある場合)。
  • 正常性確認チェックを実行するツールまたはフレームワークによる結果の分析。

応答コードは、アプリケーションの状態のほか、必要に応じて、そのアプリケーションで使用されているコンポーネントまたはサービスの状態も示します。 待ち時間または応答時間のチェックは、監視ツールまたはフレームワークによって実行されます。 この図は、パターンの概要を示しています。

Overview of the pattern

アプリケーションの正常性監視コードによって実行されるその他のチェックには、以下があります。

  • クラウド ストレージまたはデータベースの可用性と応答時間のチェック。
  • アプリケーション内にあるその他のリソースやサービス、または他の場所にあるがアプリケーションで使用されるその他のリソースやサービスのチェック。

Web アプリケーションを監視するサービスとツールを利用できます。Web アプリケーションを監視するには、構成可能な一連のエンドポイントに要求を送信し、構成可能な一連のルールに基づいて結果を評価します。 システムでいくつかの機能テストを実行することだけが目的のサービス エンドポイントの作成は比較的簡単です。

監視ツールで実行できる一般的なチェックには、以下があります。

  • 応答コードの確認。 たとえば HTTP 応答 200 (OK) は、アプリケーションがエラーなしで応答したことを示します。 監視システムは、より包括的な結果が得られるように、他の応答コードをチェックする場合もあります。
  • 200 (OK) 状態コードが返された場合でもエラーを検出することを目的とした、応答の内容のチェック。 これにより、返された Web ページまたはサービスの応答の一部にのみ影響するエラーを検出できます。 たとえば、ページのタイトルのチェックや、正しいページが返されたことを示す特定のフレーズの検索です。
  • 応答時間の測定。この応答時間は、ネットワーク待ち時間とアプリケーションが要求の実行に要した時間を足した時間を指します。 値が大きくなると、アプリケーションまたはネットワークで新しく発生した問題を示唆している可能性があります。
  • アプリケーション外のリソースまたはサービスのチェック (グローバルなキャッシュからコンテンツを配信するためにアプリケーションで使用されているコンテンツ配信ネットワークなど)。
  • SSL 証明書の期限切れのチェック。
  • DNS の待ち時間およびエラーを測定することを目的とした、アプリケーションの URL に対する DNS 参照の応答時間の測定。
  • 正しいエントリを確保することを目的とした、DNS 参照によって返される URL の検証。 これは、DNS サーバーへの攻撃が成功して悪意のある要求リダイレクトが行われるのを防ぐうえで役に立ちます。

また、可能であれば、これらのチェックをさまざまなオンプレミスの場所またホストされた場所から実行し、応答時間の測定と比較を行うことも役立ちます。 理想的には、顧客に近い場所からアプリケーションを監視し、それぞれの場所からのパフォーマンスを正確に把握することが推奨されます。 チェック メカニズムの堅牢性を高めることができるうえ、アプリケーションのデプロイ場所を決定したり、それを複数のデータセンターにデプロイするかどうかを決定したりする際に、結果が役に立ちます。

またテストは、顧客が使用するすべてのサービス インスタンスに対して実行し、アプリケーションがすべての顧客に対して正常に動作していることを確認する必要があります。 たとえば、顧客のストレージが複数のストレージ アカウントに分散されている場合、監視プロセスではこれらをすべてチェックする必要があります。

問題と注意事項

このパターンの実装方法を決めるときには、以下の点に注意してください。

応答を確認する方法。 たとえば、アプリケーションが正常に動作していることを確認するには、200 (OK) 状態コードだけで十分でしょうか。 これは、アプリケーション可用性の最も基本的な基準であり、このパターンの最低限の実装である一方、アプリケーションの動作、傾向、問題発生の可能性に関する情報をほとんど提供してくれません。

アプリケーション用に公開されるエンドポイントの数。 1 つのアプローチとしては、アプリケーションによって使用されるコア サービス用に少なくとも 1 つのエンドポイントを公開し、優先度の低いサービス用に別のエンドポイントを公開する方法があります。これにより、それぞれの監視結果に異なる重要度を割り当てることができます。 また、監視の粒度を高めるために、(コア サービスごとに 1 つなど) 公開するエンドポイントを増やすことも検討します。 たとえば、正常性確認チェックでは、アプリケーションで使用されるデータベース、ストレージ、外部のジオコーディング サービスをチェックする場合があります。これらはそれぞれ、異なるレベルのアップタイムと応答時間が必要とされています。 ジオコーディング サービスやその他のバックグラウンド タスクが数分間利用できない場合でも、アプリケーションは依然として正常である可能性があります。

一般的なアクセスに使用されているのと同じエンドポイントを監視に使用するかどうか (ただし、その場合は、一般的なアクセスのエンドポイント上に、正常性確認チェック用に設計された特定のパス (/health など) を設定する)。 これにより、一般のアクセス エンドポイントが利用可能であることを確認しながら、監視ツールでアプリケーションの一部の機能テストを実行できます (新しいユーザー登録の追加、サインイン、テストの注文など)。

監視要求に応じてサービスで収集される情報の種類と、その情報を返す方法。 ほとんどの既存のツールとフレームワークでは、エンドポイントから返された HTTP 状態コードしか表示されません。 その他の情報が返されて確認できるようにするには、カスタム監視ユーティリティまたはサービスの作成が必要な場合があります。

収集する情報の量。 チェック中に過剰な処理を実行すると、アプリケーションのオーバーロードが発生し、他のユーザーに影響が及ぶ可能性があります。 所要時間が監視システムのタイムアウト時間を超える場合があり、そうなると、アプリケーションが利用不可としてマークされます。 ほとんどのアプリケーションには、パフォーマンスと詳細なエラー情報を記録するエラー ハンドラーやパフォーマンス カウンターなど、インストルメンテーションが備わっています。正常性確認チェックで追加の情報が返されるようにしなくても、それで十分な場合があります。

エンドポイントの状態のキャッシュ。 正常性チェックを実行する頻度が高すぎると、コストが高くなる可能性があります。 たとえば、ダッシュボードを介して正常性の状態が報告される場合、ダッシュボードへの要求ごとに正常性チェックをトリガーすることは好ましくありません。 その代わり、定期的にシステムの正常性をチェックし、状態をキャッシュします。 キャッシュされた状態を返すエンドポイントを公開します。

パブリック アクセスから保護するために、監視エンドポイントのセキュリティを構成する方法。パブリック アクセスでは、アプリケーションが悪意のある攻撃にさらされる、機密情報の漏洩のリスクが生じる、サービス拒否 (DoS) 攻撃が誘発されるといった可能性があります。 これは通常、アプリケーションを再起動せずに簡単に更新できるよう、アプリケーション構成で行う必要があります。 以下の手法を 1 つ以上使用することを検討してください。

  • 認証を要求することでエンドポイントをセキュリティで保護する。 これを行うには、監視サービスまたは監視ツールで認証がサポートされているという条件で、要求ヘッダーで認証セキュリティ キーを使用するか、要求と共に資格情報を渡します。

    • 不明瞭なエンドポイントまたは非表示のエンドポイントを使用する。 たとえば、別の IP アドレスのエンドポイントを既定のアプリケーション URL で使用される IP アドレスに公開したり、非標準の HTTP ポートでエンドポイントを構成したり、テスト ページに複雑なパスを使用したりします。 通常、アプリケーション構成で追加のエンドポイント アドレスとポートを指定できます。また必要な場合は、IP アドレスを直接指定しなくてもよいように、これらのエンドポイントのエントリを DNS サーバーに追加できます。

    • キー値や操作モード値などのパラメーターを受け入れるメソッドをエンドポイントで公開する。 このパラメーターに指定された値に応じて、要求が受信された際に、コードは特定のテストまたは一連のテストを実行できます。また、パラメーター値が認識されない場合は 404 (見つかりません) エラーが返されます。 認識されるパラメーター値は、アプリケーション構成で設定できます。

      アプリケーションの操作が損なわれることなく基本的な機能テストが実行される別個のエンドポイントへの影響は、多くの場合、DoS 攻撃の及ぼす影響が少なくなります。 機密情報の漏洩につながる可能性のあるテストの使用は避けるのが理想的です。 攻撃者にとって有益な情報を返す必要がある場合は、エンドポイントとデータを未承認のアクセスから防ぐ方法を検討してください。 この場合、不明瞭さに依存するだけでは不十分です。 サーバーの負荷を増加させることになりますが、HTTPS 接続の使用と機密データの暗号化も検討する必要があります。

  • 認証を使用してセキュリティで保護されたエンドポイントにアクセスする方法は、正常性チェック エンドポイントとそれを使用するものを評価するときに考慮する必要があるポイントです。 一例として、App Service の組み込み正常性チェックは、App Service の認証および承認機能と統合されます。

監視エージェントが正しく実行されるようにする方法。 1 つの手法として、アプリケーション構成からの値、またはエージェントのテストに使用できるランダムな値を返すだけのエンドポイントを公開します。

また、誤検知の結果の発行を防ぐため、監視システムでそれ自体のチェック (自己テストや組み込みのテストなど) が実行されるようにします。

このパターンを使用する状況

このパターンは次の目的に役立ちます。

  • Web サイトと Web アプリケーションを監視して可用性を確認する。
  • Web サイトと Web アプリケーションを監視して動作の正常性をチェックする。
  • 中間層または共有のサービスを監視し、他のアプリケーションを中断させる可能性があるエラーを検出して分離する。
  • アプリケーションの既存のインストルメンテーション (パフォーマンス カウンターやエラー ハンドラーなど) を補完する。 正常性確認チェックは、アプリケーションのログと監査に関する要件に代わるものではありません。 インストルメンテーションからは、エラーやその他の問題を検出するためにカウンターとエラー ログを監視する既存のフレームワークに関して、有益な情報を提供できます。 しかし、アプリケーションが利用できない場合、情報は提供できません。

ASP.NET の正常性チェックは、ミドルウェアと、アプリ インフラストラクチャ コンポーネントの正常性を報告するための一連のライブラリです。 これによって一貫性のある方法で正常性チェックを報告するためのフレームワークが提供されて、前述の多くの手法が実装されます。 これには、データベース接続などの外部チェックや、liveness probe や readiness probe などの特定の概念が含まれます。

GitHub logoGitHub には、ASP.NET の正常性チェックを使用した多くの実装例があります。

Azure でホストされているアプリケーションのエンドポイントの監視

Azure アプリケーションのエンドポイントの監視には、いくつかのオプションがあります。

  • Azure の組み込みの監視機能を使用する。

  • サードパーティのサービスまたはフレームワークを使用する (Microsoft System Center Operations Manager など)。

  • 独自のサーバーまたはホストされているサーバーで実行されるカスタム ユーティリティまたはサービスを作成する。

    Azure には、かなり包括的な一連の監視オプションが用意されていますが、さらに情報を得るために、その他のサービスとツールを使用できます。 Azure Monitor の機能である Application Insights は、開発チームがアプリのパフォーマンスや使用状況を把握するのに役立ちます。 要求レート、応答時間、エラー率、依存関係率が監視され、外部のサービスによって処理速度が低下しているかどうかを知ることができます。

監視できる条件は、アプリケーション用に選択したホスティング メカニズムによって異なりますが、そのいずれにも、サービスの設定に指定した Web エンドポイントを使用するアラート ルールを作成する機能が含まれています。 アプリケーションが正常に動作していることをアラート システムが検出できるように、このエンドポイントは迅速に応答する必要があります。

詳細については、アラート通知の作成に関するページを参照してください。

大規模な停止が発生した場合、クライアント トラフィックは、他のリージョンまたはゾーンで使用可能なアプリケーション デプロイにルーティングできる必要があります。 これは最終的に、アプリケーションが内部または外部、あるいはその両方に接続されているかどうかに応じて、クロスプレミス接続とグローバル負荷分散を使用する必要がある場所です。 Azure Front Door、Azure Traffic Manager、または CDN などのサービスでは、正常性プローブを介して提供されるアプリケーションの正常性に基づいて、リージョン間でトラフィックをルーティングできます。

Azure Traffic Manager は、さまざまなルールと設定に基づいてアプリケーションの特定のインスタンスに要求を分散できるルーティングおよび負荷分散サービスです。 Traffic Manager は要求をルーティングするほか、指定された URL、ポート、相対パスに対して定期的に ping を実行します。これにより、ルールで定義されたアプリケーションのインスタンスのうち、どれがアクティブであり、要求に応答しているのかを特定します。 状態コード 200 (OK) が検出されると、アプリケーションは利用可能としてマークされます。 他のいずれかの状態コードの場合は、アプリケーションはオフラインとしてマークされます。 状態は Traffic Manager コンソールで確認できます。また、応答中の他のアプリケーション インスタンスに要求を再ルーティングするようルールを構成できます。

ただし、Traffic Manager では、監視対象の URL からの応答を受け取るために特定の時間しか待機しません。 そのため、この時間内に正常性確認コードが実行されるようにする必要があります。そうすることで、Traffic Manager とアプリケーションの間のラウンド トリップのネットワーク待ち時間に対応できます。

次のガイダンスは、このパターンを実装する際に役に立ちます。