Jira Software のガードレール

お困りですか?

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

コミュニティに質問

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

背景

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

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

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

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

  • インフラストラクチャの変更。たとえば、メモリや 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

エピックの数

ガードレール

100,000 エピック

この数を調べる方法

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

リスク

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

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

緩和オプション

スプリント

CONTENTTYPE

スプリントの合計数

ガードレール

60,000 スプリント

この数を調べる方法

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

リスク

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

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

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

緩和オプション

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

操作

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

ガードレール

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

この数を調べる方法


リスク

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

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

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

緩和オプション

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

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

履歴の変更

CONTENTTYPE

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

ガードレール

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

この数を調べる方法

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

リスク

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

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

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

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

緩和オプション

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

LDAP ユーザーとグループ

CONTENTTYPE

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

ガードレール

  • 70000 ユーザー

  • 20000 グループ

この数を調べる方法

LDAP と Jira 間で同期されるユーザーの合計数を調べる方法

リスク

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

  • 完全同期には非常に長い時間がかかります。

また、多数のグループや複雑な入れ子グループを伴うインスタンスは、多くの場合、非常に複雑な権限構造を持ち、パフォーマンスに影響を与える可能性があることも確認されています。

緩和オプション

  • Microsoft Active Directory をご利用の場合は、増分同期を有効にします。これによって、LDAP から変更がフェッチされて完全同期の必要性がなくなります。

  • Crowd によって次のような機能を活用します。

    • アクセスベースの同期によって、アプリへのアクセス権を持つユーザーのみを同期します。アクセスベースの同期についてご確認ください。

    • ユーザーが認証を行うたびに LDAP から Crowd にユーザーのグループ メンバーシップをインポートできるように、委任ディレクトリを使用します。委任認証ディレクトリの設定方法をご確認ください。

  • ユーザー、グループ、メンバーシップ スキーマ設定フィルターによって、Jira と同期されるデータを制限します。ユーザー管理の制限と推奨事項についてご確認ください。

最終更新日: 2022 年 12 月 21 日

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

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.