AWS でのエンタープライズ Jira インスタンスの推奨インフラストラクチャ

このページの内容

Jira Data Center のサイズ プロファイル」では、インスタンスが "Small"、"Medium"、"Large"、または "XLarge" のどれに該当するかを確認するためのシンプルなガイドラインを示しています。これらのサイズ プロファイルはさまざまな Server および Data Center のケース スタディに基づいており、あらゆるインフラストラクチャ サイズおよび構成のインスタンスを網羅しています。負荷プロファイルを把握しておくことは、企業の成長を計画したり、メトリクスの増長を確認したり、インフラストラクチャの適合性を簡単に確認したりするのに役立ちます。

特に高可用性が不要な場合には、"Small" または "Medium" サイズのデプロイでは単一ノードが適切だといえます。 
既存の Server インストールがある場合は、Data Center にアップグレードする際にそのインフラストラクチャを引き続き使用できます。Data Center 専用の多くの機能 (SAML シングル サインオンレート制限によるシステムの保護CDN サポートなど) では、クラスタ インフラストラクチャは不要です。Server インストールのライセンスをアップグレードするだけで、Data Center のこれらの機能の使用を開始できます。
tip/resting Created with Sketch.

クラスタ化が必要かどうかの詳細については「アトラシアンの Data Center 製品のアーキテクチャとインフラストラクチャのオプション」をご参照ください。

負荷が増加して "Large" または "XLarge" サイズに近づいてきたら、定期的にインフラストラクチャを評価する必要ががあります。環境内でパフォーマンスや安定性の問題が発生し始めたら、クラスタ (またはクラスタ対応) インフラストラクチャへの移行を検討します。これを行う際は、効果的に行うための方法は常に明確であるとは限らないということに注意します。たとえば、成長しつつある "Medium" サイズのインスタンスにアプリケーション ノードを追加してもパフォーマンスが向上するとは限りません (低下する場合もあります)。 

アトラシアンではお客様によるインフラストラクチャの設定または成長の計画立案をサポートするため、一般的な "Medium"、"Large" および "XLarge" サイズのインスタンスで一連のパフォーマンス テストを実施しました。これらのテストは、ご利用のクラスタ化されたデプロイメントのアプリケーションおよびデータベース ノードに有用なデータ主導の推奨事項を確認できるように設計されています。これらの推奨設定は、プロジェクト化されたコンテンツおよびトラフィックのサイズに合った適切なクラスタ化環境の計画に役立てることができます。

パフォーマンスの結果は、サードパーティ製アプリ、データ、トラフィック、インスタンス タイプなどの多くの要因によって異なります。このため、弊社で実現したパフォーマンスをご利用の環境では再現できない可能性があります。これらの推奨設定の詳細を確認するため、テストの方法論を必ずお読みください。

パフォーマンスの監視の詳細については、「Jira Data Center のサンプル デプロイと監視戦略」を参照してください。



推奨設定の概要

アトラシアンで実行したテストから得られたベンチマークおよび構成の分析に基づき、Jira Large および Jira XL のアプリケーション ノードデータベース ノードに対して、次のような費用対効果とフォールト トレラントの推奨設定を導きました。

テスト方法の詳細をお読みください。

ベスト パフォーマンスと信頼性のための推奨設定 - Jira L

For Large profile customers, we recommend c4.8xlarge 3 nodes for Jira 8.5, which guarantees best performance and fault tolerance. The test results show that having powerful hardware with fewer nodes will provide the most optimal performance.

For Jira 8.13, we recommend c5.9xlarge 3 nodes, which guarantees best performance and fault tolerance. The test results show that having relatively powerful hardware with fewer nodes will provide the most optimal performance.

We also recommend m4.2xlarge (8.13) or  m4.4xlarge (8.5) as the minimum database requirement that achieves the desired throughput. 


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.13c5.9xlarge x 3m4.2xlarge0.8594.99
Jira 8.5

c4.8xlarge x 3

m4.4xlarge

0.7427.16

インスタンスの詳細:

費用対効果および最適なパフォーマンスのための推奨設定 - Jira L

For Jira 8.5, the test results show that having powerful hardware with fewer nodes will provide the most optimal performance. The instance type used - c4.8xlarge - has 36 CPUs and 60 GB of RAM. Having two or three nodes of this type ensures good performance at a reasonable cost. We also recommend m4.xlarge as the minimum database requirement that achieves the desired throughput. 

For Jira 8.13, the test results show that less powerful hardware provides optimal performance at low cost. The instance type used -  c5.2xlarge - has 8 CPUs and 16 GB of RAM. Having 3 or 4 nodes of this type ensures good performance at a reasonable cost. We also recommend m4.xlarge as the minimum database requirement that achieves the desired throughput.


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.13c5.2xlarge x 3m4.xlarge0.8411.22
Jira 8.5

c4.8xlarge x 2

m4.xlarge

0.742

4.97

インスタンスの詳細: 

ベスト パフォーマンスと信頼性のための推奨設定 - Jira XLarge

The test results show that having powerful hardware the most optimal performance. Hence, for XLarge profile customers for whom performance takes priority over cost, we recommend c5.9xlarge 6 nodes for Jira 8.5. This number of nodes guarantees best performance, throughput, and fault tolerance. The instance type used (c5.9xlarge) has 36 CPUs and 72 GB of RAM. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput.

For Jira 8.13, we recommend c5.4xlarge 2 nodes. This number of nodes guarantees best performance, throughput, and fault tolerance. The instance type used (c5.4xlarge) has 16 CPUs and 32 GB of RAM. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput.


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.13c5.4xlarge x 2m4.4xlarge0.9182.16
Jira 8.5c5.9xlarge x 6m4.4xlarge0.80311.51

インスタンスの詳細: 

費用対効果および最適なパフォーマンスのための推奨設定 - Jira XLarge

Interestingly, for Jira 8.13, c5.2xlarge instance 8 CPUs and 16 GB RAM) at 3 nodes performed only slightly worse than c5.4xlarge still reaching an Apdex higher than 0.70. This behaviour was consistent throughout the tests. Hence, for XLarge profile customers for whom cost effectiveness is key, we recommend c5.2xlarge 3 or 4 nodes, where 4 nodes are preferred for better fault tolerance. 

また、この動作は Jira 8.5 でも見られ、c5.4xlarge を使用したときに優れた Apdex およひスループットが確認されています。このため、Jira 8.5 の場合は、c5.4xlarge 6 または 7 ノード (より優れたフォールト トレランスを希望する場合は 7 ノード) をおすすめします。なお、c5.9xlarge 3 ノードで同様の Apdex が得られました。これは c5.4xlarge の場合よりもわずかに高額です。

We recommend m4.xlarge as the minimum database requirement that achieves the desired throughput for Jira 8.5 and Jira 8.13.


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.13c5.2xlarge x 3m4.xlarge0.9051.22
Jira 8.5c5.4xlarge x 6m4.xlarge0.7204.96

インスタンスの詳細: 


1 時間あたりのコスト

1 アトラシアンの推奨設定では、各構成の相対的な価格を比較できるよう、1 時間当たりのコストを見積もっています。アプリケーション ロード バランサなどのすべてのサブコンポーネントを含めた、Jira インスタンス全体のコストを計算しています。

These figures are in US dollars (USD) for Region:Ohio, and were correct as of October 2020.


アプローチ

すべてのテストを AWS (Amazon Web Services) 環境で実施しました。これにより、多くのテストを簡単に定義および自動化し、大規模で信頼性の高いテスト結果のサンプルを取得することができます。

テスト インフラストラクチャの各部分は、すべての AWS ユーザーが利用できる標準の AWS コンポーネントです。つまり、お客様はアトラシアンの推奨設定を簡単にデプロイできます。これを実現するために、Jira Data Center のデプロイに AWS クイック スタートを使用することもできます。

標準の AWS コンポーネントを使用したため、お客様は AWS ドキュメントでそれらの仕様を確認できます。お客様が別のクラウド プラットフォームまたは特注のクラスタ ソリューションを使用することを希望している場合、ここで同等のコンポーネントや構成を見つけることができます。

考慮事項

分析用に大量のベンチマーク サンプルを収集するため、テストは簡単にセットアップしてレプリケートできるよう設計されています。このため、お客様のインフラストラクチャ計画でベンチマークや推奨設定を参照する際には、以下を考慮してください。

  • コア製品に最適な設定を見つけることに焦点を当てていたため、テスト インスタンスへのアプリのインストールは行っていません。お客様のインフラストラクチャを設計する際には、インストールしたいアプリがパフォーマンスに与える影響を考慮する必要があります。

  • Large のテストでは、MySQL 5.6.42 をデフォルト設定で使用しました (ただし接続の最大数を 151 接続に増やしました)。XLarge のテストでは、バッファ プールを 40 G に、ログ ファイルのサイズを 2 GB に増やしました。

  • アトラシアンのテスト環境では、同じサブネット上でホストされている専用の AWS インフラストラクチャを使用しています。これによりネットワーク遅延が短縮されます。

テスト手法

各テストでは、異なる AWS 環境にある Jira データ セットに同じ量のトラフィックを適用しました。Jira アプリケーション ノードとデータベース ノードのそれぞれに最適な推奨設定を見つける、2 種類のテストを実施しました。

テスト シリーズ 1: 最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。

  • Large インスタンスのテストでは、Jira バージョンに応じて、データベースに 1 つの m4.2xlarge、m4.4xlarge、および m4.xlargeノードを使用しました。 

  • XLarge の場合、Jira バージョンに応じて、データベースに m4.4xlarge / m4.xlarge ノードを使用しました。

テスト シリーズ 2: 2 番目のテスト シリーズでは、データベース用の異なる仮想マシン タイプのベンチマークを評価しました。ここでは、テスト シリーズ 1 で最高のパフォーマンスを示した 2 つのアプリケーション ノード構成に対して異なる仮想マシン タイプをテストしました。

  • For L, these were two and three c4.8xlarge for Jira 8.5 and three c5.2xlarge and c5.9xlarge for Jira 8.13.

  • For XLarge 8.13, these were three c5.2xlarge and two c5.4xlarge. These application node configurations yielded the highest Apdex. For XLarge 8.5, these were six c5.9xlarge.

To help ensure the reliability of our benchmarks, we tested each configuration two times. We ran the first and second test series on two Long Term Support releases available to us at the time – Jira Data Center 8.13 and Jira Data Center 8.5.

Large インスタンス テストのデータ セット

詳細を展開

Jira Data Center インスタンス用のデータ セットを作成しました。このデータ セットには次のディメンションがあります。

メトリック

サイズのプロファイル

課題

1,000, 700

プロジェクト

1,500

ユーザー

100,000

カスタム フィールド

1,400

グループ

22,500

コメント

5,400, 000

XLarge

ワークフロー

2

権限スキーム

3

課題セキュリティ スキーム

17

Large インスタンス テストの負荷プロファイル

詳細を展開

"Large" クライアントのトラフィックのシミュレーションを行うため、素早いペースで現実的なユーザー ワークフローを再現する 72 の Selenium ブラウザを同時に使用しました。この負荷は、1 時間あたりの HTTP リクエスト数 594,000 件に相当します。

XLarge インスタンス テストのデータ セット

詳細を展開

Jira Data Center インスタンス用のデータ セットを作成しました。このデータ・セットには次のディメンションがあります。

メトリック

サイズのプロファイル

課題

7,206, 140

XLarge

プロジェクト

3,001

XLarge

ユーザー

80,002

カスタム フィールド

1,513

グループ

6,525

コメント

55,089, 850

XLarge

ワークフロー

601

XLarge

権限スキーム

100

課題セキュリティ スキーム

4

XLarge インスタンス テストの負荷プロファイル

詳細を展開

"Large" クライアントのトラフィックのシミュレーションを行うため、素早いペースで現実的なユーザー ワークフローを再現する 144 の Selenium ブラウザを同時に使用しました。この負荷は、1 時間あたりの HTTP リクエスト数 1,296,000 件に相当します。


ベンチマーク

各テストで、許容可能なパフォーマンスのしきい値として Apdex  のスコア 0.7 を使用しました。この Apdex では、1 秒の応答時間が許容可能なしきい値であるのに対し、4 秒を超える場合はすべて不満を表すしきい値とみなします。

ここに表示される Apdex は、本番環境と直接一致しない場合があることにご注意ください。テスト環境には一貫性のあるピーク負荷を持つアプリやカスタム連携は含まれていなかったため、お客様の環境で実行中の本番環境インスタンスとは異なる場合があります。

アーキテクチャ

各構成は、AWS 上に新しくデプロイされた Jira Data Center インスタンスでテストされました。

"Large" サイズのインスタンス"XLarge" サイズのインスタンス


Jira Large の設定の詳細

L サイズのインスタンスの設定の詳細

機能

仮想マシンのタイプ

注意

Jira アプリケーション

変数

JVM ヒープは、すべてのテストで 8G に設定されました。テストに使用したインスタンス タイプ: c5.2xlarge、c5.4xlarge、c4.8xlarge、c5.18xlarge

各サーバーでは、ローカル ストレージに 100 GB の汎用 SSD (gp2) を使用しました。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

データベース

m4.4xlarge

m4.2xlarge

m4.xlarge

EC2 インスタンスでは MySQL バージョン 5.6.42 を使用しました。

データベースに使用したインスタンス サイズは 100 GB のm4.xlarge 汎用 SSD (gp2) でした。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

共有ホーム

変数

NFS サーバーでは、ストレージに 100 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 600 IOPS で、3,000 IOPS まで拡張可能です。

共有ホームのインスタンス サイズは、アプリケーション サイズと同じでした。

ELB ロード バランサ

1 x AWS Elastic Load Balancer


テストで使用した各仮想タイプの詳細については、インスタンス タイプについての AWS ドキュメント (特に「汎用インスタンス」と「コンピュート最適化インスタンス」) を参照してください。

Jira XLarge の設定の詳細

XLarge サイズのインスタンスの設定の詳細

機能

仮想マシンのタイプ

注意

Jira アプリケーション

変数:

c5.2xlarge

c4.8xlarge

c5.4xlarge

c5.9xlarge

c5.18xlarge

JVM ヒープは、すべてのテストで最大 50GB に設定されました。c5.4xlarge では最大ヒープを 25GB に設定しました。

各サーバーでは、ローカル ストレージに 300 GB の汎用 SSD (gp2) を使用しました。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

データベース

m4.4xlarge

m4.xlarge

EC2 インスタンスでは MySQL バージョン 5.6.42 を使用しました。

データベースに使用したインスタンス サイズは 300 GB の m4.4xlarge 汎用 SSD (gp2) でした。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

共有ホーム

変数

NFS サーバーでは、ストレージに 300 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

共有ホームのインスタンス サイズは、アプリケーション サイズと同じでした。

ELB ロード バランサ

1 x AWS Elastic Load Balancer


テストで使用した各仮想タイプの詳細については、インスタンス タイプについての AWS ドキュメント (特に「汎用インスタンス」と「コンピュート最適化インスタンス」) を参照してください。


テストの詳細: "Large" インスタンス

Large のテスト シリーズ 1: アプリケーション ノード

最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。このテスト シリーズでは、Jira アプリケーション ノードで、次の仮想マシン タイプのベンチマークを確認しました。

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.18xlarge

Jira のバージョンに応じて、データベースに 1 つの m4.2xlarge、m4.4xlarge または m4.xlarge ノードを使用しました。

次のグラフは、各テストでの実際の Apdex ベンチマークを示しています。

Jira 8.13 – Apdex

Jira 8.5 – Apdex

Jira 8.13 – スループット

Jira 8.5 – スループット

Jira 8.13 – アクションの失敗がユーザーに確認される頻度

Jira 8.5 – アクションの失敗がユーザーに確認される頻度


Jira 8.13 – アクションのエラーの最大数


Jira 8.5 – アクションのエラーの最大数


These results show that the best performance for Jira 8.5 came from c4.8xlarge nodes. You'll need at least three nodes for high availability for Jira 8.5. For Jira 8.13 the best performance came from c5.9xlarge nodes. You'll need at least two nodes for high availability for Jira 8.13.

The hardware spec for c4.8xlarge, is 36 CPUs and 60GB RAM. The tests using bigger hardware, c5.18xlarge, showed no performance improvements fro Jira 8.5. Also, no performance improvements were observed by adding additional nodes.

The hardware spec for c5.9xlarge is 36 CPUs and 72 GB RAM. The tests using bigger hardware, c5.18xlarge, showed no performance improvements fro Jira 8.13. Only negligible performance improvement was observed by adding an additional node.

In conclusion, for Large profile customers, we recommend c4.8xlarge 3 or 4 nodes for Jira 8.5 and c5.9xlarge 2 or 3 nodes for Jira 8.13.

これらのノードの詳細については、「Amazon EC2 C4 インスタンス」を参照してください。

ソース: Jira hardware exploration

Large のテスト シリーズ 2: データベース ノード

テスト シリーズから、Jira アプリケーションでは、c4.8xlarge 3 または 4 ノードを使用すると Apdex 結果が最高になることを確認しました。この情報を使用して次のテスト段階に移行し、データベース ノードに最適な構成をテストしました。

ここでは、両方の Jira アプリケーション ノード構成に対して、データベース ノードの次の仮想マシン タイプのベンチマークを確認しました。

  • m4.16xlarge

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge
  • m4.10xlarge


Jira 8.13 – Apex

Jira 8.5 – Apdex

Jira 8.13 – スループット

Jira 8.5 – スループット

Jira 8.13 – アクションの失敗がユーザーに確認される頻度

Jira 8.5 – アクションの失敗がユーザーに確認される頻度

Jira 8.13 – アクションのエラーの最大数


Jira 8.5 – アクションのエラーの最大数


データベース接続プールは、デフォルトの 20 (最小および最大サイズ) を使用するように構成されています。


Interestingly, the tests proved that m4.xlarge database produced satisfactory throughput and performance. This suggests that for the Large profile load, we should use m4.xlarge as the minimum database requirement that achieves the desired throughput. However, for better performance m4.4xlarge or m4.2xlarge is recommended.

ソース: Jira hardware exploration

テストの詳細: "XLarge" インスタンス

XLarge のテスト シリーズ 1: アプリケーション ノード

最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。このテスト シリーズでは、Jira アプリケーション ノードで、次の仮想マシン タイプのベンチマークを確認しました。

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.9xlarge
  • c5.18xlarge

We used a single m4.4xlarge node for the database for Jira 8.13. For Jira 8.5 we used m4.xlarge and m4.4xlarge. m4.xlarge was the smallest database to handle the XLarge data set for Jira 8.5.

次のグラフは、各テストでの実際の Apdex ベンチマークを示しています。

Jira 8.13 – Apex

Jira 8.5 – Apex

Jira 8.13 – アクションの失敗がユーザーに確認される頻度

Jira 8.5 – アクションの失敗がユーザーに確認される頻度

Jira 8.13 – スループット

Jira 8.5 – スループット


Jira 8.13 – アクションのエラーの最大数

Jira 8.5 – アクションのエラーの最大数


These results show that the best performance came from c5.9xlarge nodes for Jira 8.5 and c5.4xlarge for Jira 8.13 (although the difference between c5.9xlarge and c5.4xlarge was minimal). Based on these results, you need at least three nodes to provide an Apdex over 0.7 for Jira 8.5 and only one for Jira 8.13. Apdex turned out highest at two nodes for Jira 8.13, and and six for Jira 8.5. Additionally, at two nodes for Jira 8.13 and six for Jira 8.5 the instance achieved notable throughput.

It's also noteworthy that for Jira 8.13, 3 c5.2xlarge nodes reached Apdex of 0.905.

このインスタンス タイプ (c5.9xlarge) のハードウェア仕様は 36 CPU および 72 GB RAM です。

このインスタンス タイプ (c5.4xlarge) のハードウェア仕様は 16 CPU および 32 GB RAM です。

このインスタンス タイプ (c5.2xlarge) のハードウェア仕様は 8 CPU および 16 GB RAM です。


For Jira 8.13, the Apdex for a smaller instance, c5.4xlarge reached 0.918 at two nodes, which is only slightly better than the results for c5.9xlarge nodes. Again, at least three nodes are required for HA. The hardware spec for c5.4xlarge is 16 CPUs and 32 GB RAM. For Jira 8.5, c5.4xlarge produced good Apdex at 6 nodes, which is still fairly optimal cost-wise. For this Jira version, c5.9xlarge at 3 nodes produced the same Apdex but slightly worse throughput and this setting is also slightly more expensive.

In conclusion, if cost is no issue, then c5.9xlarge at six nodes for Jira 8.5 and c5.4xlarge at two nodes for Jira 8.13 produces the best performance results.

However, if cost-effectiveness is a concern, then for Jira 8.5 c5.4xlarge at six nodes also seems to be a good option to consider. For Jira 8.13 it's c5.2xlarge at 3 nodes.


これらのノードの詳細については、「Amazon EC2 C5 インスタンス」を参照してください。

XLarge のテスト シリーズ 2: データベース ノード

テスト シリーズから、Jira 8.13 のアプリケーション ノードでは、c5.2xlarge 3 ノードの場合に Apdex が最高となり、2 つの c5.4xlarge ノードを使用すると、最も費用対効果の高いオプションとなることが判明しました。Jira 8.5 の場合、これらは 6 つの c5.9xlarge と 6 つの c5.4xlarge になります。この情報を使用して次のテスト段階に移行し、データベース ノードに最適な構成をテストしました。

ここでは、両方の Jira アプリケーション ノード構成に対して、データベース ノードの次の仮想マシン タイプのベンチマークを確認しました。

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge

  • m4.10xlarge

  • m4.16xlarge

Jira 8.13 – Apdex

Jira 8.5 – Apdex

Jira 8.13 – アクションの失敗がユーザーに確認される頻度

Jira 8.5 – アクションの失敗がユーザーに確認される頻度

Jira 8.13 – スループット

Jira 8.5 – スループット

Jira 8.13 – アクションのエラーの最大数

Jira 8.5 – アクションのエラーの最大数


"Large" Jira インスタンス推奨設定

アトラシアンでは "Large" テスト フェーズのベンチマークと構成を分析し、最も費用対効果が高く、フォールト トレラントである以下の推奨設定を導きました。

これらの推奨設定の背後にある詳細については、上記の Large テスト フェーズの「アプリケーション ノード」と「データベース ノード」のセクションを参照してください。

ベスト パフォーマンスと信頼性のための推奨設定


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1
Jira 8.13c5.9xlarge x 3m4.2xlarge0.8594.99
Jira 8.5

c4.8xlarge x 3

m4.4xlarge

0.7427.16


Interestingly, c5.18xlarge instances (72 CPUs and 144 GB RAM) performed worse than c4.8xlarge for Jira 8.5 and than c5.9xlarge for Jira 8.13. This behaviour was consistent throughout the tests. For Large profile customers, we recommend c5.9xlarge 3 nodes for Jira 8.13 and c4.8xlarge 3 nodes for 8.5, which guarantees best performance and fault tolerance. We also recommend m4.2xlarge as the minimum database requirement that achieves the desired throughput for Jira 8.13 and for Jira 8.5 this is m4.4xlarge.

費用対効果および最適なパフォーマンスのための推奨設定


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1
Jira 8.13c5.2xlarge x 3m4.xlarge0.8411.22
Jira 8.5

c4.8xlarge x 2

m4.xlarge

0.742

4.97



For Jira 8.5, the test results show that having powerful hardware with fewer nodes will provide the most optimal performance. The instance type used - c4.8xlarge - has 36 CPUs and 60 GB of RAM. Having 2 or 3 nodes of this type ensures good performance at a reasonable cost. We also recommend m4.xlarge as the minimum database requirement that achieves the desired throughput.

For Jira 8.13, the test results show that less powerful hardware provides optimal performance at low cost. The instance type used -  c5.2xlarge - has 8 CPUs and 16 GB of RAM. Having 3 or 4 nodes of this type ensures good performance at a reasonable cost. We also recommend m4.xlarge as the minimum database requirement that achieves the desired throughput.

"XLarge" Jira インスタンスの推奨設定

アトラシアンでは "XLarge" テスト フェーズのベンチマークと構成を分析し、最も費用対効果が高く、フォールト トレラントである以下の推奨設定を導きました。

これらの推奨設定の背後にある詳細については、上記の XLarge テスト フェーズの「アプリケーション ノード」と「データベース ノード」のセクションを参照してください。

ベスト パフォーマンスと信頼性のための推奨設定

The test results show that having powerful hardware the most optimal performance. The instance type used - c5.9xlarge - has 36 CPUs and 72 GB of RAM. Hence, for XLarge profile customers for whom performance takes priority over cost, we recommend c5.9xlarge 6 nodes for Jira 8.5. This number of nodes also guarantees fault tolerance and notable throughput. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput. 

For Jira 8.13, we recommend c5.4xlarge 2 nodes. This number of nodes also guarantees fault tolerance and notable throughput. We also recommend m4.4xlarge as the minimum database requirement that achieves the desired throughput. The instance used - c5.4xlarge, is 16 CPUs and 32 GB RAM.


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.13c5.4xlarge x 2m4.4xlarge0.9182.16
Jira 8.5c5.9xlarge x 6m4.4xlarge0.80311.51

費用対効果および最適なパフォーマンスのための推奨設定

Interestingly, for Jira 8.13, c5.2xlarge instance (8 CPUs and 16 GB RAM) at three nodes performed only slightly worse than c5.4xlarge at two nodes still reaching an Apdex higher than 0.70. This behaviour was consistent throughout the tests. Hence, for Jira 8.13 XLarge profile customers for whom cost effectiveness is key, we recommend c5.2xlarge 3 or 4 nodes, where 4 nodes are preferred for better fault tolerance.

For Jira 8.5, where c5.4xlarge performed nicely at six nodes. This is why, if you're considering Jira 8.5, we recommend c5.4xlarge 6 or 7 nodes, where 7 nodes are preferred for better fault tolerance. However, it's worth noting that c5.9xlarge achieved an Apdex higher than 0.70 at 3 nodes, and this solution is only slightly more expensive than the c5.4xlarge at 6 nodes.

We recommend m4.xlarge as the minimum database requirement that achieves the desired throughput for Jira 8.13 and Jira 8.5.


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.13c5.2xlarge x 3m4.xlarge0.9051.22
Jira 8.5

c5.4xlarge x 6

m4.xlarge

0.720

4.96

1 時間あたりのコスト

1 アトラシアンの推奨設定では、各構成の相対的な価格を比較できるよう、1 時間当たりのコストを見積もっています。アプリケーション ロード バランサなどのすべてのサブコンポーネントを含めた、Jira インスタンス全体のコストを計算しています。

These figures are in US dollars (USD) for Region:Ohio, and were correct as of October 2020.

アトラシアンで使用するインスタンス

以下の表は、お客様で参照可能な弊社の本番インスタンスを示しています。

ユースケース

ノード

AWS アプリケーション ノード

説明

Jira のスケール テスト

2

c4.8xlarge

この環境を使用し、異なる Jira バージョンで "Large" サイズ プロファイルに匹敵する負荷をテストします。「Jira の拡張」の各リンクには、特定のユーザー アクションに対する Jira バージョンでの応答時間、および以前のバージョンとの比較が表示されます。

公開 Jira Service Desk インスタンス (getsupport.atlassian.com)

3

c5.9xlarge

Jira Data Center のサンプル デプロイメントと監視戦略」で、アトラシアンが管理している実際の 2 つの Jira Data Center インスタンスについて説明しています。いずれも、公開されたアトラシアン サービスをホストする Large サイズのインスタンスです。どちらも同一のアーキテクチャを備えていますが、異なるアプリケーション ノードとデータベース ノードを使用します。

公開 Jira Software インスタンス

(jira.atlassian.com)

3

m4.4xlarge

Atlassian が提供するサービス

時間の経過とともに、新しいテスト、知見、または Jira Data Center の改善によって、推奨設定が変更されることがあります。そのような場合はこのページをご参照ください。Data Center インスタンスに最適な構成を選択する際にさらなる支援が必要な場合は、アトラシアンのテクニカル アカウント マネージャーにお問い合わせください。

アトラシアンのプレミア サポート チームは、お客様のアプリケーションとログを細かく分析してヘルス チェックを行い、お客様のインフラストラクチャ構成がお使いの Data Center アプリケーションに最適であることを確認します。ヘルス チェックでパフォーマンスのギャップが判明した場合、プレミア サポートは実施可能な変更を提案いたします。

最終更新日: 2020 年 10 月 8 日

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

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