うるさい隣人のアンチパターン

Azure

マルチテナント システムでは、複数のテナント間でリソースが共有されます。 テナントは同じ共有リソースを使用するため、1 つのテナントのアクティビティが、別のテナントによるシステムの使用に悪影響を与える可能性があります。

コンテキストと問題

複数の顧客またはテナントが共有するサービス を 構築する場合は、 マルチテナント化されるようにサービスを構築できます。 マルチテナント システムの利点は、リソースをプールしてテナント間で共有できることです。 多くの場合、このリソース共有により、コストが削減され、効率が向上します。 ただし、システムで使用可能なリソースのうちの過度な量が 1 つのテナントで使用されると、システム全体のパフォーマンスが低下する可能性があります。 ノイズの多い近隣の問題は、別のテナントのアクティビティが原因で 1 つのテナントのパフォーマンスが低下したときに発生します。

2 つのテナントを持つマルチテナント システムの例を考えてみましょう。 テナント A の使用パターンとテナント B の使用パターンは一致します。 ピーク時には、テナント A がシステムのリソースをすべて使用するため、テナント B が行う要求はすべて失敗します。 つまり、リソースの合計需要がシステムの容量よりも高くなります。

この図には、テナント A とテナント B の 2 つのテナントがあります。2 つの線グラフは、各テナントのリソース使用量を表します。 テナント A は、システム リソースの完全なセットを使用します。その結果、テナント B のシステム エラーが発生します。

要求が最初に到着したテナントが優先される可能性があります。 その後、他のテナントでノイズの多い近隣の問題が発生する可能性があります。 または、両方のテナントのパフォーマンスが低下する可能性があります。

また、個々のテナントがシステムの容量のごく一部のみを消費する場合にも、ノイズの多い近隣の問題が発生します。 ただし、多くのテナントのリソース使用量を組み合わせると、全体的な使用量がピークになることがあります。

この図は、テナント A、テナント B、テナント C の 3 つのテナントのリソース使用量を表す 3 つの線グラフを示しています。これらのグラフは、時間の経過に伴うシステムの合計容量を示しています。 もう 1 つの線グラフは、3 つのテナントすべてのシステム容量とリソース使用量の合計を示しています。

このシナリオは、すべての使用パターンが似ている複数のテナントがある場合、またはシステムの集合的な負荷に対して十分な容量をプロビジョニングしていない場合に発生する可能性があります。

Solution

1 つのリソースを共有すると、本質的に、完全に回避できないノイズの多い近隣の問題のリスクが伴います。 ただし、クライアントとサービス プロバイダーの両方が、ノイズの多い近隣の問題の可能性を減らすか、その影響を軽減するために実行できるいくつかの手順があります。

クライアントが実行できる操作

• サービスに対する不要な要求の発生を減らすために、アプリケーションがサービスの調整を処理していることを確認します。 アプリケーションが一時的な障害応答を受信した要求を再試行するためのベスト プラクティスに従っていることを確認します。

• 予約容量を購入します (使用可能な場合)。 たとえば、Azure Cosmos DB を使用する場合は、 予約済みスループットを購入します。

• より強力な分離が保証されているサービス レベル (使用可能な場合) に移行します。 たとえば、Azure Service Bus を使用する場合は、 Premium レベルに移行します。 専用のインフラストラクチャとプライベート ネットワークで Azure Managed Redis を使用する場合は、ノイズの多い近隣の影響を排除するのに役立ちます。

• サービスのシングルテナント インスタンスに移行します。 たとえば、Azure ExpressRoute を使用する場合は、 パフォーマンスに影響を受けやすい環境用に個別の回線をプロビジョニングします。

サービス プロバイダーが実行できる操作

• システムのリソース使用量を監視してください。 全体的なリソースの使用状況と、各テナントが使用するリソースの両方を監視してください。 リソース使用量の急増を検出するようにアラートを構成します。 可能であれば、 スケールアップまたはスケールアウトによって既知の問題を自動的に軽減するように自動化を構成します。

• リソース ガバナンスを適用してください。 1 つのテナントがシステムを過負荷にするのを防ぎ、他のテナントが使用できる容量を減らすポリシーを適用することを検討してください。 この手順は、 調整パターン または レート制限パターンを通じてクォータの適用の形を取る場合があります。

• より多くのインフラストラクチャをプロビジョニングしてください。 このプロセスには、一部のソリューション コンポーネントのアップグレードによるスケールアップが含まれる場合があります。 また、 シャーディング パターンに従う場合は追加のシャードをプロビジョニングしてスケールアウトしたり、 デプロイ スタンプ パターンに従う場合はスタンプをプロビジョニングしたりすることも含まれます。

• テナントで事前にプロビジョニングされた容量または予約容量を購入できるようにしてください。 このアプローチにより、テナントは、ソリューションがワークロードを確実に処理できる自信が高まります。

• テナント リソースの使用量のバランスを取る。 たとえば、次のいずれかの方法を試すことができます。

  • ソリューションの複数のインスタンスをホスティングする場合は、インスタンスまたはスタンプ間でテナントを再分散することを検討します。 たとえば、予測可能で補完的な使用パターンを持つテナントを複数のスタンプに配置して、使用量のピークをフラット化することを検討します。

  • 時間に依存しないバックグラウンド プロセスやリソースを集中的に使用するワークロードがないかどうかを検討します。 これらのワークロードをピーク時以外に非同期的に実行して、時間に依存するワークロードのリソース容量を維持します。

• ダウンストリーム サービスで、うるさい隣人の問題を軽減するためのコントロールを提供するかどうかを確認します。 たとえば、Kubernetes を使用する場合は、 ポッドの制限の使用を検討してください。 Azure Service Fabric を使用する場合は、 組み込みのガバナンス機能の使用を検討してください。

• テナントが行うことができる操作を制限してください。 たとえば、返される最大レコード数またはクエリ時間制限を設定して、テナントがリソースを集中的に使用するデータベース クエリを実行できないように制限します。 または、これらの操作を非同期に変更し、ピーク時以外に実行するようにスケジュールします。 このアクションにより、テナントが他のテナントに悪影響を与える可能性のあるアクションを実行するリスクが軽減されます。

• サービス品質 (QoS) システムを提供します。 QoS を適用する場合は、一部のプロセスまたはワークロードを他のプロセスまたはワークロードよりも優先します。 QoS を設計とアーキテクチャに組み込むことで、リソースに負荷がかかっているときに優先度の高い操作が優先されるようにすることができます。

Considerations

ほとんどの場合、個々のテナントは、ノイズの多い近隣の問題を引き起こすことはありません。 個々のテナントは、ワークロードが他のテナントに対してノイズの多い近隣の問題を引き起こすことを認識していない可能性があります。 ただし、一部のテナントでは、共有コンポーネントの脆弱性を悪用して、個別に、または分散型サービス拒否攻撃を実行してサービスを攻撃する可能性があります。

原因に関係なく、これらの問題をリソース ガバナンスの問題として扱い、使用クォータ、調整、およびガバナンス制御を適用して問題を軽減することが重要です。

Note

適用する調整メカニズムや使用クォータに関するクライアントを透過的にします。 失敗した要求を適切に処理し、制限によって油断されないようにすることが重要です。

問題の検出方法

クライアントの観点から見ると、ノイズの多い近隣の問題は、通常、サービスへの要求の失敗または完了に時間がかかる要求として現れます。 具体的には、同じ要求が他の時点で成功し、ランダムに失敗したと思われる場合は、ノイズの多い近隣の問題が発生する可能性があります。 クライアント アプリケーションは、サービスへの要求の成功率とパフォーマンスを追跡するためにテレメトリを記録する必要があります。 アプリケーションでは、比較のためにベースライン パフォーマンス メトリックも記録する必要があります。

Azure ベースのサービスの場合は、 Azure サブスクリプションとサービスの制限、クォータ、制約 を確認して、ソリューション内の各 Azure コンポーネントに適用される制限とクォータを理解します。

サービスの観点からは、ノイズの多い近隣の問題は次のように表示される可能性があります。

• リソース使用量の急増: 通常のベースライン リソースの使用状況を明確に理解し、スパイクを検出するように監視とアラートを構成することが重要です。 サービスのパフォーマンスまたは可用性に影響を与える可能性があるすべてのリソースを検討してください。 これらのリソースには、サーバーの CPU とメモリの使用量、ディスクの入力と出力、データベースの使用状況、ネットワーク トラフィックなどのメトリックが含まれます。 また、Azure Cosmos DB 要求ユニットなどの要求ボリュームや合成または抽象パフォーマンス インジケーターなど、マネージド サービスによって公開されるメトリックも監視する必要があります。

• テナントの操作を実行するときのエラー: テナントがシステムのリソースの大きな共有を消費していない場合に発生するエラーを探します。 このパターンは、テナントでノイズの多い近隣の問題が発生していることを示している可能性があります。 テナントごとのリソース使用量を追跡します。 たとえば、Azure Cosmos DB を使用する場合は、各要求の要求ユニットをログに記録し、各テナントの要求ユニットの使用状況を集計できるように、テレメトリにテナントの識別子を含めます。

Contributors

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要著者:

• ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス

その他の共同作成者:

• チャド・キットテル |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
• パオロ・サルヴァトリ |プリンシパル カスタマー エンジニア、FastTrack for Azure
• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト
• Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

関連リソース

• マルチテナント ソリューションのアーキテクチャに関する考慮事項
• 一時的な障害の処理のベスト プラクティス

マルチテナント システムでは、複数のテナント間でリソースが共有されます。 テナントは同じ共有リソースを使用するため、1 つのテナントのアクティビティが、別のテナントによるシステムの使用に悪影響を与える可能性があります。

コンテキストと問題

複数の顧客またはテナントが共有するサービス を 構築する場合は、 マルチテナント化されるようにサービスを構築できます。 マルチテナント システムの利点は、リソースをプールしてテナント間で共有できることです。 多くの場合、このリソース共有により、コストが削減され、効率が向上します。 ただし、システムで使用可能なリソースのうちの過度な量が 1 つのテナントで使用されると、システム全体のパフォーマンスが低下する可能性があります。 ノイズの多い近隣の問題は、別のテナントのアクティビティが原因で 1 つのテナントのパフォーマンスが低下したときに発生します。

2 つのテナントを持つマルチテナント システムの例を考えてみましょう。 テナント A の使用パターンとテナント B の使用パターンは一致します。 ピーク時には、テナント A がシステムのリソースをすべて使用するため、テナント B が行う要求はすべて失敗します。 つまり、リソースの合計需要がシステムの容量よりも高くなります。

この図には、テナント A とテナント B の 2 つのテナントがあります。2 つの線グラフは、各テナントのリソース使用量を表します。 テナント A は、システム リソースの完全なセットを使用します。その結果、テナント B のシステム エラーが発生します。

要求が最初に到着したテナントが優先される可能性があります。 その後、他のテナントでノイズの多い近隣の問題が発生する可能性があります。 または、両方のテナントのパフォーマンスが低下する可能性があります。

また、個々のテナントがシステムの容量のごく一部のみを消費する場合にも、ノイズの多い近隣の問題が発生します。 ただし、多くのテナントのリソース使用量を組み合わせると、全体的な使用量がピークになることがあります。

この図は、テナント A、テナント B、テナント C の 3 つのテナントのリソース使用量を表す 3 つの線グラフを示しています。これらのグラフは、時間の経過に伴うシステムの合計容量を示しています。 もう 1 つの線グラフは、3 つのテナントすべてのシステム容量とリソース使用量の合計を示しています。

このシナリオは、すべての使用パターンが似ている複数のテナントがある場合、またはシステムの集合的な負荷に対して十分な容量をプロビジョニングしていない場合に発生する可能性があります。

Solution

1 つのリソースを共有すると、本質的に、完全に回避できないノイズの多い近隣の問題のリスクが伴います。 ただし、クライアントとサービス プロバイダーの両方が、ノイズの多い近隣の問題の可能性を減らすか、その影響を軽減するために実行できるいくつかの手順があります。

クライアントが実行できる操作

• サービスに対する不要な要求の発生を減らすために、アプリケーションがサービスの調整を処理していることを確認します。 アプリケーションが一時的な障害応答を受信した要求を再試行するためのベスト プラクティスに従っていることを確認します。

• 予約容量を購入します (使用可能な場合)。 たとえば、Azure Cosmos DB を使用する場合は、 予約済みスループットを購入します。

• より強力な分離が保証されているサービス レベル (使用可能な場合) に移行します。 たとえば、Azure Service Bus を使用する場合は、 Premium レベルに移行します。 専用のインフラストラクチャとプライベート ネットワークで Azure Managed Redis を使用する場合は、ノイズの多い近隣の影響を排除するのに役立ちます。

• サービスのシングルテナント インスタンスに移行します。 たとえば、Azure ExpressRoute を使用する場合は、 パフォーマンスに影響を受けやすい環境用に個別の回線をプロビジョニングします。

サービス プロバイダーが実行できる操作

• システムのリソース使用量を監視してください。 全体的なリソースの使用状況と、各テナントが使用するリソースの両方を監視してください。 リソース使用量の急増を検出するようにアラートを構成します。 可能であれば、 スケールアップまたはスケールアウトによって既知の問題を自動的に軽減するように自動化を構成します。

• リソース ガバナンスを適用してください。 1 つのテナントがシステムを過負荷にするのを防ぎ、他のテナントが使用できる容量を減らすポリシーを適用することを検討してください。 この手順は、 調整パターン または レート制限パターンを通じてクォータの適用の形を取る場合があります。

• より多くのインフラストラクチャをプロビジョニングしてください。 このプロセスには、一部のソリューション コンポーネントのアップグレードによるスケールアップが含まれる場合があります。 また、 シャーディング パターンに従う場合は追加のシャードをプロビジョニングしてスケールアウトしたり、 デプロイ スタンプ パターンに従う場合はスタンプをプロビジョニングしたりすることも含まれます。

• テナントで事前にプロビジョニングされた容量または予約容量を購入できるようにしてください。 このアプローチにより、テナントは、ソリューションがワークロードを確実に処理できる自信が高まります。

• テナント リソースの使用量のバランスを取る。 たとえば、次のいずれかの方法を試すことができます。

  • ソリューションの複数のインスタンスをホスティングする場合は、インスタンスまたはスタンプ間でテナントを再分散することを検討します。 たとえば、予測可能で補完的な使用パターンを持つテナントを複数のスタンプに配置して、使用量のピークをフラット化することを検討します。

  • 時間に依存しないバックグラウンド プロセスやリソースを集中的に使用するワークロードがないかどうかを検討します。 これらのワークロードをピーク時以外に非同期的に実行して、時間に依存するワークロードのリソース容量を維持します。

• ダウンストリーム サービスで、うるさい隣人の問題を軽減するためのコントロールを提供するかどうかを確認します。 たとえば、Kubernetes を使用する場合は、 ポッドの制限の使用を検討してください。 Azure Service Fabric を使用する場合は、 組み込みのガバナンス機能の使用を検討してください。

• テナントが行うことができる操作を制限してください。 たとえば、返される最大レコード数またはクエリ時間制限を設定して、テナントがリソースを集中的に使用するデータベース クエリを実行できないように制限します。 または、これらの操作を非同期に変更し、ピーク時以外に実行するようにスケジュールします。 このアクションにより、テナントが他のテナントに悪影響を与える可能性のあるアクションを実行するリスクが軽減されます。

• サービス品質 (QoS) システムを提供します。 QoS を適用する場合は、一部のプロセスまたはワークロードを他のプロセスまたはワークロードよりも優先します。 QoS を設計とアーキテクチャに組み込むことで、リソースに負荷がかかっているときに優先度の高い操作が優先されるようにすることができます。

Considerations

ほとんどの場合、個々のテナントは、ノイズの多い近隣の問題を引き起こすことはありません。 個々のテナントは、ワークロードが他のテナントに対してノイズの多い近隣の問題を引き起こすことを認識していない可能性があります。 ただし、一部のテナントでは、共有コンポーネントの脆弱性を悪用して、個別に、または分散型サービス拒否攻撃を実行してサービスを攻撃する可能性があります。

原因に関係なく、これらの問題をリソース ガバナンスの問題として扱い、使用クォータ、調整、およびガバナンス制御を適用して問題を軽減することが重要です。

Note

適用する調整メカニズムや使用クォータに関するクライアントを透過的にします。 失敗した要求を適切に処理し、制限によって油断されないようにすることが重要です。

問題の検出方法

クライアントの観点から見ると、ノイズの多い近隣の問題は、通常、サービスへの要求の失敗または完了に時間がかかる要求として現れます。 具体的には、同じ要求が他の時点で成功し、ランダムに失敗したと思われる場合は、ノイズの多い近隣の問題が発生する可能性があります。 クライアント アプリケーションは、サービスへの要求の成功率とパフォーマンスを追跡するためにテレメトリを記録する必要があります。 アプリケーションでは、比較のためにベースライン パフォーマンス メトリックも記録する必要があります。

Azure ベースのサービスの場合は、 Azure サブスクリプションとサービスの制限、クォータ、制約 を確認して、ソリューション内の各 Azure コンポーネントに適用される制限とクォータを理解します。

サービスの観点からは、ノイズの多い近隣の問題は次のように表示される可能性があります。

• リソース使用量の急増: 通常のベースライン リソースの使用状況を明確に理解し、スパイクを検出するように監視とアラートを構成することが重要です。 サービスのパフォーマンスまたは可用性に影響を与える可能性があるすべてのリソースを検討してください。 これらのリソースには、サーバーの CPU とメモリの使用量、ディスクの入力と出力、データベースの使用状況、ネットワーク トラフィックなどのメトリックが含まれます。 また、Azure Cosmos DB 要求ユニットなどの要求ボリュームや合成または抽象パフォーマンス インジケーターなど、マネージド サービスによって公開されるメトリックも監視する必要があります。

• テナントの操作を実行するときのエラー: テナントがシステムのリソースの大きな共有を消費していない場合に発生するエラーを探します。 このパターンは、テナントでノイズの多い近隣の問題が発生していることを示している可能性があります。 テナントごとのリソース使用量を追跡します。 たとえば、Azure Cosmos DB を使用する場合は、各要求の要求ユニットをログに記録し、各テナントの要求ユニットの使用状況を集計できるように、テレメトリにテナントの識別子を含めます。

Contributors

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要著者:

• ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス

その他の共同作成者:

• チャド・キットテル |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
• パオロ・サルヴァトリ |プリンシパル カスタマー エンジニア、FastTrack for Azure
• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト
• Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

関連リソース

• マルチテナント ソリューションのアーキテクチャに関する考慮事項
• 一時的な障害の処理のベスト プラクティス