今回はコンテナを検討するタイミングやコンテナのメリット、デメリットについてお伝えします。
■コンテナを検討するべきタイミング
既にサービスを運用していたり、新しくサービスをリリースする時に、以下のような課題や問題点があればコンテナを検討するべきと考えられます。
・サービスの機能やユーザーの利用者数に合わせてシステムの仕様やインフラ・ミドルウェアが大きく変わる可能性がある
・老朽化したシステムをリニューアルしたいが、当時のインフラ担当者は退職しており、そもそも誰も手を付けられない状態になっているが、古い技術を今更学び直そうという人材も居ない
■コンテナを採用する時のメリット
コンテナ技術を用いる事による様々なメリットのうち、導入を検討するにあたって重要だと思った点に絞ってご紹介します。
・公式／非公式を問わず多数公開されているDockerイメージを用いる事により、システムの目的に対して適切な環境構築の手間を削減できる
・開発プロセスとして自身のPCにDockerイメージを起動できるようにすることで、開発者がより本番に近い構成でサービスを開発でき、開発環境の構築手順を削減できる
・開発中に本番に近い構成のDockerイメージで自動テスト・ベンチマークを気軽に行えるため、準備をしておけばより本番に近い構成で自動テストを行える
・アプリケーションのリリースもDockerイメージを前提とする場合、それを支援するアプリケーションやサービスが存在するため、自分でシェルスクリプトを書く必要が無くなり、ケアレスミスを防げる
・サービスの負加増や老朽化の問題に対してサーバーの増強、ミドルウェアのセキュリティアップデートをより低コストに実施できる
・コンテナは旧来のサーバー管理手法（Chef, Ansible等）より簡単なため、運用コストを下げ、信頼性を確保できる
・コンテナを一つのホストマシンに集約する事で、沢山の物理・仮想化サーバーの煩雑な管理から開放されて、よりシンプルな管理手法を導入できる
■コンテナを採用する時のデメリット
インフラに大幅な変更が加わることによって大きなメリットをもたらすとともに、当然として副作用は存在します。
大ざっぱに言うと、「既に稼働しているシステムがあり、インフラに大きな問題を抱えておらず安定した開発・運用が続いているならばコンテナ化するデメリットを考慮するべき」です。
・コストパフォーマンスで見た場合、サーバー単体をフルで活用出来ている場合に比べるとコストが増える可能性がある
・既にオンプレミスで運用している場合、移行に際して構成環境の変化／コストの再試算／運用手順の学習／テストに工数が発生する
・コンテナはクラウドでの運用が前提となるため、要件によってはセキュリティ基準を確保することが難しい場合が存在する
・Dockerという技術が将来流行り続ける保証は無く、継続的に開発を続けるシステムでない場合はコンテナ技術がかえって安定運用の妨げになる可能性がある
■AWSでは、コンテナに関する便利なサービスが展開されています
「コンテナ」を使うと何が出来て、どう変わるのかご理解頂けましたでしょうか。
ざっくり一言で纏めると「開発・運用効率の向上」であり、エンジニアにとっては開発効率を高め・（開発者の）コストを削減するための大きな可能性となっています。
ここでまた問題となるのは、「どこにコンテナを乗せるのか」という話。
コンテナは数多くのマシンをホストOSとして利用できるため、例えばオンプレミス／各社の提供するVPS／EC2インスタンスの上にDockerの環境を整備して、コンテナをホストする基盤として稼働させることも可能ですが、実運用上の問題としてホストマシンの保守、スケーリングに関する管理は発生してしまうので、多くのケースではパブリッククラウドを組み合わせてコンテナを管理・運用しています。
AWSではコンテナをより安全かつ便利に利用するために、EKS／ECS／Fargate等のサービスが提供されております。
それは一体何なのか、また、それらを組み合わせてどのようなサービスが実現できるかについては、別の機会にご紹介させて頂こうと思います。
■まとめ
AWSが年に一度開催する「re:Invent」でもコンテナに関するセッションが日本語で開催される等、クラウドを利用する上でコンテナを活用したサービスの提供は今や当たり前の事となりつつあります。 システム構成について考える時にAWS上でコンテナを活用した構成について検討してみると、より良いサービスが生まれるかもしれません。