コンテナが開発者と運用担当者にもたらすメリットとは？

一方、運用担当者のメリットとしては「本番環境とステージング環境の差異を軽減できる」「柔軟かつ迅速なスケーリングでコストを最適化できる」「マイクロサービス単位での管理が可能になる」が挙げられる。

本番環境とステージング環境の差異を軽減できる

前述したように、コンテナイメージは共有が容易である。この特徴により、ステージング環境で動作することを確認できたら、動作確認済みのコンテナイメージを本番環境に持っていくこともまた容易である。

また、コンテナはリソース利用効率が良いため、仮想マシンではコスト観点で本番環境とステージング環境を同一に出来なかった場合でも、コンテナを活用すると2つの環境の状態をより近づけることが可能になる。

柔軟かつ迅速なスケーリングでコストを最適化できる

コンテナで開発スピードの高速化を実現するには、コンテナにデータや状態を持たせない(ステートレス)ようにする、すなわち、コンテナの「儚い使い方」が重要になる。

コンテナがステートレスであることは、運用担当者にもメリットをもたらす。ステートフルな仮想マシンで運用していると、リソースが不要になり仮想マシンを削除する際に(スケールイン)、データ移行を行わなくてはならない。このため、不用意に仮想マシンを削除できず、常にアクセスピーク時の負荷を見越した性能を担保しておかなくてはならない。

コンテナの場合、ステートレスであるためスケールイン時にデータ移行のことを考えなくてよい。恐れずスケールインができるため、その時々に必要な性能分のコンテナを稼働させることが容易になる。また、コンテナは仮想マシンと比べ、少ないリソースで展開できることも見逃せないポイントだ。

以上のことから、コンテナを活用するとシステムのリソース使用率とコストを最適化することができる。

マイクロサービス単位での管理が可能になる

コンテナの特徴を最大限活用しようとすると、自然とシステムはマイクロサービス単位で管理されるようになっていく。

マイクロサービスとは、個別に開発された小さなサービスとして必要な機能を実装し、それら小さなサービスをWeb APIなどで連携させることにより、1つの大きなサービスを実現するソフトウェアアーキテクチャである。これに対し、必要な機能を1つの実行バイナリに詰め込んで実現したサービスをモノリシックなサービスという。

モノリシックなサービスの場合、特定機能のアップデートが発生した時、その他の機能もアップデートの影響を受けてしまう。また、特定機能のみを負荷分散のために拡張したいときにも、その他の機能も一緒に拡張しなければならない。マイクロサービスではそうしたデメリットがなく、サービスと機能が一対一対応するようになるため機能のアップデートや性能拡張などの運用が容易になる。

なお開発者にとっても、マイクロサービスによって機能が小さなサービスとして分解されていることは、担当/責任範囲を明確にするメリットがある。

本連載を初回から今回まで読まれた方は「コンテナとは何か」「どんな特徴があるのか「どんなメリットがあるのか」を理解いただけたことだろう。そんな便利なコンテナではあるが、一体OSのどんな機能・仕組みを利用して作られているか気にはならないだろうか?

そこで、次回はコンテナがOS(カーネル)のいかなる仕組みを使って作られているのか、解剖していくことにする。