次の方法で共有

マルチテナント機能と Azure Storage

  • [アーティクル]

Azure Storage は、ほぼすべてのソリューションで使用される基本的サービスです。 マルチテナント ソリューションでは、多くの場合、BLOB、ファイル、キュー、およびテーブルのストレージとして Azure Storage を使用します。 このページでは、マルチテナント ソリューションに役立つ Azure Storage の機能の一部について説明し、Azure Storage を使用する方法を計画するときに役立つガイダンスへのリンクを提供します。

マルチテナント機能を支援する Azure Storage の機能

Azure Storage には、マルチテナント機能を支援する多くの機能が含まれています。

共有アクセス署名

クライアント アプリケーションから Azure Storage を操作する場合は、コンテンツ配信ネットワークや API など、制御する別のコンポーネントを介してクライアント要求を送信するのか、クライアントがストレージ アカウントに直接接続する必要があるのかを検討することが重要です。 別のコンポーネントを介して要求を送信することに、もっともな理由 (ネットワークのエッジでデータをキャッシュするなど) がある場合があります。 その一方で、クライアントのエンドポイントが Azure Storage に直接接続してデータのダウンロードやアップロードを行う方がメリットがある場合もあります。 この接続は、ソリューションのパフォーマンスを向上させるのに役立ちます。大きな BLOB または多数のファイルを扱う場合は特にそうです。 また、バックエンド アプリケーションとサーバーの負荷が軽減され、ネットワーク ホップの数が減少します。 Shared Access Signature (SAS) を使用すると、クライアント アプリケーションに、Azure Storage 内のオブジェクトへのアクセスを安全に提供できます。

Shared Access Signature を使用すると、クライアントが実行できる操作の範囲と、クライアントが操作を実行できる対象のオブジェクトを制限できます。 たとえば、あなたがすべてのテナントに使用できる共有ストレージ アカウントを持っていて、 tenantaという名前の BLOB コンテナーにテナント A のすべてのデータを格納している場合、SAS を作成して、テナント A のユーザーだけにそのコンテナーへのアクセスを許可することができます。 詳細については、「分離モデル」を参照して、ストレージ アカウント内のテナントのデータを分離するために使用できる方法を確認してください。

バレー キー パターン は、制約付きでスコープ指定された Shared Access Signature をアプリケーション層から発行する方法として役立ちます。 たとえば、ユーザーがビデオをアップロードできるマルチテナント アプリケーションがあるとします。 API またはアプリケーションの層で、独自の認証システムを使用してクライアントを認証できます。 その後、SAS をクライアントに提供すると、それを使用して、指定した BLOB、指定したコンテナーと BLOB パスにビデオ ファイルをアップロードできるようになります。 このとき、クライアントはファイルをストレージ アカウントに直接アップロードするので、API に余分なトラフィックや負荷が生じるのを回避できます。 BLOB コンテナーからのデータの読み取り、またはコンテナー内の別の部分、ストレージ アカウントの別のコンテナーへのデータの書き込みが試行されると、Azure Storage がその要求をブロックします。 構成可能な期間が経過すると、署名の有効期限が切れます。

保存されているアクセス ポリシー は SAS 機能を拡張するものです。これにより、単一のポリシーを定義し、これを、複数の Shared Access Signature を発行するときに使用できます。

ID ベースのアクセス制御

Azure Storage は、Microsoft Entra ID を使用して、 ID ベースのアクセス制御 も提供します。 また、この機能を使用すると、 属性ベースのアクセス制御も使用できます。これにより、BLOB パス、または特定のテナント ID でタグ付けされた BLOB へのアクセスがきめ細かく行えます。

ライフサイクル管理

マルチテナント ソリューションで BLOB ストレージを使用する場合、テナントによってはデータ保持に異なるポリシーが必要になる場合があります。 大量のデータを格納する場合は、コストを最適化するために、特定のテナントのデータが クールまたはアーカイブのストレージ層に自動的に移動するように構成しなければならないことがあります。

ライフサイクル管理ポリシー を使用して、すべてのテナント、またはテナントのサブセットの BLOB ライフサイクルを設定することを検討してください。 ライフサイクル管理ポリシーは、BLOB コンテナーまたはコンテナー内の BLOB のサブセットに適用できます。 ただし、ライフサイクル管理ポリシーで指定できるルールの数には制限があります。 マルチテナント環境でこの機能の使用を計画およびテストして、制限を超える場合は複数のストレージ アカウントをデプロイすることを検討してください。

不変ストレージ

時間ベースの保持ポリシーを使用してストレージ コンテナーに 不変 BLOB ストレージ を構成すると、指定した時間より前にデータが削除または変更されることが防止されます。 この防止はストレージ アカウント レイヤーで適用され、すべてのユーザーに適用されます。 組織の管理者であっても、不変データを削除できません。

不変ストレージは、データまたはレコードを保持しなければならないという法的またはコンプライアンス要件を持つテナントを扱う場合に役立ちます。 ただし、実際の テナント ライフサイクル のコンテキスト内でこの機能がどのように使用されるのかを検討する必要があります。 たとえば、オフボードしたテナントがデータの削除を要求した場合、この要求を満たすことができない可能性があります。 テナントのデータに不変ストレージを使用する場合は、サービス使用条件でこの問題に対処する方法を検討してください。

サーバー側のコピー

マルチテナント システムでは、あるストレージ アカウントから別のストレージ アカウントにデータを移動することが必要になる場合があります。 たとえば、デプロイ スタンプ間でテナントを移動したり、 シャード化された 一連のストレージ アカウントを再調整したりする場合は、特定のテナントのデータをコピーまたは移動する必要があります。 大量のデータを操作する場合は、 サーバー側のコピー API を使用して、データの移行にかかる時間を減らすことをお勧めします。

AzCopy ツール は、コピー プロセスを管理するために、ご自身のコンピューターから、または仮想マシンから実行できるアプリケーションです。 AzCopy はサーバー側のコピー機能と互換性があり、独自のソリューションから実行できる、スクリプト実行可能なコマンド ライン インターフェイスを提供します。 AzCopy は、大量のデータをアップロードおよびダウンロードする場合にも役立ちます。

コードからサーバー側のコピー API を直接使用する必要がある場合は、 Put Block From URL API、 Put Page From URL API、 Append Block From URL API、 Copy Blob From URL API (小さい BLOB を操作するとき) の使用を検討してください。

オブジェクト レプリケーション

オブジェクト レプリケーション 機能は、ソースと宛先のストレージ アカウントの間でデータを自動的にレプリケートします。 オブジェクトのレプリケーションは非同期です。 マルチテナント ソリューションでは、この機能は、デプロイ スタンプ間で、または Geode パターンの実装でデータを継続的にレプリケートする必要がある場合に役立ちます。

暗号化

Azure Storage を使用すると、データの 暗号化キーを指定 できます。 マルチテナント ソリューションでは、この機能を 暗号化スコープと組み合わせることを検討してください。これにより、データが同じストレージ アカウントに格納されている場合でも、テナントごとに異なる暗号化キーを定義できます。 これらの機能を組み合わせて使用すると、テナントは、自身が所有するデータの制御もできるようにもなります。 アカウントを非アクティブ化する必要がある場合は、暗号化キーを削除すると、各自のデータにアクセスできなくなります。

監視

マルチテナント ソリューションを使用する場合は、 テナントごとに消費量を測定する必要があるかどうかを検討し、各テナントに使用されるストレージの量 (容量) や各テナントのデータに対して実行される操作の数など、追跡する必要がある具体的なメトリックを定義します。 また、 コストの割り当て を使用して、各テナントの使用量に基づくコストを追跡し、複数のサブスクリプション間でチャージバックを有効にすることもできます。

Azure Storage には、組み込みの監視機能が用意されています。 Azure Storage アカウント内で使用するサービスを検討することが重要です。 たとえば、 BLOBを扱う場合、ストレージ アカウントの合計容量を表示できますが、1 つのコンテナーについてはできません。 一方、ファイル共有を使用する場合は、各共有の容量を表示できますが、フォルダー単位ではできません。

また、 Azure Storage に対して行われたすべての要求を記録することもでき、それらのログを集計して分析できます。 このアプローチにより、各テナントのデータをどのように集約し、グループ化するかについて、より柔軟に対応できるようになります。 ただし、Azure Storage に対して多くの要求を作成するソリューションでは、この方法で得られるメリットが、ログをキャプチャして処理する際のコストに見合うものかどうかを検討することが重要です。

Azure Storage インベントリ では、BLOB コンテナーの合計サイズを測定する別の方法が提供されます。

分離モデル

Azure Storage を使用するマルチテナント システムを扱う場合は、使用する分離レベルを決定する必要があります。 Azure Storage では、いくつかの分離モデルがサポートされます。

テナントあたりのストレージ アカウント数

最も強力な分離レベルは、テナントの専用ストレージ アカウントをデプロイする方法です。 これにより、すべてのストレージ キーが分離され、個別にローテーションできます。 この方法を使用すると、各ストレージ アカウントに適用される制限とクォータを回避するためにソリューションをスケーリングできますが、1 つの Azure サブスクリプションにデプロイできるストレージ アカウントの最大数を考慮する必要もあります。

注意

Azure Storage には、分離モデルを選択するときに考慮する必要がある多くのクォータと制限があります。 たとえば、 Azure サービスの制限、 スケーラビリティ ターゲット、 Azure Storage リソース プロバイダーのスケーラビリティ ターゲットなどがあります。

さらに、Azure Storage の各コンポーネントには、テナントを分離するためのさらなるオプションも用意されています。

BLOB ストレージ分離モデル

次の表に、Azure Storage BLOB の主なテナント分離モデル間の相違点を要約します。

考慮事項 共有 BLOB コンテナー テナントごとの BLOB コンテナー テナントあたりのストレージ アカウント数
データの分離 低から中。 パスを使用して、各テナントのデータまたは階層型名前空間を識別する 中。 コンテナースコープの SAS URL を使用して、セキュリティ分離をサポートする 高
パフォーマンスの分離 低 低。 ほとんどのクォータと制限がストレージ アカウント全体に適用される 高
デプロイの複雑性 低 Medium 高
操作の複雑さ 低 Medium 高
シナリオ例 テナントごとに少数の BLOB を格納する テナントスコープの SAS URL を発行する テナントごとに分離されたデプロイ スタンプ

共有 BLOB コンテナー

BLOB ストレージを扱う場合は、共有 BLOB コンテナーを使用することを選択できます。その場合、BLOB パスを使用してテナントごとにデータを分離できます。

テナント ID BLOB パスの例
tenant-a https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4
tenant-b https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4

この方法は実装が簡単ですが、多くのシナリオで、BLOB パスではテナント間で十分な分離が提供されません。 その理由は、BLOB ストレージでは、ディレクトリまたはフォルダーの概念が提供されないためです。 つまり、指定されたパス内のすべての BLOB にアクセス権を割り当てることができないということです。 ただし、Azure Storage には、 指定したプレフィックスで始まる BLOB を一覧表示 (列挙)する機能が用意されています。これは、共有 BLOB コンテナーを扱うときに役立ち、ディレクトリ レベルのアクセス制御を必要としません。

Azure Storage の 階層型名前空間 機能により、ディレクトリ固有のアクセス制御など、ディレクトリまたはフォルダーの概念をより強固にした機能が提供されます。 これは、共有 BLOB コンテナーがあるが、ある 1 つのテナントのデータへのアクセスを許可する必要があるというマルチテナント シナリオで役立ちます。

一部のマルチテナント ソリューションでは、ユーザー インターフェイスをカスタマイズするためのテナント アイコンなど、テナントごとに 1 つの BLOB または BLOB のセットを格納すれば十分である場合があります。 このようなシナリオでは、1 つの共有 BLOB コンテナーで十分な場合があります。 テナント識別子を BLOB 名として使用し、BLOB パスを列挙する代わりに特定の BLOB を読み取ることができます。

共有コンテナーを使用する場合は、テナントごとにデータと Azure Storage サービスの使用状況を追跡する必要があるかどうかを検討し、そのための方法を計画します。 詳細については、「監視」を参照してください。

テナントごとの BLOB コンテナー

1 つのストレージ アカウント内のテナントごとに個別の BLOB コンテナーを作成できます。 1 つのストレージ アカウント内で作成できる BLOB コンテナーの数に制限はありません。

テナントごとにコンテナーを作成すると、Azure Storage のアクセス制御 (SAS を含む) を使用して、各テナントのデータのアクセスを管理できます。 また、各コンテナーで使用されている容量を簡単に監視できます。

ファイル ストレージ分離モデル

次の表に、Azure Storage ファイルの主なテナント分離モデル間の相違点を要約します。

考慮事項 共有ファイルによる共有 テナントごとのファイル共有 テナントあたりのストレージ アカウント数
データの分離 中/高。 テナント固有のファイルとディレクトリの承認規則を適用する 中/高 高
パフォーマンスの分離 低 低から中。 ほとんどのクォータと制限はストレージ アカウント全体に適用されますが、サイズ クォータは共有ごとのレベルで設定します 高
デプロイの複雑性 低 Medium 高
操作の複雑さ 低 Medium 高
シナリオ例 アプリケーションによりファイルへのすべてのアクセスを制御する テナントはそれらに専用のファイルにアクセスする テナントごとに分離されたデプロイ スタンプ

共有ファイルによる共有

ファイル共有を使用する場合は、共有ファイルによる共有を使用することを選択できます。その場合、ファイル パスを使用して、各テナントのデータを分離できます。

テナント ID example_file_path
tenant-a https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4
tenant-b https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4

サーバー メッセージ ブロック (SMB) プロトコルを使用して通信できるアプリケーションを使用し、オンプレミスまたは Azure で Active Directory Domain Services を使用する場合、ファイル共有は、共有とディレクトリ/ファイル レベルの両方での 許可をサポート します。

その他のシナリオでは、SAS を使用して特定のファイル共有またはファイルへのアクセスを許可することを検討してください。 SAS を使用する場合、ディレクトリへのアクセスを許可することはできません。

共有ファイルによる共有を使用する場合は、テナントごとにデータと Azure Storage サービスの使用状況を追跡する必要があるかどうかを検討し、(必要に応じて) そのための方法を計画します。 詳細については、「監視」を参照してください。

テナントごとのファイル共有

1 つのストレージ アカウント内のテナントごとに個別のファイル共有を作成できます。 1 つのストレージ アカウント内に作成できるファイル共有の数に制限はありません。

テナントごとにファイル共有を作成すると、Azure Storage のアクセス制御 (SAS を含む) を使用して、各テナントのデータのアクセスを管理できます。 また、各ファイル共有で使用されている容量を簡単に監視できます。

テーブル ストレージ分離モデル

次の表に、Azure Storage テーブルの主なテナント分離モデル間の相違点を要約します。

考慮事項 テナントごとのパーティション キーを持つ共有テーブル テナントごとのテーブル テナントあたりのストレージ アカウント数
データの分離 低。 アプリケーションによって分離を強制する 低から中 高
パフォーマンスの分離 低 低。 ほとんどのクォータと制限がストレージ アカウント全体に適用される 高
デプロイの複雑性 低 Medium 高
操作の複雑さ 低 Medium 高
シナリオ例 共有アプリケーション層を備えた大規模なマルチテナント ソリューション テナントスコープの SAS URL を発行する テナントごとに分離されたデプロイ スタンプ

テナントごとのパーティション キーを持つ共有テーブル

1 つの共有テーブルでテーブル ストレージを使用する場合は、 パーティション分割のための組み込みサポートの使用を検討できます。 各エンティティには、パーティション キーを含める必要があります。 テナント識別子は、多くの場合、パーティション キーとして適しています。

Shared Access Signature とポリシーを使用すると、パーティション キーの範囲を指定できます。この場合、署名を含む要求は、指定のパーティション キー範囲にのみアクセスできるようになります。 これにより、他のテナントに影響を与えずに、信頼されていないクライアントが単一のテナントのパーティションにアクセスすることを許可する バレー キー パターンを実装できます。

大規模なアプリケーションの場合は、各テーブル パーティションとストレージ アカウントの最大スループットを考慮してください。

テナントごとのテーブル

1 つのストレージ アカウント内のテナントごとに個別のテーブルを作成できます。 ストレージ アカウント内に作成できるテーブルの数に制限はありません。

テナントごとにテーブルを作成することにより、Azure Storage のアクセス制御 (SAS を含む) を使用して、各テナントのデータのアクセスを管理できます。

キュー ストレージ分離モデル

次の表に、Azure Storage キューの主なテナント分離モデル間の相違点を要約します。

考慮事項 共有キュー テナントごとのキュー テナントあたりのストレージ アカウント数
データの分離 低 低から中 高
パフォーマンスの分離 低 低。 ほとんどのクォータと制限がストレージ アカウント全体に適用される 高
デプロイの複雑性 低 Medium 高
操作の複雑さ 低 Medium 高
シナリオ例 共有アプリケーション層を備えた大規模なマルチテナント ソリューション テナントスコープの SAS URL を発行する テナントごとに分離されたデプロイ スタンプ

共有キュー

キューを共有することを選択する場合は、適用されるクォータと制限について検討してください。 要求数の多いソリューションでは、1秒あたり 2000 件のメッセージというターゲット スループットが十分であるかどうかを検討します。

キューではパーティション分割もサブキューも提供されないため、すべてのテナントのデータが混在する可能性があります。

テナントごとのキュー

1 つのストレージ アカウント内のテナントごとに個別のキューを作成できます。 1 つのストレージ アカウント内に作成できるキューの数に制限はありません。

テナントごとにキューを作成すると、Azure Storage のアクセス制御 (SAS を含む) を使用して、各テナントのデータのアクセスを管理できます。

各テナントのキューを動的に作成する場合は、アプリケーション層が各テナントのキューからのメッセージをどのように使用するかを検討してください。 より高度なシナリオでは、 Azure Service Busを使用することを検討してください。これは、マルチテナント ソリューションで役立つ トピックとサブスクリプション、 セッション、 メッセージの自動転送などの機能をサポートしています。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

  • Dr. Christian Geuer-Pollmann | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Patrick Horn | FastTrack for Azure のシニア カスタマー エンジニアリング マネージャー
  • Ben Hummerstone | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Vic Perdana | クラウド ソリューション アーキテクト、Azure ISV

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

マルチテナントのストレージとデータ アプローチを確認します。