Open Source Summit Japan 2017というオープンソースソフトウェアに関する様々なセッションを聞くというイベントに昨日まで三日間参加してきました。内容を覚えてるうちにメモしておこうと思います。

Open Source Summit Japan 2017 | Open Source Summit Japan 2017 | Linux Conferences and Linux Events | The Linux Foundation

このイベントについて全然知らない人のために補足しておくと、世界中から様々な人が集まってくる全編英語の国際イベントです。参加人数はぱっと見、千人前後でしょうか。今年はとくにたくさんの人が参加したようです。かつてはLinux Con Japanという名前でlinuxカーネルを中心としたlinuxの話が主だったのですが、最近は他のOSSのセッションが増えてきてlinux色が薄まってきたからなのか、今年から改名したようです。

セッションそのもの以外でも、ここ数年は学生さんが多く参加しており*1、別の学生達や職業エンジニアの知り合いを作ったりという、同好の士を繋ぐハブとしての役割も果たしているように見えます。私も今年10人程度の学生さんを含むエンジニアと新たに知り合い、かつ、SNS上でしか知らなかった方々と初対面を果たせました。

ここからは今回とくに印象に残った二つのセッションについて紹介します。主にわたしが個人的に気になった部分の簡単な紹介や、それについて私がどう思ったか、どういう質疑があったのかということを書きます。詳しい内容は既にアップロードされている(かつこのエントリにリンクを張っている)セッションのスライドに書いているので、そちらを見ていただければと思います。

Noah: Hypervisor-Based Darwin Subsystem for Linux - Takaya Saeki & Yuichi Nishiwaki, The University of Tokyo

sched.co

スライドはこちら。

LinuxのバイナリをmacOSの上で動かすという話です。「*BSDにもWindowsにもLinuxバイナリを動かす方法があるのにmacOSには無い、作っちゃえ!」という面白い動機によって開発されたようです。ネタがネタだけに会場には馴染みのあるカーネル野郎達がウジャウジャいました。類は友を呼ぶというやつでしょうか。

実現方法はおおよそ次の通りです。

  1. 1つのlinuxバイナリを動かすごとに1つのVMを立ち上げてそこにバイナリをロードする。および、後述のNoahプロセスというプロセスを立ち上げる
  2. linuxバイナリから作ったプロセスが発行するシステムコールはハイパーバイザがすべてトラップする
  3. システムコールの依頼内容をハイパーバイザがNoahプロセスに転送
  4. Noahプロセスがシステムコールをエミュレーションして結果をLinuxバイナリから作ったプロセスに返す(ちょうど普通のハイパーバイザがguestのかわりにハード処理をするようなイメージ)

Noahプロセス自身は単なるユーザプロセスなので、エミューレーション用コードにバグがあっても*BSDやWIndowsによる他の実現方法のようにカーネルパニックが発生しないという特長があります。他にもmacOSのプロセスとLinuxバイナリから作られたプロセスがパイプやシグナルで通信できるという特長もあるようです。すごい。

話を聞いていると確かに技術的に言ってることは理解できるのですが、そのアイデアを実装して形にしてしまう行動力、および、あまたあるシステムコールのエミュレーションコードを書いて実装を完成させて動くところまでもっていくという実装力に感心しきりでした。

他にも質疑が面白かったのも特徴的でした。この手のネタはエンジニアにとってはどれだけの種類のLinuxバイナリが動くのか、つまりどこまでの範囲Linuxをエミュレーションできているのかという興味が尽きないのですが、「コンテナは動かしたことあるか」「procfsはどうなっているのか」という質問に対して彼らはことごとく「Please send PR」というカウンターパンチを使って見事切り抜けていました。発表中にとっさにこういうウィットに富んだことが言えるのもポイントが高いです。

余談ですが、発表されたおふたりはNoahで未踏スーパークリエイター認定を受けた方々だそうです。すごい人もいるもんですね。

www.ipa.go.jp

WalB: Real-time and Incremental Backup System for Block Devices - Kota Uchida, Cybozu, Inc.

sched.co

スライドはこちら。

サイボウズ社が運用しているシステムにおけるバックアップの課題と、それを解決したWalBというバックアップシステムの紹介です。サイボウズはグループウェア日本最大手であり*2、この規模の会社が使っているシステムの内部を数値込みで見られることはなかなか無いので、貴重な機会でした。

サイボウズのシステムでは一日一回のインクリメンタルバックアップが要件になっているそうです。dm-snapやdm-thinなどを用いたバックアップシステムでは(既存システムはdm-snapを用いたもの)、一日ごとにスナップショットを採取して、最新のものから数えて2つのスナップショットをスキャンすることによってバックアップ用の差分をデータを作る必要があります。これらの方法ではこのスキャン処理にかかる時間が長いのがネックなのだとか。

その一方でWalBは、管理対象とするブロックデバイスに対する書き込みのログ(デバイス内のどこに何を書き込んだかという情報)をログデバイスと呼ばれるデバイスに別途書き込んでおいて、このログがほぼそのままインクリメンタルバックアップ用の差分データになるという仕組みだそうです。この方法だと書き込み処理ごとに定常的にログデバイスに対する書き込みが発生しますが、スナップショットベースのバックアップシステムのような、一日一回バックアップ時に発生する大きなI/O負荷(スキャン処理)は無くなります。うまく考えたものです。

今回はバックアップを採取する側の話が中心でしたが、今後はリストアを含めた運用全体に関する話がどこかで聞けたらいいなあと思いました。

このセッションについては、技術的な面白さだけではなく、ハードを売っているわけでないソフトウェア専業の会社がlinuxのデバイスドライバ(WalBのブロックデバイスを実現する部分)を書いて、バックアップシステムを自作して、かつ、それを実運用していることにも感銘を受けました。最近ではFacebookがlinuxカーネルチームを抱えているなど、海外企業ではそのような事例はいくつも聞いたことがありますが、日本でもこういうことをしている会社があるのは知らなかったです。

なお、このプレゼンは再演予定もあるそうなので、興味のある人は行ってみるといいかもしれません。

atnd.org

*1:まだ学生でなく生徒と呼ばれる年齢のかたもいらっしゃいます。すごい

*2:このエントリを読んでくれるようなエンジニアの人にとっては、最近話題になった、32GBメモリのマシンを全員に支給してくれる羨ましい会社としてのほうが有名かも