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

Jira Software のガードレール

Performance and scaling

このページの内容

関連コンテンツ

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

お困りですか?

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

コミュニティに質問

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

背景

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

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

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

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

  • インフラストラクチャの変更。たとえば、メモリや 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/
最終更新日 2023 年 11 月 3 日

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

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

関連コンテンツ

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