AWS でのエンタープライズ Bitbucket インスタンスの推奨インフラストラクチャ
デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりました。テンプレートは今後も利用できますが、保守や更新は行われません。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。
AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。
ご自身のインスタンスの負荷プロファイルを把握しておくことは、インスタンスの成長を計画したり、メトリクスの増長を確認したり、インスタンスを適切なサイズに保ったりするのに役立ちます。Bitbucket Data Center サイズ プロファイルでは、インスタンスが "Small"、"Medium"、"Large"、または "XLarge" のどれに該当するかを確認するためのシンプルなガイドラインを示しています。これらのサイズ プロファイルはさまざまな Server および Data Center のケース スタディに基づいており、あらゆるインフラストラクチャ サイズおよび構成を網羅しています。
負荷が増加して "Large" または "XLarge" サイズに近づいてきたら、定期的にインフラストラクチャを評価する必要ががあります。環境内でパフォーマンスや安定性の問題が発生し始めたら、クラスタ (またはクラスタ対応) インフラストラクチャへの移行を検討します。これを行う際は、効果的に行うための方法は常に明確であるとは限らないということに注意します。たとえば、成長しつつある "Medium" サイズのインスタンスにアプリケーション ノードを追加してもパフォーマンスが向上するとは限りません (低下する場合もあります)。
アトラシアンではお客様によるインフラストラクチャの設定または成長の計画立案をサポートするため、一般的な "Medium"、"Large" および "XLarge" サイズのインスタンスで一連のパフォーマンス テストを実施しました。これらのテストは、ご利用のクラスタ化されたデプロイメントのアプリケーションおよびデータベース ノードに有用なデータ主導の推奨事項を確認できるように設計されています。これらの推奨設定は、プロジェクト化されたコンテンツおよびトラフィックのサイズに合った適切なクラスタ化環境の計画に役立てることができます。
大規模なリポジトリはパフォーマンスに影響を与える可能性がある点にご注意ください。
定期的にパフォーマンスを監視することをおすすめします。
アプローチ
すべてのテストを AWS 環境で実施しました。これにより、複数のテストを簡単に定義および自動化し、大規模で信頼性の高いテスト結果のサンプルを取得することができます。
テスト インフラストラクチャの各部分は、すべての AWS ユーザーが利用できる標準の AWS コンポーネントからプロビジョニングされています。つまり、お客様はアトラシアンの推奨設定を簡単にデプロイすることができます。また、AWS ドキュメントで仕様を確認できます。お客様の組織が別のクラウド プラットフォームまたは特注のクラスタ ソリューションを使用することを希望している場合、ここで同等のコンポーネントや構成を見つけることができます。
Bitbucket Data Center デプロイ用 AWS クイック スタートを使用することもできますが、アトラシアンではクイック スタート テンプレートのサポートや保守を終了しています。代わりに、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをおすすめしています。 Kubernetes へのデプロイについて詳しくはこちらをご確認ください。
考慮事項
幅広い構成で Bitbucket のベンチマーク テストを効果的に行うため、テストは簡単にセットアップしてレプリケートできるよう設計されています。ご利用の本番環境と弊社のベンチマークを比較する場合、次の点を考慮してください。
コア製品に最適な設定を見つけることに焦点を当てていたため、テスト インスタンスへのアプリのインストールは行っていません。お客様のインフラストラクチャを設計する際には、インストールしたいアプリが与える影響を考慮する必要があります。
すべてのテストにおいて、RDS を既定設定で使用しました。これにより、最小限のセットアップと調整で一貫した結果を実現できます。
アトラシアンのテスト環境では、同じサブネット上でホストされている専用の AWS インフラストラクチャを使用しています。これによりネットワーク遅延を短縮できます。
アトラシアンでは Trikit という内部テスト ツールを使用して、git パケットの流入のシミュレーションを実施しました。これにより、クライアント側の git パフォーマンスを測定しなくても、git リクエストの速度を測定しました。また、ツールは git データを受信して復号化するだけなので、テストでは git refs を解凍していません。
git 操作のパフォーマンス (応答時間) は、リポジトリ サイズの影響を大きく受けます。アトラシアンのテスト リポジトリのサイズは平均 14.2 MB でした。リポジトリのサイズが大きくなると、より性能に優れたハードウェアが必要になる可能性があることが推測されます。
AWS の制限により、テストを開始する前に NFS サーバー上の EBS ボリューム (ストレージ ブロック) を初期化しました。ディスクを初期化しない場合、ディスクの遅延が大幅に増加し、テスト インフラストラクチャのパフォーマンスが数時間低下します。
各テスト インスタンスで分析を有効化し、使用状況データを収集しました。詳しくは、「データ収集設定の変更」を参照してください。
テスト手法
各テストでは、異なる AWS 環境にある Bitbucket データ セットに同じ量のトラフィックを適用しました。次のコンポーネントに最適な構成を見つけるために設計された、3 つの一連のテストを実行しました。
Bitbucket アプリケーション ノード
データベース ノード
NFS ノード
ベンチマークの信頼性を確保するため、EBS ボリュームを初期化し、各構成を 3 時間テストしました。各テストを通じて、安定した応答時間を確認しました。Large インスタンスのテストには Bitbucket Data Center 5.16 を使用し、XLarge には Bitbucket Data Center 6.4 を使用しました。v1 プロトコルを実行しているカスタム ライブラリ (Trikit) を使用して Git トラフィックのシミュレーションを行いました。
データセット
ベンチマーク
テストでは、次のベンチマーク メトリックを使用しました。
ベンチマーク メトリック
しきい値
理由
Git スループット、または 1 時間あたりの git ホスティング操作 (フェッチ / クローン / プッシュ) の数
Large の場合は 32,700 (最小)
XLarge の場合は 65,400 (最小)
高いほうがよい
これらのしきい値は、Bitbucket Data Center の負荷プロファイルで定義されたトラフィックの上限です。git トラフィックがスパイクしやすいことを受け、これらの上限を設定しました。
平均 CPU 使用率 (アプリケーション ノードの場合)
75% (最大)、低いほうがよい
アプリケーション ノードの平均 CPU 使用率が 75 % 以上に達すると、Bitbucket のアダプティブ スロットリングは、対話型ユーザー向けのアプリケーションの応答性を確保するために、Git のホスティング操作のキューイングを開始します。これにより、Git の速度が低下します。
安定性
オフラインになるノードがない
インフラストラクチャが負荷の処理に不十分な場合、ノードがクラッシュする可能性があります。
テスト トラフィックでは、git ホスティング操作の量を調節するために、スリープ時間を固定しました。つまり、ベンチマークされた git スループットは、各構成で処理できる最大値を表すものではありません。アーキテクチャ
各構成は、AWS 上に新しくデプロイされた Bitbucket Data Center インスタンスでテストされました。各構成は次の共通の構造にしたがっています。
機能
ノードの数
仮想マシンのタイプ
注意
アプリケーション ノード
変数
m5.xlarge
m5.2xlarge
m5.4xlarge
m5.12xlarge
m5.24xlarge
m5.xlarge (16 GB の RAM) のテストでは、8 GB の JVM ヒープを使用しました。それ以外では 12 GB の JVM ヒープを使用しました。最大ヒープ数 (Xms) はすべてのテストで 1 G に設定しました。
ほとんどのインスタンスでは、小規模な JVM ヒープ (2 ～ 3 GB) の使用で十分であることを確認しています。
また、Git 操作はメモリの消費量が多く、Java 仮想マシンの外部で実行されることにご注意ください。Bitbucket Data Center のスケーリングの詳細を参照してください。
各 Bitbucket アプリケーションおよびでローカル ストレージに 30 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 100 IOPS で、3,000 IOPS まで拡張可能です。
データベース
1
m5.xlarge
m5.2xlarge
m5.4xlarge
Amazon RDS Postgresql バージョン 9.4.15 を既定設定で使用しました。各テストは 1 つのノードのみを対象としました。
NFS ストレージ
1
m5.4xlarge
m5.2xlarge
m5.xlarge
NFS サーバーでは、ストレージに 900 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 2700 IOPS で、3,000 IOPS まで拡張可能です。前述のように、各テストの開始時にこのボリュームを初期化しました。
Bitbucket Data Center の共有ファイル サーバーのセットアップの詳細については、「Bitbucket Data Center のインストール」の「ステップ 2. 共有ファイル システムのプロビジョニング」をご覧ください。このセクションでは、Bitbucket Data Center 用の NFS のセットアップの要件や推奨事項について説明しています。Load balancer
1
AWS Elastic Load Balancer を使用しました。パフォーマンス テスト時、アプリケーション ロード バランサでは SSH トラフィックを処理していません。
各コンポーネントに最適な構成を見つけるため、実際の "Large" および "XLarge" サイズの Bitbucket Data Center インスタンスで複数のケース スタディを実施しました。特に m5 シリーズの仮想マシン タイプ (汎用インスタンス) が多く使用されていることを確認したため、アプリケーション ノードではさまざまなシリーズの構成のベンチマークに重点を置きました。
"Large" サイズのインスタンスの推奨設定
アトラシアンではベンチマークを分析し、次の最適構成を導きました。
パフォーマンスと費用対効果が最も高い構成
コンポーネント
推奨事項
Application nodes
m5.4xlarge ノード x 4
データベース ノード
m5.2xlarge
NFS ノード
m5.2xlarge
この構成のパフォーマンス
Git スループット: 45,844 /時間
1 時間あたりのコスト 1: $4.168
平均 CPU 使用率: 45%
1 "Large" サイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Bitbucket アプリケーションとデータベース、および NFS ノードに使用したノードの価格のみを計算します。アプリケーションのその他のコンポーネント (共有ホーム、アプリケーション ロード バランサなど) の使用コストは含まれません。
これらの金額は USD で、2019 年 7 月時点の値です。
パフォーマンスの安定性は、インスタンスの平均 CPU 使用率がしきい値である 75 % からどの程度逸脱しているかで測定しました。前述のように、このしきい値に達すると、git 操作の速度が低下し始めます。インスタンスが 75 % から低下するとそれだけ、トラフィックのスパイクによって速度が低下する可能性が低くなります。
ただし、より優れたパフォーマンスを提供する、大きなサイズのハードウェア (m5.12xlarge など) を使用することによるデメリットはありません。
低コスト構成
また、1 時間あたり $2.84 で許容可能なパフォーマンスを提供する低コスト構成も導きました。
コンポーネント
推奨事項
Application nodes
m5.4xlarge x 3
データベース ノード
m5.xlarge
NFS ノード
m5.xlarge
この低コスト構成では、1時間あたりの git ホスティング呼び出しが 43,099 回となり、最適な構成よりも Git スループットが低くなります。それでも、1時間あたりの git ホスティング呼び出しが 32,700 回の最低しきい値を上回っています。コストのトレードオフになるのはフォールト トレランスです。インスタンスで 1 つのアプリケーション ノードが失われると、CPU 使用率は 85%に急上昇し、最大しきい値を超えます。インスタンスは存続しますが、パフォーマンスは低下します。
XLarge インスタンスの推奨設定
アトラシアンではベンチマークを分析し、次の最適構成を導きました。
パフォーマンスが最も高い構成
コンポーネント
推奨事項
Application nodes
m5.12xlarge x 4
データベース ノード
m5.2xlarge
NFS ノード
m5.2xlarge
この構成のパフォーマンス
Git スループット: 75,860 /時間
1 時間あたりのコスト 1: $10.312
平均 CPU 使用率: 65%
パフォーマンスの安定性は、インスタンスの平均 CPU 使用率がしきい値である 75 % からどの程度逸脱しているかで測定しました。前述のように、このしきい値に達すると、git 操作の速度が低下し始めます。インスタンスが 75 % から低下するとそれだけ、トラフィックのスパイクによって速度が低下する可能性が低くなります。
1 "XLarge" サイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Bitbucket アプリケーションとデータベース、および NFS ノードに使用したノードの価格のみを計算します。アプリケーションのその他のコンポーネント (共有ホーム、アプリケーション ロード バランサなど) の使用コストは含まれません。
これらの金額は USD で、2019 年 7 月時点の値です。
低コスト構成
また、1 時間あたり $7.02 で良好なパフォーマンスを提供する低コスト構成も導きました。
コンポーネント
推奨事項
Application nodes
m5.8xlarge x 4
データベース ノード
m5.2xlarge
NFS ノード
m5.xlarge
この低コスト構成では、1時間あたりの git ホスティング呼び出しが 74,275 回となり、最適な構成よりも Git スループットが低くなります。それでも、1 時間あたりの git ホスティング呼び出しが、しきい値である 65,400 回を上回っています。コストのトレードオフになるのはフォールト トレランスです。m5.8xlargex 3 ノードではタイムアウトやエラーが観察されたため、アプリケーション ノードがダウンするとパフォーマンスが低下する可能性があります。
次の表は、しきい値である 1 時間あたり 32,500 の git ホスティング操作を超え、CPU 使用率が 75％ を下回り、ノードのクラッシュが発生しなかったすべてのテスト構成を示しています。各構成をスループットの降順に並べました。
Application nodes
データベース ノード
NFS ノード
Git スループット
1 時間あたりのコスト
m5.12xlarge x 4
m5.2xlarge
m5.2xlarge
75,860
$10.31
m5.4xlarge x 8
m5.2xlarge
m5.2xlarge
73,374
$7.24
m5.8xlarge x 4
m5.2xlarge
m5.xlarge
74,275
$7.02
m5.4xlarge x 6
m5.2xlarge
m5.2xlarge
71,872
$5.70
m5.12xlarge x 3
m5.2xlarge
m5.2xlarge
66,660
$8.01
アプリケーション ノードのテスト結果
Large サイズのインスタンス最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけることに焦点を当てました。これらのテストでは、データベースに 1 つの m4.4xlarge ノード、NFS サーバーに 1 つの m4.4xlarge ノードを使用しました。
ベンチマークを見ると、m5.4xlarge (16 CPU) および m5.12xlargeノード (46 CPU) を使用した場合に最高の git スループットが実現されています。m5.4xlarge には 3 つ以上のノード、m5.12xlarge には 2 つのノードが必要です。
次のアプリケーション ノード構成では、CPU の利用率は 30 % に過ぎません。
m5.4xlarge x 6
m5.12xlarge x 2
これは、両方の構成がオーバープロビジョニングされていることを示しています。アプリケーションには 3 つまたは 4 つの m5.4xlarge ノードを使用するほうが費用対効果が高くなります。
ただし、3 ノードの m5.4xlarge のセットアップでは、いずれかのノードで不具合が発生した場合、CPU 使用量は ~85 % になります。このため、フォールト トレランスを向上させるために、4 ノードの m5.4xlargeのセットアップを使用することをおすすめします。
XLarge サイズのインスタンス最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけることに焦点を当てました。これらのテストでは、データベースに 1 つの m4.2xlarge ノード、NFS サーバーに 1 つの m4.2xlarge ノードを使用しました。
ベンチマークを見ると、m5.12xlarge (48 CPU) および m5.8xlargeノード (32 CPU) を使用した場合に最高の git スループットが実現されています。どちらのインスタンス タイプにも 4 つのノードが必要となります。
2 ノード (96 CPU) でもパフォーマンス テストを実施しましたが、パフォーマンスが低く、しきい値を満たすことができませんでした。テスト結果により、2 ノードのデプロイメントは XLarge の負荷に適していないことがわかりました。2 ノードのテストではカーネルでの所要時間が大きくなりましたが、4 つ以上のノードの場合はそれほどではありませんでした。
データベース ノードのテスト結果
-
Large サイズのインスタンス
アプリケーション ノードの一連のテストにより、アプリケーションに 3 つの m5.4xlarge ノードを使用すると、最もフォールト トレランスな状態ではないが、最適なパフォーマンスを実現できることがわかりました。2 度目の一連のテストでは、データベースで次の仮想マシン タイプに対してこの構成をテストしました。
m4.large
m4.xlarge
m4.2xlarge
m4.4xlarge
予想どおり、性能の良い仮想マシンを使用するほど、パフォーマンスが向上します。CPU 使用率が最も大きく向上し、Git のスループットはわずかに向上しました。
m5.large のみが CPU 使用率のしきい値に到達しませんでした。テストした他のすべての仮想マシン タイプは許容範囲内でしたが、m5.xlarge は CPU 使用率のしきい値である 60 % に非常に近い値を示しました。
XLarge サイズのインスタンスアプリケーション ノードの一連のテストにより、アプリケーションに 4 つの m5.12xlarge ノードを使用すると、最適なパフォーマンスを実現できることがわかりました。2 度目のテスト シリーズでは、データベースで次の仮想マシン タイプに対してこの構成をテストしました。
m4.xlarge
m4.2xlarge
m4.4xlarge
m4.xlarge は CPU 使用率が 100 % に達し、db.m4.4xlarge はパフォーマンスが向上しませんでした。このため、XLarge の負荷においても m4.2xlarge が推奨インスタンス タイプとなります。CPU 使用率は m4.2xlarge では ~ 40 % でした。
NFS ノードのテスト結果
ディスク I/O