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

デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりましたテンプレートは今後も利用できますが、保守や更新は行われません。

より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。

AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。

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

推奨事項は古いバージョンの Confluence に基づいています

このページの推奨事項は、Confluence の古いバージョンで行われたテストに基づいています。次の項目をテストしました。

  • Confluence Data Center 6.13 および 6.15 で設定された XLarge データ
  • Confluence Data Center 6.13 および 6.14 で設定された、サイズの大きいデータ
  • Confluence Data Center 6.13 で設定された、平均的なサイズのデータ

特に高可用性が不要な場合には、"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" サイズのインスタンスで一連のパフォーマンス テストを実施しました。これらのテストは、ご利用のクラスタ化されたデプロイメントのアプリケーションおよびデータベース ノードに有用なデータ主導の推奨事項を確認できるように設計されています。これらの推奨設定は、プロジェクト化されたコンテンツおよびトラフィックのサイズに合った適切なクラスタ化環境の計画に役立てることができます。


エグゼクティブ サマリー

推奨事項Application nodesデータベース ノード1 時間あたりのコスト1Apdex (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 を示しました。

推奨事項Application nodesデータベース ノード1 時間あたりのコスト1Apdex (Confluence バージョンごと)
6.136.14
パフォーマンスc5.4xlarge x 2m4.2xlarge2.090.8520.874
安定性c5.2xlarge x 4m4.xlarge1.720.8170.837
低コストc5.2xlarge x 3m4.xlarge1.380.8200.834


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

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


XLarge

構成Application nodesデータベース ノード1 時間あたりのコスト1Apdex (Confluence バージョンごと)
6.136.15
安定性c5.4xlarge x 4m4.2xlarge3.450.8100.826
低コストc5.4xlarge x 3m4.2xlarge2.770.8110.825

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

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

重要な注意事項

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



アプローチ

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

テスト インフラストラクチャの各部分は、すべての AWS ユーザーが利用できる標準の AWS コンポーネントです。つまり、お客様はアトラシアンの推奨設定を簡単にデプロイできます。 

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

考慮事項

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

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

Analytics

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

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

分析を有効にした場合のパフォーマンスへの影響を確認するため、個別のテストを実行しました。これを行うため、同一の 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.view84
confluence.blogpost.view1
confluence.dashboard.view6
confluence.page.create.collaborative.view2
confluence.page.edit.collaborative.view5
confluence.page.edit.collaborative.quick-view2

使用状況に関する統計が多数の 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 まで拡張可能です。 
Load balancer1AWS 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" テスト フェーズのベンチマークと構成を分析し、以下の推奨設定を導きました。

推奨事項

Application nodes

データベース ノード

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.xlarge ノードに対してテストしました。これらのテストは、テストの実施時点で利用可能な最新の長期サポート リリース バージョンであった Confluence 6.13 で実行しました。

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

最初に、アプリケーション ノード用の異なる仮想マシン タイプを、それぞれのデータベース用の 1 つの m4.xlarge ノードに対してテストしました。これらのテストは、テストの実施時点で利用可能な最新の長期サポート リリース バージョンであった 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" テスト フェーズのベンチマークと構成を分析し、以下の推奨設定を導きました。

推奨事項Application nodesデータベース ノード1 時間あたりのコスト1Apdex (Confluence バージョンごと)
6.136.14
パフォーマンスc5.4xlarge x 2m4.2xlarge2.090.8520.874
安定性c5.2xlarge x 4m4.xlarge1.720.8170.837
低コストc5.2xlarge x 3m4.xlarge1.380.8200.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 以上になるすべての構成に関する情報を示しています。 

Application nodesデータベース ノードApdex1 時間あたりのコスト1 
c5.4xlarge x 2m4.2xlarge0.8742.09
c5.4xlarge x 3m4.xlarge0.8632.40
c5.4xlarge x 2m4.xlarge0.8561.72
c5.2xlarge x 4m4.2xlarge0.8552.09
c5.2xlarge x 3m4.xlarge0.8341.38
c5.2xlarge x 4m4.xlarge0.8371.72


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

構成Application nodesデータベース ノードApdex1 時間あたりのコスト1
パフォーマンスc5.4xlarge x 2m4.2xlarge0.8742.09
安定性c5.2xlarge x 4m4.xlarge0.8371.72
低コストc5.2xlarge x 3m4.xlarge0.8341.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 でも有効かどうかを確認しました。以下の表は、これらのテストの結果を示しています。

構成Application nodesデータベース ノード1 時間あたりのコスト1Apdex (Confluence バージョンごと)
6.136.14

パフォーマンス

c5.4xlarge x 2m4.2xlarge2.090.8520.874
安定性c5.2xlarge x 4m4.xlarge1.720.8170.837
低コストc5.2xlarge x 3m4.xlarge1.380.8200.834
構成Application nodesデータベース ノード1 時間あたりのコスト1Apdex (Confluence バージョンごと)
6.136.14

パフォーマンス

c5.4xlarge x 2m4.2xlarge2.090.8520.874
安定性c5.2xlarge x 4m4.xlarge1.720.8170.837
低コストc5.2xlarge x 3m4.xlarge1.380.8200.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" テスト フェーズのベンチマークと構成を分析し、以下の推奨設定を導きました。

構成Application nodesデータベース ノード1 時間あたりのコスト1Apdex (Confluence バージョンごと)
6.136.15
安定性c5.4xlarge x 4m4.2xlarge3.450.8100.826
低コストc5.4xlarge x 3m4.2xlarge2.770.8110.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 インスタンスに最適な構成を選択する際にさらなる支援が必要な場合は、アトラシアン Advisory Service にお問い合わせください。

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


最終更新日: 2024 年 2 月 29 日

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

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