はじめに

私の所属しているプロジェクトではAtlassian Stash （Git）でソースコードを管理しています。
普段何気なく使用しているGitですが、もはや手放すことが難しい存在です。

そんな中、ふと「もしもStashのデータが消失したら。」と言う事態を想像してみました。
Gitは分散バージョン管理なので、各々のローカルのGitリポジトリをかき集めれば必要なものは復旧できそうです。

どうやらソースコードの消失などの最悪の事態は発生しないことはわかりましたが、
Stashを使用していればサーバーの冗長構成は必要ないでしょうか。

Atlassianのドキュメントによると、Stashに障害が発生した場合、復旧作業をおこなっている間、下記の様な状況になります。

作業は続行不可能では無いですが、チーム開発を進めていく上でかなりの制限となってしまいそうです。

というわけで、転ばぬ先の杖ということでStashの冗長化に挑戦してみたいと思います。

Stash冗長化について調べてみたところ、本家Atlassianに冗長化についてのドキュメントが用意されていました。

冗長構成のパターン

Atlassianのドキュメントによると、冗長構成には以下の様なパターンがあるようです

構成	復旧時間
Single node	hours-days	単一ノード
Cold Standby	2-10 min	サーバーはActive StandByともに起動させておくが、StashはActive側のみ起動しておく構成。Active側が障害となった場合StandBy側のStashを起動させ、切り替える
Warm Standby	0-30 Sec	Active Standby 双方にStashを起動させておき、Active側が障害となった場合切り替える
Active-Active	<5 Sec	マルチマスタ＆負荷分散構成ただし Stash Data Center が必要

この構成の内、Active-Active構成をするためには Stash Data Centerを使う必要があるらしく、予算的に厳しい様な予感がするので今回は見送ることとします。

また、Warm StandBy 構成はStashがメモリ上にロック情報などを持っているため、現時点でこの構成は取れないそうです。

そうすると、コストとメリットのバランスを考えた場合Cold Standby構成を取るのが良いようです。
（Atlassianのドキュメントもこの構成でクラスタを組んでいます。）

図で表すと、下記の様になります。おおむねAtlassianのドキュメント通りですが、データベースのみ、他のAtlassianプロダクトと共有することを考えて、Stashとは別のサーバーとしています。

細かいソフトウェアのバージョンなどはもう少し調べてみてから決定していきたいと思います。

というわけで、だいたいの構成の目処がついたところで、今回はここまでとしたいと思います。

次回は実際のクラスターの構築を行ってみたいと思います。