Facebook の Mercurial サーバ実装 (Mononoke)

[FUJIWARA Katsunori]

藤原です。

暫く前に Facebook から、「巨大な単一リポジトリ」向けの Mercurial サーバ

実装として、Mononoke なる OSS プロダクトが、 Github 経由で公開されまし

た。

  https://github.com/facebookexperimental/mononoke

以前から Mercurial sprint 等でも言及があったのですが、以下のような記事

(丁度一年ほど前) で紹介されていたものが、公開されたことになります。

  https://www.theregister.co.uk/2016/10/18/facebook_mercurial_devs_forget_git/

公開はされたのですが:

  - Mercurial 関連プロダクトだけど Github 経由公開

  - Mercurial だけど Rust 実装

  - 一部構成要素が未公開なので、現状単独利用は不可

といった感じに色々突っ込みどころのあるプロダクトで、且つドキュメント等

が無く、詳細がわからない状況だったので、どう紹介したものか……と保留し

ていました。

今回、Mercurial Sprint で Facebook の中の人から色々話が聞けたので、私の

理解した範囲で簡単に紹介したいと思います＆誤解があったらフォローお願い

します ＞ 西原さん

  - Mercurial の再実装「ではない」

  - 膨大なファイル／リビジョンを抱える巨大な単一リポジトリを、世界中に

    散財する複数拠点に対して、利用可能にするために、"hg serve" に相当す

    る部分を Rust で実装するのが目的

  - "hg serve" 的な挙動以外に、web API 経由でのアクセスも

  - 「複数拠点」への分散は、整合性等の点で色々面倒がある一方で、いわゆ

    る「ディザスタリカバリ」的な利点も得られる

  - ストレージ層は以下のような構成だが、適宜切り替え可能

    - 改変不要データ ⇒ blob store

    - 追記専用データ (履歴情報) ⇒ mysql

    - 改変可能データ (bookmark) ⇒ mysql

    ※ 内部的には Mercurial のフォーマットと互換性はない

  - blob store に格納されるようなデータは、フロントエンドキャッシュ等を

    置くことで、更に高速に

最小構成でも、結構色々な構成要素を組み合わせる必要があるので、超大規模

な運用以外では実用的ではない、とのことなので、Facebook クラスの規模の組

織に属していないのであれば、「話のネタ」ぐらいの感じですね (^ ^ ;;;)

ちなみに、私は最初に mononoke の名前を聞いた時に、「単一リポジトリ」を

示す "mono"と、何かを意味する "noke" の合成語だと思って、"noke" の意味

を調べたのですが、全然見つからないので、Facebook 内部のスラングかな？と

思っていました。

しかし「日本語のモノノケなのでは？」と言う人もいたので、中の人に確認し

たところ:

  - 確かに「もののけ姫」(princess mononoke) 由来の名前である

  - 一応 "mono" は「単一リポジトリ」に掛けてある

  - 「巨大なリポジトリ」 = monster 的なニュアンスもある

  - 命名はプロダクトリーダーによるもの (合議で出たものではない)

ということだそうです。Facebook にもハヤオファンが居た模様 (笑)

プロダクトロゴとかシンボルマークはまだ無い (デザイナーが参画してない)

とのことですが、流石にアレっぽいものは使わないでしょうねぇ (^ ^ ;;;)