ほとんどのクラウドベースのソリューションは、コンピューティング リソースで構成されています。 これらのリソースには、Web 層とアプリケーション層、バッチ プロセッサ、スケジュールされたジョブ、GPU やハイ パフォーマンス コンピューティングなどの特殊なリソースを含めることができます。 マルチテナント ソリューションは、インフラストラクチャごとにテナントの密度が高いほど運用コストが削減され、管理が簡素化されるため、多くの場合、共有コンピューティング リソースの恩恵を受けることができます。 分離要件と共有インフラストラクチャの影響を考慮する必要があります。
この記事では、ソリューション アーキテクトがマルチテナント コンピューティング レベルを計画する際に考慮すべき重要な考慮事項と要件に関するガイダンスを提供します。 このガイダンスには、コンピューティング サービスにマルチテナントを適用するための一般的なパターンと、回避するアンチパターンが含まれます。
主な考慮事項と要件
マルチテナントと選択した分離モデルの両方が、コンピューティング リソースのスケーリング、パフォーマンス、状態管理、セキュリティに影響します。 次のセクションでは、マルチテナント コンピューティング ソリューションを計画するときに行う必要がある主な決定事項を確認します。
規模
システムは、需要の変化に応じて適切に実行する必要があります。 テナントとトラフィックの数が増えるにつれて、需要の増加に合わせてリソースをスケーリングし、許容できるパフォーマンスを維持することが必要になる場合があります。 同様に、アクティブなユーザーの数やトラフィックの量が減少した場合は、コンピューティング容量を自動的に削減してコストを削減する必要があります。 ただし、容量を調整するときは、ユーザーの中断を最小限に抑える必要があります。
テナントごとに専用リソースをデプロイする場合、各テナントのリソースを個別にスケーリングする柔軟性があります。 コンピューティング リソースが複数のテナント間で共有されるソリューションでは、それらのリソースをスケーリングすることで、すべてのテナントが容量の増加の恩恵を受けることができます。 しかし、すべてのテナントは、全体的な負荷を処理するのに十分なスケールがない場合に苦しみます。 詳細については、「 ノイズの多い近隣のアンチパターン」を参照してください。
クラウド ソリューションを構築するときに、 水平方向または垂直方向にスケーリングするかどうかを選択できます。 テナントの数が増えるマルチテナント ソリューションでは、通常、水平方向にスケーリングすると、柔軟性が向上し、全体的なスケール上限が高くなります。
パフォーマンスの問題は、多くの場合、アプリケーションが負荷を受けるまで検出されません。 Azure Load Testing などのフル マネージド サービスを使用して、負荷がかかってアプリケーションがどのように動作するかを学習できます。
スケーリング トリガー
スケーリングに使用する方法に関係なく、通常は、コンポーネントのスケーリングの原因となるトリガーを計画する必要があります。 共有コンポーネントがある場合は、各テナントのワークロード パターンを考慮して、プロビジョニングされた容量が必要な合計需要を満たしていることを確認します。 この方法は、リソースの競合を防ぎ、テナントで ノイズの多い近隣の問題が発生する可能性を減らすのに役立ちます。 テナントの数を考慮して、スケーリング容量を計画することもできます。 たとえば、100 テナントのサービスに使用するリソースを測定する場合、より多くのテナントをオンボードするときに、追加の 100 テナントごとにリソースが 2 倍になるようにスケーリングを計画できます。
状態
コンピューティング リソースは ステートレスにすることも、 ステートフルにすることもできます。 ステートレス コンポーネントは、要求間でデータを保持しません。 スケーラビリティの観点から見ると、ステートレス コンポーネントは、新しいワーカー、インスタンス、またはノードをすばやく追加できるため、スケールアウトが簡単なことがよくあります。 ステートレス コンポーネントは、要求の処理をすぐに開始することもできます。 アーキテクチャでインスタンスの再利用がサポートされている場合は、あるテナントから別のテナントにインスタンスを再割り当てすることもできます。
ステートフル リソースは、保持する状態の種類に基づいてさらに分割できます。 永続的な状態 は、永続的に格納する必要があるデータです。 クラウド ソリューションでは、コンピューティング レベルに永続的な状態を格納しないようにします。 代わりに、データベースやストレージ アカウントなどのストレージ サービスを使用してください。 一時的な状態 は、一時的に格納されるデータです。 これには、読み取り専用のメモリ内キャッシュと、ローカル ディスク上の一時ファイルのストレージが含まれます。
一時的な状態は、バックエンド ストレージ サービスへの要求の数を減らすことで、アプリケーション層のパフォーマンスを向上させるために役立つことがよくあります。 たとえば、メモリ内キャッシュを使用する場合、データベースに接続せずに、また別の要求を処理したときに最近実行した集中的なクエリを実行せずに、読み取り要求を処理できる場合があります。
待機時間の影響を受けやすいアプリケーションでは、キャッシュハイドレートのコストが大きくなる可能性があります。 マルチテナント ソリューションは、各テナントで異なるデータをキャッシュする必要がある場合に、この問題を悪化させる可能性があります。 この問題を軽減するために、一部のソリューションでは セッション アフィニティが適用されます。 この方法により、同じコンピューティング ワーカー ノードが特定のユーザーまたはテナントのすべての要求を処理できるようになります。 セッション アフィニティにより、アプリケーション層のキャッシュを効果的に使用する機能が向上します。 ただし、セッション アフィニティでは、ワーカー間でのスケーリングとトラフィックの負荷分散も複雑になります。 このトレードオフは慎重に検討してください。 多くのアプリケーションでは、セッション アフィニティは必要ありません。
Azure Cache for Redis などの外部キャッシュにデータを格納することもできます。 外部キャッシュは、待機時間の短いデータ取得用に最適化され、コンピューティング リソースから状態を分離して個別にスケーリングおよび管理できるようにします。 多くのソリューションでは、外部キャッシュを使用すると、コンピューティング レベルをステートレスにしたまま、アプリケーションのパフォーマンスを向上させることができます。
重要
メモリ内キャッシュまたは状態を維持するその他のコンポーネントを使用する場合は、テナント間でデータをリークしないようにします。 たとえば、テナントごとにデータが確実に分離されるように、すべてのキャッシュ キーにテナント識別子を事前に設定することを検討してください。
隔離
マルチテナント コンピューティング レベルを設計する場合、テナントの分離にはいくつかのオプションがあります。 すべてのテナントの 共有コンピューティング リソース 、個々のテナント用 の専用コンピューティング リソース 、またはこれらの極端な間の 半分離アプローチ をデプロイできます。 各オプションにはトレードオフがあります。 ソリューションに最適なオプションを決定するには、分離の要件を検討してください。
テナントの論理的な分離と、各テナントに適用される管理責任またはポリシーを分離する方法に関心がある場合があります。 または、テナントのワークロードに合わせて特定の仮想マシン (VM) SKU をデプロイするなど、特定のテナントに個別のリソース構成をデプロイする必要がある場合があります。
選択した分離モデルに応じて、コンポーネントの障害や停止が発生した場合でも、テナント データが適切に分離されたままになります。 通常の自動テスト プロセスで Azure Chaos Studio を使用して、実際の停止をシミュレートする障害を導入することを検討してください。 このテストは、ソリューションが適切なテナント分離を維持し、負荷の下で引き続き機能することを確認するのに役立ちます。
考慮すべきアプローチとパターン
自動スケーリング
Azure コンピューティング サービスには、ワークロードをスケーリングするさまざまな機能が用意されています。 多くのコンピューティング サービスでは自動スケールがサポートされています。そのためには、スケーリングするタイミングを決定し、最小スケール レベルと最大スケール レベルを設定する必要があります。 特定のスケーリング オプションは、使用するコンピューティング サービスによって異なります。 次のサービスまたはコンポーネントの例を参照してください。
Azure App Service:要件に基づいてインフラストラクチャをスケーリングする自動スケール ルールを指定します。
Azure Functions: 関数が実行する作業に基づいて自動的にスケーリングするイベント ドリブン スケーリング モデルなど、複数のスケール オプションから選択します。
Azure Container Apps:イベント ドリブンの自動スケールを使用して、アプリケーションが実行する作業とその現在の負荷に基づいてアプリケーションをスケーリングします。
Azure Kubernetes Service (AKS): アプリケーションの需要に対応するには、 ワークロードを実行するノードの数を調整することが必要になる場合があります。 AKS クラスター内のアプリケーション ワークロードを迅速にスケーリングするには、 仮想ノードを使用できます。
VM: 仮想マシン スケール セットは、アプリケーション を実行する VM インスタンスの数を自動的に増減 できます。
デプロイ スタンプ パターン
デプロイ スタンプ パターンを使用してマルチテナント ソリューションをサポートする方法の詳細については、「マルチテナント ソリューションのアーキテクチャアプローチ」を参照してください。
コンピューティング リソース統合パターン
コンピューティング リソース統合パターンは、基になるコンピューティング リソースを共有することで、コンピューティング インフラストラクチャに対するテナントの密度を高めるのに役立ちます。 コンピューティング リソースを共有することで、それらのリソースの直接コストを削減できます。 また、管理するコンポーネントが少ないため、管理コストが低くなることがよくあります。
ただし、コンピューティング リソースの統合により、 ノイズの多い近隣の問題が発生する可能性が高くなります。 テナントのワークロードは、使用可能なコンピューティング容量の不均衡な量を消費する可能性があります。 多くの場合、このリスクを軽減するには、ソリューションを適切にスケーリングし、クォータや API の制限などの制御を適用して、容量の公平なシェアを超えるテナントを使用しないようにします。
このパターンは、使用するコンピューティング サービスに応じて、さまざまな方法で実現されます。 次のサービスまたはコンポーネントの例を参照してください。
App Service と Azure Functions: ホスティング サーバー インフラストラクチャを表す共有 App Service プランをデプロイします。
Container Apps:共有環境をデプロイします。
AKS: マルチテナント対応アプリケーションを使用して共有ポッドをデプロイします。
VM: すべてのテナントで使用する 1 つの VM セットをデプロイします。
各テナントの専用コンピューティング リソース
また、テナントごとに専用のコンピューティング リソースをデプロイすることもできます。 専用リソースは、各テナントのコンピューティング リソースが他のテナントから確実に分離されるため、 ノイズの多い近隣の問題 のリスクを軽減します。 また、要件に基づいて、テナントのリソースごとに個別の構成をデプロイすることもできます。 ただし、専用リソースでは、通常、リソースに対するテナントの密度が低いため、コストが高くなります。
使用する Azure コンピューティング サービスによっては、さまざまな専用リソースをデプロイすることが必要になる場合があります。
App Service と Azure Functions: テナントごとに個別の App Service プランをデプロイします。
Container Apps: テナントごとに個別の環境をデプロイします。
AKS: テナントごとに専用クラスターをデプロイします。
VM: テナントごとに専用 VM をデプロイします。
物理ホスト レベルの分離は、 Azure 専用ホストでテナント VM を実行することによっても提供できます。これは、1 人の顧客用に物理サーバー全体を予約します。 ただし、通常、この方法は共有ホストを使用するよりもコストがかかります。
準隔離コンピューティング リソース
半分離アプローチでは、他のコンポーネントを共有しながら、分離された構成でソリューションの側面をデプロイする必要があります。
App Service と Azure Functions を使用すると、テナントごとに異なるアプリケーションをデプロイし、共有 App Service プランでアプリケーションをホストできます。 App Service プランは課金単位を表しているため、この方法ではコンピューティング レベルのコストが削減されます。 また、個別の構成とポリシーを各アプリケーションに適用することもできます。 ただし、この方法では、 ノイズの多い近隣の問題のリスクが生じます。
Container Apps を使用して複数のアプリケーションを共有環境にデプロイし、Dapr やその他のツールを使用して各アプリケーションを個別に構成できます。
AKS と Kubernetes では、マルチテナントのさまざまなオプションが提供されています。
共有クラスターとノード プールにデプロイされるテナント固有のリソースを論理的に分離できるテナント固有の名前空間。
共有クラスター上のテナント固有のノードまたはノード プール。
同じノード プールを使用する可能性があるテナント固有のポッド。
また、AKS を使用してポッド レベルのガバナンスを適用して 、ノイズの多い近隣の問題を軽減することもできます。 詳細については、「 アプリケーション開発者が AKS でリソースを管理するためのベスト プラクティス」を参照してください。
また、Kubernetes クラスター内の共有コンポーネントと、マルチテナントがこれらのコンポーネントに与える影響を認識することも重要です。 たとえば、Kubernetes API サーバーは、クラスター全体で使用される共有サービスです。 テナント固有のノード プールを指定してテナントのアプリケーション ワークロードを分離した場合でも、API サーバーではテナント全体で多数の要求からの競合が発生する可能性があります。
回避すべきアンチパターン
うるさい隣人のアンチパターン
テナントが共有するコンポーネントをデプロイすると、 ノイズの多い近隣の問題 が潜在的なリスクになります。 他のテナントのアクティビティがテナントのコンピューティング ワークロードに影響を与えるリスクを軽減するために、リソース ガバナンスと監視を含めます。
テナント間のデータ漏えい
コンピューティング レベルが適切に処理されない場合、コンピューティング レベルはテナント間のデータ漏洩の影響を受ける可能性があります。 このリスクは、通常、Azure でマルチテナント サービスを使用するときに考慮する必要があるものではありません。これは、Microsoft がプラットフォーム レイヤーで保護を提供するためです。 ただし、独自のマルチテナント アプリケーションを開発する場合は、ローカル ディスク キャッシュ、RAM、外部キャッシュなどの共有リソースに、別のテナントが誤って表示または変更できるデータが含まれている可能性があるかどうかを検討してください。
ビジー状態のフロントエンドのアンチパターン
Busy Front Endアンチパターンを回避するには、アーキテクチャの他のコンポーネントや層で処理できる作業をフロントエンド層に任せすぎないようにしましょう。 このアンチパターンは、マルチテナント ソリューションの共有フロントエンドを作成する場合に特に重要です。これは、ビジー状態のフロント エンドによってすべてのテナントのエクスペリエンスが低下するためです。
代わりに、キューまたはその他のメッセージング サービスを使用して非同期処理を使用することを検討してください。 この方法では、要件に基づいてさまざまなテナント にサービスの品質 制御を適用することもできます。 たとえば、すべてのテナントが共通のフロントエンド 層を共有している可能性がありますが、 より高いサービス レベルを支払う テナントには、キュー メッセージからの作業を処理するための専用リソースのセットが高くなる場合があります。
柔軟性のない/不十分なスケーリング
マルチテナント ソリューションは、多くの場合、バーストスケール パターンの対象となります。 共有コンポーネントは、バーストのスコープが高く、個別の使用パターンを持つテナントが多い場合に効果が大きくなるため、この問題の影響を受けやすくなります。
クラウドの弾力性とスケールを利用していることを確認します。 水平スケーリングと垂直スケーリングのどちらを使用するか、自動スケールを使用して負荷の急増を自動的に処理するかを検討します。 ソリューションをテストして、さまざまなレベルの負荷で動作する方法を理解します。 運用環境で予想される負荷量と予想される増加量を含めます。 ロード テストなどのフル マネージド サービスを使用して、負荷がかかってアプリケーションがどのように動作するかを学習できます。
キャッシュ不使用のアンチパターン
キャッシュなしアンチパターンは、アプリケーション層が要求間で再利用できる情報を繰り返し要求または再計算するため、ソリューションのパフォーマンスが低下する場合です。 テナント間または単一テナント内のユーザー間で共有できるデータがある場合は、バックエンド層またはデータベース層の負荷を軽減するためにキャッシュする価値があります。
不要なステートフル性
キャッシュなしアンチパターンの影響は、コンピューティング レベルに不要な状態を格納しないようにする必要もあるということです。 状態を維持する場所とその理由を明確にしてください。 ステートフル なフロントエンド層またはアプリケーション層により、スケーリング機能が低下する可能性があります。 ステートフル コンピューティング レベルでは通常、セッション アフィニティも必要です。これにより、ワーカーまたはノード間でトラフィックを効果的に負荷分散する機能が低下する可能性があります。
コンピューティング レベルで維持する状態ごとのトレードオフと、テナントのワークロード パターンの変化に応じてスケーリングまたは拡張する機能に影響を与えるかどうかを検討します。 Azure Cache for Redis などの外部キャッシュに状態を格納することもできます。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- ディクシット・アローラ |Azure 用 FastTrack のシニア カスタマー エンジニア
- John Downs | プリンシパル ソフトウェア エンジニア
その他の共同作成者:
- Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
コンピューティング サービスのサービス固有のガイダンスを確認します。