Papers We Love というコミュニティ

第4回 システム系論文輪読会 - connpassが開催されると聞いて、思い出した話。日本だと、○○読み会という形で、特定の国際会議の論文をうわぁーっと集中的に輪読するコミュニティはいくつかあるけど、ある分野なりをまとめて回し読みしようという試みはないように思うので、ここで Papers We Love というコミュニティを紹介しようと思う。


Papers We Love Too - October 2014 - YouTube

予め断っておくが、ぼくはまだ参加したことはないし、同僚がたまたまファウンダーの一人なので知っただけだ。これがなかなか面白い試みだ。

Papers We Love is a repository of academic computer science papers and a community who loves reading them.

ということで、計算機科学のよい論文を集めたリストだ。たまに集まって発表会をやっている。過去の発表の動画がいくつかまとまっているので、様子がわかるかもしれない。発祥はニューヨークだが、トップページにあるように今ではアメリカを始めとして欧米でにわかに盛り上がっている(と思う)。

なんといっても充実しているのは分散システムのディレクトリだ。私が知っている限り重要なものはほとんど入っている。ひとつひとつ読むと時間がかかりそうである、が、読まねば…。積ん読が沢山ある皆様のことだからそんなもの見てるヒマはないというかもしれないが、ひとつ git clone してみてはいかがだろうか。

追記

東京にも有志がいるようなので登録してみた。ぼくが参加できるのはちょっと先になると思うけど…

出張でシアトルに行ってきました

Bashoではリモートワークが基本なのだが(もちろん一部にオフィスもあり通勤している人もいる)、年に何度か社員が集まっていろんなことをする機会がある。詳しくは述べないが、オンラインでできないことをやることが目的だ。

行きの飛行機では映画を2本観た。

  • Big Hero 6 : San Fransokyoという街に住む少年が兄の死の意味を理解する話。戦隊モノ。音楽がかっこいいのでサントラを買おうと思った。
  • LUCY: ロリコンだったはずのリュック・ベッソンスカーレット・ヨハンソンのために作った映画。映画のテーマとは対照的に人がサクサク死んでいく映画。あれ、人間の命ってこんなに軽かったんだっけ…?

機内食は朝のエッグベネディクトがうまかった。やはり全日空しかない。


着いたその日は牡蠣。

次の日はシアトルを散歩。スペースニードル、思ったより低かった。

橦木のない釣鐘。

長い顔

OSS

スタバ一号店。写真ちょっと傾いている

翌日のひるめし。

このビールでかなり酔った。

Pie Bar. このときは通っただけなのだが、後日行って飲んだバーボンとルートビアのカクテルがめちゃくちゃうまかった。

まるまる一尾でてきた鱒。

帰路、Sea-Tac空港でBターミナルの方にあるSUBPOPの店。ウロウロと探索していたら見つけてしまって、思わず衝動買い。

帰りの便では、運良くプレミアムエコノミーにアップグレードしてもらうことができて、快適な旅をした。もうプレミアムエコノミーなしでは無理かも…

Gone Girlという映画を観た。基本的にはサイコパスのお話なんだけども、親子の確執とか継承とか、結婚の難しさとか、メディアのプライバシーとか重い話のなかで兄弟愛だけが救いですな。最初はサイコパスの話だと知らなくてハラハラしながら観てしまったが、あとから思えばなんだか損した気分である。

自分用にGrumpy CatぬいぐるみをSea-Tac空港で買ったのを置いてみた。こいつぅ…

うちにはヘンなぬいぐるみが揃っている。

Netflixのモダンなクラウドベースのプラットフォーム

生活リズムが乱れることがしばしばあって、たとえば遅くまでプログラミングの仕事やネットサーフィンをすると脳が興奮してなかなか寝付けない。もともと寝付きが悪くて、遠足の帰りのバスも一人だけずっと起きてるような子供だったのでまあ仕方がない。さらに歳のせいか、連続して睡眠できる時間が短くなり、パフォーマンスの低下につながることが多くなった。

そこで真人間を目指していくつか施策を打っているのだが、そのひとつが布団のなかでPodcastを聞くというものだ。これは @omo2009 さんがTwitterLeslie Lamportのインタビューの話をしていて、聴いてみたら思っていたより面白かったのがきっかけである。

そういうわけで、ちょっと眠れなそうな夜には、イヤホンを寝室に持ち込んでこのIEEEのPodcastを聴くことにしている。他にもいくつかチャンネル登録しているものがあるのだけど、それはいい話があったら紹介したいと思う。

さて今回聴いたのは、
Episode 216: Adrian Cockcroft on the Modern Cloud-based Platform という話で、元Netflixのおっちゃんがモダンなクラウドベースのプラットフォームはどうあるべきか、どうやったら動くのか、という話をしてくれる。

まあ「ちょっと分散システムの実験したいときに200台のサーバーを10分くらいで立ちあげれるのはすごいアドバンテージだよね」とか「要は普段必要なものよりも大きいコンピューターリソースのプールが常にじゃぶじゃぶあるのが重要(なのであって、プライベートでもパブリックでもどっちでもいい)」というのはクラウド使ってる人だと常識だろう。5000万人にコンテンツを配信して行動をトラッキングして推薦するとか鬼のようなスケールでやっているわけだけども。一部ではまだオンプレ残ってるというのも面白かった。

仕事柄面白かった言葉は "Every Slice of Service" だ。可用性が重要。どんな障害があってもとりあえず顧客がテレビをみるのが止まったり遅れたりしてはいけない。ネットワークが切れたり不調になったりしても、サービスを構成するシステムをどう輪切りにしても、ひとつひとつの輪切りでストリーミングのシステムが上手く動いてないといけない。NetflixではよくChaos Monkeyが話題になるけど、ノードだけじゃなくあらゆる故障パターンをちゃんと想定して運用している(そういう障害を経験したから言ってるのだろう)。一方で全部そういうアーキテクチャにするのは無理なのでバランスとるのも必要なのだけど。

マイクロサービスの話もしてたか。Javaのモジュールのバージョン依存性の管理や、巨大クラスができる話、わずかな変更がサービス全体をぶっ壊してロールバックするリスクとかそういうの。是非とも聴いてみるとよい。よく眠れる。わたしも最後まで聴くのに3晩かかった。

もともとテックなイベントでの発表動画や、最近はやりのなんとか.fm系のやつは人間の喋る速度に律速されるので情報密度が低いから文章読んだほうがマシだろと思っていた。のだけど、情報密度を上げて文章にするとそれはそれで僕のような読書しないもやしっ子にはもともと難しい話だった。脳に筋肉が足りないのである。人間の話す声というのは素晴らしいものである。

ちなみに日本語のPodcastは、元深夜ラジオ勢としては聴きこんでしまって眠気を飛ばす恐れがあるので、購読していない。

Riak Meetup #5 を開催しました

Riak Meetup #5 を開催した。足掛け2年以上、ひっそり長く続いてよい感じだと思う。同日に今をときめく会社が開催するMackerel MeetupSecure AWS Users Groupがあったりして参加人数を懸念していたが、それなりに濃い話がみんなとできて非常によかった。ぼくの発表スライドはこれ。

元ネタはこれ。細かい話もCSの話もすっ飛ばしてしまったけど、まあ仕方がない…。

川島さんの発表は、なんというか実世界の問題と戦うなあという話だった。マエショリェ…

南川さんの話は、なんというかまさに、これがCSの正しい使い方だぜ!という感じである。是非とも公開していただきたい

Riak の運用とかについていくつか

Riak Meetup Tokyo #4 その後の運用の話という記事が出てきて、わりとカジュアルな運用の場合だとあれだけでも十分かもしれない。のだけど、本当はもっといろんなことができて、いろんなことに対応できるのでその基本的な扱い方や考え方をいま流行りのQiitaというやつにまとめてみた。


Riak での障害対応の手順 - Qiita

ちなみに https のベンチマーク、 Riak では Erlang/OTP の crypto のSSLを使っているはずなので速いかといわれたらまあお察しください…という話かと思われる。

Riak Core の紹介

Erlang アドベントカレンダー 2014の23日目の記事です。

Erlang/OTPでアプリケーションを書いていると、システムを冗長化するために複数ノードでうまく協調動作するようにさせるために、Distributed Erlangの上に構築されたFailoverやTakeoverを使う場面がいずれ出てくる。しかし、これらの仕組みは、Riakのようにシステムをスケールアウトさせたい場合には不十分だ。スケールアウトするシステムの本質は

  • アクセスしたいモノの物理的な位置を隠蔽して論理的な位置でアクセスできるようにする
  • 物理的な位置が故障やスケールアウトのために変化しても常に追跡できて同じ論理的な位置でアクセスする
  • アクセスしたいモノが偏らず、ほぼ均等に分散されている

の3点がサポートされていることだ。これだけだといろんなものが該当するが、 Riak風に翻訳すると

  • アクセスしたいデータがどのノードのどのディスク、どのファイルに入っているかを隠蔽して、キーが分かればアクセスできる
  • 故障やノード追加が行われても同じキーで同様にアクセスできること
  • アクセスしたいデータが各ノードに均等に分散配置されいていること

ということになる。よくよく読むと、扱う対象が、実はKVSである必要がないということだ。 Riak というデータベースの構成は、 Riak Core という分散フレームワークの上に載った Riak KV というアプリケーションであるということだ。 Riak KV は Riak Core 上で動作することを前提としているが、 vnode の動作は単なるローカルのKVSである(ちょっとRiak Coreの機能を使っている)。つまり、 Riak Core という分散フレームワークを使えばあなたのアプリケーションをvnodeに乗せてスケールアウトできるようになる!というわけである。絵でいうとこんな感じだ。

ちょっと調べたところRiak以外でも(驚くべきことに!)いくつか使われているようで、最大のクラスタはOpenXの125台のもののようだ。

参考

他にも、Riakの中だと riak_pipe というMapReduceのためのサブシステムがRiak Coreの上に分散アプリケーションとして載っている。

もうちょっと詳しく: 何ができるの?

もうちょっというと、いままで Erlang node というものにアプリをくっつけていろいろ扱ってきたものを、間にひとつ vnode というものを挟むことになる。 vnode にアプリをくっつけて分散配置するのだ。手書きの温もりあふれる絵でかくとこうなる。


リクエストのルーティング

Riak Core の用語では、リクエストは「 command 」になる。Erlangのコードの中で vnode に対してコマンドを投げるとそれを実行して、結果を返してくれるというイメージだ。どの vnode にコマンドを投げるべきかは、キーを渡してハッシュを計算すると vnode のIDが返ってくるようになっている。 "riak_core_util:chash_key/1" という関数がそれにあたる。

> DocIdx = riak_core_util:chash_key({spam, ham}).     
<<220,127,3,124,116,114,28,36,44,206,203,237,43,32,170,68,62,127,127,133>>

この関数の中は決定論的で特に副作用はないので*1、何度実行しても同じ値が返ってくる。Consitent Hashingでいうところのハッシュ値だ。これを使って Preference List をつくる。みっつめの引数は、 Riak Core アプリケーションの名前だ。ここではRiakを使っているので、 riak_kv という名前を使う。

> riak_core_apl:get_apl(DocIdx, 3, riak_kv). 
[{1278813932664540053428224228626747642198940975104,
  'riak@127.0.0.1'},
 {1301649895747835411525156804137939564381064921088,
  'riak@127.0.0.1'},
 {1324485858831130769622089379649131486563188867072,
  'riak@127.0.0.1'}]

2番めの引数は何個冗長化したいかという(合計でなんこの vnode にアクセスしたいのか?という)意味だ。これで、3つの vnode のIDと、それを持っているノードが判明する。あとはこれをもとに、 riak_core_vnode_master:command/4 を使えば vnode の handle_command が呼び出されて、アプリケーション特有の処理をすることができる。

vnode の移動、転送、破棄、作成をサポート

いくつかのコールバックを作成することで、 vnode の各種操作ができるようになる。アプリケーション毎に冗長性や移動、転送などのセマンティクスは異なるだろうから、アプリ側で作りこんでやる必要がある。簡単なコールバックで抽象化されていることから、難しい作り込みをしなくて済むようになっている。

故障時のフォールバックの動作をサポート

図のように、たとえばあるノードが故障なりダウンなりしていてそのノードが持っている vnode にアクセスできなかったとしよう。Riak Coreでは、この故障を検知して一時的にリストから外して、代替の vnode を用意する仕組みが用意されている。図のように V' にコマンドをフォールバックして別のノードで処理を代替させることができる。そのときも、本来存在しないはずの vnode を一時的に作成してセマンティクスを変えないで済むようになっている。

この代替処理のせいで、ネットワーク切断なんかのときはデータがdivergeしてしまうのだけど、そういうのも上手く処理するためのベクタークロック( vclock.erl )も用意されているので利用することができる。

つまり、Riakの高可用性の中心的な機能はフレームワークとして切り出されているので、Riak Coreを使えば誰でも高可用な分散アプリケーションを書けるようになるというわけだ。たとえば分散キューをほしいと思っている人は一部にいるだろうけど、OpenXはRiak Coreを使って広告表示フレクエンシーカウンターを作っている。噂によるとかなりの大きさのクラスタになっている(推測が正しければ、上記で出てきた125台のクラスタのことだと思うんだけど…)。

ノードの追加、削除、変更、ステータスチェックなど

riak_core_console.erl をみれば分かるのだが、Riakの cluster コマンドはほぼ全てこのモジュールにある関数を呼んでいるだけである。つまり、 vnode に紐づくアプリを実装して、各種 handle_* のコールバックを実装していけば、自動的にノードの追加、削除、変更などの各種操作のコンソールも作成できるのである。これと clique以前紹介した node_package を使えば、それっぽく動く分散アプリケーションを構築することができるようになっている。そいつのテストは riak_testで自動化 してしまえばよい。これで、スケールアウトや冗長化の難しいところ、面倒なところをほとんどがフレームワークで済ませられるので、開発者は分散まわり以外のアプリケーションの本質的な部分に集中できるという寸法だ。もちろん動作やアップデートは正しく理解して追っていかなければいけないが、自分でつくり上げて苦労するよりは随分楽だろう。

こんなのがほしかった(感想)

4年ほど前にJubatusというスケールアウトさせたいソフトウェアがあった。当時ぼくが直面していた問題は、機械学習のコアモジュールをどうやってDHTに乗せて分散させるかというものだった(BigTable風にヒエラルキアルな分散するシステムも同時期に開発していたが、わりとしんどかったのでDHTをやってみようと思っていた)。そのときコレを知っていれば(そしてC++と親和性があればナア)と、Bashoに入ってから歯痒い思いをしたものであった。

まとめ

Riakが利用している分散アプリケーション開発用のフレームワーク、Riak Coreの紹介をした。こういったことにどっぷり浸かりたい方は是非、わたしの職場で一緒にハマりましょう

*1:いろんなコンテキスト的情報を利用するのでピュ〜ア〜ではない

riak_test でインテグレーションテストの自動化

Erlangアベドントカレンダー16日目の記事。CROSS 2014で分散システムのテストがどうのという話になったときにぼくは riak_test をちょっとだけ話したが、それをもうちょっと詳しく説明しておこうと思う。ちなみに2年前もちょっとだけ紹介していた


is 何

BashoがRiakのインテグレーションテストを自動化するために開発したテストフレームワークだ。 eunit や ct では機能が不十分なので結局自分たちで作ってしまった。ペネトレーションテストとか負荷テストはまた別途。

なにができるのか

  • プロセスを立ち上げて何か叩いてチェックする、プロセスを落として環境を元に戻す、という手順を自動化できる
  • コマンド入力などマニュアル操作を自動化できる
  • 通常の eunit のアサーションを使って、ログの正規表現マッチなどさまざまなバリデーションができる
  • 複数のテストの結果を集計できる
  • 適当なところでFault Injectionして異常系の試験ができる
  • 失敗したテストのノードをそのまま残して、プロセスにアタッチして直接みてデバッグできる

というわけで、Riakそのもののテストにも使っているが、実はRiakを使ったアプリケーション(Riak CS)の結合テストも riak_test で書かれている

使い方

まずはコマンドを用意しよう。 17系のErlangで動くかどうかは知らない…

$ git clone git://github.com/basho/riak_test
$ cd riak_test && make
$ sudo cp riak_test /usr/local/bin

これで riak_test をコマンドとして実行できるようになる。

フレームワークそのものをいきなり使うのは大変なので、手っ取り早く動かしてみたいという人は(僕がいつもやっている) Riak CS のテストを走らせてみるとよいだろう。 README をもとに環境を用意して、ぜひ動かしてみてほしい。

作り方

ハーネス

rtdev.erlrt_cs_dev.erl を見るとわかる。分かりませんね、本当は behaviour で丁寧に用意すべきコールバックを用意すべきなのだが、まあそうなってないのはいつものBashoクオリティということでひとつ。このなかの setup_harness や stop_all (うろ覚え)がコールバックになっていて、これらを設定してやるとハーネスとしてなんとか動き始めるはず。はず…。

設定ファイル

以下は、ざっくりとした環境の構成を説明する。設定ファイルをつくる。設定ファイルはデフォルトでは ~/.riak_test.config だ。

{default, [
    {rt_max_wait_time, 180000},
    {rt_retry_delay, 1000}
]}.

{rtdev, [
    {rt_deps, ["/home/kuenishi/src/riak/deps"]},
    {rt_retry_delay, 500},
    {rt_harness, rtdev},
    {rtdev_path, [{root, "/tmp/rt"},
                  {current, "/tmp/rt/current"},
                  {"1.2.1", "/tmp/rt/riak-1.2.1"},
                  {"1.1.4", "/tmp/rt/riak-1.1.4"},
                  {"1.0.3", "/tmp/rt/riak-1.0.3"}]},
    {basho_bench, "/home/kuenishi/src/basho_bench"}
]}.

{rt_cs_dev, [
     {rt_project, "riak_cs"},
     {rt_deps, [
                "/home/kuenishi/cs-2.0/riak_cs/deps"
               ]},
     {rt_retry_delay, 500},
     {rt_harness, rt_cs_dev},
     {build_paths, [{root,              "/home/kuenishi/rt/riak"},
                    {current,           "/home/kuenishi/rt/riak/current"},
                    {previous,          "/home/kuenishi/rt/riak/riak-1.4.10"},
                    {ee_root,           "/home/kuenishi/rt/riak_ee"},
                    {ee_current,        "/home/kuenishi/rt/riak_ee/current"},
                    {ee_previous,       "/home/kuenishi/rt/riak_ee/riak-ee-1.4.10"},
                    %%{ee_root,         "/home/kuenishi/rt/riak_ee_onefour"},
                    %%{ee_current,      "/home/kuenishi/rt/riak_ee_onefour/current"},
                    {cs_root,           "/home/kuenishi/rt/riak_cs"},
                    {cs_current,        "/home/kuenishi/rt/riak_cs/current"},
                    {cs_previous,
                           "/home/kuenishi/rt/riak_cs/riak-cs-1.5.1"},
                    {stanchion_root,    "/home/kuenishi/rt/stanchion"},
                    {stanchion_current, "/home/kuenishi/rt/stanchion/current"},
                    {stanchion_previous,
                       "/home/kuenishi/rt/stanchion/stanchion-1.5.0"}
                   ]},
     {test_paths, ["/home/kuenishi/cs-2.0/riak_cs/riak_test/ebin"]},
     {src_paths, [{cs_src_root, "/home/kuenishi/cs-2.0/riak_cs"}]},
     {lager_level, debug},
     {build_type, oss},
     %%{build_type, ee},
     %%{flavor, {multibag, disjoint}},
     {sibling_benchmark,
      [{write_concurrency, 16}, %% seems not working more than 20
       {duration_sec, 100},
       {leave_and_join, 3},
       %%{version, previous}]
       {version, current}]
       %%]
     },

     {flavor, basic},
     {backend, {multi_backend, bitcask}}
]}.

{rt_cs_dev_old, [
     {rt_project, "riak_cs-1.5"},
     {rt_deps, [
                "/home/kuenishi/cs-1.5/riak-ee-1.4.10/deps",
                "/home/kuenishi/cs-1.5/riak_cs/deps",
                "/home/kuenshi/cs-1.5/stanchion/deps"
               ]},
     {rt_retry_delay, 500},
     {rt_harness, rt_cs_dev},
     {build_paths, [%%{root,              "/home/kuenishi/rt/riak"},
                    %%{current,           "/home/kuenishi/rt/riak/current"},
                    {root,           "/home/kuenishi/rt/riak_ee_onefour"},
                    {current,        "/home/kuenishi/rt/riak_ee_onefour/current"},
                    {ee_root,           "/home/kuenishi/rt/riak_ee_onefour/"},
                    {ee_current,        "/home/kuenishi/rt/riak_ee_onefour/current"},
                    {cs_root,           "/home/kuenishi/rt/riak_cs"},
                    {cs_current,        "/home/kuenishi/rt/riak_cs/current"},
                    {stanchion_root,    "/home/kuenishi/rt/stanchion"},
                    {stanchion_current, "/home/kuenishi/rt/stanchion/current"}
                   ]},
     {test_paths, ["/home/kuenishi/cs-1.5/riak_cs/riak_test/ebin"]},
     {src_paths, [{cs_src_root, "/home/kuenishi/cs-1.5/riak_cs"}]},
     {lager_level, debug},
     {build_type, oss},
     {flavor, basic},
     {backend, {multi_backend, bitcask}}
]}.

長かった。ここでは3つのアプリケーションのテストがセットアップされている。それぞれ長さ2のタプルであるが、ひとつめの要素はテストの名前だ。これを使ってテストを呼び出す。このファイルだと、 rtdev, rt_cs_dev, rt_cs_dev_old が用意されている。ひとつめは Riak のテストだ。ふたつめは現在開発中の Riak CS のテスト、みっつめは現行バージョンの Riak CS 1.5 系のテストだ。Riakのテストをサンプルに、各設定を説明しよう。

  • rt_deps ... テスト用の依存ライブラリがまとまっているディレクトリを指定する。 ERL_LIBSの代わりだ。
  • rt_retry_delay ... 環境によってテストの実行時間は変わるので、それに合わせたリトライ時間を設定する。
  • rt_harness ... これで setup/teardown (ノードの上げ下げ)のハーネスを指定する。 rtdev は Riak のノードを上げたり下げたりするためのものだ。 rt_cs_dev はRiak CS用。実態はただのモジュール名で、それぞれ riak_test のレポジトリ内に用意されている。もしも自分でテストをするときは、このモジュールを自作して setup/teardown のコールバックを作成する。
  • rtdev_path ... これは riak用の設定で、バージョンを記述する。current はまさにテスト対象の最新版、 previous はテスト対象のひとつ前、 legacy はもうひとつ前、といった風である。 rtdev 内にコードがあるが、このようにバージョンへのエイリアスを作成することによって、開発が進んでもテストコードを書き換えないでいいようにしている。また、 rtdev はこのディレクトリ下にRiakのリリースが入っている前提で、ここから起動終了など様々なRiakのコマンドを動かす。
  • test_paths ... コンパイル済みのテストコードの .beam を入れておくところ。ここからテストを探す。
  • lager_level ... ログレベルを設定
  • basho_bench ... これはよく知らない。がおそらく b_b のディレクトリを指定しているのだろう。このようにカスタムの設定をハーネスや環境によって変えることができる。たとえばその下にあるRiak CSにはもっと沢山の設定があって、これらの設定はテストを作る側がいろいろ変更できるようになっている。

テストコードを書く

実際のテストコードはとても単純だ。 confirm/0 という関数がエクスポートされていることが動作条件だ。この関数の spec は

-spec confirm() -> pass.

というとても単純なもので、なにかテストがコケたら例外でもbadmatchでも何でも飛ぶので、それを上で自動でキャッチしてくれる。 pass というアトムを返せば成功したことになる。どんなアサーションを入れても大丈夫だ。

うごかす

$ ls /path/to/your/test-beams
foo_test.beam              bar_test.beam
$ riak_test -c rt_your_dev -d /path/to/your/test-beams
||

とすると、 foo_test と bar_test.beam を実行する。ピンで実行したかったら、

>|sh|
$ riak_test -c rt_your_dev -t foo_test

とする。

テスト結果のオーバービューを可視化する

Giddyupというモノがある。これはいわゆる「スコアカード」というやつだ。 riak_test の実行結果は環境によって変わるだろうから、それらの結果を一覧表示してどこがダメかに早めに気付けるようにしている。ちなみに Riak CS では使ってないので、よく知らないです…やらなきゃダメなんだけれども。

ビッグデータ基盤技術勉強会で喋ってきた

研究会が設立されるとか、前からそういう流れになるとは聞いていたが、今日(11日)に開催されたビッグデータ基盤技術勉強会に参加して発表してきた。招待してくれた川島先生には感謝しかない。それにしてもあれ研究会じゃないの、ビッグデータとかいまさら冠するなんて、なんというダサいネーミングセンスなんだと思ってはいけない。世間がやっと俺たちに追い付いてきたんだから、ダサいと思ってはいけない。飽きたころに慣れたものをやめてサッサと次に行っていいのは式年遷宮だけだ。

ぼくの発表もなるべく復習に徹して、研究会だからなにか新しいことを言わなくてもいい、インダストリアル枠だしわかってることを解説していこうというスタンスで解説した。詳細を省いているところも、語弊があるところもあるがお許しいただきたい。

さて丸一日盛り上がってワイワイやった後に、吉祥寺で本番の会があって、そこでまた(いつもの)いろんな人と話した。そこで川島先生と、僕の日本のデータベースコミュニティが盛り上がらないのはよいシステム系の講義がないという主張の話になった。「あしたの授業でそういう話するけど、どんな話したらいいと思います?」という話になったので、そこで伝えたんだか伝えてないんだかよく覚えてないんだけど考えをここにまとめておこう。

ガチで詰め込むのもアリだと思う

有名なものだとUCBのCS262があって、これはアメリカだとどこの大学でも同じ番号がつくようになっているのかな?基本的にはこれを半期やるだけでも全然違うのだけど、これが知ってる限り理想的かな。ちょっと検索してみただけでもいくつかある。

あとは、分散系もひと通り理論は聞きかじっておいたほうがよくて、やはりNancy Lynchの分散アルゴリズムの講義は、他に選択の余地がない感じ。佐藤先生がいう通り、用語がクラウドまわりと若干ズレていたり、実装なんか関係ねーよ!というガチ感はあるのだけど…プログラミングの世界でいうSICPみたいなものか。MITはそもそもElectrical Engineering and Computer Scienceの学科のOCWがガチすぎて目移りしてしまうね。

ここまで来たらあなたもいっぱしに知ってると語れるはず。次は論文をガンガンと読んでいこう。僕の同僚のReading Listが、贔屓目に見なくても分散まわりをきちんとまとめていて流れを抑えている。最近はSparkやらTezやらKafkaやらいろいろと目移りするように新しいソフトウェアが登場しているが、このReading Listを押さえているのと押さえていないのでは理解度が全然違う。

システム系の話は聞くんだけど実感がない

これは、質問されてから思いついたのだが、単にアメリカでされているようなトピック、内容の講義を真似しても意味がないというか、(僕がそうだったように)日本の大学生はそのレベルからスタートできないだろうという予想がある。これはどうしてだろうかと考えながら話して、…そもそも現実世界のサーバー群は分散システムなわけで、通信は本質的にAsyncronyだしPartial Failureが起きるのだけど、講義で耳で聞いてもピンとこない。そういった分散システムのモデルを講義で語るだけでなくて、デモンストレーションや思考実験で理解させるような工夫が必要なんじゃないかと提案した。

で、シャワーを浴びながら考えたのは、そういう学生実験がないことに思い至った。ぼくは大学に入った年から毎年のように何か実験がカリキュラムにあったのだけど、データベースや分散システムに関する実験がカリキュラムに組み込まれていなかった。最近はHadoopを使う何がしかの何かがあるという話も聞いているが、まあそれは使うだけだ。Hadoopを使って何かしら計算機科学について学びがあるかというと、僕はそんなにないと思う(並列処理なら、スレッドプログラミングやMPIの実験の方が学びが多い)。

あと、ひとつだけ古いんだけど良さそうな講義資料を見つけたのでここにリンクしておこう => モバイル通信プロトコル授業資料

主催側のみなさんには本当に頭が下がります。ごくろうさまでした。