レート制限でインスタンスの安定性を改善する

レート制限は外部 REST API リクエストのみを対象とします。つまり、Jira 内でのリクエストは制限されません。ユーザーによる、Jira ユーザー インターフェイス内での移動、プロジェクトの表示、課題のトランジション、および他のアクションの完了などの操作は、制限すべきでない通常のユーザー エクスペリエンスとみなされるため、レート制限の影響を受けません。

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

• Jira でユーザーが課題を表示すると、バックグラウンドで多数のリクエストが送信されます。これらのリクエストは Jira に対し、コメント、担当者、添付ファイルなどを要求します。このトラフィックは Jira 内部のものであるため、制限されません。

• 同じユーザーがラップトップでターミナルを開き、次のようなリクエストを送信して課題に関する情報を取得した場合、この処理は Jira 外で行われるためレート制限の対象になります。

  wget https://jira.com/rest/api/2/issue/JRASERVER-70350

認証メカニズム

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

• Basic Auth
• OAuth
• JSESSIONID cookie

アトラシアンでは、レート制限の実施に利用できる多数の技術の中から、トークン バケットを採用しました。 

トークン バケットを使用すると、リクエストに交換できるトークンの残数がユーザーに提示されます。仕組みの要約は次のとおりです。

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

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

  • 定数レートまたは間隔は、時間間隔 (秒単位) を許容要求数で割ったものです。

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

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

Jira は、Confluence、Bitbucket、Bamboo などの他のアトラシアン製品と組み合わせることで、最大のメリットを発揮できます。これらの製品は技術的には、Jira の外部であるため、制限対象になります。ただし、このユースケースにおいては、これらは同じユーザー エクスペリエンス内に所属するとみなされ、製品間でやり取りされるリクエストは制限の対象外にすることが望ましいと考えられます。

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

• サーバー製品: 制限されません。

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

Jira インスタンスにインストールされている Marketplace アプリが Jira 内から行う内部リクエストは、制限されるべきではありません。ただし、これはほかの挙動と同様に、アプリの仕組みに依存します。

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

• 外部: Jira の外部でリクエスト行うアプリは制限されます。テレビにウォールボードを表示するアプリがあるとします。このアプリは、ボード、課題、担当者などの詳細を Jira から取得し、それらを再度シャッフルし、前述のウォールボードとして独自の方法で表示します。このようなアプリは外部リクエストを送信し、ターミナルからリクエストを送信するユーザーのように動作します。

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

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

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

選択した制限 (例: 100 件のリクエスト/1 時間) にかかわらず、各ノードに同じ制限が適用され、個別に設定する必要はありません。つまり、各ユーザーで利用できるリクエストの送信機能は引き続き制限され、リクエストがどのノードに転送されるかにかかわらず、Jira は安定性を維持します。

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

適切な制限を見つける

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

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

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

一般に、個別のユーザーを制御するのではなく、インスタンスを安全に保つために、制限値を選択します。レート制限は、ユーザーが作業を完了できないようにするものではなく、連携やスクリプトが壊れるのを防ぐためのものです。

許可されるリクエスト: 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% を追加することをご検討ください。これにより、ユーザーの作業が中断されるのを防ぎながら、十分な容量を維持できます。

一般に、選択する制限は、個々のユーザーを制御するのではなく、インスタンスを安全に保つ必要があります。レート制限とは、ユーザーが作業を完了するのを妨げるよりも、Jira の統合やスクリプトがヘイワイアになるのを防ぐことです。

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

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

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

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

   com.atlassian.ratelimiting.internal.requesthandler.logging

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

5. レート制限されたすべてのリクエストが、Jira のログ ファイルに表示されるようになります。 

   [INFO] [talledLocalContainer] 2019-11-27 16:21:01,610 http-nio-2990-exec-6 DEBUG [internal.requesthandler.logging.RateLimitedRequestLogger] User [admin] has been rate limited for URL [http://localhost:2990/jira/rest/rate-limiting/latest/admin/rate-limit/settings]
   [INFO] [talledLocalContainer] 2019-11-27 16:24:29,014 http-nio-2990-exec-5 DEBUG [internal.requesthandler.logging.RateLimitedRequestLogger] User [admin] has been rate limited for URL [http://localhost:2990/jira/rest/rate-limiting/latest/admin/rate-limit/settings], pre-auth

たとえば、Marketplace アプリが新しい API を Jira に追加しました。アプリ自体は UI から使用されるため制限されるべきではありませんが、Jira がこのトラフィックを外部とみなし、レート制限を適用する可能性があります。その場合、アプリを無効化するかレート制限を増やすことができますが、これは複雑さを増すことになります。

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