クラウド
Data Center と Server 9.6
バージョン

Jira Software のガードレール

Performance and scaling

このページの内容

関連コンテンツ

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

お困りですか?

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

コミュニティに質問

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

背景

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

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

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

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

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

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

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

定義

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

Jira Software のガードレール

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

プロジェクト

CONTENTTYPE

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

ガードレール

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

この数を調べる方法

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

リスク

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

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

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

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

緩和オプション

コメント

CONTENTTYPE

課題ごとのコメントの数

ガードレール

課題ごとに 1000 コメント

この数を調べる方法

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

リスク

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

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

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

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

緩和オプション

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

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

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

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

添付ファイル

CONTENTTYPE

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

ガードレール

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

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

この数を調べる方法

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

リスク

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

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

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

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

緩和オプション

CONTENTTYPE

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

ガードレール

1000 課題リンク

この数を調べる方法

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

リスク

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

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

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

緩和オプション

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

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

テキスト

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

Total number of users synchronized between LDAP and Jira

ガードレール

100,000 ユーザー

この数を調べる方法

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

リスク

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

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • Increased time for directory synchronization and user authentication

緩和オプション

  • If most of the user accounts in your instance are stored in Crowd Data Center, Crowd Server, or Microsoft Active Directory, enable incremental synchronization. This way, only the changes since the last synchronization will be queried, reducing the need for a full sync. For more information, see Connecting to an LDAP directory.
  • Consider using Crowd Server and Data Center as your external user directory to take advantage of features such as access-based synchronization. For more information, see Syncing users based on their access rights
  • Use LDAP filters to reduce the number of users and groups to process by your instance. For more information, see:
    • LDAP ディレクトリへの接続
    • LDAP から JIRA アプリケーションに同期されるユーザー数の削減 
    • LDAP 検索フィルターの作成方法  
  • Become familiar with User management limitations and recommendations.

Inactive users

CONTENTTYPE

Number of inactive users with content assigned to them synchronized between LDAP and Jira

ガードレール100,000 ユーザー
この数を調べる方法How to get the number of inactive users with content assigned to them 
リスク

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

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • Increased time for directory synchronization and user authentication

Additionally, there is a known issue in Jira Server and Data Center 8.20.6 and older that results in increased directory synchronization and user authentication times if you have more than 10,000 inactive users with content assigned to them in your system.

緩和オプション
  • If possible, upgrade your Jira Server and Data Center instance to release 8.20.7 or newer. That release includes a fix for the performance degradation issue related to inactive users with assigned content.
  • If you can’t upgrade at this time, unassign the inactive users from Jira content, and then run a sync to remove inactive users from your directory. For more information, see Synchronizing data from external directories.

グループ

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

ガードレール

25,000 グループ
この数を調べる方法How to get the total number of groups
リスク

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

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • Increased time for directory synchronization and user authentication
  • Application access and group management UI unresponsiveness
緩和オプション
  • Configure your LDAP connection pool. Too many or too few connections may have a negative impact on performance. For more information, see Configuring LDAP connection pooling.

  • Disable group sync on every login by changing the Update group membership when logging in option to For newly added users only or Never. For more information, see Connecting to an LDAP directory.

    Changing this setting means that group membership data will not be updated until the next directory synchronization.

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

  • Become familiar with user management limitations and recommendations.


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

CONTENTTYPE

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

ガードレール

4 levels deep

We also recommend groups do not contain a mix of users and other groups, as this can have a negative impact on performance.

この数を調べる方法How to check the depth of group nesting
リスク

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

  • 高負荷下での停止や顕著なパフォーマンスの低下など、インスタンスの不安定性
  • Increased time for directory synchronization and user authentication
緩和オプション

Try rebuilding your group structure to prevent deep nesting. For example, you can split your group structure into two categories:

  • groups containing only user accounts (and not other groups)
  • groups containing only other groups (and not individual accounts)

Nested groups come with their own set of limitations and potential side effects. Make sure that you understand this mechanism before rebuilding your group structure. For more information, see Managing nested groups.

例を表示する...

For a better understanding of what this type of structure might look like, imagine the following simplified scenario, where an organization defines some high-level groups:

  • staff for all of the organization’s employees
  • engineering for members of the engineering department
  • design for members of the design department
  • マーケティング部門のメンバー用の "マーケティング"

In this example, we’ll focus on the engineering group. The group is part of the larger staff group and contains only smaller sub-groups representing separate Scrum teams (and not their members' accounts); for example dev-a and dev-b. The staff group does not store any user accounts itself, only the sub-groups for each department in the company.

By making sure that individual accounts are added only to the dev-a and dev-b sub-groups of engineering, you’ve reduced the level of nesting to a maximum of three while keeping an easy-to-maintain permission inheritance scheme.

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

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/
Last modified on Mar 28, 2023

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

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

関連コンテンツ

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