TL

Cloud Service

Azure Synapse Analytics

分析用データウェアハウスと Apache Spark を1つのワークスペースに統合した統合分析プラットフォーム。AWS の Redshift と EMR の組み合わせに相当する。

中級パフォーマンス効率コスト最適化
最終更新: 2026-06-14公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.DWH(専用 SQL プール)と Spark、サーバーレス SQL を1つのワークスペースに統合する。
  • 2.Data Lake 上のファイルを移動せずにそのまま SQL や Spark で分析できる。
  • 3.AWS では Redshift と EMR、Athena を組み合わせた領域に相当する。

解決する課題

データウェアハウス(構造化データの集計・BI)とビッグデータ処理(Spark によるデータ加工・機械学習)は、従来は別々の製品・別々のチームで運用されがちでした。Synapse Analytics は、これらを単一のワークスペースに束ね、同じデータレイク上のデータに対して複数のエンジンからアクセスできるようにします。

  • 大規模な集計・分析を 列指向の MPP(超並列処理)DWH で高速に実行したい
  • データレイク上のファイルを 移動・取り込みせずに SQL や Spark で直接クエリしたい
  • DWH 用途と Spark によるデータ加工 / 機械学習 を同じ基盤で扱いたい
  • 取り込み・変換・分析・可視化までの パイプラインを1か所 で管理したい

主要概念と用語

  • ワークスペース(Synapse ワークスペース): 各種分析エンジンとパイプラインを束ねる単位。Synapse Studio から統合的に操作する
  • 専用 SQL プール(Dedicated SQL Pool): 旧 Azure SQL Data Warehouse 相当の MPP 型 DWH。DWU(Data Warehouse Unit)でスケールするプロビジョンド型のエンジン
  • サーバーレス SQL プール(Serverless SQL Pool): 事前にプロビジョニング不要で、データレイク上のファイルにそのまま T-SQL を発行できるエンジン。処理したデータ量に応じた従量課金
  • Apache Spark プール: マネージドな Spark クラスター。データ加工(ETL)や機械学習、ノートブックでの探索に使う
  • DWU(Data Warehouse Unit): 専用 SQL プールの計算リソースの単位。大きくするほど並列度とスループットが上がる
  • 分散(Distribution): 専用 SQL プールがテーブルをノード間に分割する方式。ハッシュ分散・ラウンドロビン・レプリケートの3種類がある
  • Synapse Studio: SQL・Spark・パイプライン・監視を1つの Web UI で扱う開発環境
  • Synapse Link: Cosmos DB などの運用データベースと分析を、ETL なしでほぼリアルタイムに接続する機能

仕様・制限・クォータ

  • エンジンは複数あり、用途で使い分ける: 集計・BI 向けの専用 SQL プール、アドホックなファイル探索向けのサーバーレス SQL プール、加工・ML 向けの Spark プール
  • 専用 SQL プールは DWU でスケールするプロビジョンド型で、一時停止 / 再開 ができる。停止中はコンピューティング課金が止まる(ストレージは別途)
  • サーバーレス SQL プールはスキャンしたデータ量に対する従量課金で、常時稼働するクラスターを持たない
  • 分散テーブルの設計が性能を大きく左右する。大きなファクトテーブルはハッシュ分散、小さなディメンションはレプリケートが定石
  • 専用 SQL プールには 同時実行スロットや、PolyBase / COPY による一括読み込みなどの上限・推奨がある
  • データ量・規模に関わる具体的な上限値は SKU やリージョンで異なるため、最新の公式ドキュメントで確認する

内部の仕組み

専用 SQL プールは MPP(Massively Parallel Processing) アーキテクチャを採用しています。1つの制御ノードがクエリを受け取り、複数のコンピューティングノードへ分割して並列実行し、結果を集約します。テーブルのデータは 分散の方式に従ってノード間に物理的に分割され、結合や集計がノード間でどれだけデータを移動(データ移動操作)するかが性能を決めます。

  • ハッシュ分散: 指定列のハッシュ値でデータを各ノードに割り当てる。結合キーや集計キーをそろえると、ノードをまたぐデータ移動を抑えられる
  • ラウンドロビン分散: 偏りなく均等に配るが、結合では再分散が発生しやすい。ステージング用などに向く
  • レプリケート: 全ノードに同じコピーを置く。小さなディメンションテーブルに有効
  • サーバーレス SQL プールは、データレイク上の Parquet / CSV / JSON を直接読み、クラスターを常駐させずにクエリ単位でリソースを割り当てる(AWS の Athena に近い考え方)
  • Spark プールは、ノートブックやジョブから起動するマネージド Spark で、加工結果を再びレイクや専用 SQL プールへ書き戻せる

これらのエンジンが 同一のデータレイク(Data Lake Storage Gen2) を共有するため、データを各エンジン用にコピーして回す必要が減るのが Synapse の核心です。

エンジンの使い分け

定型の集計・BI で安定した高性能が欲しいなら専用 SQL プール、レイク上のファイルを手早く調べたいならサーバーレス SQL プール、複雑な変換や機械学習なら Spark プール、と要件で選びます。1つに固定せず、適材適所で組み合わせるのが Synapse らしい設計です。

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

  • 取り込み層と分析層を分ける: 生データはレイクに置き、サーバーレス SQL や Spark で加工してから専用 SQL プールへロードする(メダリオン構成)
  • 専用 SQL プールへの一括ロードは COPY 文 / PolyBase を使い、行単位の INSERT を避ける
  • 分散キーを結合・集計のキーにそろえることでデータ移動を最小化する
  • 統計情報を最新化し、列指向(クラスター化列ストア)の利点を引き出す
  • 使わない時間帯は専用 SQL プールを一時停止してコンピューティング課金を止める
  • アドホックな探索は常駐コストのない サーバーレス SQL プールに寄せる

運用・監視

  • Azure Monitor と Synapse Studio の監視ハブで、SQL リクエスト・Spark アプリケーション・パイプライン実行を確認する
  • 専用 SQL プールでは DWU 使用率・同時実行・データ移動量を見て、ボトルネックを切り分ける
  • 診断設定でログ・メトリクスを Log Analytics へ送り、長期分析やアラートに使う
  • 専用 SQL プールの 一時停止 / 再開 を運用スケジュールに組み込み、無駄な稼働を避ける
  • パイプライン障害はトリガー実行履歴とアクティビティ単位の出力で原因を追う

コスト

エンジンごとに課金モデルが異なる点を押さえるのがコスト最適化の出発点です。専用 SQL プールはプロビジョンド(停止可能)、サーバーレス SQL プールはスキャン量の従量、Spark プールは稼働したノード時間で考えます。

エンジン課金の考え方向いている用途
専用 SQL プールDWU 単位のプロビジョンド(停止で停止)定型の集計・BI・大規模 DWH
サーバーレス SQL プールスキャンしたデータ量の従量レイク上ファイルのアドホック探索
Spark プール稼働したノード時間(自動停止可)ETL・データ加工・機械学習
コストの落とし穴

専用 SQL プールは使っていなくても稼働中はコンピューティング課金が続きます。検証環境や夜間は一時停止を徹底し、アドホックな探索はサーバーレス SQL プールに寄せると無駄を抑えられます。サーバーレス側もスキャン量課金のため、Parquet 化や列の絞り込みでスキャン量を減らすことが効きます。

セキュリティ

  • Microsoft Entra ID 認証 + RBAC を基本とし、SQL 認証への過度な依存を避ける
  • データレイクへのアクセスは マネージド ID を使い、資格情報のハードコードを避ける
  • 保存データはサービス側で暗号化され、カスタマーマネージドキー(Key Vault) にも対応する
  • マネージド仮想ネットワーク / プライベートエンドポイントでワークスペースの通信を閉域化できる
  • 専用 SQL プールでは 列レベル / 行レベルのセキュリティや動的データマスクで、ユーザーごとに見える範囲を制御する

Well-Architected の観点

  • パフォーマンス効率: 分散方式・統計情報・列ストアの設計が専用 SQL プールの性能を決める。エンジンを用途で使い分け、不要なデータ移動とスキャンを減らす
  • コスト最適化: 専用 SQL プールの一時停止、サーバーレス SQL プールへのアドホック移譲、データの Parquet 化によるスキャン量削減を組み合わせる
  • 取り込み・変換・配信をパイプラインで一元管理し、運用の複雑さを抑える点も含めて、性能とコストのバランスを継続的に見直す

試験で問われるポイント

頻出
  • 専用 SQL プール = MPP 型の DWH(旧 SQL Data Warehouse)で、DWU でスケールし一時停止できるプロビジョンド型である点
  • サーバーレス SQL プール = レイク上のファイルをそのまま T-SQL で読む、スキャン量課金のエンジンである点(AWS の Athena に近い)
  • 分散方式(ハッシュ / ラウンドロビン / レプリケート) の使い分けと、ハッシュ分散がデータ移動を抑える理由
  • Spark プールはデータ加工・機械学習、SQL プールは集計・BI、と役割が分かれること
  • 大量ロードは COPY / PolyBase を使い、行単位 INSERT を避けるという定石
  • 同一のデータレイクを複数エンジンで共有し、データのコピーを減らすのが統合の狙いである点
  • AWS の相当領域は Redshift(DWH)+ EMR(Spark)+ Athena(サーバーレスクエリ) の組み合わせ

関連サービス・比較

Synapse は単一サービスというより、AWS では複数サービスにまたがる領域を1つのワークスペースに統合したものです。AWS の代表的な相当サービスと対応づけると理解しやすくなります。

観点Azure Synapse AnalyticsAWS の相当サービス
MPP 型 DWH専用 SQL プールAmazon Redshift
Spark 処理Apache Spark プールAmazon EMR / Glue
レイク上の直接クエリサーバーレス SQL プールAmazon Athena
共有ストレージData Lake Storage Gen2Amazon S3
パイプライン / ETLSynapse パイプラインAWS Glue / Step Functions
権限付与Entra ID + RBACIAM
後継の位置づけ

新規のレイクハウス志向の構築では、Microsoft は Synapse の発展形として Microsoft Fabric を案内しています。既存の Synapse 資産は引き続き有効ですが、新規採用の際は要件に応じて両者を比較検討するとよいでしょう。

ハンズオン / CLI例

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

# Synapse が使う Data Lake Storage Gen2 用のストレージアカウントを作成
az storage account create \
  --resource-group demo-rg \
  --name demosynapselake0614 \
  --location japaneast \
  --sku Standard_LRS \
  --enable-hierarchical-namespace true

# Synapse ワークスペースを作成(既定のデータレイクを紐づけ)
az synapse workspace create \
  --resource-group demo-rg \
  --name demo-synapse-0614 \
  --storage-account demosynapselake0614 \
  --file-system synapsefs \
  --location japaneast \
  --sql-admin-login-user sqladminuser \
  --sql-admin-login-password "<強力なパスワード>"

# 専用 SQL プール(DWH)を作成(パフォーマンスレベルを指定)
az synapse sql pool create \
  --resource-group demo-rg \
  --workspace-name demo-synapse-0614 \
  --name demoSqlPool \
  --performance-level DW100c

# 不要な時間帯は専用 SQL プールを一時停止してコンピューティング課金を止める
az synapse sql pool pause \
  --resource-group demo-rg \
  --workspace-name demo-synapse-0614 \
  --name demoSqlPool

Azure Service

Azure Synapse Analyticsを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

分析

比較で見る軸

クラウド: Azure / カテゴリ: 分析 / 難易度: intermediate

導入後に効く点

Data Lake 上のファイルを移動せずにそのまま SQL や Spark で分析できる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
分析
難易度
intermediate
関連資格
設計柱
performance / cost

判断チェックリスト

  • 自社の用途が「分析 / performance」に近いか確認する。
  • 強みである「DWH(専用 SQL プール)と Spark、サーバーレス SQL を1つのワークスペースに統合する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

分析performancecost