Download as PDF, PPTX
More Related Content
Similar to クラウドDWHにおける観点とAzure Synapse Analyticsの対応
クラウドDWHにおける観点とAzure Synapse Analyticsの対応
- 1.
- 2. • 各社クラウドベンダーでは大規模データ分析向けのDWHサービスを提供しています。 本書ではDWHに必要とされる主要な観点をベースに、Azure SynapseAnalyticsをサン プルとして解説し、製品評価のための理解を促進することを目指します。 本資料の位置づけ クラウドで提供されるDWHサービス Azure Synapse Analyticsの実情は？ 様々な売り文句 無限のスケール? 簡単で強力な分析? クラウドネイティブ、管理不要? 費用対効果の高いDWH?
- 3. アジェンダ 1. [概略]現代のDWHアーキテクチャ 2. BigData基盤上での立ち位置 3. 検討ポイントとAzure の対応 1. 機能 2. 非機能
- 4.
- 5. STEP1 STEP2 STEP1 STEP2 ディスクから データを読み込み 中間処理はキャッ シュを利用 Cache Driver Cache Task Cache TaskTask •データ量の増大 • 非構造データ対応 • 求められる処理能力 • クラスタ管理の煩雑さ • 繰り返し処理時の非効率性 • 高速インタラクティブ処理 への要望（機械学習） • インメモリ高速分散処理基盤 • Hadoopの不得意な部分に改善を加 え、ビッグデータに対するバッチ処 理/リアルタイム処理/インタラク ティブ分析（繰り返し処理）を高速 実現 ビッグデータ処理技術のトレンド変遷 HadoopとSpark
- 6. 現代の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型の構造 ビッグデータへの対応
- 7. 列指向ストレージ • OLTPシステム向けの従来のストレージシステム • データ（ブロック）は1レコードを構成する複数列 が格納される •集計クエリでは特定のカラム集計値もすべてのカラ ムをリードする必要がある • DWHなど分析システム向けのストレージシステム • データ（ブロック）は複数行にまたがって一つの列 が格納される • 分析クエリでは通常少数の列しか利用しないため、 必要なスキャンのみを実施可能 行指向ストレージ 列指向ストレージ 参考：https://www.slideshare.net/nttdata-tech/bigdata-storage-layer-software-nttdata 対象列 対象列対象列 対象列
- 8. • 一般に圧縮効率はユニークなデータが少ないほど高効率となる • 列指向ストレージでは列ごとのデータ形式となるため、同じ値 が頻出することが多く（カーディナリティが低い）、データ圧 縮の効果が高い 列指向ストレージによる圧縮の効率化 IDユーザ名 都市 性別 1 AAA Tokyo 男 2 BBB Osaka 女 3 CCC Nagoya 男 同一のデータが頻出 列のデータ型毎に最適な圧縮技法を利用可能
- 9. • データ指向アプリケーションデザイン ―信頼性、拡張性、保守 性の高い分散システム設計の原理Martin Kleppmann https://www.amazon.co.jp/dp/4873118700/ref=cm_sw_r_tw_dp_U_x _q2MWEbDRE3905 参考文献 9
- 10.
- 11. 従来の分析基盤 ETL Tool エンタープライズDWH Extract 生データ Load 加工済み データ Transform BI Tools DataMarts Data Lake(s) Dashboards Apps
- 12. データレイクの導入 ETL Tool BI Tools 生データ スケーラブル ストレージ& コンピュート (HDFSなど) Transform& Load Data Marts Data Lake(s) Dashboards Apps ストリームデータ エンタープライズDWH Ingest (EL) Operational DWHなど
- 13. データレイクの導入 ETL Tool BI Tools 生データ スケーラブル ストレージ& コンピュート (HDFSなど) Transform& Load Data Marts Data Lake(s) Dashboards Apps ストリームデータ エンタープライズDWH Ingest (EL) Operational DWHなど
- 14. DatalakeとDWHの利点と課題 Datalake • 柔軟に大容量データを格納可能 だが • メタデータ管理の難しさ（データ沼） •データレイク内のデータ更新は不可能 • データレイクへのクエリ速度は低い DWH • 豊富なRDBMS機能と高速クエリ だが • アクセスがSQLに限定 • 構造化データのみの蓄積 • スケーリングの難しさ
- 15. レイクハウス型アーキテクチャ • どちらか、ではなくいいとこどりを目指すのが主流 Datalake ×DWH Datalakeとしての層＋DWHとしての層 ニーズ あらゆるデータサイロの解消 エンタープライズレベルの データ分析 ワークロード データ探索、機械学習、ストリーミング分析 BI,ダッシュボード、OLAP分析 メリット クラウドストレージに代表されるスケーラビ リティとコスト効率 あらゆるデータ形式への柔軟な対応 ACIDトランザクション 高速クエリ データモデル一貫性 RDBMSで成熟した開発管理タ スクやセキュリティ対応
- 16. • 機能 • データレイクと統合された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. 17 PlatformPlatform 評価の前提 SQL DWはAnalytics用途のPaaSを包括した総合的なサービスとして、Azure SynapseAnalyticsという名称にリブランディングさ れ、DWH機能として統合されました。 本資料では、基本的に「 Dedicated SQL Pool 」を軸に評価し、「Serverless SQL Pool」、「Spark Pool」を周辺機能として位 置づけます。 SQL Data Warehouse SQL Pool(On-Demand) [Preview機能] サーバレスなSQL クエリエンジン [一般提供済] 永続化されたエンタープライズ向け MPP型DWH Spark Pools Analytics Runtimes 一機能として統合
- 18. • 一部のクラウドでは分析アーキテクチャを統合し、複雑さを排除する方向に拡張。 • SynapseAnalyticsでもデータプラットフォームに必要な収集・加工・提供などの機能を集約し、 従来のDWHは分析ワークスペースの中の１機能へ。 補足：Azure Synapse Analyticsによる 周辺機能の統合
- 19.
- 20. 比較ポイントの一覧 # 分類 比較ポイント 1機能 データレイクと統合されたDWH 2 機能 データの保持形式や読み取り最適化 3 機能 機械学習・ニアリアルタイム分析 4 機能 その他のDB機能 5 非機能 コスト 6 非機能 開発・運用保守性 7 非機能 回復性・可用性 8 非機能 スケーラビリティ 9 非機能 セキュリティ
- 21.
- 22. • AzureではAzure DataLake 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
- 24.
- 25.
- 26.
- 27. 補足：ストレージ層での先端技術 Delta Lake •Databricksの機能であったDelta をOSS化（昨年のSpark + AI Summit 2019 Keynoteで発表） • ファイルシステム上で動作し UpdateなどのDML実行が可能 • 実態はparquetファイルのため高 圧縮率 • 現在version 0.7.0 • Synapse Sparkでも利用可能 • https://delta.io/
- 28. 補足：Delta Lake主要機能 • DeltaLake Summary Bigdataシステムで肥大した大規模なメタデータを分散処理可能 バッチデータ、ストリーミングを容易に統合 挿入データのスキーマ不正を自動検証 マージ、更新、および削除操作（DML）をサポートして複雑なユースケースを実現 データのバージョン管理により、ロールバック、完全な履歴監査証跡、機械学習の再現が可能 読み取り結果の不整合を防止
- 29. Delta Lake 活用シーン① -安全なデータの追加 •追加（append）、 上書き（overwrite）操作をアト ミックに実行 • テーブル挿入時には自動でス キーマ検証を行い、不正データ を例外処理することでデータを 保護 df.write .format("delta") .mode("append") .save("/mnt/delta/events") 連携データ 生データ保管 バッチデータ 保管テーブル追加 or 上書き （ACID） 不正列データ 生データ保管 バッチデータ 保管テーブルスキーマチェック
- 30. 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
- 31. 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") ストリーム データ ストリーム データ バッチデータ ストリームデータ 保管テーブル ストリームデータ 保管テーブル バッチデータ 保管テーブル 集計速報テーブル ストリームデータ 統合テーブル ストリーム ＆バッチデータ統 合テーブル
- 32. データレイクと統合された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によるオフロード を実行可能（上書き可能） ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 33. データレイクと統合されたDWHの観点 観点 内容 Synapse の対応 説明比較総評 データ処理 外部/永続テーブルに対す る処理 〇 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社はクラスタを常に経由するので方 針は異なるが、同様のことが可能 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 34. • Azure SynapseAnalytics (ワークスペース プレビュー) とは: 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.
- 36. データ保持形式や読み取り最適化方式 • シェアードナッシング型のアーキテクチャではコンピュートとスト レージが結合され、Nodeの追加に時間がかかる（リバランス処理） • AzureSynapse 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 に準拠した機能をベースに提供している
- 37. • SQL Serverでは、プライマリインデックス（テーブルの実体 と一体化したインデックス）にクラスター化とつける • クラスター→簡単に言うと行、もしくは列のデータの塊 • 列指向の保持形式をクラスター化列ストアインデックスという 補足：クラスター化列ストアインデックス
- 38. 補足：データパーティショニング戦略 • 論理パーティションのほかに、DWH製品では分散といわれ ることが多い。 • MPPのアーキテクチャでは各パーティションのデータを Computeノードが並列で処理することで、大量データの処 理を行う •分散では各パーティション間のデータ移動を少なくする設 計が必要 • deleteよりもパーティション削除のほうが早い場合が多く、 ETL時のパフォーマンス向上にも有効 • 列毎にデータを保持することで必要なデータアクセ ス量を削減する 水平パーティショニング（シャーディング） 垂直パーティショニング データのパーティション分割のガイダンス - Best practices for cloud applications | Microsoft Docs
- 39. 補足：パーティションプルーニング Sql server パーティション概要 (slideshare.net) • 一般に時系列で分割されたテーブルに対して、フルスキャンを 回避してアクセス量を削減する機能 • SQL Serverでは必要なファイルグループにのみアクセス テーブルのパーティション分割 - Azure Synapse Analytics | Microsoft Docs
- 40. データ保持構造と最適化の観点 観点 内容 Synapse の対応 説明備考 ストレージ 列指向ストレージであ るか 〇 クラスター化インデックスとして列ストアを選択する(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社はクラスタリングのキーを指定することで 実現 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 41. データ保持構造と最適化の観点 観点 内容 Synapse の対応 説明備考 インデックス データの並び替え方法 とセカンダリインデッ クスの利用可否 〇 • プライマリインデックス（クラスター化） • 順序指定なしor 順序指定あり • セカンダリインデックス（非クラスター化インデックス） 順序指定ありクラスター化列ストアが最もクエリ高速化の ためのオプション。ただし、書き込み時のインデックス作 成時間とトレードオフとなる インデックス機能は一般的だが、非クラスター 化インデックスはS社,Synapse固有 Materialized View 集計済みの実体をもつ Viewをどのように実装 するか 〇 分散が可能 またオプティマイザにより、ベーステーブルへの参照時に Viewテーブルへの参照に自動切換えされる（透過的な利用） Power BI 統合による自動作成の評価次第で優位性が発揮され る可能性あり SynapseとG社、S社がオプティマイザによる 自動書き換えが可能 BIツールによる自動作 成 ◎ Power BIでクエリされたデータを認識して、自動でViewを作 成する（Private Preview） BIツールを同社で提供していることから生まれ る独自の強み 結果セット キャッシュ クエリ結果をキャッ シュし、迅速に再利用 可能か 〇 同時実行数を消費せずに利用可能 上限1TB 48時間利用なしで削除 一般的な機能 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 42. • Azure SynapseAnalytics (旧称 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.
- 44. 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)
- 45. Azure CosmosDB は、 10 ミリ秒未満の読み取り/書き込み レイテンシを提供し、オペレーショナル ワークロードに最適化 99.999% の高可用性、スループット、 整合性の保証 Azure の全リージョンにわたる、 ターンキーのグローバル データ レプリケーション Azure Cosmos DB リアルタイム アプリ/サービス Azure Cosmos DB
- 46.
- 47. 大量のデータがある場合、 分析クエリの実行には時間が かかり、リソース集中型になる OLTPワークロードの パフォーマンスへの大きな影響 同一データベース上で OLTP/OLAP ワークロードを実行 リアルタイム アプリ/サービス Azure Cosmos DB レポート / ダッシュボード
- 48. ユーザー アプリ Azure Cosmos DB Azure DataLake Storage 抽出 (パイプライン) 変換 / 強化 オーケストレーション Power BI 提供 Azure Cosmos DB から Azure Data Lake Storage に定期的にデータをインジェスト 分析に最適化するために、データ形式とストレージ レイヤーを管理 Apache Spark for Synapse Synapse SQL OLTP と OLAP を分離
- 49. 準リアルタイムのデータ分析 トランザクションワークロード へのパフォーマンスの影響なし ETL が不要 Azure Synapse Link for Azure Cosmos DB
- 50. 分析ストア 分析クエリに最適化された「列ストア」 トランザクション ストア トランザクション操作に最適化された「行ストア」 Azure CosmosDB Azure Synapse Analytics コンテナー クラウド ネイティブ HTAP Azure Synapse Link SQL 自動同期 機械学習 ビッグ データ分析 BI ダッシュボード オペレー ショナル データ オペレーショナル データに対する準リアルタイムの洞察を生成 Azure Synapse Link for Azure Cosmos DBの動作
- 52. ニア リアルタイム分析のユース ケース例 サプライチェーンの分析、予測、およびレポート作成 出典：Azure Synapse Link for Azure Cosmos DB を使用したリアルタイム分析のユース ケース | Microsoft Docs
- 53. ニア リアルタイム分析のユース ケース例 IoT予測メンテナンス 出典：AzureSynapse Link for Azure Cosmos DB を使用したリアルタイム分析のユース ケース | Microsoft Docs
- 54. • Common DataModel 1.0フォーマットでAzure Data Lake Storage Gen2内に書き込み/読み取りを実行可能 • Dynamics 365 やPower BI DataflowなどのCDM形式に対応したサービスとのデータおよびスキーマ情報の連携が容易になる ※Power BI Dataflowでは旧形式の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
- 55. • Azure MachineLearning に登録された ONNX 形式のML モデルを Synapse Studio で数クリックで利用可能 • 専用 SQL プールで T-SQL PREDICT 関数をラップしたストアド プロシージャを使用してスコア付け • チュートリアル:専用 SQL プール向けの機械学習モデル スコアリング ウィザード - Azure Synapse Analytics Ignite 2020 Update Azure Synapse Analytics - Speaker Deck
- 56. IoTデバイス IoT hubStream Analytics リアルタイムダッシュボードCosmos DB Machine Learning サーバレス SQL プール 専用 SQL プール サーバレス Spark プール ホットパス コールドパス
- 57. 機械学習・ニアリアルタイム分析の観点 観点 内容 Synapse の対応 説明比較総評 ニアリアル タイム分析 ストリーミングデータの取 り扱いが可能か ◎ 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連携が登場 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 58. • Building real-timeenterprise 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 参考:機械学習・ニアリアルタイム分析
- 59.
- 60. その他のDBMS機能の観点 観点 内容 Azure Synapse 説明備考 RDBMS機能 ACIDトランザクショ ンが実行可能か 〇 SQL Serverベースのサービスであるため、標準で搭載 Delta Lakeではストレージレイヤで 実行可能 タイムトラベ ル 指定した過去時点の データにアクセス可 能か × Synapse では利用不可 S社やDelta Lakeでは実行可能（期 間の制限あり） ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 61. • Read olderversions of data using time travel: https://docs.delta.io/latest/quick-start.html#-read-older- versions-of-data-using-time-travel • 参考:その他のDB機能の観点
- 62.
- 63. ソフトウェア品質の重要な5大要素 前提：クラウドアプリケーションの評価軸 # Azureにおける品質特性 説明 1コスト最適化 もたらされる価値を最大化するためのコスト最適化プロセスです。 2 オペレーショナル エクセレンス 運用環境でシステムを継続的に動作させる運用プロセスです。 3 信頼性 障害から回復して動作を続行するシステムの能力です。 4 パフォーマンス効率 負荷の変化に対応するためのシステムの能力。 5 セキュリティ 脅威からアプリケーションとデータを保護することです。 https://docs.microsoft.com/ja-jp/azure/architecture/framework/
- 64.
- 65. • Azure SynapseAnalyticsでは大きく三種の機能に課金モデルがある（データレイクの課金は記載外） • 時間単位の切り上げ方法など細かな違いはあれど他社のDWHも以下のどれかの考え方が適用可能（複数クラ スターの場合がある） ジョブコスト＝実行時間(m) 処理コスト＝性能×実行時間(m) SQL Pool (DWHクラスター) • いわゆるクラスターに対する課金 • 性能部分は停止が可能 • 性能は事前に設定 Azure Synapse Analytics 課金モデル概要 SQL On-demand (サーバーレスクエリ) • サーバレスのため、処理性能の課金はない • コスト制限が可能 Spark for Synapse , Synapse Pipeline (ETL機能) • 処理、ジョブ機能（オーケストレーショ ン）に対する課金 • 処理性能はオートスケール 構成済みDWH (クラスター) コスト＝保存量＋性能×起動時間(h) ＋ コスト＝クエリデータ量
- 66. コスト最適化の観点 観点 内容 対象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 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 67. • コスト最適化の原則: https://docs.microsoft.com/ja- jp/azure/architecture/framework/cost/overview • AzureCost Management および Billing のドキュメント: https://docs.microsoft.com/ja-jp/azure/cost-management-billing/ • コスト最適化チェックリスト: https://docs.microsoft.com/ja- 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.
- 69. 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
- 70. オペレーショナル エクセレンスの観点 観点 内容Synapse の対応 説明 備考 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 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 71. オペレーショナル エクセレンスの観点 観点 内容Synapse の対応 説明 備考 自動化 管理タスクは簡略化さ れているか △ 自動バックアップなどが既定で準備 管理タスクはGUIで実行可能 性能変更の自動化は基本的にFunctionなどで実装 （テンプレートが提供） インフラ管理不要は一般的 管理タスクは各製品で知識が必要 S社で管理タスクを低減し、ニアゼロマネジ メントとしている チューニングは簡略化 されているか × 複雑であるが、細かな設定が可能との裏返しともな る。また、アドバイザ機能は優秀 いずれの製品も最適化のためのパラメータ は多い。 S社は管理タスク同様、自動化傾向が強い ベンダーロッ クイン 提供プラットフォーム は固有ではないか × プラットフォームとしてもAzure外でのSynapseの提 供はない Synapseではないが、Azure Arcが方向性となってい る 唯一S社はマルチプラットフォーム対応 スキルが再利用可能か 〇 SQL Serverベースの知識が必要だが、 基盤全体ではPyhon,Spark,parquet,DeltaLakeなど オープンな技術利用が可能。 A社であれば PostgreSQLベース S社ではSQL:1999ベース だが、固有の機能呼び出しに各社固有の知 識が必要となる。Python , Sparkは一般的に も対応の方向 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 72. • 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 開発・運用保守性の観点
- 73.
- 74. 信頼性の観点 観点 内容 Synapse の対応 説明備考 可用性 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日間の復元期間が明記 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 75. • 自動復元ポイント: https://docs.microsoft.com/ja-jp/azure/synapse- analytics/sql-data-warehouse/backup-and- restore#automatic-restore-points • SQLプールの geo リストア: https://docs.microsoft.com/ja-jp/azure/synapse- analytics/sql-data-warehouse/sql-data-warehouse-restore- from-geo-backup • 復元ポイントからの復元: https://docs.microsoft.com/ja-jp/azure/synapse- analytics/sql-data-warehouse/backup-and- restore#restoring-from-restore-points 参考：回復性・可用性の観点
- 76.
- 77. • スケーリング • アクセス負荷分散＝スケールアウト •処理性能向上＝スケールアップ • 分散処理のアーキテクチャではノード数を増やすことで処理負荷を分散 • マイクロサービスの思想 • パフォーマンス（ワークロード）を分離する • 適材適所のデータストア選択 • SQLクエリ→DWH • SQLクエリを発行する人＝限定的に準備されたDWH • BI→BIサーバ • 事前にインメモリDBにキャッシュすることによるレスポンス確保 • 地理的にユーザに近い場所へのコンテンツの配置（CDN的発想） • 異なる利用であれば異なるリソースで • 同じリソースで様々なことしない • 利用シーンごとに物理的に分離されているほうが適切な性能確保がしやすい • →配置が簡単なクラウドのメリットの教授 一般的なパフォーマンス確保の原則
- 78. • DWHのスケーラビリティは基本的に以下の3点についての対応が必要 • 集計規模の増大への対応 •同時実行クエリ数の増大への対応 • 容量増大への対応 • Azure Synapse Analyticsでは以下のような特徴で最大のコストパフォーマンス がベンチマークとして記録されている • コンピュートとストレージの分離 • シングルクラスター • 無制限のストレージ Azure Synapse Analytics スケーラビリティ
- 79. • コンピュートとストレージが分離しており、個別の拡張が可能 • 容量のみ増大(1TB～∞） •性能のみ増大（0.25～60ノード） 集計規模増、ストレージ容量増への対応
- 80. 同時実行数増への対応 • 同時実行数は単一クラスター性能の上限で頭打ち •クラスター数を増大することで同時実行数を増大 ※性能に余剰があってもクラスター増される 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 レプリカ
- 81. • コストを予測可能にしつつ、性能を無駄なく使うための機能をそろえている。 • 結果セットのキャッシュ…同一のクエリはメモリから応答し、同時実行数を消費しない（100～400msec応答） •ワークロード管理 • ワークロード分離…グループごとに性能上限を設定する。未使用の性能は上限を超えて利用する • ワークロードの重要度…先入先出ではなく重要なグループのクエリは割り込み実行する Azure Synapse Analyticsの同時実行戦略 Workload Isolation ワークロード分離 Marketing 40% 60% Sales 60% 100% Compute 1000c DWU Workload Importance ワークロードの重要度
- 82. 補足：パフォーマンス分離の対応 • 識別子で性能上限を指定する＝配分での対応 •ワークロードの完全な分離 Synapse DW(シングルクラスター) マルチクラスター クエリ用クラスター Primary Cluster１ ETL用クラスター Data Primary Cluster２ • 現状Synapseのワークロード分離は厳密にパフォーマンスの分離ではない • シングルクラスター方式：同一のクラスタ内でユーザやクエリタイプで性能上限を割り当て • マルチクラスター方式：同一データに対してクラスターを複数配置※スケールアウトはそれぞれのクラスタで対応 クエリ 用： 40% Primary Cluster Data ETL用:60%
- 83. 中小規模の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個の一意クエリ/時となる 同時実行に関する計算例
- 84. SQLを書かないユーザへのOLAPデータマートとしてインメモリ分析データベースを構成 戦略２：ポリグロットデータストア Azure Synapse Analytics Reporting DataWarehouse 業務ロジック、計算式 データモデリング 行レベル セキュリティ Azure Analysis Services Or Power BI dataset Visual Studio による コード管理 インメモリ キャッシュ Semantic Layer
- 85. 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分析操作
- 86. パフォーマンス効率の観点 観点 内容 Synapse の対応 説明備考 拡張の対応 クエリ規模増大への対 応が可能か(スケール アップ) 〇 ノード数を増やすことで対応。 Synapseのサイズスぺックは他社と比べて 詳細に変更可能 中断せずに性能変更可 能か × オフライン操作となる S社がオンラインスケーリングに対応 容量増大への対応が可 能か 〇 無制限 一般的 同時実行数増大への対 応が可能か △ 128までとなる。 ワークロード管理機能、Result Set Cacheを利用す ることで回避する。 128まで増大させる場合、スケールアップが伴うた め、同時実行数のみの増大は不可 他社ではクラスタースケールアウト戦略を とっていることが多い AzureではOLAP用データマートを作成する 方針が主流 性能の配分が可能か 〇 ワークロードの分離機能で、ワークロードグループ ごとに性能の配分を指定可能 性能をワークロードグループごとに分離す ることはSynapse固有だが、 S社は同一のデータに対してクラスターを複 数建てることが前提のため、多少余剰が あっても明快 クラスターの分離が可 能か × SQL Poolを複数利用する場合はデータ共有をするた めにParquet共有などを利用する。最適化には専用 ストレージに個別でロードが必要 S社のマルチクラスタ（ストレージ、コン ピュートの分離）戦略の強み。手軽だがコ ストに注意が必要 クエリの割り込みが可 能か ◎ FIFOを基本とするが、ワークロードの重要度設定に より、割り込みが可能 一般的にはFIFOで処理されるため、独自機 能である ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 87. パフォーマンス効率の観点 観点 内容 Synapse の対応 説明備考 拡張の柔軟性 自動拡張が可能か △ 不可。他サービスで機能を開発することとなる サイズ変更が手動であることは一般的 他社では同時実行数拡張が自動化が強調さ れている。 Synapseはワークロードごとに性能を割り 当てる独自の戦略 拡張は速やかに完了す るか 〇 ストレージコンピュートが分離されているので数分 で完了 Synapseは高速な部類だったが、一般的と なっている クラスターの構成が速 やかに完了するか △ S社のクラスタ構成速度は秒単位 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 88. • 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 参考：スケーラビリティ
- 89.
- 90. 90 セキュリティアプローチの変化 • 企業NW内中心のアプローチ • 企業NW内のデバイスは信頼されている →NWエンドポイントが侵害されると侵入拡大が容易とな る →モバイルデバイスや、クラウド利用により、すべてのアプリ ケーション、データが完全に組織の管理下にある状況ではな くなっている 従来のNW境界型モデル •すべてのアクセス要求は要求時点では安全ではない前提 で対処をするアプローチ • 「どこから、ではなく、誰が」 企業NW内であってもデバイスは信頼されない。（オフィス から出てきただけでは社員かどうかは確定できない） • セキュリティを複数の層で構成する（多層防御） • MicrosoftではIDベースでの多層防御アプローチを推進 ゼロトラストを前提とした多層防御アプローチ https://docs.microsoft.com/ja-jp/azure/architecture/framework/security/security-principles
- 91. 91 多層防御とPaaSセキュリティ設定例 # 観点 例 1物理的なセキュリティ • Azure データ センターの生体認証アクセス制御 https://docs.microsoft.com/ja- 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.
- 93. 分析の民主化とID、アクセス • 限定的 • システムアカウントの運用 カルチャー •アクセスユーザ≒全社員 レガシー データ分析の民主化
- 94. データ分析の民主化のためのID管理 • 普段のIDとDBアクセス用のIDを個別運用している と、分析者が広がるにつれて管理コストが激増(＝ データ漏洩リスク増) • システムごとに認証IDを設定 •認証を認証サービスに委任し、データストアは認可 制御のみ行う • 認証サービスで統合的に認証要件を設定。(e.g.,多 要素認証) レガシーな分析システム 民主化されたデータ分析システム データ分析の民主化のためには、認証サービス基盤(= ID as a Service ）を有効に利用することが重要。 →認証（だれが）、認可（何にアクセスしてよい）を適切に管理 …… 認証 アクセス制御 DB User AD User … 認証 アクセス制御 AD User社内資産など 社内資産など 認証
- 95. セキュリティの観点① 観点 内容 Synapse の対応 説明備考 物理的なセキュ リティ データセンタの保護に関する記載 〇 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に固有のセキュリティ技術と なる 機密データへの検出、ラベルつけは可能 か ◎ データの検出と分類 ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 96. セキュリティの観点② 観点 内容 Synapse の対応 説明備考 ネットワーク Firewall,IPフィルタが可能か 〇 Synapse end point に対してIPフィルタが実 装可能 DW単独の場合Service Endpoint利用可能 一般的 内部IPでの利用が可能か 〇 Private Linkと専用線の併用により、社内 NWの拡張の対応が可能 一般的 アプリケー ション 通信の脆弱性への対応 〇 TLSのバージョン下限が指定可能 SSL対応自体は一般的 データ アプリケーションに影響なく、転 送・保存データの暗号化が可能か 〇 透過的な保存データ暗号化（TDE）機能 Storage機能によるバックアップデータの暗号化 転送・保存データの暗号化は一般的 アプリケーションに影響なく、クラ イアントに表示するデータの暗号化 が可能か 〇 列レベルの暗号化を提供(Preview) 列レベル暗号化が一般的となってき ている クエリ実行結果をマスクすることが 可能か ◎ 動的データマスキング マスク設定に関しても認可制御が可能 他製品ではマスキング機能の開発が 必要 データの流出防護 ◎ 承認されていないストレージへの出力をブロック 可能 AzureのNW設計から落ちている機能 と考えられる ◎：優位性あり 〇：優位性は特にないが対応可能 △：対応できるが、劣勢 ×：対応できない
- 97. • 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- warehouse%2Ftoc.json&bc=%2Fazure%2Fsynapse-analytics%2Fsql-data-warehouse%2Fbreadcrumb%2Ftoc.json&view=sql-server-ver15 • 列レベルのセキュリティ: 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 参考①
- 98. • Azure SQLDatabase と 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- analytics/sql-data-warehouse/breadcrumb/toc.json • 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- warehouse%2Ftoc.json&bc=%2Fazure%2Fsynapse-analytics%2Fsql-data-warehouse%2Fbreadcrumb%2Ftoc.json&view=sql-server-ver15 • 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- analytics/sql-data-warehouse/breadcrumb/toc.json • 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 参考②
- 99. • 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 • データの列の暗号化 参考：セキュリティ関連記事