QConTokyo 2015 で喋ってきました

QCon Tokyo 2015 Conference｜QCon 東京 2015 カンファレンス

QConTokyo 2015で、データベースアーキテクチャーの動向と使い分けというお題で発表する機会があった。Bashoは2014年2015年にかけてQConのグローバルなゴールドスポンサーをやらせてもらっていて、ロンドン、サンフランシスコでも社員が喋った。東京は…英語以外の言語での開催はここだけなので、で、日本語でQConぽい話ができる…ということで僕が喋ってきました。

speakerdeck.com

有料イベントで話すのは初めてなので、果たして対価に見合う話を聴衆にできるのか全く自信はなかった。裏番組はGoogleの中の人が話すGolangセッションだから、そもそも人が来ないかもしれない。と思ったら一番広いホールじゃねえか。しかも、いつもはデータベースとかインフラ系の技術に興味持って集まる人が対象だけど、今回は幅広い層の聴衆が来ているはずで、実際スーツの人が多くて…といつもとは違う感じだった。

特に聴衆の関心が読めなかったので、データベースの細かい技術の話やバズワード、マーケティング的ポジショントークなんかをなるべく入れないことを前提に話を練ったのでわりと苦労した。ここまでちゃんと準備してスライドを考えたのは初めてかもしれない。話の筋を考えることに集中したので、結果的にスライドにほとんど絵を入れられなくて文字ばかりになってしまったので、当日はちょっと退屈そうな人もチラホラいた。非常に申し訳なかった。ぼくも文字ばかりのスライド、本当は嫌いだ。

ぼくがあの話をしたその翌日にHacker Newsで Call Me Maybe: MongoDB Stale Reads | Hacker News のスレが盛り上がっていた。このはなしは大分昔にKyle KingsburyがちょっとTwitterで書いていたのでなんとなく知っていたが、果たしてどうなることやら…ｗ 偶然だけど、日本ではLAMPスタックに加えて解析基盤と非同期実行のMQが入り始めたくらいで、システム自体の複雑化や大規模化がそこまで進んでないようにみえる。だからまだ問題になり始めていないのだけど、ネットワークは信頼できると思ったら大間違いなわけで、そういった認識が日本でも広まればいいなと思って書いた。データベースの技術はそのネットワークに依存しているわけで、そこはさすがに同意していただけるかなと思う。でもまあ、当たらぬも八卦、当たらぬも八卦ということで今後の成り行きを見守っていきましょう。

QCon当日はいろんな人と話したり、いろんな話を聴くことができて、世の中にはデータベースだけじゃないんだなあと改めて当たり前のことを確認したのであった。しかしテクノロジーカンファレンスなのだから、会場のWiFiはもうちょっとなんとかできると思うぞ。カンファレンスネットワーク、わりと技術的には難易度高いけどホラ、今は日本にもCONBUとかあるから。

「技術」という言葉について

とくにソフトウェアとかインターネット的な世界のはなし。典型的な用法は「〜〜という新しい技術を仕事で使いたいのだけど、上司が許可してくれない」というものだ。この〜〜には、たとえばちょっと前だとLAMP, Ruby on RailsとかAWSとかHadoopだし、今だとなんだろう、DockerとかC#かな。うーんこの違和感。私の定義では、これはどれも技術ではない。ただのソフトウェアだ。AWSはサービスだ。

TCP/IPやSIPは技術だろうか？わたしの感覚ではノーだ。ただの仕様だ。いずれもベースになっている技術はあって、たとえばパケットのルーティングや名前解決、フレーム再送やウィンドウ制御の仕組みや実装は技術といっていいだろう。Hadoopは分散処理の技術を実装したソフトウェアだ。LAMPはWebサービスを実装するためのソフトウェアスタックの総称で、そのなかに様々な要素技術はあるだろう。Dockerの中で使われいているAufsや依存性管理の仕組み、名前空間などを使ってインスタンスを分離する仕組み自体は技術だが、「Dockerという技術を習得する」という日本語は間違っている。

もうちょっと展開してみよう。Git引いてはGithubをソースコード管理などのツールとして導入したときに、「Githubという技術を導入した」とは言わない。「Gitという技術を導入した」これもおかしい。「レポジトリを分散して管理できる技術を実装したGitというソフトウェアを使って、分散レポジトリを活かした開発フローを導入した」これくらい言わないと技術という言葉は使えない。課題を解決する体系立てられたワザを技術というのであって、ソフトウェアやサービスそのものを技術とはいわない。

わたしの感覚だと、片仮名でテクニックといわれる種類のものの方が技術と呼びやすい。たとえば探索系の問題があったときに単に深さ優先にするのではなくて、DPで実装する。数値計算ならdoubleとfloatで使い分けるコツが違うし、できればSIMD使いたいけどちゃんと実装するのは難しい…（SIMDをちゃんと実装した数値計算のライブラリがあったとして、それは単にライブラリであって技術とは呼ばない）。たとえばMySQLのbinlogレプリケーションはSplit brainが起きるけどSQL ServerならPaxosを使っているのでそれが起きない、とかそういうの。

よく「○○を支える技術」といって、その会社なりサービスを支えるソフトウェアスタックや、その運用を紹介する本が出版されよく買われるようだ。その本は、単に採用されているソフトウェアなりサービスのリストが書かれているわけではない。大抵はそこにある課題と、それを解決する方法が書かれていて、その方法のひとつの実装としてソフトウェアなりサービスの名前が載っているわけである。

もうちょっと違う説明の仕方にしようか。たとえば自分たちのECサイトにリアルタイム推薦を導入したい。そのときにリアルタイムレコメンドができるJubatusを導入するとしよう。Jubatusは新しい技術か？わたしの定義ではそうじゃない。Jubatusはソフトウェアだ。そこに実装されているLSHや、それを複数ノード間で同期する仕組みは技術だ。別にJubatusじゃなくてもSolrでもなんでもよい。Solrそのものはソフトウェアだ。その中で実装されているTokenizerや転置インデックス、インデックス更新の仕組み（詳しく知らない）は技術だ。やりたいことを実現する手段なり工夫なりを技術というのであって、ソフトウェアやプロトコルのことを技術とは呼ばない。

これが私の定義なのだが、Wikipediaなどを見ると「そもそも多様である」的なことが書いてあるの。インターネットでちょっと私の定義の合わない用法があったとしてもまあ言葉狩りだと思われたくもないので、まあ喧しく言わないようにしてここに書いて忘れることにする。

ちなみに、件の上司は、「○○という（仕事の）課題は、△△という技術で解決できるのですが、それを実装したものは〜〜というソフトウェアしかないので、〜〜を使うしかないです」といえば説得できると思う。それであなたが使いたいものは何でも仕事で使えるようになるよ。

キッチンライフを少しだけ楽しくする課金アイテムKitchen Aid

我が家では家事を楽にするための設備投資は推奨されている。最新の課金アイテムはキッチンエイドのスタンドミキサーというやつだ。これの便利さは折り紙つきで、なにせ手を汚さずにいろんなものを混ぜることができる。海外の料理番組では「キッチンエイドの目盛り４で５分間混ぜる」といった風にレシピが記述されているらしい。アタッチメントをいろいろとつけかえることで、様々な混ぜ具合や材料に対応している。テクノロジーは人間を楽にするだけでなく、作業を定量化することにも貢献しているのだ。ハンバーグをこねる、餃子のタネをこねる、クッキーやケーキのもとを作るといった用途で広く知られているこの道具だが、今回はちょっと変わった用途に使ってみた。

【業務用】キッチンエイドミキサー スタンダードタイプ 4.8リットル【KSM5】【KitchenAid】 ホワイト

今回の材料は納豆である。納豆の既製品を買ってくるまでは異論の余地はないだろうが、その食べ方にはさまざまな議論がある。そこにかけるものの多様さは生卵、刻んだ葱、醤油、等々。中でも混ぜ方は大きな問題で、

• ふっふはっど　納豆　混ぜ方
• 魯山人と納豆／400回もかき混ぜたのは本当？
• 納豆、ベストの混ぜ方は？　１万回混ぜると…

すこし検索すればわかるが、いくつか流派があるようである。わたしの理解だと、およそ5〜10分ほど箸で力を入れて混ぜるのが泡立ちと粘りのバランスがとれていて丁度よさそうだ。一方で妻はあの泡が苦手で、ほとんど混ぜないのが好みなのだそうだが…今回問題にしたいのは、ちょうどよい混ぜ具合になるまでのあの手間である。腕が疲れる。指が疲れる。白飯が冷める。飽きる。もうやだ。でも粘りのある納豆を食べたい。ということでキッチンエイドで納豆を混ぜた。その様子を撮影したのでご覧いただきたい。

Mixing Natto with Kitchen Aid - YouTube

これは、KSM5という機種のスタンドミキサーで6〜7分、目盛り2〜3にして混ぜたときのものである。納豆は一般的な3パック組のものを一度に3パック投入した。粒はいささか大きいが、小粒のものにしておけばより潰れにくいだろう。人間が混ぜるよりもはるかに高速で強力な様子がわかるだろうか。

そうして混ぜたものの結果がこれだ*1。

今回は実験的な意味もこめて少し長めに混ぜた。おそらく混ぜ時間は4〜5分が最適ではないかと思う。長く混ぜてしまうと、粘りが落ちてきて粒が潰れてしまうためだ。しかし写真の品は泡がよく肥大し、米粒とよく合わさって味は非常によかった。粘りが苦手という人はキッチンエイドを使って長めに混ぜてみると、手で混ぜたのでは得られない食感が得られてよいかもしれない。

*1:カラシが垂れているのは付属品のご愛嬌ということで勘弁

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 さんがTwitterでLeslie 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 MeetupやSecure AWS Users Groupがあったりして参加人数を懸念していたが、それなりに濃い話がみんなとできて非常によかった。ぼくの発表スライドはこれ。

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

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

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

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

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

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

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