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

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

エグゼクティブ サマリー

中

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

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

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

大

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

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

XLarge

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

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

アプローチ

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

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

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

考慮事項

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

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

Analytics

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

ディスク 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 に調整しました。 

アーキテクチャ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

安定性構成では、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 に大きな改善は見られませんでした。

実際の例

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

• 「Confluence Data Center がエンタープライズに対応可能かどうかを確認する方法」では、アトラシアンが各 Confluence リリースのベンチマーク評価に使用するテスト環境について説明しています。
• 「Confluence Data Center のサンプル デプロイメントおよび監視戦略」では、内部の Confluence Data Center インスタンスの 1 つでのパフォーマンスの監視戦略について説明します。これは世界中のアトラシアン社員が使用している実際のインスタンスであり、アプリもインストールされています。

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

Atlassian が提供するサービス

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

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