Azure Application Insights

解決する課題

「ページが遅い」「たまにエラーになる」が、コードのどこで起きているのかを切り分けるための仕組みです。インフラのメトリクスだけでは見えない、アプリケーション内部の振る舞いを可視化します。

• リクエストの応答時間や失敗率を把握し、遅いエンドポイントを特定したい
• 外部 API や DB などの依存関係呼び出しのどこがボトルネックかを知りたい
• 例外のスタック トレースと発生頻度を集約して原因を追いたい
• マイクロサービスをまたぐ 1 リクエストの流れを分散トレースで追跡したい（AWS の X-Ray に相当）

主要概念と用語

• APM（アプリケーション パフォーマンス監視）: アプリの性能・可用性・利用状況を継続的に観測する分野。Application Insights はその中核機能
• テレメトリ: 収集される信号の総称。リクエスト、依存関係、例外、トレース、カスタム イベント、メトリクスなどの種類がある
• リクエスト（Requests）: 受信した HTTP 要求などの単位。応答時間・結果コード・成否を記録
• 依存関係（Dependencies）: アプリが外部に行った呼び出し（SQL、HTTP、キュー、ストレージ）。所要時間と成否を記録
• 分散トレース / 相関: サービス間にまたがる 1 件の処理を、共通の operation ID でひも付けて追跡する仕組み。W3C Trace Context に準拠
• アプリケーション マップ: コンポーネントと依存関係の関係を、性能・失敗率つきで自動描画したトポロジ図
• トランザクション検索 / エンドツーエンド トランザクション: 個々の処理を時系列で展開し、どのステップで時間がかかり、どこで例外が出たかを追う画面
• Live Metrics: ほぼリアルタイムに流れるリクエスト・依存関係・例外を秒単位で観測するストリーム
• サンプリング（Sampling）: 代表的なテレメトリだけを残して取り込み量を抑える仕組み。適応型・固定率・取り込み時の方式がある
• 自動インストルメンテーション / コードレス: コード変更なしにエージェント拡張でテレメトリを有効化する方式（対応言語・ホスト環境に依存）

仕様・制限・クォータ

• データは Log Analytics ワークスペースに格納される（ワークスペース ベース）。従来の独立型（クラシック）リソースは廃止され、ワークスペース ベースに統一された
• 格納先がワークスペースのため、保持期間・テーブル プラン・コストの考え方は Azure Monitor ログに従う。Application Insights 由来の保持は既定で数か月程度で、設定で延長できる
• テレメトリ取り込みにはサンプリングが効き、適応型サンプリングは既定で有効になりやすい。値の合計は推定で補正される
• 1 件の例外やトレースのメッセージ長などにフィールド単位の上限があり、超過分は切り詰められる
• サブスクリプション/リソースあたりのデータ レート上限が存在し、超過時はキャップや調整（throttling）の対象になり得る
• ライブで観測する Live Metrics は保持されないリアルタイム ストリームで、長期分析には KQL クエリ可能なログ側を使う

内部の仕組み

アプリに **SDK（または OpenTelemetry ディストリビューション）**を組み込むか、自動インストルメンテーションを有効化すると、受信リクエスト・送信依存関係・例外が自動で計測され、テレメトリとして Application Insights のエンドポイントへ送られます。送られたデータは結びついた Log Analytics ワークスペースに格納され、**KQL（Kusto 照会言語）**で横断的にクエリできます。

分散トレースでは、各テレメトリに operation ID などの相関プロパティが付与され、サービス境界をまたいで伝播します。これにより、フロントエンドからバックエンド、さらに外部依存までを 1 本のトランザクションとしてつなげて表示できます。相関の伝播は W3C Trace Context に準拠しており、これが AWS の X-Ray におけるトレース ID 伝播と同じ役割を果たします。

取り込み時にはサンプリングが適用され、代表データを残しつつ全体の傾向を維持します。集計済みメトリクスやアプリケーション マップは、この格納データから導出されます。

設計パターン / ベストプラクティス

• 相関を最優先で設計: 各サービスで Trace Context を確実に伝播させ、エンドツーエンドのトランザクションが途切れないようにする
• 役割分担: アプリ層の振る舞いは Application Insights、インフラ層は Azure Monitor のメトリクス・ログ、と層で分けて可観測性を組む
• カスタム ディメンションを付与し、テナント ID やバージョンなど業務軸でフィルタ・集計できるようにする
• **可用性テスト（標準テスト）**で外形監視を行い、ユーザー視点の到達性をリクエスト計測と併用する
• サンプリングをコストと精度のバランスで調整し、低トラフィックでは緩め、高トラフィックでは強めるなど環境ごとに最適化する
• デプロイ注釈やリリース情報をテレメトリに関連づけ、回帰がどのリリースで入ったかを追えるようにする

運用・監視

• データが出てこない → 接続文字列（Connection String）の設定漏れ、対象ホスト/言語が自動計装の対象外、送信エンドポイントへのネットワーク到達性を確認
• トレースが途切れる → サービス間で Trace Context の伝播が抜けている、または計装ライブラリのバージョン不整合を疑う
• 件数が想定より少ない → サンプリングで間引かれている可能性。表示は推定補正されるが、生件数が必要なら設定を見直す
• 取り込み量が急増 → 過剰な依存関係・トレースの出力、Verbose な計装を点検し、サンプリングや出力レベルで抑制する
• 即時の障害把握には Live Metrics、事後分析には KQL クエリとアプリケーション マップを使い分ける

コスト

課金は格納先である Log Analytics ワークスペースの取り込み量（GB）と保持に基づきます。テレメトリ量が直接コストに効くため、サンプリングと出力レベルの管理が重要です。

セキュリティ

• 取り込みは接続文字列で行い、宛先と取り込みエンドポイントを一意に識別する。古いインストルメンテーション キー単独の利用ではなく接続文字列方式が推奨
• 格納先ワークスペースへのアクセスは Microsoft Entra ID + Azure RBACで制御し、テーブル/リソース コンテキストで権限を絞る
• データは保存時に暗号化され、要件に応じて **Customer-Managed Key（CMK）**で鍵を管理できる
• ネットワーク分離が必要なら Private Link を用い、取り込みとクエリを閉域に閉じ込める
• 個人情報や秘匿値がテレメトリに混入しないよう計装側でマスキング/フィルタする。例外メッセージやカスタム プロパティに機微情報を載せない

Well-Architected の観点

• オペレーショナル エクセレンス: アプリケーション マップとエンドツーエンド トランザクションで、障害の切り分けと根本原因分析を高速化する。デプロイ情報と関連づけて回帰追跡を仕組み化する
• パフォーマンス効率: 依存関係の所要時間からボトルネックを特定し、遅いクエリや外部呼び出しを継続的に改善する。Live Metrics で負荷時の挙動をその場で観測する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# ワークスペース ベースの Application Insights リソースを作成
# （格納先の Log Analytics ワークスペースを --workspace で指定）
az monitor app-insights component create \
  --app demo-appinsights \
  --resource-group demo-rg \
  --location japaneast \
  --workspace "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.OperationalInsights/workspaces/demo-law"

# アプリ計装に使う接続文字列を取得
az monitor app-insights component show \
  --app demo-appinsights \
  --resource-group demo-rg \
  --query connectionString -o tsv

# 直近1時間で失敗したリクエストを KQL で集計（依存関係の遅延もあわせて確認）
az monitor app-insights query \
  --app demo-appinsights \
  --resource-group demo-rg \
  --analytics-query "requests | where timestamp > ago(1h) | where success == false | summarize failures = count() by name | order by failures desc"