コンテナ型仮想化(Docker)

コンテナ型仮想化は古くからある技術だが、ここではDockerの説明をする。 OSの上にコンテナがあり、その中でOSイメージが動くという形は従来のハイパーバイザ型の仮想化と似ているが、従来とは比較にならないくらい軽量で、可搬性に優れることが特徴である。

従来の仮想マシンとの違い

VMwareなどのハイパーバイザ型の仮想化は、物理サーバでリソースが余っている部分を有効活用することが大きな目的の一つだった。環境の作成にもメモリの大きさやNICなどハードウェアを意識することが特徴で、「ハードウェアの仮想化」と言われる。 (難しければ、「仮想マシン」という表現を見かけたらこっちだと思っといてください)

対して、コンテナはホストのOSカーネルを共有し、不要なものをそぎ落として軽量化を追求している。そのため「OSの仮想化」と言われる。 Dockerに関していえば、全てのLinuxとMac、Windows、AWS、GCP、Azureなどで、同じように動作する。ハードウェアの構成を意識する必要はなく移植可能。そのため可搬性が非常に高い。

コンテナの軽量化の仕組み

ミニマム構成のOSイメージを基にしているため、そもそも必要最小限の構成であることが大きい。 また、コンテナを複数作成した場合、ファイルを一部共有するためさらに軽くなる。 ただし、Linuxで動作することを前提に作られているので軽量化の恩恵を最大限に受けるためにはLinuxに導入するのが良いとされる。

デメリット

頻繁に更新する環境には向かず、使い捨てもしくは変更発生時にコンテナ再作成しても差し支えないサービスに向いてる。常時稼働させなければならないサービスに使うにはかなりの工夫が必要。やはり、仮想化が進むと物理ほどの安定や堅牢さを保つのは難しい。 構築したコンテナはバージョン管理の観点からもDockerFileで行うべきで、作成後のコンテナを編集するのは微妙である。なぜなら、Dockerの利点である再構築の容易さを損なうことになるし、ミニマム構成のOSイメージには構築に必要なコマンドも揃っていない。 手動でメンテナンスを行うために、諸々ダウンロードすると今度は軽量性までも損なわれる。

このように、縛りのある使い方を要求される。うまくはまると良いのだが、日本企業の場合は従来の運用ルールを曲げるハードルの高さがありそうだ。

インフラ的には

クラウド基盤もそうだがコンテナも、アプリとインフラが融合している所感がある。 というのは、従来のようにサーバを作って開発側に引き渡してから完成、というものではなく、完成物の設計をDockerFileに書く必要があり、開発側で必要となるものをヒアリングして管理しなければならない。 そのため、導入するならインフラ側だけでなくアプリ領域に踏み込むことを覚悟する必要がある。