Bitbucket を AWS 上で稼働する場合の推奨事項

2017-09-25 (Mon)  •  By 伊藤  •  ドキュメント  •  AWS Bitbucket 翻訳

今回の記事は、Bitbucket 管理ドキュメント「Recommendations for running Bitbucket in AWS 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

このページでは、自社管理の Bitbucket Data Center および Bitbucket Server インスタンスを Amazon Web サービス上で稼働する場合のサイジングおよび構成に関する一般的な推奨事項を示します。AWS 上の Bitbucket デプロイメントで最適なパフォーマンスを実現するためには、インスタンスの CPU、メモリおよび I/O リソースが不足しないように準備することが重要です。AWS が提供する最小インスタンス タイプは、Bitbucket の 最小ハードウェア要件 を満たしていないため、実稼働環境にはお薦めできません。ワークロードに対して十分なリソースが供給されない場合、Bitbucket の応答時間が遅くなる、”Bitbucket Server is reaching resource limits ” バナーが表示される、または起動に失敗する可能性があります。

EC2 および EBS インスタンス サイズに関する推奨事項

ヒント : 以下の表は、Bitbucket Server (スタンドアロン構成) または Bitbucket Data Center (クラスター構成) インスタンスを標準的なワークロードで操作する場合に推奨される EC2 および EBS 構成の一覧です。

スケールと耐障害性の両方を実現する構成のインスタンスを配置する場合は、Bitbucket Data Center の導入を推奨します。「AWS Quick Start 」ならびに関連する CloudFormation テンプレートでは、推奨される設定値、ノード サイズ オプション、およびスケーリング パラメーターが提供されています。

Bitbucket Server

アクティブ ユーザー EC2 インスタンス タイプ EBS 最適化 EBS ボリューム タイプ IOPS
0 – 250 c3.large No General Purpose (SSD) N/A
250 – 500 c3.xlarge Yes General Purpose (SSD) N/A
500 – 1000 c3.2xlarge Yes Provisioned IOPS 500 – 1000

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

アクティブ ユーザー EC2 インスタンス タイプ ノードの推奨数
0 – 250 c3.large 1-2*
250 – 500 c3.xlarge 1-2*
500 – 1000 c3.2xlarge 2
1000 – massive scale c3.4xlarge+ 3+

* 高可用性のために、最低 2 クラスター ノード以上の配置を推奨します。

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

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

アクティブ ユーザー EC2 インスタンス タイプ EBS ボリューム タイプ IOPS
0 – 250 m4.large General Purpose (SSD) N/A
250 – 500 m4.xlarge General Purpose (SSD) N/A
500 – 1000 m4.2xlarge Provisioned IOPS 500 – 1000
1000 – massive scale m4.4xlarge+ Provisioned IOPS 1000+
注意 : 現時点では、Bitbucket の共有ホーム ディレクトリは Amazon Elastic File System (EFS) をサポートして いません

詳細については、「Amazon EC2 instance types 」、「Amazon EBS–Optimized Instances」、および「Amazon EBS Volume Types」を参照してください。

注意

ホスティング ワークロードが高い Bitbucket インスタンスにおいては、多くの場合、I/O パフォーマンスが制限要因となります。EBS ボリューム オプションンに細心の注意を払うことをお薦めします。特に以下の点に注意してください。

上記の推奨事項は、指定したアクティブ ユーザー数の 標準的な ワークロードを基準としています。実際の Bitbucket インスタンスのリソース要件は、様々な要因により著しく異なる可能性があります。以下はその要因の例です。

Bitbucket Server のリソース要件の詳細については、「Scaling Bitbucket Server 」および「Scaling Bitbucket Server for Continuous Integration performance 」を参照してください。

その他のサポートされているインスタンス サイズ

以下の Amazon EC2 インスタンス も Bitbucket Server の 最小ハードウェア要件 を満たしているか、または超えています。これらのインスタンスは、CPU、メモリ、および I/O パフォーマンスがを異なる組み合わせで提供しています。したがって、標準よりも CPU やメモリをより多く必要とする、または I/O をより集中的に行うなどのワークロードの要求に対応できます。

モデル vCPU メモリ (GiB) インスタンス ストア EBS 最適化の利用 専用 EBS スループット (Mbps)
c3.large 2 3.75 2 x 16 SSD
c3.xlarge 4 7.5 2 x 40 SSD Yes
c3.2xlarge 8 15/td>

2 x 80 SSD Yes
c3.4xlarge 16 30 2 x 160 SSD Yes
c3.8xlarge 32 60 2 x 320 SSD
c4.large 2 3.75 Yes 500
c4.xlarge 4 7.5 Yes 750
c4.2xlarge 8 15 Yes 1,000
c4.4xlarge 16 30 Yes 2,000
c4.8xlarge 36 60 Yes 4,000
i2.xlarge 4 30.5 1 x 800 SSD Yes
i2.2xlarge 8 61 2 x 800 SSD Yes
i2.4xlarge 16 122 4 x 800 SSD Yes
i2.8xlarge 32 244 8 x 800 SSD
m3.large 2 7.5 1 x 32 SSD
m3.xlarge 4 15 2 x 40 SSD Yes
m3.2xlarge 8 30 2 x 80 SSD Yes
m4.large 2 8 Yes 450
m4.xlarge 4 16 Yes 750
m4.2xlarge 8 32 Yes 1,000
m4.4xlarge 16 64 Yes 2,000
m4.10xlarge 40 160 Yes 4,000
m4.16xlarge 64 256 Yes 10,000
r3.large 2 15.25 1 x 32 SSD
r3.xlarge 4 30.5 1 x 80 SSD Yes
r3.2xlarge 8 61 1 x 160 SSD Yes
r3.4xlarge 16 122 1 x 320 SSD Yes
r3.8xlarge 32 244 2 x 320 SSD
x1.32xlarge 128 1,952 2 x 1,920 SSD Yes 10,000

すべての AWS インスタンス タイプに関し、Bitbucket Server は “large”、もしくはそれ以上のインスタンスのみをサポートします。”Micro”、”small”、および “medium”サイズのインスタンスは Bitbucket の 最小ハードウェア要件 を満たしていません。そのため、本番環境での使用もお勧めしません。

Bitbucket は、D2 インスタンス バースト パフォーマンス (T2) インスタンス 、ならびに 旧世代インスタンス をサポートしていません。

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

応用 : Bitbucket の監視によるインスタンス サイズの調整方法

ヒント : このセクションは、インスタンスのリソース消費を監視し、かつ、この情報をインスタンス サイズの指針として利用したい上級ユーザー向けです。規模を拡大した際のパフォーマンスが懸念事項である場合は、Bitbucket Data Center をエラスティック スケールで配置することを推奨します。これにより、負荷が変動したり、増大したりした場合に単一ノードでいかに対応すべきかを心配する必要性が減ります。詳細については、「AWS Quick Start guide for Bitbucket Data Center 」を参照してください。

上記推奨事項は、標準的な ワークロードの場合の指針です。各 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 <>aws-monitor.gnuplot
done

cat >>aws-monitor.gnuplot <>aws-monitor.gnuplot
done

cat >>aws-monitor.gnuplot <>aws-monitor.gnuplot
done

cat >>aws-monitor.gnuplot <>aws-monitor.gnuplot
done

gnuplot 

標準的な Bitbucket Server インスタンス上で実行した場合、このスクリプトは以下のようなグラフを生成します。

このようなグラフの情報を使用することで、インスタンスで CPU、ネットワーク、または I/O リソースの供給が過剰である、または不足しているかを判断できます。

使用可能な CPU の最大値をインスタンスが頻繁に飽和する場合 (インスタンス サイズにおけるコア数を考慮)、より大きな CPU 数の EC2 インスタンスが必要であることを示しています (注意 : あなたのインスタンスが稼働する同一物理ハードウェアの CPU サイクルを Amazon 環境の他のテナントが消費する場合、小さい EC2 インスタンス サイズに関する Amazon CloudWatch の CPU 使用率レポートは、"うるさい隣人" 現象の影響をある程度受けている可能性があります)。

お使いのインスタンスが頻繁に利用可能な EBS ボリュームを超過している場合、または、頻繁に I/O 要求をキューに登録している場合、EBS 最適化インスタンスへのアップグレードが必要であることを示しています。さらには、EBS ボリューム上の IOPS 供給を増大する必要があるかもしれません。詳細については、「EBS Volume Types 」を参照してください。

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

  Previous Next  

関連記事