コンテナ運用環境を標準化？ CNCFは何をやろうとしているか：オープンソースとエンタープライズの関係（3）
Cloud Native Computing Foundationは、クラウドネイティブアプリケーション開発・運用環境に関する技術の「標準化」を推進しているという。臨時エグゼクティブディレクターに、具体的な活動内容を聞いた。
コンテナの世界は、コンテナエンジンからレジストリ、オーケストレーション、アプリケーション管理まで、さまざまな技術が入り乱れ、混沌とした状況にある。ネットワーキングやストレージ、セキュリティについても、統一的な「解」と呼べるものが存在しない。これでは、一般的な企業がコンテナベースのマイクロサービスアプリケーション開発を進めようとしても、何をどう考え、どの技術を組み合わせて環境を構築すべきか分かりにくい。
2015年7月に発表され、2016年1月に正式発足したCloud Native Computing Foundation（以下、CNCF）は、この問題の解決を目的としているという。発表時点では、AT＆T、シスコ、Cloud Foundry Foundation、CoreOS、Cycle Computing、Docker、 eBay、Goldman Sachs、グーグル、Huawei、IBM、インテル、Joyent、Mesosphere、レッドハット、Twitter、ヴイエムウェア、Weaveworksなど主要企業が参加、その後もメンバーは増え続けて50社を超えるまでになった。
だが、激しい競合が進行中のホットな分野で、CNCFが正確にはどのような立ち位置で、何をやろうとしているのか、外からは分かりにくい。そこでCNCFの臨時エグゼクティブディレクターを務めるChris Aniszczyk（クリス・アニズィック）氏に、具体的に聞いた。
CNCFとKubernetesの関係はどうなっているのか
CNCFに関して最も分かりにくいポイントは、米グーグルのコンテナオーケストレーションソフトウェア開発プロジェクトであるKubernetesとの関係だ。CNCFの発表時に、米グーグルはKubernetesのコードをシード技術としてCNCFにコントリビューションする考えを明らかにした。この時点で他にコントリビューションされる技術として示されたものはない。では、CNCFとは結局Kubernetesを推進する組織なのか。これについてAniszczyk氏に確認すると、CNCFはKubernetesの運営組織を発足する話として始まったという。
「グーグルはKubernetesを自分たちでコントロールし続けたいと思っていなかった。この技術の普及のためには、何らかのファウンデーションに移管する必要があると考えた。そこで、移管先として例えばApache Foundationを候補に挙げたが、そのガバナンスモデルが気に入らなかった。Apache Foundationには『技術に関する最高裁判所』のような存在がない。だから複数の技術を協調させる力がない。HBaseやCassandra、Stormなど、さまざまなオーバーラップする技術の間で、何らかの標準化や統一を図る仕組みがない」
「そこで、Kubenetesが要素の1つとして参加できるような、新しいタイプのファウンデーションを作ろうとした。お互いに競合する技術を横並びで扱い、標準化を進めることができ、技術に関する中立的な最高裁判所とも呼べる技術統括委員会（Technical Oversght Committee、以下TOC）が協調を推進できる組織だ。さらに、実際の利用者であるエンドユーザー組織が影響力を行使できるような環境を作ろうとした。ベンダー中心のコミュニティにだけはしたくなかったからだ。そこでさまざまな組織に働き掛けると、コンテナの世界における競合プロジェクト間の調整や協調を求める人たちが多く、こうした人たちが2015年の発表に参加した」（Aniszczyk氏）
CNCFは、現時点で仕様を策定することはない
では、CNCFは具体的に何をやっているのか。同団体では 、クラウドネイティブコンピューティングを、「コンテナベースで、動的にスケジューリングされるマイクロサービス環境」と定義しており、図に示されているように、これはさまざまな要素で構成される。
CNCFが活動の対象とするのは、OCIが担当するコンテナ形式／エンジン以外。一般企業が何をどう使えばいいのか、図中の各要素について、事実上の標準を推進するとともに、要素間のすり合わせを行う。Aniszczyk氏は、「この図よりも細かな単位で考えている」と話す
グーグルやツイッター、フェイスブックなどは、それぞれ独自にツールを開発するなど、さまざまなやり方でこうした環境を構築してきた。しかし、後に続く企業は、何をどう組み合わせれば、自分たちが便利に使える環境が作れるのかが分からない。そこでCNCFは、図の各要素について、標準やベストプラクティスを確立、他の要素との整合性を確保する取り組みを進めているという。
標準化については、まず各要素で事実上の標準となるようなオープンソースのプロジェクト／ソリューションを見いだして推奨する。次にこれをベースとし、必要であれば調整や仕様の策定を進める。
ただし、コンテナ形式については別団体のOpen Container Initive（OCI）が標準化を担っているので、これ以外の要素における標準化／ベストプラクティスの提示を進める。
例えば、KubernetesはCNCF結成のきっかけにはなったが、同団体の中で特別な存在というわけではない。単なる最初のメンバープロジェクトであり、コンテナオーケストレーションにおける推奨選択肢の1つという位置付けだ。一方、Dockerも独自のオーケストレーション技術を出しており、Mesosphereが中心となって開発しているMesosも、Kubernetesとは競合する存在だ。だが、これらが排除されることはないという。Docker、MesosphereはどちらもCNCFの当初からのメンバーであり、今後同ファウンデーションが取り上げることは十分あり得るという。
Kubernetesに続く第2のプロジェクトとして、CNCFはコンテナリソース監視のPrometheusを取り上げた。
CNCFとして各要素においてどのソフトウェアを取り上げるかについて、Aniszczyk氏が「技術に関する中立的な最高裁判所」とも表現するTOCの判断に任されている。TOCは完全に中立的な立場で、何が最もメリットに優れているかを判断し、行動する。具体的には、ストレージを例にすると次のようになる。
「コンテナのためのストレージについては、多数のスタートアップ企業が誕生しており、Dockerも自社のやり方を提供している。だが現在のところ、影響力の大きいソリューションがない状況だ。このため、現時点では仕様やインタフェースを決めるわけにはいかない。まずは１、2のストレージプロジェクトをCNCFでホストし、これらを本番環境で試してみて、どのやり方がいいのかを確かめてから、TOCが標準インターフェースの開発を進めるという手順を踏むことになる」（Aniszczyk氏）
では、ネットワークについてはどうか。これについてもDockerはlibnetworkという自社なりのやり方を提示している。一方で、Cloud Foundry、Kubernetes、Weave、Mesosなどが採用したことで、人気が高まってきている存在としてContainer Network Interface（CNI）があるという。
「CNIは、徐々に事実上の標準となりつつある。多くの人々に採用されることで、自らを証明しているともいえる。この技術をCNCFでも取り上げ、『ネットワークのための良い手段』として推進する機が熟したのかもしれない」（Aniszczyk氏）
Aniszczyk氏は、図に示された要素全てにわたる作業を一通り済ませるには、長い時間が必要になるだろうと話す。また、互いに競合する技術を中立的に扱うため、それぞれの要素についても、時間とともに取り上げるプロジェクトが増えたり、入れ替わったりする可能性があるとする。
こうした取り組みでは、異なる要素間で標準的なインタフェースを策定するのが自然な流れのはずだ。だが、Aniszczyk氏は現在のところ、そうした活動をCNCFでは予定していないと話す。
「理由は、まだ時期尚早だからだ。CNCFでは現在、3種のプロジェクトが走っている。1つはプロジェクトをホストする活動。KubernetesとPrometheusが現時点では対象となっている。これは実装のみで標準化とは異なる。2つ目のプロジェクトは事実上APIあるいは仕様に関するものだ。だが、CNCFは標準化団体になりたいわけではない。本番環境でどのようなことが行われているか。これが私たちにとっての標準化を形作ることになる。要するに、仕様は後で自然に作られるという考え方だ」
Copyright © ITmedia, Inc. All Rights Reserved.