パフォーマンスの観点からみるDockerの仕組みと性能検証 #dockerjp

Docker Meetup Tokyo #4 にて「Docker Performance on Web Application」という題で発表しました。 発表内容は、下記の2つの記事をまとめたものに加えて、最新バージョンの Docker 1.4 での ISUCON ベンチマークと、storage-driver として Device Mapper + Docker 1.4 から実装された [OverlayFS:title=https://github.com/docker/docker/pull/7619] を試しました。

この記事は、上記2記事で、いくつか難しいポイントがあったとフィードバックをいただいたので、Docker Meetup での発表内容を少し詳しめに説明したものになります。

1. Dockerのパフォーマンスについて重要な事はなにか

Docker のパフォーマンス検証に関する IBM の Research Report である An Updated Performance Comparison of Virtual Machines and Linux Containersの内容などから Linux Containers、UNION Filesystem、Volume、Portmapper、Host Networking が重要な要素であることがわかりました。

Docker Items

Linux Containers

まず、Linux Containers については、コンテナという機能があるのではなく、カーネルの各リソース(ファイルシステム、ネットワーク、ユーザ、プロセステーブルなど)について実装されている Namespace によって区切られた空間のことをコンテナと呼んでいます。つまり、Namespace で隔離された空間でプロセスを生成するというモデルになります。(普通のプロセスと扱いが変わらないので、Dockerコンテナの起動が速いのは当然)全ての Namespace を同時に使う必要はなく、一部の Namespace を使うことも当然可能です。(例えば、docker run コマンドの --net=hostオプションは、Network Namespace を使っていないだけのはず) Linux Containers は単体のカーネルで動作するので、親と子で別々のカーネルをもつ Hypervisor による仮想化と比べて、CPU命令をトラップしたり、メモリアクセスやパケットコピーの二重処理をしなくていいので、オーバヘッドがありません。(もちろん、VT-xやSR-IOVなど、ハードウェア支援による高速化手法はある)

@ten_forward さんの記事 コンテナの歴史と Linux カーネルのコンテナ関連機能についての割とどうでも良い愚痴 - TenForwardの日記 を読むとよいと思います。

Linux Containersについて実装レベルで理解されている方々にとっては、普通のプロセスと対して変わらないし、わざわざ検証するまでもないかと思いますが、production でのサービスインを考える上で一応見ておかないといけないと思いました。

UNION Filesystem

次に UNION Filesystem については、下記の公式画像をみるとだいたいわかった気になれます。

UNION Mount という手法でファイルシステムの層が実現されており、要は既にマウントされているポイントに対して重ねて別のブロックデバイス(ディレクトリ)をマウントし、最上位層のみを read-write 属性に、それ以外の層を read-only にするようなイメージです。複数のブロックデバイス(ディレクトリ)を同じマウントポイントからアクセスできます。 基本的に、任意のファイルシステムの状態から新規書き込みの分だけ上位層に書くようにすれば、最下層にベースファイルシステムがあり、その上に差分データだけを持つファイルシステム層が乗っていくようになります。

このような仕組みを実装するにあたって、ブロックデバイスレベルでの実装とファイルシステムレベルの実装があります。 Docker では storage-driver というオプションにより、UNION Filesystem の実装を切り替えることができます。 aufs,btrfs,devicemapper,vfs,overlayfs を使用可能です。 devicemapper がブロックデバイスレベルでの実装であり、aufs,btrfs,overlayfs がファイルシステムレベルでの実装となります。(vfs は docker側で無理やり層を作ってる?) Device Mapper は特定のファイルシステムに依存しないかつ、カーネル標準の機能なので気軽に使いやすいというメリットがあります。(LVM にも使われている) 一方で、Device Mapperの場合、イメージ層の作成・削除の性能は落ちるという検証結果もあります。(Comprehensive Overview of Storage Scalability in Docker | Red Hat Developer Blog) 汎用的でプリミティブな機能を持ったDevice Mapperを使って逐一、層となる仮想ブロックデバイスの作成や削除をするより、専用の機能を実装したファイルシステムレベルの実装が速そうというのはなんとなくわかる話ではあります。

発表内でデフォルトが Device Mapper とか言っていましたが、RHEL/CentOSでは事実上 Device Mapper がデフォルトであるというのが正しいです。 お詫びして訂正します。(ISUCON ベンチマークで使った Ubuntu 14.04 では、modprobe aufsした状態でデフォルトが devicemapper になっていたはずなんだけど、カーネルバージョン変えてたし、なんかミスってたのかもしれない) ちゃんとコードを読んでみると https://github.com/docker/docker/blob/5bc2ff8a36e9a768e8b479de4fe3ea9c9daf4121/daemon/graphdriver/driver.go#L79-84 となっており、aufs,btrfs,devicemapper,vfs,overlayfs の順になっているようで、デフォルトが AUFS というのが正しいです。

Volume

UNION Filesystem を使うと複数の層に対して、I/O要求もしくはその他の処理が多重に発行されるはずで(最適化はされているとは思いますが)、オーバヘッドが気になるところです。Docker には Volume という機能があり、これを使うと指定したディレクトリを UNION Mount しないようになります。したがって、そのディレクトリ以下のファイルへのI/O効率がよくなる可能性があります。

Volume 自体はパフォーマンス目的で使うものではなく、コンテナ間もしくはホスト・コンテナ間でデータを共有するためのものです。

Portmapper

コンテナ間通信やホスト・コンテナ間通信では、ホスト側の iptables によるNAPTで実現されています。(172.17.0.3がコンテナのIP)

-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.3:8000

ただし、iptablesが利用できない環境のために、コンテナ間通信のみ docker-proxy というユーザランドのプロキシが使用されます。docker-proxy自体はiptablesを使っている使っていないに関わらず起動しているようです。

docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 80 -container-ip 172.17.0.3 -container-port 8000

iptables、つまりカーネルランドの netfilter で NAPT できるところをユーザランドのプロキシを経由すれば明らかにオーバヘッドが大きくなるという予想がつきます。

Host Networking

Docker では Network Namespace を使わずに、ホストと同じ Namespace を利用する Host Networking 機能があります。 Host Networking は --net=host で使えます。 ネットワークについては、ホストでプロセスを起動するのと変わらないことになります。 これならば、先ほどの Portmapper が必要なくなるため、NAPTのオーバヘッドがなくなります。

Host Networking については @deeeetさんの DockerのHost networking機能 | SOTA が詳しいです。

2. Docker化したISUCONアプリケーションのベンチマーク

ベンチマークは、Nginx と MySQL をこれまで紹介したオプションを切り替えて Docker化 して、それぞれのスコアを比較しました。 環境は前回との差分はより新しい Linux カーネル 3.8.0、Docker 1.4.1 を使っている点です。 詳しい内容は下記のスライドを参照していただくとして、結果は Nginx を Docker 化したときに Host Networking を使わずNAPTさせたときに、15%程度スコアが落ちるというものでした。それ以外の、VolumeのOn/Off や storage-driver の切り替えによるパフォーマンスの変化は ISUCON4予選の環境では起きませんでした。

Host Networking と Volume ON の状態で、性能が変わらないのは予想通りですが、storage-driver の切り替えによりパフォーマンスに変化がないのは意外でした。 これはおそらく、今回の環境では、データが全てメモリにのっているため、Read I/Oはほぼ発生していないということと、Write I/Oは UNION FS の最上層のみに適用すればよいので、複数の層があることによるオーバヘッドがあまりないのではないかと考えています。

NAPTのオーバヘッドが顕著であり、これは docker-proxy プロセスがCPU を 50% ほど使用しているためです。 iptables を有効にしているのになぜ docker-proxy が使われるのかと思いましたが、iptablesのルールに宛先がループバックアドレスの場合はコンテナへルーティングされないようです。

-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER

benchmarker はデフォルトでは 127.0.0.1:80 へ接続するため、benchmarker - Nginx 間での接続に、ホストの 0.0.0.0:80 で LISTEN してる docker-proxy が使われてしまうという事態になっています。 benchmarker のオプションで --host <host eth0 ipaddr> としてやると、iptables でルーティングされるようになるため、スコアはDocker化していない状態とほぼ同じになりました。

なぜループバックアドレスだけ外されるのか

宛先アドレスが 127.0.0.1 のままだと、コンテナがパケットを受信して返信するときに、宛先アドレスを 127.0.0.1 にしてしまい、コンテナ自身にループバックします。 ループバックを避けるため、以下の様なPOSTROUTINGルールでNAPTする設定が必要なようです。 127.0.0.1 がコンテナのIPに書き換わり、コンテナからホストへの返信時に宛先アドレスがコンテナのIPになり、結局自分に戻ってくるようにみえます。しかし、Docker は仮想ブリッジ経由でホスト側のネットワークとコンテナ側のネットワークを接続しているので、仮想ブリッジ(docker 0)のヘアピンNAT(NATループバック)を有効にすることで、ホスト側へNATしてくれるようです。(この辺りすこし怪しい)

-A POSTROUTING -p tcp -s <container ipaddr>/28 -d <container ipaddr>/28 --dport <container port> -j MASQUERADE

ただ、RHEL/CentOS 6.5環境下で /sys以下が readonly でマウントされており、 /sys/class/net/{ifname}/brport/hairpin_mode に書き込めないため、仮想ブリッジ環境でヘアピンNATモードを有効にできないようです。(RHEL/CentOS 6.5環境のみかどうかはちゃんと調べてないです) ヘアピンNAT サポートが一旦、マージされてリバートされたのもこのためです。

発表スライド

さらに詳しい情報は下記スライドを参照してください。

Keynote テーマは弊社のデザイナ @murata_s さんが作ったテーマを使わせてもらっています。

関連情報

RedHatの @enakai さんの必読のスライド。コンテナとVMM、Dockerのファイルシステム、ネットワークについて詳しく書かれていて非常に参考になりました。 26枚目の、iptables でループバックアドレス宛のパケットだけ外されている理由がわからないという点についての回答は前述の仮想ブリッジでのヘアピンNATの話かなと思います。

Linux Containers については、LWN の記事と @ten_forward さんの記事が参考になると思います。

Device mapper については、下記スライドが参考になりました。

UNION Mount については、Oreilly の Programmer's High のブログが参考になりました。

まとめ

Docker化したWebアプリケーションにおけるパフォーマンス研究の成果について書きました。 IBMのレポートの内容から、Linuxカーネルとの接点となるUNION Filesystem や、その他 Host Networking、Volume などがパフォーマンスにおける重要な要素であることがわかりました。そこから、自分で検証してみて、ISUCON4予選問題の範疇では、iptables を使わずに docker-proxy というユーザランドのプロキシの使用を回避さえすれば、いずれのパターンでも性能の変化はないことがわかってきました。

iptablesを切って、nf_conntrack を切ってチューニングするような環境ではそもそもまともにDockerは動かせないので、ギリギリまでリソースを使い切るようなホストの場合はさすがにI/Oまわりのパフォーマンスが問題となってくると思います。 Linuxカーネル、特にUNION Filesystem周りでパフォーマンスに関する知見があればぜひ教えていただけると助かります。

パフォーマンスの観点から Docker を支える技術を調査してきてましたが、だいたい満足しました。1年半Dockerを触ってきて、知見もかなりたまってきたので、Production で Docker を投入できそうな頃合いだと思っています。

会場を提供していただいた Recruit Technologies の皆様、イベントを企画運営していただいた皆様、どうもありがとうございました。 非常に有意義なイベントでした。

はてなではWebオペレーションエンジニア(いわゆるインフラエンジニア)を募集しています。

Webオペレーションエンジニア職 - 株式会社はてな

宇宙飛行士の採用についての本

「ドキュメント 宇宙飛行士選抜試験」を読んだ。

この本は、NHKスペシャルで2009年に放送された番組「宇宙飛行士はこうして生まれた ~密着・最終選抜試験~」が書籍化されたものだ。 JAXAによる宇宙飛行士の選抜試験、特に最終試験における10人の候補者それぞれの背景や試験中の様子を通して、宇宙飛行士とは何か、宇宙飛行士に求められるものは何か、また宇宙飛行士を選抜するとはどういうことかについて、ドキュメンタリー形式で描いている。

ドキュメント 宇宙飛行士選抜試験 (光文社新書)

ドキュメント 宇宙飛行士選抜試験 (光文社新書)

タイトルに選抜試験とあるので、当然宇宙飛行士の選抜試験が具体的にどのようなものかが書かれている。 しかし、一般の企業での採用や就活生の心構えを指南するといった趣旨が中心の本ではない。 むしろ試験内容そのものについては、宇宙ステーションやシャトルでの生活を模した閉鎖環境でのロボット作りやディベートなど、宇宙飛行士という特殊な職種を前提とした内容なので、これをそのまま参考にはもちろんできない。 この本が実際に伝えたかったのは、「宇宙飛行士とは何か」ということだと思う。

「宇宙飛行士とは何か」という問いに対する明確な回答は多分難しくて本文には明示的に書かれていない。 きっと人によって、答えが変わってくる類の質問だと思う。 本来の宇宙の開発・研究のための現地作業員という役割はもちろんある。しかし一方で、世間に対する広告塔であったり、人類代表のように扱われることから人々の希望になることも求められるという。 実際に、候補者の方々の宇宙飛行士になりたい理由として、「医師である自分が宇宙から元気な姿を見せれば、世界中の病に苦しむ人々に、希望を与えられるはず」や「宇宙飛行士になって、子どもたちに宇宙の不思議や魅力を紹介し、科学することの面白さを伝えたい。」という本来の役割とは異なる一種の偶像的な役割が挙げられていた。 これはスポーツ選手に近い性質ではないかと思った。

宇宙飛行士に限らず、自分の仕事が何なのかをシュッと回答することは意外と難しい。 Webオペレーションエンジニアなんてわけがわからん。 逆に言えば、自分の仕事が何なのかを自分の言葉で表現できるようになったときが一人前になったときと言えるのかもしれない。

気になる試験内容は、宇宙兄弟で描かれていた内容とほぼ同じような感じで、宇宙兄弟を読んだことがある人にとっては目新しさや驚きはあまりないと思う。 逆に、試験内容を漫画向けに誇張したりしなくても十分にエンターテイメントになることのほうがすごいかもしれない。

宇宙兄弟(1) (モーニング KC)

宇宙兄弟(1) (モーニング KC)

ところで、最近、人材の採用について少し興味がでてきた。弟がちょうど就活ということもある。 採用という観点でいくつか気になったことを書いてみる。 さきほど、書かれている試験内容はそのまま参考にはならないと書いた。 しかし、労働環境が過度のストレス環境であることや様々な能力を平均的に高いレベルで要求されるという特殊な前提を省いてみると、特にNASAの面接方法について部分的に参考になることはいくつかあった。

まず、「なぜ今、ここにいるのか」という質問を通して、候補者の人生を知ろうとしていることだ。 なるべくリラックスした状況を作り、候補者のこれまでの人生経験を詳しく聞くことで、その人間が信用に値するのか、一緒に働きたいと思えるような人間かどうかを見極めようとしている。似たような話を読んだことがあるなと思ったら、だいぶ前に tomomii さんがいい記事を書いてた今週のお題:わたしとはてなとの出会い - tomomii日記。 今思えば、自分がはてなに入社するときの jkondo さんとの最終面接はこんな感じだったように思う。

次は、全ての試験が終わった後に行われるパーティで、候補者たちの「本当の姿」をみるという点だ。 面接では必ずしもいい状況で望めなかった候補者がいた可能性を考慮して、誤った判断を防ぐためだという。 少なくとも、自分の会社のエンジニアなら面接のような人に見られる類の緊張感がある状況で、何か仕事をするということはあまりない。ブログのほうが本当のことを書けるという人もいるかもしれない。面接でうまく話せなかったといって、仕事ができないということにはならないと思う。 これは前々からそう思っていたけど、NASAでもそのようなことを考慮しているのは意外だった。

最後に、JAXAとNASAでは試験内容が異なり、NASAではほぼ面接だけで採否が決まるというのも印象に残った。 NASAでは、技術的な専門知識やメカを操作する技量などの技術的バックグランドは、候補者の履歴書と、面接でのやりとりで十分見極められていると考えているらしい。 JAXAの場合、選抜試験で採用した人間は全員、宇宙飛行しなければならず、確実に宇宙に行ける人間を採用しなけらばならないため、採用試験が極めて厳密になる。これは、日本とアメリカの宇宙開発の規模、歴史、方針の違いによるものとのことだ。 本文中には詳しく書かれていなかったが、日本のほうが宇宙開発の歴史が浅いため採用経験も浅いかつ宇宙開発費も潤沢ではないため、厳密に試験する必要があるという意味ではないかと思った。 前提が違えば、試験内容も当然異なるということがよくわかる。

宇宙飛行士になりたいと思ったことは多分一度もないし、宇宙に行きたいという願望も特に無いけど、宇宙がでてくるSFの話は大好きなので、面白く読めた。 元となったテレビ番組の方も観てみたい。

2014年、技術しかしてない

2014年、振り返ってみてもとにかく技術しかしてない。

Webオペレーションエンジニアになった。

1人でサービスを構築・運用するようになった。

とうとう25歳になった。もう定年だ。

9月に引っ越した。自炊あきらめた。

ISUCON4の本戦で惨敗した。Cache-Controlとか知らんし。

ブログで承認ゲットした。

Dockerしてた。Dockerは最高。

数編の論文を読んた。

京都在住にしてはとにかくたくさん技術プレゼンした。東京で消耗してた。

新卒入社成功してから1年がたってた。

去年の目標みたいなのを振り返ってみる。 2013年をとにかく忘年したい - ゆううきブログ

  • プロとしてのエンジニアリングをやっていく
    • なにがプロだ。
  • ブログエントリばかり読んでないで、体系的にまとめられた書籍
    • 失敗。来年の目標にしよう。
  • OSS活動
  • DockerとかMesosとか使って何かしたり
    • Dockerで何かしてた。

2014年は職業としてのエンジニアになった年であり、エンジニアとしてのアウトプットを積極的にした年でもあった。 よい会社に入ったこともあって、充実していた。人間が1年を振り返れば、5月は5月病でやる気がなかったとか、10月は中退してずっとオンラインゲームしてたとかあると思う。今年はあまりやる気のない期間というものがなかった。1日もないといえば嘘だけど。 ずっと技術のことだけ考えておけばよかった。いつかそうも言ってられない時が来ると思って怯えてる。

来年どうするか。3つだけ考えていることがある。 まず、1年サービス運用してきて、課題がある程度みえてきたので、自作ツールで補えるところは補っていきたい。コードをあまり書けてなかったが、1年は運用技術の習得に集中しようという意識があった。集中できたかはどうか微妙だったかもしれない。 次に、計算機システムそのものについて、より深く理解したい。Dtrace の作者の方が書いてる Systems Performance: Enterprise and the Cloud という本がよさそうに思って、電子版を買って読んでる。 最後に、去年からのブームである Immutable Infrastructure 技術の導入について、Docker を支える技術と分散システムが柱になっていくと思っていて、分散システムー原理とパラダイム とかを読んで勉強したい。 Kubernetes や Consul とかツールを触ってるだけではきっと本質はわからない。

あとは、各社でサーバ運用してる同世代の若者と交流したい。この職種、若者が少ない。 年明けには、Docker meetup #4 での発表が控えてる。夏には最後のYAPCもある。どこかで連載するという話もある。 きっと、あと数年はこの延長線上を歩いてそう。その先になにがあるのかはわからない。

ブログの振り返り

去年は34本のエントリを書いた。合計ブクマ数は 1,590 users だった。年間PVは 65,070 views だった。

今年は28本をエントリを書いた。合計ブクマ数は 5,055 usersだった。年間PVは 172,878 views だった。 今年は、平均 180 users のエントリを書いたことになる。確かに今年の後半では、何か書けば絶対ホットエントリという感じで、ホットエントリ入りして感動する心を徐々に失っていって、残るのは部屋のベッドで丸まって、虚ろな目でリロードしまくる自分の姿だった。あの感動をもう一度取り戻したい。

今年のブクマ数ランキングを出してみた。100 users 以上のエントリだけ。

上位5位のうち、4つが論文を読んだ話になってる。全体的に Docker に関するエントリが多い。Docker はちょうど自分が好きな領域をまるごとカバーする技術だから好きなんだと思う。

あとは、Go がよい。余計なことを考えなくてよいようになっていて、やりたいことに集中できる。CやC++を書いてる気持ちで書くと最高だ。クロスコンパイルかつ依存なしワンバイナリで配布できるから、デプロイがしやすい。

順位 エントリ
1 位 インフラエンジニア向けシステム系論文
2 位 東京はもう古い、これからは京都
3 位 Dockerは速いのか?Dockerのパフォーマンスについて重要なことは何か?
4 位 Facebookの数千台規模のmemcached運用について
5 位 Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて
6 位 tmux + ssh + Mackerel API を組み合わせたとにかくモダンなサーバオペレーション
7 位 Perlはもう古い、これからはDocker
8 位 GoとMySQLを用いたジョブキューシステムを作るときに考えたこと
9 位 Go言語の便利情報
10 位 ISUCONでNginxとMySQLをDocker化したときのパフォーマンス
11 位 Go言語によるCLIツール開発とUNIX哲学について
12 位 Docker 使ってたらサーバがゴミ捨て場みたいになってた話 #immutableinfra
13 位 Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション

発表振り返り

今年は合計8回発表した。

Immutable Infrastructure Conference #1

やたらとウケた。もう人生であんなにウケることはきっとないと思う。最初からネタに振ってたけど、いま見ると意外と有用なことを言っていた。rebuild.fm で言及されて勝ち組と言われた。

JVM Operation Casual Talks

知見ないのになぜか話すことになってた。かんべんしてくれ。

第3回 コンテナ型仮想化の情報交換会@大阪

発表が立て込んでて、ちょっと雑になってしまって申し訳なかったかもしれない。 Docker の CHANGELOG を見ましょうという話をした気がする。

可視化ツール現状確認会

Mackerelの話をした。会場は、VOYAGE GROUP の AJITO で社内にあんなバーがあるのはどう考えてもおかしい。これが東京か〜と思って見てた。

Monitoring Casual Talks #6

全員発表型のクローズド?勉強会。質問とか議論が活発で情報交換という意味ではこういうスタイルの勉強会がよいなと思った。 ヘビーなGraphite運用について - ゆううきブログ

Hosting Casual Talks #1

会場スポンサードLTとかいって勝手にしゃべった。内容はこれ。tmux + ssh + Mackerel API を組み合わせたとにかくモダンなサーバオペレーション - ゆううきブログ。 この時はいろいろな方と話せたけど、特に @matsumotory さんとお会いできたのが良かった。目上に対する敬意がないと言われる自分でも尊敬できる人がいるのはいいことだと思う。

第5回 コンテナ型仮想化の情報交換会@大阪

ISUCON アプリを Docker 化した話をした。ブログ書いたら、某社とか某社で話題になってたらしい。ISUCONでNginxとMySQLをDocker化したときのパフォーマンス - ゆううきブログ

Hatena Engineer Seminar #3 @ Tokyo

オンプレミスとクラウド、そして Docker という話をした。 発表した後の懇親会とかそのあと2次回で、いろいろ話ができた。いつもは、誰々がどこに転職したとか疲れてるとかそういう東京ローカル事情みたいな話題が多くて、だいたいついていけない。

今年は、YAPC::Asia のような大規模カンファレンスでの発表はなかった。東京へ行く度に結構疲れてしまった反省をこめて、来年はピンポイントで興味のあるカンファレンスや勉強会で発表したい。

今年もお世話になりました。来年もよろしくおねがいします。

インフラエンジニア向けシステム系論文

この記事ははてなエンジニアアドベントカレンダー2014の23日目とシステム系論文紹介 Advent Calendar 2014の23日目を兼ねています。

今回は、インフラエンジニア向けにシステム系論文を読むということについて書きます。 ここでいうインフラエンジニアは、Webサービスを作る会社のサーバ・ネットワーク基盤を構築・運用するエンジニアを指しており、はてなではWebオペレーションエンジニアと呼んでいます。 人が足りなくて普通に困っているので採用にご興味のある方はぜひこちらまで。 Webオペレーションエンジニア職 - 株式会社はてな

はてなでは、id:tarao さんを中心に有志で論文輪読会を定期的に開催しており、システム系論文にかぎらず、言語処理系、機械学習についての論文などが読まれています。 だいたい1人でインフラまわりの論文を読んでいて、インフラエンジニア向けの論文知見が溜まってきたので、紹介したいと思います。 大学院にいたころ、研究そのものはそれなりに好きだったが、大学とか研究室はあまり好きではなかったので、そういう人間がなんか雑に書いてるぐらいのイメージです。

システム系論文とは

「システム系論文」という呼称は PFI さんで開催されている システム系論文輪読会 から拝借しました。 「システム系論文」という呼称は正式なものではなくて、なにがシステム系なのかを一言で表現するのは難しいですが、コンピュータシステムそのものについて論じていればシステム系なのかなと勝手に思っています。 具体的には、計算機アーキテクチャ、オペレーティングシステム、分散システム、ストレージなどトピックは多岐に渡ります。 このあたりの特に実践的な分野はあまり論文中に数式がでてこないので、普段からある程度の規模のシステムを運用されてる方なら比較的論文を読むための素養みたいなものが身についているような気がします。(分散システムのアルゴリズムなんかはタネンバウム本とかを読んで基礎知識を固めておかないと読むのは難しいという勝手なイメージ。http://home.att.ne.jp/sigma/satoh/diary/diary100331.html#20100102 )

論文を読むメリット

書籍として出版されていないが、内容が深いかつ新しい技術知見を得たいときに、論文を読むのがよいと思っています。

とりあえず、適当な国際会議の論文タイトルと抄録を見てみましょう。例えば、ストレージまわりに興味があれば、FASTのセッション一覧( https://www.usenix.org/conference/fast13/technical-sessions )から興味がありそうな論文を見つけられれば、それでもう読む価値があるといえると思います。 僕の場合は、A Study of Linux File System Evolution | USENIXffsck: The Fast File System Checker | USENIX などが気になりました。

論文、当然英語で書かれていて、とにかくとっかかりにくい印象がありますが、短く内容がまとまっていて短期間で読みきれるのがよいと思っています。 分厚い英語の技術書を買って、読みきれなくて失敗するということは結構あると思いますが、情報系の国際会議の論文なら2カラム構成だけど、数ページから10数ページぐらいでなんとか読めます。 あとは、少なくとも情報系の場合、無料で公開されている論文も多いので、金銭的なデメリットがないというのもあります。

http://d.hatena.ne.jp/mamoruk/20100604/p1 情報系は他の分野と異なり少々特殊で、英語論文といっても国際会議に投稿された論文と、ジャーナルとか論文誌とかいう雑誌に投稿された論文とあり、基本的には後者のほうがランクのクオリティも高く、分量も多いのだが、国際会議の論文もジャーナルの論文と同じくらい重視される点が違う(ほとんどの分野では国際会議の論文は全く評価されない。逆に海外に遊びに行っていると思われてマイナス評価になることさえあるそうで)。かといって、じゃあジャーナルを読んだ方がいいのかというと、国際会議の論文のほうがページ数も決まっていて短いし、基本的なアイデアは国際会議の論文に書かれているので、自分は最初のうちは国際会議の論文を大量に次から次に読み、俯瞰的にテーマを見渡す力をつけたほうがいいんじゃないか、と思う。

過去に読んだ論文

自分のブログに書いているもの限定ですが、過去に自分が読んだ論文を紹介します。 トピックに一貫性がないですが、研究と違って仕事だと幅広いトピックを扱うので、そのときどきに興味があるやつを読んでたりします。

論文の探し方

論文を読もうとしても、そもそもどうやって探すのかという問題があります。 僕の場合、ランクが高いと言われているジャーナル/国際会議のうち、年度が新しいものから順に眺めていって、興味がありそうなやつをリストアップしてメモしておいて、読む気になったら読むことにしています。あとはブログをあさってると、まれに何かの論文に行き着くことがあったりするので、そういうのもストックしておきます。

興味のあるキーワードや著者がはっきりしている場合は、Microsoft Academic SearchGoogle Scholar で検索するとよいと思います。

ジャーナル/国際会議と言っても、どこがよいかとか最初はわからなくて調べたので、ランクが高いと言われているシステム系の国際会議を列挙します。 各国際会議の Best Paper Award を受賞した論文などはさすがにどれも興味深そうです。 多分、このブログを普段読んでいただいている方には LISA あたりが一番ピンとくる論文が多いのではないかと思います。

情報系国際会議の Best paper賞を受賞した論文まとめページもあるので、ここから探してもよいと思います。

Best paper awards at AAAI, ACL, CHI, CIKM, CVPR, FOCS, FSE, ICCV, ICML, ICSE, IJCAI, INFOCOM, KDD, MOBICOM, NSDI, OSDI, PLDI, PODS, S&P, SIGCOMM, SIGIR, SIGMETRICS, SIGMOD, SODA, SOSP, STOC, UIST, VLDB, WWW

あとは、Google, Facebook, Twitterなどの各社が論文を投稿してるので、これもみてみるとよさそうです。

そのほかについては、情報系の国際会議・ジャーナルのランキング - ny23の日記 が参考になります。

論文の読み方

USENIX系のカンファレンスだと、プレゼン時のスライドが公開されていたりするので、それをみてイメージをつかむとよさそうです。

論文の文章構成はだいたい決まっていて、Abstraction、Introduction、Proposed Methods, Experiments, Discussion, Conclusion の順になっています。 ありきたりですが、最初に、Abstraction 、Introduction、Conclusion を読んで概要を掴んでから、Proposed Methods, Experiments, Discussion を読むようにしています。

漫然と読んでも内容が頭に入らないので、各段落の要約みたいなものを英語と日本語ごちゃまぜでいいからエディタに書いています。単語の訳とか考えてたら日が暮れるので、英語のままシュッとコピペします。論文はだいたいPDFで手に入るので、コピペが簡単ですね。 油断すると、1文1文を作業的に訳しかねないので、段落あたりの内容をコンパクトにまとめることを意識しています。段落あたりでもかなり粒度が細かいですが、日本語ではないという点と技術的な内容という点で、あたまに入りづらいので、これくらいの粒度が妥当かなと思っています。

発表前提でスライドを作る場合も、いきなり原文を読みながらスライドを作らずに、まずメモを書きながら一通り読んでしまってから、軽く構成を考えて重要ポイントだけスライドにしたりします。

最後に重要な点として、先にこの論文を読んで何を理解したいのかを言語化しておくと、常に問いを意識できるので、読まなくてもよい部分を無視して読み進めることができます。逆に言語化できないような論文を読むと、なんとなく読んだ気分に陥りがちな気がしています。 以前に、An Updated Performance Comparison of Virtual Machines and Linux Containers という論文を読んだ時は、Docker は速いのか?Dockerのパフォーマンスにとって重要なことはなにか? という問いを意識して読みました (これはそのままブログのタイトルにしました)。

id:shiba_yu36 さんがこれに近い内容の記事を書いていますのでご参考までに。 先に疑問を考えてから本を読む - $shibayu36->blog;

論文読みの続け方

僕の場合、承認欲求が満たされないと続かないので、読んだ論文についてブログに書いて、はてなブックマークで承認を得られるような形でアウトプットすることを一応目標にしています。 ブログに書くときのポイントとして、論文の内容そのものをまとめる必要はなくて、なるべく自分の立場や経験や興味を踏まえて、ある程度噛み砕いた内容にして自分の考察を書くとより読まれやすいように感じています。 どうでもいい小手先のテクニックとして、論文タイトルをそのまま記事のタイトルにするのではなく、キャッチーな単語を抜いてきて、普通のブログのタイトルっぽくするのがよいと思います。論文のタイトルそのままで当然英語なのでなかなかリンクを踏まれない気がします。

あとは、社内で輪読会とかやってないと絶対読んでないので、輪読会に参加/開催などするとよいと思います。

読んでおきたいシステム系論文

とりあえず、最近気になってるおもしろ論文を列挙します。 絶対読みきれないので、助けてください。

まとめ

インフラエンジニア向けに、読むと知見が得られるような論文の探し方やおすすめの論文などを紹介しました。 論文、最新技術の知見の宝庫なので、一度漁ってみてはいかがでしょうか。 また、識者の皆様に、よりよいシステム系論文についての知見などありましたら教えていただけると嬉しく思います。

最終日の担当は id:stanaka さんです。よろしくお願いします!