Confluence Data Center がエンタープライズ レベルに対応可能かどうかを確認する方法
Confluence Data Center のデプロイメントに関心を持っている大規模なエンタープライズの場合、エンタープライズ レベルのワークロードの処理能力をどのように確保しているかという点に特に着目しているのではないでしょうか。「Confluence Data Center のサンプル デプロイメントと監視戦略」では、当社の Confluence Data Center インスタンス (常に最新バージョンで稼働) のデプロイメント、保守、および監視の方法について説明しました。これにより、当社のこれまでの知見に照らし合わせても最も大きいワークロードを持つインスタンスの 1 つである Confluence が本番環境でどのように実行されるかを直接確認できます。
ただし、弊社自身による Confluence Data Center の実行および使用は、全体の一部にすぎません。この記事では、当社のパフォーマンス テストの方法論について説明します。一連のパフォーマンス テストをどのようにしてリリース プロセスの各フェーズに組み込んでいったかについて解説します。パフォーマンスの劣化の防止から、さまざまな負荷がかかる条件下での満足のいくパフォーマンス確保まで、あらゆる内容を取り上げます。このようなテストにより、それぞれのバージョンがさまざまなエンタープライズ レベルのワークロード (Confluence Data Center 負荷プロファイルに説明) に耐えられることを確認できます。
また、パフォーマンス テストの環境とテスト ハーネスについても詳しく説明します。Confluence Data Center でエンタープライズ レベルのワークロードをテストするためのさまざまな方法について紹介します。
開発段階でのパフォーマンス テスト
アトラシアンの開発者は、Confluence について提案されたそれぞれの機能や変更について、パフォーマンス面で考えられる影響を検討します。パフォーマンス目標に対するリスクを特定し、リスクの程度を確認するための適切なテストを作成します。品質管理エンジニアは、開発者の要望に応じて技術サポートや検証を行います。
このプロセスの概要を以下に示します。
開発者は次のように、機能のライフサイクルの各ステージにパフォーマンス テストを組み込みます。
開発
開発者はそれぞれのローカル マシンで直接パフォーマンス テストを実行します。ローカル マシンで行うことで、コード変更がパフォーマンスにおよぼす影響を分離した環境でテストできます。これによって素早いフィードバック ループを実現し、インクリメンタルな変更の影響を焦点を絞ってテストできます。たとえば、特定のマクロのフロントエンドを変更する場合、開発者は他のパフォーマンス テストを無効にして、そのマクロを含む特定のページのみを対象にテストを実行できます。
Feature branch
分離された環境での機能のパフォーマンスを確認できたら、開発者はほかの Confluence 機能への影響可否をテストします。これを実施するために、開発者は継続的インテグレーション (CI) パイプラインで実行中のフィーチャー ブランチ ビルドに変更をプッシュします。
このパフォーマンス テストですべての機能が検証されるわけではありません。パフォーマンスの劣化を引き起こすリスクが低い機能の場合、開発者はその機能を直接 master ブランチにマージできます。
マスター ブランチ
すべての機能は最終的に master ブランチにマージされます。そこから CI パイプラインが、新たにマージされたその他すべての機能とともに Confluence をコンパイルします。それぞれの新規ビルドはまずテスト インスタンスにインストールされ、その後、本番環境で確認されているもっとも大きいレベルの Confluence ワークロードが適用されます。
master ブランチでの必須のパフォーマンス テストは、パフォーマンスの劣化に対する追加の保護レイヤーとなります。これにより、すべての新しい機能が何らかのパフォーマンス テストで確実に検証されます。
リリース候補
すべてのリリース候補に最終パフォーマンス テストを行い、確立済みのベースラインとテスト結果とを比較して、多量のワークロードを円滑に処理できることを確認します。
エンタープライズ対応可能であるかどうかの検証方法
パフォーマンスの劣化に対する保護に加えて、master ブランチで実行するパフォーマンス テストは、ビルドがさまざまなワークロードにどのように耐えるかを調査するうえでも役立ちます。これらの 1 つがエンタープライズ対応ワークロードで、Confluence に対して large サイズのコンテンツとトラフィックを適用します (各コンテンツおよびトラフィック プロファイルにについては「Confluence Data Center 負荷プロファイル」を参照)。
テスト環境とアーキテクチャ
エンタープライズ対応ワークロードのテストは Amazon Web Services (AWS) Virtual Private Cloud で実行されます。これは以下の AWS インスタンスで構成されています。
機能 | AWS ノード タイプ | ノードの数 |
|---|---|---|
| Confluence アプリケーション | c5.2xlarge (Amazon Linux を実行) | 4 |
| Synchrony (共同編集用) | c5.2xlarge (Amazon Linux を実行) | 1 |
| Load balancer | AWS Application Load Balancer | 1 |
| データベース | m4.xlarge | 1 |
| Apache JMeter | c4.2xlarge | 1 |
| 共有ホーム ディレクトリ | m4.large | 1 |
各ノード タイプについては、インスタンス タイプについての AWS ドキュメント (特に「汎用インスタンス」と「コンピュート最適化インスタンス」) を参照してください。
データベースは PostgreSQL RDS で実行され、large サイズのデータセット (またはコンテンツ プロファイル) でプリロードされています。将来的には、他のデータベース プロバイダに対応する同様のテスト環境を追加する予定です。
すべての Confluence アプリケーション ノードは、NFS サーバーでホストされている共有ホーム フォルダをマウントします。
テクニカル コンポーネント
テスト ハーネスは、次のコンポーネントで構成されています。
コンポーネント | ロール | 説明 |
|---|---|---|
| ロード インジェクタ | テスト用のトラフィックは JMeter を介して生成します。特に、指定したパラメータで HTTP 呼び出しをシミュレートするために JMeter 構成スクリプトを使用します。このようなパラメータには、編集または表示するユーザー名、スペース、ページなどがあります。JMeter は分散型で実行します。これは、負荷を容易に調整できるためです。 JMeter は Javascript の実行または評価や、ページの実際のレンダリングは行いません。このため、当社では Selenium ブラウザを JMeter と同時に実行してページの読み込み時間を測定しています。 | |
| ロード インジェクタ | Selenium は、より現実的なユーザー エクスペリエンスをシミュレートするため、ユーザー インタラクション部分の実行に使用しています。当社の環境では同じ JMeter を 5 つのヘッドレス Chrome ブラウザで実行しており、これには Javascript の解析と実行も行えるメリットがあります。これにより、全体的なパフォーマンスとともに、さまざまなフロントエンドのパフォーマンス メトリック (例: 解析時間、DOM 読み込み時間) も測定できます。Selenium ブラウザから送信されるカスタム アナリティクスをテスト システムで受け取り、そこでさらに分析を重ねて、ページ読み込み時間のコストの内訳を明らかにします。 | |
| Ansible | インフラストラクチャ デプロイメント | Ansible playbook を使用して、AWS でのテスト環境のプロビジョニングからロード インジェクタの起動とテスト データの収集まで、テスト プロセス全体をオーケストレーションします。オーケストレーションにより、開発プロセス全体を通して複数のビルド間で同タイプのパフォーマンス テストを実行できます。 |
ワークロード
エンタープライズ対応テスト用ワークロードは、当社内部の Confluence Data Center インスタンスにおけるトラフィックやコンテンツに基づいてモデル化しています。これは「Confluence Data Center のサンプル デプロイメントおよび監視戦略」で説明している内容と同等です。データ ボリュームと HTTP トラフィックの面では、このインスタンスのワークロードは、当社が本番環境で確認しているもっともワークロードが大きい 10 個のインスタンスに含まれます。
ロード インジェクタはさまざまなユーザー アクションをシミュレートするために、複数の HTTP リクエストで構成されたトランザクションを生成します。JMeter と Selenium は Confluence のビジネスクリティカルなワークフローをシミュレートするため、このようなユーザー アクションをともに集約します。
全体で見ると、当社のテスト ハーネスは、毎時 19,171 トランザクション (毎秒 5.3 トランザクション) を生成します。これは、毎時 431,000 HTTP リクエスト (毎秒 120 リクエスト) と同等のスループットを生成します。
データ セット
ワークロードと同様、「Confluence Data Center のサンプル デプロイメントおよび監視戦略」で説明したインスタンスのスナップショットの作成後、テスト インスタンスのデータ セットをモデル化しました。このスナップショットには次の要素を持ちます。
ディメンション | 値 (近似値) |
|---|---|
| 合計スペース数 | 6,550 |
| サイトのスペース | 1,500 |
| 個人用スペース | 5,000 |
| コンテンツ (すべてのバージョン) | 16,000, 000 |
| コンテンツ (現在のバージョン) | 6,900, 000 |
| コメント | 2,000, 000 |
| ローカル ユーザー | 12,300 |
| ローカル グループ | 9,900 |
実行
テスト ハーネスが Ansible を介してテスト環境をプロビジョニングすると、エンタープライズ対応テストが次のように進行します。
ウォームアップ
テストは、新たにプロビジョニングされたアーキテクチャ上のコールド アプリケーションで行います。このため、有益な結果を得るには Confluence をウォームアップする必要があります。テストの最初の 15 分間でウォームアップを行い、以降はすべてのテスト データを破棄します。また、この時間を利用して 360 アクティブ ユーザーのログインも開始します。これを使用して各ユーザーのトランザクションをシミュレートします。テストの間、すべてのアクティブ ユーザーは Confluence にログインしたままとなり、すべてのユーザー アクションは各ユーザーを通してトリガーされます。
ピーク負荷
ウォームアップ後、テスト ワークロードを 2 時間適用します。このとき、各アクティブ ユーザーをワークフロー グループに割り当て、そこで一連のユーザー アクションを実行します。各ワークフロー グループは Confluence のビジネスクリティカルなワークフローに基づきます。
JMeter を使用して、次の各ユーザー アクションをトリガーします。
ワークフロー グループ | 操作 |
|---|---|
| ページの作成 | ログイン → ダッシュボードの表示 → ページ検索 → ページの表示 → ページへのいいね! → ページの作成 → ページの制限 → ラベルの追加 → ログアウト |
| ページの編集 | ログイン → ダッシュボードの表示 → ページ検索 → ページの表示 → ページの編集 → ページの表示 → 添付ファイルのアップロード → ログアウト |
| ブログの表示 | ログイン → ダッシュボードの表示 → ブログ検索 → ブログの表示 → ブログへのいいね! → インライン コメントの表示 → 添付ファイルのアップロード → コメントの作成 → ログアウト |
| インライン コメントの表示 / 更新 | ログイン → ダッシュボードの表示 → ページの表示 → インライン コメントの表示 → ログアウト |
| ブログの作成 | ログイン → ダッシュボードの表示 → ブログの作成 → 添付ファイルのアップロード → ブログの作成 → インライン コメントの作成 → ログアウト |
| コメントの作成 | ログイン → ダッシュボードの表示 → ページ検索 → ページの表示 → ページ コメントの作成 → インライン コメントの作成 → ログアウト |
同時に Selenium は次のアクションを含む一般的なワークフローを実行します。
| ログイン → ダッシュボードの表示 → ページの作成 → インライン コメントの作成 → 最近表示されたページの表示 → ページの編集 → ブログの表示 → ページの表示 → 人気のページの表示 → ログアウト |
ローカル、アクティブ、および同時ユーザー
パフォーマンス テストの目的のため、ユーザーを 3 つのタイプに分類しています。
- ローカル: Confluence インスタンスにログイン情報を持つすべてのユーザーを対象とします。当社のテスト インスタンスのローカル ユーザー数は 12,300 です。
- アクティブ: 現在ログイン中のすべてのユーザーです。すべてのテスト アクションはこれらのユーザーを通して実行します。テストで行うユーザー アクション数は 1 時間あたり 19,171 で、360 のすべてのアクティブ ユーザーにわたって行います。
- 同時: ユーザー アクションを同時にトリガーするすべてのアクティブ ユーザーです。ユーザー アクション間にさまざまな思考時間を設定しているため、テスト中の同時ユーザー数は平均 8 ユーザー、最大 29 ユーザーとなっています。
結果の収集と分析
当社では内部の InfluxDB サーバーを使用して、テスト データをリアルタイムで集約および収集しています。このサーバーでは、テストが進行中でもアクティブに監視可能で、結果を履歴データと比較することもできます。テスト ハーネスは次のツールを使用してこれらのメトリックを収集し、InfluxDB に送信します。
ツール | 説明 |
|---|---|
| Amazon CloudWatch | テスト環境を AWS にデプロイすることで、Cloudwatch を使用して各ノードからリソース使用率の詳細なメトリックを収集できます。 |
| Telegraf | アプリケーション ノードに Telegraf エージェントをインストールして Confluence のデータを監視および収集します。これらのデータには、JVMのメトリック、ガベージ コレクタの統計情報、休止状態の統計情報、クエリ数、キャッシュ、データベース プールなどがあります。 |
| JMeter プラグイン | このコンポーネントは、InfluxDB に送信されたデータから解析とグラフ作成を行います。これにより、スループット、アクティブ スレッド、成功 / エラー率、トランザクション応答時間といったさまざまなタイプのトラフィック データを視覚化できます。 |
| カスタム ツール | ブラウザのナビゲーション タイミングやパフォーマンス結果を InfluxDB に直接送信する一連のスクリプトを開発しました。 |
InfluxDB データのさまざまな面を視覚化するため、Grafana ベースのダッシュボードをいくつか作成しました。さらに、AWS ノードからすべてのログを送信し、インジェクタを中央 Splunk サーバーにロードしています。インジェクタはここで関連イベントを精査できます。
Atlassian が提供するサービス
この方法についてご不明な点がある場合は、当社の Advisory Service またはプレミアサポート チームにお問い合わせください。