アプリケーションとサービスを継続的に監視する
このユニットでは、次のことを学習します。
- "継続的監視" がアプリケーションとインフラストラクチャの正常性、パフォーマンス、および信頼性の検証にどのように役立つか。
- "可観測性" によって、監視する必要があるシステムからデータがどのように利用可能になるか。
- Azure Monitor と Application Insights を使用して継続的監視をどのように実装できるか。
- チケット発行システムを実装するために IT Service Management Connector がどのように役立つか。
継続的監視とは
チームはベータ テスト中に Web サイトとインフラストラクチャを監視する必要があります。 Tim はある程度の調査を行い、いくつかのことがわかりました。
"継続的監視" とは、アプリケーションのライフサイクルの各フェーズを監視するために使用できるプロセスとテクノロジのことです。 継続的監視は、変更が開発から運用へ移行するにつれて、アプリケーションとインフラストラクチャの正常性、パフォーマンス、信頼性を検証するのに役立ちます。
継続的監視は CI/CD の概念に基づいており、ユーザーに継続的価値を提供するために、ソフトウェアの開発と提供をより迅速かつ信頼性の高い方法で実施するのに役立ちます。
可観測性とは
"可観測性" は、監視するシステム内からデータを使用できるようにすることを意味します。 監視は、このデータを収集して表示する実際のタスクです。
Azure Monitor とは
Azure Monitor は、クラウドおよびオンプレミス両方のアプリケーションとインフラストラクチャの全体にわたって、フルスタックの可観測性を提供する Azure 内のサービスです。
Azure Monitor は Visual Studio や Visual Studio Code などの開発ツールと連携し、開発およびテスト フェーズで使用できます。 Azure DevOps と統合して、デプロイ フェーズ中のリリース管理と作業項目管理に使用できます。
Azure Monitor は、IT サービスマネジメント (ITSM) およびセキュリティ情報イベント管理 (SIEM) ツールと統合して、既存の IT プロセス内の問題とインシデントを追跡するのにも役立ちます。
アプリケーションに対する監視を有効にする
アプリケーションは複雑であり、多数のコンポーネントが相互接続されています。 すべてのシステムにおけるエンドツーエンドのトランザクションと接続を視覚化するには、すべての Web アプリケーションとサービスに対する監視を有効にする必要があります。
Azure DevOps に既存のプロジェクトがない場合は、Azure Developer CLI から始めることができます。 Azure Developer CLI (azd) はオープンソースのツールであり、アプリケーションをローカル開発環境から Azure に移動させるのにかかる時間を短縮することができます。 azd には、作業環境がターミナル、エディターや統合開発環境 (IDE)、CI/CD (継続的インテグレーションと継続的デプロイ) のいずれであっても、ワークフローの主要なステージに対応した、開発者が使いやすいベスト プラクティスのコマンドが用意されています。
その後、Azure Pipelines と Azure Application Insights を組み合わせることにより、リリース パイプラインに継続的監視を追加することができます。 Application Insights は、ライブ アプリケーションの監視に使用できる Azure Monitor の機能です。 Application Insights については、後ほど詳しく説明します。
インフラストラクチャ全体に対する監視を有効にする
アプリケーションの信頼性が、その基になるインフラストラクチャの信頼性を超えることはありません。 インフラストラクチャ全体での監視を有効にすると、完全な可観測性の実現に役立ち、何らかの障害が発生した場合に根本原因を見つけやすくなります。
Azure Monitor は、仮想マシン、コンテナー、ストレージ、ネットワークを含めたハイブリッド インフラストラクチャ全体の正常性とパフォーマンスの追跡に役立ちます。
次のものを Azure Monitor で収集できます。
- 使用しているほとんどの Azure リソースからのプラットフォーム メトリック、アクティビティ ログ、診断ログ (追加の構成は必要ありません)。
- VM の監視データ。 (VM に対する Azure Monitor)
- AKS クラスターの監視データ。 (Azure Monitor for containers)
"コードとしてのインフラストラクチャ" を使うと、アプリケーションに必要なインフラストラクチャを、コードによって記述できます。 コードを使用してインフラストラクチャを記述するので、DevOps チームがアプリケーションに使用するのと同じ開発、テスト、バージョン管理のスキームに従うことができます。
コードとしてのインフラストラクチャのアプローチを使って監視を有効にするには、以下のものを使用できます。
- Resource Manager テンプレートで多数のリソースに対して監視を有効にし、アラートを構成します。
- Azure Policy でリソースに対してさまざまなルールを適用します。 Azure Policy を使用すると、リソースを会社の標準とサービス レベル アグリーメント (SLA) に準拠した状態に確実に維持することができます。
Azure リソース グループを使用してリソースを結合する
Azure 上の一般的なアプリケーションには、仮想マシン、Azure App Service、マイクロサービス、Azure Kubernetes Service (AKS) クラスター、Azure Service Fabric などのコンピューティング リソースが含まれています。 これらのアプリケーションは、Azure Event Hubs、Azure Storage、Microsoft SQL Database、Azure Service Bus などのデータおよびネットワーク サービスに依存していることがよくあります。
Azure の "リソース グループ" には、関連する Azure リソースが保持されます。 リソースを組み合わせてリソース グループにすることで、さまざまなアプリケーションを構成するすべてのリソース全体での完全な可観測性が得られます。 リソース グループの Azure Monitor には、アプリケーション全体の正常性とパフォーマンスを追跡する基本的な方法が用意されていて、個々のコンポーネントにドリルダウンして障害のトラブルシューティングを行うことができます。
継続的デプロイによって品質を確保する
CI/CD を使用すると、自動テストの結果に基づいて、コードの変更をアプリケーションに自動的に統合してデプロイできます。 CI/CD を使用することで、デプロイ プロセスを効率化し、変更を運用環境に移行する前にコードの品質を検証できます。
デプロイ プロセス中に品質を確保するために推奨される方法をいくつか次に示します。
Azure Pipelines を使用して、コードをコミットした時点から運用に至るまでの、自動テストの実行を含むプロセス全体を自動化する CI/CD パイプラインを実装します。
デプロイ ゲートを使用して、デプロイ前とデプロイ後の環境に監視を追加します。
デプロイ ゲートは、アプリケーションが開発から運用に移行するときに、主要な正常性とパフォーマンスのメトリック (KPI) を確実に満たすために役立ちます。 また、デプロイ ゲートは、インフラストラクチャ環境における違いやスケーリング方法が KPI に悪影響を及ぼさないようにすることにも役立ちます。
開発、テスト、ステージング、運用など、さまざまなデプロイ環境の間で個別の監視インスタンスを維持します。
個別の監視インスタンスを使用すると、収集されるデータがアプリケーションとインフラストラクチャ全体で関連付けられます。 環境をまたいでデータを相互に関連付ける必要がある場合は、メトリックス エクスプローラーの複数のリソース グラフを使うか、Log Analytics のクロスリソース クエリを作成することができます。
対処できるアラートを作成する
監視作業を確実に効果的なものにするには、アクティブな問題に加えて、発生が予想される問題を管理者に通知する必要があります。 これを実現するには、次のような方法があります。
予測可能な障害状態を特定するために、ログとメトリックに基づいて Azure Monitor のアラートを作成します。
各アラートは、対処可能な重大な状態を反映したものである必要があります。 実際に存在しない問題が監視によって報告されると、"偽陽性" が発生します。 独自の静的しきい値を定義するよりも、動的しきい値を使用して、メトリック データのベースラインを自動的に計算します。
管理者に最も効果的に通知できるようにアラートのアクションを定義します。
通知に使用できるアクションには、ショート メッセージ サービス (SMS)、電子メール、プッシュ通知、音声通話などがあります。
より高度なアクションを使用し、Webhook を通じて、お使いの ITSM ツールや他のアラート管理システムに接続します。
Azure Automation Runbook または Webhook を使用してアラート状態を修復します。
自動スケーリングを使用して、収集したメトリックに基づいてコンピューティング リソースを動的に調整します。
ダッシュボードとブックを作成する
開発と運用のそれぞれのチームが同じテレメトリとツールにアクセスできるようにすることで、環境全体のパターンを把握できるようにし、"平均検出時間" (MTTD) と "平均復元時間" (MTTR) を最小限に抑えることができます。 これを行うには、次のような方法があります。
ご自身の組織内のさまざまな役割のために、一般的なメトリックとログに基づくカスタム ダッシュボードを作成します。
複数の Azure リソースからのデータをダッシュボードでまとめることができます。
開発と運用のチーム間で知識を共有するために Azure Monitor ブックを作成します。
ブックは、グラフとログの概要を含む動的レポートとして準備できます。 開発者は、カスタマー サポートまたは運用部門による問題のトラブルシューティングに役立つトラブルシューティング ガイドを作成できます。
継続的に最適化する
監視は、よく知られた "Build - Measure - Learn (構築 - 計測 - 学習)" という理念の基本的な側面の 1 つです。それによると、KPI とユーザーの行動のメトリックを継続的に追跡し、反復的な計画の実施を通してそれらを最適化することが推奨されています。 Azure Monitor を使用すると、ビジネスに関連するメトリックとログを収集し、次回デプロイ時に新しいデータ ポイントを追加できます。
- Application Insights のツールを使用して、エンドユーザーの行動とエンゲージメントを追跡します。
- 影響分析を使用して、最も重要な KPI を改善するためにどの分野に注力すべきかの優先度付けを行います。
Azure Application Insights とは何か
Application Insights は、Web 開発者向けのアプリケーション パフォーマンス管理 (APM) サービスです。 これを使用すると、次のことができます。
- ライブ Web アプリケーションを監視する。
- パフォーマンスの異常を自動的に検出する。
- エラーを診断し、ユーザーがアプリケーションで実際に何を実行しているかを把握する。
Application Insights は、.NET、Node.js、Java、その他多くのプログラミング言語とフレームワークに対応しています。 クラウドまたはオンプレミスでホストされているアプリケーションに使用できます。
Application Insights には、既存の DevOps プロセスやツールとの統合に使用できる接続ポイントが用意されています。 Application Insights は Visual Studio App Center とも連携しており、お使いのモバイル アプリケーションからテレメトリを監視および分析することができます。
Application Insights のしくみ
まず、小さなインストルメンテーション パッケージをアプリケーションに追加します。 次に、Azure portal で Application Insights リソースを作成します。 そのインストルメンテーションによってアプリを監視し、テレメトリ データを Azure に送り返します。それにポータルからアクセスできます。 アプリケーションはどこで実行されていてもかまわないことに注意してください。Azure でホストされている必要はありません。
Web アプリケーションに加えて、ほぼすべての種類のバックグラウンド コンポーネントをインストルメント化することができます。 JavaScript コードをインストルメント化することもできます。
次の図は、ライブ サービスから Application Insights への監視データのフローを示しています。 Application Insights を使用すれば、傾向を視覚化して把握できるように、アラートを生成したり、別のツールにデータをプッシュしたりできます。
また、ホスト環境からテレメトリ データをプルすることもできます。 このデータには、パフォーマンス カウンター、Azure Diagnostics、および Docker のログが含まれます。 また、"統合監視" テストを設定することもできます。 統合監視とは、一連のトランザクションを使用してパフォーマンスと可用性を評価するものです。 代理トランザクションは、リリースごとに結果を比較できる予測可能なテストです。
オーバーヘッドとは 一般的にアプリのパフォーマンスへの影響はわずかです。 追跡呼び出しは非ブロッキングであり、バッチ処理され、別のスレッドで送信されます。
Application Insights の監視対象
Application Insights は、開発チームがアプリのパフォーマンスや使用状況を把握するのに役立ちます。
次のものが Application Insights で監視されます。
要求率、応答時間、および失敗率。
最も人気の高いページ、時刻、およびユーザーの場所がわかります。 最もパフォーマンスの高いページを確認します。 応答時間とエラー率がトラフィック レベルとどのように対応しているかを確認します。
外部サービスによって動作速度が遅くなっているかどうか。
アプリケーションの例外。
集計された統計を分析します。または特定のインスタンスを選択し、スタック トレースで関連する要求を調べます。 Application Insights には、サーバーとクライアントの両方で発生した例外が報告されます。
ユーザーの Web ブラウザーから報告された、Web ページ読み込みのパフォーマンス。
Web ページからの AJAX 呼び出し (応答時間とエラー率を含む)。
ユーザーとセッションの数。
Windows または Linux サーバー コンピューターの CPU、メモリ、ネットワーク使用率などのパフォーマンス カウンター。
Docker または Azure のホスト診断。
アプリからの診断トレース ログ。 これにより、トレース イベントを要求に関連付けることができます。
クライアントまたはサーバー コードで自分が作成したカスタム イベントとメトリック。 たとえば、販売した品目や勝った試合などのイベントを追跡します。
テレメトリの確認場所
テレメトリ データは次の方法で表示および追跡できます。
-
アプリのテレメトリの通常パターンに対して自動アラートを適応し、通常とは異なるパターンがある場合にアラートをトリガーします。 カスタムまたは標準のメトリックスの特定レベルでアラートを設定することもできます。
-
アプリケーション マップを使用すると、分散アプリケーションのすべてのコンポーネントを対象にパフォーマンスのボトルネックや障害のホットスポットを特定できます。
-
Profiler は、Basic 以上のサービス レベルを使用し、Azure App Service で実行されている ASP.NET および ASP.NET Core アプリで実行できます。
-
この機能を使用すると、ユーザーのセグメント化とリテンション期間を分析できます。
-
検索は、ページ ビュー、例外、Web 要求などの個々のテレメトリ項目を検索または探索するために役立ちます。
-
メトリックス エクスプローラーを使用すると、グラフをプロットしたり、傾向を視覚的に関連付けたり、メトリックの急上昇や急降下を調べたりすることができます。
-
新しいビルドをデプロイするときに、パフォーマンス インジケーターをほぼリアルタイムで監視して、すべてが想定どおりに動作することを確認します。
-
強力なクエリ言語を使用して、アプリのパフォーマンスと使用状況に関する困難な質問に答えます。
-
ライブ Web アプリケーションからデバッグのスナップショットを収集します。
-
使用状況のメトリックをその他のビジネス インテリジェンスと統合します。
-
生データが到着するとすぐにストレージにエクスポートします。
IT Service Management Connector とは
Azure の IT Service Management Connector (ITSMC) によって、Azure 監視ツールと次のような ITSM ツールとの間に双方向の統合が提供されます。
- ServiceNow
- Provance
- Cherwell
- System Center Service Manager
Azure 監視ツールを ITSMC と統合して、次のことができます。
- Azure アラートに基づいて、ITSM ツールで作業項目を作成または更新します。
- ITSM ツールから Azure Log Analytics にインシデントと変更要求データをプルします。
Azure 監視ツールを使用すると、問題の特定、分析、トラブルシューティングを行うことができます。 ただし、問題に関連している作業項目は、通常、ITSM ツールに格納されます。 ITSMC を使用したチケット発行システムを実装する方が理にかなっています。 そうすることで、ITSM ツールと Azure 監視ツールの間を行き来するのではなく、必要なすべての情報を 1 か所で取得できます。 ITSMC を使用すると、問題の解決にかかる時間が短縮され、それによってトラブルシューティングのエクスペリエンスが向上します。