#LinuxCon Japan 2016参加レポート

コンテナー技術

このテーマは以下のセッションが該当する。

• Keynote:-Cloud-Native-and-Container-Technology
• A-Gentle-lntroduction-to-Linux-Containers
• Container-Standardization-lntroduction

コンテナー技術は2013にリリースされたオープンソースソフトウェア(OSS)であるDockerの登場頃から急成長をとげ、言葉だけよくきいていた。事前に調べて仮想化の技術（コンテナー仮想化）ということは理解したが、従来のVirtualBoxやVMwareなどによるVM仮想化との違いがいまいちわかっていなかった。今回のカンファレンスでその遠いと利点がよくわかった。

コンテナー技術は昔からあるが、最近になって急成長を遂げたのはクラウドやマイクロサービスと相性がよく、VM仮想化と比べ、クライアントOSが不要なためパフォーマンスがよく、効率がとてもよいからとわかった。

クラウド事業を行っていなければ､VM仮想化でも十分そうだが、テスト環境やサーバーを立てるときなどにも使えるので、選択肢の一つとして知っておいた方がいいと思った

オープンコンプライアンス

近年になって、 Bash､OpenSSI,など有名なOSSにセキュリティ問題が発覚してきた。今までオープンソースは技術的に普及しており、安全な印象を持っていた。今回のカンファレンスでは、OSSのコンプライアンスやセキュリティ脆弱性に関するセッションがあり、初めて知ることが多くとても興味深かった。具体的には2日目と3日目の以下のセッションが該当する。

• Keynote:Back from the Future:Open Source Compliance (David Marr)（2日目）
• Showing-Management-the-Light:-Explaining-the-Business-Strategy-Behind-Investing-in-Community-Best-Practices（2日目）
• (In)security-in-Open-Source（3日目）

社内においてもOSSはふんだんに活用している。インターネットにつながっていないので脆弱性は大きな問題にはならないと思うが、コンブライアンスの考え方や管理方法は開発ソフトの品質を向上させるためにも有用だろうと思った。

このオープンコンプライアンスについては以下がキーワードとなる。

• OpenChain:標準化の仕組み
• SPDX:メタデータの形式
• FOSSBazzar:管理ソフト
• Core Infrastructure Initiative:団体

時間を見つけて調べて、知見を深めていきたい。

カーネルドキュメント

このテーマは2日目の[Kernel Documentation: What We Have and How We’ll Make it Better]の内容だ。

個人的な興味として、ドキュメンテーションをどうやるかに関心があった。複数人での共同開発、ましてやLinuxカーネルのような巨大なプロジェクトにおいてはまとまった文書の存在がきわめて重要になってくる。ただ、文書のメンテナンスの労力は無視できないので、いかに効率よく文書化システムを整えるかが重要だろうと思っていた。

Linuxカーネルとしては、もともとは独自ツールとDocBookをベースにやっていたが、いまいちだったので、MarkdownやAsciiDocを試して今はSphinxに落ち着いたとのことだ。 Sphinxの存在は知っていたが、個人的には汎川性からAsciiDocを好んでいた。

今回、 LinuxカーネルでSphinxが使われているのを知り、改めて調べたところ、 SphinxではC言語のAPIを記述するための記法(Doxygenの関数の説明記法に似たもの）が標準で用意されていた。AsciiDocでもおそらく拡摂機能を作れば実現できると思われるが、標準でこういう機能があるのはとても重要で、ソースコードの文書化ツールに特化したSphinxならではの芸当だと思った。

CI/CD(ContinuousIntegration/Development)

開発効率を上げるには、 自動化というのが大きなポイントとなってくる。

巨大なプロジェクトになってくると、なおさら重要になる。ピルドやテストなど少しでも自動化できるところはできるだけ自動化を図つた方がいいだろう。

このためのツールとして、 2日目の[Continuous Integration and Delivery for Free and Open Source Software]で紹介されていた以下のようなツールは調査検討しておいたほうがいいと思った。

• Git
• Gemt
• Zuul
• Jenkins
• Nodepool

その他のセッション

1日目の[Networking Containers in an Ultra-I,ow-Latency Envimnmentlの発表では、ネットワークの応答速度の実験をしており、この結果は有用な部分があるのではないかと思った。

また､3日目最後のLinuxカーネル開発者のパネルディスカッション[Keynole: KemeI Developer Panel]で、静的解枅ツールとしてcoccinelleとSmatchがおすすめされていたのが気になった。

Smatchはあまり情報がなく，coccinelleのほうが情報が多そうだ。coccinelleについては，これを扱った発表があったようだ。

INTRODUCTION TOCOCCINELLE AND SMPL

また，カンファレンス終了後に公開されたスライドで興味深かったのが，Googleのオープンソースへの貢献に関する発表。

How Google Uses and Contributes to Open Source

Googleは標準のライセンスとしてApache2を採用している。特許を明示的にできるのがいいらしい。一番気になったのは，CC0について。CC0ライセンスのコードは，貢献しても自分たちの著作権を保持できないので，使ったり貢献できないとか。会社でやる以上，著作権の保持はしたいということのようだ。

食事

高級ホテルでの開催ということと国際カンファレンスということで食事がよかった。お昼ごはんはカンファレンス参加申し込み時に，事前に選ぶことがで き，菜食主義者，ヴィーガン，グルテンフリーに配慮していた。今回は菜食主義者で申し込んだので，お昼ごはんは菜食弁当だった。このお弁当がとてもおいしかった。雑穀をメインとした料理となっていて，サラダなどに使われているオイルがとてもよかった。未来食カフェレストランTUBUTUBというお店で作られたお弁当だった。

以下にお昼弁当の写真を掲載しておく。

@senopen 楽しみにしていた菜食弁当。
未来食カフェレストランTUBETUBEというお店。
手前のエビフライにみえるやつは人参。 pic.twitter.com/hhlGZaBkOM

— せのぺん (@senopen) 2016年7月13日

#linuxcon
楽しみのお昼ごはん。菜食弁当。グルテンフリーは
ベジタリアンと別らしい中身気になる。 pic.twitter.com/LNWRk5hQ49

— せのぺん (@senopen) 2016年7月14日

#linuxcon 今日のお昼。このハンバーグ雑穀のきびでできてるんだって。 pic.twitter.com/Ka6ryvY9vh

— せのぺん (@senopen) 2016年7月15日

お昼ごはんの他に，朝食にパンと3時のおやつにクッキーも配られていた。

@senopen 受付が終わって、参加しょうとシャツもらった。#linuxcon 朝ごはん。 pic.twitter.com/q8kvnfv6xi

— せのぺん (@senopen) 2016年7月12日

今日の朝ごはん#linuxcon pic.twitter.com/SlLel3E0nQ

— せのぺん (@senopen) 2016年7月13日

今日の
朝ごはん。#linuxcon pic.twitter.com/kQQo9nlWEE

— せのぺん (@senopen) 2016年7月14日

クッキーは大量に配られていて，20枚くらい食べても有り余るほどあって驚いた。

#linuxcon ひたすらクッキーをぱくつく簡単なお仕事。 pic.twitter.com/sVmOmXE7UN

— せのぺん (@senopen) 2016年7月14日

今日のクッキー#linuxcon pic.twitter.com/pJiisvA6Fw

— せのぺん (@senopen) 2016年7月15日

また，最終日の3日目の最後のセッションの終了後は，レセプションとしてパスタなどの軽食とお酒も振る舞われていた。食事は量があまりなかったので，不足気味だった。

食事とは関係ないが，基調講演のような広い会場では，冷房が強くかかっていたので，長袖の上着を用意していたほうがよかった。半袖だと寒くて内容にあまり集中できないのでもったいなかった。

まとめ

Linux創生者であるI,inus Torvaldsと直接あって会話ができて，一緒に写真に写ってもらえたのがとてもよい思い出となった。

参加費が約4-5万円ということと，開催日が平日なので参加するのは難しい。3-5年に1回最新技術の動向を追うという意味で参加するくらいがちょうどいいだろうと思った。

発表内容としては，必ずしもLinuxに直接関わるものでなくてもよいので，次回参加するときは発表者として参加できたらいいなと思う。

次の節からは開催日ごとのセッションのメモを記していく。

Keynote: Open Source Landscape

Jime Zemlin

オープンソースへの投資の状況､マーケット、市場変化について説明。現在ではすべてのコードでオープンソースが支配的であり、オープンソースに自社コードをプラスすることで、企業は価値を創出している。

一方で､オープンソースは複雑さやリスクも抱えているので､それを管理していくことも必要である。

こうしたオープンソースを支えている団体としてLinux Foundationを紹介し、スケール可能なオープンソースの要件として以下の要素をあげた。

• 統制とメンバーシップ
• 開発プロセス
• インフラ
• IP

さらに、オープンソースプロジェクトに横断して必要な要件を示した。

• セキュリティ
• ガバナンスとエコシステム
• ライセンスと1P
• 教育と認証

オープンソースは少ない投資で多くが得られる分野であるので、参加する利点が大きい。

Keynote: Overview of Hyperledger

Brian Behlendorf

初めて知ったHyperledgerというデータベースのブロックチェーン技術を発展させたオープンソースプロジェクトの紹介。既存のデータベース技術の問題点を指摘し、Hpyerledgerがそれらを解決することを目標にしている。

伝統的データベース処理では、遅延が問題なってきた。分散型データベースにおける、ブロックチェーンには以下の問題がある。

• スループットの制限
• 遅い処理・確認
• プライバシーがない
• 匿糸性

Hyperledgerはブロックチェーン技術を発展させ、複数の産業標準を考慮でき、ビジネス取り引きを確実にできる。

Keynote: Embedded Linux in lndustry and Civil lnfrastracture Systems

JanKiszka(Siemense),WshitakeKobayashi(‘Ibshiba),HimshiMine(Hitach)

産業や雑盤インフラにおけるLinuxの砿要さを打ち出した発表だった。ビジネスカンファレンスでよくある事例紹介で個人的にはあまりおもしろくなかった。

Keynote: The Rise of the Open Source Program Office

Gil Yehuda(Yahoo)

オープンソースを組織で適用していく際の戦略についての話だった。かなりビジネス寄りの話が展開され理解が難しい内容だった。

Keynote: The Kernel Report

JonathanCorbet(LWN.net)

LinuxKemelの開発状況についての発表。

LinuxKemelは現在だいた70日くらいでバージョンを上げている。次のリリースが7/17の4.7の予定。

ここ数年の傾向として、 リリースごとの貢献者数は微増。開発コミュニティの変化はほとんどなく、継続がスムーズになった。

そのほか、Linux Kemelの課題として以下の項目について言及した。

• セキュリティ
• メモリー
• カーネルバイパス
• 転送プロトコル
• ライセンス
• 文書

Keynote: Fujitsu with Open Source Communities

KeniiKaneShige(Fujitsu)

富士通がLinux Kemelやオープンソースコミュニティになぜ参加するか、どういう貢献をしているかについて説明していた。

富士通はここ 10年くらいオープンソースにコミットしてきた。従来はLinuxOSへのコミットが多かったが、ここ2-3年でOpenStackへのコミットが急増して、全体の半分がOpenStackへのコミットとなった。

富士通がOSSに参加する理由について説明｡一般的に、開発コストを減らすにはどうすればいいか考えたとき、単一の会社で行うとコストが高くつく。しかし、コミュニティで協力するとコストは高くない。また､信頼できるプラットフォームを自社が提供するうえで､使用しているオープンソースの改善が必要だった。

オープンソースへコミットすることで社内のエンジニアの成長にもつながった。

Linux Kernel Security Update

JamesMoITis(Oracle)

資料：http://events.linuxfoundation.org/sites/events/files/slides/linux_kernel_security_linuxconjp2016.pdf

Linux KerneIのセキュリティサブシステムのコア開発者による現在の状況の報告。Linux Kernelの機能について細かい説明が多く理解が難しかった｡

Fail Fast, Fail Often

GordonHafT & WilliamHenly(RedHat)

開発において、失敗はつきもの。この話では上手な失敗の仕方についての発表だった。

上手に失敗するうえでは5の規範を守ることが亜要となる。

1. 適切な範囲：失敗の影響を制限。
   
2. Small :十分に定義された機能に分割。
3. AUTDNOMOUS:実装の変化をほかのサービスから独立させる。
4. 適切なアプローチ：継続的な実験と反復。
5. Pmcess：関係者を巻き込んでコミュニケーションをとる。

そして、繰り返しの自動化。ビルドと組織のシステム化は上手な失敗を容易にする。

Introducing the Civil lnfrastructure Platfom Project

Yoshitake Kobayashi(Tbshiba, JanKisZka(Siemens)

資料：http://events.linuxfoundation.org/sites/events/files/slides/Intriducing_the_CIP-LCJ2016.pdf

インフラとして使われるようなオープンソースやLinuxカーネルの保守の話。

オープンソースは般化した技術を使っているので､安全な面がある。逆に、コードをクローズドにしてしまうと近い将来で深刻な問題を引き起こす。他のソフトのアップデートで不確合が起きて問題になる。

Linuxカーネルは3か月ごとに更新しており、 ITS(Long Term Support:長期サポート） として2年サポートしている。しかし、一般的にインフラでは少なくても10年はサポートが必要。そこで、CIPというプロジェクトがあり、これでLinux Kemelを10年サポートしている。

あるソフトを10年ごとに更新するのは変化が多くたいへん。だからといって、2年おきに更新すると10年で5回更新することになる。小さなパッケージから始め互換性を保つことが重要となる。

Networking Containers in an Ultra-Low Latency Environment

AviDeitcher(AtomicInc.)

GoogleやAmazonなどは通信速度が少しでも遅くなればそれがダイレクトに損失につながってくる。

Latency(通信の要求開始から応答までの速度）がとても短いネットワーク (ULL)を行うのにどういうハードを使えばいいかの実験の報告。

結論

• SR-IOVは試す価値がない。
• Metalは常に最高のパフォーマンス。
• Direct network++ではmacvlanは頼もしい。
• ULI, :Metal/net = host > macvlan > callco > overlay

最終的には自分のアーキテクチャーとスキルに焦点を当てる必要がある。

ネットワークについて知識はあまりないが，とても有用な発表だったように思えた。

Keynote: Cloud Native and Container Technology

ChrisAniszDWk(TheLinuxFoundatiOn/CNCF)

クラウド業界やコンテナー技術の動向についての発表。最近コンテナー技術と呼ばれるものが流行ってきており、なぜ流行ってきているのか興味深かった。

最近の傾向として、世界の大企業はどんどんソフトウェアの会社になろうとしている。例えば、自動車会社や旅行会社。TOYOTAはスタンフォードの博士と協力してAIを研究している。

また、データの収集・利用が以前にもまして重要さを上げてきている。

例えば、Web会社

• Google
• Twitter
• Facebook

これらの会社でのソフト開発はサービスを売るためにやっている。

大企業で使われるクラウドコンピューティングの特徴として以下の要素がある。

• コンテナー技術
• マイクロデバイス

クラウドにおいて、コンテナー技術を使うと非常に効率がいい。人件費を大幅に削減でき、ダイナミックなスケジューリングが可能。

これがGoogleやTOYOTAでコンテナー技術が使われる理由。

例えば、コンテナーの利用スケールは以下となっており、かなり使っている．

• Google：20億
• Facebook：30万
• Twitter：25万
• Netfix： 1万

こうした企業では過去にスケールで失敗しており、研究してたくさんのソフトを試してきた。

こうした動きを受け､昨年2015年にクラウドコンピューティングの団体ができた｡CIoud Nalive Compuling Foundation (CNCF)。最後にこの団体でどういうことをやろうとしているのかを報告。

Keynote: Back from the Future: Open Source Compliance

DavidMarr(Oualcomm)

法律家によるオープンソースコンプライアンスの話。この話ではOpenChainとSPDXというキーワードが印象的だった。

オープンソースのコピーレフトという考え方は、とてもクリエイティプで法律家としても好きな考え方だった。しかし、オープンソースの中には間違っているものもある｡ 間違っていてもそのまま情報が受け継がれていく．自己修正のメカニズムがない。これはリスクが大きい｡バグフィックスのライセンスがない。

これを解決するために、OpenChainというアセスメントの標準がある。これに従うことで、効率性や透明性を上げることができ、オープンソースのリファレンスモデルとなる。さらに、SPDXというメタデータの文書形式がある。これに現在のコードの問題点などのメタデータを組み込むことで、 自己修正がしやすくなる。OpenChainとSPDXをもっと広めていきたい。

Keynote:Conversation with Linux Creator

DarkHohndel(VMwarc),Linux.Torrvalds

Linuxの創成者であるI,inus TbrvaldsとVMwareの人による対淡｡Linuxのカーネルの話はよくわからなかった。気になった点を抜粋。

• カーネルの2ﾉ3はドライバー。残りがアーキテクチャーやファイルシステム。
• 優れたメンテナーはよいテイスト （趣味）がある。プログラミングとは述う。プログラミングはエンジニアリングで､みかけや動作がいいことを要求される。例えば､美しくて機能のある家。これを気にしているのではない。同じことを見ても、もっといい方法があるだろうと思えること。これだったらいいぞと理解できる人がいい．

Kernel Documentation: What We Have and How We’ll Make it Better

Jon Corbet(LWN.nel)

Linux Kemelにおける文書化の話。個人的にはかなり興味のあるテーマだった｡

カーネルツリー全体の俯瞰は必要だが、もともと相互参照やほかの文書を参照するようなものはなかった。文書はカーネル開発に参加するときのとっかかりの最初となることが多い。

Linuxカーネルの開発は25年の歴史があるが、最初の15年間は文書がいまいちだった。

規模感

• カーネルのソースコード:53654ファイル
• カーネル文書
  
  • 2264ファイル
  • 228ディレクトリ
  • 23MB

カーネル文書の形式は以下の3形態がある。

• .txtファイル(2000+)
• DocBook形式(34のテンプレート) (重要事項の文書）
• Doxygenに似たKernelコメント (55000個）

文書化には従来、開発者が自作した文書システムを使っていた。ただ欠点がある。

• 遅い
• britlIe
• 設定とmakeが難しい。
• 汚い
• 残りの文書との統合ができない。

ここ最近kerneldocにmarkdown処理を加えた。その後asciidocに切り替えた。

これにより，

• DocBookを回避
• よりよい文苫

欠点

• 新しいツールの追加
• ツール間での不整合
• パフォーマンス
• 文書間でのリンクがない。
• Ruby依存

カーネルの文書化でやりたいこと。

• DocBookはやめたい。
• 簡単なマークアップを使いたい(MaIkdown、AsciiDoc,Sphinx)
• 書式化していない.txt文書にもそのまま適用したい。

これらを実現するために文書化ツールを再検討とした。それでSphinxに目を付けた。

Sphinxの利点

• コードの文書化に特化
• でかい文書にも対応
• 世界的に使われている
• 出力はHTML、EPUB、PDF
• DocBookやTeXに頼らない

一部簡単な拡張機能を作って使い始めた。今後はSphinxの適用を拡大予定。

Continuous Integration and Delivery for Free and Open Source Software

DongMa(HPE)

資料：http://events.linuxfoundation.org/sites/events/files/slides/Continuous%20Integration%20and%20Delivery%20for%20Free%20and%20Open%20Source%20Software%20Development_0.pdf

OSS(OPenStack)におけるCI/CDの重要さとその流れについての発表だった。

巨大なオープンソースプロジェクトでは、CI/CDもスケールしないといけない。OpenStackでは以ドのツールを組み合わせてCI/CDを維持している。

• Git
• Gerrit
• ZuuI
• Jenkins
• NodepOol

A Gentle lntroduction to Linux Containers

BrianPmmt(RedHat)

資料：http://events.linuxfoundation.org/sites/events/files/slides/gentle-intro-containers-LCJapan2016.pdf

Linuxのコンテナー技術全般の紹介とDockerの使い方に関する発表。この発表でコンテナー技術の特徴がよくわかった。

Linuxコンテナーの特徴は以下となっている。

• ユーザースペースだけ。ホストカーネル上でイメージがアプリを実行。
• アプリ＋ランタイムの依存関係を持つ。
• ホストと同じOSであること。
• アプリはホストOSから独立。

コンテナー技術と仮想化技術は似ている｡VMに対するコンテナーの特徴は以下となる。

• コンテナーの方が軽い。コンテナーの方が小さく、必要なリソースが小さい。
• 同じOSに制限される。
• コンテナーはマイクロサービスのためにある。

コンテナー技術自体は新しいものではなく、歴史としては1998年のchroootに始まる。

Linuxコンテナーの利点は以下となる

• 環境をまたぐ商いポータピリティ性。
• 開発とテストの一箇性．
• VMに比べ動作が早く容量が小さい。
• 他人の作業の上で使える。
• モジュール化。
• レガシー環境の扱いがとても簡単。

Container Standardization lntroduction

MaShimiao(Fujitsu)

資料：http://events.linuxfoundation.org/sites/events/files/slides/container_standardization_introduction_v3.pdf

最近急成長してきたコンテナー技術の標準化に関する話。

仮想化を、コンテナー技術を使ったコンテナー仮想化とVMを使ったシステム仮想化の二つに分頽。

コンテナー仮想化がシステム仮想化に比べて軽い理由は、システム仮想化はHOST上にゲストOSをそれぞれ持つのに対し、コンテナー仮想化はホストOSだけでいいから。

コンテナー技術が最近急成長してきた理山は以ド3点。

• ポータピリティ
• ユーザービリティ
• Agility

コンテナー技術の急成長に伴い、多くのコンテナー技術ソリューションが’生まれた。

• Docker
• Rocket/rkt
• OpenVZ/Odin
• Hpyer

しかし、これらは互換性がなく、業界標準がない。どのアプリがベストなのかユーザーは遡択が難しい｡

そこで、OCI (Open Container lnitialive) という標準化団体が2015-06-22に設立された。

Solving Device tree lssues, Part2.0

FrankROwand(SOny)

l.inuxのデバイスツリーについて、デバッグ方法の紹介。設定ファイルの説明など細かい情報が多く、 デバイスツリーについて知識がなかったのでよくわからなかった。

Showing Management the Light: Explaining the Business Strategy Behind Investing in Community Best Practices

ShadeCoUgh!an(Insignary)

オープンソースコンプライァンスの話。

オープンソースは78％の会社で使われており、オープンソースによりイノベーション速庇が速くなった。

プロプライエタリなソフトと同様に、オープンソースにもセキュリティ検査や監視が必要．67％の会社がOSSの脆弱性を監視しきれていない。

オープンソースというのはコードだけでない。法律やビジネス戦略もかかわってくる。

OpenChainは、オープンソースのサプライチェーンの作るために必要な仕組み。

コンブライアンスのためのツールとしては以下がある。

• Binary analysis
• FOSSOLOGY

オープンソースの知識はほかのステークホルダーから利用可能。コミュニティの全員はオープンソースの継続的成長に興味がある。自社の成功にもつながる。

フリーライダーは市場からフェードアウトしていく。

Tracking Huge Files with Git LFS

TimPcttcrscn(Allassian)

資料：http://events.linuxfoundation.org/sites/events/files/slides/Tracking%20huge%20files%20with%20Git%20LFS%20-%20LinuxCon%20JP.pdf

Gitで巨大なバイナリーファイルを管理するGit I,FSの発表。Gitの仕組みの説明もあり勉強になった。

なぜGilは巨大ファイルの管理が苦手か。これを知るにはGitの仕組みの理解が必要。

Gitではコミットごとにオブジェクトへの参照（ポインター）を持っている。親のコミットから親のディレクトリへ、そこからさらに個別のファイルへの参照を持っている。これにより、変更があったファイルだけの差分を持つことができている。

しかし、バイナリーファイルは少しでも差分があればカウントしてしまう。だから、 単一で50MBのファイルでも2回目の変更で+50MBで合計100MBとなってしまい、どんどんリポジトリが肥大化．

これを防ぐために、Git LFSではさらにもう一つポインターを間に持つ。これにより、ホストとLFSとで保存先をわけることできる。 git pullしたときには最新のI,FSだけを提供することで、 リポジトリの肥大化を抑制する。

Introduction to the Fuego Test Framework

Tim Bird

資料：http://events.linuxfoundation.org/sites/events/files/slides/Introduction-to-Fuego-LCJ-2016.pdf

テストフレームワークのFucgoの紹介。コンテナー技術の応用としてなるほどと思って。環境を統一するのにもコンテナーは有用だと思った。

Fuego=(Jenkins + abstraction Scripts + pre-packaged test) inside a container

フロントエンド：Jenkins

バックエンド：シェルスクリプト

Fluentd and Coutainers

Satoshi Tagomori & Masahiro Nakagawa(Tresure Dala)

ネットでよく見かけるが実態をよくしらないFluentdというログの収集分析ソフトの話。

まず、最初に伝統的なロギング方法の問題点を指摘し、 Fluentdの特徴を説明。最後にFIuentdとコンテナーの組み合わせを紹介していた。

伝統的なロギングにはryncが使われていた。これには以ドの問題がある。

• ログたまり、収集が終わるまで1日またないとけない。
• データ形式がぱらぱらで解析が困難

FIuentdの特徴

• Low Latency
• ログをJSON形式に整形。

Apache、Hadoop、MySOl.、 AWSなど変換が簡単｡

データ構造にQueを使っており、チャンクごとにデータをため込んでいる。これにより、転送途中で送信が失敗してもリトライが少なくて済む。

コンテナーだと、大量に一つのところにログが転送される。これだと負荷が大きすぎる。サーバー側にFIuentdを常駐させ、さらに間にアグリゲーションサーバーを一つはさむことで、 うまくいく。

Why Fujitsu Joined the CNCF

Hiroyuki Kamemwa & Wolfgang Ries(Fujitsu)

富士通がCNCF(Cloud Native Computing Foundation)に参加した敬意とその活動についての発表。

CNCFはコンテナーパッケージやマイクロサービスを念頭においた団体。 10000の新しいパラダイムが生まれた。

データを集めてそのあとどうするか？データを活用して高い生産性につなげよう。

クラウドプラットフォームは極めて生産性が高い。今プラットフォームの在り方が変わってきて、オンデマンドプラットフォームになってきた。 コンテナーを使えばオンデマンドプラットフォームの実現が簡単になる。

富士通がOSSに入ったのは、 白分たちが治すす必要のある問題があったため。

Live Patching for Linux

Vojtech pavlik(SUSE)

プログラムの動作中にパッチによる修正を施すLive Patchingの事例と実演。内容が少し難しくてあまり理解できなかった。

膨大なコスト (100kUSD/hour)の削減のためにLive Patchingが必愛な場面がある。

• 問題発生時：動作停止
• 緊急対応：脆弱性対応

Live Patchingは一般的にはDSU(Dynamic Software Updates) と呼ばれる。

関数を新しく作って差し替えたり、オブジェクトファイルだけを差し替えたり、いくつか方法がある。

(In)security in Open Source

Shane Coughlan(Insignary)

オープンソースのセキュリティ問題とその関連ツールについて言及。

オープンソースで起きた有名な脆弱性。

• Hertbleed
• Shellshock(bash)
• Freak
• Ghost
• Venom

他にもDROWN攻撃で11百万のサイトがOpenSSLを使いリスクを冒していた。韓国ではIotでバスの到着情報がハックされた。

どうすればいいか。十分なレビューがされていないからではないか。文書化が必愛なもの、自動化できるものを決める。FOSS BazzarとかSPDXでこうしたコンブライアンスに関する情報を管理できるようにする。

Keynote Panel: Open Source Evolution for Carries

Ashiq Khan(Docomo Research Labs), Masashi Kudo(NEC), DanieI Farrell (Red Hat), Marc Cohn(The l,inux Foundation)

ネットワークのキャリアなど業界のトップによるオープンソース革命についてのパネルディスカッション。ビジネスよりな話が多く内容は難しかった。主にオープンな組織運営とその利点に関する話が多い印象だった。

Q. 組織においてオープン性の実現に必要なことは何か？

A. 歴史的には小さな会社と人きな会社があると、最初は大きな会社が支配的になる。時間がたって多くの頁献荷が入ってくると、最初にいたコミッターの役割が変化して中立性が生まれてくる。多様性を維持することがオープン性とII’立性に必要な要素の一つといえる。

Q. オープンとクローズドでそれぞれどういう利点があるか？

A. クローズドにするときは、 IPとか売り上げを独占したいとき。オープンを選んだらIPはすべてリリースしないといけない。隠せない。ただ、皆の意見が社外コミュニティに実装されてうれしいことがある。技術戦略としてはクローズドよりはオープンの利点が大きい。

Keynote:Kernel Developer Panel

GregKman-Hartman,LaurengPincharLChristophHellwig･JamesMomsMasamiHimmatsu

Linuxカーネルのコア開発者によるパネルディスカッション。話が早くてメモが間に合わなかった。

Q.プロジェクトで使う言語を変えることがあるか？

A. その言語が30年使えるか、統合できるか。静的な型チェックができることはかなり重要。もう一つはコンパイラー。このあたりを満たせれば検討の余地はある。

O. 最初のカーネルのパッチをどうやって出せばいいか？

A. どういう手順でどういうパッチをどこにだせばいいか、文書化しているのでそれに従えばいい。

Q. パッチをリジェクトされたらどうすればいいか。せめて理由を教えてほしい。

A. 粘り強くやってほしい。メンテナーも忙しいときがある。できるだけ返信しようとはしている。宛先にメンテナー、CCにMLを入れてメールを出してくれると誰かに読んでもらえる可能性が高い。CCにメンテナーを入れてもフィルターで弾くことがある。

O. SF的な質問だが、巨大な帝国は滅びることが世の常だが、 Linuxは残るだろうか？

A. AIにメンテさせるとか、それこそターミネーターの世界。 Linuxはレガシーコードベースのものが多いので、なくならないと思う。なくなるとしたら、オーバーヘッドが無視できないとか、新しい技術などが入ってきて共同できなくなったときだろうか。

Q. Linuxのいいところはどんなところか？

A. 進化の形がいい。ライセンスがGPLだから、どんな変化もForkもマージできる。そして、大企業の影響を受けないのが強い。OpenStackは企業ベースだから辛いだろうね。

O. 静的な型チェックツールで何かおすすめはあるか？

A. coccinelleとSmatchがよい。 とくにcoccinellは3年前にしっていれば採用していた。