Software Transactional Memo

STM関係のことをメモっていこうと思います。

分散システムについて語らせてくれ。顛末と反省。

8/10のNTT Tech Conference #2 にて発表の時間をもらってこのタイトルで喋ってきた

ntt-developers.github.io

発表が決まるまで

これはNTTグループ内のソフトウェア・ネットワーク系技術者が集まるコミュニティで、誰が発表者になれるかは投稿されたProposalに対するコミュニティ内での投票によって選考される。

何を話したいか自分の中でも固まりきっていなかった上に、主催者の話をロクに聞いていなかった自分は小さい部屋で僕のことを知る人しか集まらない不人気セッションを勝手に想像しており、abstractを書く欄に「実世界で使われている分散システムを構成する際に理解してほしい議論についてkumagiが一人で滔々と語る。」という漠然とした説明を書いた。初心者にこそ聴いて欲しいという身勝手な理由でレベル設定をBeginnerにし、自己紹介欄に至っては本当は経歴などを色々書くべき所に「データベースの研究をしている」としか書いていなかったし、お前やる気あるのか、いやこれで落選するならそれもやむなしというつもりでProposalを投稿した。

そして投票結果はまさかの一位通過となり、無事にメイン会場でガッツリ発表時間を貰う事になった。初めからunconferenceに投稿しておくべきだった。この時点でチーム内slackには漠然としたリアクションしかしていない僕だったが内心は焦燥感に満ちていた。これはふざけている場合ではなくなった。

発表当日

当日というか前日からだが、社会人としての基本ができていない僕は案の定極限まで作業を遅延評価し続け1ページたりとも資料を作っていなかった。発表の数日前になってカレンダーを見て、発表日時は3週ほど先なので気長に作ろうと思っていた自分の浅はかさを悔いた。が、後悔はしても反省をしていない、多分こいつはまたやらかす。

次ぐらいはまともな時期に資料を作り始めたい。 そして資料を作る集中力が続かなくてFGOを立ち上げ、水着イベントなのに期間限定が一つも引けてないので無料石で回したら1%SSRの更にピックアップすり抜けを引き当てる。

 そしてFLP Imposssibilityの話の裏付けを確認した後で、そうなるとFailure Detectorの議論はどうやって収束性の判断をしているのだろうかと気になって論文をあさり始めたころのツイート。

 そしてもう空も明るくなりつつある4:33に、2PCとPaxosの説明を過去の資料から取り込んで説明を補正しながら悟りの境地に至りこのツイートを放ち、寝る。

そして多少の睡眠を取って昼過ぎに会場入りし直前まで資料を手直ししてRaftなどの説明を継ぎ足し発表を行う。同一時間帯にOSSコミッタや暗号ハンズオンの話があったにも関わらず幸いにして会場のどの机にも人が座っている程度の観客の入りを観測できた。(むしろそれら2つのセッションは自分の発表と被って居なければ聞きたかったセッションTop2である)

肝心の発表内容は、会場入りしてからも資料に手を加えたり、時間をロクに把握せずもちろん発表練習もしていない有り様で、いつもの噛み噛み高速トークでいろいろ口を滑らせながらPaxosの話がノリに乗ってきた所でタイムオーバーとなった。

 などと煽られたが完全にそのとおりである。

資料のErrataやらなんやら
 
Q. Raftの説明間違えてない?
A. 間違えてる。うろ覚えで資料作るもんではない。ここに関しては僕が手を尽くして説明するより
The Secret Lives of DataのRaft の説明が至高なのでそっちを見て欲しい。

 

Q. 資料わかりにくい
A. 口頭で補う気マンマンのところがいくつもあって資料に落とされていないし、そもそも僕自身がスライド単品で説明が完結する資料(いわゆるスライデュメント)を好まないので後日資料だけ見てもわからない事が多いと思う。やはりその場に来てくれた人へのライブ感を大事にしたいし、資料を読むだけで完璧に理解してもらえる物を目指すならそれは長文ブログ記事なり書籍なりで狙って行きたい。もちろん他の人がもっとわかりやすい資料をバンバン公開してくれたら僕も第三者ももっとハッピーになるのでそれも期待したい。
 
Q. そもそも壊れやすいようなマシンを使うからこんな困難に遭うんでしょ
A. 壊れにくいマシンそもそもすごく高いじゃないですか。
Q. 壊れにくさそのものが価格に完全に跳ね返ってるわけではなく、あれは安心料みたいなもんだからまだまだ価格が安くなる余地はあるからそっちに期待しても良いのでは?
A. 故障率1/10のサーバが2倍程度の値段で買えたとしても、それを100台並べたらその中の1台以上が壊れる確率はざっと100倍になるわけで、一台のサーバの故障率が1/10だとかは些細な改善で根本的な解決にはならない。高信頼なハードウェアを使う事はそれはそれでコストダウンが見込めるなら導入すれば良いが、ハードウェアそのものの信頼性を分散システムの最初かつ最後の砦にしてしまうとやはり大規模化した際には高確率で壊れてしまう。つまりハードウェアが丈夫になっても分散システムの耐障害性の研究が無意味になることはない。
 
Q. 本番もっとぶっちゃけてたよね
A. あまりおおっぴらに言えないような事をいろいろ喋ったけれど、そこは現場のライブ感を楽しんで貰いたく、更に後日資料を見るだけの人にまでその価値をお届けするのは無理と判断した。
 
Q. 資料はいっぱい見てもらえててすごいね
A. 自己ベストの参照数とはてブ数をもらっている。NTTパワーすごい。
個人的には僕自身の資料ツイートを差し置いて

 この1ページを呟いたツイートが2000Fav&2000RT超えてる点が世の中の需要を捉えているなと感じた。個人的には発表資料をただ眺めるだけより面白い話を口頭でしているつもりなので是非生で見て欲しい。

 

Q. Latency Numberの出典はJeff Deanなの?

A. 僕は彼の発表資料から抜粋してきたから間違いでは無いが

https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

が、彼が引用したオリジナルの出典はどうやらこっち?

Teach Yourself Programming in Ten Years

右揃えと左揃えによる僕のスライドにおけるレイアウトは僕の工夫。

 

Q. Primary BackupとChain Replicaitonはバグっている事になるの?

A. Failure Detectorとそれに従うプロトコルを正しく実装すれば仮想的にFail-Stop故障モデルに近い状態を作り上げる事ができるのでその方向に倒したほうが良い。Paxosなんかは過半数のマシンが生きていないとシステムとして破綻してしまうけれど、Primary BackupやらChain Replicationやらは最後の1台だけでも生きていれば稼働するし、合意云々を頑張る必要もないので速度・効率・耐障害の観点では理想に近い。異常系の実装が難しいだけ。

 

Q. もっとちゃんと準備してちゃんと発表しよ?

A. すいませんでした。以後気をつけます。