負荷制限リファレンスガイド
|
この技術は、experimentalと考えられています。 experimental モードでは、アイデアを成熟させるために早期のフィードバックが求められます。ソリューションが成熟するまでの間、プラットフォームの安定性や長期的な存在を保証するものではありません。フィードバックは メーリングリスト や GitHubの課題管理 で受け付けています。 とりうるステータスの完全なリストについては、 FAQの項目 を参照してください。 |
負荷制限とは、サービスの過負荷を検出し、リクエストを拒否する処理のことです。
Quarkus では、quarkus-load-shedding エクステンションによって負荷制限メカニズムが提供されます。
1. 負荷制限エクステンションの使用
負荷制限エクステンションを使用するには、プロジェクトに io.quarkus:quarkus-load-shedding エクステンションを追加する必要があります。
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-load-shedding</artifactId>
</dependency>implementation("io.quarkus:quarkus-load-shedding")設定は必要ありませんが、可能な設定オプションについては以下で説明します。
2. 負荷制限アルゴリズム
負荷制限アルゴリズムには 2 つの部分があります。
-
過負荷検出
-
優先負荷制限 (オプション)
2.1. 過負荷検出
現在のサービスが過負荷かどうかを検出するために、TCP Vegas を応用しています。
アルゴリズムは、最初に 100 件の同時リクエストを許可します。 各リクエストについて、現在のリクエスト数を許可された制限と比較し、制限を超えた場合は過負荷状態が通知されます。
制限を超えていない場合、または優先負荷制限によりリクエストを拒否する必要がないと判断された場合 (以下を参照)、リクエストは許可されます。 完了すると、その処理時間がこれまでの最短時間と比較され、キューサイズの推定に使用されます。 キューサイズが alpha より小さい場合、現在の制限は増加しますが、指定された最大値 (デフォルトでは 1000) までしか増加されません。 キューサイズが beta を超える場合、現在の制限は減少します。 それ以外の場合、現在の制限は維持されます。
アルファとベータは、設定可能な定数を現在の制限の底が 10 の対数 (10 進対数) と掛け合わせることで計算されます。
probe ファクターを設定することで変更可能な、一定数のリクエスト後に、最も短い処理時間は最後に確認されたリクエストの処理時間にリセットされます。
2.2. 優先負荷制限
過負荷状況が通知されると、優先負荷制限が呼び出されます。
デフォルトでは、優先負荷制限が有効になっています。つまり、現在の CPU 負荷が十分に高い場合にのみ、リクエストが拒否されます。 リクエストを拒否するかどうかを判断するには、次の 2 つの属性が考慮されます。
-
リクエストの優先度
-
リクエストコホート
静的に定義された優先度が 5 つ、コホートが 128 あり、合計で 640 のリクエストグループになります。
優先度とコホートの両方がリクエストに割り当てられた後、リクエストグループ番号が計算されます: group = priority * num_cohorts + cohort。
次に、グループ番号は現在の CPU 負荷の単純な 3 次関数と比較されます。ここで、load は 0 から 1 の間の数値です: num_groups * (1 - load^3)。
グループ番号が大きい場合、リクエストは拒否されますが、それ以外の場合は過負荷の状況でも許可されます。
優先負荷制限が無効になっている場合、過負荷状況ではすべてのリクエストが拒否されます。
2.2.1. リクエストの優先度のカスタマイズ
優先度は io.quarkus.load.shedding.RequestPrioritizer によって割り当てられます。
io.quarkus.load.shedding.RequestPriority 列挙には、CRITICAL、IMPORTANT、NORMAL、BACKGROUND、DEGRADED の 5 つの静的に定義された優先度があります。
デフォルトでは、リクエスト prioritizer が適用されない場合、優先度は NORMAL であると見なされます。
デフォルトの prioritizer が 1 つあり、非アプリケーションエンドポイントへのリクエストには優先度 CRITICAL が割り当てられます。
@Priority は宣言されていません。
RequestPrioritizer インターフェイスのカスタム実装を定義することが可能です。
実装は CDI Bean である必要があり、そうでない場合は無視されます。
typesafe な解決の CDI ルールに従う必要があります。
つまり、異なる @Priority 値を持つ複数の実装が存在し、そのうちのいくつかが @Alternative である場合、最も高い優先度値を持つ代替実装のみが保持されます。
代替実装となる実装がない場合、すべての実装が保持され、@Priority の降順で並べ替えられます (最も高い優先度の値が最初になります)。
2.2.2. リクエストコホートのカスタマイズ
コホートは io.quarkus.load.shedding.RequestClassifier によって割り当てられます。
静的に定義されたコホートは 128 あり、最小番号は 1、最大番号は 128 です。
分類子はこの範囲内の番号を返す必要があります。返さない場合、番号が自動的に調整されます。
リモート IP アドレスと現在の時刻のハッシュに基づいてコホートを割り当てるデフォルトの分類子が 1 つあり、IP アドレスのコホートはおよそ 1 時間ごとに変更されます。
@Priority は宣言されていません。
RequestClassifier インターフェイスのカスタム実装を定義することが可能です。
実装は CDI Bean である必要があり、そうでない場合は無視されます。
typesafe な解決の CDI ルールに従う必要があります。
つまり、異なる @Priority 値を持つ複数の実装が存在し、そのうちのいくつかが @Alternative である場合、最も高い優先度値を持つ代替実装のみが保持されます。
代替実装となる実装がない場合、すべての実装が保持され、@Priority の降順で並べ替えられます (最も高い優先度の値が最初になります)。
3. 制限
負荷制限エクステンションは現在、HTTP リクエストにのみ適用され、リクエスト/レスポンスのネットワークインタラクションに大きく偏っています。 そのため、gRPC、WebSocket、その他の HTTP 経由のストリーミングはサポートされていません。 メッセージングなどの Quarkus アプリケーションへの他の「エントリーポイント」もサポートされていません。
さらに、負荷制限の実装は現時点ではかなり基本的なものであり、実稼働環境で十分にテストされていません。 改善が必要になる可能性があります。
4. 設定リファレンス
ビルド時に固定された設定プロパティー。その他の設定プロパティーはすべてランタイム時にオーバーライド可能です。
Configuration property |
タイプ |
デフォルト |
|---|---|---|
Whether load shedding should be enabled. Currently, this only applies to incoming HTTP requests. Environment variable: Show more |
ブーリアン |
|
The maximum number of concurrent requests allowed. Environment variable: Show more |
int |
|
The Environment variable: Show more |
int |
|
The Environment variable: Show more |
int |
|
The probe factor of the Vegas overload detection algorithm. Environment variable: Show more |
double |
|
The initial limit of concurrent requests allowed. Environment variable: Show more |
int |
|
Whether priority load shedding should be enabled. Environment variable: Show more |
ブーリアン |
|
