Azure Data Explorer

解決する課題

Azure Data Explorer（ADX、Kusto とも呼ばれます）は、継続的に流れ込む大量のログ・テレメトリ・イベント・時系列データを取り込み、低レイテンシで対話的に分析するためのフルマネージド分析サービスです。

• ログやメトリクスを 秒単位で取り込み、取り込み直後から検索したい
• テラバイト規模のデータに対して アドホックなクエリを数秒で返したい
• 全文検索・集計・時系列分析・異常検知を 同じエンジンで行いたい
• BI ツールやダッシュボードの 裏側の高速分析ストアとして使いたい

近い役割を持つ AWS のサービスは Amazon OpenSearch Service（ログ・テレメトリの検索と分析基盤）です。本文では理解の助けとして随所で対応関係に触れます。

主要概念と用語

• クラスター（Cluster）: 計算とストレージを束ねる ADX のデプロイ単位。スケールやコストの境界となる
• データベース（Database）: クラスター内でテーブルやポリシーを束ねる論理コンテナ
• テーブル（Table）: 列指向で格納される構造化データの入れ物。スキーマを持つ
• KQL（Kusto Query Language）: ADX の読み取り専用クエリ言語。パイプでフィルター・集計・時系列処理をつなぐ
• 取り込み（Ingestion）: データをテーブルへ取り込む処理。バッチ取り込みとストリーミング取り込みがある
• エクステント（Extent / シャード）: テーブルを構成する不変のデータブロック。再構成（マージ）されながら保持される
• 保持ポリシー / キャッシュポリシー: データを保持する期間と、ホットキャッシュ（高速層）に置く期間を制御するポリシー
• マテリアライズドビュー: 集計結果を事前計算して保持し、繰り返しクエリを高速化する仕組み
• 更新ポリシー（Update policy）: 取り込み時に変換クエリを適用し、別テーブルへ派生データを書き込む仕組み

仕様・制限・クォータ

• KQL は読み取り中心の言語で、データの更新や削除よりも追記（append）型の取り込みに最適化されている
• 取り込みはバッチが既定で、小さなデータをまとめてから書き込むためわずかな遅延がある。低遅延が必要なら ストリーミング取り込みを有効化する
• クエリ結果やクエリ時間には上限があり、巨大な結果セットの返却や長時間クエリは制限される（定性的に大規模分析向けの上限が設定されている）
• データはホットキャッシュとコールドストレージに分かれ、キャッシュ対象期間のクエリほど高速になる
• クラスターあたりのデータベース数や同時実行クエリ数などには上限があり、変動するため設計時に公式ドキュメントで確認する

内部の仕組み

ADX はデータを 列指向で格納し、列ごとに圧縮とインデックスを適用します。テーブルは不変の エクステント（シャード）の集合として保持され、取り込みのたびに新しいエクステントが作られ、バックグラウンドで継続的にマージ・最適化されます。検索時には、テキスト列に対する全文インデックスや列の統計を使って読むべきブロックを絞り込むため、テラバイト規模でも対話的な応答が得られます。

• 取り込まれたデータはまずホットキャッシュ（高速なローカル層）に置かれ、保持期間を過ぎるとコールドストレージへ移る
• クエリエンジンは列のプルーニングとインデックスでスキャン量を最小化し、集計・時系列・文字列処理を並列実行する
• マテリアライズドビューや更新ポリシーで、よく使う集計や整形を取り込み時・事前計算側に寄せて読み取りを軽くできる

この「取り込んだログを列指向＋インデックスで高速に検索・集計する」モデルは、AWS の Amazon OpenSearch Service がドキュメント指向の転置インデックスで実現する領域と用途が重なります。違いとして、ADX は KQL によるパイプライン型の分析と時系列処理に強みがあります。

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

• 役割分担: 取り込みは Event Hubs や IoT Hub、変換・派生は更新ポリシー、可視化は Power BI や Grafana と組み合わせる
• キャッシュポリシーの調整: よく検索する直近データのキャッシュ期間を長く、古いデータは短くしてコストと速度を両立する
• マテリアライズドビューの活用: ダッシュボードが叩く定番集計は事前計算しておき、対話的応答を安定させる
• パーティション設計: 時系列のデータは時間で自然に分割され、時間範囲での絞り込みが効くようクエリ側でも時間フィルターを先頭に置く
• 取り込みの整形: 取り込み時に不要列を落とし、列型を適切にして圧縮効率とクエリ速度を上げる

運用・監視

• Azure Monitor のメトリクスでクラスターの CPU・キャッシュ使用率・取り込み遅延・取り込み失敗を監視する
• 取り込みの失敗は専用の診断や取り込み結果のテーブルで把握し、スキーマ不一致やマッピング誤りを切り分ける
• 自動スケールを設定し、負荷に応じてインスタンス数を増減させてコストと性能のバランスを取る
• クエリが遅いときは、キャッシュ対象期間か、時間フィルターの有無か、集計の重さかを切り分け、必要ならマテリアライズドビューへ寄せる

コスト

コストの主因は クラスターのコンピューティング（インスタンス種別と台数） と ストレージ（保持データ量）、それに取り込み量です。具体的な料金は変動するため定性的に押さえます。

セキュリティ

• Microsoft Entra ID + RBAC で認証・認可を行い、データベースやテーブル単位の権限を割り当てる
• アプリからの接続は マネージド ID を使い、資格情報のハードコードを避ける
• 行レベルセキュリティや制限付きビューで、利用者ごとに見えるデータを絞れる
• 保存データはサービス側で暗号化され、**カスタマーマネージドキー（Key Vault）**にも対応する
• プライベートエンドポイントやネットワーク規則で公開アクセスを制限し、転送は TLS で保護する

Well-Architected の観点

• パフォーマンス効率: 列指向ストレージとインデックス、ホットキャッシュ、マテリアライズドビューで対話的なクエリ性能を確保する。時間フィルターを先頭に置く KQL の書き方も性能に直結する
• オペレーショナルエクセレンス: 取り込み・クエリのメトリクスを Azure Monitor で継続監視し、自動スケールと保持・キャッシュポリシーで運用を自動化する。更新ポリシーで取り込み時の整形を標準化すると運用が安定する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Data Explorer クラスターを作成（SKU と台数を指定）
az kusto cluster create \
  --resource-group demo-rg \
  --name demoadx0614 \
  --location japaneast \
  --sku name="Standard_D11_v2" tier="Standard" \
  --capacity 2

# クラスターの中にデータベースを作成（保持365日・キャッシュ31日）
az kusto database create \
  --resource-group demo-rg \
  --cluster-name demoadx0614 \
  --database-name logs \
  --read-write-database location=japaneast \
    soft-delete-period=P365D hot-cache-period=P31D

# 使い終わったらクラスターを停止してコンピューティング費用を抑える
az kusto cluster stop \
  --resource-group demo-rg \
  --name demoadx0614