Confluence 用のパフォーマンステストフレームワーク

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

パフォーマンス テスト フレームワークは以前、Elastic Experiment Executor (E3 ) と呼ばれていました。これは、Confluence Data Center 製品のインスタンスをセットアップ、実行し、負荷状態でのパフォーマンスを分析するためのフレームワークです。

このページでは、Confluence での実験の実行について説明します。 



このページの内容:

はじめる前に

実験を実行する前に、パフォーマンス テスト フレームワークの前提条件をすべて満たしていることを確認し、パフォーマンス テスト フレームワークのセットアップを行う必要があります。 

開始方法については、「アトラシアン パフォーマンス テスト フレームワーク」を参照してください。 

実験を定義する

実験は、以下を定義する JSON ファイルで記述されます。

  • (並列して) 実行される独立した実験スレッド
  • テストするインスタンスのタイプ
  • テストするインスタンスのサイズと形状
  • インスタンス内のデータの形状 (プロジェクト、リポジトリ、ユーザーなど)
  • インスタンスに負荷をかけるクライアント マシンのサイズと形状
  • ワークロードの操作の組み合わせ
  • 実験の各ステージで適用される負荷の量 (クライアント スレッドの数)

e3-home/experiments には事前定義済みの実験用ライブラリがあります。独自に定義することもできます。

実験用の JSON ファイルで参照されるワークロードは e3-home/workloads で定義されます。

実験のフェーズ

パフォーマンス実験には、次のスクリプトに対応する複数のフェーズがあります。

  1. Provision.py which spins up product instance(s), cluster(s) of worker machines, and other associated infrastructure in AWS. Will automatically create a 'run file' in  e3-home/runs  from your experiment definition.
  2. Run.py: ワーカー マシンからクライアント ワークロードを実際に実行します (また、ステージ間で本番インスタンスを既知の安定した状態にリセットします)。
  3. Gather.py: 実行された実験 (実行中または完了済み) のデータをすべてのマシンから収集します。
  4. Analyze.py: 実行された実験のデータを分析してグラフ化し、インスタンスのパフォーマンス状態や負荷状態における全インスタンスの "バイタル サイン" の視覚化をサポートします。
  5. Deprovision.py: テスト マシンのプロビジョニングを解除し、実験の実行をアーカイブします。

これらすべてのフェーズを順に実行するグローバル Orchestrate.py スクリプトに加えて、各フェーズは個別でも実行できます。

$ cd ./e3
$ ./Provision.py -e <experiment_name>
$ ./Run.py -r <run_name>
$ ./Gather.py -r <run_name>
$ ./Analyze.py -r <run_name>

ワークロード

ワークロードは、実験で使用する実行スクリプトのタイプと分散を定義します。1 つの実験で定義できるワークロードは 1 つのみですが、各ワークロードには複数のスクリプトを含めることができます。ワークロード記述子は e3-home/workloads に保存されます。

ワークロードの説明に含まれるもの:

  • script: 実験中に実行されるスクリプトのパス。e3/execution/grinder ディレクトリの相対パス。
  • description: 説明の名前。分析で生成されるグラフで使用されます。
  • scale: 分析ステージで適用される、実験での相対的な重み付け。重要度の低いオペレーションや負荷の低いオペレーションを視覚的に目立たせないようにするために使用できます。
  • weight: この実行スクリプトに適用される重み付け。すべての重みの合計値が 1.0 になるようにします。

重み

パフォーマンス テスト フレームワークがクライアント スレッドとワーカーに処理を割り当てる方式では、重み付けの方法をワークロードの定義に合わせて調整する必要があります。これを示す例は次のとおりです。

experiment.json
{
    ...
    "stages": [
        {
            "clients": 10
        },
        {
            "clients": 20
        }
    ]
}

上記で定義した実験は 10 クライアントのみのステージで実行されているため、重み付けで対応できる最大の解決状況は 1/10 または 0.1 です。そのため、0.1 未満の重みのスクリプトを含むワークロードの定義は実行できない場合があります。

また、フレームワークは、すべてのワーカー マシンでクライアント スレッドを均一に分散させます。つまり、各ステージで多数のクライアント スレッドを指定する場合、割り当てたワーカー マシンの数で除算できる数にする必要があります。

分析

パフォーマンス テスト フレームワークでは、ワーカー マシンや本番環境マシンから収集されたデータからグラフを生成できます。2 種類の分析スクリプトが付属します。

  • gnuplot
  • rrdtool

./e3/Analyze.py -r <run_name> を呼び出すと、特定の実行に対するタイプとグラフの両方が生成されます。

1 タイプのグラフのみを生成する場合:

$ ./e3/analysis/gnuplot/Analyze.py -r <run_name>

または

$ ./e3/analysis/rrdtool/Analyze.py -r <run_name>

生成されたグラフは e3-home/runs/<run_name>/analysis ディレクトリに保存されます。

注: 実験を実行した後に rrdtooll と gnuplot の両方からグラフを生成するには、Analyze.py スクリプトを使用する必要があります。Orchestrate.py は現在、rrdtool を使用するグラフのみを生成します。分析と、フレームワークで生成されるグラフのタイプに関する詳細については、Analysis/README.md にある専用の README を参照してください。

Confluence のデータセット

実験でさまざまな負荷テストを行うために、Confluence インスタンス用の複数のデータセットを用意しています。

インスタンスは、Confluence の実験ファイルで指定した場所にある space-import.zip.xml ファイルを使用して入力されます。既定では、これは Confluence の resources ディレクトリです。このファイルを独自のスペース エクスポート ファイルと置き換えることができますが、既存のスペースにはテスト中にスクリプトで使用される特定のコンテンツが含まれるため、この方法は推奨されません。

構成のカスタマイズ

パフォーマンス テスト フレームワークでは、カスタム データセット以外に、製品インスタンスの形状やサイズ、および負荷テストの性質を微調整できる、製品固有の追加カスタム構成もサポートします。

基本的な実験のブレークダウン

以下の基本的な実験は、Grinder と Confluence という 2 つの構成コンポーネントで構成されます。それぞれのカスタム構成は以下のとおりです。

{
    "product": "Confluence",
    "duration": 180000,
    "workload": "confluence-mixed",
    "threads": [
        {
            "name": "1-node",
            "instance": {
                "name": "1-node",
                "version": "6.1.0",
                "template": "ConfluenceDataCenter",
                "properties": [
                    "confluence.data.directory=resources/confluence",
                    "confluence.license.key=<license-key-string>",
                    "confluence.number.of.instances=1",
                    "confluence.number.of.users=60",
                    "confluence.min.users.to.run.experiment=60"
                ]
            },
            "worker": {
                "name": "2-node-worker-cluster",
                "template": "WorkerCluster",
                "parameters": {
                    "ClusterSize": "2"
                }
            },
            "stages": [
                {
                    "clients": 20
                },
                {
                    "clients": 40
                },
                {
                    "clients": 60
                }
            ]
        }
}

Grinder のカスタム構成

次のプロパティは、Grinder で実行する負荷テストの方法を指定します:

  • duration: 負荷テストの実行期間 (ミリ秒単位)
  • workload: 各実験スレッドで実行するワークロードの名前 (e3-home/workloads](./e3-home/workloads) で定義)
  • worker: クライアント構成
    • ClusterSize: Confluence インスタンスに対してスクリプトを実行するクライアントとして動作するノード数を指定
  • stages: 1 つのインスタンスの実験の連続実行回数、および各ステージでシミュレーションを行うクライアントの数

Confluence のカスタム構成

次のプロパティを指定して、Confluence インスタンスをカスタマイズできます。

  • version: スピンアップする Confluence の製品バージョン
  • properties: Confluence がセットアップ中に使用するプロパティの一覧
    • confluence.data.directory: Confluence のセットアップ データ (スペースのインポートやカスタム メールサーバー構成を含む) を見つけることができる、e3-home への相対パス
    • confluence.license.key: Confluence インスタンスのセットアップに必要なライセンス (: json ではスラッシュをエスケープする必要があります)
    • confluence.number.of.instances: セットアップする Confluence クラスタのサイズ
    • confluence.number.of.users: すべてのステージにわたる、1 つの実験スレッドでシミュレーションされるクライアントの最大数
    • confluence.min.users.to.run.experiment: セットアップ エラーが発生した場合に実験の実行に必要となる作成済みユーザーの最小数。既定値は 0 で、ユーザーをまったく作成できなかった場合でも実験の実行を試みます。
    • mailtrap.api.token: メール通知の負荷テストに使用するための MailTrap サーバーを指定するオプション パラメータ。トークンが提供されない場合は、既定のカスタム メール構成ファイル mail-server.properties が設定されます。

独自のインフラストラクチャを使用する 

AWS を使用したくない場合、パフォーマンス テスト フレームワークで独自のインフラストラクチャに対してテストを実行することができます。現在、Linux システムのみがサポートされます。これを行うには、以下が必要です。

  1. パフォーマンス メトリックの収集に使用された製品インスタンスと追加ソフトウェアをセットアップおよび構成します。
  2. 製品インスタンスを記述する構成ファイルを作成します。
  3. 負荷を生成するワーカー クラスターを構成し、それについて説明する構成を記述します。
  4. パフォーマンス テストを記述する実験ファイルを作成します。

Confluence インスタンスのセットアップ

次のセクションでは、パフォーマンス メトリックのレポートを行いながら実験リクエストを送信できるように Confluence をセットアップするためにあたり、必要な手順について説明します。

注: セットアップの一環として、新規テスト ユーザーを作成し、テスト データを削除/インポート/変更するためのフレームワークの認証資格情報を提供する必要があります。パフォーマンス テスト フレームワークを重要なデータを含むインスタンスで使用する際は、最初に Confluence のバックアップを行うことを強くお勧めします。

  1. クラスター内の各ノードの認証に使用する公開鍵と秘密鍵のペアを作成します。すべてのクラスター ノードで同じキー ペアを使用する必要があります。
  2. 上記のキーペアを使用して e3-user をセットアップします。
  3. Confluence クラスター インスタンスを処理する各ノードで SSH デーモンが実行中であることを確認する
  4. お使いの Confluence インスタンスの JMX 監視を有効化します (ほとんどの Confluence バージョンでは既定で有効化されています)
  5. セキュアな管理者セッション (WebSudo) を無効化、リモート API を有効化、およびオンボーディング プラグインを無効化するように Confluence インスタンスを構成します。オプションとしてメール サーバーをセットアップします。 
  6. PTF マシンから ./e3/util/AddUsers.py を実行して、Confluence インスタンスでテスト ユーザーをセットアップします。Confluence のベース URL、実験でスピンアップするクライアントの最大数、および適切なユーザー作成権限を持つ認証資格情報を渡す必要があります。所有しているライセンスが、テスト ユーザーの作成数に対応できることを確認します。
    使用例:

    $ ./e3/util/AddUsers/py --product Confluence --url http://localhost:8090/confluence --users 100
  7. collectd デーモン (バージョン 5.2 以降) をインストールし、このリポジトリにサンプルとして含まれている confluence-collectd.conf 構成ファイルを使用して構成します。Linux ディストリビューション / collectd インストールに応じて調整が必要となる場合があります。詳細について、専用の config/README.md を参照してください。テストを開始する際にデーモンが実行中であることを確認します。 
  8. Confluence インスタンスを記述する json ファイルを作成し、次のフィールドを含めます。 ClusterNodes 接続文字列の一覧、Confluence サーバーの URL。 
  9. e3-home/instances ディレクトリに、インスタンスを記述する json ファイルとインスタンスの秘密鍵ファイルの両方をコピーします。両方のファイルは同じ名前でそれぞれ異なる拡張子 (.json および .pem) を使用する必要があります。
2 ノードの Confluence の構成ファイルの例
{ 
  "ClusterNodes": [ 
  "e3-user@confluence-server-node-1", 
  "e3-user@confluence-server-node-2" 
  ], 
  "URL": "http://confluence-server" 
}

ワーカー ノードを構成する

このセクションでは、本番環境インスタンスに負荷を与えると同時に、実験を理解するうえで便利なメトリックを収集する、ワーカー クラスターのセットアップに必要な手順について説明します。

クラスター内の各ノードの認証に使用する公開鍵と秘密鍵のペアを作成します。すべてのワーカー ノードで同じキー ペアを使用する必要があります。

ワーカー クラスターの各ノードで次の操作を行います。

  1. 以下をインストールします。
    • git
    • Java
    • python 2.7
    • collectd (バージョン 5.2 以降)
  2. このリポジトリにテンプレートとして含まれている worker-collectd.conf 構成ファイルを使用して collectd をセットアップします。Linux ディストリビューション / collectd インストールに応じて調整が必要となる場合があります。詳細については、専用の config/README.md を参照してください。テストを開始する際にデーモンが実行中であることを確認します。 
  3. ワーカー ノードで SSH デーモンが実行中であることを確認します。 
  4. sudo 権限で、このクラスタ用に作成した公開鍵 / 秘密鍵のペアを使用して認証できる e3-user を作成します。sudo コマンドを実行する際、パスワードは求められません。/etc/sudoers 構成を編集して e3-user ALL=(ALL) NOPASSWD:ALL などを含める必要がある場合があります。 
  5. e3-user をオーナーとして /media/data ディレクトリを作成します。 
  6. ワーカー クラスターを記述する json ファイルを作成します。 
  7. インスタンスのワーカー クラスタと秘密鍵ファイルを記述する json ファイルを e3-home/instances ディレクトリにコピーします。両方のファイルは同じ名前でそれぞれ異なる拡張子 (.json および .pem) を使用する必要があります。

ワーカー クラスターの構成ファイルの例。

{ 
  "ClusterNodes": [ 
  "e3-user@worker-node-1", 
  "e3-user@worker-node-2", 
  "e3-user@worker-node-3", 
  "e3-user@worker-node-4" 
  ] 
}

実験ファイルの例

上記で作成したインフラストラクチャ ファイルを参照して、実験について記述します。パフォーマンス テスト フレームワークでインスタンスをプロビジョニングしようとしているわけではないため、上記の実験セクションで説明されたすべての情報は不要な場合があります。独自のインフラストラクチャで実験を実行するために必要な最小限の情報を含む実験ファイルの例を以下に示します。

{
  "product": "Bitbucket",
  "duration": 10000,
  "workload": "bitbucket-mixed",
  "threads": [
    {
      "name": "2-node",
      "instance": {
        "stack": {
          "Name": "two-node-cluster"
        }
      },
      "stages": [
        {
          "clients": 40
        }
      ],
      "worker": {
        "stack": {
          "Name": "four-node-worker"
        }
      }
    }
  ]
}

上記の Name フィールドは、クラスタやワーカー構成を含む json ファイルの名前を参照します。

実際の例を使用して実験を準備する

この例では、負荷レベルが増加する中で 2 ノードと 4 ノードのクラスターを比較する実験の実行方法を示します。

最初に、製品インスタンスの構成ファイルを定義します。

Two-node.json
{ 
  "ClusterNodes": [ 
    "e3-user@confluence-server-node-1", 
    "e3-user@confluence-server-node-2" 
  ], 
  "URL": "http://confluence-server-with-2-nodes",   
}
Four-node.json
{ 
  "ClusterNodes": [ 
    "e3-user@confluence-server-node-1", 
    "e3-user@confluence-server-node-2", 
    "e3-user@confluence-server-node-3", 
    "e3-user@confluence-server-node-4" 
    ], 
  "URL": "http://confluence-server-with-4-nodes", 
}

次に、ワーカー ノードを定義します。

Two-node-worker.json
{ 
  "ClusterNodes": [ 
    "e3-user@worker-node-1", 
    "e3-user@worker-node-2", 
    "e3-user@worker-node-3", 
    "e3-user@worker-node-4" 
  ] 
}

および同一の four-node-worker.json

これらの 4 つのファイルとそれぞれの秘密 ssh 鍵を ./e3-home/instances にコピーし、ディレクトリに次の情報が含まれることを確認します。

  • two-node.json
  • two-node.pem
  • four-node.json
  • four-node.pem
  • two-node-worker.json
  • two-node-worker.pem
  • four-node-worker.json
  • four-node-worker.pem

my-experiment.json というファイル名で実験を定義します。この例では、5 つのステージで同時接続を 40 から 200 まで増加させます。それぞれのステージは 5 分間持続し、confluence-mixed ワークロードを実行します。

{
  "product": "Confluence",
  "duration": 300000,
  "workload": "confluence-mixed",
  "threads": [
    {
      "name": "2-node",
      "instance": {
        "stack": {
          "Name": "two-node"
        }
      },
      "stages": [
        { "clients": 40 },
        { "clients": 80 },
        { "clients": 120 },
        { "clients": 160 },
        { "clients": 200 }
      ],
      "worker": {
        "stack": {
          "Name": "two-node-worker"
        }
      }
    },
    {
      "name": "4-node",
      "instance": {
        "stack": {
          "Name": "four-node"
        }
      },
      "stages": [
        { "clients": 40 },
        { "clients": 80 },
        { "clients": 120 },
        { "clients": 160 },
        { "clients": 200 }
      ],
      "worker": {
        "stack": {
          "Name": "four-node-worker"
        }
      }
    }
  ]

}

実験の名前 (この場合は my-experiment) を使用して、./e3-home/runs ディレクトリに新しいフォルダを作成する必要があります。./e3-home/runs ディレクトリが存在しない場合は作成します。実験ファイルを ./e3-home/runs/my-experiment/ にコピーします。

実験を実行する

実験を実行する前に、「セットアップ」セクションの指示に従い、前提条件の製品がインストールされていることを確認してください。

パフォーマンス テスト フレームワークがステージ間で Confluence をリセットできるように、管理者のユーザー資格情報を提供する必要があります。e3 ディレクトリに移動して以下を実行します。

$ ./Run.py -r my-experiment -u <admin_username> -p <admin_password>

実験データを分析する

実験の実行が完了したら、パフォーマンス テスト フレームワークで収集されたデータを確認します。インスタンスやワーカー ノードからデータを収集して分析する方法は非常に簡単で、e3 ディレクトリから次のコマンドを実行するだけです。

$ ./Gather -r my-experiment
$ ./Analyze -r my-experiment

データ ファイルと結果のグラフは、事前に作成した実験実行フォルダ (./e3-home/runs/my-experiment など) に保存されます。

サポート

パフォーマンス テスト フレームワークは現状のまま提供され、Atlassian ではサポートを提供していません。アトラシアンのサポート チームは、テスト結果の解釈を支援することはできません。

Atlassian コミュニティの「パフォーマンス テスト フレームワーク」に移動し、他のユーザーがどのようにフレームワークを使用しているかを確認したり、実行内容を共有したり、コミュニティでサポートを求めたりすることができます

最終更新日 2019 年 1 月 22 日

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

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