Azure Data Share

解決する課題

部署間や取引先との間でデータを渡すとき、CSV をメール添付したりストレージのキーを共有したりすると、誰に何を渡したのか分からなくなり、更新の反映も手作業になります。Azure Data Share は、こうしたデータ共有を招待と関係（リレーションシップ）に基づくマネージドな仕組みに置き換えます。

• 組織外の相手へ アクセスキーを直接渡さずに データを共有したい
• 共有したデータを 定期的に最新化 して相手へ届けたい
• 誰に何をいつ共有したか を共有元として一元的に把握したい
• 受け取る側として、複数の提供元からのデータを 自分のサブスクリプションに取り込んで 集約したい
• 共有の 開始・停止・条件 をガバナンスのもとで管理したい

主要概念と用語

• データプロバイダー: データを共有する側。共有の中身を定義し、相手を招待する
• データコンシューマー: データを受け取る側。招待を受諾し、自分のストレージや SQL に取り込む
• 共有（Share）: プロバイダーが作成する共有の単位。共有するデータセットと共有方式をまとめたもの
• データセット: 共有に含める実体。Blob やファイル、ADLS のフォルダ、SQL のテーブルなどを指す
• 招待（Invitation）: コンシューマーへの参加依頼。メールアドレスやテナント宛てに送られ、受諾して初めて共有が成立する
• 共有サブスクリプション: コンシューマー側が招待を受諾して作る、受信側の構成。取り込み先や同期設定を持つ
• スナップショット共有: ある時点のデータをコピーしてコンシューマーのストアへ配置する方式。フルとインクリメンタルがある
• インプレース共有（In-place Sharing）: データを複製せず、プロバイダーのソースを参照する形で共有する方式
• スナップショットスケジュール: スナップショットを定期実行して内容を最新化する設定

仕様・制限・クォータ

• 2つの共有方式: コピーを配布する スナップショット共有 と、複製せず参照する インプレース共有 の2方式がある。対応するデータストアは方式によって異なる
• 対応データストア: スナップショット共有は Blob Storage、Data Lake Storage、SQL Database、Synapse などが対象。インプレース共有は対応ストアが限られるため、利用前に公式ドキュメントで確認する
• 増分スナップショット: ファイルやテーブルの更新分のみを共有する増分共有に対応し、全件再送を避けられる
• 招待単位の関係: 1つの共有に複数のコンシューマーを招待でき、コンシューマーごとに受信構成を持つ
• スナップショットの頻度には下限がある: スケジュール実行の最短間隔などにサービス上の制約があり、具体値は変動しうるため公式ドキュメントで確認する
• テナントをまたぐ共有: 別の Microsoft Entra テナントの相手とも、招待を通じて共有できる

内部の仕組み

Azure Data Share は、プロバイダーが定義した共有とコンシューマーが受諾した共有サブスクリプションという2つの構成を関係づけて動作します。実データはプロバイダー自身のストレージや SQL に置かれたままで、共有方式に応じて配布または参照されます。

• スナップショット共有 では、スケジュールまたは手動実行のたびにプロバイダーのソースからコンシューマーのストアへデータがコピーされる。フルスナップショットは全件、インクリメンタルは前回以降の更新分のみを転送する
• インプレース共有 では、データをコピーせずプロバイダーのソースをコンシューマー側から参照する。コピーが発生しないため、大規模データを最新の状態で共有しやすい
• 招待と受諾 の流れで関係が確立する。コンシューマーが招待を受諾し、取り込み先（ターゲットのストレージや SQL）を指定して初めてデータが流れる
• 同期の管理 は双方で可視化される。プロバイダーは送信状況を、コンシューマーは受信状況とスケジュールを、それぞれの共有から確認できる

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

• 増分共有でコストと時間を削減: 更新分だけを送るインクリメンタルスナップショットを基本にし、全件再送を避ける
• スケジュールは要件から逆算: コンシューマーが必要とする鮮度に合わせてスナップショット頻度を決め、過剰な同期を避ける
• 共有の粒度を設計: 相手や用途ごとに共有を分け、必要なデータセットだけを含めて最小権限で渡す
• 取り込み先を計画: コンシューマー側は受信先ストレージのコストやライフサイクルを設計し、受け取ったデータの保持方針を決める
• インプレースは鮮度重視で: 常時最新が必要な参照系データはインプレース共有を選び、コピーの運用負荷を持たない

運用・監視

• 共有の状態確認: プロバイダーは送信した共有とコンシューマーの一覧、スナップショットの実行履歴を確認できる
• スナップショット履歴: 各実行の成否・所要時間・転送量を追え、失敗時の再実行も行える
• Azure Monitor 連携: 診断設定でログやメトリクスを Log Analytics へ送り、共有の実行状況を可視化・アラート化できる
• 関係の停止: 共有が不要になったらプロバイダー側から取り消せ、以後の同期を止められる

コスト

課金は主にスナップショットの実行（データセットのスナップショット単位）に対して発生し、加えてデータ転送や、プロバイダー・コンシューマー双方のストレージや SQL などソース/ターゲット側リソースのコストがかかります。インプレース共有はコピーを伴わないため、スナップショット実行に紐づく課金の考え方が異なります。

• 増分共有で実行コストを抑える: 更新分のみの転送はスナップショットの負荷と転送量の両方を下げる
• 頻度の最適化: 不要に高い同期頻度はスナップショット回数と転送量を増やすため、鮮度要件に合わせて調整する
• 具体的な単価は変動するため、断定せず公式の料金ページで確認する

セキュリティ

• キーを渡さない共有: ストレージのアクセスキーや接続文字列を相手へ直接渡すことなく、招待ベースでアクセスを成立させる
• マネージド ID: Data Share のリソースはマネージド ID を使ってソースとターゲットのストレージや SQL へアクセスするため、認証情報の直書きを避けられる
• 招待による明示的な同意: コンシューマーが招待を受諾しない限りデータは流れず、誰と共有するかを明示的に制御できる
• RBAC: Microsoft Entra ID と RBAC で、共有の作成・管理・受諾を行える主体を制御する
• テナント境界の尊重: 別テナントとの共有も招待を介するため、相手組織の同意なしにデータが渡ることはない

関連サービス・比較

ハンズオン / CLI例

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

# Data Share アカウントを作成
az datashare account create \
  --resource-group demo-rg \
  --name demo-datashare-0628 \
  --location japaneast

# 共有（スナップショット方式）を作成
az datashare create \
  --resource-group demo-rg \
  --account-name demo-datashare-0628 \
  --name sales-share \
  --share-kind CopyBased

# 送信した共有の一覧を確認
az datashare list \
  --resource-group demo-rg \
  --account-name demo-datashare-0628 \
  --output table