Data Center インフラストラクチャに関する推奨事項

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

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



これらの推奨事項をどのように使用すればよいですか?


インスタンス サイズ プロファイルの決定 




インスタンスの現在の大きさを確認します。"Small"、"Medium"、"Large"、"XLarge" があります。ガイドラインをご覧ください。

推奨設定の確認


Data Center のサイズを確認したら、以降でハードウェアの推奨設定を確認し、ニーズに合う最適なオプションを選択します。

インスタンスのボトルネックの監視 



インスタンスでスパイクやボトルネックの監視を続けます。ガイドラインを参照し、アトラシアンでのインスタンスの監視方法をご確認ください。 


これらの推奨設定を確認する際は、何に考慮する必要がありますか?

ハードウェアの推奨事項を確認する際には、次の点を考慮する必要があります。

  • パフォーマンスは、サードパーティ製アプリ、大規模なリポジトリ、データ、トラフィック、同時実行、カスタマイズ、インスタンスの種類などのさまざまな要因によって決定されます。このため、弊社でのテスト結果をお客様の環境では完全にレプリケートできない場合があります。アトラシアンでのテスト結果の背景を確認するため、弊社でのテスト方法をご確認いただくことをおすすめします。
  • アトラシアンが提供する 1 時間あたりのコストには、共有ホームやアプリケーション ロード バランサなど、アプリケーションの他のコンポーネントを使用するコストは含まれていないことにご注意ください
  • テストの詳細を参照し、推奨されるインスタンス構成のスループットをご確認ください。パフォーマンスに優れたオプションと費用対効果に優れたオプションのどちらを選ぶかの判断のためのデータとして使用できる可能性があります。テストの詳細」を参照してください。

推奨設定を自身のインスタンスにマッピングするにはどうすればよいですか?

  • 推奨されるハードウェアの仮想マシン タイプの仕様で、CPU とメモリの量をご確認ください。このデータをベースラインとして使用して、環境を計画します。Jira、Confluence、または Bitbucket 上にインストールした製品がある場合 (サードパーティ製アプリなど)、それらはパフォーマンスに影響を与え、より性能の良いハードウェアや追加のハードウェアが必要になる可能性があることに注意してください。
  • パフォーマンス テスト用のハードウェアは、Amazon Web Services (AWS) からプロビジョニングされました。インスタンスが別のプラットフォーム上でデプロイされている場合も引き続き推奨事項をガイドラインとして使用できますが、パフォーマンスは若干異なる場合があります。 
  • 実行中のアトラシアン アプリケーションに十分なリソースをプロビジョニングしていることを確認します。仮想マシンを使用している場合、Jira、Confluence、または Bitbucket を実行するための専用リソース (vCPU とメモリ) があることを確認します。共有リソースをエンタープライズ アプリに過剰にプロビジョニングしたり割り当てたりしないことをおすすめします。

推奨設定の概要

Jira Large の推奨設定

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

"Large" サイズのプロファイルのお客様には、最高のパフォーマンスとフォールト トレランスを保証する c4.8xlarge 4 ノードをおすすめします。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。

興味深いことに、c5.18xlarge インスタンス (72 CPU および 144 GB RAM) のパフォーマンスは c4.8xlarge よりも低下しました。この動作は、テスト全体を通じて一貫していました。

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト 

c4.8xlarge x 4

m4.xlarge

0.734

6.56

インスタンスの詳細: 

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

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

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト 

c4.8xlarge x 3

m4.xlarge

0.737

4.97

インスタンスの詳細: 

Jira XLarge の推奨設定

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

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

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト 

c5.9xlarge x 7

m4.4xlarge

0.774

11.51

インスタンスの詳細: 

費用対効果のための推奨設定 - Jira XLarge

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

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト 

c5.4xlarge x 5

m4.4xlarge

0.723

4.20

インスタンスの詳細: 


Bitbucket Large の推奨設定

ベスト パフォーマンスのための推奨設定 - Bitbucket Large

パフォーマンスの安定性は、インスタンスの平均 CPU 使用率がしきい値である 75 % からどの程度逸脱しているかで測定しました。前述のように、このしきい値に達すると、git 操作の速度が低下し始めます。インスタンスが 75 % から低下するとそれだけ、トラフィックのスパイクによって速度が低下する可能性が低くなります。

ただし、より優れたパフォーマンスを提供する、大きなサイズのハードウェア (m5.12xlarge など) を使用することによるデメリットはありません。

アプリケーション ノード

データベース ノード

NFS ノード

1 時間あたりのコスト 

m5.4xlarge x 4

m5.2xlarge

m5.2xlarge

$4.168

インスタンスの詳細: 

費用対効果のための推奨設定 - Bitbucket Large

この低コスト構成では、1時間あたりの git ホスティング呼び出しが 43,099 回となり、最適な構成よりも Git スループットが低くなります。それでも、1時間あたりの git ホスティング呼び出しが 32,700 回の最低しきい値を上回っています。コストのトレードオフになるのはフォールト トレランスです。インスタンスで 1 つのアプリケーション ノードが失われると、CPU 使用率は 85%に急増し、最大しきい値を超えます。インスタンスは存続しますが、パフォーマンスは低下します。

アプリケーション ノード

データベース ノード

NFS ノード

1 時間あたりのコスト 

m5.4xlarge x 3

m5.xlarge

m5.xlarge

$2.840

インスタンスの詳細: 

Bitbucket XLarge の推奨設定


ベスト パフォーマンスのための推奨設定 - Bitbucket XLarge

パフォーマンスの安定性は、インスタンスの平均 CPU 使用率がしきい値である 75 % からどの程度逸脱しているかで測定しました。前述のように、このしきい値に達すると、git 操作の速度が低下し始めます。インスタンスが 75 % から低下するとそれだけ、トラフィックのスパイクによって速度が低下する可能性が低くなります。

Component

アドバイス

アプリケーション ノード

m5.12xlarge x 4

データベース ノード

m5.2xlarge

NFS ノード

m5.2xlarge

インスタンスの詳細:

m5.12xlarge = 48 vCPU および 192 GiB

m5.2xlarge = 8 vCPU および 32 GiB

費用対効果のための推奨設定 - Bitbucket XLarge

この低コスト構成では、1時間あたりの git ホスティング呼び出しが 74,458 回となり、最適な構成よりも Git スループットが低くなります。それでも、1 時間あたりの git ホスティング呼び出しが、しきい値である 65,400 回を上回っています。コストのトレードオフになるのはフォールト トレランスです。m5.8xlargex 3 ノードではタイムアウトやエラーが観察されたため、アプリケーション ノードがダウンするとパフォーマンスが低下することがあります。

Component

アドバイス

アプリケーション ノード

m5.8xlarge x 4

データベース ノード

m5.2xlarge

NFS ノード

m5.xlarge

インスタンスの詳細:

m5.8xlarge = 32 vCPU および 128 GiB

m5.2xlarge = 8 vCPU および 32 GiB

m5.xlarge = 4 vCPU および 16 GiB


Confluence Medium の推奨設定

最適なパフォーマンスのための推奨設定 - Confluence Medium

パフォーマンス オプションは、テストしたすべての構成の中で最高の Apdex を実現しました。1 つのノードが失われても、Apdex 0.9 以上を維持できます。Confluence はすべてのテストで、0.90 を超える Apdex を示しました。

アドバイス アプリケーション ノード データベース ノード 1 時間あたりのコスト  Apdex (6.13)

パフォーマンス

c5.xlarge x 2

m4.large

$0.522

0.929

インスタンスの詳細: 

安定性のための推奨設定 - Confluence Medium

安定性オプションは、同じコストでより優れたフォールト トレランスを提供しますが、パフォーマンスはわずかに低下します。Confluence はすべてのテストで、0.90 を超える Apdex を示しました。

アドバイス アプリケーション ノード データベース ノード 1 時間あたりのコスト  Apdex (6.13)

安定性

c5.large x 4

m4.large

$0.522

0.905

インスタンスの詳細: 

Confluence Large の推奨設定

ベスト パフォーマンスのための推奨設定 - Confluence Medium

パフォーマンス オプションは、テストしたすべての構成の中で最高の Apdex を実現しました。1 つのノードが失われても、Apdex 0.8 以上を維持できます。

アドバイス アプリケーション ノード データベース ノード 1 時間あたりのコスト  Apdex (Confluence バージョンごと)
6.13 6.14
パフォーマンス c5.4xlarge x 2 m4.2xlarge 2.09 0.852 0.874

インスタンスの詳細: 

安定性と費用対効果のための推奨設定 - Confluence Large

安定性オプションと低コスト オプションは、価格、フォールト トレランス、およびパフォーマンスのバランスが取れたオプションです。これらは両方とも同じ仮想マシン タイプを使用しています。安定性オプションの場合、追加アプリケーション ノードが 1 つだけあります。安定性オプションは多くのノードが失われるまで完全にオフラインにはなりませんが、低コスト オプションはコストを削減できます。これら 2 つのオプションでは、パフォーマンスの差はほとんどありません。

アドバイス アプリケーション ノード データベース ノード 1 時間あたりのコスト  Apdex (Confluence バージョンごと)
6.13 6.14
安定性 c5.2xlarge x 4 m4.xlarge 1.72 0.817 0.837
低コスト c5.2xlarge x 3 m4.xlarge 1.38 0.820 0.834

インスタンスの詳細: 

Confluence XLarge の推奨設定

安定性のための推奨設定 - Confluence XLarge

安定性構成では、1 つのアプリケーション ノードが失われても、許容可能なパフォーマンス (Apdex 0.8) を保持できます。アプリケーション ノードが 4 つある場合、全体的なフォールト トレラントを低コスト構成よりも実現できます。

構成 アプリケーション ノード データベース ノード 1 時間あたりのコスト Apdex (Confluence バージョンごと)
6.13 6.15
安定性 c5.4xlarge x 4 m4.2xlarge 3.45 0.810 0.826

インスタンスの詳細: 

費用対効果のための推奨設定 - Confluence XLarge

低コスト構成は、3 つのノードが失われるまでサービスがオフラインにならないため、非常にフォールト トレラントです。ただし、アトラシアンのテストでは、低コスト構成でノードが 1 つ失われると、Apdex が 0.8 を下回ることが確認されています。

構成 アプリケーション ノード データベース ノード 1 時間あたりのコスト Apdex (Confluence バージョンごと)
6.13 6.15
低コスト c5.4xlarge x 3 m4.2xlarge 2.77 0.811 0.825

インスタンスの詳細: 


テストの詳細

テスト データを参照すると、アトラシアンでのテストの実行方法と測定内容についてより詳細に確認できます。

最終更新日 2019 年 8 月 22 日

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

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