クラウド
Data Center と Server 5.0
バージョン

Bitbucket を AWS で実行する場合の推奨事項

Bitbucket Server と AWS の使用を開始する

このページの内容

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

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

コミュニティに質問


このページでは、Amazon Web Services でセルフマネージ型の Bitbucket Data Center および Bitbucket Server インスタンスを実行するための、一般的なサイジングと構成の推奨事項について説明します。AWS で Bitbucket デプロイを最大限に活用するには、インスタンスの CPU、メモリ、I/O リソースを十分にプロビジョニングすることが重要です。AWS が提供する最小のインスタンス タイプは Bitbucket の最低ハードウェア要件を満たすことができないため、本番環境では推奨されません。ワークロードに対して十分なリソースを用意しないと、Bitbucket の応答時間が遅くなったり、Bitbucket Server のリソース上限に達したり、完全に起動しなかったりする可能性があります。

推奨される EC2 および EBS インスタンスのサイズ

以下の表は、通常のワークロード下で Bitbucket Server (スタンドアロン) または Bitbucket Data Center (クラスタ化) インスタンスを運用するために推奨される EC2 および EBS 構成です。

スケールと復元力の両方を考慮したインスタンスをデプロイするには、Bitbucket Data Center をデプロイすることをお勧めします。AWS クイックスタートおよび関連付けられた CloudFormation テンプレートでは、推奨の既定設定、ノード サイズ オプション、およびスケーリング パラメータが提供されます。

On this page

Bitbucket Server

アクティブ ユーザー数EC2 インスタンス タイプEBS 最適化EBS ボリューム タイプIOPS

0 – 250

c3.largeいいえ汎用 (SSD)N/A
250 – 500c3.xlargeはい汎用 (SSD)N/A
500 ~ 1000c3.2xlargeはいプロビジョンド IOPS500 – 1000

Bitbucket Data Center (クラスタ ノード)

アクティブ ユーザー数EC2 インスタンス タイプ推奨されるノード数

0 – 250

c3.large1-2*
250 – 500c3.xlarge1-2*
500 – 1000c3.2xlarge2
1000 – 大規模c3.4xlarge+3+

* 高可用性のためには、最低でも 2 つ以上のクラスター ノードをデプロイすることをお勧めします。

Bitbucket Data Center (共有ファイル サーバ)

これらの推奨事項では、単一の EC2 インスタンスに、クラスタの共有 NFS サーバとして機能する EBS ボリュームが接続されていることを前提としています。

アクティブ ユーザー数EC2 インスタンス タイプEBS ボリューム タイプIOPS

0 – 250

m4.large汎用 (SSD)N/A
250 – 500m4.xlarge汎用 (SSD)N/A
500 – 1000m4.2xlargeプロビジョンド IOPS500 – 1000
1000 – 大規模m4.4xlarge+プロビジョンド IOPS1000+

(error) The Amazon Elastic File System (EFS) is not supported for Bitbucket's shared home directory due to poor performance of git operations.


詳細については、「Amazon EC2 インスタンス タイプ」、「Amazon EBS – 最適化されたインスタンス」、および「Amazon EBS ボリューム タイプ」を参照してください。

注意

ホスティング負荷が高い Bitbucket インスタンスでは、I/O パフォーマンスが制限要因となることが多くあります。EBS ボリューム オプションの次の点に特に注意することをおすすめします。

  • EBS ボリュームのサイズも I/O パフォーマンスに影響します。一般に、EBS ボリュームを大きくすると、利用可能な帯域幅および 1 秒あたりの I/O 操作数のスライスが大きくなります。本番環境では最低でも 100 GiB が推奨されます。
  • 汎用 (SSD) ボリュームによって持続可能な IOPS は、Amazon の I/O クレジットによって制限されます。I/O クレジット残高を使いきると、IOPS はベースライン レベルに制限されます。より大きな汎用 (SSD) ボリュームを使用したり、プロビジョンド IOPS (SSD) ボリュームに切り替えたりすることを検討する必要があります。詳細については、「Amazon EBS ボリューム タイプ」を参照してください。
  • 特に新しい EBS ボリュームでは、各ブロックが初めてアクセスされた際にパフォーマンスが低下します。詳細については、「Amazon EBS ボリュームの事前ウォーミング」を参照してください。

上記の推奨事項は、指定された数のアクティブ ユーザーでの一般的なワークロードを基準にしています。実際の Bitbucket インスタンスのリソース要件は、次のような多数の要因によって大きく異なります。

  • Bitbucket Server からクローンまたはフェッチする継続的インテグレーション サーバの数。多数のビルド サーバが Bitbucket Server から頻繁にクローンまたはフェッチするように設定されている場合、Bitbucket Server はより多くのリソースを使用します。
  • 継続的インテグレーション サーバーがプッシュ モード通知を使用しているか、更新をウォッチするために定期的にリポジトリをポーリングしているか
  • 継続的インテグレーション サーバーがフル クローンを実行するように設定されているか、シャロー クローンを実行するように設定されているか
  • Bitbucket Server への主なトラフィックが、HTTP、HTTPS、または SSH のどれに該当するか、および使用されている暗号化方式
  • リポジトリの数とサイズ。多数の大きなリポジトリを運用している場合、Bitbucket Server はより多くのリソースを使用します
  • ユーザーのアクティビティ。ユーザーがプル リクエストを参照、クローン、プッシュ、および操作するために Bitbucket Server の Web インターフェイスを積極的に使用している場合、Bitbucket Server はより多くのリソースを使用します
  • オープンなプル リクエストの数。オープンなプル リクエストが大量にある場合、特にそれらのすべてが大規模でビジーなリポジトリの同じブランチを宛先にしている場合、Bitbucket Server はより多くのリソースを使用します

Bitbucket Server のリソース要件の詳細については、「Bitbucket Server のスケーリング」および「継続的インテグレーション パフォーマンスのための Bitbucket Server のスケーリング」を参照してください。

その他のサポート対象のインスタンス サイズ

次の Amazon EC2 インスタンスも、Bitbucket Server の最低ハードウェア要件を満たしています。これらのインスタンスでは、CPU、メモリ、I/O パフォーマンスがさまざまなバランスで提供されており、CPU、メモリ、I/O が通常よりも集中するワークロードで使用できます。 

モデルvCPUメモリ (GiB)インスタンス ストア (GB)

EBS
最適化を
利用できるか

専用 EBS
スループット
(Mbps)
c3.large23.752 x 16 SSD--
c3.xlarge47.52 x 40 SSDはい-
c3.2xlarge8152 x 80 SSDはい-
c3.4xlarge16302 x 160 SSDはい-
c3.8xlarge32602 x 320 SSD--
c4.large23.75-はい500
c4.xlarge47.5-はい750
c4.2xlarge815-はい1,000
c4.4xlarge1630-はい2,000
c4.8xlarge3660-はい4,000
i2.xlarge430.51 x 800 SSDはい-
i2.2xlarge8612 x 800 SSDはい-
i2.4xlarge161224 x 800 SSDはい-
i2.8xlarge322448 x 800 SSD--
m3.large27.51 x 32 SSD--
m3.xlarge4152 x 40 SSDはい-
m3.2xlarge8302 x 80 SSDはい-
m4.large28-はい450
m4.xlarge416-はい750
m4.2xlarge832-はい1,000
m4.4xlarge1664-はい2,000
m4.10xlarge40160-はい4,000
m4.16xlarge64256-はい10,000
r3.large215.251 x 32 SSD--
r3.xlarge430.51 x 80 SSDはい-
r3.2xlarge8611 x 160 SSDはい-
r3.4xlarge161221 x 320 SSDはい-
r3.8xlarge322442 x 320 SSD--
x1.32xlarge1281,9522 x 1,920 SSDはい10,000

すべての AWS インスタンス タイプで、Bitbucket Server は "large" 以上のインスタンスのみをサポートしています。"Micro"、"small"、"medium" サイズのインスタンスは Bitbucket の最低ハードウェア要件を満たすことができないため、本番環境では推奨されません。 

Bitbucket では、D2 インスタンス、Burstable Performance (T2) インスタンス、または旧世代のインスタンスはサポートされていません。 

インスタンス ストア デバイスが利用可能なインスタンス タイプでは、Bitbucket AMI から起動された Bitbucket インスタンスにより、Bitbucket Server の一時ファイルとキャッシュを含む 1 つのインスタンス ストアが構成されます。インスタンス ストアは EBS ボリュームよりも高速になる可能性がありますが、インスタンスが停止または再起動された場合にデータが保持されません。インスタンス ストアを使用すると、パフォーマンスを改善し、EBS ボリュームの負荷を削減できます。詳細については、「Amazon EC2 インスタンス ストア」を参照してください。 

高度なヒント: Bitbucket を監視してインスタンス サイジングを調整する

このセクションは、インスタンスのリソース消費を監視し、この情報をインスタンス サイジングのガイドとして使用したいユーザーを対象としています。大規模環境でのパフォーマンスが懸念されている場合、Bitbucket Data Center をエラスティック スケーリングでデプロイをおすすめします。これは、単一ノードで流動的な負荷や増大する負荷に対応する方法について心配する必要がないデプロイです。詳細については、「Bitbucket Data Center 向け AWS クイック スタート ガイド」を参照してください。

上述の推奨事項は、一般的なワークロードに関するガイダンスを提供しています。それぞれの Bitbucket Server インスタンスのリソース消費は、ワークロードの組み合わせによって異なります。Bitbucket Server インスタンスが AWS で十分にプロビジョニングされているかどうかを判断するための最も信頼できる方法は、Amazon CloudWatch でリソースの使用量を定期的に監視することです。これによって、Bitbucket Server が消費している CPU、I/O、およびネットワーク リソースの実際の量の統計情報が得られます。 

以降の単純な BASH スクリプトの例では次のものを使用します。

これらを使用して、CPU、I/O、およびネットワーク統計を収集し、インスタンス サイジングの決定に役立つシンプルなグラフで表示します。 

ここをクリックして展開... 
#!/bin/bash
# Example AWS CloudWatch monitoring script
# Usage:
#   (1) Install gnuplot and jq (minimum version 1.4)
#   (2) Install AWS CLI (http://docs.aws.amazon.com/cli/latest/userguide/installing.html) and configure it with
#       credentials allowing cloudwatch get-metric-statistics
#   (3) Replace "xxxxxxx" in volume_ids and instance_ids below with the ID's of your real instance
#   (4) Run this script

export start_time=$(date -v-14d +%Y-%m-%dT%H:%M:%S)
export end_time=$(date +%Y-%m-%dT%H:%M:%S)
export period=1800
export volume_ids="vol-xxxxxxxx"    # REPLACE THIS WITH THE VOLUME ID OF YOUR REAL EBS VOLUME
export instance_ids="i-xxxxxxxx"    # REPLACE THIS WITH THE INSTANCE ID OF YOUR REAL EC2 INSTANCE

# Build lists of metrics and datafiles that we're interested in
ebs_metrics=""
ec2_metrics=""
cpu_datafiles=""
iops_datafiles=""
queue_datafiles=""
net_datafiles=""
for volume_id in ${volume_ids}; do
  for metric in VolumeWriteOps VolumeReadOps; do
    ebs_metrics="${ebs_metrics} ${metric}"
    iops_datafiles="${iops_datafiles} ${volume_id}-${metric}"
  done
done
for volume_id in ${volume_ids}; do
  for metric in VolumeQueueLength; do
    ebs_metrics="${ebs_metrics} ${metric}"
    queue_datafiles="${queue_datafiles} ${volume_id}-${metric}"
  done
done
for instance_id in ${instance_ids}; do
  for metric in DiskWriteOps DiskReadOps; do
    ec2_metrics="${ec2_metrics} ${metric}"
    iops_datafiles="${iops_datafiles} ${instance_id}-${metric}"
  done
done
for instance_id in ${instance_ids}; do
  for metric in CPUUtilization; do
    ec2_metrics="${ec2_metrics} ${metric}"
    cpu_datafiles="${cpu_datafiles} ${instance_id}-${metric}"
  done
done
for instance_id in ${instance_ids}; do
  for metric in NetworkIn NetworkOut; do
    ec2_metrics="${ec2_metrics} ${metric}"
    net_datafiles="${net_datafiles} ${instance_id}-${metric}"
  done
done

# Gather the metrics using AWS CLI
for volume_id in ${volume_ids}; do
  for metric in ${ebs_metrics}; do
    aws cloudwatch get-metric-statistics --metric-name ${metric} \
                                         --start-time ${start_time} \
                                         --end-time ${end_time} \
                                         --period ${period} \
                                         --namespace AWS/EBS \
                                         --statistics Sum \
                                         --dimensions Name=VolumeId,Value=${volume_id} | \
      jq -r '.Datapoints | sort_by(.Timestamp) | map(.Timestamp + " " + (.Sum | tostring)) | join("\n")' >${volume_id}-${metric}.data
  done
done

for metric in ${ec2_metrics}; do
  for instance_id in ${instance_ids}; do
    aws cloudwatch get-metric-statistics --metric-name ${metric} \
                                         --start-time ${start_time} \
                                         --end-time ${end_time} \
                                         --period ${period} \
                                         --namespace AWS/EC2 \
                                         --statistics Sum \
                                         --dimensions Name=InstanceId,Value=${instance_id} | \
      jq -r '.Datapoints | sort_by(.Timestamp) | map(.Timestamp + " " + (.Sum | tostring)) | join("\n")' >${instance_id}-${metric}.data
  done
done

cat >aws-monitor.gnuplot <<EOF
set term pngcairo font "Arial,30" size 1600,900
set title "IOPS usage"
set datafile separator whitespace
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%SZ"
set grid
set ylabel "IOPS"
set xrange ["${start_time}Z":"${end_time}Z"]
set xtics "${start_time}Z",86400*2 format "%d-%b"
set output "aws-monitor-iops.png"
plot \\
EOF
for datafile in ${iops_datafiles}; do
  echo "  \"${datafile}.data\" using 1:(\$2/${period}) with lines title \"${datafile}\", \\" >>aws-monitor.gnuplot
done

cat >>aws-monitor.gnuplot <<EOF

set term pngcairo font "Arial,30" size 1600,900
set title "IO Queue Length"
set datafile separator whitespace
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%SZ"
set grid
set ylabel "Queue Length"
set xrange ["${start_time}Z":"${end_time}Z"]
set xtics "${start_time}Z",86400*2 format "%d-%b"
set output "aws-monitor-queue.png"
plot \\
EOF
for datafile in ${queue_datafiles}; do
  echo "  \"${datafile}.data\" using 1:2 with lines title \"${datafile}\", \\" >>aws-monitor.gnuplot
done

cat >>aws-monitor.gnuplot <<EOF

set term pngcairo font "Arial,30" size 1600,900
set title "CPU Utilization"
set datafile separator whitespace
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%SZ"
set grid
set ylabel "%"
set xrange ["${start_time}Z":"${end_time}Z"]
set xtics "${start_time}Z",86400*2 format "%d-%b"
set output "aws-monitor-cpu.png"
plot \\
EOF
for datafile in $cpu_datafiles; do
  echo "  \"${datafile}.data\" using 1:2 with lines title \"${datafile}\", \\" >>aws-monitor.gnuplot
done

cat >>aws-monitor.gnuplot <<EOF

set term pngcairo font "Arial,30" size 1600,900
set title "Network traffic"
set datafile separator whitespace
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%SZ"
set grid
set ylabel "MBytes/s"
set xrange ["${start_time}Z":"${end_time}Z"]
set xtics "${start_time}Z",86400*2 format "%d-%b"
set output "aws-monitor-net.png"
plot \\
EOF
for datafile in $net_datafiles; do
  echo "  \"${datafile}.data\" using 1:(\$2/${period}/1000000) with lines title \"${datafile}\", \\" >>aws-monitor.gnuplot
done

gnuplot <aws-monitor.gnuplot

このスクリプトを通常の Bitbucket Server インスタンスで実行すると、次のようなグラフが生成されます。

このようなグラフの情報を使用して、CPU、ネットワーク、または I/O リソースがインスタンスでオーバー プロビジョニングかアンダー プロビジョニングかを判断できます。 

インスタンスが頻繁に最大利用可能 CPU 使用率 (インスタンス サイズのコア数を考慮) に達する場合、CPU 数が多い EC2 インスタンスが必要なことを示している場合があります (Amazon 環境の他のテナントがあなたのインスタンスが実行されているものと同じ物理ハードウェアで CPU サイクルを消費している場合、Amazon CloudWatch で報告される小さい EC2 インスタンス サイズの CPU 使用率は "ノイジー ネイバー" 現象の影響をある程度受ける可能性があります)。 

インスタンスが EBS ボリュームで利用可能な IOPS を頻繁に超えていたり、I/O リクエストが頻繁にキューに入れられたりする場合、EBS 最適化インスタンスにアップグレードする必要がある、および / または EBS ボリュームのプロビジョンド IOPS を増やす必要があることを示している場合があります。詳細については、「EBS ボリューム タイプ」を参照してください。 

インスタンスがネットワーク トラフィックによって頻繁に制限される場合、利用可能なネットワーク帯域幅のスライスが大きい EC2 インスタンスを選択する必要があることを示している場合があります。 

最終更新日: 2019 年 2 月 6 日

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

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.