コンテナストレージの共通仕様にも着手、あらためて、CNCFは何をどうしようとしているのか：CNCFのトップ2人に聞いた
CNCFは、クラウドネイティブアプリケーションの世界のデファクト標準を作り上げたいのか、それともコンポーネントベースでCloud Foundryの競合勢力を構築したいのかが、分かりにくい部分がある。そこでCNCFのエグゼクティブディレクターであるダン・コーン氏と、COOであるクリス・アニズィック氏に、あらためて同組織のやろうとしていることを聞いた。
Kubernetesを最初のホスティング対象プロジェクトとし、クラウドネイティブアプリケーションのプラットフォームの1つの姿をコンポーネントベースで追求する組織として設立されたCloud Native Computing Foundation（CNCF）。数回インタビューをしてきたが、結局この組織は、クラウドネイティブアプリケーションの世界のデファクト標準を作り上げたいのか、それともコンポーネントベースでCloud Foundryの競合勢力を構築したいのかが、分かりにくい部分がある。そこでCNCFのエグゼクティブディレクターであるダン・コーン（Dan Kohn）氏と、COOであるクリス・アニズィック（Chris Aniszczyk）氏に、あらためて同組織のやろうとしていることを聞いた。
参考記事：
コンテナ運用環境を標準化？ CNCFは何をやろうとしているか
コンテナネットワーキング仕様の次は
――CNCFは最近、10番目のプロジェクトとしてCNI（Container Networking Interface）を発表しましたが、これはインターフェースであり、従来のプロジェクトとは異なりますね。
アニズィック Open Tracingとは似ている部分があります。Open Tracingはさまざまな言語でトレース情報にアクセスできる共通ライブラリ群ですから。CNIが加わったことで、CNCFは2つの「仕様プロジェクト」を持つことになりました。続いて、Calico、FlannelなどのCNIプラグインをCNCFに迎え入れる可能性もあります。
何が起こっているかというと、CNCFでは最近、いくつかのワーキンググループを発足しました。その1つにネットワーキングがあり、このワーキンググループでは「何をCNCFに持ち込むべきか」「何をすることに意味があるか」について、合意を得る活動をしています。
最初の成果の1つが「CNIを（CNCFのプロジェクトとして）加えるべき」というもので、TOC（Technical Oversight Committee：技術監督委員会）に推奨し、TOCはこれを了承しました。これに続いて、幾つかのプラグインをCNCFに持ち込む議論を始めました。
――しかし、例えば1つのプロジェクトを迎え入れれば、他が苦情を言うのではないでしょうか？
アニズィック 苦情を言ってもいいですが、9人の委員で構成されるTOCが技術的な判断をします。CNCFでは、TOCが技術的な水準を高く保つ役割を担ってきました。
CNCFが、互いに競い合う複数のプロジェクトを受け入れた実績はあります。例えばContainerdとRktは競合していますが、双方ともCNCFに加わりました。CNI関連では、ある程度のオーバーラップが互いにありますが、それほど競合しない側面もあります。例えばCalicoはポリシーにフォーカスしています。
CNIはかなり前から提案されていました。しかし当初、TOCは仕様をプロジェクトとして認めることには消極的でした。この姿勢はOpen Tracingがうまくいき、仕様を迎え入れることのメリットをTOCが意識することによって変わりました。
――CNCFの当初からの目的の1つは標準化だったのではないですか？
アニズィック 「標準化」という言葉で何を意味するかによります。統合と言った方がいいかもしれません。さまざまな技術が協調して動くことが重要です。特定の単一技術に標準化することが目的ではありません。目的は、複数の技術をアラカルトで使えるよう、互いにうまく統合できる環境を作ることです。
――ええ、ですからインターフェースをプロモーションすることは大事ですよね。
コーン CNCFはIETFのような標準化団体と、Apacheのようなプロジェクトホスティング組織の中間です。Kubernetes、モニタリングのPrometheus、ロギングではFluentdなどを持ち込みましたが、Open TracingやCNIなど、仕様が成立しやすい分野では、進んで仕様の確立に取り組んでいます。
DockerとCoreOSによるcontainerdとrktのコントリビューションは、OCIという仕様と、（実装としての）オープンソースプロジェクトが双方とも存在するいい例です。
コンテナランタイムをホストする意味
――2社によるコンテナランタイムのコントリビューションは、CNCFの活動にとってどのような意味がありますか？
コーン 非常にポジティブなことだと思います。この1、2年、Dockerはフォークするのかといったうわさがありました。一方で、DockerへのSwarm Kitのバンドルに関する話がありましたが、Kubernetesで使うランタイムについては、最小限の実装を使いたいという意見が多数聞かれました。その後、Dockerは統合されたコンポーネントを分解し、その後ContainerdをCNCFにコントリビューションしてきました。これは業界にとって、非常にポジティブな動きだと思います。
アニズィック 「コンテナ戦争」やフォークについてさまざまな議論がありましたし、Dockerに対する不満も聞かれてきましたが、今回の動きにより、2つの最も人気のあるコンテナエンジンが中立的な家を持つことになりました。競争があるというのはいいことです。双方が同じ土俵で競うことは望ましいと思います。フォークに関する議論はこれで実質的に消えたと思います。
（ContainerdとCRI-Oは）プロジェクト的には単一の仕様に落ち着くと考えています。（CRI-Oについては）「Dockerが適切にふるまわないためフォークする」という考え方から、互いのアイデアを活用し、協力し合う方向に変わりました。
重要な点として理解していただきたいことは、企業としてのDockerが、自分から自社の技術を小さな部分に分解したことです。Containerdはこうした努力がなければ実現しませんでした。Mobyもコンポーネント化の一環です。
CNCFも自らのコレクションを主張する？
――以前アニズィックさんはCloud Foundryを「opinionated」な技術だと言っていましたが、あらためて考えると、CNCFもそこそこopinionatedな、クラウドネイティブ関連技術のキュレーション活動だと表現できるのではないでしょうか？
アニズィック TOCが選択した技術群をそろえているという点ではopinionatedですが、全てがまとまった単一のディストリビューションが存在するわけではありません。Kubernetesだけで60以上のディストリビューションが存在するわけですが、CNCFのメンバー企業には、それぞれ使いたい技術コンポーネントを選択して、自らのクラウドネイティブ技術のディストリビューションを構築することで、競争してほしいと思っています。
CNCFとしては、これらのディストリビューションのコンフォーマンスを確保することが重要だと考えています。どのコンポーネントをつなぎ合わせて売るかは、市場が決めることだと思うからです。
これに対し、Cloud Foundryでは基本的に全ての技術が1つにまとまっています。この点で、基本的にアプローチの違いがあります。
コーン この図で、クラウドネイティブの世界がどれだけ複雑になっているかが分かると思います。448ものプロジェクトが示されています。緑色がCNCFで採用したプロジェクトです。私たちは比喩として、「クラウドネイティブという、混乱しがちな新天地の地図を作る支援をする」という表現をしています。クラウドネイティブの目的地に向けては、さまざまな経路があり得るでしょう。しかし、CNCFのプロジェクト群は、1つの、よく構築された道を示しています。信頼性が高く、安全な道です。
――「CNCFは各分野で最適と考える技術を積極的にハンティングしている」と表現してもいいのですか？
コーン あなたが先ほど使った「キュレーション」という言葉はいいと思います。幾つかの分野では特定のプロジェクトを選択しています。一方、ネットワーキングなどの分野では、仕様を選択し、さらに複数のプロジェクトを選択します。（複数のプロジェクトを選択する理由は、）場合によって異なる技術が適していると考えられるからです。
アニズィック 実際に何が起こっているかというと、TOCが特定プロジェクトをスカウトすることもありますし、プロジェクトの方から働きかけてくるケースもあります。後者の場合はTOCが受け入れるか、拒否するかを判断します。
Googleはもともと、なぜKubernetesをCNCFに託したのか
――GoogleはGoogle Cloud Platform（GCP）について、オープンであることを強調しています。ですが、オープンは直接ビジネスに結びつきません。KubernetesをCNCFにコントリビューションしたことが、どうGCPのビジネスにつながるのでしょう？
コーン 私の説明は次の通りです。Googleが社内ツールであるBorgからKubernetesを生み出したとき、最もクローズドなものから最もオープンなものまで、4つの選択肢がありました。
第1に、Amazon Web Services（AWS）のAmazon EC2 Container Servicesのように、自社特有のクラウドサービスとして提供することができました。この場合、ユーザーはKubernetesを使いたかったら、料金を支払ってグーグルのサービスとして使う必要があります。第2に、Googleがコントロールするオープンソースプロジェクトにすることもできました。開発言語Goで、同社はこの方法を採用しました。3番目はKubernetesだけのための場所として、ファンデーションを作ることです。しかし、彼らは4番目の、最もオープンなシナリオを選びました。Kubenetesに加え、他のクラウドネイティブコンピューティングに関するプロジェクトをホストするファンデーションです。（この選択肢を選んだ）理由は、他のクラウドサービスとの差を縮めることにあったと思います。
――しかし、他のクラウドでも動く、地球上で最も人気のあるコンテナオーケストレーションツールを生み出したからといって、（自社のクラウドの）ビジネスの助けにはならないでしょう？
コーン Googleにとって最悪のシナリオは、企業が例えばAWSに自社の全てのITを移行してしまうことです。しかし、「AWSにロックインされる代わりに、GCPにロックインされてください」と言っても、誰も聞く耳を持ちません。そこで、ゲームチェンジをする必要があったのです。
Kubernetesはまさにこれを実現します。「AWSにも、Azureにも、GCPにもロックインされるべきではありません。このオープンソースのソフトウェアスタックを選択すれば、どのクラウドの間でも行き来できますよ」と言えます。
現時点ではおそらく、最も多くのKubernetesがAWSで動いているでしょう。しかし、そのうち顧客は、「料金を引き下げてくれなければ、他のクラウドに移行する」と交渉するようになるでしょう。
アニズィック 補足すると、AWSは主要クラウドサービスの中で唯一、Kubernetesをサービスとして提供していませんが、顧客が動かすのを止めてはいません。
コーン そこで、顧客があらためてクラウドサービスを比較し、ネットワークの品質、サービスの内容、料金などを検討してもらえれば、GCPは選ばれる確率が高まります。これまで、人々はGCPを選択肢として考えようともしなかったのですから。
コンテナストレージの共通仕様にも取り組む
――CNCFが現在注力していることを教えてください。
コーン 3つあります。1つはKubernetesです。非常に多くのユーザーと開発者を抱えるようになり、新たな課題も見えてきました。このプロジェクトの活動拡大に見合うリソースを確保できるよう、支援をしています。次にCNI、3番目にストレージです。
アニズィック コンテナストレージに関しては、CNIと同様に、共通のインターフェースについての議論が高まっています。ストレージベンダーは、異なるコンテナオーケストレーションツールについて、別個にライブラリを書き続けなければならないという不満を漏らしてきました。
以前、コンテナオーケストレーションツールは、この分野で競争していました。しかし、面白いことに、Docker Swarm、Mesos、Kubernetesは今、お互いに協力してCSI（Container Storage Interface）という共通の仕様を生み出そうとしています。これにより、誰かが特定のストレージについて、例えばDocker Swarmのためにライブラリを書くだけで、これがKubernetesやMesosで使えるようになります。
これは、CNCFが価値を発揮できる分野の1つです。人々が中立的な方法でコラボレーションできる場を与えられます。特定のプロジェクトでこうしたことをやろうとしても、（合意を得るのは）難しいと思います。現時点で、CNCF内ではストレージのワーキンググループが活発に活動しています。既に初期の仕様はあり、2、3カ月のうちには現実のものになるでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.