クラウド
Data Center 10.1
バージョン

Jira Software のガードレール

Performance and scaling

このページの内容

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

このページの内容は、Jira 10.1 に適用されます。別のバージョンについての情報をお探しの場合は、右上隅のメニューからバージョンを選択してください。

背景

アトラシアンは、大手顧客のニーズをサポートすることを約束しています。これには、製品のパフォーマンスとスケーラビリティの継続的な改善が含まれます。インスタンス内のデータ量は、パフォーマンスと安定性の問題の要因になる可能性があります。インスタンスが大きくなるにつれて、時間の経過とともにパフォーマンスが低下するリスクも増えます。多くの場合、これは段階的な低下であり、チームに重大な影響を与えるポイントに到達するまで気づかれない可能性があります。

次の表では観察されたパフォーマンスと安定性への影響を説明して、リスクを軽減するために実行できるいくつかのアクションを提案しています。ガードレールは一部の大手顧客の実際の経験に基づいていますが、必ずしもすべての組織の経験を代表するものではありません。

パフォーマンスと安定性に関する重大な問題が発生するリスクを軽減する方法には、次のようなものがあります。

  • アプリの変更。たとえば、パフォーマンスを向上させるために新しいアプリ バージョンにアップグレード、またはユーザーの管理方法を変更します。

  • インフラストラクチャの変更。たとえば、メモリや CPU を増設、またはクラスターやミラーを実行します。

  • フットプリントを削減するためのデータ クリーンアップ アクティビティ。たとえば、アーカイブ、またはモノリス サイトを分割します。

これらはハード制限ではなく、一部の製品インスタンスは既にこれらのしきい値を超えている可能性があることにご注意ください。異なるデータ タイプ間の相互作用やサイトの負荷など、さまざまな要因によって次に示すような潜在的な影響が発生する可能性とその影響の程度が決まります。あらゆるタイプのリスクと同様に、リスクを特定して計画を立てることが不可欠です。そうすれば、これらのアクションに優先順位付けて将来のパフォーマンス問題の可能性を減らすのに役立ちます。

定義

製品ガードレールとはデータ タイプに関する推奨事項であり、潜在的なリスクを特定してインスタンス最適化ジャーニーの次のステップに関する意思決定をサポートするように設計されています。

Jira Software のガードレール

次のガードレールは、スケール リスクを特定して軽減し、インスタンスのクリーンアップに関する意思決定を下すのに役立ちます。

プロジェクト

CONTENTTYPE

アクティブ プロジェクトの数

ガードレール

7000 プロジェクト (未アーカイブ)

この数を調べる方法

古いプロジェクトを特定してクリーンアップする方法

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • プロジェクト数が多いと、権限の計算が複雑になって所要時間が長くなります。

  • 新しいプロジェクトの作成時にアプリがクラスターのアクティブ ノードごとに 20-50 秒間ハングして (10k のプロジェクトで観察)、プロジェクトが正常に作成された場合でも 60 秒後にタイムアウト エラーが表示されます。

  • インデックスの再作成に長い時間がかかります。

緩和オプション

コメント

CONTENTTYPE

課題ごとのコメントの数

ガードレール

課題ごとに 1000 コメント

この数を調べる方法

データベースで最もコメントが多い課題を調べる方法

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 課題ビューの読み込みが遅くなります。

  • メモリ不足エラーが発生して、アプリがクラッシュする可能性があります (極端な場合)。

  • インデックスの再作成に長い時間がかかります。

緩和オプション

  • セーフガードによって、メンバーが作成できる特定のアイテムの数にグローバル制限を設定してユーザー グループのアクティビティを抑制します。

  • REST または ScriptRunner によって古いコメントを削除します。

  • 自動化をチェックして、不要なコメントを追加していないことを確認します。頻度を減らすか、更新のバッチ処理をご検討ください。

  • レート制限を実装して、誤設定された統合により短時間に数千件ものコメントが追加されるのを防止します。レート制限についてご確認ください。

添付ファイル

CONTENTTYPE

課題ごとの添付ファイルの数

ガードレール

課題ごとに 3000 添付ファイル

1 添付ファイルあたり 10MB

この数を調べる方法

データベースで最も添付ファイルが多い課題を調べる方法

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 課題ビューの読み込みが遅くなります。

  • 共有ホーム ファイル システムに負荷がかかります (サムネイルの読み込み中など)。

  • 課題の操作 (表示、更新など) または後処理がトリガーとなって、課題とそのすべての課題プロパティ (課題のすべての添付ファイル プロパティを含む) がシリアライズされる可能性があります。

緩和オプション

CONTENTTYPE

課題リンクまたはサブ課題の数

ガードレール

1000 課題リンク

この数を調べる方法

データベースで最も課題リンクが多い課題を調べる方法

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 課題ビューの読み込みが遅くなります。

  • スレッドがスタックしてインスタンス全体に影響を与える可能性があります。

緩和オプション

  • 課題リンクが多い課題を特定して、すべての不要なリンクを削除します。

  • 不要になった課題をアーカイブします。課題のアーカイブ方法をご確認ください。

Text

CONTENTTYPE

フィールドにあるテキストの量

ガードレール

単一行フィールドで 255 文字

説明および複数行フィールドで 100k 文字

この数を調べる方法

詳細設定の構成

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • インデックス サイズが大きくなります。

  • 検索結果の取得が遅くなります。

緩和オプション

  • テキスト フィールドの文字数制限を設定します。詳細設定の方法をご確認ください。

カスタム フィールド

CONTENTTYPE

カスタム フィールドの合計数

ガードレール

1,200 カスタム フィールド

この数を調べる方法

カスタム フィールドの使用状況を分析する

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 全体的なパフォーマンスが低下します。

  • インデックスの再作成に長い時間がかかります。

緩和オプション

エピック

CONTENTTYPE

エピックの数

ガードレール

120,000 エピック

この数を調べる方法

JQL によってエピック数を特定する ( issuetype = Epic )

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • エピック リンク メニューの読み込みが遅くなります。

緩和オプション

スプリント

CONTENTTYPE

スプリントの合計数

ガードレール

60,000 スプリント

この数を調べる方法

データベースでスプリントの合計数を調べる方法

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • スプリントのキャッシュへの格納が遅延して、全体的なパフォーマンスが低下します。

  • closedSprints() JQL 関数が機能しません (65,000 スプリントまでに制限)。

緩和オプション

ワークフロー スキーム一括アクション

操作

新しいの課題タイプを既存のワークフロー スキームに関連付ける

ガードレール

一括アクションごとに 1000 課題

この数を調べる方法


リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 一括アクションが完了するまでに非常に長い時間 (数日) がかかる可能性があります。

  • URL を短くしないとワークフロー スキームの変更の進捗を確認できません。

緩和オプション

  • 元のワークフロー スキームをコピーして変更を加え、ワークフロー スキームをプロジェクトごとに関連付けます。

  • 何もしません。バックグラウンド プロセスが完了するまでに時間はかかりますが、リソースを大量に消費せずパフォーマンスの問題も引き起こしません。完了するまで Jira を再起動しないようにしてください。

履歴の変更

CONTENTTYPE

課題に関連付けられた変更アイテムまたは変更グループの数

ガードレール

20,000 変更アイテムまたは変更グループ

この数を調べる方法

課題の変更履歴を取得する

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • [履歴] タブを表示するとメモリ不足エラーが発生します。

  • 課題ビューとその他の課題アクションの読み込みが遅くなります。

  • インデックスの再作成に長い時間がかかります。

緩和オプション

  • 履歴は新しい課題にコピーされないため、データベース クエリによって多数の変更アイテムと変更グループを伴う課題を特定してから課題を複製します。

ユーザー

CONTENTTYPE

LDAP と Jira の間で同期されるユーザーの合計数

ガードレール

100,000 ユーザー

この数を調べる方法

ユーザーの総数を取得するには

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • ディレクトリ同期とユーザー認証の長期化

緩和オプション

  • インスタンスのほとんどのユーザー アカウントが Crowd Data Center または Microsoft Active Directory に保存されている場合は、インクリメンタル同期を有効にしてください。この方法では、前回の同期以降の変更のみがクエリされるため、完全同期の必要性が減ります。詳細については、「LDAP ディレクトリへの接続」を参照してください。
  • アクセスベースの同期などの機能を活用するには、外部ユーザー ディレクトリとして Crowd Data Center を使用することを検討してください。詳細については、「アクセス権に基づくユーザーの同期」を参照してください
  • LDAP フィルターを使用して、インスタンスで処理するユーザーとグループの数を減らします。詳細については、次の情報を参照してください。
    • LDAP ディレクトリへの接続
    • LDAP から JIRA アプリケーションに同期されるユーザー数の削減 
    • LDAP 検索フィルターの作成方法  
  • ユーザー管理の制限と推奨事項をよく理解してください。

グループ

CONTENTTYPELDAP と Jira の間で同期されるグループの合計数

ガードレール

25,000 グループ
この数を調べる方法グループの合計数を取得する方法
リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • ディレクトリ同期とユーザー認証の長期化
  • アプリケーション アクセスとグループ管理の UI が応答しない
緩和オプション
  • LDAP 接続プールを設定してください。接続が多すぎたり少なすぎたりすると、パフォーマンスに悪影響を及ぼす可能性があります。詳細については、「LDAP 接続プールを設定する」を参照してください。

  • [ログイン時にグループメンバーシップをアップデート] オプションを [新規追加ユーザー向けのみ] または [しない] に変更して、ログインごとのグループ同期を無効にしてください。詳細については、「LDAP ディレクトリへの接続」を参照してください。

    この設定を変更すると、グループ メンバーシップのデータは次のディレクトリ同期まで更新されなくなります。

    Jira のユーザー ディレクトリ設定ページの "詳細設定" セクション

  • ユーザー管理の制限と推奨事項をよく理解してください。


入れ子になったグループの深さ

CONTENTTYPE

グループが入れ子になっているときの階層レベルの数

ガードレール

深度 4 レベルまで

また、グループにユーザーと他のグループが混在しないようにすることをお勧めします。これもパフォーマンスに影響する可能性があるからです。

この数を調べる方法グループのネストの深さを確認する方法
リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • ディレクトリ同期とユーザー認証の長期化
緩和オプション

深い入れ子にならないように、グループ構造を再構築してみてください。たとえば、グループ構造を次の 2 つのカテゴリに分けることができます。

  • ユーザー アカウントのみを含むグループ (他のグループは含まない)
  • 他のグループのみを含むグループ (個人アカウントは含まない)

入れ子グループには、独自の制限と潜在的な副作用があります。グループ構造を再構築する前に、このメカニズムを必ず理解しておいてください。詳細については、「入れ子グループの管理」を参照してください。

例を表示する...

この種の構造がどのようなものかをよりよく理解するために、次の単純なシナリオにおいて組織がいくつかの上位グループを定義する場合を考えます。

  • staff - 組織の全従業員用
  • engineering - エンジニアリング部門のメンバー用
  • design - デザイン部門のメンバー用
  • マーケティング部門のメンバー用の "マーケティング"

この例では、engineering グループに焦点を当てます。このグループはより大きな staff グループの一部であり、dev-a と dev-b など、別々のスクラム チームを表す小さなサブグループのみで構成されます (メンバーのアカウントは含まれません)。staff グループには、ユーザー アカウント自体は保存されず、社内の各部門のサブグループのみが保存されます。

個々のアカウントが engineering の dev-a と dev-b のサブグループにのみ追加されるようにすることで、管理しやすい権限継承スキームを維持しながら、入れ子のレベルを最大 3 つに減らしています。

次のツリー図は、この階層を示しています。

staff/
├─ engineering/
│  ├─ dev-a/
│  │  ├─ jsmith@acme.com
│  │  ├─ jdoe@acme.com
│  │  ├─ mdavis@acme.com
│  ├─ dev-b/
│  │  ├─ rlewis@acme.com
│  │  ├─ nphillips@acme.com
│  │  ├─ tadams@acme.com
├─ design/
├─ marketing/

Automation for Jira

Automation for Jira のガードレールは、インスタンスの全体的なヘルス状態から導き出されています。ルール実行のパフォーマンスを評価するときは、Jira Software と Jira Service Management のパフォーマンスとスケーリングに関するガードレールに留意してください。 

自動化ルールを最適化するためのベスト プラクティスについて説明します

ルールの作成/更新/削除

CONTENTTYPEルールの作成/更新/削除の頻度
ガードレール

インスタンスのルール数:

  • 1–5000 ルール → 編集は 1 分ごとに 1 回
  • 5001–10.000 ルール → 編集は 5 分ごとに 1 回
  • 10.001–15.000 ルール → 編集は 15 分ごとに 1 回
  • 15.000 超 → 推奨されません
この数を調べる方法
(warning) データベースへのアクセスが必要

X を、対応する分の値に置き換えます。クエリに含まれる時間単位の単数形/複数形を調整してください (PostgreSQL のみ)。

SELECT "UPDATED"
FROM "AO_589059_RULE_CONFIG"
WHERE "UPDATED" >= NOW() - INTERVAL 'X MINUTE/S';
SELECT UPDATED 
FROM AO_589059_RULE_CONFIG
WHERE UPDATED >= NOW() - INTERVAL X MINUTE;
SELECT UPDATED 
FROM AO_589059_RULE_CONFIG
WHERE UPDATED >= DATEADD(MINUTE, -X, GETDATE());
SELECT UPDATED
FROM AO_589059_RULE_CONFIG
WHERE UPDATED >= SYSDATE - INTERVAL 'X' MINUTE;
リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • ルール構成での作成/更新/削除操作の頻度が高いと、高コストな EventRuleCache の更新がトリガーされます。

  • 課題関連のアクション (作成、編集、削除) は、変更適用後に EventRulesCache が読み込まれるまで待機するため、20-50 秒の遅延が発生します。

  • 自動化ルールの構成変更と課題操作を連続して行う HTTP スレッドが以下をブロックします。

    • http-nio-8080-exec-x URL: /jira/rest/cb-automation/latest/project/GLOBAL/rule/xxxx (…) 待機中

    • http-nio-8080-exec-x URL: /jira/rest/api/2/issue/ (…) 待機中

  • ルール実行を担当する HTTP スレッドが待機します (automation-rule-executor:thread-x 待機中)。

緩和オプション

  • 自動化ルールの数を減らします (キャッシュの読み込みが速くなります)。

  • 自動化ルール (ルール構成) に対して実行する作成/更新/削除操作の数を減らします。

  • ユーザーがルールを頻繁に更新する理由を確認します。

  • ルール管理権限を持つユーザーの数を減らします。

  • ルール管理の実施スケジュールを設定し、組織に周知します。これにより、ユーザーは遅延発生の可能性があることを把握できます。

自動化ルールの実行

CONTENTTYPE1 日あたりのルール実行回数
ガードレール10,000, 000
この数を調べる方法

(warning) データベースへのアクセスが必要

SELECT COUNT(*)
FROM "AO_589059_RULE_STAT"
WHERE "CREATED"::DATE = NOW()::DATE;
SELECT COUNT(*)
FROM AO_589059_RULE_STAT
WHERE DATE(CREATED) = CURDATE();
SELECT COUNT(*)
FROM AO_589059_RULE_STAT
WHERE CAST(CREATED AS DATE) = CAST(GETDATE() AS DATE);
SELECT COUNT(*)
FROM AO_589059_RULE_STAT
WHERE TRUNC(CREATED) = TRUNC(SYSDATE);

UI から (ルールごとに集計)

1 日あたりのルール実行回数を確認する手順は以下のとおりです。

  1. [管理] > [システム] > [自動化ルール] (Automation for Jira の下) の順に移動します。

  2. […] (その他の操作) メニュー > [View performance insights (パフォーマンス インサイトを表示)] > [1d (1 日)] の順に選択してから、グラフの下にあるドロップダウン メニューで [Execution count (実行回数)] を選択します。

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • AO_589059_RULE_STAT_ROLLUP_DAY の TempDB/Version ストアの使用率が高いことが原因でディスク容量がなくなります。
緩和オプション

Jira Data Center 自動化リリース ノートの詳細をご覧ください。

Automation for Jira のバージョン間の互換性についての詳細をご確認ください。


JQL を含むルール

ルールに JQL 検索が含まれている場合は、パフォーマンスの問題が発生しないかどうかを評価する必要があります。

CONTENTTYPEJQL クエリの複雑さ
ガードレール(ルールごとに) 個別の評価が必要
この数を調べる方法

アプリ診断 

JQL モニターは以下から入手できます。
 <JIRA_URL>/plugins/servlet/diagnostics/overview

Jira Data Center の監視についての詳細をご確認ください。

低速な JQL のログ

既定のしきい値 400ms を超える実行について、JQL クエリとそのソースを記録します (atlassian-jira-slow-queries.log)。

Automation for Jira に関連するスレッドには、プレフィックス automation-rule-executor:thread-# が付きます。

有用な Jira ログ ファイルの詳細をご確認ください。

リスク

このガードレールを超えて運用した場合は、次の問題が確認されています。

  • ルールの実行が遅くなります。

  • 自動化スレッドがブロックされます。

  • JQL のケースによっては、影響を受ける Jira の一部のパフォーマンスが低下します。

  • 最悪のシナリオではインスタンスが応答しなくなります。

緩和オプション

Automation for Jira の監視

Automation for Jira には、一連の監視ツールが用意されています。

自動化アクティビティを監視し、問題を診断する方法の詳細をご確認ください。

大規模なインスタンスについては、次のことを強くお勧めします。

  • ログの有効期限を短くします。大規模なインスタンスでは時間の経過とともに監査ログが蓄積されて、Jira データベースのパフォーマンスに影響を与えてディスク容量を圧迫する可能性があります。監査ログ アイテムを期限切れにする方法についてのガイドでは、不要になった古い監査ログ アイテムを定期的に削除する方法について説明しています。 
  • サービス制限を調整します。Jira 自動化には、自動化ルールを抑制するための一連のサービス制限が用意されています。ルールがこれらの制限に違反すると、Jira インスタンスに影響を与えないように調整されて無効化されます。 
Last modified on Mar 25, 2024

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.