BT

GoogleがGit Ketchをキックオフ - フォールトトレラントなGit管理システムの実現へ

| 作者: Abraham Marín Pérez フォローする 8 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2016年3月9日. 推定読書時間: 2 分 |

原文(投稿日:2016/02/02)へのリンク

開発が始まったばかりではあるが,GoogleがGit Ketchの最初のコミットを発表した。レジリエンスとスケーラビリティを目的として複数のGitサーバに情報を複製する,マルチマスタのGit管理システムである。JavaベースのGitサーバであるJGitをベースとして変更を加えているが,それ以外のGitサーバでもマルチマスタのクラスタに参加することができる。

Gitは分散型のソース管理リポジトリシステムとして設計されているが,ほとんどの組織は集中型のアプローチを採用している。すなわち,コードの“ゴールデンコピー”を持ったマスタリポジトリがあって,すべての開発者が変更のプッシュとアップデートのプルを行なう,という運用方法である。開発者の間で変更を直接適用することも可能だが,このような運用が行なわれるのはまれだ。こうした集中型アプローチは,単一障害点を発生させることになる。

JGitはこの問題に対して,DFS(Distributed File System)ストレージオプションという形で,部分的な解決策を提供している。部分的というのは,JGitが提供しているのが,DFSストレージのコントラクトを定義する抽象クラスセット定義のみだからだ。データのレプリケーションをサポートするアーキテクチャの設計や抽象クラスの実装は,ユーザが行なわなくてはならない。これはつまり,JGit DFSの実装に相応のリソースを投資しなければならないという意味であり,企業にとっては導入を躊躇する理由になる(Googleは既知の実装を所持している数少ない企業のひとつだ)。

Ketchは違う戦略を採用する。DFSでデータを複製可能な単一のGitサーバを定義する代わりに,Ketchでは複数の一般的なGitサーバの存在を前提にする。これらのサーバは互いに同期可能であり,それゆえに“マルチマスタ”なのだ。任意の時点において,サーバのひとつがリーダとして機能し,それ以外はスレーブになる。いずれかのサーバにプッシュ要求が送信されると,その要求はリーダに転送される。リーダはそのプッシュ要求をすべてのサーバに送信する。サーバの大部分がプッシュ要求の処理に成功した場合にのみ,最初の発信者に操作の成功が通知される仕組みだ。Raftアルゴリズムを基本とするこの機構により,少なくともサーバの大半に要求された変更が反映されていることが保証される。データ操作に失敗したサーバは,その他のものと同期を行なえばよい。現時点でリーダになれるのはJGitサーバのみだが,アトミックなプッシュを実装したGitサーバであれば,マルチマスタクラスタの参加サーバとして機能することができる。

提案中の変更はJGitのGerritで,ツールや進捗状況に関する詳細はJGitのeメール配布リストで,それぞれ入手が可能だ。

 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT