日本でのアトラシアン(Atlassian)製品導入No.1

  1. HOME

リックソフトブログ

2016/01/07

Bitbucket Server のサイジングについて

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

Author

樋口 晃Akira Higuchi

樋口 晃

bitbucket_rgb_blue

こんにちは。リックソフトのプリセールス担当の樋口です。今まで、JIRA, Confluence についてはサーバーサイジングの目安になる日本語の資料が有ったのですが、Bitbucket Server については無かったので、今回作成しました。Atlassian社の 以下の情報を参考にしました。

サイジングの目安

上記の 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 コマンドです。配慮が必要なケースは以下の2つです。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サーバーの負荷が少なければこの程度で利用できます。
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

カテゴリ一覧

最近の記事

年別アーカイブ