前回のエントリでは，分散型データセンターOSの背景と概要について述べた．
本エントリでは，さくらインターネット研究所としてのフォーカス領域に基づいて、分散型データセンターOSからさらに踏み込んだ、ユビキタスデータセンター(命名 id:y_uuki )としての目的と解釈を紹介し，その文脈で，各社研究開発しているコンテナ実行環境，すなわち，コンテナランタイムにおけるOCIランタイム（Low-Level runtime）がどのように分類できるかを具体的に整理する．
大規模なデータセンターを建設し，ハードウェアリソースを集約することにより，コストの削減を行うといったような，Googleがデータセンターを立てることのコストメリットや効率化についての研究が過去に報告されてきた*1*2*3． これまでデータセンターの集約化が進んできた中，Webサービスを取り巻くシステムアーキテクチャは抽象化が進んでいる．
例えば，HTTP/2やgRPC*4の実用化に伴い，マイクロサービスアーキテクチャ*5においては，Webサービスにおける各種コンポーネントを小さなサービスとして抽象化し，複数のサービスを組み合わせて大きなシステムを実現している． マイクロサービスによって抽象化を行いながら，全体のシステムも安定化させるためには，マイクロサービス間でのネットワークのレイテンシが重要になってくる．
マイクロサービスのメリットとして，サービスを抽象化かつ疎結合な状態にすることで再利用性を高めながら，1つのマイクロサービスに問題が起きても，マイクロサービス単位でのスケーリングや耐障害性を高める構成をとりやすくなる． 一方で，マイクロサービスアーキテクチャのメリットを最大限享受するためには，マルチクラウドやクラウドネイティブ化*6*7を進め，1つのデータセンターや単一のクラウドサービスに依存しない構成をとる必要がある．
そのため，データセンター事業者としては，巨大なデータセンターを一箇所に集約するよりも，クラウドネイティブの時代に即した，データセンターの分散化を考慮する必要がある． 様々な場所にデータセンターや小さなコンピュータ群を分散して建設、配置することによって，データセンター間やエンドユーザーからアプリケーション起動場所までの物理距離を短縮し，レイテンシーを改善する． そのことによって，場所にも依存しない，より信頼性の高いマイクロサービスアーキテクチャを採用することが可能になる．
ユビキタスデータセンターOSとは
データセンターの分散と集約，そして小さなコンピュータ群が社会や生活に溶け込むようになり、さらには，あらゆるシステム要求に対してクラウドサービスが使われる時代になってくると，データセンターやクラウドサービス利用者にとって，どのデータセンターやコンピュータ群に自分のアプリケーション実行環境が起動しているかは気にせずに利用したい． むしろ，マルチクラウドやクラウドネイティブが進む時代において，データセンターやクラウドサービス利用者がコンピュータの場所を詳細に知る必要があると，利用者にとっては使いづらいサービスになり得る．
今後，データセンター間のレイテンシーの課題を解決することと，予測できない大量のトラフィックに耐えうるデータセンターの構成を取り，コンピュータリソースを適切に管理することが重要である． 我々は，こうした要件と時代背景を考慮して，コンテナ型データセンターだけではなく，より小規模のデータセンター，あるいは，データセンターとは呼べないまでも小型のラック群やコンピュータ群があらゆる場所に分散、溶け込んでいく時代になっていくと考えている． 最終的には、データセンターのいわゆるユビキタス化が進むことによって、もはやデータセンターレスのようであったり、あらゆるものがコンピュータのアシストがあって、Edge/Fogやスマートハウスやスマートモビリティの文脈でもクラウド適用箇所をいかに高速にしてあらゆるものに適用していくかが重要である。前回エントリのビジョンを改めて個々に再掲する。
データセンターをユビキタス化して様々な場所に建設することによって，データセンター間やエンドユーザーからアプリケーション起動場所までの物理距離をさらに短くし，レイテンシーを低減していく． データセンターの分散と集約、そしてユビキタス化、さらには，あらゆる要求においてクラウドが使われる時代になると，どのデータセンターにデータセンターやクラウドサービス利用者のアプリケーション実行環境が起動しているかは抽象化されて隠蔽され，システムの状態に応じて自律的に再構成することが求められる．
データセンターの集約から分散、生活にあらゆるコンピュータが溶け込むユビキタス化が進むと，分散されたデータセンターを抽象化するOSの層，及び，実行環境の高集積化やセキュリティ，性能，リソース管理，運用技術といった課題を解決するための基盤技術がソフトウェアとして必要になる． そのOSの層を，本エントリではユビキタスデータセンターOSと呼ぶ． ここでいうOSとは，複数のデータセンターや生活に溶け込んだ小さなコンピュータ群を抽象化する機能や，抽象化されたデータセンターリソースをプロセスやスレッドのようにみなせるアプリケーション実行環境に割り当てる機能，分散されたデータセンターを透過的にスケジューリングする機能などを意味する．
例えば，Mesos Marathon*8ははやくからこの考えのもとに様々な議論や実装を進めている． また，松本らは，Webサーバの高集積マルチテナントアーキテクチャに関する研究*9を行っており，単一の収容サーバに高集積にホストを収容しながら，いかにセキュリティや性能，リソース管理，運用技術を向上させるかという観点で類似している． 本エントリでは，よりコンテナの実行環境や、データセンターのユビキタス化といった現在の時代背景に合わせて，関連技術を整理する．
ユビキタスデータセンターOSの役割
ユビキタスデータセンターOSの役割は，いつ誰がどこでクラウドを使っても，それがどのデータセンターやコンピュータで動いているかは意識する必要がない． さらに，負荷分散やディザスタリカバリにおいても，できるだけ自動的にデータセンター間を移動して最適な実行環境をデータセンターやクラウドサービス利用者に提供することにある． ディザスタリカバリに関する研究でも，災害が起きたときにネットワークの経路*10やデータサイズ*11を判断して，自動的に安全なデータセンターにデータを移動させる手法が提案されている． この分野においても，レイテンシーや分散と集約の課題は重なる部分がある，
このように，マルチクラウドやクラウドネイティブの時代に，ユビキタスデータセンターを実現するためには，ユビキタスデータセンターを薄く繋いだレイヤーを提供するユビキタスデータセンターOSを検討することが必要である． さらに，予測できないような突発的なアクセス過多や災害，イベントに応じてユビキタスデータセンターを自由に移動できるマイグレーションや状態変化の高速化といった，リアクティブ性を持ったアプリケーション実行基盤技術の研究開発が必要になる．
GoogleやAmazonなど，データセンターを持つクラウドベンダーは，各社アプリケーション実行環境とし，コンテナ実行環境の基盤技術を研究開発している． 以下では，runC*12，Firecracker*13，gVisor*14，Nabla-Containers*15，Kata-Containers*16を例にその基盤技術について整理する，
コンテナ実行環境とは
コンテナ実行環境とは，kubernetes*17を中心とするコンテナオーケストレーションに必要な機能のうち，Open Container Initiative (OCI)の Runtime Specification v1.0.0とImage Format Specification v1.0.0*18に基づいて起動する，コンテナプロセスが実行される環境を意味する． kubernetsと連携してコンテナを実行する機能をコンテナランタイムと呼ぶが，コンテナランタイムは大きく分けてCRIランタイム(High-level container runtime)とOCIランタイム(Low-level container runtime)に区別できる． CRIランタイムはオーケストレーション層からのコンテナに関するパラメータを取得し，Podと呼ばれるコンテナの起動スペースの管理や，コンテナのイメージ管理，その他コンテナの起動に必要な情報をOCIランタイムに渡して指示する機能等を提供する． OCIランタイムはCRIランタイムから受け取った情報に基づいて，ランタイム専用のPodの起動処理や，コンテナプロセスを適切なPod上に起動させる機能等を提供する．
コンテナプロセスは，コンテナが起動するホストOS上のカーネルを共有し，chroot()システムコールやunshare()システムコール等，様々なプロセスの隔離技術を組み合わせることで隔離環境を実現する． そのようなコンテナプロセスをホストOS上に起動する際に，複数のコンテナプロセスはホストOSを共有するために，各コンテナプロセス間でのセキュリティやリソース管理，パフォーマンスを考慮する必要がある．
コンテナ実行環境の分類
コンテナ実行環境の基盤技術は現状以下の5つに分類される．
- プロセス型
- サンドボックス型
- ユニカーネル型
- microVM型
- VM型
プロセス型
(1)のプロセスアプローチは，ホストOS上にcgroup()やunshre()システムコールによって隔離したPodを作成し，Pod内にコンテナを起動させる． これによって，Pod内で起動する単一，あるいは，複数のコンテナは，Podで隔離されたリソースやネームスペース，ネットワークを共有し，さらにコンテナ単位で隔離を行う． そのため，各Podやコンテナは，ホストOSのカーネルを共有することになるため，カーネルに異常が生じた場合は影響を受ける．
OCIがRuntime specificationを準拠した実装として公開しているrunCがこのアプローチに含まれる． 従来のコンテナのプロセス隔離の手法を利用しているため，Podやコンテナを簡単に起動できて，状態の変化も高速である． 一方で，プロセス単位での隔離であり，ファイルシステムやシステムコール等の精緻な制限はしていないため，OSの脆弱性の影響を受けやすい．
サンドボックス型
(2)のサンドボックスアプローチは，(1)のアプローチと同様，コンテナの起動スペースであるPodやコンテナが複数起動した場合，Pod，あるいは，コンテナ間でホストOSのカーネルを共有する． 一方で，サンドボックスアプローチのコンテナは，ユーザー空間上に仮想的に最低限のカーネル環境を構築して，コンテナ上のアプリケーションのアクセス制御を行う． その上で，kubernetsのPodの仕様に基づき，ユーザー空間上に作成された仮想カーネル環境単位でPodが構成される．
例えば，サンドボックスアプローチにおける代表的な実装であるgVisorは，コンテナ上で起動するアプリケーションのシステムコールをsentryとよばれるユーザー空間上のカーネルがptrace*19によって監視する． さらにsentryはseccomp*20によって，ptraceで監視しているシステムコールを制限する． ファイルシステムのアクセスについては，sentryとは別にgoferと呼ばれるプロセスによってアクセス制御を行う． 以上の特徴から，Podの起動やコンテナプロセスの起動は，ユーザー空間上で行われるため，高速に起動できるという特徴がある． 一方で，ユーザー空間上のカーネルやホストOSのカーネルに異常が生じたり，脆弱性があった場合は，複数のコンテナが影響を受ける可能性がある． また，ユーザー空間上でのアクセス制御の影響から，アプリケーションのパフォーマンスやI/O，ネットワーク性能がオーバーヘッドになるという報告もある*21．
ユニカーネル型
(3)のユニカーネル*22アプローチは，ハイパーバイザ上に起動可能なユニカーネルOSのHW仮想化領域を，ユーザ空間におけるコンテナによる隔離技術に置き換えて起動させる． ユニカーネルは本来，単一のアプリケーション専用のカーネルを用意し，起動させるアプローチをとるため，アプリケーション専用の最適化をカーネルに適用できるというメリットがある． 一方で，アプリケーションとカーネルレイヤー間の抽象化や実装が複雑になったり，適切に動作するアプリケーションがユニカーネルの仕様に強く依存する．
例えば，Nabla-Containersは，solo5のユニカーネル実装を採用しており，ユニカーネルのHW仮想化領域をコンテナによる隔離技術に置き換えることで，LinuxホストOS上のユーザー領域にユニカーネルを展開させる． そして，solo5用にビルドされたアプリケーションイメージを使って，アプリケーションをユニカーネル上に起動させる． PodもNable-Containers専用のPodを採用し，ユニカーネルであるsolo5単位でPodを作成し，Pod内でコンテナを起動させる． そのため，Podもコンテナの起動もユーザー領域のカーネルの起動となるため高速に起動する． また，ユニカーネルとホストOSの境界では，システムコールを7個まで制限しており，Horizontal Attack Profileの観点で，他のランタイムよりもセキュアであるという方向もある*23．
microVM型
(4)のmicroVM*24アプローチは，ホストOS上に，セキュリティや状態変化の効率性を最大化するために，コンテナが起動に必要な最低限のカーネルの4つの機能（virtio-net，virtio-block，serial console，a 1-button keyboard controller）だけをロードした軽量VM上にコンテナを起動させる． そのため，Podは高速かつ軽量に起動するmicroVM上で区別され，コンテナはmicroVM上に起動する． コンテナ，あるいは，Pod単位でmicroVMを起動する必要があるが，コンテナの起動に必要な最低限のカーネルの機能のみをロードするため，VMでありながら状態の変更が高速であるという特徴がある．
例えばFirecrackerは，microVMアプローチによるハイパーバイザを実現しており，microVM単位でPodを構成し，Pod内ではOCIにより実装され広く使われているruncによってコンテナを起動する． Firecrackerはsnapshotterとruntimeで構成されている． runtimeによって，microVMを管理するVMMとmicroVM内のagentが連携してruncを操作し，Podやコンテナを制御する． また，snapshotterはmicroVMで動作するコンテナイメージを作成する． snapshotterはブロックデバイスとしてイメージファイルを作成し，イメージファイルを介してmicroVMにパススルーする． FirecrackerのVMMは，RESTでリモートから操作可能になっている．
VM型
(5)のVMアプローチは，PodをVM単位で構成する． そのため，Podを起動させるためには，VMを起動させる必要があり，起動に時間がかかる． 一方で，OpenStackを始めとする従来のVMオーケストレーションやVMの資産を利用することができるため，OSレイヤでの専用の修正が必要なく，シンプルで利用しやすい． また，Pod単位でVMが分離されるため，従来のVMの隔離程度のセキュリティを容易に確保できる． これまでのハイパーバイザやVMの資産を活用できるため，Podさえ起動してしまえば，他のアプローチと比べてもCPUやメモリ，ネットワーク性能は非常に高い*25． Kata-Containersはまさにこのアプローチを採用している． また，Kata-Containersで扱うPodはVMであれば良いので，(4)アプローチのFirecrackerのVMMと連携してPodを起動するという実装も報告されている*26．
Windowsでも従来からピコプロセス*27*28という仕組みがある． ピコプロセスは，microVMほどカーネルレベルでの分離はしないが，ユニカーネルアプローチのようにライブラリOSを採用し，専用のアプリケーションイメージを実行しながらシステムコールを監視して，そのシステムコールによってWindowsカーネルと共存しているLinuxカーネルの処理をユーザランドに展開し，Linuxのプロセスを立ち上げられる．
リアクティブ性の高いコンテナ実行環境の必要性
これまでは，Webアプリケーションは事前にプロセスやインスタンスを起動させておき，大量のアクセスが想定される場合は予め複数台のインスタンスを起動させておく方式が広くとられていた． しかし，多種多様なWebサービスやスマートフォンを始めとする大量のクライアントが人々の生活に強く依存し，SNSが広く普及したことから，事業者は大量のアクセスや変化を予測することが困難になっている． そこで，クライアントからのSMTP接続やHTTPリクエストのようなセッション契機でリアクティブにコンテナの状態を変化させることにより，収容サーバに高集積にコンテナを収容しながらも，突発的なアクセスに対して適応的にスケーリングする研究がされている*29． また，各種クラウドベンダーではサーバレスアーキテクチャに基づいて，AWS lambda*30をはじめとする各種サービスが提供されている．
ホストOSとPod，コンテナ，および，それらを制御するオーケストレーション層は，ユビキタスデータセンターを覆うかのようなOSとみなせる． そのような分散型データセンターOSの観点で，よりリソースの効率性や状態変化のリアクティブ性を実現するためには，カーネルを共有してサンドボックス環境でコンテナ実行環境を起動させる方法をとればよい． (2)のサンドボックスアプローチは，ユーザ空間に仮想的にカーネルを構成し，システムコールレベルでの脆弱性があった場合に，コンテナ間のプロセスで相互に影響を受けない. 一方で，(4)のmicroVMアプローチと違いカーネルは基本的に共有のため，コンテナが動作しているカーネル本体が停止すると，そのカーネルで同様に動いているコンテナは影響を受ける． まさにこれは，データセンターOSの視点から，OSの概念でいうメモリを共有するスレッド上で，複数の軽量スレッドを仮想的に生成するという意味で，軽量スレッドであるといえる． また，(3)のユニカーネルアプローチのように，ホストOSのカーネルを共有しながら，(2)のサンドボックスアプローチのアクセス制御よりも，従来のユニカーネルの資産を利用して，ユニカーネル専用のアプリケーションイメージを採用し，より厳密なアクセス制御を行うアプローチは，ホストOSのカーネルを共有していることからも，スレッドとみなせる．
microVMアプローチに分類されるFirecrackerでは，データセンターにある大量のサーバ上に薄いユビキタスデータセンターOSのようなレイヤーを作り，まるでデータセンター上に大量の軽量VM，つまり，OSの概念でいくと軽量プロセスが起動するような状態を実現することができる． 各軽量VMはRESTでコントロール可能であり，かつ，軽量VMは最低限のカーネルの機能しか起動時にロードしないので，AWSの報告*31によると，125ms程度で高速に起動できることから，イベントに応じてリアクティブに状態を変えられる． 一方で，コンテナランタイム環境が高速に起動できたとしても，コンテナ上で起動するWebサーバ等のミドルウェアが高速に起動できないという課題もある． 松本らは，コンテナ上で起動するサーバプロセスを，予め起動完了直後でCRIU*32によってイメージ化しておくことにより，Apache httpdで起動を900msec程度高速化することに成功している*33． まさにmicroVMアプローとは，ユビキタスデータセンターOSにおける軽量プロセスとみなせる．
(1)(2)(3)(4)のアプローチは，同時にデータセンターやサーバに対する収容効率も大幅に上げることができる． コンテナの起動をはじめとした状態を高速に変更できることは，イベントが生じたときだけ起動すればよく，イベントがない状態では停止状態が許容されることを意味する． つまり，同時セッション数の数だけ起動しておけばよく，これまでのプロアクティブなVMやプロセスの起動で，予め収容数の数だけ起動させておく必要があるのとは，効率性の観点で大きな違いが生じる． このように，データセンターの集約相当のハードウェアコストのメリットを活かすために，ソフトウェアの観点からデータセンターが分散してもコンテナの高集積化を行うことでハードウェアコストのメリットを高めてくというアプローチにもなる．
コンテナ実行環境におけるmicroVMアプローチを分散型データセンターOSにおける軽量プロセス，ユニカーネルアプローチをスレッド，サンドボックスアプローチを軽量スレッドとみなすのであれば，コンテナの実行環境を単一のVM上に起動させるVMアプローチは，ユビキタスデータセンターOS上にカーネルを共有しないメモリ空間にコンテナを起動させるという意味でプロセスとみなせる． また，ユビキタスデータセンターOS上におけるuid/gidなど，認証や権限の考え方についても検討する必要があるが，本エントリでは言及しない．
つまり，ユビキタスデータセンターOSにおいては，これらのプロセスや軽量プロセス，スレッドや軽量スレッドを状況に応じて自由に使い分けられるようなプラットフォームを目指すことが理想的である．
まとめ
以上のように，今回はユビキタスデータセンターOSの概要と，関連するコンテナ実行環境技術を分類して整理した． 次回は，この整理に基づいて，ユビキタスデータセンターOSに必要な要件や設計について述べていきたい．
*1:Barroso L A, Hölzle U, The case for energy-proportional computing, Computer, Vol.40, No.12, pp.33–37, 2007.
*2:D Abts, M R Marty, P M Wells, P Klausler, H Liu, Energy proportional datacenter networks, SIGARCH Computer Architecture News, Vol.38, No.3, pp.338-347, June 2010.
*3:Barroso L A, Clidaras J, Hölzle U, The datacenter as a computer: An introduction to the design of warehouse-scale machines, Synthesis lectures on computer architecture, Vol.8, No.3, pp.1-154, 2013
*4:gRPC, https://grpc.io/
*5:Fowler M, Lewis J, Microservices. http://martinfowler.com/articles/microservices.html
*6:Balalaie A, Heydarnoori A, Jamshidi P, Microservices architecture enables devops: Migration to a cloud-native architecture, IEEE Software, Vol.33, No.3, pp.42-52, 2016.
*7:千葉立寛, クラウドネイティブ時代に振り返るコンテナのこれまでとこれから, 情報処理, Vol.59, No.11, pp.1022-1027, 2018年.
*8:Mesosphere, Inc., Marathon: A container orchestration platform for Mesos and DC/OS, https://mesosphere.github.io/marathon/
*9:松本 亮介, Webサーバの高集積マルチテナントアーキテクチャに関する研究, 京都大学博士(情報学)学位論文, https://repository.kulib.kyoto-u.ac.jp/dspace/handle/2433/225954, 2017.
*10:江戸麻人，和泉諭，阿部亨，菅沼拓夫:災害リスクを考慮 したネットワークの経路制御手法の提案と評価，電気学会論文誌C，Vol.137, No.3, pp.532-541 2017年.
*11:Ma L, Su W, Wu B, Taleb T, Jiang X, Shiratori N, ε-time early warning data backup in disaster-aware optical inter-connected data center networks, IEEE/OSA Journal of Optical Communications and Networking, Vol.9, No.6, pp.536-545, 2017.
*12:CLI tool for spawning and running containers according to the OCI specification, https://github.com/opencontainers/runc
*13:Firecracker: Secure and fast microVMs for serverless computing, https://firecracker-microvm.github.io/
*14:gVisor: Container Runtime Sandbox, https://github.com/google/gvisor
*15:Nabla containers: a new approach to container isolation, https://nabla-containers.github.io/
*16:Kata Containers - The speed of containers, the security of VMs, https://katacontainers.io/
*17:The Kubernetes Authors, kubernetes: Production-Grade Container Orchestration, https://kubernetes.io/
*18:Open Container Project, The Open Container Initiative, https://www.opencontainers.org/
*19:Pradeep Padala, Playing with ptrace, Part I, Linux Journal, Vol.2002, Issue.103, p5, 2002.
*20:SECure COMPuting with filters, https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
*21:Xu Wang, Kata Containers and gVisor: a Quantitative Comparison - OpenStack, KubeCon CloudNativeCon North America 2018, https://www.openstack.org/assets/presentation-media/kata-containers-and-gvisor-a-quantitave-comparison.pdf
*22:Madhavapeddy A, Mortier R, Rotsos C, Scott D, Singh B, Gazagnaire T, Smith S, Hand S, Crowcroft J, Unikernels: Library operating systems for the cloud, SIGPLAN Not, Vol.48, No.4, pp.461–472, Mar 2013.
*23:Aravena R, Bottomley J, Container Security & Multi-Tenancy Tales from Kata & Nabla, KubeCon CloudNativeCon North America 2018, https://schd.ws/hosted_files/kccna18/20/Container%20Security%20and%20Multi-Tenancy%20Tales%20from%20Kata%20and%20Nabla.pdf
*24:Ogel Frédéric, THOMAS Gaël, FOLLIOT Bertil, Supporting efficient dynamic aspects through reflection and dynamic compilation, Proceedings of the 2005 ACM symposium on Applied computing, pp.1351-1356, 2005.
*25:Xu Wang, Kata Containers and gVisor: a Quantitative Comparison - OpenStack, KubeCon CloudNativeCon North America 2018, \url|https://www.openstack.org/assets/presentation-media/kata-containers-and-gvisor-a-quantitave-comparison.pd
*26:Ernst E, Kata Containers 1.5 release, \url|https://medium.com/kata-containers/kata-containers-1-5-release-99acbaf7cf34
*27:J Howell, B Parno, J R Douceur, How to run POSIX apps in a minimal picoprocess. In 2013 USENIX Annual Technical Conference, pp.321–332, June 2013
*28:A Baumann, M Peinado, G Hunt, Shielding applications from an untrusted cloud with haven. In USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2014.
*29:松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技術シンポジウム2017論文集，2017，89-97（2017-11-30）, 2017年12
*30:Amazon Web Services: Lambda, https://aws.amazon.com/lambda/
*31:Firecracker – Lightweight Virtualization for Serverless Computing, https://aws.amazon.com/jp/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/
*32:CRIU -- A project to implement checkpoint/restore functionality for Linux, https://criu.org/
*33:松本亮介, 近藤宇智朗, 栗林健太郎, CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法, 研究報告インターネットと運用技術（IOT）, Vol.2018-IOT-44, pp.1-8, Mar 2019.
