ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

コンテナ技術入門

目次

ITインフラストラクチャに対する柔軟性や迅速性のニーズが高まる中でコンテナ技術が注目されています。アプリケーション開発環境としてだけではなく、インフラの使用効率向上とコスト削減を目的として本番環境における採用も進んでいます。IDCの調査によると日本企業のDocker/コンテナの本番導入率はまだ1割未満と低い値を示していますが、今後は利用用途の拡大とともに、普及することが予想されます[1]。日本市場においてコンテナ技術が急成長する前にコンテナを取り巻く技術要素を紐解いてご紹介します。

VMとコンテナ

ハイパーバイザ型の仮想化はハイパーバイザと呼ばれる専用のソフトウェアによって動作します*1。ハイパーバイザ型のソフトウェアの代表的なものとしては、VMware ESXi、Hyper-V、KVMなどが挙げられます。これらのハイパーバイザは、物理マシン上でCPUやメモリー等をソフトウェアにより仮想的に提供し、物理マシン上で複数の仮想マシン(以降、VMと呼ぶ)を独立して起動することを可能にします。VM上にLinuxやWindowsなどのOSをインストールすることで1台の物理マシン上で複数のVMを起動し、VM内で独立したOSが起動し、必要なアプリケーションを利用することが可能です。これにより、一台の物理サーバーリソースを複数のVMで共有し、利用効率を高めることが可能です。

一方、コンテナ型仮想化はハイパーバイザ型と異なり、ベースとなるホストのLinux OSの上に仮想環境を構築します。VMと大きく異なる点として、コンテナが利用するOSのカーネルはベースとなるホストOSと共有されます。VMの場合は各仮想環境毎にOSをインストールする必要がありますが、コンテナの場合は各コンテナがホストOSのカーネルを利用するため、コンテナイメージはライブラリ/ミドルウェアとアプリケーションのみで構成されます。これにより、コンテナは高速に起動し、非常に軽量に動作させることができ、コンテナイメージが小さいためポータビリティが高いという特徴があります。

*1: これ以外にホスト型仮想化が挙げられます。ホスト型の例としてVirtualBoxなどの仮想化ソフトウェアが挙げられますがハイパーバイザとは動作の仕組みがやや異なります。

図1. ハイパーバイザ型仮想化とコンテナ型仮想化の比較

このコンテナ仮想化を実現するソフトウェアはコンテナランタイムと呼ばれDockerやPodmanがあげられます。コンテナランタイムはコンテナ型の仮想環境を構築し、VMのようにコンテナ同志が互いに干渉しない隔離された空間を作り出すことができます。また、コンテナはコンテナイメージの作成(Build)、コンテナイメージの配布(Ship)、コンテナの実行(Run)という一連のワークフローを一貫して行うための機能が備わっています。では、この隔離されたコンテナ仮想環境をどのように作り出しているのでしょうか?これは、主にLinuxカーネルによって提供されるnamespaceとcontrol group(以降、cgroupと呼ぶ)の2つによって実現されています。

まずnamespaceは、プロセスID(PID)やマウントポイント、ユーザID/グループIDなどOSが扱うリソースをユニークなIDで隔離する機能です[2]。例えば、図2のようにベースとなるホストOSの上でコンテナ1の空間とコンテナ2の空間があるとします。コンテナ2の空間でPID 5番のプロセスを停止(kill)したとしても、各コンテナ内のプロセスは独立したnamespace空間で機能しているため、コンテナ1に存在しているPID 5番のプロセスは影響を受けず動き続けることが可能です。

namespaceには以下の7種類があり、これらの技術によって隔離された仮想環境を作り出しています。

  • Cgroup Namespace:cgroupルートディレクトリを分離
  • IPC namespaces:System V、IPCオブジェクトおよびPOSIXメッセージキューの分離
  • Network namespace:ネットワークデバイス、IPv4およびIPv6スタック、IPルーティングテーブル、ファイアウォールルールの分離
  • Mount namespaces:マウントポイントの分離
  • UTS namespaces:ホスト名の分離
  • PID namespaces:プロセスの分離
  • User namespaces:ユーザIDとグループIDを分離

一方cgroupは、コンピュータに備わる物理的なリソースの制限や割り当て、隔離するための機能です[3]。cgroupの機能を用いることで、コンテナの中で起動したプロセスやスレッドをまとめてリソース制限できます。例として、図2のようにコンテナのリソースを制御することができます。

  • CPU:使用時間、コア数の上限を制御
  • Memory:RAM、スワップ使用量の上限を制限
  • Network:帯域を制御
  • Block I/O:物理 IO の優先順位を制御

図2. namespaceとcgroupによるプロセスとリソース制御

コンテナオーケストレーション

さて、これまでコンテナ技術の基本についてご紹介してきましたが最後にコンテナオーケーストレーターであるKubernetesについて少しだけ紹介させていただきます。

Kubernetesはクラスタ化した複数台のホスト上でコンテナを利用する際の運用管理ツールです。コンテナを活用してアプリケーションを作成する場合、一般的にそれぞれのコンテナには必要最低限の機能だけを持たせるため、Webサーバー用のコンテナ、アプリケーションサーバー用のコンテナなど、1つのアプリケーションが複数のコンテナによって構成されます。このように複数のコンテナが稼働する場合には、以下のような運用課題が出てきます。

  • ホストに対してのコンテナのスケジューリング
  • 障害時の対応
  • コンテナの冗長化、スケール
  • コンテナイメージバージョンアップ

このような課題を解決するのが、Kubernetesです。コンテナの数が少ない場合にはDockerによる運用でも問題ありませんが、コンテナ数が多い大規模なシステムではその恩恵を得ることができるでしょう。

まとめ

今回はコンテナの技術について、ハイパーバイザ型の仮想化とコンテナ型仮想化を比較して紹介させていただきました。その中で、コンテナが独立した空間を作り出す技術やリソースを分配する技術について触れ、最後にコンテナオーケストレーションツールであるKubernetesを紹介しました。次回はこのKubernetesの商用ディストリビューションに関してご紹介いたします。

参考文献

[1]国内でDockerコンテナを本番利用しているのは9.2%。コンテナオーケストレーションツールはKubernetesがデファクト。IDC Japanの調査結果 - Publickey,

<https://www.publickey1.jp/blog/19/docker92kubernetesidc_japan.html>.

[2]namespaces(7) – Linux manual page,

<http://man7.org/linux/man-pages/man7/namespaces.7.html>.

[3] Index of /doc/Documentation/cgroup-v1/,

<https://www.kernel.org/doc/Documentation/cgroup-v1/>.

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND