低レイヤの知識の重要性は今後も変わらない - 小崎資広に聞くLinuxカーネル開発の裏側

―小崎さんがプログラミングのスキルを向上させたのは、新卒入社された企業の経験が大きく影響しているそうですね。

小崎　そうなんです。私は1999年に大学を卒業した後にパナソニックの子会社を就職先として選んだのですが、最初に経験した案件がなかなかのデスマーチでした（笑）。

当時はテレビがアナログからデジタルに切り替わる過渡期で、まずBS放送が切り替わり、1～2年後にCS放送が切り替わり、その後に地上波放送が切り替わり、という時期です。家電業界はひたすらその対応に追われていて、とにかくエンジニアが足りない状況です。私の場合は研修を完全にスキップして、入社後すぐに現場に配属されました。

―おおお……。かなり大変な環境からのスタートだったのですね。

小崎　それに加えて、ちょうど家電の作り方そのものも変化している時期だったんです。昔ながらのファームウェアっぽい世界から、リモコンのボタンを押すとインタラクティブにコンテンツがおりてくるとか、モデムが付いていてインターネットにつながるとか、OSやプロトコルスタックなどが必要な世界に変化しつつありました。

BSデジタル放送においても、日本がそれまで用いていたMPEGベースの方式ではなく、アメリカに追随してXMLベースの方式に切り替えることになりました。ですが、XMLベースの放送規格は当初存在すらしておらず、自分たちでゼロから作るほかありません。放送規格のドキュメントを作成しながら、プログラムを実装するという日々が続きました。これだけ過酷な環境からのスタートですから、自然とレベルはアップしますよね。

―画面のレンダリングには何の技術を用いていたのですか？

小崎　XHTMLをベースにして改良したものを使っていました。ブラウザまわりの技術を身につける必要がありましたから、配属から最初の2週間で、World Wide Web Consortium（W3C）のブラウザ関係の規格書を全部読みましたね。

それに、私が入社したのは1999年だったのですが、当時ははちょうどNetscape社がブラウザのソースコードを公開したくらいの時期です。「なんだ、良いサンプルがあるじゃん。参考にしよう」と思って見に行ったら、超巨大ソースコードがそこには広がっていて（笑）。大変でしたが、ひたすら読みまくりましたね。

社内にもともといたメンバーも新しい放送規格のことはわかりませんから、いつの間にか新卒で入ったはずの自分が一番詳しいという状況になりました（笑）。

Linuxの“土地勘”をどう身につけるか？

―Linuxの知識を身につけるうえで、転機となったプロジェクトはありますか？

小崎　入社3～4年目くらいの頃に、パナソニック社のテレビがインターネット対応端末になり、それをきっかけにOSを独自OSからLinuxへと移行することになりました。ですが、もともと独自OSのカーネルを書いていたチームなので、Linuxカーネルについて詳しくはない。となると、誰かに質問しても答えは返ってきません。自分でLinuxカーネルの膨大なソースコードを読むしかないわけです。

―当時はどのようにして、Linuxカーネルのソースコードを効果的に解読されていましたか？

小崎　組み込みの開発がキャリアの出発点だったのは、すごく幸運でした。組み込みでは多くの場合、もともと機器にシリアルで接続してリモートデバッグする文化なので、ちょっと工夫すればカーネルでもGNUデバッガで普通に接続し、アプリケーションと同様にデバッグすることが可能です。

―つまり、デバッグで1行ずつ処理を追うことができると。

小崎　そういうことです。そして、問題のある処理をGNUデバッガで止める作業を何度もくり返していると、「よく出てくるファイルは種類が限られている」と気づきます。徐々に「そういったファイルのソースコードを全て読んでおいた方が得だ」と分かってくるわけです。

―それを続けることで、いわばLinuxの土地勘を身につけていったわけですね。

小崎　他にも、カーネルのタイマ・ハンドラでインストラクションポインタレジスタを覚えるだけの超簡易プロファイラを書いて、どの処理が遅いかを洗い出してみたり。メモリ破壊バグを検知するために、ツールを自作してみたり。当時はそうやって、Linuxカーネルの仕様を学んでいきました。

―現職の若手エンジニアには、どのような方法でLinuxの土地勘を手に入れることをおすすめしますか？

小崎　私が普段、自社でカーネル開発に携わる方々に言っていることは2つあります。

まずは、CPUスケジューラやメモリ管理の中心部のような、いわゆる情報系の学部のOSの授業で習うような処理のソースコードを最初に読むこと。理論がすでに頭に入っていて、馴染みがある処理なので読みやすいです。

もう1つは、Linuxにはprocファイルシステムというものがあり、さまざまなチューニングパラメーターがそこにぶら下がっています。パラメーターの名前でソースコードをgrepすると、パラメーターをいじった際の挙動がどこで実装されているのかすぐわかります。そういった箇所を起点に見ていくと、解読がしやすいです。

VMの性能改善に、多大なる貢献

―その後2005年に、小崎さんは富士通へと転職されます。

小崎　その頃、富士通がLinuxカーネルの開発者を集めていたんです。アップストリームへのコントリビューションを始めたのも、富士通への転職後でした。当時、富士通はRed Hatとの業務提携を開始したのですが、Red Hatは「自社ではLinuxカーネルのバグ修正を行わない。誰かがupstreamにコード修正を投げてマージされたら、バックポートして自社の製品に組み込む」というポリシーでした。

不具合が原因でお客さまが困っているケースもありますから、富士通としてはなるべく早くバグを潰したい。となると、自分でコードを修正するのが一番早いわけです。それを機に、バグ修正や性能改善などを行ってアップストリームにあげていくようになりました。

―小崎さんは2000年代後半から、VMの性能改善に大きな貢献をされたことでも有名ですが、それは何をきっかけに？

小崎　カーネルを取り扱える人が意外と少ないので、コミュニティで普通のことが普通にできていると、それだけで目立ってしまうものなんです（笑）。それで当時Red HatにいたRik van Riel{$annotation_1}という有名なメモリ管理開発者から「一緒に新しいVMを作ろう」と誘われたのがきっかけでした。これは自分にとっても新しい挑戦だなと思い、いっしょにやることにしたんです。これがのちにRed Hatに出向にもつながっていったんです。

―以前のVMと改善後のVMは、設計のどのような点が違っていたのですか？

小崎　古いVMの課題はふたつありました。ひとつはメモリのスケーラビリティに課題があり、メモリが一定量以上になった場合に処理が遅くなってしまっていたこと。もうひとつは、当時のVMは共有メモリ（コンピューターのメモリ領域のうち、実行中の複数のプログラムから読み書きが可能な領域）の扱いが特に苦手だったことです。

当時はOracleなどのデータベースがどんどんLinuxに移植されている時期でした。データベースのほとんどはマルチプロセスですから、共有メモリを多用します。さらにデータベースはメモリサイズも非常に大きい。つまり、前述の弱点に刺さりまくるわけです。データベースをLinux上で動かすには、VMの課題を解決する必要がありました。

VMの改善に関しては、小崎さんによる解説に詳しい。

―VMに手を入れるという経験を積まれたことは、ご自身のキャリアにおいてどのような意義があったと思いますか？

小崎　これはLinuxに限らないですが、「この領域は自分が作りました」といえる要素があると、何かトラブルがあっても解決できるので、キャリアとしての優位点になりますし会社としても売り込みやすいです。

それから、もう少し卑近なビジネスの話をすると、アライアンス企業に「リリースまで日が迫っているが、○○の修正を取り込んでほしい」という類のお願いをするときに「テストに割ける期間は少ないですが、開発した自分が世界で一番詳しいですから、リスクは低いです」と言える。つまり交渉において優位になるという利点もあります。

Linuxカーネルのメンテナーになるには、知識と覚悟が必要

―Linuxカーネルの開発コミュニティが持つ特徴についても聞かせてください。

小崎　Issueトラッカーがないことが大きな特徴です。Issueに関するやり取りは、全てメーリングリスト内で行われます。これが原因で参入の敷居が上がっているという側面もありますが、コミュニティ内で活動しているとIssueトラッカーがない利点も理解できますね。

というのも、世界中から来るIssueの数が人類にはハンドリング不可能なほど膨大です（笑）。「打ち返せなかったIssueは忘れていく以外にしょうがない」という合理的な判断をしているんです。

もう1つユニークなのはメンテナーの選び方です。普通のOSSコミュニティは中心メンバーがなんとなく決まっており、その方々が新しいメンテナーを指名するケースが多いですよね。しかしLinuxの場合は、MAINTAINERSというファイルに自分の名前を書いてLinus Torvalds（ torvalds 以下、Linus）にPull Requestを送り、Linusがマージすればメンテナーになるという流れです。

<

―珍しいフローですね。どのような基準を満たしたら、メンテナーの申請を出してもいいという判断をするのですか？

小崎　それは私にもよくわからないんですよね。当人たちの「そろそろいいんじゃないか」という感覚的な判断のもとに行われているように感じます。

―なぜ、そのようなフローになっているのでしょうか？

小崎　これは私の推測ですが、Linuxカーネルの修正は困難の多い作業なので、「メンテナーになりたい」と自己推薦する人が少ない世界だから、という要因は大きい気がします。その領域に飛び込んでいくのに、ある種の覚悟が必要というか。事前にかなりの学習時間を投下しないと、会話についていけないですから。人材の見極めが重要視されているのでは、と。

―まさに「半年ROMれ」の世界ですね。Linuxの開発コミュニティではLinusの存在が非常に有名ですが、過去と現在とで、彼のレビューに対する価値観で変わってきた部分はありますか？

小崎　昔のLinusはセキュリティ系のfeatureの価値を認めておらず、他の方がメンテナンスする状態がずっと続いていました。ですがそういうパッチも、ここ数年はLinus自身がよくマージするようになりました。

過去のLinusは、原理主義者な発言をすることが多かったです。例えば他のメンバーが「バグが存在しない未来というのは永久に来ない。だからこそ、バグが原因で機密情報を盗まれることを未然に防ぐためならば、多層防御的に緩和策を入れることには意味があるんだ」という旨の発言をしたならば「バグがあるならば、そもそもそのバグを直すべきであって、不要な緩和策を入れるべきではない」という感じに反対していました。

ですが最近のLinusは、セキュリティ系のfeatureの賛同派になりつつあります。活動を続けていくうちに、徐々にセキュリティについての考え方が変わってきたのだと思います。

時代が変わっても、低レイヤの知識の重要性は変わらない

―Linuxは世界中で使用されていますから、コード修正をした際の影響が非常に大きいのではないかと推測します。影響力を実感される瞬間はありますか？

小崎　Linuxカーネルのコントリビューションをしていると、面識のない方からサンキューメールが届くことがよくあるんですよ。「あなたの書いたプログラム改善のおかげで、私のシステムが100倍高速化された。本当にありがとう」とか。こういうときは非常に嬉しいですね。

―自分の書いたコードが世界の誰かの役に立つのは、感慨が大きいでしょうね。逆に、修正する恐ろしさを感じることはありますか？

小崎　しょっちゅうですよ。LinuxというOSは、ありとあらゆるコンピューター上で動いています。だから例えば、「世界にわずか何十台しかないスーパーコンピューターでしか再現しないバグ」のレポートが送られてくることもあるわけです。「たぶんソースコードをこう修正すれば直るだろうけれど、自分がスーパーコンピューターと同じテスト環境を手に入れることは絶対に不可能」というケースが日常的にあります。

―ヒヤヒヤしますね……。

小崎　そうしたときも対応できるだけのスキルが、コントリビューターには求められます。カーネルの動作の正常性を隅々までテストで保証することは、おそらく将来的にも無理です。「実機で動かしてみないと不安」というレベルでは、コントリビューターを務めることは難しいでしょうね。

―Linuxカーネル開発コミュニティの、レベルの高さを感じます。これまでの機能修正のなかで「入れてよかった」と印象に残るものはありますか？

小崎　NUMA（Non-Uniform Memory Access）まわりの調整は印象深いですね。細かい調整が多かったので1つ1つは解説しませんが、LinuxでNUMAの対応が最初にされたころは普通のPCにNUMAという概念はなくて、ほぼSGI（Silicon Graphics, Inc.）社のスーパーコンピューター専用機能だったんですよ。

それで色々なパラメーターのデフォルトがスーパーコンピュータ的な大きなマシンと、HPC（High Performance Computing）的な分散並列な処理を仮定していて、ふつうのx86がNUMAになるとさまざまな問題が生じてしまうんです。NUMA最適化コードをパラメタでoffにすると速くなるみたいなライフハックが溢れてしまって……。

すでにある機能を後付けで調整していくのは非常に骨が折れるのですが、結果的にインストール直後にすぐoffにする機能みたいなのが減ってよかったと思っています。

あと、これは他の人が行った貢献ですが、環境変数の最大値が4KB（メモリ1ページ分）に制限されていたのをとっぱらう機能は印象的です。当時はなんの役にも立たなかったけど、あとから考えてみると、いい修正なんです。

というのも、近年はクラウドネイティブの時代になって、多様なパラメーターを環境変数で渡すことが一般的になってきましたよね。4KBでは足りないようなケースも出てきました。もしもあのとき反対していたら、自分たちの首を締める結果になっていたかもしれません。

―1つひとつの決断が、非常に大きな意味合いを持つのですね。最後に伺いたいのですが、近年、クラウド技術や各種マネージドサービスの対等により、「低レイヤの知識を知らなくても何とかなってしまう時代」になりつつあるように感じます。そんな現代だからこそ、低レイヤーの技術を学ぶ意義とは何だと思いますか？

小崎　ただ動くアプリケーションを作るだけであれば、確かに低レイヤの知識はあまりいらなくなってきていると思います。ですが実際には、何かしらのシステムでトラブルや性能問題などが発生したとき、低レイヤの知識を知らなければ問題を解決できません。

だから、低レイヤのことをちゃんとわかっている人が不要になる世界は、今後も来ないと思うんですよ。むしろ、そのスキルを持つ人の希少価値は上がっていますから、キャリアとしての価値はより大きくなっているように思いますね。

取材・執筆：中薗昴