本エントリはさくらインターネットアドベントカレンダー2018の12月25日の記事です。メリークリスマス！！！！！
12月24日は、echizenya yotaさんの「さくらインターネット株式会社の田中邦裕社長からクリスマスプレゼントをもらう方法」でした。
ということで、今日は @matsumotory が 「分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから」について書いてみようと思います。
現状のgVisorやFirecrackerをはじめとするコンテナ実行基盤技術の公開に伴って、個人としてはこれからますます分散型データセンターOSのような基盤と、その上で実行されるリアクティブ性を持つコンテナ実行環境が重要になってくる時代がはじまるように思っています。
今日は、そのあたりについての自分の考えと、その流れを見据えて現在開発しているミドルウェアを2つ紹介したいと思います。
データセンターの分散と集約
現状、大規模なデータセンターをたててリソースを集約することにより、大規模だからこそできるコストの削減を行うといったような、過去にGoogleがデータセンターを立てることのコストメリットや効率化についての研究がされてきました。一方で、アプリケーションの高度化や基盤をクラウドに外出しながらも、マルチクラウド、クラウドネイティブといった時代になるにつれて、リアルタイム性を必要とする利用者にとっては、データセンターまで、あるいは、データセンター間のレイテンシーが課題になってきています。また、事業者としては巨大なデータセンターをたてたあとに、この変化のはやい時代に、そこにこれから何年かけて利用者を増やしていくのかといった見積もりの難しさという課題もあります。
現在、僕が所属するさくらインターネット研究所では、こうした課題と時代背景を考慮して、研究所としてのビジョンを以下の絵のように考えています。
この図にあるとおり、今後はコンテナ型データセンターにコンテナが動くのはもちろん、もっと小さなデータセンター、あるいは、データセンターとは呼べないまでも小型のラック群があらゆる場所に分散していく時代になってくるだろうと考えています。このように、マルチクラウドやクラウドネイティブ、さらには、スマートハウスやスマートモビリティ、エッジコンピューティング、データ流通といったように、ますますリアルタイム性が要求されて、かつ、計算にクラウド環境を活用することで、今後技術的にもプロダクト的にももっと社会をより良くできるような時代が訪れる予感があります。さらに、リアルタイム性の問題が解決してクラウドがもっと当たり前に使われていくと、これまで以上に予測できない大量のアクセスやトラフィックが集中するようにもなるでしょう。事業者にとっては、嬉しい悲鳴になりそうです。
分散型データセンターのOS化
データセンターの分散と集約、さらには、あらゆる要求においてクラウドが使われる時代になってくると、もはやどのデータセンターに利用者のアプリケーション実行環境などが起動しているかは気にしている場合ではありません。むしろ、そんな事を気にするようなシステムでは、利用者にとっては使いづらくてしょうがないでしょう。
そこで、当然ながらデータセンターの集約から分散が進み出すと、分散されたデータセンターをうまく抽象化するOSレイヤー、及び、実行環境の高集積化やセキュリティ、性能、リソース管理、運用技術といった課題を解決するための基盤技術のようなものがソフトウェア的に必要になってくるだろうと考えています。それらを本エントリでは分散型データセンターOSと呼ぶことにします。ちなみに、そこが僕の研究開発の領域になっていくことは自然な流れでして、同様の研究をWebサーバの文脈でこれまで取り組んできたからです。
Mesosとかははやくからこの考えのもとに色々な議論を進めており、本当にすごいなと感心するばかりです。今回はよりコンテナの実行環境や現在の時代背景に合わせて、僕の見解を展開していきたいと思います。
ここでいう分散型データセンターOSの役割は、いつ誰がどこでクラウドを使っても、それがどのデータセンターで動いているかは意識しないし、負荷分散やディザスタリカバリにおいても、できるだけ自動的にデータセンター間を移動して最適な実行環境を利用者に提供することにあります。最近のディザスタリカバリに関する研究でも、災害が起きたときにいかにネットワークの経路やデータサイズを判断して、自動的に安全なデータセンターにデータを移動させるといった話題も増えてきています。この文脈でも、レイテンシーや分散と集約の課題は重なる部分があるでしょう。
このように、マルチクラウドやクラウドネイティブの時代に、分散型データセンターを実現するためには、分散型データセンターを薄く繋いだレイヤーを提供する分散型データセンターOSを作っていくこと、そして、予測できないような突発的なアクセス過多や災害、イベントに応じて分散型データセンターを自由に行き来することのできるマイグレーションや状態変化の高速化といった、リアクティブ性を持った実行基盤技術の研究開発が必要になります。
そして、実は既にそのような流れを見越したようなコンテナ実行基盤の基盤技術が作られてきているのです。以下では、Firecracker、gVisor、Kata-containers、Nabla-containersを例にその基盤技術について解説していきます。
コンテナ実行環境の基盤技術
microVMアプローチに分類されるFirecrackerでは、薄いホストOS上に、セキュリティや状態変化の効率性を最大化するために、コンテナが起動に必要な最低限のカーネルの4つの機能（virtio-net,、virtio-block、serial console、a 1-button keyboard controller）だけをロードした軽量VM上にコンテナを起動させるようにしています。このようなコンテナ自体の実行環境はOCIランタイムとしても定義できます。これによって、データセンターにある大量のサーバ上に薄い分散型データセンターOSのようなレイヤーを作り、まるでデータセンター上に大量の軽量VM、つまり、OSの概念でいくと軽量プロセスが起動するような状態を実現することができそうです。しかも、各軽量VMはRESTでコントロール可能であり、かつ、軽量VMは最低限のカーネルの機能しか起動時にロードしないので高速に起動できることから、イベントに応じてリアクティブに状態を変えられると言えるでしょう。
同時にデータセータやサーバに対する収容効率も大幅に上げることができます。なぜなら、高速に状態を変更できるのだから、イベントがあるときだけに起動すれば良く、仕事がない状態では軽量VMは停止状態でも問題ないからです。つまり、同時セッション数の数だけ起動しておけばよく、これまでの、リアクティブ性と対比の意味でのプロアクティブなVMやプロセスの起動では予め収容数だけ起動させておく必要があるのとは、効率性の観点で大きな違いになります。このように、データセンターの集約相当のコストメリットまではいかないにしても、ソフトウェアの観点からデータセンターが分散してもうまくコンテナの高集積化を行うことでコストメリットを高めてくというアプローチにもなるでしょう。
サンドボックスアプローチにおけるgVisorでは、分散型データセンターを覆う薄いホストOS上に、Firecrackerほどカーネルレベルでの分離は行わないものの、よりリソースの効率性や状態変化のリアクティブ性を実現するために、カーネルを共有してサンドボックス環境でコンテナ実行環境を起動させようとしています。サンドボックスアプローチによって、システムコールレベルでの脆弱性があった場合に、それをコンテナ間のプロセスで相互に巻き込まれないようにするといったことができます。一方で、micro VMアプローチと違いカーネルは基本的に共有のため、カーネルが止まると一緒にそのカーネルで動いているコンテナは影響を受けます。まさにこれは、データセンターOSの視点から、OSの概念でいうメモリを共有するという意味でのスレッドにあたるでしょう。
また、FirecrackerをOSにおける軽量プロセス、gVisorをOSにおけるスレッドと呼ぶのであれば、まさに普通のプロセスというアプローチもあります。例えばそれは、コンテナの実行環境を単一のカーネル上に起動させるようなハイパーバイザー的アプローチのKata-containerだったり、コンテナ実行環境とカーネルの境を無くし、まさにコンテナ実行環境の最適化をカーネルレベルでもやってしまい、それによって汎用性を犠牲にできることから、大幅に性能の向上やリソース効率、状態変化のリアクティブ性を実現できるような、かつてはユニカーネルと呼ばれたユニカーネル型アプローチのNabla-containerなどがあります。まさに、これらは分散型データセンターOS上にカーネルを共有しないメモリ空間にコンテナを起動させるという意味で、microVMアプローチが軽量プロセス、サンドボックスアプローチがスレッドであるならば、これらのユニカーネルやハイパーバイザーアプローチはOSの概念におけるプロセスと言えるでしょう。
Windowsでも従来からピコプロセスという仕組みがあって、これは、microVMほどカーネルレベルでの分離はしないにしても、サンドボックス的にシステムコールを監視して、そのシステムコールによってWindowsカーネルと共存しているLinuxカーネルの処理をユーザランドに展開してLinuxのプロセスを立ち上げられるといったことができて、古くからある仕組みであるとはいえ、現在のLinuxのコンテナ実行基盤の技術を色々とうまく使っている仕組みであり、非常に興味深いです。
以上のように、分散型データセンターOSという文脈で、コンテナ実行環境の、状態変化の速度、セキュリティ、リソース分離、高集積化、運用技術あたりの研究開発を進めていこうと思っていますし、そこはもともと僕の博士課程時代にWebサーバという文脈でそれ相当の研究をしてきたので、ここが熱くなっていくことは自然な流れのように感じました。
分散型データセンターOSとリアクティブ性を持つコンテナ実行環境に必要な要素技術
ようやく本題にきました。ここまでの話を簡単にまとめると、今後の時代背景、マルチクラウドやクラウドネイティブ、さらには、スマートハウスやスマートモビリティ、エッジコンピューティング、データ流通といったように、やリアルタイム性の課題、さらには社会にクラウドリソースを使うことでより良いプロダクトが生まれやすくなるであろうことから、クラウド事業者としては、分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術を進めていく時代になるだろうという話をしました。
その中で、今後僕が必要になってくるだろうなと思って開発しているミドルウェアを今日は2つ公開したいと思います。今後はそれらのミドルウェアを開発しつつも、gVisroやFirecracker、nabla-contaienrやKata-containerといった領域の、データセンター収容効率が高く、コンテナ間でカーネルの影響を極力受けないようなセキュリティを担保し、かつ、状態変化が高速なリアクティブ性を持ったコンテナ実行環境のソフトウェアを作っていきたいと思っています。
k2i：分散型データセンターOSのプロセス情報取得
k2iは各OS上で動作しているプロセスの起動状態の情報をHTTP(S)経由でJSONで取得するミドルウェアです。これは、分散型データセンターOSが進んだ際には、ローカルで ps auwx とかtopとかするのではなくて、データセンターOSに対してそれらのコマンドに相当する処理を実現するために、各OS上にk2iさえ起動しておけば、その情報を回収してデータセンター単位でプロセスの状態を取得、解析できるような基盤ミドルウェアです。データセンターOSに対するカーネルのtask_struct的なものと思って頂くと良いかもしれません。
現在でも、特定のサービス基盤に対してconsulなどを使ってそれに近いことをやっているところも多いと思いますが、よりプロセス情報を収集する基盤ソフトウェアとして、各種コマンドやミドルウェア、さらにはOSの管理プロセスなどから情報を取得できるような使い方を想定して開発しています。k2iが高速に情報をHTTP(S)経由でまるっとデータセンター単位で収集できることで、分散型データセンターOSに必要なツールもどんどん開発しやすくなるように思います。最終的には、カーネルパラメータを外からPOSTできるようにしちゃってもいいかな、などと妄想もしていますが、これは今後のデータセンターOSの様子を伺いながら開発を進めていこうと思います。実装はRustで行っています。
middlecon：分散型データセンターOSのプロセス間通信
続いて、もう一つはmiddleconです。これは、これまで実行環境の状態変化に対してリアクティブ性というものがそこまで求められなかったため、キューの処理なども比較的非同期で処理することが選択されてきました。一方で、データセンターOSにおいては、予測できないような突発的なアクセス過多や災害、イベントに応じて分散型データセンターを自由に行き来することのできるマイグレーションといった、リアクティブ性を持った実行基盤技術の研究開発が必要になります。そこで、middleconが解決する問題は、ミドルウェア、コンテナ実行環境、コンテナランタイム、あるいは、OSといったソフトウェアが互いに同期的にメッセージ通信を行うためのソフトウェアです。OSの概念においては、プロセス間通信を想像してもらうと良いかと思います。
上述してきた通り、分散型データセンターOSでは、各コンテナ実行環境（これはコンテナランタイムの文脈ではOCIランタイムと考えても良い）は、OSの概念におけるプロセス、スレッド、軽量プロセスといった役割を果たすと考えられるます。さらに、分散型であるので、できれば中層集権的な実装は極力無くしていくことを考えると、必然的に、プロセス間での通信がOSと同様に必要になってくるだろうと思います。そこで、middleconを色々なOS上で起動させておくことで、コンテナ実行環境間などで高速かつ同期的にメッセージ通信を行うことで、変化に対するリアクティブ性を担保できると良いなと考えています。
MQTTといったメッセージングソフトウェアとの違いとしては、レイテンシーの課題や小型デバイスのための非同期前提の仕組みと違い、データセンターの分散化が進み、レイテンシーが少なくなった比較的信頼性のあるネットワークの状況において、計算機リソースを十分に持つプロセスは同期的かつリアクティブに処理できたほうが都合のよう状況が沢山出てくることを前提としていることです。例えば、オートスケーリングだったり予測できないイベントに反応的な処理を行うといったピタゴラスイッチ的なアプローチです。
一方で、ここについてはk8sを始めとするオーケストレーション層とどう棲み分けしていくかも鍵となりますので、オーケストレーション層がOSとの概念におけるカーネルなのであれば、その処理まで踏み込み過ぎず、コンテナ実行環境間での高速な同期的通信の役割を担うようにする必要があるでしょう。これまた実装はRustで行っています。
まとめ
10分ぐらいで書くつもりがちょっと長くなってしまいましたが、データセンターの分散と集約、そして、データセンター上に展開されるOSやリアクティブ性を持つコンテナ実行環境の将来について、自分の考えを熱く語ってしまいました。このあたりの構想は、k2iやmiddleconの実装も含めて2年前ぐらいから進めていたのですが、色々忙しいこともあって進められず、世界の巨人が続々とこの文脈にも合うようなソフトウェアをリリースしてきたので、非常に悔しい思いをしています。ですが、同時に自分のこういった現状把握からの構想はそれほど時代の流れからずれない、という意味で自信にもなりました。
今後はこの視点で、自身の研究開発を進めていきたいと考えています。また、繰り返しになりますが、こういった分散型データセンターOSを支える基盤技術としてk2iやmiddleconを研究開発していますが、今後はCNCFとも連携しつつ、k8sそのものや棲み分けを意識しながら、gVisroやFirecracker、nabla-contaienrやKata-containerといった領域の、データセンター収容効率が高く、コンテナ間でカーネルの影響を極力受けないようなセキュリティを担保し、かつ、状態変化が高速なリアクティブ性を持ったコンテナ実行環境のソフトウェアを作っていきたいと思っています。
このあたり、一人でやるには色々大変だと思っていたところに、まだコンテナランタイムの自作とかがあまりされていない時期にDockerからそうそうにコンテナの必要機能を切り出してdrootというソフトウェアを開発したりしてきたあの有名な id:y_uuki さんと2月から一緒の職場であり一緒のチームということで、一緒にこの辺も進めていけたら良いなと考えております。
