プレイブック

データが、製品カタログや財務記録のように、事前定義されたスキーマ（行と列）を持つ固定の表形式レイアウトで整理されている場合。

→構造化データとして表現します。

理由: 構造化データは厳格なスキーマに準拠しており、リレーショナルデータベース（OLTP）に最適です。半構造化データ（JSON/XML）や非構造化データ（画像/音声）とは対照的です。

データには何らかの組織構造（タグ、キー）があるものの、厳格なスキーマがありません。IoTセンサーのJSONドキュメントのように、各レコードが異なるフィールドを持つ場合があります。

→半構造化データ（例：JSON、XML）として表現します。

理由: JSONとXMLは自己記述型であり、構造化データの固定スキーマよりも柔軟性を提供します。NoSQLデータベースやデータレイクに最適です。

MRIスキャン、ビデオ、オーディオ録音などの、事前定義されたスキーマや組織構造を持たない大規模なファイルを保存する場合。

→非構造化データとして表現します。

理由: このデータ型は従来の行/列データベースには保存できません。Azure Blob Storageのようなオブジェクトストレージが必要です。

日常業務のためのワークロードと履歴分析のためのワークロードを区別する場合。

→大量かつ低遅延のトランザクション（例：eコマースの注文）にはOLTP（Online Transaction Processing）を使用します。大規模な履歴データセットに対する複雑なクエリ（例：販売トレンド分析）にはOLAP（Online Analytical Processing）を使用します。

理由: OLTPシステムは正規化されており、高速な書き込みに最適化されています。OLAPシステムは非正規化されており（スター スキーマ）、高速な読み取りと集計に最適化されています。

データウェアハウスのデータ統合パターンを選択する場合。

→変換ロジックが複雑で、ロード前にステージングサーバーで実行される場合はETL（Extract, Transform, Load）を使用します。強力なターゲットシステム（例：Synapse Analytics）に生データをロードし、そのコンピューティングを変換に活用する場合はELT（Extract, Load, Transform）を使用します。

理由: ELTは最新のクラウドパターンであり、ターゲットデータストア（データウェアハウス/レイクハウス）のスケーラブルなコンピューティングを活用し、取り込みを簡素化します。

データプラットフォームタスクの責任を割り当てる場合。

→データエンジニア：ETL/ELTパイプラインを構築および保守します。データベース管理者：データベースのセキュリティ、パフォーマンス、可用性を管理します。データアナリスト：ビジネスインサイトのためのレポートとビジュアライゼーション（例：Power BI）を作成します。

理由: 明確に定義された役割は不可欠です。主な区別は、構築（エンジニア）、管理（DBA）、分析（アナリスト）です。

異なる遅延要件を持つ大量のデータを処理する場合。

→スケジュールされた間隔で処理される静止データ（例：夜間レポート）にはバッチ処理を使用します。到着時に継続的に処理される移動中のデータ（例：リアルタイム詐欺検出）にはストリーム処理を使用します。

理由: 主要なトレードオフは、レイテンシーとコスト/スループットです。ストリーム処理は低レイテンシーを提供しますが、常時稼働のリソースが必要です。バッチ処理は高レイテンシーですが、大量のデータに対してはコスト効率が高いです。

分析クエリをサポートするために、データウェアハウスのスキーマを設計する場合。

→中心となるファクトテーブル（数値メジャーを含む）と、複数のディメンションテーブル（記述属性を含む）が接続されたスター スキーマを使用します。

理由: この非正規化された構造は、分析クエリの結合を最小限に抑え、正規化された（OLTP）スキーマと比較してパフォーマンスを向上させます。スノーフレーク スキーマよりも、ほとんどのBIツールにとってよりシンプルで高速です。

分析用の中央リポジトリを選択する場合。

→生のデータをネイティブ形式で大量に保存する（スキーマオンリード）には、データレイク（例：Azure Data Lake Storage）を使用します。BIおよびレポート用の構造化された処理済みデータを保存する（スキーマオンライト）には、データウェアハウス（例：Synapse Dedicated SQL Pool）を使用します。

理由: データレイクは、データサイエンスや生のデータ探索のための柔軟性を提供します。データウェアハウスは、ビジネスインテリジェンスのための高いパフォーマンスと構造を提供します。

基盤となるインフラストラクチャを管理することなく、新しいクラウドネイティブアプリケーション向けに完全に管理されたリレーショナルデータベースが必要な場合。

→Azure SQL Databaseを使用します。

理由: 自動パッチ適用、バックアップ、高可用性を備えたPaaS製品です。OSレベルのアクセスが不要な標準的なSQLワークロードに最適です。

リファレンス↗

SQL Server Agent、クロスデータベースクエリ、Service Brokerなどのインスタンススコープの機能を使用するオンプレミスのSQL Serverワークロードをリフト＆シフトで移行する場合。

→Azure SQL Managed Instanceを使用します。

理由: SQL MIはオンプレミスのSQL Serverエンジンとほぼ100%互換性があり、移行時の変更を最小限に抑えます。Azure SQL Databaseはこれらのインスタンスレベルの機能をサポートしていません。

リファレンス↗

OS、特定のSQL Serverバージョン、またはPaaSサポートが限定されている機能（特定のCLRアセンブリなど）を完全に制御する必要があるSQL ServerデータベースをAzureに移行する場合。

→Azure Virtual Machines上のSQL Serverを使用します。

理由: このIaaSオプションは最高の互換性と制御を提供しますが、PaaSとは異なり、OS、パッチ適用、バックアップの管理はユーザーが行う必要があります。

アプリケーションが断続的で予測不可能な使用パターンを持ち、長いアイドル期間がある場合。非アクティブ時のコストを最小限に抑える必要がある場合。

→Azure SQL Databaseのサーバーレスコンピューティング層を使用します。

理由: サーバーレスは需要に基づいてコンピューティングを自動的にスケーリングし、データベースを自動一時停止できるため、アイドル期間中はストレージのみ課金されます。変動するワークロードに最適です。

リファレンス↗

変動するワークロードを持つ異なるテナント（SaaS）向けに複数の小さなデータベースをホストする場合。コスト削減のためにリソースを共有する必要がある場合。

→Azure SQL Databaseエラスティックプールを使用します。

理由: エラスティックプールを使用すると、複数のデータベースが事前割り当てされたリソースセット（DTUまたはvCore）を共有できるため、マルチテナントアプリケーションにとって費用対効果の高いソリューションとなります。

データベースが4 TBを超えて成長する（最大100 TB）と予想され、サイズに関係なく高速なスケーリングとほぼ瞬時のバックアップおよび復元が必要な場合。

→Azure SQL Databaseのハイパースケールサービス層を使用します。

理由: ハイパースケールは、非常に大規模なデータベース（VLDB）向けに独自の分散アーキテクチャを使用しており、他の層のサイズ制限を打破し、一定時間でのデータベース操作を提供します。

ゾーン冗長高可用性、およびコンピューティングとストレージの独立したスケーリングを必要とするマイクロサービスアプリケーション向けに、マネージドPostgreSQLデータベースをデプロイする場合。

→Azure Database for PostgreSQL - Flexible Serverを使用します。

理由: Flexible Serverは推奨される製品であり、ゾーン冗長HA、カスタムメンテナンスウィンドウ、および古いSingle Serverモデルと比較して優れたコスト最適化を提供します。

機密データ（例：クレジットカード番号）を、保存時、転送中、およびサーバーでの使用時（メモリ内）に暗号化されたまま保護する必要がある場合。DBAでさえ平文データを見るべきではない場合。

→Always Encryptedを使用します。

理由: Always Encryptedは、キーがクライアントによって保持されるクライアントサイド暗号化テクノロジーであり、データがサーバー上で復号化されることがないようにします。TDEは保存時のデータのみを保護します。

保存されているデータを変更することなく、クエリ結果で非特権ユーザーから機密データ（例：社会保障番号の下4桁のみを表示する）を隠す必要がある場合。

→動的データマスキングを使用します。

理由: DDMは、ユーザー権限に基づいてクエリ時にマスキングルールを適用します。これはデータの露出を制限するためのセキュリティ機能であり、暗号化機能ではありません。

リージョン障害発生時に自動フェールオーバーをセカンダリリージョンに有効にすることで、Azure SQL Databaseのグループの事業継続性を確保する場合。

→自動フェールオーバーグループを構成します。

理由: 自動フェールオーバーグループは、フェールオーバー後にトラフィックを自動的にリダイレクトする統合リスナーエンドポイントを提供し、DRのためのアプリケーション設計を簡素化します。地理冗長バックアップからの復元よりも低いRPO/RTOを提供します。

ビデオファイル、画像、バックアップ、ログなどの大量の非構造化データを費用対効果の高い方法で保存する必要がある場合。

→Azure Blob Storageを使用します。

理由: Blob Storageは、ペタバイト規模の非構造化データを保存するために最適化されたオブジェクトストレージサービスです。構造化クエリワークロードには適していません。

リファレンス↗

アクセスパターンが異なるデータのストレージコストを最適化する場合。

→Azure Blob Storageのアクセス層を使用します：ホット（頻繁にアクセス）、クール（めったにアクセスしない、30日以上）、アーカイブ（ほとんどアクセスしない、180日以上）。

理由: 層はコストのトレードオフを提供します。ホット層はストレージコストが最も高いがアクセスコストが最も低い。アーカイブ層はストレージコストが最も低いがアクセスコストが最も高く、取得レイテンシー（時間単位）がかかります。

コストを最適化するために、ブロブの経過時間または最終アクセス時間に基づいて、ホット、クール、アーカイブ層間でブロブを自動的に移動する場合。

→ストレージアカウントでライフサイクル管理ポリシーを構成します。

理由: これにより階層化プロセスが自動化され、手動での介入なしにデータが常に最もコスト効率の高い層に保持されるようになります。

SMBファイル共有を使用するオンプレミスアプリケーションを移行する場合。複数のVMが同じ共有フォルダーをマウントしてアクセスする必要がある場合。

→Azure File Storageを使用します。

理由: Azure Filesは、SMBおよびNFSプロトコルを介してアクセスできる、クラウド内の完全に管理されたファイル共有を提供し、オンプレミスファイルサーバーの直接的な代替となります。

効率的なディレクトリレベル操作と、POSIXライクなきめ細かいアクセス制御を必要とするビッグデータ分析用のデータレイクを構築する場合。

→Azure Data Lake Storage Gen2を使用します。

理由: ADLS Gen2はBlob Storage上に構築されており、階層型名前空間（アトミックなディレクトリ操作用）とPOSIX準拠のACLのサポートを追加しています。これらはSparkのようなビッグデータフレームワークにおけるパフォーマンスとセキュリティにとって不可欠です。

グローバルアプリケーションが、NoSQLデータベースに対して、1桁ミリ秒の読み取り/書き込みレイテンシー、自動マルチリージョンレプリケーション、および水平スケーリングを必要とする場合。

→Azure Cosmos DBを使用します。

理由: Cosmos DBは、グローバルに分散されたミッションクリティカルなアプリケーション向けに設計されており、ターンキーグローバル分散、保証された低レイテンシーSLA、および複数の整合性モデルを提供します。

リファレンス↗

新しいCosmos DBアプリケーションのデータモデルとAPIを選択する場合。

→NoSQL用API（ドキュメント）、MongoDB API（ドキュメント）、Apache Gremlin API（グラフ）、Table API（キーバリュー）、またはApache Cassandra API（ワイドカラム）を使用します。

理由: データモデルと既存のアプリケーションスタックに最適なAPIを選択してください。新しいJSONベースのアプリにはNoSQLを、関連性の高いデータにはGremlinを、既存のワークロードを移行する場合はその他（MongoDB、Cassandra、Table Storage）を使用します。

Cosmos DBアプリケーションの読み取り整合性、可用性、パフォーマンスのバランスを取る場合。

→Strong、Bounded Staleness、Session（デフォルト）、Consistent Prefix、Eventualの5つの整合性レベルから選択します。

理由: Strongは最高の整合性を提供しますが、最も高いレイテンシーを伴います。Eventualは最も低いレイテンシーを提供しますが、最も弱い整合性です。Sessionが最も一般的で、ユーザーが自分のセッション内で書き込んだ内容を読み取ることを保証します。

ダウンストリームサービスが、Cosmos DBコンテナーで作成または更新されたデータにほぼリアルタイムで反応する必要がある場合（例：検索インデックスを更新するため）。

→Cosmos DB変更フィードを使用します。

理由: 変更フィードは、永続的で順序付けされた変更ログを提供します。データベースをポーリングすることなくイベント駆動型アーキテクチャを構築するために、Azure Functionsによって一般的に利用されます。

トランザクションワークロードのパフォーマンスに影響を与えることなく（HTAP）、運用中のCosmos DBデータに対して複雑な分析クエリを実行する必要がある場合。

→Azure Cosmos DB分析ストアを有効にし、Azure Synapse Linkを使用します。

理由: 分析ストアは、トランザクションデータの完全に分離された、自動同期されたカラム形式の表現です。トランザクションの要求ユニット（RU）を消費することなく、Synapseを介した分析クエリを可能にします。

大量のシンプルで構造化された非リレーショナルデータ（例：デバイスのテレメトリー）を、非常に低コストで高速なキーベースのルックアップのために保存する場合。

→Azure Table Storageを使用します。

理由: Table Storageは、PartitionKeyとRowKeyによる大量のシンプルなルックアップに最適化されたNoSQLキーバリューストアです。低レイテンシーSLAとグローバル分散が不要な場合、Cosmos DBよりも大幅に安価です。

メッセージが非同期に処理されるアプリケーションコンポーネントを分離するために、シンプルで信頼性の高いメッセージングシステムが必要な場合。

→Azure Queue Storageを使用します。

理由: Queue Storageは、基本的な非同期通信パターン向けに、シンプルでコスト効率が高く、信頼性の高いメッセージキューを提供します。

様々なオンプレミスおよびクラウドソースからデータを移動および変換する複雑なデータ統合ワークフローを構築、スケジュール、監視する必要がある場合。

→Azure Data Factory (ADF) を使用します。

理由: ADFは、ETL/ELTパイプラインを大規模に構築および管理するためのマネージドクラウドオーケストレーションサービスであり、広範な接続機能と監視機能を提供します。

リファレンス↗

Azure Data Factoryパイプラインが、企業ファイアウォールの背後にあるオンプレミスのデータソースにアクセスする必要がある場合。

→オンプレミスネットワーク内のマシンにセルフホスト型統合ランタイム (IR) をインストールします。

理由: セルフホスト型IRはセキュアなゲートウェイとして機能し、クラウド内のADFがオンプレミスソースをパブリックインターネットに公開することなく、それらに接続してデータを移動できるようにします。

データウェアハウジング（SQL）、ビッグデータ分析（Spark）、データ探索（サーバーレスSQL）、データ統合のための単一の統合プラットフォームが必要な場合。

→Azure Synapse Analyticsを使用します。

理由: Synapseは、これらの異なる分析エンジンを統合する統一ワークスペース（Synapse Studio）を提供し、複雑さと統合オーバーヘッドを削減します。

Synapse Analytics内でSQLクエリエンジンを選択する場合。

→データレイク内のデータに対するアドホックな探索的クエリには、クエリごとの支払いモデルを持つサーバーレスSQLプールを使用します。プロビジョニングされたリソースを持つ高パフォーマンスで予測可能なデータウェアハウジングワークロードには、専用SQLプールを使用します。

理由: サーバーレスは予測不可能な探索と発見に適しています。専用プールは、パフォーマンスSLAを伴う本番環境のBIおよびレポートに適しています。

IoT HubやEvent Hubsなどのソースから大量のストリーミングデータをリアルタイムで処理および分析し、ライブダッシュボードを強化したりアラートをトリガーしたりする必要がある場合。

→Azure Stream Analyticsを使用します。

理由: Stream Analyticsは、シンプルなSQLライクなクエリ言語を使用して、移動中のデータを低レイテンシーで分析するリアルタイムイベント処理エンジンです。

データサイエンスチームが、Apache Sparkを使用して大規模なデータエンジニアリングと機械学習のためのコラボレーション可能なノートブックベースの環境を必要とする場合。

→Azure Databricksを使用します。

理由: Databricksは、最適化されたSparkランタイム、コラボレーション可能なノートブック、および統合されたML機能（MLflow）を提供し、Azure上の高度な分析およびMLのための最高のプラットフォームとなっています。

モバイルアプリ、ウェブテレメトリー、IoTデバイスなどのソースから毎秒数百万イベントをリアルタイム処理のために取り込む必要がある場合。

→Azure Event Hubsを使用します。

理由: Event Hubsは、高スループットのイベント取り込み向けに設計されたビッグデータストリーミングプラットフォームです。ストリーミングデータの「玄関口」として機能し、プロデューサーとコンシューマーを分離します。

組織が、データエンジニアリング、データサイエンス、データウェアハウジング、BIを組み合わせた単一の統合SaaS分析プラットフォームを、最小限のインフラストラクチャ管理で必要とする場合。

→Microsoft Fabricを使用します。

理由: Fabricは、単一のデータレイク（OneLake）上に構築されたエンドツーエンドのSaaSベースの分析エクスペリエンスを提供します。個別のPaaSサービスで構築する場合と比較して、アーキテクチャを簡素化し、統合のオーバーヘッドを削減します。

リファレンス↗

Microsoft Fabric内で、Sparkエンジン（データエンジニアリング用）とSQLエンジン（BI用）の両方からアクセスできるオープンなDelta Lake形式でデータを保存する単一のアーティファクトが必要な場合。

→Microsoft Fabric Lakehouseを使用します。

理由: LakehouseはFabricにおけるコアなアーキテクチャパターンです。データレイクのスケーラビリティと柔軟性を、データウェアハウスのトランザクション保証とSQLクエリ機能と組み合わせています。

Microsoft Fabric内のPower BIレポートが、インポートモードのパフォーマンスとDirectQueryのデータ鮮度を両立させつつ、OneLakeから直接大量のデータをクエリする必要がある場合。

→Power BIでDirect Lakeモードを使用します。

理由: Direct LakeはFabric独自の機能で、Parquet/DeltaファイルをオンデマンドでPower BIエンジンメモリに直接ロードし、データの重複とクエリレイテンシーを回避しながら、ほぼリアルタイムのデータアクセスを提供します。

ビジネスユーザーが様々なデータソースに接続し、インタラクティブなダッシュボードやレポートを作成し、組織全体でインサイトを共有する必要がある場合。

→Power BIを使用します。

理由: Power BIは、インタラクティブなデータビジュアライゼーションを構築するためのMicrosoftのビジネス分析サービスです。作成にはPower BI Desktopを、共有と共同作業にはPower BI Serviceを使用します。

Power BIで、複数ページのインタラクティブな分析と、単一ページの概要レベルのビューを区別する場合。

→レポートは、単一のデータセットから構築された詳細でインタラクティブなビジュアルの複数ページのコレクションです。ダッシュボードは、1つ以上のレポートからピン留めされたタイルで構成される単一のキャンバスで、一目でわかる概要を提供します。

理由: レポートは詳細な分析用です。ダッシュボードは主要なメトリックの監視用です。

単一のPower BIレポートを複数のユーザーと共有する必要があるが、各ユーザーは自分に関連するデータのみを見るべきである場合（例：営業マネージャーは自分の地域のデータのみを見る）。

→行レベルセキュリティ (RLS) を実装します。

理由: RLSはユーザーロールに基づいてフィルタールールを定義し、データモデルレベルでデータセキュリティを強制するため、同じレポートにアクセスするユーザーは異なるデータのサブセットを参照します。

印刷またはPDFエクスポートに最適化された、高度にフォーマットされたピクセルパーフェクトなレポート（請求書や財務諸表など）を生成する必要がある場合。

→Power BIページ分割レポートを使用します。

理由: ページ分割レポートは、オンスクリーン探索用の標準的なインタラクティブPower BIレポートとは異なり、ヘッダー、フッター、改ページを厳密に制御できる印刷準備済みのレイアウト向けに設計されています。

数十億行を含むPower BIデータセットの更新に時間がかかりすぎる場合。データの変更が頻繁なのは過去数日分のみである場合。

→データセットで増分更新を構成します。

理由: 増分更新はデータ（通常は日付ごと）をパーティション分割し、最新のパーティションのみを更新することで、大規模データセットの更新時間とリソース使用量を劇的に削減します。

単一のPower BIレポートが、事前ロードされた高パフォーマンスデータ（インポートモード）と、運用ソースからのリアルタイムデータ（DirectQueryモード）を組み合わせる必要がある場合。

→Power BI複合モデルを使用します。

理由: 複合モデルを使用すると、単一のデータセットで異なるストレージモードのテーブルを組み合わせることができ、パフォーマンスとデータの鮮度をバランスさせる柔軟性を提供します。

組織が、データガバナンスと発見を可能にするために、ハイブリッドデータ環境全体のすべてのデータ資産を発見、分類、カタログ化する必要がある場合。

→Microsoft Purviewを使用します。

理由: Purviewは、自動データスキャン、ビジネス用語集、データ分類、エンドツーエンドのデータリネージ可視化を提供する統合データガバナンスサービスです。