自動化サービスの制限
Jira Automation には、自動化ルールを抑制するための一連のサービス制限が用意されています。ルールがこれらの制限に違反すると、Jira インスタンスに影響を与えないように調整されて無効化されます。
ルールの制限違反を特定する
ルールの制限違反は、監査ログ内の次のエラーによって見分けられます。
- 調整済み: 監査アイテムのステータスは THROTTLED です。
- 詳細な説明: 監査アイテムには次のような詳細な説明が含まれています。
この自動化ルールは前日の合計処理時間の上限を超えた。1 日の最大処理時間 (秒):
Automation for Jira が過去 1 時間のルール実行数の上限を超えた。
この自動化ルールの JQL 検索が 1 回の検索で取得できる最大課題数を超えた。最初の課題から次の上限数までしか処理されていない:
REST によって制限を表示して設定する
REST によって現在の制限を表示して変更できます。
制限を表示する
制限を確認するには、次の REST 呼び出しを使用します。
https://YOUR_JIRA_INSTANCE_URL/rest/cb-automation/latest/configuration/property応答の例を次に示します。
{
"max.processing.time.per.day": "3600",
"rule.rate.per.five.second": "2",
"short.scheduled.interval.issue.limit": "1000",
"max.rules.per.hour": "5000",
"max.issues.per.search": "1000",
"max.queued.items.per.rule": "25000"
}制限を設定する
制限の 1 つを設定するには、次の REST 呼び出しを使用します (Content-Type が application/json に設定されている必要があります)。次の表に、各制限のプロパティを示します。
PUT https://<your Jira instance url>/rest/cb-automation/latest/configuration/property
{
"key": "max.processing.time.per.day",
"value": "10000"
}curl コマンドの例
curl -X PUT -H 'Content-type: application/json' \
-d '{"key": "max.rules.per.hour", "value": "10000"}' \
https://your-instance.com/rest/cb-automation/latest/configuration/propertyサービス制限とそのプロパティ キー
サービス制限の制御には次のプロパティを使用します。
| 制限名 | プロパティ キー | 既定値 | 説明 |
|---|---|---|---|
| JQL で検索される課題 | max.issues.per.search | 1000 | 検索を実行するコンポーネント (JQL や受信 Webhook トリガーなど) から返される課題の最大数。 |
| 1 日の処理時間 | max.processing.time.per.day | 3600 | 直近 12 時間で 1 つのルールの処理に費やせる最大秒数。 制限に違反した場合、ルールの実行に時間がかかりすぎている (操作に時間がかかる可能性がある)、実行頻度が高すぎる、またはその両方の組み合わせのいずれかです。 |
| 5 秒周期のルール レート | rule.rate.per.five.second | 2 | これら 2 つのパラメーターは、短期間でルール実行回数が急増した際にルールの調整が必要かどうかを判断するために考慮されます。 この仕組みの詳細は「サービス制限がルールに与える影響」をご参照ください。 |
| 1 時間あたりの最大ルール実行回数 | max.rules.per.hour | 5000 | |
| ルール別キュー アイテム数 | max.queued.items.per.rule | 25000 | 1 つのルールで同時にキューに入れられるアイテムの数を示します。 キューに入れられるアイテムの詳細については、キューに入れられるアイテムに関する後述の説明をご参照ください。 |
| キュー アイテム総数 | max.queued.items | 100000 | すべてのルールで同時にキューに入れられるアイテムの数を示します。 キューに入れられるアイテムの詳細については、キューに入れられるアイテムに関する後述の説明をご参照ください。 |
| ループ実行の上限 | max.rule.execution.loop.depth | 10 | ループの検出方法を制御します。1 つ以上のルールによって、そのルールまたは他のルールがトリガーされて、この上限数まで実行チェーンを作成します。 ルールがそのルール自体を即座にトリガーする場合は、実行が 10 回行われたあと、実行が停止されて、監査ログで LOOP としてマークされます。 |
| スケジュールによる JQL 課題制限 | short.scheduled.interval | 1000 | この制限によって、スケジュールされたトリガーにより大規模な課題検索を実行できる間隔を短縮します。クエリがこの制限を超える課題を返す場合、UI には警告が表示されて 24 時間に多くても 4 回のスケジュールのみが許可されます。これはソフト制限で、ルールの設定時にのみ適用されます。 |
| ブランチ即時優先アイテム制限 | branch.rule.immediate | 10 | 即時に実行できるブランチ実行の最大数。 ルールでより多くのブランチ実行が必要な場合、それらは自動化キューに格納されます。このような状況は、JQL クエリを使用するブランチ コンポーネントからこの値よりも多くの課題が返される場合などに発生する可能性があります。 |
| 送信 Webhook タイムアウト | outgoing.webhook.timeout.ms | 30000 | 送信 Webhook の HTTP リクエスト タイムアウト (ミリ秒)。 |
| ユーザー条件ユーザー制限 | user.condition.get.users.limit | 50 | ユーザー条件で 1 つのロールから取得できるユーザーの最大数。 |
| スレッド プール サイズ | automation.processing.thread.pool.size.per.node | 6 | キュー内のルールを処理するために使用されるスレッドの数。 初期設定では、サーバーごと (または Data Center のノードごと) に 6 個のスレッドです (ほとんどの場合これで十分です)。ルールの実行速度が遅い場合は、スレッド数を 8 個に増やしてみてください。 副次的な影響として、この値によってキュー内の要素のうち、キュー要求者が 1 つのリクエストで扱える要素の数も決まります。
|
| ノードごとのイベント シリアライザー スレッド ポーリング | automation.event.serializer.pool.size.per.node | 2 | Jira イベントを自動化イベントに変換するために使用されるスレッドの数。このような変換にはコストがかかる可能性があるため、この制限によってボトルネックが解消されます。 この値は、既定値の 2 より小さくしたり、利用可能なコアの数より大きくしたりできません。 |
| 正規表現タイムアウト | regex.timeout | 30000 | 正規表現の評価タイムアウト (ミリ秒)。 この制限は、最適化が不十分で長時間ループする可能性のある正規表現から保護するためのものです。 |
この値を増やすと逆効果となり、データベースまたはサーバーが増加した負荷を処理できない場合にパフォーマンスが低下する可能性があります。インフラに処理能力が確実にある場合にのみ、この値を増やしてください。サービス制限がルールに与える影響
下の図は、ルールを実行するか調整するかを決定するために使用されるアルゴリズムを示しています。プロセス全体に一連のサービス制限が含まれており、違反したサービス制限が多すぎるとルールが調整されます。
キューに入れられるアイテムに対するサービス制限
サービス制限の 1 つに、キュー内のアイテム数を制御するものがあります。このセクションでは、この制限が重要である理由、そして単純なルールによって大量のアイテムを非常に簡単にキューに追加する方法について説明します。
Jira Automation では、ルール処理キューによって自動化ルールの実行を管理します。
Jira では、ブラウザーでユーザーからのリクエストを処理、また自動化ルールなどのバックグラウンド サービスを実行するための処理能力に限界があります。Jira が過負荷にならないようにするため、ルール実行はキューに入れられて、同時に処理されるアイテムの数が制限されます。初期設定では、サーバーごと (または Data Center のノードごと) に 6 個のスレッドが同時に使用されます。
自動化ルール ビルダーによって、ほぼすべての処理に対応したルールを設定できます。その結果、それらのルールの実行に非常にコストがかかる可能性があります。
例として次の課題を扱うシナリオについて考えましょう。
- ABC-120 - 課題タイプが「タスク」の親開発課題
- ABC-121 - サブタスク 1
- ABC-122 - サブタスク 2
- ABC-123 - サブタスク 3
- ABC-124 - サブタスク 4
- ABC-125 - サブタスク 5
- ABC-130 - 課題タイプが「タスク」の別の親開発課題
- ABC-131 - サブタスク 1
- ABC-132 - サブタスク 2
- ABC-133 - サブタスク 3
- ABC-134 - サブタスク 4
- ABC-134 - サブタスク 5
ここで、次のルールを考えてみましょう。
この単純なルールでは、13 個の個別アイテムが自動化キューに入れられます。では、順番に解説していきましょう。
- 1 アイテムがキューに入っている目的は、検索を実行するために最初にスケジュールされたトリガーの実行です。
- 2 アイテムがキューに入っている目的は、親課題 ABC-120 & ABC-130 のマッチングです。
- 次に、それらの各アイテムについて、関連する課題のブランチがそれぞれ 5 アイテムをキューに入れています。
たとえば、最初にスケジュールされたトリガーが多数の課題にマッチする、または関連する課題ブランチが多数の課題にマッチする場合、こうしたタイプのルールではキュー アイテムがすぐに増える可能性があることが分かります (また、関連する課題ブランチは JQL 別に課題を検索できます)。
制限に違反するルールを無効にする
ルールの実行終了時にキューに過剰な数のアイテムが追加されると、そのルールは監査ログに記録されてそれ以上は実行されないように無効になります。
キューが急増する原因となるルールはどのようなものですか?
多数の関連課題ブランチを伴い、これらの各課題ブランチが多数の課題とマッチしているルールの例を次に示します。
- 100 件の課題にマッチするスケジュールされたトリガー
- 50 件の課題にマッチする関連課題ブランチ
- 80 件の課題にマッチする別の関連課題ブランチ
この結果は (約) 13,000 アイテム (100 * 50 + 100 * 80) です。
(if 条件をシミュレートするための) 多数の関連課題ブランチ含むルール
- トリガー: 課題の更新
- 関連課題ブランチの JQL タイプがバグであり、課題 1000 件にマッチする
- 関連課題ブランチの JQL タイプがタスクであり、課題 500 件にマッチする
- 関連課題ブランチの JQL タイプがフィーチャーであり、課題 2000 件にマッチする
この結果は、ブランチの数に応じて 3,500 アイテム以上になります (1000 + 500 + 2000)。
限度内に収まるようにルールを改善する
ルールが許容限度内に収まるようにするには、次のようないくつかのステップを実行します。
間隔を短くする
スケジュールされたルールの実行間隔を短くします。たとえば、ルールの実行を 5 分間隔ではなく 1 時間に 1 回だけにします。
JQL クエリを制限する
実行対象を最小限の課題セットに抑えた JQL クエリを使用します。そのための方法は、次のとおりいくつかあります。
- JQL 検索の内容をできるだけ具体的にします。たとえば、現在「進行中」の課題にのみ関心がある場合は、単純に
type = Taskに一致する課題を検索しないでください。type = Task and status = "In Progress"と検索することをお勧めします。 Only include issues that have changed since the last time this rule executedチェックボックスをチェックにして、ルールを最後に実行してから変更された課題のみを含めます。ルールの多くは、この小さいサブセットで運用するだけでも問題ありません。
条件チェックのブランチを避ける
関連課題ブランチを「条件付きの確認」用に作成しないでください。そのため上記のルールは多くの関連課題ブランチで type = Bug、type = Task などを確認することで、次のように効率的に書けます。
- トリガー: 課題の更新
- 目的の課題とマッチする特定 JQL の関連課題ブランチ (何らかの形でトリガー課題に関連する)
- このブランチで、if/else ブロックによってマッチを課題タイプに基づいて探す
一般的に、トリガーまたは関連課題ブランチによって、1 つのルールで取得する課題の総数を減らすことを目的としています。
ルールの最適化方法に関する詳細は「自動化ルールを最適化する」をご参照ください。