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

このページの内容

お困りですか?

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

コミュニティに質問

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

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

We no longer use the Atlassian Performance Testing framework for our own performance tests. You can still use the framework, but we won’t be able to provide support or help you interpret the results.


このページの内容:

はじめる前に

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

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

実験を定義する

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

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

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

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

実験のフェーズ

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

  1. Provision.py: 本番インスタンス、ワーカー マシンのクラスタ、および AWS 内のその他の関連インフラストラクチャをスピンアップします。実験用定義から e3-home/runs に自動的に "実行ファイル" を作成します。Bitbucket Server では、独自のインフラストラクチャがある場合にはこの手順をスキップできますが、実行ファイルを作成し、マシンの詳細を最初に入力する必要があります。
  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 を参照してください。

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

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

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

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

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 (および、場合によっては RDSElasticsearch) のスナップショットを作成する必要があります。これは、Atlassian Bitbucket AMI に付属する Atlassian Bitbucket DIY バックアップ スクリプトを使用することで簡単に実現できます。あるいは、bitbucket.org からリポジトリをクローンできます。

AWS で Bitbucket Server 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-fileSnapshot スクリプトに提供すると、スクリプトはインスタンス内のユーザーを検索し、各ユーザーの構成済み公開鍵に秘密鍵をマッピングします。

パスワード

現在、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 システムのみがサポートされます。これを行うには、以下が必要です。

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

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

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

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

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

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

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

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

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

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

  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 ノードの 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/ にコピーします。

実験を実行する

実験を実行する前に、「Atlassian パフォーマンス テスト フレームワーク」ページの指示に従い、前提条件の製品がインストールされていることを確認してください。

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

$ ./Run.py -r my-experiment

実験データを分析する

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

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

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

サポート

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

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


最終更新日 2019 年 8 月 26 日

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

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