Application of ContainerOS in cloud native

クラウドコンピューティングの発展は、3 つの段階に分けることができます。

第 1 段階：スタンドアロンデプロイメントの段階で、デバイス中心のアプローチです。たとえば、Java Web アプリケーションをデプロイする際、通常は 1 台のデバイスのみを使用します。そのデバイスに OS をインストールし、さらに Java JDK や Tomcat などを OS 上にデプロイします。

第 2 段階：デバイスとハードウェアの発展に伴い、従来のデバイス中心の開発からリソース中心の開発へと移行し、クラウドの概念が誕生しました。一般的に、まずパブリッククラウドまたはプライベートクラウドを構築し、その上に仮想マシンリソースを配置してから、Java アプリケーションなどの従来のビジネスをデプロイします。

第 3 段階：情報化の進展に伴い、徐々にアプリケーション中心へと進化しました。たとえば、Java アプリケーションでは従来のサービス形態ではなく、コンテナ化や DevOps ワークフローを用いてアプリケーションを実装するようになりました。クラウドネイティブが現在の主な開発トレンドです。

クラウドネイティブの発展トレンドの中で、OS はどうなるのでしょうか。

まず、従来の OS では、デプロイ時に sshd や Apache ソフトウェアパッケージがインストールされている場合があります。クラウドネイティブシナリオでは、すべてのアプリケーションはコンテナベースです。たとえば、Python アプリケーションでは Python コンテナイメージを使用するケースが多く、基盤となる sshd や Apache パッケージは不要です。これらを削減することで、システムをより軽量にできます。

次に、クラウドネイティブ環境では、K8s クラスター内に数百から数千の OS ノードが存在する可能性があります。運用保守は非常に手間がかかり、アップグレードなどの操作は各マシンで順次実行する必要があります。

さらに、従来の Linux 環境はファイルベースの環境であり、クリティカルなパスやデータを自由に変更できます。クラウドネイティブ環境では、システムをできる限り不変にする必要があり、安定性やセキュリティがより高まります。

従来の OS ソフトウェアは RPM 形式で配信され、アップデート形式でアップグレードされます。ContainerOS のアプリケーションはコンテナイメージの形で利用します。OS のアップグレードは個別のアップデートではなく、OS クラスター全体を一つの単位として変更します。CVE のアップグレードはリポジトリに一度プッシュするだけで、システムはリポジトリ内のパッケージに従って自動的にアップグレードされます。

従来の K8s デプロイは、Kubernetes 公式が提供するデプロイスクリプトやデプロイツールを用いて実施されていました。K8s クラスターのデプロイ後、その上に NGINX や Java などのアプリケーションをデプロイしていました。現在では、Sealer テクノロジにより、アプリケーションを K8s と一体化してパッケージ化しデプロイできます。つまり、K8s のデプロイ後に配信されるのは、純粋な K8s クラスターではなく、K8s + NGINX アプリケーションを含む統合環境です。

フレームワークの最下層にある ContainerOS は、Dragon monitor または Unison の OS をベースに軽量化されたもので、システムをイミュータブル OS として固定化しています。上層レイヤーにはコンテナランタイム関連のコンポーネントパッケージを提供し、さらに上層には K8s クラスターコンポーネントがデフォルトで組み込まれています。

従来の OS から ContainerOS へ変更するには、3 つのステップだけで済みます。既存のポッドを移行し、既存の OS を ContainerOS に置き換え、既存のコンテナアプリケーションのミラーイメージデータを ContainerOS 上の同じデータとして移行することで、ビジネスのスムーズな移行を実現します。

前述の図は、移行前後のアーキテクチャ比較を示しています。移行後も、元のコンテナイメージを K8s クラスター経由でプッシュしたり、コミュニティや Unitrust が提供するイメージを利用してサービスを提供したりできます。

ContainerOS には、クラウドネイティブ環境で以下のようなメリットがあります。

第 1 に、リソース効率の向上です。不要なコンポーネントパッケージを削減することで、リソースをより合理的に活用できます。

第 2 に、アプリケーション利用の利便性です。アプリケーションは従来の RPM パッケージ形式ではなく、コンテナイメージ形式で配信されるため、依存関係の問題が解決されます。たとえば、Python 2 と Python 3 を両方使用したい場合、従来の OS では対応が困難でしたが、ContainerOS では Python 2 用と Python 3 用の 2 つのコンテナイメージを用意するだけで対応できます。

第 3 に、運用保守サービスの利便性です。ゼロ運用保守を推進しています。クラスター内のすべての OS バージョン、ソフトウェアパッケージ、コンポーネント、カーネルが統一されており、追加の設定は不要です。各アップグレードは新しいシステムとして実行されるため、スノーフレークサーバーや個別設定の発生を防ぎます。新しい OS をインストールするのと同じように、よりシンプルに実行できます。

クラウドネイティブシナリオでは、ContainerOS にはより多くの適用シーンがあります。

1. 既存環境の移行と置き換え：従来の OS や K8s クラスターにデプロイされた環境を、ContainerOS + K8s シナリオへ直接移行できます。プライベートリポジトリのコンテナイメージが提供されており、イメージ作成時に CVE 修正やセキュリティスキャンを実行することで、コンテナのセキュリティを向上できます。

2. クラウドベースの変革：クラウドネイティブシナリオでは、開発は K8s を中心に行われます。コンテナクラウドシナリオでは、K8s をコンテナクラウドのコンポーネントとして組み込み、API インターフェイスを提供できます。アップグレード、システムポッドモニタリング、K8s モニタリングなどの機能を、提供された API インターフェイス経由でコンテナクラウドプラットフォームに接続し、より統合された配信を実現できます。

3. プライベートカスタマイズ：ContainerOS を使用して独自の PaaS プラットフォームをカスタマイズできます。たとえば、OA ソフトウェアをコンテナクラウド + OA ソフトウェアの統合 PaaS プラットフォームとして直接提供できます。

前述の図は、クラウド環境でのオペレーティングシステムのパフォーマンステスト結果を示しています。同時実行数とレイテンシが大幅に改善されています。これは主にシステムとカーネルの軽量化により、より多くのリソースが解放された結果です。

クラウドネイティブ時代における ContainerOS の全体的なコンセプトは、運用保守をより簡単にすることです。

動物園の飼育係を例にとると、動物園にさまざまな種類の動物がいる場合、飼育係は各動物の習性を理解する必要があり、管理が困難です。動物園に 1 種類の動物しかいなければ、飼育係の作業は非常にシンプルになります。オペレーティングシステムも同じです。基盤となる OS をすべて 1 つに統一すれば、運用保守やアップグレードがより容易になります。

以上の通り、ContainerOS はクラウドネイティブシナリオにおいて、運用保守からの解放と管理の簡素化に注力しています。