パフォーマンスおよび拡張のテスト
Jira の各リリースにおいて、アトラシアンは最新の Jira バージョンと以前のバージョンでのパフォーマンスの比較を行い、パフォーマンスと拡張に関するレポートを公開しています。このレポートには、さまざまなデータ ディメンション (カスタム フィールド、課題、プロジェクトなどの数) による Jira への影響に関する結果が記載されているため、Jira の拡張で最良の結果を実現するために制限すべきデータ ディメンションの判断に役立ちます。
これは Jira 9.4 のレポートです。他のバージョンに関するレポートをお探しの場合は、画面の右上隅でご希望のバージョンを選択してください。
次のセクションにジャンプ
はじめに
一部の Jira 管理者は、Jira の拡張方法を検討する際に、単一の Jira インスタンスが保有できる課題の数に焦点を当てがちです。しかし、Jira インスタンスの拡張性を決める要因は、課題の数だけではありません。大規模なインスタンスのパフォーマンスを理解するには、複数の要因を検討する必要があります。
このページでは、異なるバージョンや設定における Jira のパフォーマンスについてご説明します。お客様がニーズの拡大に合わせて Jira を拡張する方法を理解しようとする新人の Jira エバリュエータであっても、Jira を次のレベルに進めることに関心を持つ経験豊富な Jira 管理者であっても、このページが役に立つでしょう。
次の 2 つも主なアプローチを組み合わせ、組織全体で Jira を拡大することができます。
- 単一の Jira インスタンスを拡張する
- クラスタ化されたマルチノード設定で Jira Data Center を使用する
ここでは、Jira を最大限に活用するための、両アプローチに共通する手法をご説明します。Jira Data Center のその他の情報や、Jira Data Center による同時実行の負荷下でのパフォーマンスの改善については、Jira Data Center ページをご参照ください。
1 つの Jira インスタンスのスケールを決定する
Jira の柔軟性は、ご利用の構成に多大なる多様性をもたらします。アナリティクス データによると、ほぼすべてのお客様のデータ セットが、それぞれ独自の特性を持っています。Jira インスタンスが異なれば、その規模が拡大する上でのデータ ディメンションの比率も異なります。いくつかのディメンションが他のディメンションより大幅に大きくなることも頻繁に起こります。課題数が急速に増加する一方で、プロジェクト数が一定数を維持する場合もあれば、カスタム フィールド数が非常に多くても課題数は少ない場合もあります。
多くの組織には独自のプロセスやニーズがあります。これらのさまざまなユース ケースをサポートできる Jira の能力が、データ セットの多様性の理由となっています。ただし、各データ ディメンションは Jira の速度に影響を与える可能性があります。多くの場合、これらの影響は一定または直線的ではありません。
最適なエクスペリエンスを提供してパフォーマンスの低下を避けるためには、特定のデータ ディメンションが速度にどう影響するかを理解することが重要です。
ご利用の組織で Jira のパフォーマンスに影響を与える可能性がある要因は複数あります。こうした要因は、次のようなカテゴリーに分類されます (順不同)。
- データ サイズ (次に示す項目の数):
- issues
- コメント
- attachments
- プロジェクト
- プロジェクト属性 (カスタム フィールド、課題タイプ、スキームなど)
- 登録されたユーザーとグループ
- ボード
- 任意のボード上の課題 (Jira Software の場合)
- 使用パターン (次に示す項目の数または規模):
- Jira に同時にログインしているユーザー
- 同時操作
- メール通知
- 設定 (次に示す項目の数):
- プラグイン (一部は独自のメモリ要件を持っている場合がある)
- ワークフロー ステップの実行 (トランジションや事後操作など)
- ジョブとスケジュールされたサービス
- デプロイ環境:
- 使用している Jira のバージョン
- Jira を実行しているサーバー
- 使用しているデータベースとデータベースへの接続性
- オペレーティング システム (そのファイル システムを含む)
- JVM 設定
次のセクションでは、データベースに保存されているデータのサイズや特徴によって、Jira の速度がどのように影響を受けるかをご説明します。
テスト手法
まずは、パフォーマンス テストで採用したテスト方法と、使用したテスト環境のハードウェア仕様をご説明します。
テスト データ セット
テストを開始する前に、一般的な大規模な Jira インスタンスを表すデータ セットのサイズと形状を決定する必要がありました。
これを実現するために、アトラシアンはアナリティクス データを収集して、お客様の環境や、大規模な組織で Jira を拡張する際に直面する課題の概要を把握しました。次に、テストに含まれる各データ ディメンションの 999 番目のパーミルの値を四捨五入して、内部データ生成ソリューションでランダムなテスト データ セットを生成しました。
パフォーマンス テストの結果をお客様の実際のシナリオに近づけるために、Data Generator for Jira から、より積極的に保守されている新しいデータ生成ツール (社内専用) に切り替えました。
次の表は、各データ ディメンションの正確な要素数を示しています。
| データ ディメンション | 値 |
|---|---|
アジャイル ボード | 1450 |
添付ファイル | 660,00 |
コメント | 2,900, 000 |
カスタム フィールド | 1400 |
グループ | 22,500 |
課題 | 1,000, 000 |
権限 | 200 |
プロジェクト | 1500 |
セキュリティ レベル | 170 |
ユーザー | 100,000 |
ワークフロー | 1500 |
実行した操作
次の表は、テスト ペルソナのシナリオに含まれるアクションの割合を示しており、テスト中に各アクションが実行された回数の割合を表しています。「アクション」とは、課題を開くこと、コメントの追加、ブラウザー ウィンドウでのバックログ表示など、完全な操作を意味します。
操作 | 最小 | たとえば、この個人を Max とします。 |
|---|---|---|
コメントを追加 | 1.270% | 1.284% |
ボードの参照 | 1.382% | 1.398% |
プロジェクトの参照 | 3.371% | 3.403% |
課題の作成 | 3.129% | 3.159% |
課題の編集 | 3.325% | 3.375% |
ログイン | 0.298% | 0.329% |
プロジェクトの要約 | 3.139% | 3.159% |
JQL の検索 | 13.668% | 13.750% |
課題ナビゲーション ビューの切り替え | 13.680% | 13.769% |
バックログを表示 | 5.821% | 5.913% |
ボードの表示 | 5.828% | 5.915% |
ダッシュボードの表示 | 6.967% | 7.026% |
履歴タブを表示 | 1.309% | 1.332% |
課題の表示 | 36.376% | 36.578% |
テスト環境
パフォーマンス テストは、eu-west-1 リージョンにデプロイされた一連の EC2 インスタンス上ですべて実行しました。テストごとに、環境全体のリセットと再ビルドを行いました。
テストを実行するために、スクリプトを組んだブラウザー 20 個を使用して、アクションの実行にかかる時間を計測しました。各ブラウザーのスクリプトは、定義済みのアクション リストからランダムにアクションを実行して、ただちに次のアクションに移る (つまり思考時間がゼロになる) ように記述されていました。これによって、各ブラウザーは実際のユーザーよりも大幅に多くのタスクを実行します。ブラウザー数が実際の同時実行ユーザー数と等しくなるとは解釈できないため、ご注意ください。
各テストを 20 分間行ったあと、統計情報を収集しました。
Jira Server 環境の構成内容:
- Jira ノード 1 つ
- 別のノード上にあるデータベース
- 別のノード上にあるロード ジェネレーター
Jira Data Center 環境の構成内容:
- Jira ノード 2 つ
- 別のノード上にあるデータベース
- 別のノード上にあるロード ジェネレーター
- 別のノード上にある共有ホーム ディレクトリ
- ロード バランサー (EC2 上で動作する Apache ロード バランサー)
Jira Server と Jira Data Center でパフォーマンス テストを実行するために使用した各 EC2 インスタンスのハードウェア仕様の簡単な要約を次に示します。
Jira | |||
|---|---|---|---|
ハードウェア | ソフトウェア | ||
EC2 タイプ | c5d.9xlarge (EC2 タイプ) Jira Server: 1 ノード Jira Data Center: 2 ノード | Operating system | Ubuntu 20.04LTS |
CPU のタイプ | 3.0 GHz Intel Xeon Platinum 8000-series | Java プラットフォーム | Java 1.8.0 |
CPU コア数 | 36 | Java オプション | 16 GB ヒープ サイズ |
メモリ | 72 GB | ||
ディスク | 900 GB NVMe SSD | ||
データベース | |||
|---|---|---|---|
ハードウェア | ソフトウェア | ||
EC2 タイプ | c5d.9xlarge ( EC2 タイプ ) | Operating system | Ubuntu 20.04LTS |
CPU のタイプ | Intel Xeon E5-2666 v3 (Haswell) | データベース | MySQL 5.7.32 |
CPU コア数 | 36 | ||
メモリ | 72 GB | ||
ディスク | EBS 100 GB gp2 | ||
ロード ジェネレーター | |||
|---|---|---|---|
ハードウェア | ソフトウェア | ||
EC2 タイプ | c5d.9xlarge (EC2 タイプ) | Operating system | Ubuntu 20.04LTS |
CPU のタイプ | Intel Xeon E5-2666 v3 (Haswell) | Java プラットフォーム | Java JDK 8u162 |
CPU コア数 | 36 | その他のソフトウェア | Google Chrome (最新の安定したバージョン) Chromedriver (最新の安定したバージョン) WebDriver 3.141.59 |
メモリ | 72 GB | ||
ディスク | EBS 30 GB gp2 | ||
結果
このセクションでは、さまざまな設定値の相対的な影響を調査するために実施した、すべての拡張性テストの結果をご説明します。テスト プロセスは次のとおりです。
テストの参考として、上述したベースライン テスト データ セットを含む Jira インスタンスを使用して、パフォーマンス テスト サイクル全体を実行しました。
データ ディメンションとそれらのパフォーマンスへの影響に焦点を当てるため、個々のアクションをテストする代わりに、パフォーマンス テストのすべてのアクションの平均値を算出しました。
次に、ベースライン データ セットで各属性を 2 倍にして、2 倍になった各値に対して、独立したパフォーマンス テストを実施しました。一方で、ベースライン データ セットのその他のすべての値は変更しませんでした。つまり、課題の数を 2 倍にして、またはカスタム フィールドの数を 2 倍にしてテストを実行しました。ノイズを減らすために、結果が収束状態になるまでテストを繰り返しました。収束状態とは、各データ ディメンションの集計された平均応答時間の差が、それ以降の各テスト実行で 10 ミリ秒を超えなくなった状態です。
次に、2 倍にしたデータ セット テスト サイクルの応答時間を参照結果と比較しました。このアプローチによって、個別の Jira 構成アイテムのサイズの増加が (すでに大規模な) Jira インスタンスの速度にどのように影響するかを、隔離した環境で観測できました。
Jira 9.4.11 と Jira 8.20.27 を比較したデータセットごとの応答時間を次に示します。
Jira Data Center および Server 9.4.11 と Jira Data Center および Server 8.20.27 を比較した以下の表には、上記のチャートの正確な応答時間の値が記載されています。
Jira Server 9.4.11 と Jira Server 8.20.27 の比較
応答時間の単位はすべてミリ秒です。
データ ディメンション | 応答時間 (Jira 8.20.27) | 応答時間 (Jira 9.4.11) |
|---|---|---|
ベースライン | 548 | 519 |
アジャイル ボード | 552 | 517 |
カスタム フィールド | 575 | 554 |
課題 | 596 | 557 |
添付ファイル | 564 | 536 |
プロジェクト | 580 | 557 |
権限とセキュリティ レベル | 548 | 530 |
ユーザーとグループ | 555 | 531 |
コメント | 560 | 527 |
すべてのデータセット | 564 | 536 |
Jira Data Center 9.4.11 と Jira Data Center 8.20.27 の比較(2 ノード)
応答時間の単位はすべてミリ秒です。
データ ディメンション | 応答時間 (Jira 8.20.27) | 応答時間 (Jira 9.4.11) |
|---|---|---|
ベースライン | 572 | 541 |
アジャイル ボード | 565 | 533 |
カスタム フィールド | 586 | 569 |
課題 | 606 | 577 |
添付ファイル | 574 | 558 |
プロジェクト | 602 | 579 |
権限とセキュリティ レベル | 561 | 541 |
ユーザーとグループ | 564 | 546 |
コメント | 576 | 548 |
すべてのデータセット | 578 | 554 |
その他のリソース
課題をアーカイブする
課題の数は Jira のパフォーマンスに影響するため、不要になった課題のアーカイブが望ましい場合があります。また、Jira のビューに多数の課題が表示され、不要になった古い課題をインスタンスからアーカイブしたい場合があります。「プロジェクトのアーカイブ」を参照してください。
ユーザー管理
Jira ユーザー ベースが増加すると、以下を確認する必要が出る場合があります。
- 認証、ユーザー、グループ管理のために Jira をディレクトリに接続します。
- ユーザー管理のために Crowd または別の Jira Server に接続する 。
- 他のアプリケーションに対し、ユーザー管理のために Jira への接続を許可する。
Jira ナレッジベース
パフォーマンス関連のトピックの詳細なガイドラインについては、Jira ナレッジベースの「Jira サーバーのパフォーマンスの問題のトラブルシューティング」の記事を参照してください。
Jira エンタープライズ サービス
For help with scaling Jira in your organization directly from experienced Atlassians, check out our Additional Support Services offering.
ソリューションパートナー
お住まいの地域のアトラシアン エキスパートも、お客様の環境での Jira の拡大をサポートできます。