コンテナ型仮想化のメリット・デメリット
サーバインフラ運用の観点から。
メリット
- 起動が高速なので急な負荷上昇時に迅速にスケールアウトでき、機動的なキャパシティ制御(リソース管理)が可能。ピーク負荷に備えておくために、余分に起動しておくということが不要になり得る。
- ただし、コンテナを載せるホストには常に余剰リソースが必要。
- ローリングリスタートの仕組みが整えばデプロイがより安全になり、楽になり得る。再起動に伴う性能劣化やサービス停止の考慮が不要になるため。
- アプリケーションに応じて graceful restart の仕組みを整えるという手間がなくなり得る。
- OS やパッケージの更新がより簡単に実施できるようになる可能性がある。
- コンテナ側の更新の容易さについては、上記で説明がついていると思う。
- ホスト側の更新もより楽になりそう。
- 理由1) コンテナを別ホストに引っ越すことが簡単にできるシステム構成になるはず。
- 理由2) ホスト側で必要なパッケージは最低限コンテナの起動に必要なものだけになるので、多くのケースでは少なくなるだろう。
デメリット
- 世間的にまだ実績が乏しい。
実は、これ以外に明確な技術的デメリットが思いつかない。
※4/6 追記
…と思ってたら、ひょっとしたらデメリットかもしれないと思えるつぶやきが飛び込んできた。
containers reintroduced the concept of “waiting for the code to compile” to scripting languages by making us wait for the image to be built
— Daisuke Maki (@lestrrat) April 6, 2016
開発側の視点ではあるけれども。
これは一旦さておき、コンテナ型仮想化環境への移行に伴うハードルなら、いっぱい挙げられる。
少し挙げてみる。
- システムが複雑になる
- コンテナを積むホストとコンテナを別々に管理することになる
- ログ収集や監視、デプロイなど仕組みを整える必要がある
とかとか。
これからどうなるでしょうね。