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

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

このページでは、Bitbucket Server または Bitbucket Data Center での実験について説明します。

アトラシアンでは、社内のパフォーマンステストでのアトラシアンパフォーマンステストフレームワークの使用を終了しました。お客様は引き続きフレームワークを使用できますが、結果の解釈についてのサポートを受けることはできません。

On this page:

はじめる前に

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

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

実験を定義する

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

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

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

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

実験のフェーズ

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

Provision.py: 本番インスタンス、ワーカーマシンのクラスタ、および AWS 内のその他の関連インフラストラクチャをスピンアップします。実験用定義から e3-home/runs に自動的に "実行ファイル" を作成します。Bitbucket Server では、独自のインフラストラクチャがある場合にはこの手順をスキップできますが、実行ファイルを作成し、マシンの詳細を最初に入力する必要があります。
Run.py: ワーカーマシンからクライアントワークロードを実際に実行します (また、ステージ間で本番インスタンスを既知の安定した状態にリセットします)。
Gather.py: 実行された実験 (実行中または完了済み) のデータをすべてのマシンから収集します。
Analyze.py: 実行された実験のデータを分析してグラフ化し、インスタンスのパフォーマンス状態や負荷状態における全インスタンスの "バイタルサイン" の視覚化をサポートします。
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 を参照してください。

データセットとスナップショット

スナップショット記述子ファイルは Bitbucket データセットの記述に使用され、e3-home/snapshots に保存されます。アトラシアンは次のような多数の既定スナップショットを提供しています。

snapshots/e3-small.json
snapshots/bitbucket-e3-small.json
snapshots/bitbucket-e3-medium.json

既定のスナップショットはすべて、以下を備えています:

ファイルサーバーのパブリックな EBS スナップショット
データベースのパブリックな RDS スナップショット
パブリックな Elasticsearch スナップショット (JSON スナップショット記述子に記載されたデータの検索インデックスを含む S3)。

AWS で実験を実行する場合、これらの既定スナップショットを使うと、実験を素早く開始および実行できます。

別の環境で実験を実行中の場合、実験を行なっている Bitbucket インスタンスのデータセットの記述子をフレームワークに提供する必要があります。新しいスナップショット記述子を生成するには、次の Snapshot.py スクリプトを使用できます。

$ ./util/Snapshot.py --url "https://bitbucket-instance" --username admin --password admin --name snapshot-name --description "snapshot description"

AWS で独自のデータセットを作成する

./util/Snapshot.py スクリプトを --aws true オプションを指定して実行した後、データの EBS (および、場合によっては RDS と Elasticsearch) のスナップショットを作成する必要があります。これは、Atlassian Bitbucket AMI に付属する Atlassian Bitbucket DIY バックアップスクリプトを使用することで簡単に実現できます。あるいは、bitbucket.org からリポジトリをクローンできます。

「AWS で Bitbucket DIY バックアップを使用する」を参照してください。

生成されたスナップショットで EBS (git リポジトリ)、RDS (データベース) および ES (検索インデックス) のスナップショットフィールドを構成する必要があります (以下の例を参照)。

次の構成例は、Bitbucket Data Center インスタンスから取得したスナップショットを指定します。

"ebs": { 
    "ap-southeast-2": "snap-4ee80fde", 
    "us-east-1": "snap-25e718aa" 
}, 
"rds": { 
    "account": "098706035825", 
    "id": "e3-small" 
}, 
"es": { 
    "id" : "e3-small", 
    "bucket": "bitbucket-server-e3" 
}

SSH キー

公開 / 秘密鍵のペアを保存するためにキーファイルを使用できます。これらは、実験の実行中に Bitbucket での認証にユーザーが使用します。これらの記述子は e3-home/keys に保存されます。

既存のデータセットを使用している場合、フレームワークが SSH 経由での認証に使用できる公開および秘密 SSH キーを提供する必要があります。key-file を Snapshot スクリプトに提供すると、スクリプトはインスタンス内のユーザーを検索し、各ユーザーの構成済み公開鍵に秘密鍵をマッピングします。

パスワード

現在、Snapshot スクリプトはすべてのユーザーが同じパスワードを設定していることを想定しています (既定では password)。

注: 各ユーザーは、すべてのプロジェクト/リポジトリへのアクセス権があると想定されます。テストスクリプトは十分な権限を保持していないため、障害による復元性はありません。

構成のカスタマイズ

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

Bitbucket 用に実験をカスタマイズできる多数のプロパティがあります。次の基本的な json は、使用方法の例を含みます。

{
    "product": "Bitbucket",
    "duration": 600000,
    "workload": "bitbucket-mixed",
    "threads": [
        {
            "name": "1-node",
            "instance": {
                "name": "1-node",
                "version": "4.11.0",
                "snapshot": "e3-small",
                "template": "BitbucketDataCenter",
                "properties": [
                    "plugin.bitbucket-git.throttle.ref.advertisement=false",
                    "plugin.bitbucket-scm-cache.upload-pack.enabled=false",
                    "throttle.resource.scm-hosting.strategy=adaptive",
                    "throttle.resource.scm-hosting.adaptive.limit.min=8",
                    "throttle.resource.scm-hosting.adaptive.limit.max=100",
                    "throttle.resource.scm-hosting.adaptive.interval=2",
                    "throttle.resource.scm-hosting.adaptive.growth.max=1.0",
                    "throttle.resource.scm-hosting.adaptive.target.cpu=0.8"
                ],
                "parameters": {
                    "ClusterNodeMin": "1",
                    "ClusterNodeMax": "1"
                }
            },
            "worker": {
                "name": "worker-cluster-1",
                "template": "WorkerCluster",
                "parameters": {
                    "ClusterSize": "4"
                }
            },
            "stages": [
                {
                  "clients": 40
                },
                {
                  "clients": 80
                },
                {
                  "clients": 160
                }
            ]
        }
    ]
}

詳細なカスタム構成については、bitbucket.properties ファイルを使用し、「CloudFormation のテンプレートまたはアプリケーションプロパティをオーバーライドする方法」を参照してください。

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

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

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

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

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

クラスター内の各ノードの認証に使用する公開鍵と秘密鍵のペアを作成します。すべてのクラスターノードで同じキーペアを使用する必要があります。
上記のキーペアを使用して e3-user をセットアップします。
Bitbucket クラスターインスタンスを処理する各ノードで SSH デーモンが実行中であることを確認します。
本番環境インスタンスで表示予定のデータを表すファイルシステムとデータベーススナップショットを選択します。
上記で選択したファイルシステムとデータベースで Bitbucket を構成します。
テストデータのスナップショットを生成して、e3-home/snapshots にコピーします。
Bitbucket インスタンスの JMX 監視を有効化します。
collectd デーモンをインストールし、このリポジトリにサンプルとして含まれている bitbucket-collectd.conf 構成ファイルを使用して構成します。Linux ディストリビューション / collectd インストールに応じて調整が必要となる場合があります。詳細については、専用の config/README を参照してください。テストを開始する際はデーモンが実行中であることを確認します。
Bitbucket インスタンスを記述する json ファイルを作成し、次のフィールドを含めます。
1. ClusterNodes 接続文字列のリスト
2. Bitbucket Server の URL
3. ステップ 3 で生成された snapshot ファイルの名前
4. admin_password: テスト中のシステムの管理者パスワード
e3-home/instances ディレクトリに、インスタンスを記述する json ファイルとインスタンスの秘密鍵ファイルの両方をコピーします。両方のファイルは同じ名前でそれぞれ異なる拡張子 (.json および .pem) を使用する必要があります。

2 ノードの Bitbucket の構成ファイルの例:

{ 
  "ClusterNodes": [ "e3-user@bitbucket-server-node-1", 
  "e3-user@bitbucket-server-node-2" ], 
  "URL": "http://bitbucket-server", 
  "snapshot": "my-snapshot", 
  "RunConfig": { 
     "admin_password": "s3cr3t" 
    } 
}

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

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

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

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

以下をインストールします。
- git
- Java
- python 2.7
- collectd (バージョン 5.2 以降)
このリポジトリにテンプレートとして含まれている worker-collectd.conf 構成ファイルを使用して collectd をセットアップします。Linux ディストリビューション / collectd インストールに応じて調整が必要となる場合があります。詳細については、専用の config/README.md を参照してください。テストを開始する際はデーモンが実行中であることを確認します。
ワーカーノードで SSH デーモンが実行中であることを確認します。
sudo 権限で、このクラスタ用に作成した公開鍵 / 秘密鍵のペアを使用して認証できる e3-user を作成します。sudo コマンドを実行する際、パスワードは求められません。/etc/sudoers 構成を編集して e3-user ALL=(ALL) NOPASSWD:ALL などを含める必要がある場合があります。
e3-user をオーナーとして /media/data ディレクトリを作成します。
ワーカークラスターを記述する json ファイルを作成します。
インスタンスのワーカークラスタと秘密鍵ファイルを記述する 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 ノードの Bitbucket クラスターを比較する実験の実行方法を示します。

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

Two-node.json

{ 
  "ClusterNodes": [ 
    "e3-user@bitbucket-server-node-1", 
    "e3-user@bitbucket-server-node-2" 
  ], 
  "URL": "http://bitbucket-server-with-2-nodes",   
  "snapshot": "my-snapshot", 
  "RunConfig": { 
    "admin_password": "s3cr3t" 
  } 
}

Four-node.json

{ 
  "ClusterNodes": [ 
    "e3-user@bitbucket-server-node-1", 
    "e3-user@bitbucket-server-node-2", 
    "e3-user@bitbucket-server-node-3", 
    "e3-user@bitbucket-server-node-4" 
    ], 
  "URL": "http://bitbucket-server-with-4-nodes", 
  "snapshot": "my-snapshot", 
  "RunConfig": { 
    "admin_password": "s3cr3t" 
  } 
}

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

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 分間持続し、bitbucket-mixed ワークロードを実行します。

{
  "product": "Bitbucket",
  "duration": 300000,
  "workload": "bitbucket-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/ にコピーします。

実験を実行する

テストを実行する前に、「アトラシアンパフォーマンステストフレームワーク」のページに記載された指示に従い、適切な前提条件でインストールしていることをご確認ください。

Bitbucket のテスト中であれば、e3 ディレクトリに移動して以下を実行することでこの実験を簡単に実行できます。

$ ./Run.py -r my-experiment

実験データを分析する

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

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

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

サポート

パフォーマンステストフレームワークは現状のまま提供され、アトラシアンのサポート対象外となります。アトラシアンのサポートチームは、テスト結果の解釈を支援できません。

アトラシアンコミュニティの「パフォーマンステストフレームワーク」トピックに移動して、他のユーザーがどのようにフレームワークを使用しているかを確認したり、体験を共有したり、コミュニティでサポートを求めたりできます。

製品

Jira Software

Jira Service Management

Jira Work Management

Confluence

Bitbucket

リソース

関連ドキュメント

コミュニティ

システムステータス

提案とバグ

Marketplace

請求とライセンス情報

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

アトラシアンパフォーマンステストフレームワーク

このページの内容

お困りですか?

はじめる前に

実験を定義する

実験のフェーズ

ワークロード

重み

分析

データセットとスナップショット

AWS で独自のデータセットを作成する

SSH キー

パスワード

構成のカスタマイズ

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

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

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

実験ファイルの例

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

実験を実行する

実験データを分析する

サポート

ページ

Viewport

Confluence

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

アトラシアン パフォーマンス テスト フレームワーク

このページの内容

関連コンテンツ

お困りですか?

はじめる前に

実験を定義する

実験のフェーズ

ワークロード

重み

分析

データセットとスナップショット

AWS で独自のデータセットを作成する

SSH キー

パスワード

構成のカスタマイズ

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

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

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

実験ファイルの例

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

実験を実行する

実験データを分析する

サポート

関連コンテンツ

アトラシアンパフォーマンステストフレームワーク

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