Linus Torvalds氏やMitchell Hashimoto氏が登場 〜Open Source Summit Japan 2018 （2018年6月20日・22日取材）
The Linux Foundation主催の技術カンファレンス「Open Source Summit Japan 2018」が、2018年6月20日〜22日に開催された。公式発表によると、Open Source Summit Japan / Automotive Linux Summit Japan 2018の参加者数は1000名以上。
ここでは、20日のキーノートの後半と、22日のキーノートをレポートする。
（このレポートは「Open Source Summit Japan 2018開幕 Jim Zemlinの講演に続きAGLやHyperledgerの事例を発表」の続きです）
LinuxカーネルのSpectre対策で大変だった点は
20日のキーノートの後半では、Linuxカーネルのコア開発者としてThe Linux Foundationに所属し、stableカーネルのメンテナーでもあるGreg Kroah-Hartman氏（通称Greg K-H）が登壇。今年初頭から各種OSを騒がせたSpectre/Meltdownと呼ばれる一連の脆弱性について、Linuxでの対応をまじえて解説した。
Hartman氏はこの問題について、CPUのハードウェアのバグで現代的なCPUに共通するものであること、アプリケーションが正しいコードでも防げないこと、CPUの投機的実行を悪用したものであることなどを概説した。
Spectreは現在、1〜5の番号が付けられたvariant（変種）が発見されている。ちなみに、このうちvariant 3がMeltdownとも呼ばれる。
variant 1は境界チェックの回避だ。たとえば、配列の終わりをチェックしながら1つずつ値を読み取るような場合、CPUは範囲チェックより先にメモリを読んでキャッシュに入れるため、キャッシュの有無から値を推定できるというものだ。
Linuxカーネルでは、範囲チェックにarray_index_nospec()マクロを用意して、該当箇所をこれで置き換えることで対応した。最初は遅くなるものだったが、後からLinuxハッカーたちが最適化して、アセンブリ言語の簡単な命令になっているという。
Linuxカーネルでは、x86で1月に、ARMで2月に対応。それ以前のカーネルはアップデートするようHartman氏は呼び掛けた。
variant 2は、CPUの分岐予測を悪用したものだ。これは、コンパイラ、カーネル、マイクロコードのアップデートで修正がなされている。Linuxカーネルでは、x86は3月に修正。ARMは関係ないと思うが、確かなことはわからないという。
Meltdown（variant 3）はユーザー空間からカーネル空間のメモリを読めるもの。KPTIやKAISERなどの修正が順次作られており、I/Oヘビーなシステムでは対策による性能への影響が見られるが、新しい修正ほど性能が大きく向上しているという。
Meltdownは、Linuxカーネルのx86では1月上旬に修正がなされた。ARMでは2〜4月に修正がなされたが、x86と違う方法で修正がなされているという。
なお、Meltdownのさらに変種のvariant 3aもあり、これもMeltdownの修正で対策されている。
variant 4は5月に公表された脆弱性で、「もうみんな慣れてセンセーショナルには扱われなかった」とHartman氏。ほとんどマイクロコードの問題で、カーネルにも少しの修正がある。Linuxのx86では5月に修正、ほかのCPUは問題ないと思うが確かなことはわからないという。
variant 5は、2018年6月に公表されたばかりの脆弱性だが、Linuxでは2016年に気付いて修正しているという。Linuxカーネル4.4には、2018年に追加でバックポートされた。
さて、なぜSpectreが大きな問題だったか。それはCPUのバグだったから、とHartman氏は説明した。すべてのOSに影響し、対策によってパフォーマンスが落ちた。CPU製品にも何年か影響するし、今後も報告や対応が続くだろうという。
また、この脆弱性は公表される以前に、CPUの会社から各種ベンダー企業には情報が行ったが、Linuxカーネル開発者にはなかなか来なかったのが困ったという。また、クラウドプロバイダーは商用ディストリビューションのLinuxカーネルを使わず、コミュニティカーネルを元にした独自カーネルを使っていたことも、遅れになったという。こうした情報体制が変わることを期待したいとHartman氏は語った。
最後にHartman氏は、Linuxカーネルを使う側の心得を挙げた。まず、パッチをつまみ食い（cherry-pick）せずに、stableカーネルのアップデートをすべて適用すること。また、カーネルのハードニング機能を使うこと。できればハードニングなどの対策が追加された新しいバージョンのカーネルを使うこと。そして、マイクロコードやBIOSもアップデートすることだ。
HelmのCNCFプロジェクトへの道
Microsoft Azureのシニアソフトウェアエンジニアであり、HelmやDraftのコアメンテナーでもあるMichelle Noorali氏は、Helmの必要性やCNCFプロジェクト入りの経緯、Draftについて語った。なお、Noorali氏は冒頭で「私はもともとRubyのプログラマーで、Rubyは日本のMatz（まつもとゆきひろ）氏が開発した言語」と自己紹介した。
Kubernetesについてはもともと、3年前に自社の課題に使えないか調べはじめたという。それは、コンテナアプリケーションを信頼できるやりかたでスケールさせるという課題だ。そこで、コミュニティに参加して調べ、安定して持続可能だろうと判断したという。
Kubernetesでは、マニフェストファイルで定義してやると、コンテナのクラスタを動かし、面倒を見てくれる。ただし、アプリケーションを動かすためにはマニフェストの記述が多数になるとして、Noorali氏は例を見せた。
そこで、Kubernetesで動かすアプリケーションのマニフェストを「チャート」としてパッケージングして再利用できるようにし、共有させるツールがHelmだ。これがコラボレーションを促進する、とNoorali氏は説明した。
Helmも大きく成長している。このように開発コミュニティが大きくなってくると、スケールの問題が出てくる、とNoorali氏は言う。メーリングリストやSlackなどのコミュニケーションチャンネルを管理したり、カンファレンスを開いたりと、技術的でない課題も増えてくる。
そこでHelmのコア開発者たちが話し合い、CNCFに入ってプロジェクトをホストしてもらうことを決めた。プロポーザルを書いて手続きし、受け入れられて、5月末にCNCF入りが発表された。「いまはそのための事務作業中で、非常に楽しみにしている」とNoorali氏はコメントした。
もう一つ、人が集まり始めたプロジェクトとして「Draft」も紹介された。アプリケーションをコンテナ化してHelmでデプロイするまでの何度もやるプロセスを自動化するツールだ。Draftは1.0の前に人気が出た例だ、とNoorali氏は説明した。
Draftのデモも壇上でなされた。APIサーバーのアプリケーションと、それを呼ぶWebアプリケーションとを、それぞれDraftでデプロイして動かし、Webブラウザーでアクセスしてみせた。
最後にNoorali氏は、CNCFにはすばらしいツールやサンプル、ガイドラインが揃っていると説明。ライセンスや行動規範なども紹介しながら「みなさんが新しいドアを開けられたらと思う」と語った。
SUSEとNECも講演
SUSEのThomas Di Giacomo氏（CTO）とTroy Topnik氏（Product Manager, Cloud Application Platform）は、PaaS基盤ソフトCloud FoundryのディストリビューションであるSCF（SUSE Cloud Foundry）をデモした。
講演のタイトル「Better Together」は、Clouf FoundryとKubernetesをつなぐという意味だ。デモでは、Helmを使ってKubernetes上で動かしたSCFで、サンプルアプリケーションをSCFにデプロイして動かした。さらにSCFから同じアプリケーションをIBM Cloudにもデプロイしてみせた。
NECのKeiichi Seki氏は、同社のOSSへの取り組みを紹介した。NECではオープンソースへの取り組みを、Operation、Community、Governanceの3つで考えているという。
プロジェクトとしては、以前からLinuxやOpenStackなどにコアメンバーとして参加している。OpenDaylightやOPNFV、ONAPといったネットワークや通信のプロジェクトにも参加。KubernetesやHyperledgerなどの新しいプロジェクトにも参加している。Seki氏は「エコシステムが大事だと思っている」として「われわれはコミュニティに貢献していく」と語った。
Linux Torvalds氏「退屈なのがいちばんいい」
Linus Torvalds氏のキーノートは、いつものようにカーネル開発者のDirk Hohndel氏（VMware）との対談形式で行われた。
「いつもと同じ質問から始めます」と前置きしてHohndel氏は、RC版としてリリースされたLinux 4.18-rc1について聞いた（なお、rc2は6月24日にリリースされた）。これに対してTorvalds氏は「コンスタントな開発ができるように考えていて、順調に続いている」と回答した。「毎回リリースごとにだいたい1万以上のコミットがあり、今回のリリースも前回と違わない。今回で違うのは、消した行が多かったことぐらいだ」。
メンテナーのトラブルについてHohndel氏が聞くと、「単純なミスだ」とTorvalds氏。「新しいコードを受け付ける期間のあとにバグフィックスのみの期間を設けているが、みんなバグを直すより新しい機能を作るほうが楽しいので、バグフィックスと称して新しいコードを遅りたがる（笑）。それできつい言葉を使うこともある」。
とはいえ、この数ヶ月には特別な状況としてSpectre/Meltdownの問題があった。これについて「この問題は投機的実行を用いたものだ。私はCPUに興味があるので、本当は興味深い攻撃だ」とTorvalds氏。「しかし、秘密裏に進められたのはフラストレーションを感じた。一部の人たちだけが問題を知り、コミュニケーションがないことが分かってしまった。その後、問題が公表されて、メーリングリストで公に議論できるようになった」と不満を訴えた。
日本のOpen Source SummitはAutomotive Linux Summitと共催となっている。それにちなんでHohndel氏は自動車でのLinuxの信頼性について質問した。これについてTorvalds氏は「小さいシステムのほうが問題が入り込みにくいが、現在では自動車でもネットワークを使うようになってきており、小さな組み込みシステムでは済まなくなっている。Linuxは長年やってきてテストされているので、信頼できると思う」と答えた。
ここでHohndel氏は、「『Linus Torvaldsの作ったものでいちばん影響があるのはLinuxではなくgitだ』という記事を見た」と苦笑混じりに話題を振った。Torvalds氏は「このあいだ、git bisect（どのコミットで問題が混入したか探す機能）がなかった時にはどう開発していたのか、不思議に思った」とgitの有用性を自ら認めた。「gitを始めたときには乱暴で使いにくいと言われたものだったが、慣れてくるとみんな使うようになった。これには私も驚いている」。
gitの開発は、Torvalds氏が始めたあと、Junio Hamano（濱野純）氏が引き継いだ。「彼が大変なところをぜんぶやってくれた」とTorvalds氏は語る。「gitは大きなものになったが、考え方はシンプルだ。コアになる共通の考え方があり、その上に細かいツールが乗る。これはUnixやLinuxと似ている」
Hohndel氏はさらに、GitHubの成功についても話を広げた。「GitHubの成功は、gitのためのインフラが必要だったからでは」とHohndel氏が質問すると、Torvalds氏は「YesでありNoでもある。インフラが必要というのは正しいが、gitは分散バージョン管理システムだ。git以前は集中型バージョン管理システムが多かったが、それだとプロジェクトの場所を1箇所に決める必要があるので、GitHubのようなインフラは使いづらい。gitであればプロジェクトの場所が関係ないので、GitHubが好きに使える」と答えた。
これについてHohndel氏がさらに「GitHubが世界の中心でなくていい。つまり、Microsoftが買収しても何も変わらないということですね」と聞くと、Torvalds氏は「それがgitのメリット。コントロールで競争するのでなく、よいもので競争する」と答えた。
話題は再び変わって、Linuxやgit、さらにSubsurface（Torvalds氏がHohndel氏らとともに開発しているスキューバダイビング用ソフト）の次の新しいプロジェクトについてHohndel氏は質問した。Torvalds氏は「新しいものは好きじゃない（笑）。いつも、自分には欲しいけどほかの人が作っていない、というネガティブな理由で始めた。3つのプロジェクトを始めて、もうこれで十分なので、ひとつのことに集中したい」と答えた。
なお、ほかに興味のあることしては、「コンパイラに興味があったし、FPGAで新しいハードウェアを設計して作るのにも興味があるが、時間がない」という回答だった。
Linuxカーネルの方針に「ユーザーのコードを壊さない」というものがある。Linuxカーネルのバージョンを上げたときに、その上で動くソフトウェアが動かなくなることがないようにするということだ。これについてHohndel氏が質問すると、Torvalds氏は「開発者は機能を変えるのがいちばん楽しいが、使うユーザーが求めるのはいままでと同じことができることだ。退屈なのがいちばんいいことだ。私がメールで暴言を書くのはたいてい、誰かが何かを壊して、直さなくていいでしょうと言っているときだ」と発言した。
とはいえ、Linuxが機器に組込まれるようになると、使われる期間は長くなる。「安定したバージョンが必要ということで2年前のカーネルを製品に採用して、その製品が5年使われると、7年前のコードに依存することになる。その時点で7年前のコードを直してくれと言われても困る。早い時点で言ってくれれば対応できるのだが。それを組み込みの人に言いたい」（Torvalds氏）
最後にHohndel氏は「来年のこの場所で話すこと」を尋ねた。Torvalds氏は「こうなったらうれしいこと」として、「ARMアーキテクチャはさまざまなプラットフォームで動くのが、ハードウェア屋さんにとってはアドバンテージだが、それがカーネル開発者には厳しい。来年には、全ARMシステムでブートが標準化されるのを期待している」と語った。
Mitchell Hashimoto氏「ありがちな失敗は、従来型とクラウド型のミスマッチ」
Mitchell Hashimoto氏は、企業のクラウドへの移行で問題になることについて語った。氏は「ソフトウェアを使うのは簡単。大事なのは考え方を変えること。クラウドにもそれがいえる」と冒頭で述べた。
Hashimoto氏は、「クラウド」「マイクロサービス」「スケジューラー」の3つを順に来ている主流トレンドとして挙げた。
基本になるのがクラウドだ。Hashimoto氏はクラウドのメリットを、最小限から使用量に合わせて使えること、APIファーストで作られて自動化できること、グローバルに分散すること、高価値のサービスが用意されること、低コストで拡張できることとした。
次にマイクロサービス。そのメリットとして、1つのソフトウェアの担当範囲を小さくしてクオリティを上げられること、標準化されたコンピュータインターフェイス、開発とデプロイの並行化、パーツごとにアップデートできてセキュリティにもいいことが挙げられた。
スケジューラーは3つの中で最新のものだ。さまざまなアプリケーションを統一してデプロイし、リソースの利用効率を上げ、自動復旧やスケールアウトを実現する。
さて、その次にハードルとなるのは、運用、セキュリティ、ネットワーク、開発の4種類の人がみな仕事をクラウドに切り替える必要があることだ。「馬から自動車に変わったときのようなものだ。自動車を単にいい馬として扱うと、メリットを生かせない」とHashimoto氏は言う。
運用の人の場合、従来型のスタティックなモデルでは専用のサーバーをあらかじめ必要な量用意する形だが、クラウドのダイナミックなモデルではオンデマンドで無限のスケールとなる。セキュリティの人の場合、従来型ではファイアウォールなどの境界線で区切るIPベースのセキュリティだが、クラウド型では境界線がなくアイデンティティベースのセキュリティとなる。ネットワークの人の場合、従来型ではホストベースでスタティックIPアドレスで構成したが、クラウド型ではサービスベースでダイナミックIPアドレスで構成する。開発の人の場合、従来型ではアプリは専用のインフラ上で動くが、クラウド型ではどこでも動く。
「ありがちな失敗は、たいてい技術ではなく、従来型とクラウド型のミスマッチが原因だ」とHashimoto氏は述べ、2つのパターンを紹介した。
1つめのパターンは、運用だけクラウド型にして、ほかの3つは従来型のままなケースだ。「これはよくある。クラウドに移ったけど、ほかは同じにして成功、と言っているケースだ」とHashimoto氏。
この場合に問題になるのは、クラウド上で従来型のネットワークやセキュリティ、開発を実現するために、たくさんのVPCや山ほどのサーバーなど、必要ないインフラがたくさんできることだとHashimoto氏は指摘する。また、開発スピードにもボトルネックが生じる。
2つめのパターンは、ほかの3つがクラウド型に移ったのにセキュリティだけが従来型のケースだ。この場合に問題になるのは、すばやくデプロイできるようになったのに、セキュリティのレビューの時間がかかって、アプリケーションのデプロイが遅くなることだ。
このパターンに銀行での事例があったとHashimoto氏は紹介した。従来型のセグメントベースのセキュリティとクラウド型のセキュリティを両立させてコストが倍になる。また、アプリケーションをデリバリーするためにたくさんのファイアウォールの設定を変え、そこに時間がかかることにもなっていた。この事例ではセキュリティもクラウド型のロールベースモデルに変え、ファイアウォールをとめることで、時間とコストを削減したという。
最後にHashimoto氏は、こうしたクラウド型のモデルをすべて可能にするのは、KubernetesやTeraform、Ansibleといったオープンソースの力だと説明。さらに、「新しいモデルを採用すればみなさんの会社も新しいことに成功する」と語った。
AGLのIVIへの取り組み
Automotive Grade Linux（AGL）プロジェクトに参加するマツダ、スバル、スズキの3社によりIVI（In-Vehicle Infotainment、車載インフォテインメント）への取り組みに関する講演も行われ、それにホンダとトヨタを加えた5社が壇上に立った。
マツダのSeiji Goto氏は、AGLにおけるIVIの取り組みを解説した。
IVIでは非競争領域をAGLで共通化して問題を解決しようとしているという。「リファレンスボードに比べて製品ははるかに複雑で、そのギャップが発展を阻害している。そのギャップを小さくしようとしている」とGoto氏。
2017年に、「AGL Reference Hardware Specification」の規格を出した。ここでは、共通の部分をメインボードにし、違う部分を拡張ボードにする。
次のコンセプトとして現在議論中なのは、組み合わせて使える「レゴブロック」だ。実際の車に搭載できるように2DINサイズを目指すという。
スバルのShinji Tsunoda氏は、プロジェクトのスケジュールを紹介した。リファレンスハードウェアの1stステップは、2019年上半期まで。そのあと2ndステップに移行する。
1stステップでは、メインボードにルネサスのRenesas R-Car Gen3 Startar Kitとインテルのボードを、拡張ボードにシマフジのKingfisher AdvancedとKingfisher Standardを用いる。
スズキのToshihisa Haraki氏は、2ndステップを紹介した。2ndステップではできるだけいろいろな種類のメインボードと拡張ボードを作る。また、メインボードと拡張ボードの間は、1stステップでは特殊なインターフェイスだが、2ndステップでは共通のインターフェイスにしたいという。
