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

このページの内容

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

サイズが大きくなってきたら、インフラストラクチャをアップグレードすることを検討する必要がある場合があります。この計画を立てる際には、Jira アプリケーションとデータベース ノードのデプロイ方法を把握しておく必要があります。ただし、これを効果的に行うための方法は常に明確であるとは限りません。たとえば、成長しつつある "Medium" サイズのインスタンスにアプリケーション ノードを追加してもパフォーマンスが向上するとは限りません (低下する場合もあります)。

アトラシアンではお客様を支援するため、一般的な "Large (L)" および "Extra Large (XL)" サイズの Jira インスタンスで一連のパフォーマンス テストを実施しました。これらのテストは、ご利用の AWS デプロイメントのアプリケーションおよびデータベース ノードに有用なデータ主導の推奨事項を確認できるように設計されています。これらの推奨設定を使用することで、適切な環境を計画したり、現在のインスタンスがコンテンツおよびトラフィックのサイズに適しているかどうかを確認したりすることができます。

これらの推奨設定をそれぞれの Jira エンタープライズ リリース について更新しました。

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

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



推奨設定の概要

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

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

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

"Large" サイズのプロファイルのお客様には、最高のパフォーマンスとフォールト トレランスを保証する c4.8xlarge 4 ノード (Jira 7.13) または 3 ノード (Jira 8.5) をおすすめします。テスト結果は、少ないノード数で強力なハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。また、目的のスループットを実現する最小データベース要件として、m4.2xlarge (7.13) または  m4.4xlarge (8.5) をおすすめします。 


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.5

c4.8xlarge x 3

m4.4xlarge

0.742 7.16
Jira 7.13

c4.8xlarge x 4

m4.2xlarge

0.717

8.36

インスタンスの詳細:

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

テスト結果は、少ないノード数で強力なハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c4.8xlarge) の仕様は 36 CPU、60 GB RAM でした。このタイプのノードを 2 つまたは 3 つ使用することで、妥当なコストで優れたパフォーマンスを確保できます。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。 


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.5

c4.8xlarge x 2

m4.xlarge

0.742

4.97

Jira 7.13

c4.8xlarge x 3

m4.xlarge

0.716

6.56

インスタンスの詳細: 

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

テスト結果は、優れた性能のハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c5.9xlarge) の仕様は 36 CPU、72 GB RAM でした。そのため、コストよりもパフォーマンスを優先する "XLarge" プロファイルのお客様には、c5.9xlarge 7 ノード(Jira 7.13) および 6 ノード (Jira 8.5) をおすすめします。このノード数を使用することで、最高のパフォーマンス、スループット、およびフォールト トレランスを保証できます。また、目的のスループットを実現する最小データベース要件として、m4.4xlarge をおすすめします。


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.5 c5.9xlarge x 6 m4.4xlarge 0.803 11.51

Jira 7.13

c5.9xlarge x 7

m4.4xlarge

0.743

13.04

インスタンスの詳細: 

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

興味深いことに、Jira 7.13 では、c5.4xlarge インスタンス (16 CPU および 31 GB RAM) を 5 ノードで使用した場合、パフォーマンスは c5.9xlarge の場合よりわずかに低下しましたが、Apdex は引き続き 0.70 を超えました。この動作は、テスト全体を通じて一貫していました。したがって、費用対効果を重視する "XLarge" サイズのお客様には、c5.4xlarge 7 または 8 ノード (より優れたフォールト トレランスを実現する場合は 8 ノード) をおすすめします。 

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

目的のスループットを実現する最小データベース要件として、Jira 8.5 の場合は m4.xlargeJira 7.13 の場合は m4.4xlarge をおすすめします。


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.5 c5.4xlarge x 6 m4.xlarge 0.720 4.96
Jira 7.13

c5.4xlarge x 7

m4.4xlarge

0.723

6.24

インスタンスの詳細: 


1 時間あたりのコスト

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

これらの金額は USD で、リージョンはオハイオであり、2019 年 8 月時点の値です。


アプローチ

すべてのテストを 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 つのアプリケーション ノード構成に対して異なる仮想マシン タイプをテストしました。

  • "L" の場合これらは 3 つの c4.8xlarge および 4 つの c4.8xlarge でした。これらのアプリケーション ノード構成のみが、Apdex スコア 0.70 以上を示しました。

  • "XLarge 7.13" の場合、これらは 7 つの c5.9xlarge と 7 つの c5.4xlarge でした。これらのアプリケーション ノード構成が最高の Apdex スコアを示しました。"XLarge 8.5" では、これらは 6 つの c5.9xlarge でした。

ベンチマークの信頼性を確保するため、それぞれの構成を 2 回ずつテストしました。アトラシアンでは、1 番目と 2 番目のテスト シリーズを、その時点で利用可能な最新のエンタープライズ リリースだった Jira Data Center 7.13Jira 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

Medium

コメント

55,089, 850

XLarge

ワークフロー

601

XLarge

権限スキーム

100

Medium

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

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 7.13 – Apdex

Jira 8.5 – Apdex

Jira 7.13 – スループット

Jira 8.5 – スループット

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

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


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


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


これらの結果は、c4.8xlarge ノードで最高のパフォーマンスが得られたことを示しています。Jira 8.5 で高可用性を確保するには 3 つ以上のノード、Jira 7.13 の場合は 4 つ以上のノードが必要となります。

このインスタンス タイプ (c4.8xlarge) のハードウェア仕様は 36 CPU および 60 GB RAM です。より大きなハードウェアを使用したテスト (c5.18xlarge)では、パフォーマンスは改善しませんでした。また、ノードを追加してもパフォーマンスの改善は見られませんでした。

結論として、"Large" プロファイルのお客様には、Jira バージョンに応じてc4.8xlarge 3 または 4 ノードをおすすめします。

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

ソース: Jira hardware exploration

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

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

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

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge
  • m4.10xlarge


m4.16xlarge


Jira 7.13 – Apex

Jira 8.5 – Apdex

Jira 7.13 – スループット

Jira 8.5 – スループット

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

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

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

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


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


興味深いことに、テストでは、m4.xlarge のデータベースで十分なスループットとパフォーマンスが確認されました。つまり、Large プロファイルの負荷の場合、目的のスループットを実現する最小データベース要件として、m4.xlarge を使用する必要があります。ただし、優れたパフォーマンスを実現する場合、Jira バージョンに応じて m4.4xlarge または m4.2xlarge をおすすめします。

ソース: Jira hardware exploration

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

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

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

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.9xlarge
  • c5.18xlarge

1 つの m4.4xlarge ノードを Jira 7.13 のデータベースに使用しました。Jira 8.5 の場合、Jira バージョンに応じて m4.xlarge および m4.4xlarge を使用しましたm4.xlarge は、Jira 8.5 の "XLarge" データ セットを処理できる最小のデータベースでした。

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

Jira 7.13 – Apex

Jira 8.5 – Apex

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

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

Jira 7.13 – スループット

Jira 8.5 – スループット


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

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


これらの結果は、c5.9xlarge ノードで最高のパフォーマンスが得られたことを示しています。これらの結果に基づき、0.7 を超える Apdex を提供するには、3 つ以上のノードが必要です。Jira 7.13 では 7 ノード、Jira 8.5 では 6 ノードの場合、Apdex スコアは最高になりました。さらに、Jira 7.13 では 7 ノード、Jira 8.5 では 6 ノードの場合、インスタンスは顕著なスループットを達成しました。

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


Jira 7.13 の場合、小規模なインスタンスの Apdex は、c5.4xlarge (7 ノード) で 0.723 に到達しました。この結果は、c5.9xlarge ノードの結果をわずかに下回っています。HA には少なくとも 8 つのノードが必要です。c5.4xlarge のハードウェア仕様は 16 CPU および 32 GB RAM です。Jira 8.5 の場合、c5.4xlarge は 6 ノードの場合に優れた Apdex スコアを示しました。これは引き続き優れた費用対効果と言えます。この Jira バージョンの場合、c5.9xlarge (3 ノード) を使用すると Apdex は同じになりますが、スループットはわずかに下回るほか、この設定はわずかに高額です。

結論として、コストに問題がない場合、c5.9xlarge を Jira 7.13 では 7 ノード、8.5 では 6 ノード使用すると、最高のパフォーマンス結果が得られます。

ただし、費用対効果が懸念される場合、Jira 7.13 には 7 ノードの c5.4xlarge、Jira 8.5 には 6 ノードを検討することをおすすめします。


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

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

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

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

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge

  • m4.10xlarge

  • m4.16xlarge

Jira 7.13 – Apdex

Jira 8.5 – Apdex

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

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

Jira 7.13 – スループット

Jira 8.5 – スループット

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

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


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

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

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

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


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1
Jira 8.5

c4.8xlarge x 3

m4.4xlarge

0.742 7.16
Jira 7.13

c4.8xlarge x 4

m4.2xlarge

0.717

8.36


興味深いことに、c5.18xlargeインスタンス (72 CPU および 144 GB RAM) では、パフォーマンスは c4.8xlarge よりも低下しました。この動作は、テスト全体を通じて一貫していました。"Large" サイズのプロファイルのお客様には、最高のパフォーマンスとフォールト トレランスを保証する c4.8xlarge 4 ノード (Jira 7.13 の場合) または 3 ノード (8.5 の場合) をおすすめします。また、目的のスループットを実現する最小データベース要件として、m4.2xlarge(Jira 7.13 の場合) または m4.4xlarge (Jira 8.5 の場合) をおすすめします。

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


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1
Jira 8.5

c4.8xlarge x 2

m4.xlarge

0.742

4.97
Jira 7.13

c4.8xlarge x 3

m4.xlarge

0.716

6.56



テスト結果は、少ないノード数で強力なハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c4.8xlarge) の仕様は 36 CPU、60 GB RAM でした。このタイプのノードを 2 つまたは 3 つ使用することで、妥当なコストで優れたパフォーマンスを確保できます。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。

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

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

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

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

テスト結果は、優れた性能のハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c5.9xlarge) の仕様は 36 CPU、72 GB RAM でした。そのため、コストよりもパフォーマンスを優先する "XLarge" プロファイルのお客様にはc5.9xlarge 7 ノード(Jira 7.13) および 6 ノード (Jira 8.5) をおすすめします。このノード数を使用することで、フォールト トレランスと顕著なスループットも保証できます。また、目的のスループットを実現する最小データベース要件として、m4.4xlarge をおすすめします。 


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.5 c5.9xlarge x 6 m4.4xlarge 0.803 11.51
Jira 7.13

c5.9xlarge x 7

m4.4xlarge

0.774

13.04

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

興味深いことに、Jira 7.13 では、c5.4xlarge インスタンス (16 CPU および 31 GB RAM) を使用した場合、パフォーマンスは c5.9xlarge の場合よりわずかに低下しましたが、Apdex は引き続き 0.70 以上をマークしました。この動作は、テスト全体を通じて一貫していました。ただし、Jira 7.13 "XLarge" サイズのお客様で費用対効果を重視する場合には、c5.4xlarge 7 または 8 ノード (より優れたフォールト トレランスを実現する場合は 8 ノード) をおすすめします。

この動作は、Jira 8.5 の場合 (6 ノードのc5.4xlargeで優れたパフォーマンスを発揮) も同様です。このため、Jira 8.5 の場合は、c5.4xlarge 6 または 7 ノード (より優れたフォールト トレランスを希望する場合は 7 ノード) をおすすめします。なお、c5.9xlarge は 0.70 以上の Apdex (3 ノードの場合) を示し、このソリューションは c5.4xlarge (6 ノード) よりもわずかに高額です。

目的のスループットを実現する最小データベース要件として、Jira 7.13 の場合は m4.4xlargeJira 8.5 の場合は m4.xlarge をおすすめします。


アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

Jira 8.5

c5.4xlarge x 6

m4.xlarge

0.720

4.96

Jira 7.13

c5.4xlarge x 7

m4.4xlarge

0.723

6.24

1 時間あたりのコスト

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

これらの金額は USD で、リージョンはオハイオであり、2019 年 8 月時点の値です。

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

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

ユースケース

ノード

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 アプリケーションに最適であることを確認します。ヘルス チェックでパフォーマンスのギャップが判明した場合、プレミア サポートは実施可能な変更を提案いたします。

最終更新日 2019 年 9 月 11 日

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

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