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

レート制限は外部 REST API リクエストのみを対象とします。つまり、Jira 内でのリクエストは制限されません。ユーザーによる Confluence 内の移動、コメントの追加、およびその他の操作の完了は、制限すべきでない通常のユーザー エクスペリエンスとみなされるため、レート制限の影響を受けません。

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

• Confluence でユーザーがスペースを訪問すると、バックグラウンドで多数のリクエストが送信されます。これらのリクエストは Confluence に対し、ページ、ブログ投稿などを要求します。このトラフィックは Confluence 内部のものであるため、制限されません。

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

  curl -u user:password http://localhost:8090/rest/api/space/SPACEKEY/content

認証メカニズム

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

• Basic Auth
• OAuth
• JSESSIONID cookie

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

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

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

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

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

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

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

• サーバー製品: 制限されません。
• クラウド製品: クラウド製品に送受信されるリクエストにレート制限が適用される、既知の問題があります。アトラシアンではクラウド製品に対するレート制限の無効化に取り組んでおり、近日中に提供を開始する予定です。現時点では、Confluence を Jira Cloud と連携する場合、通常よりもレート制限を高く設定する必要があります。

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

• 内部: アプリがユーザー エクスペリエンスの強化のために内部で動作している場合、それは制限されません。このようなアプリの例として、Confluence スペースに表示される特別なバナーなどがあります。このバナーは作成されたすべてのページを確認し、このスペースの勝者、つまり、先月もっとも多くのページを作成したユーザーを表示するとします。このようなトラフィックは内部のものになり、制限されません。
• 外部: Confluence の外部でリクエスト行うアプリは制限されます。テレビにウォールボードを表示するアプリがあるとします。このアプリは、ボード、課題、担当者などの詳細を Jira から取得し、それらを再度シャッフルし、前述のウォールボードとして独自の方法で表示します。このようなアプリは外部リクエストを送信し、ターミナルからリクエストを送信するユーザーのように動作します。

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

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

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

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

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

適切な制限を見つける

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

1. ユーザーの作業の中断は許可されますか? ユーザーによる連携機能がミッションクリティカルな場合、代わりにハードウェアをアップグレードすることをご検討ください。連携の重要性に応じて、制限も高く設定する必要があります。算出した数を 2 倍または 3 倍にすることをご検討ください。
2. インスタンスですでに、REST トラフィックの量による問題が発生していますか? その場合、インスタンスで問題が発生しなかった日の基本値に近い制限を選択します。顕著な問題が発生していないのであれば、基本値に 50% を追加することをご検討ください。これにより、ユーザーの作業が中断されるのを防ぎながら、十分な容量を維持できます。

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

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

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

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

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