パフォーマンスおよび拡張のテスト

お困りですか?

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

コミュニティに質問

アトラシアンでは Jira の各リリースで、最新の Jira バージョンを過去のものと比較するパフォーマンスおよびスケーリング レポートを公開しています。このレポートには、さまざまなデータ次元 (カスタム フィールド、課題、プロジェクトなどの数) による Jira への影響についての結果も記載しているため、Jira のスケーリングで最良の結果を実現するために制限すべきデータ次元の判断に役立ちます。

これは Jira 8.20 のレポートです。他のレポートをお探しの場合は、右上でバージョンを選択してください。

はじめに

一部の Jira 管理者は Jira の拡張方法について考えたとき、1 つの Jira インスタンスが保有できる課題数に焦点を与えることがよくあります。ただし、Jira インスタンスの規模を決める要因は課題数のみではありません。大きなインスタンスの実行方法について理解するには、複数の要因を検討する必要があります。

このページでは、異なるバージョンや構成で Jira を実行する方法について説明します。そのため、あなたがニーズの拡大に合わせて Jira を拡大する方法について理解する新人 Jira エバリュエータであっても、Jira を次のレベルに進めることに関心を持つ熟練した Jira 管理者であっても、このページが役に立ちます。

次の 2 つも主なアプローチを組み合わせ、組織全体で Jira を拡大することができます。  

  1. 1 つの Jira インスタンスを選択します。 
  2. Jira のクラスタリングを提供する Jira Data Center を使用します。

ここでは Jira を最大限活用するための、両方のアプローチに共通の手法について説明します。Jira Data Center の詳細や、同時負荷状態でのパフォーマンスを改善する方法については、Jira Data Center のページを参照してください。

1 つの Jira インスタンスの規模を決定する

組織内の Jira のパフォーマンスに影響を与える可能性のある要因は複数あります。これらの要因は次のカテゴリーに分類されます (特定の順序はありません):

  • データ サイズ
    • 課題、コメント、および添付ファイルの数
    • プロジェクトの数。
    • Jira プロジェクト属性の数 (カスタム フィールド、課題タイプおよびスキーム)。
    • Jira やグループに登録されているユーザー数。
    • ボード数、およびボード上の課題数 (Jira Software を使用している場合)
  • 使用パターン
    • Jira を同時に使用しているユーザー数。
    • 同時操作の数。
    • 電子メール通知の量。
  • 構成
    • プラグインの数 (一部は独自のメモリ要件を持っている場合がある)。
    • ワークフロー ステップ実行の数 (移行や事後操作など)。
    • ジョブの数とスケジュールされたサービス。
  • デプロイメント環境
    • 使用されている Jira のバージョン。
    • Jira が実行されているサーバー。
    • 使用されているデータベースとデータベースへの接続性。
    • オペレーティングシステム (ファイルシステムを含む)。
    • JVM 構成。

このページは、データベースに保存されているデータのサイズや特徴によって、Jira の速度がどのように影響を受けるかを示しています。

Jira 8.20 のパフォーマンス

Jira 8.20 はパフォーマンスのみに焦点を当てたバージョンではありませんでしたが、各リリースでは同等かそれ以上のパフォーマンスを提供することを目指しています。このセクションでは、Jira 8.13 を Jira 8.20 と比較します。同じ広範囲のテスト シナリオを両方の Jira バージョンに対して実行しました。シナリオ間の違いは Jira のバージョンのみです。

次のグラフは、Jira で実行された各種操作の平均応答時間を示しています。これらの操作と対象の Jira インスタンスの詳細については、「テスト手法」を参照してください。

Jira 操作の応答時間

Jira 8.13.11 と Jira 8.20.0 の比較

100 万件の課題

200 万件の課題


テスト手法

以下のセクションでは、当社のパフォーマンス テストで使用するテスト環境 (ハードウェア仕様を含む) とテスト方法を詳しく説明します。

テスト方法...

テストを開始する前に、一般的な大きい Jira インスタンスを表すデータセットのサイズと形状を決定する必要があります。 

これを実現するため、顧客環境の全体像や、大組織で Jira を拡張する際に顧客が直面する問題を把握するため、Analytics データを使用しました。

次の表では、各データ ディメンションの 999 番目のパーセンタイルの値を切り捨てています。これらの値を使用して、Jira Data Generator でランダム テスト データが入ったサンプル データセットを生成します。

基準となる Jira データ セット

Jira データディメンション
課題1,000, 000
プロジェクト1500
カスタム フィールド1400
ワークフロー450
添付ファイル660,000
コメント2,900, 000
アジャイルボード1,450
ユーザー100,000
グループ22,500
セキュリティ レベル170
Permissions200
実行した操作...

最も一般的なユーザー操作の例を表す操作の組み合せを選択しました。このコンテキストにおける "操作" とは、ブラウザ ウィンドウで課題を開くなどの、完全なユーザー操作です。次の表は、ペルソナのテスト用のシナリオに含めた操作の詳細と、1 回のテスト中に操作が実行される回数を示しています。この場合の性能テストには複数のテストの実行が含まれます。

操作名説明テスト実行あたりのアクション数
ダッシュボードの表示ダッシュボード ページを開く。10
課題の作成課題の作成ダイアログを送信する5
課題の表示別のブラウザー ウィンドウで個別の課題を開く。55
課題の編集課題を編集して変更を送信し、課題に表示されるまで待ちます。5
コメントを追加コメントを追加し、それが課題に表示されるまで待ちます。2
JQL の検索

課題ナビゲーター インターフェイスで JQL を使用して検索クエリを実行する。

次の JQL クエリが使用されました。
resolved is not empty order by description
text ~ \"a*\" order by summary

 

priority in [priorityname] order by reporter

 

project = [projectname] order by status

 

assignee = [username] order by project

 

reporter was [username] order by description

 

project = [projectname] and assignee = [username] order by reporter

 

text ~ "[text]" order by key

 

20
ボードの表示Agile Board を開く10
プロジェクトの参照プロジェクトのリストを開く (プロジェクト > すべてのプロジェクトの検索メニューから利用できます)5
ボードの参照Agile Boards のリストを開く (Agile > ボードの管理メニューから利用できます)2
プロジェクトの要約"プロジェクトの要約" ページを開き、メタデータ列が表示されるのを待つ5
バックログを表示[バックログ] ページを開く10
すべての操作1 回のテスト実行で実行されたすべてのアクションの重み付き算術平均です。各データ ポイントの重みは、テスト実行あたりのアクションごとのリクエスト数に対応します。-
テスト環境...

すべてのパフォーマンス テストは、eu-central-1 リージョンにデプロイされた一連の AWS EC2 インスタンス上で実行されていました。テストごとに環境全体をリセットおよび再構築し、各テストの最初にはインスタンス キャッシュをウォームアップするためのアイドル サイクルを実行しました。以下で、Jira Server と Jira Data Center で使用された環境の詳細や、EC2 インスタンスの仕様を確認できます。

テストを実行するため、スクリプトを組んだブラウザを 20 個使用し、操作の実行にかかる時間を計測しました。各ブラウザーのスクリプトは、定義済みの操作リストからランダムに操作を実行し、すぐに次の操作に移る(つまり思考時間がゼロになる)ように記述されています。これによって各ブラウザは実際のユーザーが可能なタスクよりも実質的に多くのタスクを実行するため、ブラウザの数が実際の同時実行ユーザー数と等しくなると解釈することはできません。

各テストは 20分間実行され、その後、統計情報が収集されます。 


Jira ServerJira Data Center

Jira Server の環境の構成内容:

  • 1 Jira ノード
  • 別のノード上にあるデータベース
  • 別のノード上にあるロード ジェネレーター

Jira Data Center の環境の構成内容:

  • 2 Jira ノード
  • 別のノード上にあるデータベース
  • 別のノード上にあるロード ジェネレーター
  • 別のノード上にある共有ホーム ディレクトリ
  • ロード バランサ (AWS ELB HTTP ロード バランサ)
Jira
ハードウェアソフトウェア
EC2 タイプ:

c5d.9xlarge (EC2 タイプを参照)  

Jira Server: 1 ノード

Jira Data Center: 2 ノード

オペレーティング システム: Ubuntu 16.04 LTS
CPU:

3.0 GHz Intel Xeon Platinum 8000-series

Java プラットフォーム: Java 1.8.0
CPU コア:36 Java オプション:

8 GB heap


メモリ72 GB
ディスク:

900 GB NVMe SSD

データベース
ハードウェアソフトウェア
EC2 タイプ: c4.8xlarge (see EC2 types)   データベース:MySQL 5.5
CPU: Intel Xeon E5-2666 v3 (Haswell) オペレーティング システム:


Ubuntu 16.04 LTS


CPU コア:36
メモリ60 GB
ディスク:

Jira Server: AWS EBS 100 GB gp2

Jira Data Center: AWS EBS 60 GB gp2

ロード ジェネレーター
ハードウェアソフトウェア
EC2 タイプ: c4.8xlarge (see EC2 types)   オペレーティング システム: Ubuntu 16.04 LTS
CPU: Intel Xeon E5-2666 v3 (Haswell)ブラウザ: Google Chrome 62


CPU コア:36自動化スクリプト:

Chromedriver 2.33

WebDriver 3.4.0

Java JDK 8u131

メモリ60 GB
ディスク: AWS EBS 30 GB gp2

Jira 8.20 の拡張性

Jira は柔軟なため、顧客の構成にはとてつもない多様性があります。Analytics データは、ほとんどの顧客データセットが、独自の特性を示していることを示します。異なる Jira インスタンスは、各データ ディメンションの異なる比率で増加します。いくつかのディメンションは他のディメンションより大幅に大きくなることが多くあります。たとえば、課題数が急速に増加する一方、プロジェクト数は一定数を維持することがあります。また、別の事例では、カスタム フィールドが膨大なのに、課題数が少なくなる場合があります。

多くの組織には独自のプロセスやニーズがあります。これらのさまざまな使用事例をサポートできる Jira の能力が、データセットの多様性の理由となっています。ただし、各データ ディメンションは Jira の速度に影響を与える可能性があります。多くの場合、これらの影響は一定または直線的ではありません。

それぞれの Jira インスタンス ユーザーに最適な体験を提供し、パフォーマンスの低下を防ぐため、どの Jira データ属性がアプリケーションの速度にどのような影響を与えるかを理解することが重要です。このセクションでは、各種設定値の相対的な影響を調査した Jira 8.20 拡張性テストの結果を示します。 

テスト方法

  1. テスト用の参照として、「テスト方法論」で指定したベースライン データ セットとともに Jira 8.20 インスタンスを使用し、フル パフォーマンス テスト サイクルを実施しました。 
  2. データ ディメンションとそれらのパフォーマンスへの影響に焦点を当てるため、個々の操作はテストしていませんが、代わりにパフォーマンス テストからのすべての操作の平均を使用しました。
  3. 次にベースライン データ セットで各属性を 2 倍にし、ベースライン データ セットのその他すべての値はそのままで、2 倍になった値に対して独立したパフォーマンス テストを実施しました (例:課題数を 2 倍、またはカスタム フィールド数を 2 倍にしてテストを実行)。 
  4. 次に、データ セットを 2 倍にしたときのテスト サイクルの応答時間を参照結果と比較しました。このアプローチにより、個別の Jira 構成アイテムのサイズの増加が (すでに大規模な) Jira インスタンスの速度にどのように影響するかを、隔離した環境で観測できました。 

Jira データ セットの応答時間

Jira 8.13.11 と Jira 8.20.0 の比較

データ セットが異なる場合でも応答時間は Jira のバージョン間ではほぼ同じであり、上の画像にあるような違いは、ほとんどの場合 1% を超えません。


Jira Data Center における Advanced Roadmaps のパフォーマンス

Advanced Roadmaps のパフォーマンスに影響する要因

Jira Data Center インスタンスにおける Advanced Roadmaps のパフォーマンスに関する最大の変動要因は、単純に含まれる情報の量です。Advanced Roadmaps のプランはいくつかの Jira 機能で構成されており、プランを作成するときにそれぞれを個別に実行する必要があります。プランが実行する関数が多いほど、読み込みにかかる時間が長くなります。

インスタンスにおける Advanced Roadmaps の速度は、次の要素によって決まります。

テスト方法

このページの「テスト手法」セクションで説明されているハードウェアと手法を含む、Jira パフォーマンス テスト フレームワークを使用しました。

テスト インスタンスの内容は次のとおりです。

  • 課題 1,000,000 件
  • 100,000 ユーザー

テスト プランの内容は次のとおりです。

  • 500 件の課題
  • 5 件の課題ボード課題ソース
  • 5 件のチーム (課題ソースあたり 1 件)
  • 5 レベルの課題階層
  • 80 件のリリース/バージョン
  • 0 件のプラン カスタム フィールド

Jira Data Center 8.20 における Advanced Roadmaps の要約メトリック

Jira Data Center 8.20 に含まれている本バージョンの Advanced Roadmaps は、上記の基準に基づいて次の読み込み時間を記録しました。

改善された (3.x) インターフェイスを使用中のプラン


Jira 8.20 向け Advanced RoadmapsJira 8.13 向け Advanced Roadmaps
初期の読み込み時間29833102
プラン バックログの読み込み時間10751099
プランの合計読み込み時間40634204
自動スケジュール時間35943643

単位はすべてミリ秒です。

レガシー (2.x ライブ プラン) インターフェイスを使用中のプラン


Jira 8.20 向け Advanced RoadmapsJira 8.13 向け Advanced Roadmaps
初期の読み込み時間24342553
プラン バックログの読み込み時間25952506
プランの合計読み込み時間50365066
詳細ビューの読み込み時間710702
プラン計算時間49174963

単位はすべてミリ秒です。

その他のリソース

課題をアーカイブする

課題の数は Jira のパフォーマンスに影響するため、不要になった課題のアーカイブが望ましい場合があります。また、Jira のビューに多数の課題が表示され、不要になった古い課題をインスタンスからアーカイブしたい場合があります。「プロジェクトのアーカイブ」を参照してください。

ユーザー管理

Jira ユーザー ベースが増加すると、以下を確認する必要が出る場合があります。

Jira ナレッジベース

パフォーマンス関連のトピックの詳細なガイドラインについては、Jira ナレッジベースの「Jira サーバーのパフォーマンスの問題のトラブルシューティング」の記事を参照してください。

Jira エンタープライズ サービス

経験豊富なアトラシアンから直接組織内の Jira の拡大のサポートが必要な場合は、プレミア サポートと技術アカウント管理サービスをご利用ください。

ソリューションパートナー

お住まいの地域のアトラシアン エキスパートも、お客様の環境での Jira の拡大をサポートできます。 

最終更新日: 2021 年 10 月 25 日

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

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