Google Open Source Peer Bonus Award受賞

2023年08月01日火曜日

【この記事を書いた人】
田崎創

2016 年より IIJ 技術研究所にて勤務。

「Google Open Source Peer Bonus Award受賞」のイメージ

Linux Kernel Library (LKL) への貢献が認められ、Google Open Source Peer Bonus Award というものを受賞しました。

https://opensource.googleblog.com/2023/05/google-open-source-peer-bonus-program-announces-first-group-of-winners-2023.html

この賞は特定のオープンソースへの貢献が認められたものへ、Google 社員の推薦により授与されるもので、2012年あたりより実施されているようです。LKL の開発者は現在 Google の社員なので、なかば内輪よりの推薦という意味では少し弱いものかとも思われますが、どんな形にせよ活動が誰かに役立っていたという事を確認するのはとてもうれしい事でした。

この機会に便乗して、僕個人と LKL の関わりをこれまでの活動を振りかえる形で書きだしてみようと思います。Linux カーネルへの取り込みというゴールにはまだ辿りついていない、この道半ばで振り返るのは早計ではありますが。。

LKL とは

Linux カーネルのソースコードを利用して再利用可能なライブラリを生成し、モノリシックカーネルとしての用途以外にそのプログラムを利用するものです。以前弊社のセミナーで発表した資料などがありますので、参考までに。

このオープンソースプロジェクトとの関わりが始まったのは、2015 年ころでした。LKML (Linuxカーネル開発者メイリングリスト)へ、Octavian Purdila氏(当時 Intel)が LKL パッチを投稿*1した事から始まりました。Octavian 氏とは以前から面識があり、当時僕は Linux libOS*2 という似たオープンソースプロジェクトで開発していました。この libOS は、以前に ns-3 というネットワークシミュレータにて、Linux の IPv4/v6 スタックを利用するという研究*3にて開発したものを、拡大解釈して任意のユーザ空間プログラムで利用可能にするというものでした。

この当時何がしたかったかと言うと、長年の開発によって成熟した Linux カーネルの機能を再実装して互換を目指したり、性能向上のみを目的としてカーネルを迂回(カーネルバイパス)する技術を使用した時に、迂回した実装物をまた 0 から作りなおそうとしたりしている技術があまりに多く、そんな事する必要はないよ、という事を言いたかったというのが大きくありました。Linux 互換と呼ばれるものは世の中に沢山ありますが、そんなに簡単に互換性はとれるものではありません。ローマは1日にして成らず、と*4。

そんな動機が共通だった事もあり、僕は libOS をやめて LKL の開発に合流して一緒に活動していく事にしました。

Linux カーネルのソースコード再利用のモチベーション

ここに至るまでの経緯は、新卒で働いていた会社時代に遡る事になるのですが、備忘として記述してみようと思います。

2005-: エンジニア時代

当時僕はあるソフトウェア製品(今風に言うとミドルボックスソフトウェア)の Layer-3 まわりのプログラムの開発、検証を担当していました。カーネルが管理するアドレスや経路情報を、シグナルプロトコルをしゃべるプログラムで読み書きするようなプログラムの開発・保守をしておりました。

このプログラムの検証過程として、大規模環境での動作検証というものがありました。OSPF の neighbor 数 100 台を単一エリアで動作させるとか、RIP でフラグメントするパケットが必要そうな大量情報を受信させる、とか。こういった検証環境を準備するのに、模擬プログラムを書く事もありましたが、仮想マシン (VM) を使って大量ノードを生成した上で動作させるといったテストが主流でした。テスト専用プログラムは効率的に実装の中心となるアイデアの検証には役立つものですが、その検証をパスしたからといって対象とする大規模環境においてバグがないとは限らない事などがあまり有用ではなかった理由でした。つまり、模擬プログラムは、DUT (実験対象)の特定部分の負荷をかける事は可能ですが、その他の機能もその負荷環境下で合わせて検証できないと、検証としての効果が少なくなってしまうためです。
(Ixia や Agilent などの機器の導入も検討していましたが高価であるためなかなか占有して利用する事ができず、あまり利用しませんでした)。

この当時は、この不満に対してこれといった対策もとれなかった記憶があります。我慢して大量 VM の環境で検証をしていました。

2008-2011: 博士学生時代

その後、仕事としてプログラムを書く機会が減った事に不満を抱いた僕は会社を離れ、博士課程の学生になる事になりました。小さい頃から、電器屋の店員になる事をおぼろげに目指していた僕が、なぜここまでコンピュータやプログラムに心奪われていったのかはあまり記憶がありませんが、単に面白かったのだと思います。

大学院では、無線ネットワークを自由気ままに構成し、ネットワーク管理者がいない環境でも誰かのインターネット接続を間借りする事で、様々なノードへ到達性を提供するという技術を研究開発していました (Fon というのがありましたね)。無線アドホックネットワークと呼ばれる分野の研究です。
研究の現場では、それまでいた開発の現場以上に論理のみの検証、研究のコアとなる新しいアイデアの検証「のみ」にフォーカスした実験が行われていました。無線ネットワークの研究では、伝統的にシミュレータと呼ばれる、こういったアイデア検証やそこで検証したプログラムが生成するデータの可視化や分析が得意なツールが利用されていました。当時は ns-2 と呼ばれるネットワークシミュレータを利用した研究が大量になされていて、ここでも天邪鬼な僕は、こういったテストでしか利用しないプログラムで検証したアイデアが、本当に有用なのかという疑問を持ちはじめ、到底価値など存在しないと決めつけていました。。他の大先生も同じ事を考えていそうなのを見つけたりしては*5、自己肯定していたと思います。典型的な天邪鬼のやり口ですね。

http://ccr.sigcomm.org/online/files/p45-v38n1k-crowcroftA.pdf

Jon Crowcroft, Cold topics in networking, ACM SIGCOMM CCR, January 2008. (*5)

2010-2013: ns-3 と Direct Code Execution (DCE)

こういったタイミングで出会ったのが、当時フランスの INRIA という研究所で働いていた、Mathieu Lacage 氏です。Lacage 氏は、前述した ns-2 プログラムを改善しようという研究テーマで博士論文を書こうとしており、ns-3 というオープンソースプロジェクトを現場でリードしていた方でした。この ns-3 の中で、POSIX socket で書かれた既存のプログラムを修正なしに利用する事ができる機能、Direct Code Execution (DCE)を実装しはじめている所でした。年齢も学歴も近しく親近感を持ったという事もあり、僕は彼が活動していた ns-3 のオープンソースプロジェクトのメイリングリストに改造コードを投稿し、zebra (ルーティングデーモン群が実装されているプログラム)を ns-3 で動作させられるようにしたり、また彼の参加している学会を見つけて発表原稿を準備したり、そんな事を博士課程2年目くらいの時はしていました。
私の研究は、Mobile IPv6/NEMO で利用する IPIP トンネルを、アドホックネットワークの環境で頻繁に追加削除するような技術の提案をしていたので、トンネル作成削除のオーバヘッドを知る事はアイデアの検証には大部分をしめているものでした。さらに、Linux カーネルと NetBSD カーネル以外に、当時は NEMO の「まともな」実装は存在しておらず、これらを ns-3 シミュレータ用にゼロから実装したところで、現存する IP(v4/v6)ネットワークやNEMO実装の互換をくまなく検証する事はほぼ不可能だと思っていました (無限に小人が生成でき、実装にかかるコストがほぼゼロであれば、可能だったのかもしれませんが、悲しい事に僕はそんなハッカーではありませんでした)。Mathieu の実装していた DCE は、そんな僕の不満を根本から解決する、スーパーハッカーのなせる技の集合でした。

2013-2015: NUSE開発開始

DCE の研究開発も終え、博士課程も卒業した僕は、この DCE の可能性をもっと引き出せる事ができないか？という興味を持ちはじめていました。そんな中見つけたのが、NetBSD に実装されていた rump kernel という機能でした*6。この機能は、フィンランド人の Antti Kantee 氏が中心になって実装していて、既に NetBSD カーネルに取り込まれているという機能でした。

rump カーネルのできる事は、NetBSD カーネルのソースコードを「そのまま」利用して、ユーザ空間プログラムができる共有ライブラリを生成したり、マイクロカーネルサーバの実装として利用したり、unikernel と呼ばれる単一メモリアドレス空間を持つプログラムを生成したりできるものでした。これは、Antti 氏の博士論文*7内でも触れられている、Anykernel と呼ばれるカーネルの実装でした。元々モノリシックカーネルである NetBSD カーネルのコードの、長年蓄積された資産を損う事なく、別形態で利用可能とするものでした。

まさに、これ ! という感じでした。ns-3 で Mathieu がやろうとしていた事は、もう少し抽象化して考えたらば、この Antti が考えていた事に包含される、というのを発見した気持ちでいました。今度は、rumpkernel の IRC チャネルを探し、Linux カーネルでの rump kernel 的なものの実装について、相談していました。カーネルの開発者の数も多かった Linux カーネルはそれだけ機能の数も多く、NetBSD でのメリットは Linux でも大きなメリットになるであろうと考えていました。

こうして、NUSE (Network in UserSpacE) と名付けた Linux カーネル版の rump kernel を見せびらかしに行くために、ロンドンでの MeetUp operatingsystems.io (osio) *8に参加しました。このイベントは Antti と一緒に rump kernel の開発をしていた、Justin Cormack 氏 (現 Docker 社 CTO)の主催のもと、当時変わった事を OS という形で実装していた人達が沢山発表をしていたイベントでした。MirageOS の Anil Madhavapeddy 氏や、K言語の実装などなど、東京で Kernel/VM という会がありますが、まさに似たような雰囲気(もっとシャレオツでしたが)でした。

2015: Linux netdev conference 0.1

こういったイベントでの発表をモチベーションとして、NUSE の実装を進めて Linux のカーネルパッチという形で LKML に投稿し、そのお披露目として Linux netdev conference 0.1 オタワで発表しました。その発表があったためか、Linuxカーネルの旧くからある広報誌 lwn.net (Linux Weekly News)に紹介記事*2が掲載されました。その他、Phoronix*9, Linux magazine*10, などなど、様々な所で注目して頂きました。

LKML での投稿も反応も良かったので、すんなり upstream されるかと思っていましたが、そこは老舗オープンソースコミュニティの Linux で、しっかり反論も頂きました。Linuxカーネルには、libOS や LKL ととても似た、User Mode Linux (UML)という機能が 2000 年代初頭から存在していました。実装は大分古く中には現代で書きなおす事もできる機能もありましたが、古くからあるという事は利用者も存在していて、彼らの存在を無視した機能追加は、安易にはしない雰囲気がありました(同等の機能を複数保守する考えはなるべく排除しようとしたいですし)。libOS パッチは、前述したように後に LKL パッチに引き継がれますが、LKML 全体として、また arch メンテナ (LKL も libOS も arch/lkl or arch/lib という場所で提案されていました)の意見としても、UML との共通部品を整理するところから始めるようにという提案もあったりして、提案そのままの形で upstream されるという選択肢は当時はなくなりました。

2018-2021: µKontainer、コンテナカーネルとしての LKL

LKL の upstream 活動と平行して、このライブラリを他の形でも利用できる事を見せたいと思いました。その一つが、µKontainer と呼ばれるもので、 LKL を unikernel プログラムとして作成し、コンテナのランタイムと併わせて利用するものを研究開発しました*4*11。

Docker で市民権と沢山のユーザを得たコンテナ技術は、自然な流れとしてその仕組みの改善がなされていました。ソフトウェアによる隔離 (isolation)を改善するため、仮想マシンを軽量化しコンテナと同等の速度や多重化された環境で利用可能にするものや(firecracker、kata containers)、Linux カーネルのエミュレーションを実装する事で、コンテナが動作しているカーネルへの攻撃による障害が、他コンテナへ波及しないようなサンドボックスを実装するものなど (gVisor, Graphene, Nabla container)。これらのゴールの一つに、既に大量に生成されているコンテナイメージをそのまま利用可能にするというものがありました。VM であれば Linux がほぼそのまま動作するのでコンテナイメージは再利用可能ですが、エミュレータを元にしたものはその Linux カーネルの互換性が問題となっていました。

ここで、このエミュレータを再実装するのではなくて、再利用可能な Linux カーネルを使用したエミュレータを作りたい、というのは僕にとっては自然な思考でした。この方式のコンテナを、既存 docker や k8s などの環境でも利用可能にしたものを実装しました。

Linux カーネルへの upstream 活動

Linux upstream カーネルへの提案活動は、2023年現在も継続していて、UML への提案の一方別路線も検討したりしていますが、目立った進展はここ数年出せていないというのが現状です。このupstream活動については、また別の機会に書き出してみようと思います。

最後に

仮想マシンを使えば、既存プログラムを再利用しながら高速化やカーネルの拡張といった事も可能だとは思うのですが、僕はこの VM があまり好きじゃなかったというのも、これらの活動の起点になっていたと思います。前述の VM による大規模検証・実験は困難を極めていて、また namespace を利用したコンテナに浮気していた事もありましたが、こちらもノード数の制約を VM 利用時より大幅に改善するといった事は、(少なくとも)当時はできませんでした。

そもそも、多重化したかったのは IP スタックとその別インスタンスで動くプログラムだけだったので、OS 全体を複数並べるという形に、無駄を感じていたのでした。

あと、初めての VM 体験も良くなかったと思ってます。僕が初めて VM に触れたのは、大学院時代の研究室で(2000年ちょうどくらいです、年がバレますね)、当時使用していた私物マシン ThinkPad 560 に VMware workstation ? を入れ Windows を動かした事でした。まさしくスローモーションで動く Windows を見て、面倒なマルチブート環境を作る事なく別 OS を動かせるといった世界観に感動したのと同時に、このレベルの応答性だと生活で使用するのは難しいと思ったのを覚えています。その後の僕の計算機とのお付き合いにおいて、VM を使うのは最終手段というのが刷りこまれたのが、この時期だったのかと思います。
VM はその後進化し続け、若者がこのようなトラウマを生むような事は無くなったと思いますが、僕のここまでの疑似 Linux へのモチベーションを説明するには、この出来事が大きく関係していると思います。

この文章では僕のライブラリ化されたカーネルとの関わりについて、やや脱線しながらおおまかに振り返ってみましたが、こういう私的な体験がもとになって、研究のネタがつくられていく事もあるという事をお伝えできればと思います。かなり偏った経験なので参考になるとは思いませんが、そういう文章だとご理解頂ければ幸いです。