最後のYAPC::Asia Tokyoでコンテナの作り方についてしゃべりました
ブログを書くまでYAPCは終わらない！ということで…
先週末の8/21（金）、22（土）に、今年度で最後とされる YAPC::Asia Tokyo に参加してきました。初めて参加したのが多分東大開催の年だったと思うので、多分2012年…？から毎年欠かさず参加してきた YAPC::Asia Tokyo もついに最後の年ということでした。今年は最後の年だし…ということで、去年まで単なる参加者に徹してきましたが、同僚の @maokt の誘いに乗ってトークに応募してみることにしました。応募は締切日の日が変わる直前に滑り込み*1、大した宣伝もしなかったのであのとてつもない倍率の中採用されたときはビックリしましたが、きっと少しはトークの内容に興味を持ってもらえた？のかなと思います。
自分のトークについて
少し迷ったんですが、トークは結局英語にすることにしました。というのも、同時翻訳の準備をしてもらえそうだったので、それなら私が英語で喋れば、英語・日本語どちらでも好きなほうでトークが聞いてもらえると思ってのことです。相談の結果、自己紹介のみ両スピーカーとも日本語で、それ以降を英語＋同時通訳ということにしました。もちろん英語 only の参加者は少なくはありますが一定数いるので、結果的に英語で話すことにしてよかったと思います。同時通訳を用意してくださった運営側、またネイティブでもない私が喋る英語をうまく訳してくれた（自分ではもちろん聞けなかったんですがクオリティが高かったらしい）同時通訳者の方に感謝です。
トークの内容は、" Linux コンテナを Perl で自作する"をテーマに、現在話題の Docker などで使用されている技術がどうやって実現されているのかを深堀りしていく話をしました。実際のところこの内容に Perl を使う必要性は全くなかったんですが、 YAPC だし Perl monger 向けの解説、ということで。トークを聞きに来てくれる方がどれくらい Linux の OS レベルの話に親しんでるか全く予測がつかなかったので、mount, /proc, uid / gid / capability あたりの基礎から始めたのですが、twitter での反応を見る限りは正解だったかな、と思います。前半で基礎的な話をして、後半でシステムコール unshare を使った実装の話をしました。時間的に cgroup や network name あたりは踏み込むことはできず、mount / user / pid namespace の話に集中する、といった構成を取りましたが、これもまぁ結果的にはよかったかなと思います。cgroup とかを入れてたら、多分ごちゃごちゃしすぎたかなと。
Docker や Linux コンテナ関連のトークは最近よく見ますが、これを使うとこういうことができてクールだよ、とかこういうユースケースがという話になることが多いので（機能上あたり前だけど）、実は中でこんなことが…という話にフォーカスしたものがたまにはあってもいいのかな、と思ってこの内容にしました。個人的にもこのへんの機能によって kernel のコードも少し昔のものと変わってしまったんだろうな…と思っていたので、学ぶきっかけになってよかったです。
トーク準備は全体的に少しバタバタしてしまって*2、スライドの準備も直前となってしまい、@lestrrat さん、同時通訳のスタッフさんには多大な迷惑をおかけしました。申し訳ございませんでした。
スライドは、弊社内でのしかるべき許可がおりたらアップしますので、少々お待ちを…
また、弊社ではエンジニアを積極採用しております。トーク中にもお話しましたが、Open Container Initiative などにも金融分野の会社からは珍しく参加してまして、技術的にも面白い課題のある職場だと思います。興味のある方は @nukamu までご一報を！（採用権限は全くありません笑）
YAPC::Asia Tokyo について
10年来の歴史を持つ YAPC::Asia からすると新参者だったし、多くの参加者が所属するであろう web 企業の人でもなかったので知り合いもそう多くはありませんでしたが、YAPC::Asia には毎年参加しては楽しませてもらっていました。普段 Perl もそんなに書きませんが、そんな私でも受け入れてくれる非常に懐の広いカンファレンスでした。今回が最後ということですが、交流させていただいた人たちにはまたどこかで会える気がしています。また何かしらの YAPC があるかもしれないですし、Beacon も開催されるかもしれませんし*3。先のことはわからないですが、また着々と自分がエンジニアとして成長できるよう、日常に戻って頑張っていきたいと思います。@lestrrat さんをはじめ、スタッフの皆さまには本当に感謝しています。ありがとうございました。
皆さま、3日間（人によっては4日間？）お疲れ様でした。またどこかでお会いしましょう！
今年一番感動した技術 - Google BigQuery
【この記事は Tech Women Advent Calendar の16日目の記事として書かれています】
Tech Women Advent Calendar ということで、全く Women であることには関係ないのですが、今年1年のまとめも兼ねて、今年印象に残った技術について書こうと思います。
今年の技術的 Input
今年は社会人2年目、1年目のように時間に融通がきかなくなってくるころですが、それでもいくつか、ちょこちょことカンファレンス・勉強会に出没してました。
大きめ（？）カンファレンスとしては、
なんかに行きました。この他にも色々と行きたいものはあったのですが、日程の都合などにより断念（PyCon とか、行ったことないし行ってみたかった…普段 python を一番多く書くのに）。他にも勉強会的なものには面白そうなもの手当たり次第、月1, 2くらいで行ってたかなというくらいです。
今回のブログにはこれらのカンファレンスのうち QCon 以外の3つで取り上げられていて（LinuxCon / Hadoop Conference / YAPC ）、個人的に最もおおっと思った Google BigQuery に関して書きます。
Google BigQuery
Google BigQuery は、Google 内部で2006年ごろから使われている Dremel というカラム型データストアを外部の人が使えるようにしたもので、アドホック/インタラクティブなクエリを扱うのに適しています。とりあえず Google の佐藤さんが出した white paper "An Inside Look at Google BigQuery - https://cloud.google.com/files/BigQueryTechnicalWP.pdf" は読んでみましたが、インデックスなしで350億のレコードを数十秒で総スキャンできるそうです。キーとなる技術としてはざっくりまとめると、
- カラム指向のデータストアであること (Columnar Storage, p4)
- Traffic minimization - “SELECT top(title) FROM foo” といったようなよくあるクエリでは、あるカラムのデータしか必要としないのでデータ転送を少なくできる
- Higher compression ratio - row-based なデータストアよりもデータの圧縮率を高めるのが容易
- サーバ群間のデータ通信を木構造で行う (Tree Architecture, p4-5)
- 短い時間の間に効率的にクエリを数千以上のサーバにディスパッチし、結果を収集することができるように木構造で通信を行う（記事中の図がわかりやすい）
ということです。詳しいことは Dremel の paper (link) に書いてあります。インデックスは基本的に作りません。構造化されたデータを（正規表現は使用可）SQLで、より素早く/アドホックに扱うのが Dremel/BigQuery のターゲットで、バッチ処理に向いている MapReduce とはそもそもターゲットが違うようです。
Google BigQuery ではストレージのコストが $0.026 per GB per month、クエリのコストが $5 per TBで Google の持つ巨大なインフラを用いた解析が誰でもできるように、ということで第三者へのサービスを展開しています。
何にそんなに感動したのか
最近はこの類のデータストアも色々あっていろんな界隈で盛り上がってますが、私は実際に Google がこれをインフラ含めて（しかも格安で）第三者向けに提供できるところまで来てるということに驚きました。実際 BigQuery は Google の所有する豊富なインフラがあってこそこんな速さが出せるもので、技術的にはそこまであっと驚くアイデアによるものではないかもしれません。ただ、私は大学・大学院で並列データ処理の研究をしていましたが、研究では多めに見ても30台くらいのサーバで並列化・実行時間を短縮といった実験をしてたので（それでもコア数としてはそこそこありますが）、そのスケールにはさすが、という思いでした。Google では数千のサーバをフルに活かして並列度を出しているようで、他ではそんな並列度を生かしきれるような環境はなかなかない…分かっていてもできない、というのが実際のところ大学含めた研究機関でも多いと思います。
研究機関以外でも、企業で、インフラを必要とすることもなく、プログラマ以外の人でも簡単に格安にアドホックなクエリでデータ解析ができる BigQuery は、日々の仕事のやり方を変えるようなソリューションとなり得るんじゃないかと思います。
ただ、Google が "Google BigQuery for Open Data" としてるように、なかなか企業の持つデータをどんどん BigQuery に置いて解析しましょう、ということには今の状況ではならないかもしれません。
Google が Dremel 以前に使っていたと言われる MapReduce が発表されたのが 2004 年、Dremel は2006年ごろから社内で使われていたようなので、もうすでに Google では次のソリューションに移行しているのかも？と思うと、技術者としてはなんとも悔しいところではありますが。
来年の抱負とか
もう気づけば2014年も終わりですね…今年はプライベートで色々忙しかったのでなかなかでしたが、来年はもっとエンジニアリングにも時間を使っていきたいです。
今年も皆様お疲れ様でした。来年も頑張りましょう。
YAPC::Asia 2013 に参加してきました
もう2週間も経ってしまってますが、今年もYAPC::Asiaに参加してきました。
前回の東大開催のものに引き続き2回目です。
前回とは違ってもう学生ではないのですが、上司にYAPC行きたいんだけど…と相談したら金曜日をトレーニング扱いにして行かせてもらえることになりました。ラッキー。
私は特にPerlを業務で多く使うわけでもないので、トークについていけるのかと心配してたりもしましたが、意外と大丈夫でした。
個人的にはHisamoriさんのRiakの話とか特に興味深くきかせていただきました。
全体的にみなさんうちではこうしてます！という話をしていただけることも多く、そのへんの自由度が高そうでうらやましく思ったり。（私が会社の業務のことなんかしゃべろうとしたら、険しくて終わりない承認プロセスがry）
まぁそもそも業務であまりPerlを使うことがないんですけどね。
(追記: 気のせいでした、これからガッツリ使いそうです笑)
昨年、今年と参加してみて少し感じたのは英語のトークが減った？とか。
昨年はひとつの部屋ではだいたい英語トークしてる印象だったのですが。（ただの印象なので定かではないです）
今回同じく参加した同じチームの上司は英語ネイティブですが、日本語は勉強中なのでまだ技術の話を日本語できくのは難しく、聞くトークを選ぶのが大変そうに見えました。
（まあスライドやコードなどで大筋は理解できることも多いようでしたが）
テクノロジの話をするのに自然言語の違いが障害になって、というのはなんとも悲しいので、早く翻訳こんにゃくできないかしら（笑）
今でこそ、外資系の会社で半分くらいの人が日本語しゃべれない、みたいな会社に入ってしまったので英語に対する苦痛はなくなりつつありますが、もともと英語は大っ嫌いで避け続けてきた人間なので、そんなことを思ってしまいます。
なんにしてもやっぱりYAPC楽しいところですね。Perlにどっぷりって人以外にもプログラマなら楽しめるかと思います。
運営の方々はお疲れさまでした！
来年のYAPCはどのように開催されるかわからない、そもそも開催されるのか？ということですが、きっとあるでしょ！ってことで、今後の発展も期待していきたいと思います。
とりあえずご挨拶
2011年、年の瀬にやり残したこととしてブログの設営しました。
# 大晦日に実家で何をやっているんだろうか…ｗ
来年になりますが、色々更新していきたいと思います。 実はこのようなものを作ったりするのは初めてです。ので、何を書くべきなのかよく分かりませんが、情報系の大学院生として、情報技術関係のことが多くなるのかな、と思います。あとは一応今年（いや来年か）は就職活動をする年らしいので、そのへんの所感とかもあるのかもしれません。
そういえば、はてなダイアリーとはてなブログ（ベータ版、こないだまで招待性だったけど、数日前にオープンになったらしい）とどっちでブログ開設しようか迷ったけど、とりあえず今後の発展に期待してはてなブログにしてみました。 デザインの候補が少なくて、はてダみたいにカレンダーとか出したりできないの？と思ったりとか、 Linux版chromeでは見たまま編集でたまにバグったりとかしたけど、そのへんは今後の発展に期待です。
とりあえず開設＋ご挨拶まで。
あと2011年も数時間ですが、よいお年を。そして来年も皆様よろしくお願いします。
