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

このページの内容:

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

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

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


エグゼクティブ サマリー

Medium

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

パフォーマンス

c5.xlarge x 2

m4.large

$0.522

0.929

安定性

c5.large x 4

m4.large

$0.522

0.905


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

安定性オプションは、同じコストでより優れたフォールト トレランスを提供しますが、パフォーマンスはわずかに低下します。

Confluence はすべてのテストで、0.90 を超える Apdex を示しました。

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


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

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


XLarge

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

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

安定性構成と低コスト構成は、ノードの数以外は同じです。これらの Apdex スコアもほとんど変わりません。低コスト構成は、3 つのノードが失われるまでサービスがオフラインにならないため、非常にフォールト トレラントです。ただし、アトラシアンのテストでは、低コスト構成でノードが 1 つ失われると、Apdex が 0.8 を下回ることが確認されています。

重要な注意事項

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



アプローチ

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

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

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

考慮事項

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

  • コア製品に最適な設定を見つけることに焦点を当てていたため、テスト インスタンスへのアプリのインストールは行っていません。お客様のインフラストラクチャを設計する際には、インストールしたいアプリがパフォーマンスに与える影響を考慮する必要があります。
  • すべてのテストにおいて、Postgresql 9.4.15 を既定の AWS RDS 設定で使用しました。これにより、最小限のセットアップと調整で一貫した結果を実現できます。
  • アトラシアンのテスト環境では、同じサブネット上でホストされている専用の AWS インフラストラクチャを使用しています。これによりネットワーク遅延を短縮できます。
  • Confluence Data Center 6.14 で "Large" サイズのデータ セット、6.15 で "XLarge" サイズのデータ セットをテストしました。これは、リリースのタイミングによるものです。6.14 は "Large" サイズをテストした時点での最新リリースであり、"XLarge" サイズをテストした時点では 6.15 がリリースされていました。さらに、両方のデータ セットを最新の Confluence エンタープライズ リリース (6.13) でテストしました。"Medium" データ セットは Confluence 6.13 でテストされました。

分析

各テスト インスタンスで分析を有効化し、使用状況データを収集しました。詳細については、データ収集ポリシーを参照してください。

分析がパフォーマンスに大きな影響を与えるかどうかについてもテストしました (大きな影響はありませんでした)

分析を有効にした場合のパフォーマンスへの影響を確認するため、個別のテストを実行しました。これを行うため、同一の Confluence Data Center インスタンス 2 つで本番環境の負荷のシミュレーションを実施しました。同じ "Large" サイズのデータ セットで両方のインスタンスを読み込み、両方で同じ量のトラフィックを実行しました。唯一の違いとして、一方でのみ分析を有効にしました。

次のグラフは、分析を有効にした場合 (ベースライン - 左) と無効にした場合 (テスト - 右) の主要な操作の箱ひげ図を示しています。

全体として、応答時間に軽微な違いが見られました。

ディスク I/O に関する考慮事項

データ セットには一定量の添付ファイルが含まれていたため、(一般的な本番環境インスタンスと比較して) ほとんどが書き込み操作で構成されるトラフィックが発生しました。このトラフィックにより、読み取り速度と書き込み速度はそれぞれ平均で 1 kbps および 2,500 kbps になりました。これは大まかに、それぞれ平均で 0.15、 200 の読み取り IOPS および書き込み IOPS に相当します。

ディスク I/O を特にテストするための設定は行っていませんが、これらの結果により、負荷に対する共有ホーム構成 (1 つの m4.large ノードが gp2 上で NFS を実行) が十分であったことがわかります。テスト全体を通じてディスク負荷は安定しており、NFS サーバーへの過剰な負荷はありませんでした。

ここで使用した合成トラフィックは、ほとんどが書き込みトラフィックであることにご注意ください。これは一般的な本番環境インスタンスを表しているわけではありません。一般的な本番環境では、読み取りトラフィックの割合が高くなります。

テスト手法

"Medium" サイズ、"Large" サイズ、および "XLarge" サイズ用に、個別のテスト フェーズを実行しました。各フェーズでは同じ Confluence データ セットへの特定の量のトラフィックを、新しくプロビジョニングされた AWS 環境でテストしました。各環境は、アプリケーション ノードとデータベース ノードの構成を除いてまったく同じにしました。

テストの目的は、"Medium" サイズ、”Large" サイズおよび "XLarge" サイズのプロファイルでの異なる構成をベンチマークに従って評価することでした。特に、異なるタイプの AWS 仮想マシンがインスタンスのパフォーマンスに与える影響について分析しました。 

ベンチマーク

"Medium" サイズ、"Large" サイズ、および "XLarge" サイズのプロファイルのすべてのテストで、許容可能なパフォーマンスのしきい値として Apdex  のスコア 0.8 を使用しました。この Apdex では、1-秒の応答時間が許容可能なしきい値であるのに対し、4 秒を超える場合はすべて不満を表すしきい値とみなします。

比較のため、内部の本番環境用 Confluence Data Center インスタンスではターゲットとなる Apdex を 0.7 に設定しました (「Confluence Data Center のサンプル デプロイメントおよび監視戦略」を参照)。0.7 の Apdex は対象ののインスタンスでアプリがパフォーマンスに与える影響を考慮したものでした。テスト インスタンスではアプリをインストールしていなかったため、テストのターゲット Apdex を 0.8 に調整しました。 


各テストでの全体的な Apdex の計算方法については、こちらをクリックしてください

Apdex (Application Performance Index) は、多くの企業がアプリケーションのパフォーマンスのレポート、ベンチマーク、および追跡に使用する一般的な基準です。詳細は、 http://apdex.org/overview.html を参照してください。


全体的な Apdex を計算するには、まず応答時間に基づいて Apdex を各ユーザーに割り当てる必要があります。

応答時間 Apdex リクエスト
1 秒未満 1
1-4 秒 0.5
4 秒以上 0


次に、アクションのタイプに基づき、そのアクションの Apdex に重み付けを適用します。この重み付けは、アクションのスコアが全体的な Apdex に与える影響の大きさを表しています。 

ユーザー アクションのタイプ 重み (%)
confluence.page.view 84
confluence.blogpost.view 1
confluence.dashboard.view 6
confluence.page.create.collaborative.view 2
confluence.page.edit.collaborative.view 5
confluence.page.edit.collaborative.quick-view 2

使用状況に関する統計が多数の Confluence ユーザーから提供され、上位 1,000 件のトラフィック ボリュームを持つインスタンスに基づいて重み付けを設定しました。これらのインスタンスでは、ページ ビュー (confluence.page.view) がユーザー アクションの大部分を占めます。

つまり、シミュレートされるそれぞれのユーザー アクションでのスコアは以下のとおりです。

(Apdex) x (ページ アクション タイプあたりの重み) = 重み付けされた Apdex

例えば、confluence.page.edit.collaborative.view の完了に 2 秒かかる場合、以下に基づいて 0.025 と重み付けした Apdex が得られます。

0.5 x 0.05 = 0.025

最後に、全体的な Apdex を取得するには、すべてのユーザー アクションに対して重み付けされた Apdex を加算します。 

アーキテクチャ

アーキテクチャの詳細

"Medium"、"Large"、および "XLarge" のデータ セットをテストするために、同じ基本アーキテクチャを使用しました。

 

各構成は、AWS 上に新しくデプロイされた Confluence Data Center インスタンスでテストされました。各構成は次の共通の基本構造にしたがっています。

機能 ノードの数 仮想マシンのタイプ 注意
Confluence アプリケーション 変数

c5.large (Medium)

c5.xlarge

c5.2xlarge

c5.4xlarge

c4.8xlarge

各テストでは、Confluence アプリケーションと Synchrony の両方のノードで同じ仮想マシン タイプを使用しました。Confluence アプリケーションにはさまざまな数のノードを使用しましたが、Synchrony のノードは常に 1 つにしました。

c5.xlarge (RAM が 8 GB) をテストする際は、JVM ヒープに 4 GB を使用しました。それ以外の場合は、8 GB を使用していました。

Medium インスタンス (4 GB RAM) で c5.large をテストする際は、JVM ヒープに 2 GB を使用しました。それ以外の場合は、4 GB を使用しました。

Synchrony  1
データベース 1

m4.xlarge
m4.2xlarge
m4.4xlarge

Amazon RDS Postgresql バージョン 9.4.15 を既定設定で使用しました。各テストは 1 つのノードのみを対象としました。
共有ホーム 1

m4.large

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

各 Confluence アプリケーションおよび Synchrony ノードでは、ローカル ストレージに 50 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 150 IOPS で、3,000 IOPS まで拡張可能です。 

テストに使用した各仮想マシン タイプの詳細については、インスタンス タイプに関する AWS ドキュメントの「汎用インスタンス」、および「コンピュート最適化インスタンス」をご参照ください。

"Medium" サイズのインスタンスの推奨設定

以下の表は、"Medium" サイズのインスタンスのパフォーマンス テストで使用したデータ セットとトラフィックを示しています。

負荷プロファイル メトリック

合計スペース数

1,700

サイトのスペース

1600

コンテンツ (すべてのバージョン)

1,520, 000

ローカル ユーザー

9,800

トラフィック (1 時間あたりの HTTP リクエスト)

180,000

その他のデータ セットとトラフィックの詳細はこちらをクリック

"Medium" の標準サイズ

Confluence Data Center 負荷プロファイル」に基づき、"Medium" サイズのインスタンスは各メトリックの次の範囲内にあてはまります。

  • 合計スペース数: 1,000 ~ 2,500

  • コンテンツ (全バージョン): 500,000 ~ 2,500 万

  • ローカル ユーザー: 1,000 ~ 10,000

  • 1 時間あたりの HTTP 呼び出し: 70,000 ~ 350,000 p/h

テスト データセットとトラフィックの内訳

"Mediume" データ セットに使用したメトリックは「Confluence Data Center 負荷プロファイル」に基づき、インスタンスの全体的な負荷プロファイルを "Medium の上限に近い範囲に含めるようにしています。これらのメトリックは、実際に使用されている "Medium" サイズの Confluence Data Center インスタンスを表すことを意図しています。

 メトリック

合計

コンポーネント

値 (概数)

合計スペース数


1700

サイト スペース

1600


パーソナル スペース 100

コンテンツ (すべてのバージョン)

1,520, 000

コンテンツ (現在のバージョン)

1,490, 000

コメント 30,000

ローカル ユーザー

9,800


アクティブ ユーザー数: 94

トラフィック (HTTP リクエスト)

180,000 / 時間


~ 1915 件の HTTP リクエスト / 時間 / ユーザー

tip/resting Created with Sketch.

考慮事項

  • コンテンツ (すべてのバージョン) は、インスタンス内のすべてのページ、ブログ投稿、コメント、およびファイルのすべてのバージョンの総数です。これは、Confluence データベースの CONTENT テーブルの行の総数です。

  • コンテンツ (現在のバージョン) は、インスタンス内のページ、ブログ投稿、コメント、およびファイルの総数です。これには、ページ、ブログ投稿、またはファイルの過去のバージョンは含まれません。

  • ローカル ユーザーは、ローカルおよびデータベースに同期されているリモート ディレクトリのユーザー アカウントの数です。これには、アクティブなアカウントと非アクティブなアカウントとの両方が含まれています。

  • アクティブ ユーザーは、各テストの実行中にログインしたすべてのローカル ユーザーの数です。すべての HTTP リクエストは、すべてのアクティブ ユーザーのサブセットによって発行されました。

アトラシアンでは "Medium" テスト フェーズのベンチマークと構成を分析し、以下の推奨設定を導きました。

アドバイス

アプリケーション ノード

データベース ノード

Apdex (6.13)

1 時間あたりのコスト1

パフォーマンス

c5.xlarge x 2

m4.large

0.929

$0.522

安定性

c5.large x 4

m4.large

0.905

$0.522

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

安定性オプションは、同じコストでより優れたフォールト トレランスを提供しますが、パフォーマンスはわずかに低下します。

Confluence はすべてのテストで、0.90 を超える Apdex を示しました。

1 時間あたりのコスト

1 "Medium" サイズ プロファイルの推奨設定では、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Confluence アプリケーションとデータベースに使用したノードの価格のみを計算します。その他のコンポーネント (Synchrony、共有ホーム、アプリケーション ロード バランサ) の使用コストは含まれません。

これらの図は、米国東部でのデプロイに対する USD の金額で、2019 年 4 月時点の値です。

"Medium" テスト: 結果と分析

Confluence のアプリケーション ノードに最適な構成を判断するため、1 つのタイプのテストを実行しました。テストでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。これらのテストでは、データベースに 1 つの m4.xlarge ノードを使用しました。


アプリケーション ノードのテスト結果

最初に、アプリケーション ノード用の異なる仮想マシン タイプを、それぞれのデータベース用の 1 つの m4.6xlarge ノードに対してテストしました。これらのテストは、テストの実施時点で利用可能な最新バージョンであった Confluence 6.13 で実行しました。

次のグラフは、1 つの m4.xlarge ノードに対する、アプリケーション ノード用の異なる仮想マシン タイプでの Apdex ベンチマークを示しています。

最初に、アプリケーション ノード用の異なる仮想マシン タイプを、それぞれのデータベース用の 1 つの m4.6xlarge ノードに対してテストしました。これらのテストは、テストの実施時点で利用可能な最新バージョンであった Confluence 6.13 で実行しました。

次のグラフは、1 つの m4.xlarge ノードに対する、アプリケーション ノード用の異なる仮想マシン タイプでの Apdex ベンチマークを示しています。


これらの結果は、c5.xlarge (4 CPU) 以上のインスタンス サイズで最高のパフォーマンスが得られたことを示しています。グラフに示すように、より性能の良いハードウェアを使用しても、それ以上の Apdex の改善はありませんでした。つまり、Apdex は c5.2xlarge (8 CPU)、および c5.4xlarge (16 CPU) で同じです。

このため、最高のパフォーマンスを実現するには c5.2xlarge を 2 ノード、優れたフォールト トレランスには c5.large を 4 ノード使用することをおすすめします。

データベース ノードのテスト結果
データベース ノード

アプリケーション ノードのテスト結果は、c5.xlarge ノード 2 つ、または c5.xlarge ノード 4 つの構成で、許容可能な Apdex 結果が得られることを示しました。この情報を使用して次のテスト段階に移行し、データベース ノードに最適な構成をテストしました。これらのテストは Confluence 6.13 で実行しました。

データベース ノードの次の仮想マシン タイプに対して、最高のパフォーマンスを示す Confluence アプリケーション ノード構成のベンチマーク評価を行いました。

  • m4.large

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge

次のグラフは、各仮想マシン タイプをデータベース ノードとして実行した場合のパフォーマンスを示します。

より大きなデータベースを使用しても、それ以上のパフォーマンスの向上はありませんでした。そのため、"Medium" サイズの負荷には、m4.large インスタンス タイプをおすすめします。

"Large" サイズのインスタンスの推奨設定

以下の表は、"Large" サイズのインスタンスのパフォーマンス テストで使用したデータ セットとトラフィックを示しています。

負荷プロファイル メトリック
合計スペース数 6,550
コンテンツ (すべてのバージョン) 16,000, 000
ローカル ユーザー 12,300
トラフィック (1 時間あたりの HTTP リクエスト) 498,000
その他のデータ セットとトラフィックの詳細はこちらをクリック

"Large" の標準サイズ

Confluence Data Center 負荷プロファイル」に基づき、"Large" サイズのインスタンスは各メトリックの次の範囲内にあてはまります。

  • 合計スペース数: 2,500 ~ 5,000
  • コンテンツ (すべてのバージョン): 250 万~ 1000 万
  • ローカル ユーザー: 10,000 ~ 100,000
  • 1 時間あたりの HTTP 呼び出し: 350,000 ~ 700,000 p/h


"Large" データ セットに使用したメトリックは「Confluence Data Center 負荷プロファイル」に基づき、インスタンスの全体的な負荷プロファイルを "Large" の上限に近い範囲に含めるようにしています。これらのメトリックは、実際に使用されている "Large" サイズの Confluence Data Center インスタンスを表すことを意図しています。

メトリック 合計 コンポーネント 値 (概数)
合計スペース数 6,550 サイトのスペース 1,500
パーソナル スペース 5,000
コンテンツ (すべてのバージョン) 16,000, 000 コンテンツ (現在のバージョン) 6,900, 000
コメント 2,000, 000
ローカル ユーザー 12,300 アクティブ ユーザー数 565
トラフィック (HTTP リクエスト) 498,000 / 時間 N/A

データセットでは、9,900 のローカル グループも使用します。


tip/resting Created with Sketch.

考慮事項

  • コンテンツ (すべてのバージョン) は、インスタンス内のすべてのページ、ブログ投稿、コメント、およびファイルのすべてのバージョンの総数です。これは、Confluence データベースの CONTENT テーブルの行の総数です。

  • コンテンツ (現在のバージョン) は、インスタンス内のページ、ブログ投稿、コメント、およびファイルの総数です。これには、ページ、ブログ投稿、またはファイルの過去のバージョンは含まれません。

  • ローカル ユーザーは、データベースと同期されているローカルおよびリモート ディレクトリのユーザー アカウントの数です。これには、アクティブなアカウントと非アクティブなアカウントとの両方が含まれています。

  • アクティブ ユーザーは、各テストの実行中にログインしたすべてのローカル ユーザーの数です。すべての HTTP リクエストは、すべてのアクティブ ユーザーのサブセットによって発行されました。


アトラシアンでは "Large" テスト フェーズのベンチマークと構成を分析し、以下の推奨設定を導きました。

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


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

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

1 時間あたりのコスト

1 "Large" と "XLarge" の両方のサイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Confluence アプリケーションとデータベースに使用したノードの価格のみを計算します。その他のコンポーネント (Synchrony、共有ホーム、またはアプリケーション ロード バランサ) の使用コストは含まれません。

これらの図は、米国東部でのデプロイに対する USD の金額で、2019 年 4 月時点の値です。

"Large" テスト: 結果と分析

2 種類のテストを実施し、Confluence アプリケーション ノードに最適な構成とデータベース ノードに最適な構成の推奨設定を導きました。

  1. 最初のテスト タイプでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。これらのテストでは、データベースに 1 つの m4.xlarge ノードを使用しました。
  2. 2 番目のテストでは、データベース用の異なる仮想マシン タイプのベンチマークを評価しました。ここでは、2 つのアプリケーション ノード構成 (c5.4xlarge ノード 2 つと c5.2xlarge ノード 4 つ) に対して異なる仮想マシン タイプをテストしました。これらのアプリケーション ノード構成では、過去のテストと比較して最高の Apdex スコアが得られました。これらの一連のテストでも、1 つのデータベース ノードのみを使用しました。


これらのテスト結果の詳細についてはここをクリックしてください

アプリケーション ノードのテスト結果

最初に、アプリケーション ノード用の異なる仮想マシン タイプを、それぞれのデータベース用の 1 つの m4.xlarge ノードに対してテストしました。これらのテストは、テストの実施時点で利用可能な最新バージョンであった Confluence 6.14 で実行しました。

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

これらの結果は、c5.4xlarge ノードで最高のパフォーマンスが得られたことを示しています。高可用性を確保するには 2 つ以上のノードが必要で、テストでのノード数に関わらず、Apdex のパフォーマンスは他よりも高くなっています。これらの各ノードは 32 GB RAM を持つ CPU を 16 個搭載しています。

3 つ以上の c5.2xlarge ノードを使用しても、Apdex は引き続き許容可能な値を示しました。4 ノードを超えると、パフォーマンスに大きな変化はありませんでした。信頼性とフォールト トレランスのために 2 つ以上のノードを使用したい場合、これらは考慮する価値があります。4 つの c5.2xlarge ノードの 1 時間あたりのコスト 1 は、2 つの c5.4xlarge ノードの場合とほぼ同じです。

データベース ノードのテスト結果

アプリケーション ノードのテスト結果は、c5.4xlarge ノード 2 つ、または c5.2xlarge ノード 4 つの構成で、許容可能な Apdex 結果が得られることを示しました。この情報を使用して次のテスト段階に移行し、データベース ノードに最適な構成をテストしました。これらのテストも Confluence 6.14 で実行し、データベース ノードの次の仮想マシン タイプに対して、最高のパフォーマンスを示す Confluence アプリケーション ノード構成のベンチマークを評価しました。 

  • m4.large
  • m4.xlarge
  • m4.2xlarge
  • m4.4xlarge

次のグラフは、各仮想マシン タイプをデータベース ノードとして実行した場合のパフォーマンスを示します。

データベースに db.m4.large、アプリケーションに 4 つの c5.2xlargeを使用すると、Apdex がしきい値である 0.8 を下回りました。すべてのテストを通じ、アプリケーションに 2 つの c5.4xlargeノードを使用した場合に優れたパフォーマンスを得ることができました。 

データベースに m4.2xlarge ノードを使用することで、両方のアプリケーション ノード構成で最高のパフォーマンスを実現できました。興味深いことに、m4.4xlarge を使用すると、パフォーマンスがわずかに劣化しました。これにより、"Large" サイズの負荷の場合、m4.2xlarge より強力な仮想マシン タイプを使用してもパフォーマンスは改善されないことがわかりました。


Confluence 6.14 でのテスト結果の概要

アプリケーション ノード テストのベンチマークは、Confluence のパフォーマンスについては、垂直方向の拡張が水平方向の拡張よりも効果的であることを示しています。つまり、性能の低いハードウェアで多数のノードを確保するよりも、性能が高いハードウェアでノード数が少ない場合のほうが、高いパフォーマンスが得られます。

以下の表は、Confluence Data Center 6.14 で Apdex が 0.8 以上になるすべての構成に関する情報を示しています。 

アプリケーション ノード データベース ノード Apdex 1 時間あたりのコスト1 
c5.4xlarge x 2 m4.2xlarge 0.874 2.09
c5.4xlarge x 3 m4.xlarge 0.863 2.40
c5.4xlarge x 2 m4.xlarge 0.856 1.72
c5.2xlarge x 4 m4.2xlarge 0.855 2.09
c5.2xlarge x 3 m4.xlarge 0.834 1.38
c5.2xlarge x 4 m4.xlarge 0.837 1.72


この表で、6.14 で最高のパフォーマンス、最高のコスト、および最低のコストを実現する構成を確認することができます。

構成 アプリケーション ノード データベース ノード Apdex 1 時間あたりのコスト1
パフォーマンス c5.4xlarge x 2 m4.2xlarge 0.874 2.09
安定性 c5.2xlarge x 4 m4.xlarge 0.837 1.72
低コスト c5.2xlarge x 3 m4.xlarge 0.834 1.38

ここに安定性構成を含めたのは、安定性構成はパフォーマンス オプションと低コスト オプションの両方よりもフォールト トレラントに焦点を当てているためです。安定性構成では 4 つのアプリケーション ノードが失われるまでサービスがオフラインになりません (パフォーマンスおよび低コスト オプションの場合、それぞれ 2 つおよび 3 つでオフラインになります)。また、テストでは、低コスト構成でノードが 1 つ失われると、Apdex が 0.8 を下回りました。安定性構成では、管理者はノードの損失の対応により多くの時間をかけることができます。 

構成を選択する際は、ノードがオフラインになった際のパフォーマンスについても考慮する必要があります。アトラシアンのテストでは、パフォーマンス オプションでノードが 1 つのみになっても、Apdex は 0.8 を超える値を維持しました。ただし、低コスト オプションの Apdex は、1 つのノードが失われただけで 0.8 を下回る結果になりました。

安定性オプションでは、1 つのノードが失われても 0.8 以上を維持することができます。

Confluence 6.13 (エンタープライズ リリース) の結果の検証

Confluence Data Center 6.14 のパフォーマンス安定性、および低コスト構成を再テストし、6.13 でも有効かどうかを確認しました。以下の表は、これらのテストの結果を示しています。

構成 アプリケーション ノード データベース ノード 1 時間あたりのコスト1 Apdex (Confluence バージョンごと)
6.13 6.14

パフォーマンス

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

パフォーマンス

c5.4xlarge x 2 m4.2xlarge 2.09 0.852 0.874
安定性 c5.2xlarge x 4 m4.xlarge 1.72 0.817 0.837
低コスト c5.2xlarge x 3 m4.xlarge 1.38 0.820 0.834

安定性オプションと低コスト オプションは、同様のパフォーマンスを示しています。つまり、これら 2 つのオプションでは、価格がフォールト トレランスの主なトレードオフとなります。ほかと同様、これら 3 つの推奨設定のうち、価格と Apdex が最も高いのはパフォーマンス オプションです。  

"XLarge" サイズのインスタンスの推奨設定

以下の表は、"XLarge" サイズのインスタンスのパフォーマンス テストで使用したデータ セットとトラフィックを示しています。

負荷プロファイル メトリック
合計スペース数 10,500
コンテンツ (すべてのバージョン) 34,900, 000
ローカル ユーザー 102,000
トラフィック (1 時間あたりの HTTP リクエスト) 1,000, 000
その他のデータ セットとトラフィックの詳細はこちらをクリック

"XLarge" の標準サイズ

Confluence Data Center 負荷プロファイル」に基づき、"XLarge" サイズのインスタンスは各メトリックの次の範囲内にあてはまります。

  • 合計スペース数: 5,000 ~ 50,000
  • コンテンツ (すべてのバージョン): 1000 万~ 2500 万
  • ローカル ユーザー: 100,000 ~ 250,000
  • 1 時間あたりの HTTP 呼び出し: 700,000 ~ 1,000,000

テスト データセットとトラフィックの内訳

"XLarge" データ セットでは、インスタンスの全体的な負荷は "XLarge" の下限に近い範囲になります。これらのメトリックは、実際に使用されている "XLarge" サイズの Confluence Data Center インスタンスを表すことを意図しています。

メトリック 合計 コンポーネント 値 (概数)
合計スペース数 10,500 サイトのスペース 5,800
パーソナル スペース 5,000
コンテンツ (すべてのバージョン) 34,900, 000 コンテンツ (現在のバージョン) 26,600, 000
コメント 15,800, 000
ローカル ユーザー 102,000 アクティブ ユーザー数 1,200
トラフィック (HTTP リクエスト) 1,000,000/時間 読み取り (kbps) 1
書き込み (kbps) 5,500

データセットでは、9,900 のローカル グループも使用します。 


tip/resting Created with Sketch.

考慮事項

  • コンテンツ (すべてのバージョン) は、インスタンス内のすべてのページ、ブログ投稿、コメント、およびファイルのすべてのバージョンの総数です。これは、Confluence データベースの CONTENT テーブルの行の総数です。

  • コンテンツ (現在のバージョン) は、インスタンス内のページ、ブログ投稿、コメント、およびファイルの総数です。これには、ページ、ブログ投稿、またはファイルの過去のバージョンは含まれません。

  • ローカル ユーザーは、データベースと同期されているローカルおよびリモート ディレクトリのユーザー アカウントの数です。これには、アクティブなアカウントと非アクティブなアカウントとの両方が含まれています。

  • アクティブ ユーザーは、各テストの実行中にログインしたすべてのローカル ユーザーの数です。すべての HTTP リクエストは、すべてのアクティブ ユーザーのサブセットによって発行されました。


アトラシアンでは "XLarge" テスト フェーズのベンチマークと構成を分析し、以下の推奨設定を導きました。

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

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

安定性構成と低コスト構成は、ノードの数以外は同じです。これらの Apdex スコアもほとんど変わりません。低コスト構成は、3 つのノードが失われるまでサービスがオフラインにならないため、非常にフォールト トレラントです。ただし、アトラシアンのテストでは、低コスト構成でノードが 1 つ失われると、Apdex が 0.8 を下回ることが確認されています。

"XLarge" テスト: 結果と分析

"XLarge" テストでは最初に、アプリケーション ノード用の異なる仮想マシン タイプを、それぞれのデータベースの 1 つの m4.2xlarge ノードに対してテストしました。これらのテストは、その時点で利用可能な最新バージョンであった Confluence 6.15 で実行しました。

最高のパフォーマンスを実現する構成を確認した後、それを Confluence 6.13 で再度テストしました。

これらのテスト結果の詳細についてはここをクリックしてください

アプリケーション ノードのテスト結果

最初に、アプリケーション ノード用の異なる仮想マシン タイプを、それぞれのデータベース用の 1 つの m4.xlarge ノードに対してテストしました。これらのテストは、その時点で利用可能な最新バージョンであった Confluence 6.15で実行しました。

ただし、これらのうち、Apdex スコアが 0.8 を上回ったものはありませんでした。以下のグラフは、データベースに m4.2xlarge を使用して同じテストを実行したときの、実際の Apdex のベンチマークを示しています。


アプリケーション ノードでテストした仮想マシン タイプの中で、Apdex が 0.8 を上回ったのは c5.4xlarge のみでした。この仮想マシン タイプを 3 ノードまたは 4 ノードにすることで実現しました。2 ノードに減らすと、Apdex 0.8 を下回りました。

データベース ノードのテスト結果

また、データベース ノードに m4.4xlarge を使用し、アプリケーション ノードに別の仮想マシン インスタンスを使用する組み合わせも試しましたが、Apdex に大きな改善は見られませんでした。

実際の例

これらの推奨設定の実際のアプリケーションを確認したい場合は、次のリソースを確認してください。

いずれも、AWS でホストされている "Large" サイズの Confluence Data Center インスタンスです。また、最も低コストのノード構成の仮想マシン タイプを使用しています。ただし、フォールト トレランスを向上させるため、アプリケーション ノードを 4 つ使用しています。アトラシアンの本番環境 Confluence インスタンスでは、全体的な負荷やインストール済みアプリを考慮したうえでも、この構成でユーザーが許容可能なパフォーマンスを実現できています。

Atlassian が提供するサービス

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

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


最終更新日 2019 年 5 月 21 日

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

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