Dockerコンテナと関連技術をやさしく解説（最終回） | 東京エレクトロンデバイス

Dockerコンテナを開発したDocker社は2022年5月に開催した同社主催イベント「DockerCon 2022」で、Nestybox社の買収を発表しました。Nestybox社はコンテナランタイム「Sysbox」の開発元であり、Sysboxは「次世代runc」と形容されています。 

runcとはDockerコンテナの中核となるコンテナランタイムのことです。そしてDocker社は今後、runcをSysboxに置き換えていくと見られています。Sysboxが優れている点は、コンテナランタイムの分離レベルを上げて、よりセキュアにしているところです。 

本連載の第4回「Dockerコンテナの中身が進化！標準化や堅牢性の実現へ - Dockerコンテナと関連技術をやさしく解説 （その4）」で紹介したように、Dockerコンテナのコンテナランタイムには標準仕様である「Runtime Specification」があり、これを満たしている実装であればどの実装であっても置き換えて使うことができます。そのため、AWSから「Firecracker」、Googleから「gVisor」が登場するなど、よりセキュアなコンテナランタイムが登場しています。 

Docker社もこうしたセキュアなランタイムの提供を実現すべく、今回のNestybox社買収に至ったと考えられます。少なくとも本番環境において、今後はよりセキュアなコンテナランタイムが採用されていくことが大きなトレンドのひとつになると言えるでしょう。 

一方、コンテナオーケストレーションにおいて事実上の標準となったKubernetesにおいては、コンテナオーケストレーションの機能だけでなく、インフラの抽象化や運用の自動化といった機能に対する注目が高まっていきます。 

Kubernetesには、本連載の第5回「Dockerコンテナを普及させた『Kubernetesの重要な役割』とは？ - Dockerコンテナと関連技術をやさしく解説 （その5）」で紹介した、コンテナの数を自動的に維持管理するコンテナオーケストレーションが最も主要な機能として存在しますが、それ以外にもインフラの抽象化や運用の自動化を実現する機能、サーバーレスを実現する機能などへも注目が集まってきています。 

インフラの抽象化機能は、オンプレミスや複数のクラウドを組み合わせて利用するマルチクラウドの実現に使われています。例えばGoogleの「Anthos」はGoogle Cloudはもちろん、オンプレミスやAWS、Microsoft Azureにも対応しています。 

このAnthosには基盤としてKubernetesが用いられており、Anthosにアプリケーションをデプロイすれば、オンプレミスやGoogle Cloud以外のクラウドへもアプリケーションを展開でき、あるいはクロスクラウドで展開するといったことが可能になります。 

これはKubernetesがもともとコンテナを管理する機能によって、その下位レイヤーにある仮想マシンは自動的にアプリケーションから隠蔽されるのに加え、Kubernetes Federation機能を用いることで複数のKubernetesクラウドの構成を容易に管理できること、Kubernetesはコンテナに対してストレージ機能を提供するコンテナストレージインターフェイスも備えているため、コンテナからストレージも隠蔽されるなど、Kubernetesによってインフラが抽象化しやすくなるために実現されています。 

同様に、マイクロソフトもKubernetesを用いてマルチクラウドを実現する機能を備えた「Azure Arc」を提供し、AWSもAmazon Elastic Kubernetes Service（Amazon EKS）と同じKubernetes基盤をAWS以外の環境でも構築し、AWSコンソールから統合管理を可能にする「Amazon EKS Everywhere」をリリースするなど、Kubernetesによるインフラの抽象化を用いたマルチクラウド環境の実現は、大手クラウドベンダーを中心に進められようとしています。 

Kubernetesには、アプリケーションの運用にかかわる操作などをコード化すると、それをKubernetes上で自動的に運用してくれる「Operator」と呼ばれる機能が備わっています。 

Operatorを用いることで、障害発生時のフェイルオーバーやリカバリ、定期的なスナップショットやバックアップの取得、バージョンアップ時のアップグレードなどを含む、運用時のさまざまな操作を自動化できるようになります。 

オラクルはこのKubernetes Operatorの機能を用いてMySQLの運用を自動化する「MySQL Operator for Kubernetes」をリリースしており、さまざまなアプリケーション向けのOperatorを集めた公開リポジトリ「OperatorHub.io」が、Red Hatを中心にAWS、Google Cloud、Microsoft Azureなどの協力によって運営されています。 

このKubernetes Operatorを中心に、今後はKubernetes上のアプリケーションに対する運用自動化がさらに注目され、運用自動化基盤としてのKubernetesの進化も期待されていくはずです。 

そして今後、クラウドネイティブ関連でさらに注目度が高まるであろう技術が「eBPF」と「WebAssembly」でしょう。

eBPFとは、Linuxカーネルのコードを変更することなく、カーネルの持つさまざまな機能をフックすることで、カーネルに対してある種の機能拡張を実現する技術です。

一般にカーネルの機能の変更や拡張を行うには、カーネルのソースコードを書き換え、再コンバイルしなければなりません。そのため、例えばカーネル内のネットワーク関連の機能を拡張してプロトコルやセキュリティを追加したいと思っても、その実現には手間がかかり、簡単に試すこともできません。

eBPFは、これをカーネルの再コンパイルなしで実現する機能です。eBPFを用いることで、Dockerコンテナ間のネットワークをより高速かつ柔軟に実現し、追加のデーモンなどを用いることなくカーネル内のさまざまなメトリクスを収集することで、オブザーバビリティを実現するなど、今後のDockerコンテナとKubernetesのエコシステムにおいて欠かせない技術になりそうです。

WebAssemblyは、もともとWebブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマットとして開発され、現在ではWebブラウザ以外のさまざまな場所でも実行可能になっています。WebAssemblyは高速に起動し、安全に分離した空間内でアプリケーションを実行する機能を備えており、その特長はDockerコンテナが実現するものと似ています。

しかも、DockerコンテナはOSに依存した構造を持つため、Linux版のDockerコンテナとWindows版のDockerコンテナで実行できるアプリケーションには互換性がないのに対して、WebAssemblyはWASI（WebAssembly System Interface）と呼ばれる仕様によって、OSのシステムコールを抽象化することでアプリケーションのクロスプラットフォーム化を実現しようとしている点が、Dockerコンテナよりも優れた点として挙げられています。

Kubernetesのノードとして、Dockerコンテナの代わりにWebAssemblyランタイムを利用できる「Krustlet」の開発が現在進められているように、WebAssemblyをDockerコンテナのように軽量なアプリケーション実行基盤として利用するための開発も進んでいます。

Dockerコンテナの開発者であるSolomon Hykes氏は2019年に「もしもWebAssemblyとWASIが2008年に存在していたら、私たちがDockerを開発する必要はなかっただろう」とツイートしているように、一部のIT技術者の間ではWebAssemblyとWASIがDockerコンテナを置き換えるのではないかといった意見も出始めています。

筆者の見方も、おそらくWebAssemblyはDockerコンテナと並んで軽量なアプリケーション実行基盤となっていくことでしょう。もしかしたらWebAssemblyがDockerコンテナの地位を脅かす可能性さえあるかもしれません。

Dockerコンテナの登場と普及によって、それまでITシステム基盤の主役であった仮想化基盤は少しずつ脇役へと押しやられていった感があります。今後、WebAssemblyとWASIの発展と普及によって、Dockerコンテナが同じような道筋をたどるのかどうか、それがわかるのはこれからまだ数年先のことになるでしょう。