コンテナ化について

コンテナ化とは

コンテナ化とは、オペレーティング・システム（OS）のライブラリーと、コンテナと呼ばれる（任意のインフラストラクチャーで一貫して実行される）単一の軽量実行可能ファイルを作成するためのコードの実行に必要な依存関係のみを含むソフトウェア・コードのパッケージ化です。仮想マシン（VM）よりも移植性とリソース効率の高いコンテナは、最新のクラウドネイティブ・アプリケーションの事実上の計算ユニットになっています。

コンテナ化の導入により、開発者はアプリケーションをより迅速かつ安全に作成およびデプロイできます。従来の手法では、コードは特定のコンピューティング環境で開発されます。そのため、このコードを新しい場所に移して実行すると、バグやエラーが発生することがよくあります。例えば、開発者がデスクトップ・コンピューターからVMへ、あるいはLinuxからWindowsオペレーティング・システムへコードを移した場合などです。コンテナ化を活用すると、アプリケーション・コードを関連する構成ファイル、ライブラリー、さらには実行に必要な依存関係とバンドルすることで、この問題を解消できます。この単一のソフトウェア・パッケージ、つまり「コンテナ」は、ホスト・オペレーティング・システムから分離された結果、単独で動作し、移植できるようになり、任意のプラットフォームまたはクラウド上で問題なく稼働します。

コンテナ化とプロセスの分離の概念は数十年にわたって存在してきましたが、2013年にシンプルな開発者ツールと普遍的なパッケージ化手法を提供するコンテナの業界標準である、オープンソースのDocker Engineが登場すると、このテクノロジーは加速度的に受け入れられるようになりました。今日、組織はコンテナ化をますます使用して、新しいアプリケーションを作成し、クラウド用の既存のアプリケーションをモダナイズしています。最近のIBMの調査（PDF、1.4 MB）では、コンテナ採用者の61％が、過去2年間に構築した新しいアプリケーションの50％以上でコンテナを使用していると報告しています。コンテナ採用者の64％は、既存のアプリケーションの50％以上が今後2年間でコンテナ化されると予想していました。

コンテナは、よく「軽量」であると言われます。これは、コンテナがマシンのオペレーティング・システム・カーネルを共有し、各アプリケーション内でオペレーティング・システムを関連付けるためのオーバーヘッドを必要としないことを意味します。コンテナは本質的にVMよりも容量が小さく、始動にかかる時間も短いため、1つのVMを実行するのに必要な計算能力で、はるかに多くのコンテナを実行できます。これにより、サーバーの効率性を向上させ、サーバーやライセンス交付にかかるコストを削減できます。

おそらく最も重要なことは、コンテナ化により、アプリケーションを「一度作成すればどこでも実行できる」ことです。この移植性により、開発がスピードアップされ、クラウド・ベンダーによる囲い込みが防止され、障害の分離、管理のしやすさ、セキュリティーの簡素化など、その他にも注目すべきメリットが提供されます（以下を参照）。

アプリケーションのコンテナ化

コンテナは、アプリケーション・コードを関連する構成ファイル、ライブラリー、実行に必要な依存関係すべてとともにバンドルした単一の実行可能ソフトウェア・パッケージとして、アプリケーションをカプセル化します。コンテナ化されたアプリケーションは、オペレーティング・システムのコピーをバンドルしていないという点で「分離」されていると言えます。その代わりに、ホストのオペレーティング・システムには、オープンソース・ランタイム・エンジン（Dockerランタイム・エンジンなど）がインストールされます。このエンジンは、コンテナが同じコンピューター・システム上の他のコンテナとオペレーティング・システムを共有するための基盤としての役割を果たします。

他のコンテナ層（共通のバイナリーやライブラリーなど）も、複数のコンテナ間で共有できます。これにより、各アプリケーション内でオペレーティング・システムを実行するためのオーバーヘッドが不要となり、コンテナの容量の縮小、および始動までの時間の短縮が可能となるため、サーバーの効率性向上につながります。アプリケーションをコンテナとして分離することで、1つのコンテナに存在する悪意のあるコードが他のコンテナに影響を与えたり、ホスト・システムに侵入したりする可能性も低くなります。

ホスト・オペレーティング・システムから分離することにより、コンテナ化されたアプリケーションは移植可能になり、任意のプラットフォームまたはクラウド上で一様にかつ一貫して実行できます。コンテナは、デスクトップ・コンピューターから仮想マシン（VM）に、またはLinuxからWindowsオペレーティング・システムに簡単に転送でき、仮想化インフラストラクチャーまたは従来の「ベアメタル」サーバー（クラウド内のオンプレミス）で一貫して実行されます。そのため、ソフトウェア開発者は自分が最も使いやすいツールやプロセスを引き続き使用できます。

企業がアプリケーションの開発と管理に対する優れた手法としてコンテナ化を急速に導入しているのには、しかるべき理由があります。コンテナ化によって、アプリケーションが従来型のモノリス（単一層のソフトウェア・アプリケーション）であるか、マイクロサービス上に構築されたモジュラー・アプリケーションであるかにかかわらず、開発者はアプリケーションの作成とデプロイをより迅速かつ安全に行うことができます。また、クラウド・ベースの新しいアプリケーションを、コンテナ化されたマイクロサービスとして新たに構築して、複雑なアプリケーションを、それぞれが特定の目的に特化した、管理しやすい一連の小さなサービスに分割できます。さらに、既存のアプリケーションを、計算リソースをより効率的に使用するコンテナ（またはコンテナ化されたマイクロサービス）に再パッケージすることもできます。

コンテナ化のメリットの詳細

コンテナ化は、開発者と開発チームに大きなメリットを提供します。以下にその一部を紹介します。

移植性： コンテナにより、ホスト・オペレーティング・システムから分離された（結び付けられたり、依存したりしない）実行可能ソフトウェア・パッケージが作成されます。この結果、コンテナは移植可能となり、任意のプラットフォームまたはクラウド上で一様にかつ一貫して稼働することができます。

俊敏性： コンテナを実行するためのオープンソースのDocker Engineによって、シンプルな開発者ツールと、LinuxとWindowsの両方のオペレーティング・システムで動作する普遍的なパッケージ化手法を提供するコンテナの業界標準が導入されました。コンテナのエコシステムは、Open Container Initiative（OCI）によって管理されるエンジンに移行しました。ソフトウェア開発者は、引き続きアジャイルまたはDevOpsのツールやプロセスを使用して、アプリケーションの迅速な開発と機能強化を図ることができます。

スピード： コンテナは、よく「軽量」であると言われます。これは、コンテナがマシンのオペレーティング・システム（OS）カーネルを共有するため、余分なオーバーヘッドで動きが取れなくなるということがないことを意味します。これにより、サーバーの効率性を向上させることができるだけでなく、ブートすべきオペレーティング・システムがないために、サーバーとライセンス交付にかかるコストを削減できると同時に、始動にかかる時間を短縮することもできます。

障害分離： コンテナ化されたアプリケーションはそれぞれ分離され、他のアプリケーションから独立して動作します。コンテナの1つで障害が発生しても、他のコンテナの継続的な稼働に影響が及ぶことはありません。開発チームは、他のコンテナにダウン時間を発生させることなく、1つのコンテナ内の技術的な問題を識別し、修正できます。また、コンテナ・エンジンは、任意のOSセキュリティー分離技法（SELinuxアクセス制御など）を活用して、コンテナ内の障害を分離することができます。

効率性： コンテナ化された環境で実行されるソフトウェアは、マシンのOSカーネルを共有します。また、1つのコンテナ内のアプリケーション層は複数のコンテナで共有できます。そのため、コンテナは本質的にVMよりも容量が小さく、始動にかかる時間も短いため、1つのVMを実行するのに必要な計算能力ではるかに多くのコンテナを実行できます。これにより、サーバーの効率性を向上させ、サーバーやライセンス交付にかかるコストを削減できます。

簡単な管理： コンテナ・オーケストレーション・プラットフォームは、コンテナ化されたワークロードとサービスのインストール、スケーリング、および管理を自動化します。コンテナ・オーケストレーション・プラットフォームは、コンテナ化されたアプリケーションのスケーリング、アプリケーションの新規バージョンのロールアウト、さらにモニタリング、ロギング、デバッグなどの機能の提供を始めとする、各種の管理タスクを容易にします。おそらく最も人気のあるコンテナ・オーケストレーション・システムであるKubernetesは、本来はLinuxのコンテナ機能を自動化するためのオープンソース・テクノロジーです（最初は、Borgと呼ばれるGoogle社の社内プロジェクトをベースにして、同社によってオープンソース化されました）。 Kubernetesは、Dockerなどの多くのコンテナ・エンジンと連携しますが、コンテナ・イメージのフォーマットやランタイムに関するOpen Container Initiative（OCI）標準に準拠する、あらゆるコンテナ・システムとも連携します。

セキュリティー： アプリケーションをコンテナとして分離することで、悪意のあるコードの侵入が他のコンテナやホスト・システムに影響を及ぼすのを防ぐことができます。さらに、セキュリティー権限を定義することで、不要なコンポーネントがコンテナに入るのをブロックしたり、不要なリソースとの通信を制限したりすることができます。

コンテナ化の種類

コンテナ・ベースのソリューションに対する関心やその活用が急速に高まったことで、コンテナ・テクノロジーやソフトウェア・コードのパッケージ化手法に関する標準が必要となりました。 2015年6月にDockerなどの業界リーダーによって設立されたOpen Container Initiative（OCI）は、コンテナ・テクノロジーに関する一般的で、最小限のオープンな標準と仕様の作成を推進しています。そのため、OCIはオープンソース・エンジンの選択肢の拡大を支援しています。ユーザーは特定のベンダーのテクノロジーにロックインされるのではなく、OCIが認定するテクノロジーを活用し、多様なDevOpsツールを使用してコンテナ化されたアプリケーションを構築して、希望するインフラストラクチャー上で一貫して実行できるようになります。

現在、Dockerは最もよく知られ、広く使用されているコンテナ・エンジン・テクノロジーの1つですが、使用可能な選択肢は他にもあります。エコシステムは、containerdや、CoreOS rkt、Mesos Containerizer、Linux Containers（LXC）、OpenVZ、crio-dなどの代替ソフトウェアを標準とする方向に進んでいます。機能やデフォルトは異なる場合がありますが、これらがOCIの仕様を採用・活用して進化していくことにより、ベンダーに依存せず、複数のオペレーティング・システムで稼働し、複数の環境で使用できるソリューションになります。

マイクロサービスとコンテナ化

今やさまざまな規模のソフトウェア会社が、従来のモノリシックなモデル（ソフトウェア・アプリケーションおよび関連するユーザー・インターフェースと基盤となるデータベースを、単一のサーバー・プラットフォーム上の単一ユニットに統合する）ではなく、マイクロサービスを優れたアプリケーション開発・管理手法として活用しています。マイクロサービスでは、複雑なアプリケーションは、それぞれが独自のデータベースと独自のビジネス・ロジックを備えた、より小さく、より特化した一連のサービスに分割されます。個々のマイクロサービスは、共通インターフェース（APIなど）およびRESTインターフェース（HTTPなど）を介して相互に通信します。マイクロサービスを使用すると、開発チームはアプリケーション全体に影響を与えることなく、そのアプリケーションの特定の領域を更新して、開発、テスト、およびデプロイのそれぞれのプロセスを迅速化できます。

アプリケーションを、移植可能かつスケーラブルで、効率性が高く、管理しやすい、小さなサービスあるいはコンポーネントの集合に変換するソフトウェア開発手法であるという点において、マイクロサービスとコンテナ化の概念は本質的によく似ています。

さらに、マイクロサービスとコンテナ化を一緒に使用するとうまく連携します。アプリケーションが従来のモノリス型であるか、モジュラー・マイクロサービスであるかにかかわらず、コンテナはすべてのアプリケーションの軽量のカプセル化を可能にします。コンテナ内に作成されたマイクロサービスは、開発プロセスおよびベンダー互換性（ベンダー・ロックインなし）における移植性に加えて、開発者の俊敏性、障害分離、サーバーの効率性、インストール/スケーリング/管理の自動化、セキュリティー層などの、コンテナ化固有のメリットをすべて提供します。

今日の通信は、ユーザーが迅速かつ効率的にアプリケーションを開発できるクラウド・ベースへと急速に移行しています。クラウド・ベースのアプリケーションとデータには、あらゆるインターネット接続デバイスからアクセスできるため、チーム・メンバーはリモートでも、移動中でも作業ができます。基盤となるインフラストラクチャーはクラウド・サービス・プロバイダー（CSP）によって管理されるため、企業はサーバーやその他の機器にかかるコストを節減できるだけでなく、自動ネットワーク・バックアップ機能によってより高い信頼性を確保できます。クラウド・インフラストラクチャーは、オンデマンドでスケーリングでき、ロード要件の変化に応じて、コンピューティング・リソース、容量、インフラストラクチャーを動的に調整できます。さらに、CSPは定期的にオファリングを更新して、ユーザーが最新の革新的なテクノロジーにアクセスできるようにします。

コンテナ、マイクロサービス、およびクラウド・コンピューティングは連携して、アプリケーションの開発とデリバリーを、従来の方法や環境では不可能とされていた新たなレベルに導いています。これらの次世代の手法は、ソフトウェア開発ライフサイクルに俊敏性、効率性、信頼性、さらにはセキュリティーをもたらします。その結果、アプリケーションや機能拡張をエンド・ユーザーや市場に迅速にデリバリーできるようになります。

セキュリティー

コンテナ化されたアプリケーションは、分離されたプロセスとして実行でき、また他のコンテナから独立して動作できるため、本質的に一定レベルのセキュリティーを確保しています。真の意味で分離されているため、悪意のあるコードが他のコンテナに影響を与えたり、ホスト・システムに侵入したりするのを防ぐことができます。ただし、コンテナ内のアプリケーション層は、多くの場合、コンテナ間で共有されます。リソースの効率性の観点から見ると、このことはメリットになりますが、他方でコンテナ間での干渉やセキュリティー侵害の発生につながります。また、複数のコンテナを同じホスト・オペレーティング・システムに関連付けることができるため、共有オペレーティング・システムについても同じことが言えます。共通のオペレーティング・システムに対するセキュリティーの脅威は、関連するすべてのコンテナに影響を及ぼす可能性があります。また逆に、コンテナ侵害がホスト・オペレーティング・システムにまで至る可能性もあります。

しかし、コンテナ・イメージそのものはどうでしょうか。コンテナ内にパッケージされたアプリケーションやオープンソース・コンポーネントは、どのようにしてそのセキュリティーを向上させることができるのでしょうか。 Dockerなどのコンテナ・テクノロジー・プロバイダーは、引き続きコンテナのセキュリティー問題に積極的に対応しています。セキュリティーはプラットフォームに本質的に備わっているべきものであり、個別に実装および構成されるべきソリューションではないという考えの下に、コンテナ化では、「デフォルトでの保護（Secure By Default）」の手法が採用されています。この目的を達成するために、コンテナ・エンジンは、基盤となるオペレーティング・システムに固有のすべてのデフォルトの分離プロパティーをサポートします。セキュリティー権限を定義することで、不要なコンポーネントがコンテナに入るのを自動的にブロックしたり、不要なリソースとの通信を制限したりすることができます。

例えば、Linux Namespaceは、各コンテナに対してシステムの分離されたビューを提供するのに役立ちます。これには、ネットワーキング、マウント・ポイント、プロセスID、ユーザーID、プロセス間通信、ホスト名設定が含まれます。 Namespaceを使用して、各コンテナ内のプロセスからこれらのリソースにアクセスすることを制限できます。通常、Namespaceをサポートしないサブシステムには、コンテナ内からアクセスできません。管理者は、シンプルなユーザー・インターフェースを使用して、コンテナ化された各アプリケーションに対し、このような「分離制約」を容易に作成し、管理できます。

研究者は、Linuxコンテナのセキュリティーのさらなる強化に取り組んでいます。幅広いセキュリティー・ソリューションを利用して、企業全体で脅威の検知と対処を自動化したり、業界標準やセキュリティー・ポリシーを遵守するためにコンプライアンスをモニターおよび適用したり、アプリケーションやエンドポイントでの安全なデータ・フローを確保したりできます。

あらゆる規模の組織全体でのコンテナ・セキュリティーをスケーリングするための戦略

について詳細をご覧ください。

仮想化とコンテナ化

コンテナはしばしば仮想マシン（VM）と比較されます。これは、どちらのテクノロジーも、単一の環境で複数のタイプのソフトウェア（LinuxやWindowsベース）を実行できるようにして、有意な計算効率を実現するためです。しかし、コンテナ・テクノロジーは仮想化に勝る重要なメリットを提供するということが分かってきたため、コンテナ・テクノロジーは急速にITの専門家に支持されるテクノロジーとなりつつあります。

仮想化テクノロジーでは、複数のオペレーティング・システムとソフトウェア・アプリケーションが同時に稼働して、単一の物理コンピューターのリソースを共有できます。例えば、IT部門では、WindowsとLinuxの両方を、あるいは1つのオペレーティング・システムの複数のバージョンを、同じサーバー上で複数のアプリケーションとともに実行できます。それぞれのアプリケーションとその関連ファイル、ライブラリー、依存関係（オペレーティング・システム（OS）のコピーを含む）は、VMとしてまとめてパッケージ化されます。複数のVMが1つの物理マシン上で稼働するため、資本、運用、エネルギーのコストを大幅に削減できる可能性があります。

仮想化の概要については、動画「2019年の仮想化」と「仮想化：完全ガイド」をご覧ください。

一方、コンテナ化は、計算リソースをさらに効率的に使用します。コンテナにより、アプリケーション・コードをすべての関連する構成ファイル、ライブラリー、実行に必要な依存関係とともにバンドルした、単一の実行可能ソフトウェア・パッケージが作成されます。ただし、VMとは異なり、コンテナはOSのコピーにバンドルされていません。その代わりに、コンテナ・ランタイム・エンジンがホスト・システムのオペレーティング・システムにインストールされ、コンピューター・システム上のすべてのコンテナが同じOSを共有するための基盤の役割を果たします。

先に述べたように、コンテナはよく「軽量」であると言われます。これは、コンテナがマシンのOSカーネルを共有し、（VMの場合とは異なり）各アプリケーション内でOSを関連付けるためのオーバーヘッドを必要としないからです。他のコンテナ層（共通のバイナリーやライブラリーなど）も複数のコンテナ間で共有して、コンテナの容量をVMよりも小さくし、始動にかかる時間もより短くできます。 1つのVMを実行するのに必要な計算能力で複数のコンテナを実行できるため、サーバーの効率性を向上させ、サーバーやライセンス交付にかかるコストをさらに削減できます。