「Amazon EC2 Container Service」を理解する

Amazon Web Servicesで「Dockerコンテナ」を使うと何がうれしいのか（2/2 ページ）

公開 2015年09月18日 12時01分

[TechTarget]

印刷する

コンテナとECSの使用に伴う問題点

　コンテナはまだ開発途上にある。最も懸念されるのがセキュリティだ。例えばDockerの動作には管理者権限であるrootが必要であり、本来であればrootでしかアクセスできないはずのホスト内のファイルにも、コンテナからアクセスできてしまう可能性がある。

　AWSでは、ユーザーの社内データセンターとAWSのデータセンターとをVPN（仮想プライベートネットワーク）で接続できる「Amazon Virtual Private Cloud（VPC）」が利用でき、かつ仮想ファイアウォールの「セキュリティグループ」を設定できる。そのため、AWSでDockerを利用する場合、Dockerにまつわるネットワークおよびセキュリティの懸念は多少緩和される。とはいえ、rootアクセスのジレンマが解消されるわけではない。VPCは隔離レイヤーとしての役割を果たすだけなのだ。

　ECSはDockerそのものよりも高度なセキュリティ機能を備えているものの、セキュリティ意識の高いクラウドユーザーにとっては不安が残る。またAWSのユーザーは、ECSで利用可能なスケジューラよりもサードパーティー製のスケジューラを好むようだ。言い換えれば、AWSにはセキュリティの分野でまだ課題が残されているということである。

コンテナ技術に関するAWSの次のステップは何か

　AWSが今後どのような方向に進もうとしているのか予測するのは難しい。コンテナの利用で可搬性が高まるのは魅力だが、全ての環境で同一のコンテナを動作可能にするのは、口で言うほど簡単ではないかもしれない。

　DockerのコンテナはVMと同じレベルの隔離を実現することはできない。ただし、VMにコンテナをインストールすることで、リスクは多少なりとも緩和される。

　コンテナの最大の制約が何なのかは、まだ分かっていない。アプリケーションを要素ごとにマイクロサービスとして隔離する仕組みは、アプリケーションの保護に一定の効果はあるものの、まだ安心感よりも不安の方が根強いようだ。

　ECS は、Dockerが利用できる代表的なコンテナ管理サービスだが、改善の余地はある。ECSのリポーティング機能はログ保存だけであり、これはコンテナのスプロール（無秩序な増殖）を引き起こし、余計なコストを発生させる可能性がある。AWSの「AWSマネジメントコンソール」やサードパーティー製のAWS管理ツールを使えば、CPUの利用状況やコストを把握できるものの、いずれにしても監視を怠ると収拾がつかなくなる恐れがある。

　ECSを使い、アプリケーションのデプロイや管理を支援するPaaS「AWS Elastic Beanstalk」を実行すると、問題が発生したという事例も報告されている。コンテナへの注目度が高まる中、ユーザーのニーズの高まりに応えるべく、DockerやAWSはこうした問題に対処していくはずだ。