Azure Service Bus でのスロットル操作
クラウド ネイティブ ソリューションは、ワークロードに合わせて拡張できる無制限のリソースという概念を提供します。 クラウドでは、オンプレミスのシステムよりもこの概念に真実味がありますが、クラウドにはまだ制限があります。 この記事で説明するように、Standard レベルと Premium レベルの両方で、これらの制限によってクライアント アプリケーションの要求がスロットルされる場合があります。
Standard レベルでのスロットリング
Service Bus の Standard レベルは、従量課金制の価格モデルを使用したマルチテナント セットアップとして動作します。 ここでは、同じクラスター内の複数の名前空間が、割り当てられたリソースを共有します。 Standard レベルは、開発者環境、QA 環境、および低スループットの運用システムで推奨される選択肢です。
以前の Service Bus には、リソース使用率に厳密に依存する粗いスロットリング制限がありました。 ただし、スロットリング ロジックを改良し、これらのリソースを共有しているすべての名前空間に対して予測可能なスロットリング動作を提供する機会はあります。
同じリソースを使用するすべての Service Bus Standard 名前空間のあいだでリソースの公平な使用と配分を担保するために、Service Bus Standard は現在クレジットベースのスロットルロジックを使用しています。
Note
重要な注意点として、スロットルは、Azure Service Bus やクラウド ネイティブ サービスにとって目新しいものではありません。
クレジットベースのスロットリングは、単純に、マルチテナントの Standard レベル環境でさまざまな名前空間がリソースを共有する方法を改良し、リソースを共有するすべての名前空間による公平な使用を実現します。
クレジットベースのスロットルとは
クレジットベースのスロットルは、特定の期間中に特定の名前空間で実行できる操作の数を制限します。 クレジットベースのスロットリングのワークフローを次に示します。
- 各期間の開始時に、Service Bus によっていくつかのクレジットが名前空間ごとに提供されます。
- 送信側または受信側のクライアント アプリケーションによって実行される操作は、これらのクレジットに対してカウントされます (また、使用可能なクレジットから差し引かれます)。
- クレジットがなくなると、次の期間が始まるまで、後続の操作はスロットルされます。
- クレジットは、次の期間の開始時に補充されます。
クレジットの制限とは
クレジットの制限は現在、(名前空間ごとに) 毎秒 1000 クレジットに設定されています。 すべての操作が等しく作成されるわけではありません。 各操作のクレジット コストは次のようになります。
| 操作 | クレジット コスト |
|---|---|
データ操作 (Send、SendAsync、Receive、ReceiveAsync、Peek) |
メッセージあたり 1 クレジット |
管理操作 (キュー、トピック、サブスクリプション、フィルターに対する Create、Read、Update、Delete) |
10 クレジット |
Note
トピックに送信する場合は、各メッセージがサブスクリプションで使用可能になる前にフィルターに対して評価されることに注意してください。 各フィルター評価もクレジット制限に対してカウントされます (つまり、フィルター評価ごとに 1 クレジット)。
スロットルされていることを認識するのはどのような状況ですか?
クライアント アプリケーション要求がスロットルされると、クライアント アプリケーションは次のサーバー応答を受け取ります。
The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.
どのようにすればスロットルを回避できますか?
共有リソースを使用する場合、リソースを共有するさまざまな Service Bus 名前空間のあいだで公平な使用を何らかの形で強制することが重要です。 スロットリングにより、1 つのワークロードでスパイクが発生しても、同じリソース上の他のワークロードがスロットルされないようにします。 この記事で後述するように、クライアント ソフトウェア開発キット (SDK) および、その他の Azure PaaS オファリングには既定の再試行ポリシーが組み込まれているため、スロットルされることのリスクはありません。 スロットルされた要求はエクスポネンシャル バックオフによって再試行され、最終的にはクレジットが補充されれば完了します。
もちろん、アプリケーションによってはスロットルの影響を受けやすい場合があります。 その場合は、現在の Service Bus Standard 名前空間を Premium に移行することをお勧めします。 移行の際、専用リソースを Service Bus 名前空間に割り当てて、ワークロードでスパイクが発生する場合はリソースを適切にスケールアップし、スロットルの確率を下げることができます。 さらに、ワークロードが通常レベルに低下したら、名前空間に割り当てているリソースをスケールダウンできます。
Premium レベルでのスロットリング
Service Bus Premium レベルでは、お客様がセットアップした個々の名前空間に、メッセージング ユニットの単位で専用リソースが割り当てられます。 これらの専用リソースは予測可能なスループットと待機時間を提供し、スループットまたは機密性が高い実稼働グレードのシステムに推奨されます。 さらに、Premium レベルでは、ワークロードでスパイクが発生したときにお客様がスループット容量をスケールアップすることもできます。 詳細については、「Azure Service Bus 名前空間のメッセージング ユニットを自動的に更新する」を参照してください。
Service Bus Premium でのスロットルのしくみ
Premium レベルの排他的リソース割り当てでは、スロットリングは純粋に、名前空間に割り当てられるリソースの制限によって発動します。 現在のリソースが処理できる数よりも要求が多くなると、要求はスロットルされます。
スロットルされていることを認識するのはどのような状況ですか?
Service Bus Premium レベルでは、スロットリングを識別する複数の方法があります。
- [Throttled Requests](スロットルされた要求) が Azure Monitor の [要求] メトリックに出現し、スロットルされた要求の数を示します。
- [CPU 使用率] の高い値は、現在のリソース割り当てが高水準であり、現在のワークロードが低下しなければ要求がスロットルされる可能性があることを示します。
- [メモリ使用量] の高い値は、現在のリソース割り当てが高水準であり、現在のワークロードが低下しなければ要求がスロットルされる可能性があることを示します。
どのようにすればスロットルを回避できますか?
Service Bus Premium 名前空間には既に専用のリソースがあるため、ワークロードでスパイクが発生した (または、それが予想される) 場合、名前空間に割り当てるメッセージング ユニットの数をスケールアップすることで、スロットルの確率を下げることができます。 詳細については、「Azure Service Bus 名前空間のメッセージング ユニットを自動的に更新する」を参照してください。
FAQ
スロットルがアプリケーションに与える影響は?
要求がスロットルされた場合は、要求数がリソースの許容量を超えているためサービスがビジー状態であることを意味します。 しばらくしてから同じ操作を再試行した場合、サービスが現在のワークロードの処理を完了してからでないと、要求は受け付けられません。
スロットリングはどのクラウド ネイティブ サービスでも予想される動作であるため、Service Bus SDK 自体に再試行ロジックが組み込まれています。 既定では、同じ要求が毎回スロットルされないよう、エクスポネンシャル バックオフによって自動再試行するように設定されています。 既定の再試行ロジックは、すべての操作に適用されます。
Note
他のサード パーティのサービスを呼び出すメッセージ処理コードも、それらの他のサービスによって調整される可能性があります。 これらのシナリオを処理する方法について詳しくは、調整パターンに関するドキュメントをご覧ください。
スロットルによってデータが失われますか?
Azure Service Bus は永続化のために最適化されています。 Service Bus に送信されるすべてのデータは、サービスが要求の成功を確認する前にストレージにコミットされることが保証されています。
要求が Service Bus によって正常に確認されると、それは Service Bus によって要求が正常に処理されたことを意味します。 Service Bus によって失敗が返される場合、それは Service Bus で要求を処理できなかったため、クライアント アプリケーションで要求を再試行する必要があることを意味します。
ただし、要求がスロットルされている場合、サービスが意味しているのは、リソース制限のため今すぐに要求を受け入れて処理することはできない、ということです。 これは、Service Bus によって単に要求が確認されていないことによる何らかのデータ損失を意味するものではありません。 この場合、Service Bus SDK の既定の再試行ポリシーに従うことで、要求が最終的には処理されることが保証されます。
関連するコンテンツ
Service Bus のメッセージングの詳細と使用例については、次の詳細トピックをご覧ください。