Infrastructure recommendations for enterprise Confluence instances on AWS

このページの内容:

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

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

To help you plan your infrastructure set-up or growth, we ran a series of performance tests on typical Medium, Large, and XLarge Confluence instances. We designed these tests to get useful, data-driven recommendations for your deployment's application and database nodes. These recommendations can help you plan a suitable environment, or even check whether your current instance is adequate for the size of your content and traffic.


Executive summary

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


The Performance option offers the best Apdex among all the configurations we tested. It can maintain an Apdex above 0.9 even when it loses one node.

The Stability option offers better fault tolerance at the same cost, but there is a slight drop in performance.

Confluence performed well in all tests, demonstrating Apdex of above 0.90.

アドバイス アプリケーションノード データベース ノード 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


The Performance option offered the best Apdex among all the configurations we tested. It can maintain an Apdex above 0.8 even when it loses one node.

安定性オプションと低コスト オプションは、価格、フォールト トレランス、およびパフォーマンスのバランスが取れたオプションです。これらは両方とも同じ仮想マシン タイプを使用しています。安定性オプションの場合、追加アプリケーション ノードが 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

The Stability configuration can maintain acceptable performance (that is, Apdex above 0.8) even if it lost one application node. At four application nodes, it is more fault tolerant overall than the Low cost configuration.

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

Important note

Performance results depend on many factors such as 3rd party apps, data, traffic or the instance type. Hence, the performance we achieved might not be replicable to your environment. Make sure you read through the methodology of our test to learn the details of these recommendations.



アプローチ

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

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

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

考慮事項

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

  • コア製品に最適な設定を見つけることに焦点を当てていたため、テスト インスタンスへのアプリのインストールは行っていません。お客様のインフラストラクチャを設計する際には、インストールしたいアプリがパフォーマンスに与える影響を考慮する必要があります。
  • We used Postgresql 9.4.15 with default AWS RDS settings across all our tests. This allowed us to get consistent results with minimal setup and tuning.
  • アトラシアンのテスト環境では、同じサブネット上でホストされている専用の AWS インフラストラクチャを使用しています。これによりネットワーク遅延を短縮できます。
  • We tested a Large data set on Confluence Data Center 6.14, and XLarge on 6.15. This was a result of release timing: 6.14 was the latest available release when we tested for Large, and 6.15 was available when we tested XLarge. On top of that, we tested both data sets against the latest Confluence Enterprise release (namely, 6.13). The Medium data set was tested on 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 サーバーへの過剰な負荷はありませんでした。

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

テスト手法

We ran three separate test phases: one for Medium, one for Large, and another for XLarge. Each phase involved testing a specific volume of traffic to the same Confluence data set, but on a freshly provisioned AWS environment. Each environment was exactly like the last, except for the configuration of application and database nodes.

Our objective was to benchmark different configurations for Medium,  Large, and XLarge size profiles. Specifically, we analyzed how different AWS virtual machine types affected the performance of the instance. 

ベンチマーク

For all tests in Medium,  Large, and XLarge size profiles, we used an Apdex of 0.8 as our threshold for acceptable performance. This Apdex assumes that a 1-second response time is our Tolerating threshold, while anything above 4 seconds is our Frustrated threshold.

比較のため、内部の本番環境用 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 を加算します。 

アーキテクチャ

Architecture details

We used the same basic architecture to test Medium, Large, and XLarge data sets:

 

各構成は、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 を使用していました。

When testing c5.large for Medium instances (which only has 4GB of RAM), we used 2GB for JVM heap. For all others, we used 4GB.

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 ドキュメントの「汎用インスタンス」、および「コンピュート最適化インスタンス」をご参照ください。

Recommendations for Medium-sized instances

The following table shows the data set and traffic we used on our performance tests for Medium-size instances:

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

合計スペース数

1,700

サイトのスペース

1600

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

1,520, 000

ローカル ユーザー

9,800

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

180,000

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

Standard size for Medium

According to Confluence Data Center load profiles, a Medium-sized instance falls within the following range for each metric:

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

  • Content (all versions): 500,000 to 2.5 million

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

  • HTTP calls per hour: 70,000 to 350,000 p/h

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

The metrics we used for our Medium data set are based on Confluence Data Center load profiles, which put the overall load profile of the instance in the middle range of Medium. We believe that these metrics represent a majority of real-life, Medium-sized Confluence Data Center instances.

 メトリック

合計

コンポーネント

値 (概数)

合計スペース数


1700

サイト スペース

1600


パーソナル スペース 100

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

1,520, 000

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

1,490, 000

コメント 30,000

ローカル ユーザー

9,800


Active users: 94

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

180,000 / 時間


~ 1915 HTTP requests per hour, per user

tip/resting Created with Sketch.

考慮事項

  • Content (all versions) is the total number of all versions of all pages, blog posts, comments, and files in the instance. It's the total number of rows in the CONTENT table in the Confluence database.

  • Content (current versions) is the number of pages, blog posts, comments, and files in the instance. It doesn't include historical versions of pages, blog posts, or files.

  • Local Users is the number of user accounts from local and remote directories that have been synced to the database. It includes both active and inactive accounts.

  • Active Users is the number of all Local Users logged in during each test. All HTTP requests were issued by a subset of all active users.

We analyzed the benchmarks and configurations from our Medium testing phase and came up with the following recommendations:

アドバイス

アプリケーションノード

データベース ノード

Apdex (6.13)

Cost per hour 1

パフォーマンス

c5.xlarge x 2

m4.large

0.929

$0.522

安定性

c5.large x 4

m4.large

0.905

$0.522

The Performance option offers the best Apdex among all the configurations we tested. It can maintain an Apdex above 0.9 even when it loses one node.

The Stability option offers better fault tolerance at the same cost, but there is a slight drop in performance.

Confluence performed well in all tests, demonstrating Apdex of above 0.90.

1 時間あたりのコスト

1 In our recommendations for Medium size profiles, we quoted a cost per hour for each configuration. We provide this information help inform you about the comparative price of each configuration. This cost only calculates the price of the nodes used for the Confluence application and database. It does not include the cost of using other components like Synchrony, shared home, or application load balancer.

These figures are in USD for deployments in US-EAST, and were correct as of April 2019.

Medium tests: results and analysis

We ran one type of tests to determine optimal configurations for the Confluence application node. The tests sought to find out which AWS virtual machine types to use (and how many) for the application node. For these tests, we used a single m4.xlarge node for the database.


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

We first tested different virtual machine types for the application node against a single m4.xlarge node for the database in each.We ran these tests on Confluence 6.13, which was the latest Enterprise release version available at the time of our tests.

The following graph shows the Apdex benchmarks at different virtual machine types for the application node against a single m4.xlarge node:

We first tested different virtual machine types for the application node against a single m4.xlarge node for the database in each.We ran these tests on Confluence 6.13, which was the latest Enterprise release version available at the time of our tests.

The following graph shows the Apdex benchmarks at different virtual machine types for the application node against a single m4.xlarge node:


These results show that the best performance came from instance sizes which are equal to or higher than c5.xlarge (4 CPUs). As shown in the graph, there were no further Apdex improvements in using stronger hardware. That is, Apdex remained the same for c5.2xlarge (8 CPUs) and c5.4xlarge (16 CPUs).

For this reason, we recommend c5.2xlarge 2 nodes for best performance or c5.large 4 nodes for better fault tolerance.

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

The application node tests showed that using two c5.xlarge nodes or four c5.large nodes provided acceptable Apdex results. Using this information, we moved on to the next series of tests – testing optimal configurations for the database node. We ran these tests on Confluence 6.13.

We benchmarked the best-performing Confluence application node configurations against the following virtual machine types for the database node:

  • m4.large

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge

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

There were no further performance improvements when we used a larger database. Thus, for medium-sized load, m4.large is the instance type we recommend.

"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


The metrics we used for our Large data set are based on Confluence Data Center load profiles, which put the overall load profile of the instance at the upper range of Large. We believe that these metrics represent a majority of real-life, Large-sized Confluence Data Center instances.

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

データセットでは、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


The Performance option offered the best Apdex among all the configurations we tested. It can maintain an Apdex above 0.8 even when it loses one node.

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

1 時間あたりのコスト

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

These figures are in USD for deployments in US-EAST, and were correct as of April 2019.

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

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

  1. Our first test type sought to find out which AWS virtual machine types to use (and how many) for the application node. For these tests, we used a single m4.xlarge node for the database.
  2. 2 番目のテストでは、データベース用の異なる仮想マシン タイプのベンチマークを評価しました。ここでは、2 つのアプリケーション ノード構成 (c5.4xlarge ノード 2 つと c5.2xlarge ノード 4 つ) に対して異なる仮想マシン タイプをテストしました。これらのアプリケーション ノード構成では、過去のテストと比較して最高の Apdex スコアが得られました。これらの一連のテストでも、1 つのデータベース ノードのみを使用しました。


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

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

We first tested different virtual machine types for the application node against a single m4.xlarge node for the database in each. We ran these tests on Confluence 6.14, which was the latest version available at the time of our tests.

次のグラフは、各テストでの実際の 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

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

Using m4.large for the database and four c5.2xlarge nodes for the application yielded results below our Apdex threshold of 0.8. Throughout all tests, using two c5.4xlarge nodes for the application showed better performance. 

Using the m4.2xlarge node for the database provided the best performance on both application node configurations. Interestingly, using m4.4xlarge showed a slight regression in performance. This shows that for our Large-sized load, using virtual machine types more powerful than m4.2xlarge yielded no performance improvement.


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

The Stability configuration can maintain acceptable performance (that is, Apdex above 0.8) even if it lost one application node. At four application nodes, it is more fault tolerant overall than the Low cost configuration.

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

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

For our XLarge tests, we first tested different virtual machine types for the application node against a single m4.2xlarge node for the database in each. We ran these tests on Confluence 6.15, which was the latest available version at the time.

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

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

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

We first tested different virtual machine types for the application node against a single m4.xlarge node for the database in each. We ran these tests on Confluence 6.15, which was the latest available version at the time.

However, none of those resulted in Apdex scores above 0.8. The following graph shows our actual Apdex benchmarks when we ran the same tests using m4.2xlarge for the database:


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

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

We also tested different combinations of virtual machine instances for the application node using m4.4xlarge for the database node, but did not see any improvement in 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.