Linux Foundationは11月15日、日本におけるオープンソース活用を推進する活動の一環として「Open Source Forum 2016」を横浜にて開催しました。

Linuxの普及をサポートするNPOであるLinux Foundationは、これまで毎秋に国内外のユーザ企業向け技術カンファレンスとして「Enterprise User's Meeting」を開催してきました。Linux Foundation 日本担当VPの福安 徳晃氏は、毎年改善を繰り返してきた「Enterprise User's Meeting」を今年から「Open Source Forum」として始動することになったといいます。

第1回目となる今年は、現在最も注目されているテクノロジー分野であるコンテナ、ブロックチェーン、セキュリティに関するオープンソースプロジェクトに注目し、Linux Foundationの協業プロジェクトであるCloud Native Computing Foundation（CNCF⁠）⁠、Open Container Initiative（OCI⁠）⁠、Hyperledger ProjectおよびCore Infrastructure Initiative（CII）のプロジェクトリーダーが来日し、それぞれのプロジェクトの現状や今後について紹介しました。本稿では、この中でもコンテナ分野にフォーカスして当日のイベントを紹介したいと思います。

最初に登壇したLinux FoundationのExecutive Director Jim Zemlin氏は、オープンソースプロジェクトに必要なのは「持続可能なエコシステム」であり、豊かな開発コミュニティがビジネスに利益を与えるコマーシャルプロダクトを製品化できるコードを生み出し、再びそのプロジェクトに投資することであるいいます。

Zemlin氏は、エコシステムには、ガバナンスモデルやメンバーシップの決定と推進、リリースプロセスなどの開発プロセス、セキュリティおよび信頼性を担保するインフラストラクチュア、イベントやトレーニングなどのエコシステム開発、トレードマークなどの知的財産管理などの実務的な業務が必要だとします。Linux Foundationでは、このような考えに立ち、上述のプロジェクトを含めて近年多くの協業プロジェクトと呼ぶオープンソースプロジェクトを支援しているそうです。

特に近年急激な増加を示している協業プロジェクトについて、私は「どのような基準で協業プロジェクトを選んでいるのか？」という質問しました。

Zemlin氏は、3つの視点で選定しているといいます。1つは問題を解決できるコードであること。たとえば、ブロックチェーンに対するHyperledger Projectです。2つめは、問題を解決するために複数の組織が関係するため、中立／相互的な場所が必要になるときです。たとえば、1つの企業で解決できる場合はそのような問題がないので、協業プロジェクトの候補にはならないそうです。3つめは、開発するためのリソースをずっと得ることができるかということです。

CNCFとOCI、そしてクラウドネイティブアプリケーションとは？

このような背景のもと、Linux Foundationで推進されているコンテナ関係の協業プロジェクトにCloud Native Computing Foundation（CNCF）とOpen Container Initiative（OCI）があります。コンテナ関係のセッションで最初に登壇したChris Aniszczyk氏（CNCF COO 兼 OCI GM）は、「⁠クラウド・ネイティブとオープン・コンテナ技術の状況」と題して講演を行いました。

Aniszczyk氏は、コンテナテクノロジーの採用は引き続き拡大しているが、一方で「分断されている」という課題を指摘するところからスタートしました。分断化された例として、Docker、rkt、Kurma、LXC/LXD、Hyperd、OpenVZといった複数のコンテナテクノロジーが存在しているといいます。

もう1つの問題提起として、Googleのようなインターネットスケールの企業から学んだことを紹介しました。次のようなことです。

伝統的なシステム管理者は、問題が発生してからマニュアルで課題に取り組み、サービスが大きくなるにつれチームを大きくし、開発チームとは関係が良くありません。一方、昨今話題のSRE（Site Reliability Engineers）では、こうしたやり方とは違うアプローチ（クラウドネイティブアプローチ）を取ります。SREは運用の自動化を行い、マニュアルでの作業を避け、blameless postmortem（個人批判をしない、建設的な障害の振り返りミーティング）のカルチャーを持つといいます。

この2点の問題提起をふまえて、彼はサーバ（Sun⁠）⁠、仮想化（VMware⁠）⁠、IaaS（Amazon Web Services⁠）⁠、PaaS（Heroku⁠）⁠、Open Source IaaS（OpenStack⁠）⁠、Open Source PaaS（Cloud Foundry⁠）⁠、コンテナ（Docker）といった2000年以降の代表的な企業／組織とテクノロジーの変化を紹介し、OCIとCNCFもこの流れの中にあると位置づけました。

これらの流れが示すのは、コアのビルディングブロックが、［⁠サーバー⁠］⁠→［⁠仮想マシン⁠］⁠→［⁠ビルドパック⁠］⁠→［⁠コンテナ］に変化したことに加え、「⁠クローズドソースで1社だけのテクノロジー」から「オープンソースでベンダをまたがったテクノロジー」となったことだといいます。そして、この流れから発足したのがOCIとCNCFであるとします。

OCIは、2015年6月にAmazon Web Services、CoreOS、Docker、Mesosphere、Microsoft、Red Hat, VMwareなどが参加して「Open Container Project（OCP⁠）⁠」として設立されました。Facebookが中心となり推進しているOpen Compute Project（OCP）と略称が一緒ということもあり、設立後すぐに現在の名称に変わっています。OCIでは、コンテナフォーマットとランタイムに関する共通仕様を定義することを目指しています（なお、OCIは俗に「コンテナ戦争を終結させた」プロジェクトといわれています。実際にどのような流れであったかは後述⁠）⁠。

Docker, CoreOSのrkt、Apache Mesos、CNCFのKubernetes、Cloud Foundryなどが現在OCIによる標準をサポートしています。コントリビュータとしてはRed Hat、Docker, CoreOSだけでなく、HUAWEIの貢献が大きいことも注目点でしょう。

続いて紹介されたのがAniszczyk氏がCOOを勤めるCNCFです。2015年7月にDocker、CoreOS、Red Hat、Google、IBM、Mesosphere、Cisco、Intelなどが参加して発足した団体です。マイクロサービス指向のアプリケーションやサービスによるクラウドネイティブなアプリケーションの推進を目的とした団体です。

CNCFが最初の開発プロジェクトとして進めたのが、Googleから寄贈されたコンテナ管理システムKubernetesとSoundCloud社が始めた監視ソフトウェアPrometheusです。CNCF発足後1年以上が経過した現在、これらのソフトウェア以外にもさまざまなプロジェクトが承認あるいは提案されています。たとえば、Treasure Dataの共同創業者である古橋貞之氏が2011年に開発を始めたOSSログ収集ソフトウェアであるFluentdはCNCFの管理するプロジェクトになっています。

ところで、組織の名称にある“⁠クラウドネイティブ⁠”といってもピンとこない人もいると思います。

Aniszczyk氏は、CNCFで定義しているCloud Native Reference Architectureを紹介しました。Cloud Native Reference Architectureでは、アプリケーションの定義や開発、オーケストレーションと管理、ランタイム環境、プロビジョニングおよびインフラストラクチャーの層に分けて、代表的なソフトウェアや環境をマッピングしています。どのようなソフトウェアがクラウドネイティブであるかを知るには、以下のマップを見るのが一番簡単でしょう。

彼はクラウドネイティブであることの価値として次の点を挙げます。

• コードやコンポーネントの再利用や運用のシンプル化などアイソレーションできること
• OSSスタックをパブリッククラウド、プライベートクラウドあるいはその組み合わせたクラウド環境にデプロイできるためロックインがないこと
• モダンな分散環境に最適化されていてスケーラビリティに制限がないこと
• マイクロサービスを動的に管理、スケジュールするオーケストレーションプロセスが可能で、効率的に運用管理、リソースの最適化が可能であること

Aniszczyk氏は、CNCFのゴールとしてこれらのクラウドネイティブソフトウェアプロジェクトをホストするベストな場所になりたいとのことでした。

「コンテナ戦争」とコンテナ標準化

コンテナテクノロジーのトラックで続いて登壇したのが、CoreOS社チームリードであるJonathan Boulle氏です。Boulle氏は、前述のCloud Native Reference Architecture にマップされているetcdやコンテナ技術rktの開発をリードするエンジニアです。彼は、「⁠The Open Container Initiative : オープンなエコシステムの標準の形成」と題して、OCIがリードするコンテナテクノロジーの標準化について紹介しました。

運用エンジニアは、「⁠標準コンテナイメージを利用して、自分が開発したイメージやサードパーティ製のイメージを安全にデプロイしたり、イメージを利用するツールを選択したり、あるいはイメージを検査・監査できるようにしたいと思うだろう」と、あるべき姿を示しながら、実際どのようにコンテナテクノロジーの標準化が進んだかという歴史を紹介しました（つまり、数年前はあるべき姿ではなかったということです⁠）⁠。

2013年までは、ulimit, cgroups, chroot, namesspaeなどを利用して自分用のコンテナを使うか、パワフルではあるが複雑なLXCを利用していたといいます。2013～2014年にかけて、アプリケーションコンテナの夜明けとなります。それは、使いやすく開発者にフレンドリーなDockerが登場したことによります。そして2015～2016年には、DockerだけでなくrktやFLATPAKが登場し、アプリケーションコンテナがメインストリームへと進出するようになりました。

しかし、Boulle氏は2014年ごろのDockerのイメージフォーマットには問題があったといいます。たとえば、仕様が決まっていない、content-addressableでない、MX recordsのようなName delegationがない、サイニングができないなどといった点です。

そこで発足したのがCoreOS社などが参加するappc（App Container）プロジェクトです。appcでは、イメージフォーマットとランタイムにフォーカスし、配布しやすいコンテナテクノロジーの標準化を目指しました。appcでの成果物として、rkt（Linux⁠）⁠、Kurma（Linux⁠）⁠、Jetpack（FreeBSD）のランタイム環境が開発されています。

2015年には、Docker社がv2.2となるイメージフォマットを定義しました。ベンダー仕様ではありますが、初めてほとんどの内容がドキュメント化されたことや、content-addressableとなったことが特徴です。しかし、依然としてName delegationがなく、サイニングについてはオプションで別個に定義されていました。つまり、一歩標準化には進んだが、appcプロジェクトの目標から見ると足りない点があるということになります。

上記のような事情もあり、2015年の段階ではコンテナテクノロジーの標準が2つに分かれていました。このappcとDocker社の争いは「コンテナ戦争」と呼ばれていました。

しかしこの状況は長くは続かず、2015年6月にコンテナイメージフォーマットおよびランタイムの標準化に向け、Docker社やappcメンバーを含む多数のコンテナ関連ベンダーが結集して、OCIが発足しました。OCIの活動は順調に進み、現在コンテナイメージフォーマットおよびランタイムの第1版のリリース候補が公開されています。今後OCIは、これらの標準に基づいてさまざまなツールやランタイム環境が提供されるようになることをゴールの1つとしています。

このように「コンテナ戦争」は収束しました。

Docker社もCoreOS社も日本法人が存在していないことから、「⁠コンテナ戦争」については十分な情報がなく、興味のある方が翻訳されたニュースなどを追いかけていたと思います。今回、当事者から当時の経過を聞くことができて非常に勉強になりました。

協業プロジェクトを「絵に描いた餅」にしないために

今回のセミナーでは、コンテナ関係ではRobust Perception創業者あるBrian Brazil氏が、Dockerやマイクロサービスの監視で注目が高まっている監視ソフトウェアPrometheusをデモンストレーションつきで紹介しました。ZabbixやNagiosのような運用監視ソフトウェアとは違う領域で力を発揮するソフトウェアです。興味のある方はぜひ検索してみてください。

Zemlin氏は講演の最後に「今、私たちは歴史上もっとも偉大な共有されたテクノロジー資産を構築つつある」と述べました。本セミナーの翌日となる11月18日には、MicrosoftがLinux Foundationのプラチナメンバーになったことが発表されたように、あらゆる企業や団体、開発者、ユーザが参加して、テクノロジーを共有する動きはますます強まっていると思います。今回紹介したコンテナ関係のプロジェクトは誰も参加できるものです。ぜひ参加してみてはいかがでしょうか？

最後に、Zemlin氏が90年代に上智大学に留学していたことを初めて知りました。そのため、私が日本語で質問した内容を通訳なしで理解して、当日会場の日本語がわからない参加者に英語で質問内容を説明していたことには驚きました。Zemlin氏をイベントで見かけたときには、日本語で変なことを言ったりしてもわかってしまうということですね。