Erlangアプリケーションを node_package で簡単パッケージング

この記事はErlang Advent Calendar 2014の9日目の記事です。

Erlang/OTP でサーバー作ったあとのデプロイはわりと大変だ。リリースをわりと念入りに作っておいても、ディレクトリ構造がややこしかったりいろいろと面倒らしい。ぼく自身は運良くそういう問題はこれから紹介する node_package を使っているのであまり苦労をしたことがないのだが、リリースを作る大変さはすごいE本を読めば書いてある。

すごいErlangゆかいに学ぼう!

すごいErlangゆかいに学ぼう!

これを読んで、やっぱり自分がラッキーなことを再確認した。実際、うまくツールチェインを作りこんでも、 NIF があったりしてリリースを環境ごとにコンパイルしなければいけなかったりとかなり面倒だ。で、サービスを運用している会社でもない場合、たとえばCentOSやUbuntu, Redhatなど複数の環境にインストールできるようにしなければならない。

しかしながら、ディストリビューションやOSによってパッケージシステムの設計や思想が全く異なっていて、それぞれの作法ややり方をいちから覚えて作りなおさないといけない。せっかくどんなOSでも動作するErlang VMを同梱したはずのリリースを作ったのにこれでは本末転倒だ。ほら、やっぱり設定ファイルは /etc に置きたいし、各種ツール類は /usr/sbin にインストールしたいじゃない。

その問題を解決してくれるのが node_package だ。これは Riak や Riak CS のリリースパッケージを作るために作られた便利ツールチェインだ。前提条件としては、 rebar でリリースが作れるようになっていれば、あとはこれを rebar.config に追加しておいて、 Makefile かどこかにパッケージ作成のコマンドを覚えておけば、あとは make package でどんなパッケージでも作れるようになっている。 node_package がサポートする環境の一覧は Riak のダウンロードページを見るのが正しい確認方法だ。

使い方

使い方はまあ、 Riak の Makefile の様子を見てそれなりに汲み取ってもらえれば…というのはいささか大変過ぎるだろうと思うので、まずはEUC 2013での解説スライドを貼っておこう。

簡単な手順をかいておこう。

パッケージ作成用のツールを予め入れておく

CentOSだと rpm-build だし、 Ubuntu だと dchroot devscripts debhelper あたりが必要だろう*1

rebar で release を作れるようにしておく

"rebar generate" でローカルのリリースがきちんとできるように準備しておこう。この辺りはいろいろ面倒なので省略。reltools.config とか vars.overlay とかまあいつものアレをちゃんと書いて、パッケージがなくてもこのリリースがちゃんと動くようにしておこう。 node_package も含めて正しい手順を詳しく知りたい人はこちらをどうぞ→Erlang/OTP パッケージングコトハジメ

rebar.config に依存を追加

まずはモノを持ってこないと話にならない。他にも当然、 lager, eper, cluster_info くらいはリリースに入れると思うのでちょっとここでも書いておく。最新版は 2.0.0 だ。

{deps,[
       {node_package, ".*", {git, "git://github.com/basho/node_package", {tag, "2.0.0"}}},
       {lager, ".*", {git, "git://github.com/basho/lager", {tag, "2.0.3"}}},
       {eper, ".*", {git, "git://github.com/basho/eper.git", {tag, "0.78"}}},
       {cluster_info, ".*", {git, "git://github.com/basho/cluster_info.git", {tag, "2.0.0rc1"}}}
      ]}.

Makefile を書く

お作法としては、 package/ というディレクトリを作って、そこに改めて指定のタグなりブランチなりをクリーンな状態にして持ってきた方が余計なものが入らなくてよい。Makefileは deps/node_package/ に入っているので、これを持ってくる。

package: package/$(PKG_ID).tar.gz
	$(MAKE) -C package -f $(PKG_ID)/deps/node_package/Makefile

package/$(PKG_ID).tar.gz: package.src

package.src: deps
	mkdir -p package
	rm -rf package/$(PKG_ID)
	git archive --format=tar --prefix=$(PKG_ID)/ $(PKG_REVISION)| (cd package && tar -xf -)
	make -C package/$(PKG_ID) deps
	for dep in package/$(PKG_ID)/deps/*; do \
		echo "Processing dep: $${dep}"; \
	    mkdir -p $${dep}/priv; \
        git --git-dir=$${dep}/.git describe --tags >$${dep}/priv/vsn.git; \
	done
	find package/$(PKG_ID) -depth -name ".git" -exec rm -rf {} \;
	tar -C package -czf package/$(PKG_ID).tar.gz $(PKG_ID)

pkg.vars.config 作成

node_package が見るための設定ファイルのようなものだ。パッケージのベースネームやライセンスの指定、インストールすべきスクリプト類、作成すべきユーザー名などいくつかの項目を指定することがでくいる。 Riak だとこんな感じになる。そこに載ってない豆知識をひとつ披露しておくと、

{deb_depends, ["nkf"]}.

みたいな感じで、依存パッケージもここで指定できたりする。

パッケージ作成

ここまでできたら、あとは簡単。

$ make package

あとは、 node_package がディストリビューションや環境を自分で判定してリリースから、その環境用のパッケージを作ってくれる。リモートのレポジトリにきちんとタグがついていれば、そのタグを使ってバージョン番号をよしなにパッケージにつけてくれるし、そうでなければ git のコミットハッシュを使ってユニークな番号をつけてくれる。

コツは rebar.config でちゃんとバージョンを固定しておくことだ。依存ライブラリが多すぎて毎度タグを打つのが面倒な場合は rebar_lock_deps_plugin を使うとよいだろう。

ためしにソースからパッケージを作ってみよう

1番簡単に作れるものとしては、やはり Riak CS を推したい。もしも Riak CS がサポートするLinuxやFreeBSD、MacOSなどの環境を持っているようであれば、Erlang (R16B03-1) をインストールした
あとにコレを試していただきたい。(CentOSやUbuntuだとパッケージ作成系のパッケージも必要)

$ git clone git://github.com/basho/riak_cs -b release/1.5
$ cd riak_cs && make package
...(snip)
make[2]: Leaving directory '/tmp/riak_cs/package'
make[1]: Leaving directory '/tmp/riak_cs/package'
$ ls package/packages/
riak-cs_1.5.2.8.g09aa0a4-1_amd64.deb  riak-cs_1.5.2.8.g09aa0a4-1_amd64.deb.sha

できた!
簡単ですね。

応用例

ぼくはこれとDockerを組み合わせて、いつでもどこでも CentOS 用のRPMパッケージを作れるようにしてある。ブランチ名を指定して make rpm とやると、それだけで修正済みのパッケージができるようになっている。せっかくなのでDockerfileを公開しておこう。こうしておけば、大規模なビルド環境がなくても Drone.io とか?ローカルでちょこっとパッケージを作ってあちこちの環境で試すことができる。 Docker Image を作っておいとけばいいではないかという話もあるが、ネットワークとIOまわりのことを気にして下回りになるべくレイヤーを挟みたくないのでやらない。

これをちょっと応用して、わりとパッケージを作りにくい、 escriptize されたツールもRPMなどのパッケージを作れるようにもしてある。最近だと、 basho_bench のRPMが急遽必要になったのでこれでRPMパッケージをサクッと作ってリリースした。他にも、特定のユーザー向けの簡単なErlangツールもこれでパッケージにしておくと、Erlangで書かれたとか、使うためにErlangをインストールしなきゃいけないとか面倒なことを考えなくてよいし、こちらも説明の手間が省けている。本当に便利すぎる。

おまけ

この node_package すこぶる便利なのだが、いくつかイケてないところもある。 /usr/share に入れるようなドキュメント類(リリースノートやライセンス、や manpages なんか)も一緒にうまく入ればよいのだが、そのあたりは全く機能がない(Riakでは docs.basho.com に全てドキュメントを公開してしまっているので困ってない)。あと、 release upgrade には対応していない。というか、この手のパッケージ管理と release upgrade ってすごく相性が悪いので…というわけで、この辺りをうまくこなしてくれる猛者がいたら、こちらか、こちらまでどうぞ!

*1:よくわからないのでとりあえず入れている

msgpack-erlangのはなし

この記事は Erlang Advent Calendar 2014 の三日目の記事です。

MessagePackというシリアライゼーションのフォーマット
がある。これはまあまあ有名じゃないかもしれないけど、今をときめく fluentd の裏側で使われているプロトコルだ。この手のシリアライザは多種多様で、圧縮まで考えると歴史的にも沢山あって死屍累々の歴史でもある。モダンなやつだとAvro, Thrift, ProtocolBuffers などがあるが、サイズ、速度、柔軟性のバランスを考えるとかなり独特な位置にある。興味があるひとはTwitterでMessagePackってつぶやいてみると作者たちが釣れるかもしれない。今日はこの Erlang/OTP での実装について話をしよう。


使い方

基本的にはこれを単体で使うことはないだろうと思うが、簡単に試したいかたは次のようにすればよいだろう。システムに Erlang/OTP (R15B ~ 17.x) と git がインストールされていることが前提だ。

$ git clone git://github.com/msgpack/msgpack-erlang
$ cd msgpack-erlang
$ ./rebar compile
$ erl -pa ebin
> Bin = msgpack:pack([<<"spam">>, <<"ham">>, <<"egg">>, 42]).
<<148,164,115,112,97,109,163,104,97,109,163,101,103,103,42>>
> msgpack:unpack(Bin).
{ok,[<<"spam">>,<<"ham">>,<<"egg">>,42]}

他にもいくつかAPIがあり、ドキュメントはないが、関数そのものは4つしかない。 msgpack.erl をみれば概要がわかるだろう。ちなみに Erlang/OTP 専用になるが、 "msgpack:term_to_binary/1" と "msgpack:binary_to_term/1" という便利関数も用意している。これは、 MessagePack の新仕様の拡張型を使って、ErlangのTermを全部エンコードできるようにしたものだ。これを使えば、 ナマのMessagePackでサポートしているプリミティブなErlang Termはそちらに変換され、 pid() などどうにもしにくいものは t2b なり b2t に部分的にフォールバックしてくれるというスグレモノだ。ちなみにコレを使っている人はまだみたことがない。速いかどうかは知らない。

自分のErlang/OTPのソフトウェアに組み込みたいときは、 rebar.config に次のように書くとよいだろう。

{deps, [
        {msgpack, "0.*",
         {git, "git://github.com/msgpack/msgpack-erlang", {tag, "0.3.2"}}}
       ]}.

事例

  • 今をときめくアドテクの会社、VOYAGE GROUPで使われているとのこと
  • 某社で内部のプロトコルで使われているそう
  • たまに海外からメールが来る

今の実装の問題点

  • NIF版に手をつけられていない。拡張型が入った時点で一旦外していたのだが、戻ってこられず…
  • jiffyやjsxインターフェースを捨てたいが捨てられない
  • 最適化?なにそれ?
  • テストが足りてない

今後の方向性

− Pull Request がいつの間にか来てたので対応したい

コントリビュート

こちらまで。Apache 2ライセンスに同意していただくことが必要。OSSのソフトウェアを開発する仕事をしているくせに、OSSの開発にあまり時間を割けていないというみっともない状態なので、メンテナが増えてくれると嬉しいなあ…

歴史とポエム

いま改めて検索してみると、最初の実装を発表したのは5年以上も前になる。最初のコードはわずか300行ちょっとの1ファイルで、シリアライザとデシリアライザが全部入ってしまって、Erlangのパターンマッチすげえ!と感動したのを5年ぶりに思い出せた。当時はまだ僕はErlangを始めたばっかりで…(以下ポエム)

それが、8ヶ月後には公式ライブラリの仲間入りをして…それも4年前のことであるから、思えば遠くまで来たもんだ。

日本のデータベース系のコミュニティ、なぜイマイチ盛り上がらないのか

11月の19,20日に開催されたWebDB Forumに参加してきた。カンファレンスそのものは、いろんな人に久しぶりに会えたり、ネット上でなんとなく知っていても話したことなかった人と話したり、意外な人の意外な一面をみることができたりと、とても楽しむことができた。立場としては所属している会社のスポンサー枠で参加して目的もあって発表もしてきたわけだが、いくつか思うところがあるのでここにまとめておきたい。

現実にアカデミックで起きていること

WebDB Forumと銘打ってはいるものの、データベースに関する研究発表は非常に少ない。OSやネットワーク、システム系の研究と併せても、機械学習やNLP、Webなどの技術に感心を持つ人は多く数で圧倒されている。体感では 90% だ。それをいえば別に VLDB や SIGMOD などのトップカンファレンスもデータベースの技術を直接扱うことは少ないし、データベースの要素技術は多岐にわたるので一概に定義することは難しいのだが。まあ私が興味を持てる発表が少なかったと言い換えても構わない。

学会がこのようになっているのは、当然の原因があって、そもそもデータベースを扱う研究室が非常に少ない。わたしはそんなに知っているわけではないが、インダストリアルからも見えているのは東大の喜連川研、東工大の首藤研、筑波大の川島研、最近できた阪大の鬼塚研がわずかに取り組んでいるだけだ。それもクラウドの要素技術のひとつとして、研究室の一部で…というのが実態だ。ComSysやDEIMに行けばもっと多様なものが見られるのは知っているが…

現実にインダストリアルで起きていること

まずはいくつかのスライドをはっておく。

これがCassandra

ほかにも、 CyberAgentにおけるMongoDB[C16] インメモリ分散KVSの弱点。一貫性が崩れる原因と、それを克服する技術とは? by Taichi Umeda など、アカデミックとは違うことが起きているのが分かるだろうか。

これは単なる人材の需給のミスマッチで説明できる現象ではなくて、そもそもこういった下回りの技術に若者たちが興味を持たないという傾向がここ十年以上続いていることが遠因だ。現に私が学生だったときも、OSやデータベース、ネットワークにまだまだ研究課題があるとは思っていなかった。それは教科書や論文の延長で考えれば確かにそうなのだけど、現実世界に引き込んだ瞬間に違うことになる*1。…のだが、その魅力に気付いたのは、私の場合は大学を出てサラリーマンになってからだった。分散システムやデータベースに出会って、自分で設計してみて、実装してみて初めて分かることがあまりに多い。とんでもなく優秀な人なら、周囲の助けも得て学部から修士の3,4年でその境地に辿り着けるだろうが、私のようなふつうの学生 はそうではなかった。

あと最近はAWS使えばそれで大抵うまく動くので別にいいよね、みたいな。身近に問題がないというのも問題なのだけど、…。

どうしたらよいのか

WebDB Forumで何人かアカデミックやその出身の人と話した限りでは、やはり講義が少ないという現実があって、それは学生が興味を持たないことも原因だし、教授陣があまりそっち系の講義をやっていない&できる人がいないことも原因でもある。人が集まらないのはなぜかというと、…という言葉を考えるとちょっと言葉に詰まる。

とりあえず分散システムの人はトランザクションを学ぶべきだし、トランザクションの人は分散システムを学ぶべきだ。だから、とりあえず、Bashoという会社に行くと(どっちかというと分散システムの知識にかたよるけど)両方の経験が身につくので、行ってみるといいと思うよ!


奇しくも、5年も前に 基盤系プログラマ - kuenishi's blog などという煽り記事を書いた問題がわりと近い方向であたっていて、今ではどんな会社もちゃんとしたインフラエンジニア(当時はそういう言葉がまだなかった)を欲しがっている。これからデータ量やトラフィックが益々増えていくとそういう人種の価値がますます上がるわけで、この需給のギャップを解決するためには、やっぱり最初の一歩は大学の講義が増えて「こういう技術、ものすごく金になるんですよ」とか、「本当に賢いヤツらはここに集まっている」ということを滾々ともう一度伝えていくしかないのだろうかとか最近考えている。

追記

欧米でわぁ〜、というのはあまり言いたくはないのだが UCB の cs262 をネット上で貼ってくれている人がいたのでここでもリンクしておこうと思う。わたしもあまり多く追えてはいないのだけど、アメリカでCSの強い大学だとどこでもこのレベルの講義があって、学生がヒィヒィ言いながら履修している(という印象だ)。日本だとこういうのなかったよね、少なくとも私が学生だった頃は。

*1:某チョプリン氏がよい例だと思う

ラスベガスで開催されたRICON 2014に行ってきました

日本でもそうなのだが、アメリカでも分散システム専門で、しかもアカデミアと産業が両方出てくるカンファレンスはRICONを除いてほとんどない。確かに分散データベースに関するカンファレンスはアメリカではいくつかあるのだが、わりと商業的であったり、運用や実装に近い問題が多く分散システムの難しい側面にフォーカスされることはあまりない。

そんな素晴らしいカンファレンスが今年も開催されたので参加してきた。わたしが所属している会社が主催しているので、まあ主催者枠である。肝心のカンファレンスそのものは、アカデミアと運用事例、分散システムのエンジニアリングに関するはなしが同じくらいの割合でされていてまあ面白かった。圧巻はPeter Alvaroによる2日目のキーノート講演だった。

分散システムで難しいのは、AsynchronyとPartial Failureで、単体だと話はとても簡単なのだけど、現実世界はこれが揃っているせいで理論的には難しいものになっているというので、それをFault Injectionで検証する方法を考えてみたところ、Kyle KingsburyがJepsenで見つけたKafkaのデータロスもちゃんと出たし、Paxosは正しいことが証明できた。これまで分散システムを形式検証するよい方法はほとんどなかったのだけど、実際使えそうなものが出てきたことは本当にすごい。
動画はこちら:


Keynote 2 Day 2: Peter Alvaro - Outwards from the ...

RICONのよいところは、商業的な話も少しだけしつつ、Riakに限らず他の話もわりといろいろ入る。個人的に一番勉強になったのはMesosの話だった。

…とまあ、ここまでは表の顔で、裏の顔は普段リモートワークしているBashoの社員が集まってじゃれ合うイベントでもある。他にも沢山の画像が上がっているが、いかに楽しんでしまったかを一部の写真からご想像いただきたい






最後、ホテルの部屋の窓からチェックアウト直前に撮った一枚が個人的にはベストショットでありました。
100D3300-DSC_1818
100D3300-DSC_1818 | Flickr - Photo Sharing!

バグの間抜けな倒しかた

プログラムを書いていると、間抜けなバグをいくらでも仕込むことができる。たとえば一文字だけのTypoだったり、ifの括弧のつけわすれであったり、エラー処理をひとつ忘れていたり、もしくはその言語特有の間抜けなバグというものもあるだろう。そういったバグは往々にしてコードレビューはテストを掻い潜ってしまう。製品や本番のコードに残ったままリリースされ、とてもヘンなデータが入ったり障害が起きたりしたときにだけ発露する。今回のはなしもそのエラー処理をひとつ忘れてリリースしてしまったことがきっかけではあるのだが、むしろバグの見つけ方が間抜けであったことをここに書いて今後の反省の材料としたい。

riak_cs#985 はそんなバグのひとつで、エラー処理をひとつ忘れて Riak CS のコネクションプールが漏れていたという話だ。再現条件としては、ユーザに関するAPI(一覧GETなど)を叩いたり、 Authorization ヘッダなしで存在しないバケットを GET すると、コネクションがプールからひとつ漏れていく。コネクションプールが枯れてしまうと全てのAPIリクエストが503だか何だかのエラーしか返らなくなってしまって、まあ要はサービスが落ちるわけだ。これの原因が分からなくて、2日ほどうんうんと唸っていた *1

僕が非常に間抜けな見つけかたをしたのは後者の再現条件だ。 Riak には /ping という簡単な動作確認用のAPIがある。これをGETでたたくと、 "OK" という2文字がBodyに入ったレスポンスが返ってくるので、RiakのプロセスがすくなくともHTTPのレベルで生きていることはわかる。同様に、 Riak CS には /riak-cs/ping というAPIがあって、これを叩くと生きているかどうかがわかる。 #985 が問題になっているときに焦ってしまって、思いつく限りのAPIを適当に叩きまくっていたのだけど、そのなかに /ping というAPIがあると仕様を間違って理解していて、その実装は riak_cs_wm_ping.erlだと思っていた。これがコネクションを使っているし、あまりテストもないし、これが怪しいんじゃないかと疑っていた。これだと認証ヘッダがつかないので、ふつうのAPIアクセスとは違った挙動になる…ことを期待していたわけではなく、八方塞がって s3curl ではなく curl を使って叩いていた。ほんとうは /riak-cs/* のAPIも認証ヘッダが必要なのだけど、頭が混乱していたわけだ。
それで、

$ curl http://localhost:8080/ping

というコマンドを叩くとコネクションが漏れることを発見した。これがきっかけで問題箇所を特定できた(特定したのは僕ではない)のだけど、これは riak_cs_wm_ping.erl のコードを使っていなくて、 riak_cs_wm_objects.erl という全く別のAPIを叩いていたのである。どれくらい的外れかというと、この手の死活監視ならふつうは200が返ってくるのが相場だが、ステータスコードは404が返ってきてそういうXMLが表示されるくらい的外れだ。そして404が返っていても、リークを見つけて興奮していたのでそれにしばらく気付かなかったくらいボケていた。
ぼくの仮説の設定は全くの検討外れで、今回は運良くたまたま原因となるところにリーチできたわけだ。

ぼくはわりと性急な性格なので、勤務時間中は給料をもらっていると考えると効率を上げるために焦る傾向があるようで、デスクトップは片付けないし、かなりの数のメールをタイトルだけ読んでArchiveする。同様にドキュメントやコードを読むときは要点だけを知りたいので、細かい所はわりと飛ばしてよむ癖がある。それが今回は幸いしたわけだが、お前は本当にそれでよかったのかと問いたい。

じゃあバグの体系的な倒しかた、とかバグを仕込みにくい開発やプログラミング言語とは、という話になるのだけど、再発予防とか水平展開とか一般論に陥りがちで難しい。まあ QuickCheck でテストを書けという話ではある。

*1:まあ2日で見つかるんだからいいじゃないかという気もする

Riak 2.0がリリースされていた

9月に入ってから、Riak 2.0がリリースされた。昨年の今頃から動き始めて、1年かけてようやっとリリースにこぎつけた。あちこちで繰り返されているが、ここでも新しい機能をちょっとずつ試していきたいと思う。マーケティング的には華々しく4つくらいの新機能が宣伝されているが、ここでは地味でマニアックなことから。とりあえず思いつくものをここから。

  • Erlang/OTPをR16に更新(ようやく)
  • Cuttlefish: 設定フォーマットの簡単化
  • Bucket Types: Bucket名前空間の追加
  • Strong Consistency: レプリケーションの強い整合性
  • Riak Search 2.0: Solrを組み込んだ高機能な分散インデックス
  • Security: 認証認可と通信路の暗号化
  • Java Client 2.0: 進化したJavaクライアントとか、ほかにもいろいろ

進化とか書いてしまってカッコイイな。と思ったら、hiroeさんがQiitaに注意点をまとめていたのでとりあえずそのリンクを貼ってお茶を濁しておこう。

日本でも新機能をバンバン使っていろいろやろうとしているのでなんか追加の記事を書くかもしれない。

システム系論文輪読会で話してきた #pfisystemreading

先週の金曜日に、PFIで開催されたシステム系論文輪読会で話してきた。いい加減に積んであるものが多すぎて、こういった機会に便乗して自分を追い込まないと何もできないからである。


第2回 システム系論文輪読会 - connpass

僕が読んで解説したのは Peter Bailis et al., "Coordination-Avoiding Database Systems" VLDB 2015, to appear である。この論文がどれだけすごいものであるかという話についてはぼくのレジュメを参照いただくとして…この論文は神林さんに教えてもらったのだけど、VLDBやBailisのグループは要チェックだということを再確認した。この論文、なかに分散システムの証明が書いてあったりするのだけど、21回も続いている分散合意本読書会で鍛えた証明の読解力で割とスラスラとノリを理解できたので感動した。というわけで合意本を読めば…

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

といいたいところであるが、この本は一人で読み進めることは素人には不可能なのでなかなかキビシイ。ちなみに、わりとついてきた地力を使えば、CAP定理の証明 [1] くらいであれば、サクサクと読めるようになったりはする。

話を戻すと、この論文の内容はともかくとして、この論文がどうすごいのかを書いておこう、と思ったけど上のGistにだいたい書いてあった。クラウドとか分散KVSとか言ってるひとたち、この論文読まないとだめだよ。あとサーベイとしても非常によくできていて(各方面の歴史たちが共著者になっているので、歴史的に漏れがほとんどない)、参考文献リストの長さに顔が青くなること必至である。

まあ、流れでいうと、NoSQL的にトランザクションとかACIDとかレプリケーションをそこそこで割り切って作ったデータベースのよいところと、RDBMSとか2PCとかデータの整合性をキッチリキッチリやってきた流れがここで融合しているのがすごいのである。市場にも「トランザクションできるNoSQLだぜー」とか高速なRDBMSだぜーみたいな話は死ぬほどあるのだけど、どれもこれまでのデータベースの研究と製品の歴史を無視したマーケティングなので無視したらよい。製品にして使ったところでどこかでハマるのが原理的にわかっているので(ハマらないことが証明された設計になっているのであれば、それは論文にして出した方がマーケティングとしても効果が高い)。MongoDBやMySQLのようなタイプのレプリケーションをやっていると、ネットワーク分断、耐障害性、スケーラビリティのどこかで問題が出てくるし、CassandraやRiakのような設計でレプリケーションをやっているとスケーラビリティや耐障害性が十分であっても、整合性に限界があったりアプリケーション的なユースケースが限られたりする。

これはひとつのパラダイムでいろいろなデータベースの問題を解いて全てのユースケースをカバーできないということの証左であるわけだが、このCoordination Avoidingなデータベースでは、ひとつのデータベースで、ユースケース毎に理論的な限界をギリギリまで詰められることを証明した。具体的には、整合性を保ちつつスケーラビリティや分断耐性を追うためのユースケース分析をして、それをうまく使い分ける提案をしたわけだ。I-Confluenceの概念とその証明でだんだんテンションは上がって、TPC-Cのアクセスパターン分析でこの論文は最高に盛り上がる。

しかし原理の解説やTPC-Cの分析と実験は非常に興味深いのだけど、実装や設計の話がほとんどなくて、これじゃあちょっと再現とか実装してテストしてみるというわけにはいかなそうなのが難点である。きっとベンチャーを立ち上げるのだろう。

個人的には、この論文の実装が世にでるか出ないかのタイミングで「ひとつの用途にひとつのデータストア」の時代が終わるのではないかと予想している。今でも、AWSに入ってる各種データストアや、Orchestrate.ioなどが登場しており、データベースを個別にデプロイして使い分けるのではなく、複数のユースケースをなるべくシンプルなサービスにまとめて使い分けるという形が主流になっていくのではないか。手前味噌であるが、Riak も2.0のリリースでその第一歩を踏み出している

  • [1] Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.