次の方法で共有


Application Insights を使用した Web アプリおよびサービスの詳細な診断

この記事では、DevOps サイクルへの Application Insights の組み込みについて説明します。

Application Insights が必要な理由

Application Insights は、実行中の Web アプリを監視します。 これを使用することでエラーやパフォーマンスの問題が通知され、顧客がどのようにアプリを使用しているかを分析するのに役立ちます。 これは、ASP.NET、Java EE、Node.js などのプラットフォームで実行されているアプリに対して機能します。 クラウド内またはオンプレミスで提供されます。

Web アプリのデリバリーの複雑さのさまざまな側面を示すイメージ。

最新のアプリケーションでは、実行中の監視が不可欠です。 顧客よりも早くエラーを検出する必要があります。 速度の低下を招いたり、ユーザーに不都合をもたらしたりするパフォーマンスの問題を検出して修正することも必要です。 システムが期待どおりに動作している場合は、ユーザーがシステムを使用して何をしているのかを知る必要もあります。 たとえば、最新機能を使用しているかどうかです。 うまく使用できているか、などを知りたいと思うでしょう。

最新の Web アプリケーションは、継続的デリバリーのサイクルの中で開発されています。

  • 新機能または機能強化をリリースします。
  • ユーザーのためにどれだけうまく機能しているかを確認します。
  • その知見に基づいて、次に行う追加の開発を計画します。

このサイクルで重要なのは観察のフェーズです。 Application Insights は、Web アプリケーションのパフォーマンスと使用状況を監視するためのツールを提供します。

このプロセスで最も重要なのは診断です。 アプリケーションがうまく動かないと、ビジネスの損失が発生します。 監視フレームワークの主な役割は、次のとおりです。

  • 障害を確実に検出します。
  • すぐに通知します。
  • 問題を診断するために必要な情報を提示します。

Application Insights は、これらのタスクを実行します。

バグはどこから発生するのか

通常、Web システムでのエラーは、構成の問題や、多くのコンポーネント間の不適切な相互作用に起因します。 ライブ サイト インシデントに対処するときの最初のタスクは、問題の発生場所を識別することです。 原因は、どのコンポーネントまたはリレーションシップですか。

今よりも単純な時代には、コンピューター プログラムは 1 つのコンピューターで実行されていました。 開発者は出荷する前にそれを徹底的にテストしましたが、出荷後にそれを見直したり再検討したりすることはほとんどありませんでした。 ユーザーは何年もの間、残存しているバグを我慢しなければなりませんでした。

現在、プロセスは大きく異なります。 アプリが実行されるデバイスは多種多様で、それぞれのデバイスでまったく同じ動作を保証することは困難である場合があります。 クラウドでアプリを提供するということは、すばやくバグを修正できることを意味します。 しかし、絶え間ない競争と頻繁な新機能の提供への期待も伴います。

このような状況で、バグの数を確実に管理する唯一の方法は、自動化された単体テストです。 デリバリーのたびにすべてを手動で再テストすることは不可能です。 現在では、単体テストはビルド プロセスの一部として普及しています。 複数のブラウザー バージョンでの UI テストの自動化を提供する Xamarin Test Cloud などのツールが役立ちます。 このようなテスト方法を活用することで、私たちはアプリで見つかるバグの割合を最小限に抑えることを期待できます。

一般的な Web アプリケーションには多くのライブ コンポーネントがあります。 クライアント (ブラウザーやデバイス アプリ) と Web サーバーに加え、相当量のバックエンド処理もあるでしょう。 そのバックエンドはおそらく、コンポーネントのパイプラインや、連携する構成要素の厳密ではない集合体です。 それらの多くは、開発者の管理下にありません。 それらは、開発者が依存している外部サービスです。

このような構成では、ライブ システム自体以外の、考えられるすべての障害の状態をテスト、あるいは予測することは困難かつ非経済的である場合があります。

質問

Web システムを開発しているときには、次のような疑問が生じます。

  • アプリはクラッシュしていますか。
  • 正確には何が起こりましたか。 要求に失敗した場合、そうなった経緯を把握したいと考えます。 イベントのトレースが必要です。
  • アプリの速度は十分ですか。 一般的な要求への応答時間はどのくらいですか。
  • サーバーは負荷を処理できますか。 要求率が増加した時の応答時間は安定していますか。
  • 依存するコンポーネント (アプリが呼び出す REST API、データベースなど) の応答速度はどのくらいですか。 具体的には、そのシステムが低速の場合、それは自分のコンポーネントですか。または、他のコンポーネントから低速な応答を受け取っていますか。
  • アプリは起動していますか、停止していますか。 世界各地から閲覧できますか。 停止する場合はそれを把握する必要があります。
  • 根本的な原因は何ですか。 自分のコンポーネントまたは依存するコンポーネントのどちらの障害でしたか。 通信に関する問題ですか。
  • 影響を受けているユーザーの数はどれくらいですか? 対処すべき問題が複数ある場合は、最も重要なのはどれですか。

Application Insights とは

Application Insights の基本的なワークフローを示すイメージ。

  1. Application Insights では、アプリをインストルメント化し、アプリの実行時に、アプリに関するテレメトリを送信します。 Application Insights SDK をアプリに組み込むか、実行時にインストルメンテーションを適用することができます。 前者の方法は、標準のモジュールに独自のテレメトリを追加できるため、より柔軟です。
  2. テレメトリは、テレメトリが保管および処理される Application Insights ポータルに送信されます。 Application Insights は Azure で提供されていますが、Azure アプリだけでなく、任意の Web アプリを監視できます。
  3. テレメトリは、イベントのグラフとテーブルの形式で表示されます。

テレメトリには 2 つの主な種類があります。 集計インスタンスと生のインスタンスです。

  • インスタンス データには、Web アプリが受信した要求のレポートが含まれている場合があります。 Application Insights ポータルの検索ツールを使用して、要求の詳細を検索して検査できます。 インスタンスには、アプリが要求に応答するために要した時間、要求された URL、クライアントのおおよその場所などのデータが含まれている場合があります。
  • 集計データには、要求の割合を応答時間と比較できるように、単位時間あたりのイベントの数が含まれています。 要求の応答時間などのメトリックの平均値も含まれています。

データの主なカテゴリは次のとおりです。

  • URL、応答時間、成功または失敗に関するデータを含む、アプリへの要求 (通常は HTTP 要求)。
  • URI、応答時間、成功も含む、アプリによって行われる REST および SQL の呼び出しなどの依存関係。
  • スタック トレースを含む例外。
  • ユーザーのブラウザーから取得するページ ビュー データ。
  • パフォーマンス カウンターなどのメトリックおよび自分で作成したメトリック。
  • ビジネス イベントを追跡するために使用できるカスタム イベント。
  • デバッグに使用するログ トレース。

ケース スタディ: レアル・マドリード F.C.

レアル・マドリード フットボール クラブ の Web サービスは、世界各地の約 4 億 5,000 万人のファンにサービスを提供しています。 ファンは、Web ブラウザーとクラブのモバイル アプリからここにアクセスします。 ファンはチケットを予約でき、試合結果、選手、今後の試合に関する情報やビデオ クリップにもアクセスできます。 フィルターを使用して、得点数などを検索できます。 ソーシャル メディアへのリンクもあります。 ユーザー エクスペリエンスは高度にパーソナライズされており、ファンとの交流のための双方向コミュニケーションとして設計されています。

このソリューションは、Azure でのサービスとアプリケーションのシステムです。 スケーラビリティは重要な要件です。 トラフィックは変わりやすく、試合の前後と試合中は、トラフィック量が増える場合があります。

レアル・マドリードでは、システムのパフォーマンスを監視することが不可欠です。 Application Insights は、システム全体の包括的なビューを提供して、信頼性のある高レベルのサービスを保証できます。

クラブは、ファンに関する詳細な情報も取得します。この情報には、ファンの場所 (スペインはたった 3% です)、ファンが関心を持っている選手、過去の試合結果、今後の試合に関する事柄、および試合結果に対する反応が含まれます。

このテレメトリ データの大部分は、コードの追加なしで自動的に収集されます。これにより、ソリューションが単純化され、運用上の複雑さが軽減されます。 レアル・マドリードの場合、Application Insights は 1 か月あたり 38 億人のテレメトリ ポイントを処理します。

レアル・マドリードは Power BI モジュールを使用してテレメトリを表示します。

Application Insights テレメトリの Power BI ビューを示すスクリーンショット。

スマート検出

プロアクティブ診断は最新の機能です。 特別な構成なしで、Application Insights はアプリの障害発生率の異常な増加を自動的に検出してアラートを生成します。 この機能は、偶発的なエラーの背景と、要求の数に比例して単純に増加したエラーを無視できるほどスマートです。

たとえば、開発者が依存しているいずれかのサービスでエラーが発生する可能性があります。 または、デプロイした新しいビルドがうまく機能していない可能性があります。 メールを見るとすぐにそのことが分かります。 他のアプリをトリガーできるように webhook も用意されています。

テレメトリの詳細な分析を毎日実行し、検出が困難なパフォーマンスの異常なパターンを検出するのが、この機能のもう 1 つの側面です。 たとえば、特定の地理的領域または特定のブラウザーのバージョンに関連付けられたパフォーマンスの低下を検出できます。

どちらの場合も、検出された症状がアラートによって通知されます。 関連する例外レポートなど、問題の診断を支援するために必要なデータも提供されます。

プロアクティブ診断からのメールを示すスクリーンショット。

お客様である Samtec は次のように語っています。「私たちは、先日の機能のカット オーバーの際、リソースの限界に達し、タイムアウトを発生させている小規模なデータベースに気づきました。 私たちが問題をトリアージしているとき、広告のとおり、まさにほぼリアルタイムでプロアクティブな検出アラートが生成されました。 このアラートと Azure プラットフォームのアラートによって、ほぼ瞬時に問題を修正することができました。 ダウンタイムは合計で 10 分未満でした。」

ライブ メトリック ストリーム

最新のビルドを展開することは、気がかりな体験となる場合があります。 何らかの問題がある場合、必要に応じて取り消すことができるように、すぐに問題を把握する必要があります。 ライブ メトリック ストリームを使用すると、約 1 秒の待機時間で重要なメトリックが提供されます。

ライブ メトリックを示すスクリーンショット。

すぐにエラーまたは例外のサンプルを検査できます。

ライブ エラー イベントを示すスクリーンショット。

アプリケーション マップ

アプリケーション マップは、アプリケーション トポロジを自動的に検出します。 マップの上にパフォーマンス情報を配置して、分散環境全体のパフォーマンスのボトルネックと問題のあるフローを簡単に識別できるようにします。 アプリケーション マップを使用すると、Azure サービスのアプリケーションに対する依存関係を検出できます。

問題がコードに関連しているか、または依存関係に関連しているかを理解することで、問題をトリアージできます。 1 つの場所から、関連する診断エクスペリエンスにドリルダウンできます。 たとえば、アプリケーションは SQL 層のパフォーマンスの低下が原因で失敗している可能性があります。 アプリケーション マップを使用すると、問題をすぐに確認し、SQL Index Advisor やクエリの洞察のエクスペリエンスにドリルダウンすることができます。

アプリケーション マップを示すスクリーンショット。

Application Insights の Log Analytics

Log Analytics を使用すれば、強力な SQL に似た言語で任意のクエリを記述することができます。 さまざまなパースペクティブが接続されるにつれて、アプリ スタック全体の診断が簡単になります。 その後、適切な質問をして、サービス パフォーマンスをビジネス メトリックや顧客エクスペリエンスと関連付けることができます。

ポータルに格納されているすべてのテレメトリ インスタンスとメトリックの生データを照会できます。 言語には、フィルター、結合、集計などの操作が含まれています。 フィールドを計算し、統計的な分析を実行できます。 テーブルとグラフの視覚エフェクトを使用できます。

分析クエリと結果グラフを示すスクリーンショット。

たとえば、次のことを簡単に行うことができます。

  • アプリケーションの要求のパフォーマンス データを顧客層ごとに分割し、顧客満足度を把握します。
  • ライブ サイトの調査中に特定のエラー コードまたはカスタム イベント名を検索します。
  • 特定の顧客のアプリの使用状況をドリルダウンし、機能がどのように入手および導入されているかを把握します。
  • 特定のユーザーのセッションと応答時間を追跡し、サポートおよび運用チームがすぐに顧客サポートを提供できるようにします。
  • 頻繁に使用されるアプリ機能を判別し、機能の優先順位付けに関する質問に回答します。

お客様である DNN は次のように語っています。「Application Insights は、必要に応じてデータの結合、並べ替え、クエリ、およびフィルター処理を実現するための方程式の欠落部分を補ってくれました。 当社のチームが独自のアイデアと経験を活用し、強力なクエリ言語でデータを検索できることで、当社は洞察を検索して、今まで知りもしなかった問題を解決することができます。 "...だろうか" で終わる質問から、多くの興味深い回答が生まれます。」

開発ツールの統合

Application Insights は開発ツールと統合されます。

Application Insights の構成

Visual Studio および Eclipse には、開発しているプロジェクトの正しい SDK パッケージを構成するためのツールが用意されています。 Application Insights を追加するメニュー コマンドがあります。

Log4N、NLog、System.Diagnostics.Trace などのトレース ログ記録フレームワークを使用している場合は、そのログを他のテレメトリと共に Application Insights に送信し、そのトレースを要求、依存関係の呼び出し、例外と簡単に関連付けることができます。

Visual Studio でのテレメトリの検索

機能を開発およびデバッグするときには、Visual Studio でテレメトリを直接表示および検索できます。 Web ポータルと同じ検索機能を使用できます。

Application Insights で例外が記録されると、Visual Studio でそのデータ ポイントを確認し、関連するコードに直接移動できます。

Visual Studio の検索を示すスクリーンショット。

デバッグ中は、開発用コンピューターにテレメトリを保持できます。 ポータルに送信しなくても、Visual Studio で表示できます。 このローカル オプションにより、デバッグと運用環境のテレメトリの混合を回避できます。

作業項目

Application Insights では、アラートが発生したときに、作業項目追跡システムに自動的に作業項目を作成できます。