次の方法で共有

マルチテナントと 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 を使用して、クライアントが実行できる操作のスコープと、クライアントが操作を実行できるオブジェクトを制限できます。 たとえば、すべてのテナントの共有ストレージ アカウントがあり、テナント A のすべてのデータを tenanta という名前の BLOB コンテナーに格納する場合は、テナント A のユーザーのみがそのコンテナーにアクセスできるようにする SAS を作成できます。 詳細については、「 分離モデル 」を参照して、ストレージ アカウント内のテナントのデータを分離するために使用できる方法を調べることができます。

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

保存されたアクセス ポリシーは SAS 機能を拡張するため、複数の共有アクセス署名を発行するときに使用できる単一のポリシーを定義できます。

ID ベースのアクセス制御

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

ライフサイクル管理

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

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

不変ストレージ

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

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

サーバー側のコピー

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

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

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

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

オブジェクト レプリケーション機能は、ソース ストレージ アカウントとコピー先ストレージ アカウントの間でデータを自動的にレプリケートします。 オブジェクト レプリケーションは非同期です。 マルチテナント ソリューションでは、この機能は、デプロイ スタンプ間または 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 コンテナー テナントあたりのストレージ アカウント数
データの分離 低 ～ 中。 パスを使用して各テナントのデータまたは階層型名前空間を識別する ミディアム コンテナー スコープの SAS URL を使用してセキュリティの分離をサポートする 高
パフォーマンスの分離 低 低。 ほとんどのクォータと制限は、ストレージ アカウント全体に適用されます 高
デプロイの複雑性 低 ミディアム 高
操作の複雑さ 低 ミディアム 高
シナリオ例 テナントごとに少数の BLOB を格納する テナントスコープの SAS URL を発行する テナントごとに分離されたデプロイ スタンプ

共有ブロブコンテナー

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 コンテナーを作成できます。 ストレージ アカウント内で作成できる BLOB コンテナーの数に制限はありません。

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

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

次の表は、Azure Storage ファイルの主なテナント分離モデルの違いをまとめたものです。

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

共有ファイルによる共有

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

テナント ID ファイル パスの例
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 つのストレージ アカウント内で、テナントごとに個別のファイル共有を作成できます。 ストレージ アカウント内で作成できるファイル共有の数に制限はありません。

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

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

次の表は、Azure Storage テーブルの主なテナント分離モデルの違いをまとめたものです。

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

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

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

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

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

テナントあたりのテーブル数

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

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

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

次の表は、Azure Storage キューの主なテナント分離モデルの違いをまとめたものです。

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

共有キュー

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

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

テナントごとのキュー

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

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

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

貢献者

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

主要な著者

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

その他の共同作成者:

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

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