Azure Queue Storageは、非同期処理用のメッセージを格納します。 この記事では、マルチテナント ソリューションのパーティション分割戦略、分離モデル、キュー ストレージ機能について説明します。 メッセージの負荷の分散、テナントのメッセージの分離、アクセス、暗号化、使用状況の管理に役立つガイダンスを提供します。
パーティション分割戦略
Queue Storage では、キュー内のパーティション キーやサブ キューは公開されません。 キューは、メッセージの負荷を分散するために使用できる最小の境界であり、ストレージ アカウントは次の境界です。 共有キューでは、テナント固有のスループットやパフォーマンスの分離は提供されません。
1 KiB のメッセージの場合、1 つのキューのターゲット スループットは 1 秒あたり最大 2,000 メッセージ、ストレージ アカウントの最大要求レートは 1 秒あたり 20,000 メッセージです。 メッセージのサイズとアクセス パターンは、ワークロードが達成するスループットに影響します。 キュー メッセージは最大 64 KiB です。 より大きなメッセージや高度なブローカー機能については、Azure Service Busの使用を検討してください。
ワークロードがキューごとのターゲットを超える可能性がある場合は、複数のキューにメッセージを分散します。 ルーティングと運用の要件に応じて、テナント、テナント グループまたはサービス レベル、機能ワークロード、デプロイ スタンプ、またはリージョンごとにキューをパーティション分割できます。 キューを他のテナントと共有する大量トラフィックのテナントは、キューのスループットを不釣り合いに多く消費し、他のテナントでスロットリングを引き起こす可能性があります。
同じストレージ アカウント内の複数のキューは、引き続きアカウントの容量とアカウント レベルの構成を共有します。 集計ワークロードがストレージ アカウント ターゲットを超える可能性がある場合、またはテナントで独立したスケールまたはリージョン構成が必要な場合は、複数のストレージ アカウントにキューを分散します。 スロットリングを監視し、指数バックオフ再試行を使用し、文書化されている Queue Storage のスケーラビリティ ターゲットに対してワークロードをテストします。 テナント アクセスとデータ分離のオプションについては、「 分離モデル」を参照してください。
分離モデル
メッセージの負荷を分散する方法を決定したら、適用するテナント分離のレベルを決定します。 Queue Storage では、共有キュー、各テナントのキュー、および各テナントのストレージ アカウントがサポートされます。 次の表は、Queue Storage の主なテナント分離モデルの違いをまとめたものです。
| Consideration | 共有キュー | 各テナントの待ち行列 | 各テナントのストレージ アカウント |
|---|---|---|---|
| データの分離 | 低い。 アプリケーションは分離を強制します。 | 低から中 | 高 |
| パフォーマンスの分離 | Low | 低い。 ほとんどのクォータと制限は、ストレージ アカウント全体に適用されます。 | 高 |
| 配置の複雑性 | Low | Medium | 高 |
| 操作の複雑さ | Low | Medium | 高 |
| サンプル シナリオ | 大規模なマルチテナント ソリューションには、共有アプリケーション層があります。 | テナント スコープの Shared Access Signature (SAS) URL が発行されます。 | 各テナントには、独自のデプロイ スタンプがあります。 |
Note
分離モデルを選択するときは、クォータと制限を考慮してください。 これらの制限にはAzure サービスの制限、Queue Storage のスケーラビリティ ターゲット、および Storage リソース プロバイダーのスケーラビリティ ターゲットが含まれます。
共有キュー
キューを共有する場合、すべてのテナントがそのスループット ターゲットを共有します。 1 つのテナントが負荷をかけすぎると、他のテナントのスロットリングを引き起こす可能性があります。 メッセージの負荷を分散する方法については、パーティション分割戦略を参照してください。
キューはパーティション分割やサブキューを提供しないため、すべてのテナントのデータが混在する可能性があります。 アプリケーションでは、メッセージごとにテナントを識別し、処理中に分離を強制する必要があります。 テナントが他のテナントのメッセージにアクセスしてはならない場合は、共有キューへの直接アクセスをテナントに許可しないでください。
各テナントの待ち行列
1 つのストレージ アカウント内のテナントごとに個別のキューを作成できます。 ストレージ アカウント内で作成できるキューの数に制限はありません。
各テナントのキューは、ルーティングとアクセス制御の境界を提供しますが、パフォーマンスの分離は提供しません。 アカウント内のすべてのキューは、ストレージ アカウントの容量とパフォーマンスのターゲットを共有します。
このシナリオでは、SAS を含む Queue Storage アクセス制御を使用して、各テナントのデータのアクセスを管理できます。
テナントごとにキューを動的に作成する場合は、アプリケーション層が各テナントのキューからのメッセージを使用する方法を検討してください。 高度なシナリオでは、セッション、メッセージ自動転送、トピックとサブスクリプションなどの機能をサポートするAzure Service Busの使用を検討してください。
各テナントのストレージ アカウント
最も強力な分離レベルでは、テナントごとに専用のストレージ アカウントが使用されます。 このモデルにより、ストレージ アカウント キーが完全に分離され、個別にローテーションできます。 また、各ストレージ アカウントの制限とクォータを超えてソリューションをスケーリングすることもできます。 メッセージの量が多いテナントや、独立したリージョン構成またはパフォーマンス目標を必要とするテナントの場合は、このモデルを検討してください。 ただし、1 つの Azure サブスクリプション内で許可されるストレージ アカウントの最大数も考慮する必要があります。
マルチテナントをサポートする Queue Storage の機能
次の Queue Storage 機能は、選択した分離モデルの実装と運用に役立ちます。
Shared Access Signature
クライアント アプリケーションから Queue Storage を使用する場合は、アプリケーション層を介して要求をルーティングするか、クライアントがキューに直接接続できるようにするかを検討します。 直接クライアント アクセスを使用すると、バックエンド アプリケーションの負荷とネットワーク ホップの数を減らすことができます。
Shared Access Signature (SAS) を使用すると、クライアント アプリケーションにキューへの制限付きアクセスを提供できます。 クライアントが実行できる操作と、アクセスが許可される期間を制限できます。 たとえば、メッセージの読み取りまたは削除を許可せずに、テナントが独自のキューにメッセージを追加できるようにする SAS を発行できます。
バレット キー パターンを使用して、アプリケーション層から制約付き SAS トークンとスコープ付き SAS トークンを発行します。 アプリケーションの認証システムを使用してクライアントを認証し、アクセスできるテナントのキューを決定し、必要な操作に対してのみトークンを発行します。
保存されたアクセス ポリシーを 使用すると、複数のサービス SAS トークンを発行するときに使用する 1 つのポリシーを定義できます。 保存されたアクセス ポリシーは、ユーザー委任 SAS トークンまたはアカウント SAS トークンには適用されません。
ユーザー委任 SAS
サービス SAS またはアカウント SAS は、いずれかのストレージ アカウント キーで署名されます。 ユーザー委任 SAS は、代わりにMicrosoft Entra資格情報で保護されます。 アプリケーション層は、独自のマネージド ID を使用してユーザー委任キーを要求した後、テナントごとにスコープ付きの時間制限付きトークンを署名して生成します。 アカウント キーの配布や保存は行いません。 Microsoftでは、設計上対応している場合は、アカウント キー SAS ではなくユーザー委任 SAS を使用することをお勧めします。
トークンの有効期間を短くし、トークンが侵害された場合にアクセスを取り消す方法を計画します。 アプリケーション ログを Queue Storage ログと関連付けるために、ストレージ要求にクライアント要求 ID (x-ms-client-request-id) を設定し、テナント ID と共にログに記録します。
ID ベースのアクセス制御
Queue Storage は、Microsoft Entra IDを介して ID ベースのアクセス制御を提供します。 マネージド ID と Azure のロールベースのアクセス制御を使用して、アカウント キーを保存することなく、アプリケーションがキューにアクセスできるように認証します。 テナントが直接アクセスを必要とする場合は、各テナントのキューへのアクセス範囲を制限します。 キュー レベルの認可では、共有キュー内の個々のテナントのメッセージは分離されません。
Encryption
Queue Storage は、Microsoft マネージド キーを使用して、既定で保存データを暗号化します。 カスタマー マネージド キーを使用するには、アカウントの作成時に、キューにアカウント スコープの暗号化キーを使用するようストレージ アカウントを構成します。 アカウントの作成後に、この暗号化キーのスコープを変更することはできません。
テナントで個別のカスタマー マネージド キーが必要な場合は、個別のストレージ アカウントを使用します。 Blob Storage の暗号化スコープと、個々の要求で顧客が指定するキーは、Queue Storage には適用されません。 テナントのライフ サイクルと共に、キーのローテーションと失効を計画します。
Monitoring
マルチテナント ソリューションでは、 各テナントの使用量を測定する必要があるかどうかを検討します。 各テナントのメッセージや操作の数など、追跡する特定のメトリックを定義します。 また、コストの割り当てを使用して、各テナントの使用状況のコストを追跡し、複数のサブスクリプション間でチャージバックを有効にすることもできます。
Queue Storage には、 組み込みの監視機能が用意されています。 テナントがキューを共有する場合は、メッセージ処理と使用状況を適切なテナントに関連付けできるように、アプリケーション テレメトリにテナント識別子を含めます。
要求レートと HTTP 500 および 503 応答を監視して、スケーラビリティ ターゲットに近づくキューまたはアカウントを検出します。 このテレメトリをテナント識別子と関連付け、使用状況が共有容量に影響を与えるテナントを識別できるようにします。
要求ログを収集し、アプリケーション テレメトリと共に集計して分析できます。 大量の要求を作成するソリューションでは、これらのログをキャプチャして処理するためのコストがメリットによって正当化されるかどうかを検討します。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主要著者:
- John Downs | プリンシパルソフトウェアエンジニア, Azure パターン＆プラクティス
その他の共同作成者:
- クリスチャン・ゲウアー・ポルマン博士 |プリンシパル カスタマー エンジニア、FastTrack for Azure
- パトリック・ホーン |Azure 用 FastTrack のシニア カスタマー エンジニアリング マネージャー
- Ben Hummerstone |プリンシパル カスタマー エンジニア、FastTrack for Azure
- Vic Perdana | クラウド ソリューション アーキテクト、Azure ISV
- ダニエル・スコット=レインズフォード |パートナー ソリューション アーキテクト、データおよび AI
- Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。