クラウドDWHにおける観点とAzure Synapse Analyticsの対応

株式会社ジール
クラウドDWHにおける検討項目と
Azure Synapse Analyticsの対応
2020/12版

• 各社クラウドベンダーでは大規模データ分析向けのDWHサービスを提供しています。
本書ではDWHに必要とされる主要な観点をベースに、Azure Synapse Analyticsをサン
プルとして解説し、製品評価のための理解を促進することを目指します。
本資料の位置づけ
クラウドで提供されるDWHサービス
Azure Synapse Analyticsの実情は？
様々な売り文句
無限のスケール?
簡単で強力な分析?
クラウドネイティブ、管理不要?
費用対効果の高いDWH?

アジェンダ
1. [概略]現代のDWHアーキテクチャ
2. Big Data基盤上での立ち位置
3. 検討ポイントとAzure の対応
1. 機能
2. 非機能

[概略]現代のDWHアーキテクチャ

STEP1 STEP2
STEP1 STEP2
ディスクから
データを読み込み
中間処理はキャッ
シュを利用
Cache
Driver
Cache
Task
Cache
TaskTask
• データ量の増大
• 非構造データ対応
• 求められる処理能力
• クラスタ管理の煩雑さ
• 繰り返し処理時の非効率性
• 高速インタラクティブ処理
への要望（機械学習）
• インメモリ高速分散処理基盤
• Hadoopの不得意な部分に改善を加
え、ビッグデータに対するバッチ処
理/リアルタイム処理/インタラク
ティブ分析（繰り返し処理）を高速
実現
ビッグデータ処理技術のトレンド変遷
HadoopとSpark

現代のDWHのアーキテクチャ
• OLTP処理向けの従来のDBMS製品でのスタンダー
ド
• ディスク、メモリが複数のCPUに共有される
• →CPU性能の頭打ちなどの背景から、ビッグデータ
に対する大量処理要件を満たすことができなくなっ
た
• 大規模データ対応のDWH製品でのスタンダード
• ディスク、メモリは各ノードで独立(Shared
Nothing)
• データは分配され、各ノードで並列に処理される
• Control Nodeがクエリの分配、整合性をチェック
SMP (対称型マルチプロセッシング ) MPP (超並列処理)
Disk
CPU CPU CPU
Shared Memory
Worker Node
CPU
Memory
Disk
・・・
Disk
Worker Node
CPU
Memory
Control Node
ABC XYZ
・・・
ABC…XYZ
Shared Disk型の構造 Shared Nothing型の構造
ビッグデータへの対応

列指向ストレージ
• OLTPシステム向けの従来のストレージシステム
• データ（ブロック）は1レコードを構成する複数列
が格納される
• 集計クエリでは特定のカラム集計値もすべてのカラ
ムをリードする必要がある
• DWHなど分析システム向けのストレージシステム
• データ（ブロック）は複数行にまたがって一つの列
が格納される
• 分析クエリでは通常少数の列しか利用しないため、
必要なスキャンのみを実施可能
行指向ストレージ列指向ストレージ
参考：https://www.slideshare.net/nttdata-tech/bigdata-storage-layer-software-nttdata
対象列対象列対象列対象列

• 一般に圧縮効率はユニークなデータが少ないほど高効率となる
• 列指向ストレージでは列ごとのデータ形式となるため、同じ値
が頻出することが多く（カーディナリティが低い）、データ圧
縮の効果が高い
列指向ストレージによる圧縮の効率化
ID ユーザ名都市性別
1 AAA Tokyo 男
2 BBB Osaka 女
3 CCC Nagoya 男
同一のデータが頻出
列のデータ型毎に最適な圧縮技法を利用可能

• データ指向アプリケーションデザイン ―信頼性、拡張性、保守
性の高い分散システム設計の原理 Martin Kleppmann
https://www.amazon.co.jp/dp/4873118700/ref=cm_sw_r_tw_dp_U_x
_q2MWEbDRE3905
参考文献
9

Big Data基盤上での立ち位置

従来の分析基盤
ETL Tool
エンタープライズDWH
Extract
生データ
Load
加工済み
データ
Transform
BI Tools
Data Marts
Data Lake(s)
Dashboards
Apps

データレイクの導入
ETL Tool
BI Tools
生データ
スケーラブル
ストレージ&
コンピュート
(HDFSなど)
Transform & Load
Data Marts
Data Lake(s)
Dashboards
Apps
ストリームデータ
エンタープライズDWH
Ingest (EL)
Operational DWHなど

DatalakeとDWHの利点と課題
Datalake
• 柔軟に大容量データを格納可能
だが
• メタデータ管理の難しさ（データ沼）
• データレイク内のデータ更新は不可能
• データレイクへのクエリ速度は低い
DWH
• 豊富なRDBMS機能と高速クエリ
だが
• アクセスがSQLに限定
• 構造化データのみの蓄積
• スケーリングの難しさ

レイクハウス型アーキテクチャ
• どちらか、ではなくいいとこどりを目指すのが主流
Datalake × DWH
Datalakeとしての層＋DWHとしての層
ニーズあらゆるデータサイロの解消
エンタープライズレベルの
データ分析
ワークロードデータ探索、機械学習、ストリーミング分析 BI,ダッシュボード、OLAP分析
メリット
クラウドストレージに代表されるスケーラビ
リティとコスト効率
あらゆるデータ形式への柔軟な対応
ACIDトランザクション
高速クエリ
データモデル一貫性
RDBMSで成熟した開発管理タ
スクやセキュリティ対応

• 機能
• データレイクと統合されたDWH機能（ETLを含む）について
• 大量処理を実現するデータ保持形式や読み取り最適化方式について
• 機械学習、準リアルタイム分析の対応
• その他、Bigdata分析に役立つデータベース機能について
• 非機能
• Microsoft Azure Well-Architected Frameworkを基本とする
（https://docs.microsoft.com/ja-
jp/azure/architecture/framework/）
※類似にAWS Well-Architectedあり
（https://aws.amazon.com/jp/architecture/well-architected/）
観点の整理方針

17
PlatformPlatform
評価の前提
SQL DWはAnalytics用途のPaaSを包括した総合的なサービスとして、Azure Synapse Analyticsという名称にリブランディングさ
れ、DWH機能として統合されました。
本資料では、基本的に「 Dedicated SQL Pool 」を軸に評価し、「Serverless SQL Pool」、「Spark Pool」を周辺機能として位
置づけます。
SQL Data Warehouse
SQL Pool(On-Demand)
[Preview機能]
サーバレスなSQL クエリエンジン
[一般提供済]
永続化されたエンタープライズ向け
MPP型DWH
Spark Pools
Analytics Runtimes
一機能として統合

• 一部のクラウドでは分析アーキテクチャを統合し、複雑さを排除する方向に拡張。
• Synapse Analyticsでもデータプラットフォームに必要な収集・加工・提供などの機能を集約し、
従来のDWHは分析ワークスペースの中の１機能へ。
補足：Azure Synapse Analyticsによる
周辺機能の統合

検討ポイントとAzure の対応

比較ポイントの一覧
# 分類比較ポイント
1 機能データレイクと統合されたDWH
2 機能データの保持形式や読み取り最適化
3 機能機械学習・ニアリアルタイム分析
4 機能その他のDB機能
5 非機能コスト
6 非機能開発・運用保守性
7 非機能回復性・可用性
8 非機能スケーラビリティ
9 非機能セキュリティ

データレイクとの統合（機能）
21

• AzureではAzure Data Lake Storage Gen2をデータレイクとして構成｡
• Spark によるETLおよび、データレイクへのSQLクエリによりクエリ用テーブルにロード
される。
データレイクとの統合
Store
Transform QueryIngest
Synapse Pipeline
Azure Data Lake
Storage Gen2
Spark Pool SQL Pool
クラウドデータ
SaaS データ
デバイスデータ
Power BI
Azure
Machine Learningオンプレミスデータ
Azure Analytics

データレイクのキュレーション工程
リレーショナル
データベース
ファイル
メッセージ
csv
txt
json
parquet
Landing
揮発性の生データ
Bronze
蓄積用の構造化生データ
Silber
クエリ可能
Gold
レポート利用可能
Query Optimized
parquet
parquet
parquet
parquet
parquet
parquet
データソースデータレイク DWH

データレイクのキュレーション工程
リレーショナル
データベース
ファイル
メッセージ
csv
txt
json
parquet
Landing
揮発性の生データ
Bronze
蓄積用の構造化生データ
Silber
クエリ可能
Gold
レポート利用可能
Query Optimized
parquet
parquet
parquet
parquet
parquet
parquet
データソースデータレイク DWH
サーバレスSQLによる論理DWH
→探索最適化
専用SQLによる
物理DWH→分析最適化

補足：ストレージ層での先端技術 Delta Lake
• Databricksの機能であったDelta
をOSS化（昨年のSpark + AI
Summit 2019 Keynoteで発表）
• ファイルシステム上で動作し
UpdateなどのDML実行が可能
• 実態はparquetファイルのため高
圧縮率
• 現在version 0.7.0
• Synapse Sparkでも利用可能
• https://delta.io/

補足：Delta Lake主要機能
• Delta Lake Summary
Bigdataシステムで肥大した大規模なメタデータを分散処理可能
バッチデータ、ストリーミングを容易に統合
挿入データのスキーマ不正を自動検証
マージ、更新、および削除操作（DML）をサポートして複雑なユースケースを実現
データのバージョン管理により、ロールバック、完全な履歴監査証跡、機械学習の再現が可能
読み取り結果の不整合を防止

Delta Lake 活用シーン①
-安全なデータの追加
• 追加（append）、
上書き（overwrite）操作をアト
ミックに実行
• テーブル挿入時には自動でス
キーマ検証を行い、不正データ
を例外処理することでデータを
保護
df.write
.format("delta")
.mode("append")
.save("/mnt/delta/events")
連携データ生データ保管
バッチデータ
保管テーブル追加 or 上書き
（ACID）
不正列データ生データ保管
バッチデータ
保管テーブルスキーマチェック

Delta Lake 活用シーン②
-DMLによるデータ更新
• Update、Delete、 Mergeをサ
ポートし、データの修正・削除
Upsertを実行
• タイムトラベルにより復元可能
• パーティションの利用により高
速化が可能
• Databricksでは先行利用できた
が、Delta Lake 0.3.0リリースで
実装（Announcing the Delta
Lake 0.3.0 Release）
ID eventType timestamp
1 clck 2020/4/1 23:00
2 clck 2020/4/1 23:01
3 conversion 2020/4/1 23:02 UPDATE events
SET eventType = 'click’
WHERE eventType = 'clck'
ID eventType data
1 click AAA
2 click BBB
3 conversion CCC
ID eventType data
3 conversion ccc'
4 conversion DDD
MERGE INTO events
USING updates
ON events.eventId = updates.eventId
WHEN MATCHED THEN
UPDATE SET events.data = updates.data
WHEN NOT MATCHED THEN
INSERT (date, eventId, data) VALUES (date, eventId, data)
ID eventType data
1 clck AAA
2 clck BBB
3 conversion ccc'
4 conversion DDD

Delta Lake 活用シーン③
-異なるソースデータの統合
• Structured-Streamingを利用し
たDataframe操作により、バッ
チ、ストリームを容易に結合可
能
• Structured-Streamingでは追加
されたファイルのみを正確に処
理
spark.readStream
.format("delta")
.load("/mnt/delta/events")
Or
events.writeStream
.format("delta")
.outputMode("append")
.option("checkpointLocation", “path")
.start("/delta/events")
ストリーム
データ
ストリーム
データ
バッチデータ
保管テーブル
保管テーブル
バッチデータ
保管テーブル
集計速報テーブル
統合テーブル
ストリーム
＆バッチデータ統
合テーブル

データレイクと統合されたDWHの観点
観点内容 Synapse
の対応
説明比較総評
入出力データレイク統合（外部
テーブル）
〇専用ストレージ外のデータへのアクセス機能
Dedicated SQL Poolでは外部テーブル(Polybase)の
作成が可能
Serverless SQL Poolではファイルに対するView作成
が可能
CSV、Parquetの場合、スキーマ推論が可能
一般的な機能
G社でもスキーマ推論が実装
データレイクからのデータ
ロード
◎ Copy コマンド、Polybase、Spark Pool APIを利用
したロードが可能。Pipeline機能でGUI作成可能とス
キルセットによる選択肢は豊富
Copyコマンドベースでのロードは一
般的
オープンな技術のデータ形
式への対応
△ 外部テーブルとして利用できるデータレイク上の
ファイル形式はParquet,CSV,JSONが利用可能
Spark PoolからはDelta Lakeにアクセス可能
A社ではDelta Lakeへのデータベー
スクエリが可能
保持テーブルをデータレイ
クにオフロード可能か
△ Serverless SQL PoolではCETASが利用可能だが、上
書き、更新が不可
Pipeline、SparkなどETL機能を利用してオフロード
をする
S社、A社ではSQLによるオフロード
を実行可能（上書き可能）
◎：優位性あり
〇：優位性は特にないが対応可能
△：対応できるが、劣勢
×：対応できない

データレイクと統合されたDWHの観点
の対応
説明比較総評
データ処理外部/永続テーブルに対す
る処理
〇 DWUを構成してT-SQLを実行
Serverless SQL Poolではサーバレス実行が可能
一般にDWHの処理性能が問われるのは
この部分である
ETL、オーケストレーショ
ンサービスが用意されてい
るか
◎ Azure Data FactoryでのGUI利用が可能（Synapse
Pipelineとして統合）
ADFではオンプレミスのSSIS の再利用が可能
各社オーケストレーションツールが用
意されているが、GUIでのETL処理の
充実性、コネクタの豊富さが強み
S社はADF対応
Spark,HadoopのETLが可
能か
◎ Databricksや、Spark PoolによるAutoScaleに対
応した利用が可能
PysparkにはSQL Analytics APIが容易されており、
容易なテーブル作成が可能
S社にSpark Connectorがあるように、
Spark対応自体は一般的だが、専用API
や、Synapse内でクラスタ管理ができ
ることを評価
データ探索データレイクに対しての
サーバレスアドホッククエ
リが可能か
〇 Serverless SQL Pool or Spark Poolで可能 A社、G社などでも可能
S社はクラスタを常に経由するので方
針は異なるが、同様のことが可能

• Azure Synapse Analytics (ワークスペースプレビュー) とは:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/overview-what-is
• SQL 分析用に Azure Data Lake Storage からデータを読み込む:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-load-from-azure-data-lake-store?toc=/azure/synapse-
analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json
• Azure Data Factory を使用した Azure SQL Data Warehouse へのデータの読み込み:
https://docs.microsoft.com/ja-jp/azure/data-factory/load-azure-sql-data-warehouse?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json
• Apache Spark を使用したデータのインポートとエクスポート:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/spark/synapse-spark-sql-pool-import-export
• Synapse SQL での CETAS:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql/develop-tables-cetas
• Synapse SQL で外部テーブルを使用する:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql/develop-tables-external-tables
• SQL オンデマンド (プレビュー) を使用した Azure Open Datasets の分析と Azure Synapse Studio (プレビュー) での結果の視覚化:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql/tutorial-data-analyst
• Azure Synapse Analytics の SQL オンデマンド (プレビュー) を使用して Parquet ファイルに対してクエリを実行する:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql/query-parquet-files?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json#automatic-
schema-inference
• Azure Cosmos DB の Azure Synapse Link (プレビュー) を構成して使用する:
https://docs.microsoft.com/ja-jp/azure/cosmos-db/configure-synapse-link?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json
• 概要:ストレージ内のデータを照会する:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql/query-data-storage?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json
• Azure Stream Analytics からの出力を理解する:
https://docs.microsoft.com/ja-jp/azure/stream-analytics/stream-analytics-define-outputs
• Azure Synapse Analytics の Apache Spark とは:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/spark/apache-spark-overview
• 構造化ストリーミング:
https://docs.microsoft.com/ja-jp/azure/databricks/spark/latest/structured-streaming/
• Delta Lake とは
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/spark/apache-spark-what-is-delta-lake
参考:データレイクと統合されたDWHの観点

データ保持形式や読み取り最適化方式
35

データ保持形式や読み取り最適化方式
• シェアードナッシング型のアーキテクチャではコンピュートとスト
レージが結合され、Nodeの追加に時間がかかる（リバランス処理）
• Azure Synapse Analyticsはコンピュートとストレージの分離された
アーキテクチャ上にSQLエンジンが配置される
• ストレージ分離により、性能変更が高速で実行可能。ただし、60ス
トレージに分散される方式のため、小さいデータも分散される、ス
トレージ間の移動を伴うクエリのパフォーマンスなど注意点が多い
通常のMPPアーキテクチャ Synapse Analyticsのアーキテクチャ概要
参考URL : https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_high_level_system_architecture.html
Azure SQLではSQL Server時代から改良され続けているオプティマイザと従来のSQL Sever
に準拠した機能をベースに提供している

• SQL Server では、プライマリインデックス（テーブルの実体
と一体化したインデックス）にクラスター化とつける
• クラスター→簡単に言うと行、もしくは列のデータの塊
• 列指向の保持形式をクラスター化列ストアインデックスという
補足：クラスター化列ストアインデックス

補足：データパーティショニング戦略
• 論理パーティションのほかに、DWH製品では分散といわれ
ることが多い。
• MPPのアーキテクチャでは各パーティションのデータを
Computeノードが並列で処理することで、大量データの処
理を行う
• 分散では各パーティション間のデータ移動を少なくする設
計が必要
• deleteよりもパーティション削除のほうが早い場合が多く、
ETL時のパフォーマンス向上にも有効
• 列毎にデータを保持することで必要なデータアクセ
ス量を削減する
水平パーティショニング（シャーディング）垂直パーティショニング
データのパーティション分割のガイダンス - Best practices for cloud
applications | Microsoft Docs

補足：パーティションプルーニング
Sql server パーティション概要 (slideshare.net)
• 一般に時系列で分割されたテーブルに対して、フルスキャンを
回避してアクセス量を削減する機能
• SQL Serverでは必要なファイルグループにのみアクセス
テーブルのパーティション分割 - Azure Synapse
Analytics | Microsoft Docs

データ保持構造と最適化の観点
の対応
説明備考
ストレージ列指向ストレージであ
るか
〇クラスター化インデックスとして列ストアを選択する(100万
行ごとで生成)
ロード時の処理低減のために行ストアも利用可能
列ストアは一般的だが、行・列でストア形式を
選択可能なのはSynapse,Sのみ
S社ではより詳細な単位となり、チューニング
は容易（16MB）
複数のDWHクラスタ
で同一データを共有
できるか
△ Sparkでテーブル化したParquetをSeverless SQL Poolか
ら利用するメタデータ共有機能あり（Parquetのみ。
DeltaLakeなどは未対応）
Dedicated SQL Pool間でのメタデータ共有は現状不可
S社のもっとも大きな利点として、専用ス
トレージ上のデータを複製せずにDWH間
で共有することができる
分散 MPPアーキテクチャ上
でどのようにデータ分
割し、スキャン負荷の
削減、分散を行うか
〇 3つの方式のどれかで60分割される。1億行以上のデータに対
して分散と列ストアが有効活用される
1. ラウンドロビン(既定)
2. Hash分散（一つのキー列に基づく。複数列を予定済み）
3. レプリケート
定数60での分割はSynapse独特。
分散キーの指定はA社でも同様
S社が特に細かい分割形式をとる（自動）
クラスタリング〇クラスター化列ストアインデックス（順序指定なし）が既定
行ストアor列ストアで作成可能
列ストアの場合、1,048,576 行でクラスタリングされる
S社が特に細かい分割形式をとる（自動）
パーティション
プルーニング
〇年月などの値範囲によりデータを分割、プルーニング可能
（年月の場合、年あたり12パーティション作成されるために
7.2億件/年以上での利用が推奨）
一般的だが、ベンダーにより呼び方が細かく異
なる。A社ではsortにて対応
S社はクラスタリングのキーを指定することで
実現

データ保持構造と最適化の観点
の対応
説明備考
インデックスデータの並び替え方法
とセカンダリインデッ
クスの利用可否
〇 • プライマリインデックス（クラスター化）
• 順序指定なしor 順序指定あり
• セカンダリインデックス（非クラスター化インデックス）
順序指定ありクラスター化列ストアが最もクエリ高速化の
ためのオプション。ただし、書き込み時のインデックス作
成時間とトレードオフとなる
インデックス機能は一般的だが、非クラスター
化インデックスはS社,Synapse固有
Materialized
View
集計済みの実体をもつ
Viewをどのように実装
するか
〇分散が可能
またオプティマイザにより、ベーステーブルへの参照時に
Viewテーブルへの参照に自動切換えされる（透過的な利用）
Power BI 統合による自動作成の評価次第で優位性が発揮され
る可能性あり
SynapseとG社、S社がオプティマイザによる
自動書き換えが可能
BIツールによる自動作
成
◎ Power BIでクエリされたデータを認識して、自動でViewを作
成する（Private Preview）
BIツールを同社で提供していることから生まれ
る独自の強み
結果セット
キャッシュ
クエリ結果をキャッ
シュし、迅速に再利用
可能か
〇同時実行数を消費せずに利用可能
上限1TB
48時間利用なしで削除
一般的な機能

• Azure Synapse Analytics (旧称 SQL DW) のチートシート
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/cheat-sheet#index-your-table
• ベストプラクティス：
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-best-practices-development
• 列ストアインデックス概要：
https://docs.microsoft.com/ja-jp/sql/relational-databases/indexes/columnstore-indexes-overview?view=azure-sqldw-latest
• 具体化されたビューを使用したパフォーマンスチューニング：
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/performance-tuning-materialized-views
• 順序指定クラスター化列ストアインデックスを使用したパフォーマンスチューニング：
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/performance-tuning-ordered-cci
• 結果セットのキャッシュを使用したパフォーマンスのチューニング：
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/performance-tuning-result-set-caching
• Synapse SQL プールでのテーブルのパーティション分割:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-tables-partition
• Synapse SQL プールでの分散テーブルの設計に関するガイダンス:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-tables-distribute
• 列ストアの行グループの品質を最大限にする:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-memory-optimizations-for-
columnstore-compression
• メタデータ共有
https://qiita.com/ryoma-nagata/items/300ae6df431642bc9919
• メタデータ共有概要
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/metadata/overview
• Power BI performance accelerator for Azure Synapse Analytics (private preview)
Powering data exploration and data warehousing with new features - Microsoft Tech Community
参考:データ保持構造と最適化の観点

機械学習・ニアリアルタイム分析
43

Azure Cosmos DB と
Azure Synapse Analytics を使って、
リアルタイム HTAP ソリューションを構築
Azure Synapse Link for Cosmos DB
D15 | Azure Cosmos DB - Build 2020 アップデート | de:code
(decode) 2020 (microsoft.com)

 Azure Cosmos DB は、
10 ミリ秒未満の読み取り/書き込み
レイテンシを提供し、オペレーショナル
ワークロードに最適化
 99.999% の高可用性、スループット、
整合性の保証
 Azure の全リージョンにわたる、
ターンキーのグローバルデータ
レプリケーション
Azure Cosmos DB
リアルタイム
アプリ/サービス
Azure
Cosmos DB

大規模なオペレーショナルデータで
準リアルタイムに分析を実行したい場合は、
どうするか?

 大量のデータがある場合、
分析クエリの実行には時間が
かかり、リソース集中型になる
 OLTP ワークロードの
パフォーマンスへの大きな影響
同一データベース上で
OLTP/OLAP ワークロードを実行
リアルタイム
アプリ/サービス
Azure
Cosmos DB
レポート /
ダッシュボード

ユーザー
アプリ
Azure
Cosmos DB
Azure Data Lake Storage
抽出
(パイプライン)
変換 /
強化
オーケストレーション
Power BI
提供
Azure Cosmos DB から Azure Data Lake Storage に定期的にデータをインジェスト
分析に最適化するために、データ形式とストレージレイヤーを管理
Apache Spark
for Synapse
Synapse
SQL
OLTP と OLAP を分離

 準リアルタイムのデータ分析
 トランザクションワークロード
へのパフォーマンスの影響なし
 ETL が不要
Azure Synapse Link for Azure Cosmos DB

分析ストア
分析クエリに最適化された「列ストア」
トランザクションストア
トランザクション操作に最適化された「行ストア」
Azure Cosmos DB Azure Synapse Analytics
コンテナー
クラウドネイティブ
HTAP
Azure
Synapse
Link
SQL
自動同期
機械学習
ビッグデータ分析
BI ダッシュボード
オペレー
ショナル
データ
オペレーショナルデータに対する準リアルタイムの洞察を生成
Azure Synapse Link for Azure Cosmos DBの動作

ニアリアルタイム分析のユースケース例
サプライチェーンの分析、予測、およびレポート作成
出典：Azure Synapse Link for Azure Cosmos DB を使用したリアルタイム分析のユースケース | Microsoft Docs

ニアリアルタイム分析のユースケース例
IoT予測メンテナンス
出典：Azure Synapse Link for Azure Cosmos DB を使用したリアルタイム分析のユースケース | Microsoft Docs

• Common Data Model 1.0フォーマットでAzure Data Lake Storage Gen2内に書き込み/読み取りを実行可能
• Dynamics 365 やPower BI DataflowなどのCDM形式に対応したサービスとのデータおよびスキーマ情報の連携が容易になる
※Power BI Dataﬂowでは旧形式のmodel.jsonを利用しているので、未対応の可能性
• Data Factory でもCDMフォルダのサポートを開始されているのでCDMの展開に期待
補足：Apache Spark 用の新しいCommon Data Model コネク
タ (Public Preview)
• https://azure.microsoft.com/en-us/updates/new-common-data-model-connector-for-apache-spark-in-azure-synapse-azure-databricks/
• https://docs.microsoft.com/en-us/common-data-model/data-lake
Azure Data Lake Storage Gen2
No code ,low code Low to high code

• Azure Machine Learning に登録された ONNX 形式のML モデルを Synapse Studio で数クリックで利用可能
• 専用 SQL プールで T-SQL PREDICT 関数をラップしたストアドプロシージャを使用してスコア付け
• チュートリアル:専用 SQL プール向けの機械学習モデルスコアリングウィザード - Azure Synapse Analytics
Ignite 2020 Update Azure Synapse Analytics - Speaker Deck

IoTデバイス IoT hub Stream Analytics リアルタイムダッシュボードCosmos DB
Machine Learning
サーバレス SQL プール
専用 SQL プール
サーバレス Spark プール
ホットパス
コールドパス

機械学習・ニアリアルタイム分析の観点
の対応
説明比較総評
ニアリアル
タイム分析
ストリーミングデータの取
り扱いが可能か
◎ Stream Analyticsによる、200MB/sのインジェス
トを利用
一般にファイルの到着をニアリアルタ
イムで処理が可能だが、ストリーム
データの直接のインジェストは
Azure,A社が対応
運用データに対するニアリ
アルタイム分析が可能か
◎ Cosmos DB Synapse Linkにより、HTAP構成が可
能
Common Data Modelへのアクセスにより、
Dynamics,Power PlatformからDatalakeに出力さ
れるデータに対してSparkを用いた分析が可能
Synapse Linkにより、OLTP処理用の
CosmosDBから、分析用ストアに
NoETLで変換でき、SQL, Sparkでのア
クセスが可能となることが新しい強み
となる
Common Data Modelデータに対して
は現状Spark のみ対応
機械学習ＭLサービスとの連携〇 Azure ML 連携（Spark からの呼び出し、SQL
Poolでの利用）が可能
各ベンダーでML連携が意識されてい
る
Notebook UIによるＭL開
発
◎ Spark Poolには各種MLライブラリがビルトインさ
れたnotebook UIが提供
Sparkの利用は一般的だが、Notebook
ＵI提供まで同一サービス上での提供は
独自
自動機械学習 ◎ Azure ML と連携し、右クリックで開始可能 A社でＭL連携が登場
MLモデルの利用 ◎ Azure ML に登録されたモデルをSQL Poolにイン
ポートして、テーブルデータにスコアリング可能
A社でＭL連携が登場

• Building real-time enterprise analytics solutions with Azure
Synapse Analytics
• Azure Synapse Link for Azure Cosmos DB にはどのような利点があ
り、いつ使用するか | Microsoft Docs
• B07 | Power Platform で広がるデータインテグレーションの世界
(1/2) | de:code (decode) 2020 (microsoft.com)
• Azure Synapse Analytics の機械学習 - Azure Synapse Analytics |
Microsoft Docs
• チュートリアル:専用 SQL プール向けの機械学習モデルスコアリン
グウィザード - Azure Synapse Analytics | Microsoft Docs
• チュートリアル:AutoML を使用した機械学習モデルトレーニング -
Azure Synapse Analytics | Microsoft Docs
• チュートリアル:Apache Spark MLlib で機械学習アプリをビルドす
る - Azure Synapse Analytics | Microsoft Docs
参考:機械学習・ニアリアルタイム分析

その他のDBMS機能の観点
観点内容 Azure
Synapse
説明備考
RDBMS機能 ACIDトランザクショ
ンが実行可能か
〇 SQL Serverベースのサービスであるため、標準で搭載 Delta Lakeではストレージレイヤで
実行可能
タイムトラベ
ル
指定した過去時点の
データにアクセス可
能か
× Synapse では利用不可 S社やDelta Lakeでは実行可能（期
間の制限あり）

• Read older versions of data using time travel:
https://docs.delta.io/latest/quick-start.html#-read-older-
versions-of-data-using-time-travel
•
参考:その他のDB機能の観点

ソフトウェア品質の重要な5大要素
前提：クラウドアプリケーションの評価軸
# Azureにおける品質特性説明
1 コスト最適化もたらされる価値を最大化するためのコスト最適化プロセスです。
2 オペレーショナルエクセレンス運用環境でシステムを継続的に動作させる運用プロセスです。
3 信頼性障害から回復して動作を続行するシステムの能力です。
4 パフォーマンス効率負荷の変化に対応するためのシステムの能力。
5 セキュリティ脅威からアプリケーションとデータを保護することです。
https://docs.microsoft.com/ja-jp/azure/architecture/framework/

• Azure Synapse Analyticsでは大きく三種の機能に課金モデルがある（データレイクの課金は記載外）
• 時間単位の切り上げ方法など細かな違いはあれど他社のDWHも以下のどれかの考え方が適用可能（複数クラ
スターの場合がある）
ジョブコスト＝実行時間(m)
処理コスト＝性能×実行時間(m)
SQL Pool
(DWHクラスター)
• いわゆるクラスターに対する課金
• 性能部分は停止が可能
• 性能は事前に設定
Azure Synapse Analytics 課金モデル概要
SQL On-demand
(サーバーレスクエリ)
• サーバレスのため、処理性能の課金はない
• コスト制限が可能
Spark for Synapse , Synapse Pipeline
(ETL機能)
• 処理、ジョブ機能（オーケストレーショ
ン）に対する課金
• 処理性能はオートスケール
構成済みDWH
(クラスター)
コスト＝保存量＋性能×起動時間(h)
＋
コスト＝クエリデータ量

コスト最適化の観点
観点内容対象 Synapse
の対応
説明備考
従量課金利用しただけの課金
結果となりやすいか
DWH △ 時間単位での課金となる。
クラスター性能の増減、停止、再開は顧客側で自動
化などの設定をする必要がある
ストレージコストは1TBからスタート
※Shrink問題
A社、S社などでは秒単位課金、
スケジュール停止（S社は自動）、
クラスター数の自動増減などが可
能。（クラスター単体の性能増減
についてはAzureと同じ）
ストレージコストについてはより
低容量からのスタートが多い
サーバーレス
クエリ
〇クエリ量に対する課金のためオンデマンド課金とい
える
一般的
ETL 〇性能は上限を設定してCore数が自動増減されるため、
基本的に実行時間で考えることができる。
一般的
予測可能性コストを試算するこ
とが容易か
DWH 〇性能、起動状態が明確で、停止再開が高速（3～5
分）のため、課金の予測が容易
オンデマンドであることとトレー
ドオフ
S社ではエディションを選択可能
だが機能が異なることに注意
サーバーレス
クエリ
〇データ量課金のため、正確な予測は困難。
アドホッククエリの量で試算可能。上限設定可能
一般的だがG社では上限が設定で
きる
ETL △ やや複雑。毎日のジョブ時間が予測可能であれば試
算可能。
一般的
コスト管理監視の手法はあるか - 〇コストマネジメントによる、アラート・予算設定・
可視化・推奨事項提示が可能
各社で工夫するための機能あり
最適化手法はあるか - 〇事前予約によるコストダウンが可能一般的
参考：https://docs.microsoft.com/ja-jp/azure/architecture/framework/cost/overview

• コスト最適化の原則:
https://docs.microsoft.com/ja-
jp/azure/architecture/framework/cost/overview
• Azure Cost Management および Billing のドキュメント:
https://docs.microsoft.com/ja-jp/azure/cost-management-billing/
• コスト最適化チェックリスト:
jp/azure/architecture/framework/cost/optimize-checklist
• Azure Synapse Analytics の価格:
https://azure.microsoft.com/ja-jp/pricing/details/synapse-analytics/
• サーバーレス SQL プールのコスト管理 - Azure Synapse Analytics |
Microsoft Docs
• Azure Data Factory の価格を実例から理解する - Azure Data Factory |
Microsoft Docs
参考：コスト最適化

オペレーショナルエクセレンス
68

Azure Synapse Analytics 開発・運用保守性
Collaboration
Data Engineering
自動テスト・自動リリース(Dev Ops) 自動テスト・自動リリース(Dev Ops)
Analytics + Machine Learning
モデル学習・配置の自動化(ML Ops)
開発・コード管理
分析者・データサイエンティスト
DB管理タスク分析・データ探査・ビジュアル開発
開発者意思決定者・業務ユーザー
モデル開発・コード管理
• 開発から運用まで、周辺ツールと組み合わせたサイクルが想定されたサービス提供
• 開発・運用：Github、AzureDevOps、Visual Studio（DB Project）などと連携した開発効率化
• 民主化・共有：Teams、SharePoint、Power BI Serviceなどとの統合
Board によるアジャイル開発 Board によるアジャイル開発 Sharepoint,Power BIによる共有
ReposSynapse Studio SSMS Power BI desktop Synapse Studio Azure ML Repos
PipelinesPipelines開発環境本番環境推論アプリ学習済みモデルPipelines開発環境本番環境
Communication Communication
ID Management

オペレーショナルエクセレンスの観点
の対応
説明備考
DevOps 開発チーム、ユーザー
がが情報を共有する基
盤が提供されているか
◎ Azure DevOps、 Teamsなど、周辺ツールによるコラボ
レーションが充実
SynapseというよりAzureだが、
Office系との統合は強みとなる
開発ツールの充実性 ◎ Visual Studio,SSMS,AzureDataStudioなど開発管理ツー
ルが充実
SQLServer時代からの蓄積が強み
コード管理が可能か〇 Azure Repos or Git hubでgit管理が可能 Git hub を使うことが一般的
テスト・リリースの自
動化が可能か
◎ Azure Pipelineではgitと連動して、テストリリースパイプ
ラインが構成可能
一般的だが、Azure DevOpsに統合さ
れているのは強み
監視サービスヘルスを監視
可能か
〇 Azure Monitorとの連動が可能一般的
性能監視機能があるか〇 DMVにより実施
https://docs.microsoft.com/ja-jp/azure/synapse-
analytics/sql-data-warehouse/sql-data-warehouse-
manage-monitor
一般的
自動化環境をコード化するこ
とが可能か
〇 Teraformなど3rdパーティを利用することが一般的。
Azureの標準で検討するとARMテンプレートの学習コスト
が発生
Armの仕組みはAzure固有だが、各社
Teraformなどを利用することが一般
的
参考：https://docs.microsoft.com/ja-jp/azure/architecture/checklist/dev-ops

オペレーショナルエクセレンスの観点
の対応
説明備考
自動化管理タスクは簡略化さ
れているか
△ 自動バックアップなどが既定で準備
管理タスクはGUIで実行可能
性能変更の自動化は基本的にFunctionなどで実装
（テンプレートが提供）
インフラ管理不要は一般的
管理タスクは各製品で知識が必要
S社で管理タスクを低減し、ニアゼロマネジ
メントとしている
チューニングは簡略化
されているか
× 複雑であるが、細かな設定が可能との裏返しともな
る。また、アドバイザ機能は優秀
いずれの製品も最適化のためのパラメータ
は多い。
S社は管理タスク同様、自動化傾向が強い
ベンダーロッ
クイン
提供プラットフォーム
は固有ではないか
× プラットフォームとしてもAzure外でのSynapseの提
供はない
Synapseではないが、Azure Arcが方向性となってい
る
唯一S社はマルチプラットフォーム対応
スキルが再利用可能か〇 SQL Serverベースの知識が必要だが、
基盤全体ではPyhon,Spark,parquet,DeltaLakeなど
オープンな技術利用が可能。
A社であれば PostgreSQLベース
S社ではSQL:1999ベース
だが、固有の機能呼び出しに各社固有の知
識が必要となる。Python , Sparkは一般的に
も対応の方向

• Microsoft の DevOps への道のり:
https://medium.com/@yuhattor/microsoft-%E3%81%AE-devops-%E3%81%B8%E3%81%AE%E9%81%93%E3%81%AE%E3%82%8A-db59c0848d78
• Microsoft がアジャイルの原則をどのようにチームに適用したか
https://medium.com/@yuhattor/microsoft-
%E3%81%8C%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AE%E5%8E%9F%E5%89%87-
%E3%82%92%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AB%E9%81%A9%E7%94%A8%
E3%81%97%E3%81%9F%E3%81%8B-297b97de810
• Azure DevOps:
https://azure.microsoft.com/ja-jp/services/devops/
• Azure Data Factory における継続的インテグレーションとデリバリー:
https://docs.microsoft.com/ja-jp/azure/data-factory/continuous-integration-deployment
• Azure 上の Terraform のドキュメント:
https://docs.microsoft.com/ja-jp/azure/developer/terraform/
• ARM テンプレートのドキュメント
https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/
• Visual Studio Code Azure 拡張機能
https://code.visualstudio.com/docs/azure/extensions
• Azure と GitHub の統合:
https://docs.microsoft.com/ja-jp/azure/developer/github/
• データウェアハウジングのための継続的インテグレーションと継続的デプロイ:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-continuous-integration-and-deployment
• Synapse SQL プールでの管理容易性と監視:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-overview-manageability-
monitoring?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json
• DMV を使用して Azure Synapse Analytics SQL プールのワークロードを監視する
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-manage-monitor
• Synapse SQL のレコメンデーション
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-concept-recommendations
• #AzureSQLDW cost savings with Autoscaler – part 2 | Azure Blog and Updates | Microsoft Azure
開発・運用保守性の観点

信頼性の観点
の対応
説明備考
可用性 SLAが示されているか〇 https://azure.microsoft.com/ja-
jp/support/legal/sla/synapse-analytics/v1_0/
一般的
高可用性構成が構成
可能か（単一リー
ジョン）
〇マネージドである。アーキテクチャの公開はしていない
が、コンピュートレベルでの可用性構成はとられている
(Services Fabricで構成)
A社もSynapseと同様の対応
S社ではプラットフォームレベルで
レプリケーション（別エンドポイン
ト）を構成可能
高可用性構成が構成
可能か（マルチリー
ジョン）
× 地理的な冗⾧化は不可
回復性 DC障害時にフェール
オーバーが可能か
△ ペアリージョンにGeoバックアップがとられている。
ただし、手動リストアとなる
バックアップのRTO △ SQL プールでは8 時間(7日間保持)
Geoバックアップは1日に1回
リテンション最大期間は一般と比べ
ると短い。
S社は更のたびに履歴作成するため、
タイムトラベルと合わせて協力
リソース誤削除の対
応が可能か
△ SQL Serverが残っている場合、メンテナンスで実行され
た、バックアップから復元可能
それ以外にサポートチケットによる対応が可能
S社では5日間の復元期間が明記

• 自動復元ポイント:
analytics/sql-data-warehouse/backup-and-
restore#automatic-restore-points
• SQL プールの geo リストア:
analytics/sql-data-warehouse/sql-data-warehouse-restore-
from-geo-backup
• 復元ポイントからの復元:
analytics/sql-data-warehouse/backup-and-
restore#restoring-from-restore-points
参考：回復性・可用性の観点

パフォーマンス効率
76

• スケーリング
• アクセス負荷分散＝スケールアウト
• 処理性能向上＝スケールアップ
• 分散処理のアーキテクチャではノード数を増やすことで処理負荷を分散
• マイクロサービスの思想
• パフォーマンス（ワークロード）を分離する
• 適材適所のデータストア選択
• SQLクエリ→DWH
• SQLクエリを発行する人＝限定的に準備されたDWH
• BI→BIサーバ
• 事前にインメモリDBにキャッシュすることによるレスポンス確保
• 地理的にユーザに近い場所へのコンテンツの配置（CDN的発想）
• 異なる利用であれば異なるリソースで
• 同じリソースで様々なことしない
• 利用シーンごとに物理的に分離されているほうが適切な性能確保がしやすい
• →配置が簡単なクラウドのメリットの教授
一般的なパフォーマンス確保の原則

• DWHのスケーラビリティは基本的に以下の3点についての対応が必要
• 集計規模の増大への対応
• 同時実行クエリ数の増大への対応
• 容量増大への対応
• Azure Synapse Analyticsでは以下のような特徴で最大のコストパフォーマンス
がベンチマークとして記録されている
• コンピュートとストレージの分離
• シングルクラスター
• 無制限のストレージ
Azure Synapse Analytics スケーラビリティ

• コンピュートとストレージが分離しており、個別の拡張が可能
• 容量のみ増大(1TB～∞）
• 性能のみ増大（0.25～60ノード）
集計規模増、ストレージ容量増への対応

同時実行数増への対応
• 同時実行数は単一クラスター性能の上限で頭打ち • クラスター数を増大することで同時実行数を増大
※性能に余剰があってもクラスター増される
Synapse DW(シングルクラスター) クラスタースケールアウト
Compute Compute
Control Node
Primary
Cluster
Compute Compute
Control Node
Data
Temp
Cluster
• Azure Synapse Analyticsはシングルクラスター構成をとり、クラスタースケールアウト未対応のため、同時実行数が
128で頭打ちとなる。
※大規模クエリ対応≠同時実行数対応ではない
Compute Compute
Control Node
Primary
Cluster
Data
大規模クエリ
対応
同時実行数は128で頭打ち
同時実行数を増大
大規模クエリ
対応 Read レプリカ

• コストを予測可能にしつつ、性能を無駄なく使うための機能をそろえている。
• 結果セットのキャッシュ…同一のクエリはメモリから応答し、同時実行数を消費しない（100～400msec応答）
• ワークロード管理
• ワークロード分離…グループごとに性能上限を設定する。未使用の性能は上限を超えて利用する
• ワークロードの重要度…先入先出ではなく重要なグループのクエリは割り込み実行する
Azure Synapse Analyticsの同時実行戦略
Workload Isolation
ワークロード分離
Marketing
40%
60%
Sales
60%
100%
Compute
1000c DWU
Workload Importance
ワークロードの重要度

補足：パフォーマンス分離の対応
• 識別子で性能上限を指定する＝配分での対応 • ワークロードの完全な分離
Synapse DW(シングルクラスター) マルチクラスター
クエリ用クラスター
Primary
Cluster１
ETL用クラスター
Data
Primary
Cluster２
• 現状Synapseのワークロード分離は厳密にパフォーマンスの分離ではない
• シングルクラスター方式：同一のクラスタ内でユーザやクエリタイプで性能上限を割り当て
• マルチクラスター方式：同一データに対してクラスターを複数配置※スケールアウトはそれぞれのクラスタで対応
クエリ
用：
40%
Primary
Cluster
Data
ETL用:60%

中小規模のDWスぺックで実行可能な32をベースに40 個の同時実行クエリの例を想定して、同時実行数を完全消費する例について考える。
前提:
平均クエリ時間: 30 秒
同時実行時間: 1 時間 (計算のため)
1 時間の秒数: 3600 秒
同時実行の秒数: 144,000 秒
(3600 秒 * 40 個のクエリ)
時間を埋めるのに必要となる一意のクエリ数: 4,800 個
(504,000 秒/30 秒)
結果: 結果セットのキャッシュなしで 1 時間 40 個の同時実行クエリを
実行するための容量を妥当なものにするには、その時間内に最大 4,800 個の
一意のクエリが必要になる。
とはいえ、同時実行数を向上させるためにはDWの性能増が必要なので、コストパフォーマンスではマルチクラスタが勝るケースもある。
※最大スペックである128をベースに140の同時実行クエリ例で考えると、完全消費する例は16,800個の一意クエリ/時となる
同時実行に関する計算例

SQLを書かないユーザへのOLAPデータマートとしてインメモリ分析データベースを構成
戦略２：ポリグロットデータストア
Azure
Synapse Analytics
Reporting Data Warehouse
業務ロジック、計算式
データモデリング
行レベル
セキュリティ
Azure Analysis Services
Or Power BI dataset
Visual Studio による
コード管理
インメモリ
キャッシュ
Semantic Layer

DWHに直接業務ユーザーがSQLを発行するケースがあるかを考える。
「セマンティック層」で分析データを保持する場合も含めて検討する。セマンティック層がクエリを
発行するケースもある場合はDWHの同時実行数を考慮
(補足)BIツールとセマンティック層
Reporting
(Power BI , Qlik ,Tableau , Excel)
Semantic Layer
(Power BI Dataset, Analysis Services)
Data Warehouse
(Synapse Analytics)
Data Sources
ビジネスユーザーの分析を支援するためのセマンティッ
クモデルの役割
• ビジネスロジックの共通化
• リレーション構造のモデリング
• データアクセス制御
• データ取得先に対するクエリの作成・発行
• 物理名から分析用の名称の変換・多言語
対応
• 同時実行数増のためのスケールアウト
…etc.
BIセマンティックモデル
データ統合
クエリ結果取得
OLAP分析操作

パフォーマンス効率の観点
の対応
説明備考
拡張の対応クエリ規模増大への対
応が可能か(スケール
アップ)
〇ノード数を増やすことで対応。 Synapseのサイズスぺックは他社と比べて
詳細に変更可能
中断せずに性能変更可
能か
× オフライン操作となる S社がオンラインスケーリングに対応
容量増大への対応が可
能か
〇無制限一般的
同時実行数増大への対
応が可能か
△ 128までとなる。
ワークロード管理機能、Result Set Cacheを利用す
ることで回避する。
128まで増大させる場合、スケールアップが伴うた
め、同時実行数のみの増大は不可
他社ではクラスタースケールアウト戦略を
とっていることが多い
AzureではOLAP用データマートを作成する
方針が主流
性能の配分が可能か〇ワークロードの分離機能で、ワークロードグループ
ごとに性能の配分を指定可能
性能をワークロードグループごとに分離す
ることはSynapse固有だが、
S社は同一のデータに対してクラスターを複
数建てることが前提のため、多少余剰が
あっても明快
クラスターの分離が可
能か
× SQL Poolを複数利用する場合はデータ共有をするた
めにParquet共有などを利用する。最適化には専用
ストレージに個別でロードが必要
S社のマルチクラスタ（ストレージ、コン
ピュートの分離）戦略の強み。手軽だがコ
ストに注意が必要
クエリの割り込みが可
能か
◎ FIFOを基本とするが、ワークロードの重要度設定に
より、割り込みが可能
一般的にはFIFOで処理されるため、独自機
能である

パフォーマンス効率の観点
の対応
説明備考
拡張の柔軟性自動拡張が可能か △ 不可。他サービスで機能を開発することとなるサイズ変更が手動であることは一般的
他社では同時実行数拡張が自動化が強調さ
れている。
Synapseはワークロードごとに性能を割り
当てる独自の戦略
拡張は速やかに完了す
るか
〇ストレージコンピュートが分離されているので数分
で完了
Synapseは高速な部類だったが、一般的と
なっている
クラスターの構成が速
やかに完了するか
△ S社のクラスタ構成速度は秒単位

• Data Warehouse ユニット (DWU):
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/what-is-a-data-warehouse-unit-dwu-cdwu
• Azure Synapse Analytics (旧称 SQL DW) の容量制限:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-service-capacity-limits
• ワークロード管理とは:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-workload-management
• ワークロードグループの同時実行の最大値:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/memory-concurrency-limits#concurrency-
maximums-for-workload-groups
• Azure Synapse Analytics データウェアハウスでコンピューティングを管理する:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-manage-compute-overview
• クイックスタート:Azure portal を使用して Synapse SQL プールのコンピューティングを一時停止、再開する
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/pause-and-resume-compute-portal
• クォータ要求の種類:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-get-started-create-support-
ticket#quota-request-types
• Apache Spark の自動スケール動作:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/spark/apache-spark-autoscale
• Azure Synapse Analytics で Apache Spark ジョブ (プレビュー) を最適化する
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/spark/apache-spark-performance
• 統合ランタイム:
https://docs.microsoft.com/ja-jp/azure/data-factory/concepts-integration-runtime
• Power BI Premium の大規模なモデル (プレビュー):
https://docs.microsoft.com/ja-jp/power-bi/admin/service-premium-large-models#checking-dataset-size
参考：スケーラビリティ

90
セキュリティアプローチの変化
• 企業NW内中心のアプローチ
• 企業NW内のデバイスは信頼されている
→NWエンドポイントが侵害されると侵入拡大が容易とな
る
→モバイルデバイスや、クラウド利用により、すべてのアプリ
ケーション、データが完全に組織の管理下にある状況ではな
くなっている
従来のNW境界型モデル
• すべてのアクセス要求は要求時点では安全ではない前提
で対処をするアプローチ
• 「どこから、ではなく、誰が」
企業NW内であってもデバイスは信頼されない。（オフィス
から出てきただけでは社員かどうかは確定できない）
• セキュリティを複数の層で構成する（多層防御）
• MicrosoftではIDベースでの多層防御アプローチを推進
ゼロトラストを前提とした多層防御アプローチ
https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/security-principles

91
多層防御とPaaSセキュリティ設定例
# 観点例
1 物理的なセキュリティ
• Azure データセンターの生体認証アクセス制御
jp/azure/security/fundamentals/physical-security
2 IDとアクセス
• Azure Active Directory ユーザー認証
• RBAC
3 境界
• DDoS保護
• Advanced Threat Protection （脅威検出機能）
4 ネットワーク
• ネットワークセキュリティ規則
• ファイアウォール、IPフィルタ
5 コンピューティング
• OS および階層型ソフトウェアパッチを定期的に適用
（PaaSではベンダーの責任範囲となる）
6 アプリケーション • セッションの暗号化
7 データ • Azure Blob Storage に保存中のデータの暗号化
https://docs.microsoft.com/ja-jp/learn/modules/design-for-security-in-azure/2-defense-in-depth

92
（補足）クラウドにおける共同責任
https://docs.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility

分析の民主化とID、アクセス
• 限定的
• システムアカウントの運用
カルチャー
• アクセスユーザ≒全社員
レガシーデータ分析の民主化

データ分析の民主化のためのID管理
• 普段のIDとDBアクセス用のIDを個別運用している
と、分析者が広がるにつれて管理コストが激増(＝
データ漏洩リスク増)
• システムごとに認証IDを設定
• 認証を認証サービスに委任し、データストアは認可
制御のみ行う
• 認証サービスで統合的に認証要件を設定。(e.g.,多
要素認証)
レガシーな分析システム民主化されたデータ分析システム
データ分析の民主化のためには、認証サービス基盤(= ID as a Service ）を有効に利用することが重要。
→認証（だれが）、認可（何にアクセスしてよい）を適切に管理
……
認証
アクセス制御
DB User
AD User
…
認証
アクセス制御
AD User社内資産など社内資産など
認証

セキュリティの観点①
の対応
説明備考
物理的なセキュ
リティ
データセンタの保護に関する記載
〇 Azure データセンターの生体認証
アクセス制御など
クラウドベンダでは物理的セキュリ
ティの対応は一般的
IDとアクセス
ユーザID管理・認証機能がどのように実
装されるか
◎ DB User以外にAADを利用して多
要素認証が可能。
ID管理サービスとしてADの歴史が⾧く、
他社であってもAD連携の優先度は高い
テーブルor行or列単位の認可が可能か
◎ 認可Viewを利用せずにテーブルオ
ブジェクトへの設定が可能
テーブル制御は一般的だが、
行・列レベルの認可は認可Viewを作成
する必要がある製品が多い
他サービスとの連携時の認証がどのよう
に実装されるか
◎ AADの管理する、Managed IDが利
用可能。（Synapseリソースに対
してIAMロールを割り当てなど）
クラウド外との連携はサービスプ
リンシパル(無人ユーザ)を構成す
る
各社によりさまざまだが、サービスID
をAD管理下における点でAzureは優位
境界
監査ログを設定可能か
〇 DB監査ログをストレージに⾧期保
存可能
一般的
不正検出機能が実装可能か
◎ Advanced Threat Protectionおよ
び、データベース監査、脆弱性評
価が利用可能
Synapseに固有のセキュリティ技術と
なる
機密データへの検出、ラベルつけは可能
か
◎ データの検出と分類

セキュリティの観点②
の対応
説明備考
ネットワーク
Firewall,IPフィルタが可能か
〇 Synapse end point に対してIPフィルタが実
装可能
DW単独の場合Service Endpoint利用可能
一般的
内部IPでの利用が可能か
〇 Private Linkと専用線の併用により、社内
NWの拡張の対応が可能
一般的
アプリケー
ション
通信の脆弱性への対応
〇 TLSのバージョン下限が指定可能 SSL対応自体は一般的
データ
アプリケーションに影響なく、転
送・保存データの暗号化が可能か
〇
透過的な保存データ暗号化（TDE）機能
Storage機能によるバックアップデータの暗号化
転送・保存データの暗号化は一般的
アプリケーションに影響なく、クラ
イアントに表示するデータの暗号化
が可能か
〇列レベルの暗号化を提供(Preview)
列レベル暗号化が一般的となってき
ている
クエリ実行結果をマスクすることが
可能か
◎
動的データマスキング
マスク設定に関しても認可制御が可能
他製品ではマスキング機能の開発が
必要
データの流出防護 ◎
承認されていないストレージへの出力をブロック
可能
AzureのNW設計から落ちている機能
と考えられる

• Azure Synapse でデータベースをセキュリティで保護する
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-overview-manage-security
• Azure Synapse Analytics に対する認証
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-authentication?view=sql-server-ver15
• ログインとユーザーアカウントを使用した、認証されたユーザーに対する SQL Database および Azure Synapse Analytics へのデータベースアクセスの承認:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-manage-logins?toc=%2Fazure%2Fsynapse-analytics%2Fsql-data-
warehouse%2Ftoc.json&bc=%2Fazure%2Fsynapse-analytics%2Fsql-data-warehouse%2Fbreadcrumb%2Ftoc.json&view=sql-server-ver15
• Azure リソースのマネージド ID とは:
https://docs.microsoft.com/ja-jp/azure/active-directory/managed-identities-azure-resources/overview
• 行レベルのセキュリティ:
https://docs.microsoft.com/ja-jp/sql/relational-databases/security/row-level-security?toc=%2Fazure%2Fsynapse-analytics%2Fsql-data-
• 列レベルのセキュリティ:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/column-level-security?view=sql-server-ver15
• Azure SQL 監査:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-auditing?toc=/azure/synapse-analytics/sql-data-
warehouse/toc.json&bc=/azure/synapse-analytics/sql-data-warehouse/breadcrumb/toc.json
• Azure SQL Database 向け Advanced Data Security:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-advanced-data-security?toc=/azure/synapse-analytics/sql-data-
warehouse/toc.json&bc=/azure/synapse-analytics/sql-data-warehouse/breadcrumb/toc.json
• Azure SQL Database の Advanced Threat Protection:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-threat-detection-overview?toc=/azure/synapse-
analytics/toc.json&bc=/azure/synapse-analytics/breadcrumb/toc.json
• SQL 脆弱性評価は、データベースの脆弱性を特定するのに役立ちます:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-vulnerability-assessment?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-
analytics/breadcrumb/toc.json
参考①

• Azure SQL Database と Azure Synapse Analytics の IP ファイアウォール規則:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-firewall-configure?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-analytics/sql-data-
warehouse/breadcrumb/toc.json
• Azure SQL Database と Azure Synapse Analytics に対するプライベートリンク
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-private-endpoint-overview?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-
analytics/sql-data-warehouse/breadcrumb/toc.json
• データベースサーバー用の仮想ネットワークサービスエンドポイントおよび規則を使用する
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-vnet-service-endpoint-rule-overview?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-
• Synapse マネージドプライベートエンドポイント (プレビュー):
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/security/synapse-workspace-managed-private-endpoints
• Azure Active Directory 認証を使用して Synapse SQL での認証を行う:
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql/active-directory-authentication
• Azure SQL Database と Azure Synapse Analytics に対する動的データマスキング:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-dynamic-data-masking-get-started?toc=%2Fazure%2Fsynapse-analytics%2Fsql-data-
• SQL Database および Azure Synapse の透過的なデータ暗号化:
https://docs.microsoft.com/ja-jp/azure/sql-database/transparent-data-encryption-azure-sql?toc=%2Fazure%2Fsynapse-analytics%2Fsql-data-
warehouse%2Ftoc.json&bc=%2Fazure%2Fsynapse-analytics%2Fsql-data-warehouse%2Fbreadcrumb%2Ftoc.json&view=sql-server-ver15&tabs=azure-portal
• カスタマーマネージドキーを使用した Azure SQL Transparent Data Encryption:
https://docs.microsoft.com/ja-jp/azure/sql-database/transparent-data-encryption-byok-azure-sql?toc=/azure/synapse-analytics/sql-data-warehouse/toc.json&bc=/azure/synapse-
• Always Encrypted:
https://docs.microsoft.com/ja-jp/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver15
• データの列の暗号化:
https://docs.microsoft.com/ja-jp/sql/relational-databases/security/encryption/encrypt-a-column-of-data?view=sql-server-ver15
• Azure SQL Database と Azure Synapse Analytics のデータの検出と分類:
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-data-discovery-and-classification?toc=/azure/synapse-analytics/toc.json&bc=/azure/synapse-
analytics/breadcrumb/toc.json
• Azure Synapse Analytics ワークスペースでのデータ流出の防止 - Azure Synapse Analytics | Microsoft Docs
• プライベートリンクを使用して Synapse Studio に接続する - Azure Synapse Analytics | Microsoft Docs
参考②

• Azure の境界セキュリティに関するベストプラクティス
• Azure のデータベースセキュリティに関するベストプラクティス
• Azure のデータセキュリティと暗号化のベストプラクティス
• Azure の ID 管理とアクセス制御セキュリティのベストプラクティス
• Azure のネットワークセキュリティに関するベストプラクティス
• Azure で運用可能なセキュリティに関するベストプラクティス
• Azure PaaS のベストプラクティス
• Azure Service Fabric のセキュリティに関するベストプラクティス
• Azure VM のセキュリティに関するベストプラクティス
• Azure における安全なハイブリッドネットワークアーキテクチャの実装
• モノのインターネットのセキュリティのベストプラクティス
• Azure で Paas データベースをセキュリティ保護する
• Azure App Service を使用して PaaS の Web アプリケーションとモバイルアプリケーションをセキュリティ保護する
• Azure Storage を使用して PaaS の Web アプリケーションとモバイルアプリケーションをセキュリティで保護する
• Azure における IaaS ワークロードのセキュリティに関するベストプラクティス
• https://docs.microsoft.com/ja-jp/azure/security/fundamentals/physical-security
• データの列の暗号化
参考：セキュリティ関連記事

クラウドDWHにおける観点とAzure Synapse Analyticsの対応

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to クラウドDWHにおける観点とAzure Synapse Analyticsの対応

Similar to クラウドDWHにおける観点とAzure Synapse Analyticsの対応 (20)

More from Ryoma Nagata

More from Ryoma Nagata (8)

クラウドDWHにおける観点とAzure Synapse Analyticsの対応