2016/01/07
Bitbucket Server のサイジングについて
Author
樋口 晃Akira Higuchi
こんにちは。リックソフトのプリセールス担当の樋口です。今まで、JIRA, Confluence についてはサーバーサイジングの目安になる日本語の資料が有ったのですが、Bitbucket Server については無かったので、今回作成しました。Atlassian社の 以下の情報を参考にしました。
- Saling Stash ： https://confluence.atlassian.com/stash/scaling-stash-282988851.hml#notfound
- Recommendations for running Stash Server in AWS https://confluence.atlassian.com/stash/recommendations-for-running-stash-server-in-aws-722142113.html#notfound
サイジングの目安
上記の AWS の資料によると、ユーザー数別の推奨スペックは下記の通りとなっております。一番左のユーザー数を目安にサーバースペックを決定して下さい。この数字は私達の経験値とも一致しています。また経験上、SSDは必須では有りません。
| Active Users | EC2 instance type | VCPU(Core数) | ECU | Memory(GB) | EBS Optimized | EBS Volume type | IOPS |
|---|---|---|---|---|---|---|---|
| 0_250 | C3.large | 2 | 7 | 3.75 | No | General Purpose (SSD) | N/A |
| 250_500 | c3.xlarge | 4 | 14 | 7.5 | Yes | General Purpose (SSD) | N/A |
| 500_1000 | c3.2xlarge | 8 | 28 | 15 | Yes | Provisioned IOPS | 500_1000 |
Bitbucket Server のサイジングの考慮点
通常は上表の通りで良いと思いますが、以下の通り補足させて頂きます。
Bitbucket Server はJavaアプリケーションですが、サーバー内でGitリポジトリーを管理するためにGit コマンドを実行します。サーバーのリソースを消費するのは、Javaよりも Git コマンドです。配慮が必要なケースは以下の２つです。Gitコマンドの処理の中で最もリソースを消費するのは、クローン 処理です。クローン処理では、サーバー内のリポジトリーの履歴も含んだ全ての情報を圧縮しクライアントに送信します。
- リポジトリーのサイズが大きい場合
リポジトリーサイズが大きいと、ファイル圧縮に多くのメモリーを必要とします。 - CIサーバーを利用する場合
開発者がクローン 処理を実施するのは、Gitリポジトリーの利用を開始する時だけです。2回目以降は変更分を送信するだけなので軽くなります。問題になるのは、Bamboo や Jenkins などの CIサーバーを実行した場合です。ビルド処理の度にリポジトリーをクローンするので処理が重くなりますので、CIサーバーを利用される場合は配慮が必要です。
CPUとメモリーの基準値
Git コマンドが利用するCPUとメモリーの見積もりには以下の式を利用します。Javaアプリがメモリーを 1.5GB程度消費すると考えて、サーバーのメモリーを計算する事を推奨します。
- メモリー：平均リポジトリーサイズ（(700MBより大きい場合は700MB） x 1.5 x 推定同時クローン数
- 例：リポジトリーサイズが100MB、同時クローン数が 4 の場合、
- 0.1 x 1.5 x 4 = 0.6GB
- 例：リポジトリーサイズが 2GB、同時クローン数が 4 の場合、
- 0.7 x 1.5 x 4 = 4.2GB
- CPUlコア数：同時クローン数 ÷ 2
- 同時クローン数が 4 の場合は 2Core となります。
- 上記の「サイジングの目安」の表で、100ユーザーの場合、2Coreで 同時クローン数が4 というのは少ないと思われるかも知れませんが、経験上はCIサーバーの負荷が少なければこの程度で利用できます。
