Azure Analysis Services

解決する課題

Azure Analysis Services（AAS）は、データウェアハウスやデータマートの上に「セマンティックモデル（意味のあるビジネスモデル）」を構築し、BI ツールから一貫した定義で高速にクエリできるようにするマネージド分析エンジンです。SQL Server Analysis Services（SSAS）の表形式（Tabular）モードを、サーバー管理なしで利用できる形にしたものと考えると理解しやすくなります。

• レポートごとにバラバラだった 集計やビジネス指標（メジャー）の定義を1か所に集約したい
• ダッシュボードの操作（ドリルダウンやスライス）に対して 数百ミリ秒で集計結果を返したい
• 複数の BI ツールやユーザーに対して 同じ「正しい数字」の定義を共有したい
• 列レベル・行レベルでユーザーごとに 見える範囲を制御したい

主要概念と用語

• 表形式モデル（Tabular モデル）: テーブル・列・リレーションシップ・メジャーで構成される BI 向けのモデル。AAS が扱う中心的なモデル形式
• セマンティックモデル: 物理的なテーブルにビジネス上の意味（指標名・集計ロジック・階層）を与えた層。レポートはこの層に問い合わせる
• メジャー（Measure）: 売上合計や前年比などの集計値の定義。DAX 式で記述する
• DAX（Data Analysis Expressions）: メジャーや計算列を定義する数式言語。フィルタコンテキストに応じて集計を評価する
• VertiPaq（xVelocity）: 列指向でデータをインメモリ圧縮して保持するストレージエンジン。インポートモデルの高速さの源
• インポートモードと DirectQuery: データをモデルに取り込んで保持するインポートと、クエリのたびに元データソースへ問い合わせる DirectQuery の2方式がある
• 処理（プロセス / Process）: 元データを読み込み、モデルへ反映（更新）する操作。フルとインクリメンタルがある
• パーティション: 大きなテーブルを分割する単位。更新対象を絞ってインクリメンタル処理を効率化する
• ロール（Role）: モデルへのアクセス権の単位。行レベルセキュリティ（RLS）もロール単位で定義する

仕様・制限・クォータ

• AAS は表形式モデルのみを扱う。SSAS にあった多次元（Multidimensional）モードや MDX 中心のキューブは対象外で、表形式と DAX が前提となる
• 価格レベルは開発向けと本番向けに分かれる。本番向けの上位レベルほど割り当てメモリと QPU（クエリ処理ユニット）が大きく、扱えるモデルサイズと同時実行が増える
• インポートモデルはメモリに収まる必要がある。圧縮後のモデルサイズが割り当てメモリを超えないよう、列の選別やパーティション設計で抑える
• サーバーの一時停止 / 再開ができる。停止中はコンピューティング課金が止まる（一般的な目安として、停止中は処理もクエリも不可）
• 同時実行クエリ数や処理のスループットには上限があり、価格レベルとモデル設計に依存する。具体的な数値は変動するため公式ドキュメントで確認する

内部の仕組み

AAS の表形式モデル（インポートモード）は、データを VertiPaq エンジンが列指向で圧縮しインメモリに保持します。列ごとに辞書エンコードやランレングス圧縮を適用するため、ディスク上の元データよりはるかに小さくなり、集計時はメモリ上の列を高速にスキャンして合計や平均を求めます。クエリは DAX で評価され、フィルタコンテキスト（スライサーやドリルダウンで絞られた条件）に応じてメジャーが再計算されます。

• インポートモードは元データを取り込み、VertiPaq で圧縮保持する。最も低レイテンシだが、鮮度は処理（更新）の頻度に依存する
• DirectQuery モードはデータを保持せず、クエリのたびに元のデータソース（例: SQL）へ問い合わせる。鮮度は高いが、応答は元データソースの性能に左右される
• **処理（プロセス）**で元データを読み直してモデルを更新する。テーブルをパーティションに分け、変化した期間だけを インクリメンタルに処理すると更新コストを抑えられる
• メジャーは保存値ではなくクエリ時に評価されるため、DAX の書き方とモデルのリレーション設計が応答性能を大きく左右する

この「集計済み・圧縮済みのセマンティックモデルを BI の裏で高速に返す」役割は、AWS では単一の同等サービスというより、Power BI のデータセット層に近い分析ストアを別建てで持つ構成にあたります。AAS 自体は SSAS 表形式モードのクラウド版という位置づけが最も正確です。

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

• スター スキーマで設計する: ファクトテーブルとディメンションテーブルを明確に分け、リレーションをシンプルに保つと DAX も性能も安定する
• 不要な列・高カーディナリティ列を持ち込まない: VertiPaq の圧縮効率とメモリ使用量に直結する。とくに一意性の高い ID 列や自由テキストは注意する
• パーティションでインクリメンタル処理: 時系列のファクトを期間で分割し、最新期間だけを更新してフル処理を避ける
• メジャーは集約側に寄せる: レポート側で複雑な計算を繰り返すより、モデルにメジャーとして定義して再利用する
• DirectQuery は限定的に: 鮮度要件やサイズ制約がある部分だけに使い、ホットな分析はインポートで高速化する

運用・監視

• Azure Monitor / 診断設定でメトリクスとログを Log Analytics に送り、QPU 使用率・メモリ・処理時間・クエリ時間を継続監視する
• 処理（更新）の自動化は Azure Automation や Logic Apps、データ パイプラインからスケジュール実行し、失敗時に再実行・通知する
• 一時停止 / 再開のスケジュール化で、利用しない時間帯のコンピューティング課金を止める
• **スケールアウト（読み取りレプリカ）**を使うと、クエリ負荷の高い時間帯に同時実行を分散できる
• クエリが遅いときは、メモリ逼迫か、DAX の重さか、DirectQuery 側のデータソース性能かを切り分ける

コスト

コストの主因は サーバーの価格レベル（割り当てメモリと QPU）と稼働時間です。停止可能なプロビジョンド型のため、稼働させた時間に対して課金されると考えると整理しやすくなります。具体的な料金は変動するため定性的に押さえます。

セキュリティ

• Microsoft Entra ID 認証が前提で、ユーザーやサービスプリンシパルに対してロールで権限を割り当てる
• **行レベルセキュリティ（RLS）**をロール単位で定義し、ユーザーごとに見える行を絞る（例: 担当地域のデータだけを表示）
• データソースへの接続は マネージド ID を使い、資格情報のハードコードを避ける
• 保存データはサービス側で暗号化され、転送は TLS で保護される
• オンプレミスデータゲートウェイや VNet 連携で、閉域のデータソースへ安全に接続する

関連サービス・比較

AAS は SQL Server Analysis Services（SSAS）の表形式モードをクラウド化したものです。オンプレミスの SSAS と対応づけると、移行や使い分けの判断がしやすくなります。

ハンズオン / CLI例

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

# Analysis Services サーバーを作成（開発向けの価格レベルを指定）
az resource create \
  --resource-group demo-rg \
  --name demoaas0628 \
  --resource-type Microsoft.AnalysisServices/servers \
  --location japaneast \
  --properties '{}' \
  --is-full-object \
  --properties '{"sku": {"name": "D1", "tier": "Development"}}'

# サーバーを一時停止してコンピューティング課金を止める
az resource invoke-action \
  --resource-group demo-rg \
  --name demoaas0628 \
  --resource-type Microsoft.AnalysisServices/servers \
  --action suspend

# 利用再開時はサーバーを再開する
az resource invoke-action \
  --resource-group demo-rg \
  --name demoaas0628 \
  --resource-type Microsoft.AnalysisServices/servers \
  --action resume