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 – 250c3.largeNoGeneral Purpose (SSD)N/A
250 – 500c3.xlargeYesGeneral Purpose (SSD)N/A
500 – 1000c3.2xlargeYesProvisioned IOPS500 – 1000

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

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

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

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

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

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

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

注意

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

  • EBS ボリュームのサイズも I/O パフォーマンスに影響します。一般的に、EBS ボリュームが大きいほど、使用可能な帯域幅のスライスが大きくなります。また、1 秒あたりの I/O 処理 (IOPS) も多くなります。実稼働環境では、最低 100GiB を推奨します。
  • 汎用 (SSD) ボリュームにより維持されている IOPS は Amazon の I/O 容量に制限されます。I/O 容量制限を超過した場合、IOPS はベースライン レベルに制限されます。より大きな汎用 (SSD) ボリュームを使用するか、プロビジョンド IOPS (SSD) ボリュームに切り替える事を検討してください。詳細については、「Amazon EBS Volume Types 」を参照してください。
  • 特に、新しい EBS ボリュームは、各ブロックに初めてアクセスされた際にパフォーマンスが低下します。詳細については、「Pre-Warming Amazon EBS Volumes 」を参照してください。

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

  • Bitbucket Server からクローンやフェッチを行う継続的インテグレーション サーバーの数。
  • Bitbucket Server からクローンやフェッチを頻繁に行うビルド サーバーを数多く設定した場合、Bitbucket Server はより多くのリソースを消費します。
  • 更新をウオッチするために、継続的インテグレーション サーバーがプッシュ型通知を使用している場合、または、リポジトリのポーリングを定期的に行っている場合。
  • 継続的インテグレーション サーバーが完全クローンや浅いクローンを行うように設定されている場合。
  • Bitbucket Server への主要なトラフィックが HTTP、HTTPS、または SSH 経由で行われており、かつ暗号化 Cipher が使用されている場合。
  • リポジトリの数とサイズ。大容量リポジトリが多い場合、Bitbucket Server はより多くのリソースを必要とします。
  • ユーザのアクティビティ。ユーザーが Bitbucket Server の Web インターフェイスを使用して参照、クローン/プッシュ、ならびにプル リクエストの操作を活発に行っている場合、Bitbucket Server はより多くのリソースを消費します。
  • オープンなプル リクエストの数。オープンなプル リクエストの数が多い場合 (特にそれらすべてが大容量かつ頻繁に使用されているリポジトリを対象としている場合)、Bitbucket Server はより多くのリソースを消費します。

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.large23.752 x 16 SSD
c3.xlarge47.52 x 40 SSDYes
c3.2xlarge815/td>2 x 80 SSDYes
c3.4xlarge16302 x 160 SSDYes
c3.8xlarge32602 x 320 SSD
c4.large23.75Yes500
c4.xlarge47.5Yes750
c4.2xlarge815Yes1,000
c4.4xlarge1630Yes2,000
c4.8xlarge3660Yes4,000
i2.xlarge430.51 x 800 SSDYes
i2.2xlarge8612 x 800 SSDYes
i2.4xlarge161224 x 800 SSDYes
i2.8xlarge322448 x 800 SSD
m3.large27.51 x 32 SSD
m3.xlarge4152 x 40 SSDYes
m3.2xlarge8302 x 80 SSDYes
m4.large28Yes450
m4.xlarge416Yes750
m4.2xlarge832Yes1,000
m4.4xlarge1664Yes2,000
m4.10xlarge40160Yes4,000
m4.16xlarge64256Yes10,000
r3.large215.251 x 32 SSD
r3.xlarge430.51 x 80 SSDYes
r3.2xlarge8611 x 160 SSDYes
r3.4xlarge161221 x 320 SSDYes
r3.8xlarge322442 x 320 SSD
x1.32xlarge1281,9522 x 1,920 SSDYes10,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 インスタンスを選択する必要があります。


Related Articles

お気軽にお問い合わせください

お問い合わせ