Rate limiting targets only external REST API requests, which means that requests made within Bamboo aren’t limited in any way. When users move around the Bamboo user interface, viewing projects, transitioning issues, and completing other actions, they won’t be affected by rate limiting, as we’re seeing this as a regular user experience that shouldn’t be limited.

次の例で詳しく説明します。

• When a user views an issue in Bamboo, a number of requests are sent in the background — these requests ask Bambo for comments, assignees, attachments, etc. Since this traffic is internal to Bamboo, it won’t be limited.

• When the same user opens up the terminal on their laptop and sends a request to get information about an issue, it will be rate limited because it’s made outside of Bamboo.

認証メカニズム

制限対象のリクエストを製品で特定する方法の詳細として、製品では次の認証メカニズムを使用した外部 HTTP リクエストを対象にしています。

• Basic Auth
• OAuth
• JSESSIONID cookie

アトラシアンでは、レート制限に利用できる多数の技術の中から、リクエストに交換可能なトークンの残数をユーザーに示すトークン バケットを採用ました。トークン バケットの仕組みの概要は次のとおりです。

• ユーザーにはトークンが提供されます。これはリクエストに交換されます。1 つのトークンは 1 件のリクエストに相当します。

• ユーザーは一定のタイミングで新しいトークンを取得するため、常に新しいリクエストを作成できます。これが許可されたリクエスト数であり、10 個/1 分のように設定されます。

• トークンは、個人用のバケットが満杯になるまで追加されます。これが最大リクエスト数であり、トークンの使用を独自の頻度に調整できます。たとえば、通常のレートとして指定した 10 件/1 分ではなく、20 件/2 分とすることができます。

• ユーザーが、自身が保有しているトークン数を超えるリクエストを送信しようとした場合、バケットからトークンを取得できたリクエストのみが成功します。残りのリクエストには 429 エラー メッセージ (too many requests) が返されます。ユーザーは新しいトークンの取得後にこれらのリクエストを再試行できます。

Bamboo works best when used with our other products like Bitbucket, or Jira. Technically, products like these are external to Bamboo, so they should be limited. In this case, however, we’re treating them as belonging to the same user experience and don’t want to enforce any limits for requests coming from or to these products.

現在の状況は次のとおりです。

• Data Center: Not limited in any way.

• クラウド製品: クラウド製品に送受信されるリクエストにレート制限が適用される、既知の問題があります。アトラシアンではクラウド製品に対するレート制限の無効化に取り組んでおり、近日中に提供を開始する予定です。現時点では回避策を使用できます。詳しくは、「アトラシアン クラウド製品に対するレート制限の削除」を参照してください。

The general assumption is that Marketplace apps are installed on a Bamboo instance, make internal requests from within Bamboo, and shouldn’t be limited. But, as always, it depends on how an app works.

• 内部: アプリがユーザー エクスペリエンスの強化のために内部で動作している場合、それは制限されません。このようなアプリの例として、スクラム ボードに表示される特別なバナーなどがあります。このバナーは完了したすべての課題を確認し、このスプリントの勝者、つまり、このスプリントでもっとも多くの課題を完了したユーザーを表示するとします。このようなトラフィックは内部のものになり、制限されません。

• External: Apps whose requests are external to Bamboo are limited. Let’s say we have an app that displays a wallboard on TV. It asks Bamboo for details about boards, issues, assignees, etc. and then reshuffles and displays them in its own way as the earlier mentioned wallboard. An app like that sends external requests and behaves just like a user sending requests over a terminal.

アプリによって異なりますが、ほとんどのものが制限対象外であると想定しています。

レート制限は Data Center で利用可能なため、ノードのクラスタがロード バランサの背後にある可能性が高くなります。各ユーザーには、各ノードに個別の制限があります (レート制限はクラスタではなくノードごとに適用されます)。

つまり、1 つのノードで許可されたリクエスト数を使用してレート制限されている場合、別のノードで新しいセッションを開始すると、論理的にはもう一度リクエストを送信できます。ユーザーがノードを切り替えることはできませんが、これが発生する可能性があることを念頭に置いてください。

Whatever limit you’ve chosen (e.g. 100 requests every 1 hour), the same limit will apply to each node, you don’t have to set it separately. This means that each user’s ability to send requests will still be limited, and Bamboo will remain stable regardless of which node their requests are routed to.

適切な制限の設定は多くの要因に依存するため、単純な回答を提供することはできません。ここではいくつかの提案をご案内させていただきます。

適切な制限を見つける

最初に、インスタンスが受信するトラフィックのサイズを理解します。アクセス ログを解析し、1 日に最大数の REST リクエストを作成したユーザーを見つけます。UI トラフィックはレート制限されないため、この数字はレート制限として必要な値よりも大きくなります。次に、これを基本値とし、以下の質問に基づいてさらに変更します。

1. ユーザーの作業の中断は許可されますか? ユーザーによる連携機能がミッションクリティカルな場合、代わりにハードウェアをアップグレードすることをご検討ください。連携の重要性に応じて、制限も高く設定する必要があります。算出した数を 2 倍または 3 倍にすることをご検討ください。

2. インスタンスですでに、REST トラフィックの量による問題が発生していますか? その場合、インスタンスで問題が発生しなかった日の基本値に近い制限を選択します。顕著な問題が発生していないのであれば、基本値に 50% を追加することをご検討ください。これにより、ユーザーの作業が中断されるのを防ぎながら、十分な容量を維持できます。

In general, the limit you choose should keep your instance safe, not control individual users. Rate limiting is more about protecting Bamboo from integrations and scripts going haywire, rather than stoping users from getting their work done.

許可されるリクエスト: 10 件/時間 | 最大リクエスト数: 100

• ある開発者は 1 日を通じ、1 時間あたり 10 件のリクエストを定期的に送信します。1 回にまとめて 20 件のリクエストを送信しようとすると、そのうち 10 件のみが成功します。その後の 1 時間で新しいリクエストを作成できるようになったら、残りの 10 件を再試行できます。

• 別の開発者は過去 10 時間にリクエストを送信していません。そのため、許可されているリクエスト数は最大リクエスト数である 100 に到達するまで蓄積され続けます。これにより、一度に 100 件のリクエストを送信でき、それらすべてが成功するようになります。利用可能なすべてのリクエストを使い果たしたら、1 時間待機することで 10 件のリクエストのみが許可されます。

• 同じ開発者が 100 件のリクエストのうち 50 件のみを送信した場合、その開発者は直ちに追加で 50 件を送信するか、次の 1 時間で再度蓄積を開始することができます。

許可されるリクエスト: 1 件/秒 | 最大リクエスト数: 60

• 開発者は、1 秒あたり 1 件のリクエストまたは 毎分 60 件のリクエスト を送信するように任意の頻度を選択できます。

• 割り当てられた 60 件のリクエストを任意の頻度で使用できるので、それらすべてを一度に使用することも、非常に短い間隔で使用することもできます。このような場合、1 秒あたり 1 件のリクエストという通常のレートを超えることになります。

適切な制限の設定は多くの要因に依存するため、単純な回答を提供することはできません。ここではいくつかの提案をご案内させていただきます。

適切な制限を見つける

最初に、インスタンスが受信するトラフィックのサイズを理解します。アクセス ログを解析し、1 日に最大数の REST リクエストを作成したユーザーを見つけます。UI トラフィックはレート制限されないため、この数字はレート制限として必要な値よりも大きくなります。次に、これを基本値とし、以下の質問に基づいてさらに変更します。

1. ユーザーの作業の中断は許可されますか? ユーザーによる連携機能がミッションクリティカルな場合、代わりにハードウェアをアップグレードすることをご検討ください。連携の重要性に応じて、制限も高く設定する必要があります。算出した数を 2 倍または 3 倍にすることをご検討ください。

2. インスタンスですでに、REST トラフィックの量による問題が発生していますか? その場合、インスタンスで問題が発生しなかった日の基本値に近い制限を選択します。顕著な問題が発生していないのであれば、基本値に 50% を追加することをご検討ください。これにより、ユーザーの作業が中断されるのを防ぎながら、十分な容量を維持できます。

In general, the limit you choose should keep your instance safe, not control individual users. Rate limiting is more about protecting Bamboo from integrations and scripts going haywire, rather than stoping users from getting their work done.

制限付きのリクエストをログ ファイルに追加するには、次の手順を実行します。

1. [管理] > [システム] > [ロギングとプロファイリング] に移動します。

2. [別のパッケージ用にログ レベルを設定する] をクリックします。

3. パッケージ名を次のように設定します。 

   com.atlassian.ratelimiting.internal.requesthandler.logging

4. ロギング レベルを [DEBUG] に設定して [追加] をクリックします。

5. Every rate limited requests will now appear in the Bamboo log file.

For example, a Marketplace app added some new API to Bamboo. The app itself is used from the UI, so it shouldn’t be limited, but it might happen that Bamboo sees this traffic as external and applies the rate limit. In this case, you could disable the app or increase the rate limit, but this brings additional complications.

このような問題を回避するには、アプリによって追加されたリソース全体を許可リストに追加し、それらが制限なしで動作するようにできます。