コンテナ超入門！特長やメリットから、AWSの関連サービスまで理解する

コンテナが注目されている理由、それは「アプリケーションを動かす環境を管理するのが面倒すぎるから」ということでしょう。アプリケーションを動かすには、実際に開発した「ソースコード」のほかに、それを動かすための「ランタイム」が必要です。さらに最近はいろいろな「ライブラリ」を使っているケースも多いはず。これらのバージョンなどが正しくないと、想定したとおりに動かなかったりするわけですね。

そして、アプリケーション開発では、ローカルの開発環境、テスト用の検証環境、本番環境と複数の環境があるのが普通です。すると、なぜか「検証環境と本番環境のランタイムのバージョンが違う」「ローカルで動いたものが検証環境で動かない」ということが起きる。そう、それも結構な頻度で起きたりするわけです……（遠い目）。

というわけで、この問題の解決策として登場したのがコンテナ。アプリケーションを動かすために必要な、ランタイム/エンジン、依存ライブラリ/パッケージ、アプリケーションコードをすべてコンテナのなかにまとめて運べば、環境に依存しないで動くじゃん！ということですね。なにそれ素敵すぎる。
ちなみに、コンテナのなかに敢えて入れないものが「設定」です。当然ですが、設定値は環境ごとに異なるもの。これをコンテナに入れちゃうと結局また環境ごとにコンテナを作ることになってしまうので、それはやめようということですね。

アプリケーションに必要なコンポーネントをコンテナ化

そして、コンテナ周りでよく聞くのがDockerとKubernetesの2つです。どちらもオープンソースのソフトウェアで、デファクトスタンダードと言っても過言ではないでしょう。
……と言いつつ、なにができるのかイマイチよく分からないこの2つ。まずDockerから見ていきましょう。Dockerは、上で説明した「コンテナ」そのものを実現するためのもの。サーバやローカルPCなどでDockerエンジンを実行しておけば、そのうえでコンテナを作成して動かすことができる。つまり、ローカルPCで作ったDockerコンテナをそのままサーバ環境にもっていけば、同じように動く、ということです。イチイチ環境ごとにPythonとかのランタイムをインストールする必要がなく、バージョン違いに泣くこともない。素敵な仕組みですね。

ただし、Dockerではサーバごとに「必要なコンテナを用意して」「実行する」必要があります。サーバの台数が少なければいいですが、規模が大きくなると延々これを繰り返す羽目になります。そして！繰り返し作業をなにより嫌うのがエンジニアというもの！（極論）

そこで登場するのがKubernetesです。Kubernetesはコンテナ管理を自動化するための「コンテナオーケストレーションツール」。たとえば、どのコンテナイメージを何台実行するかを指定すると自動で配置してくれたり、リソース不足などの際に自動でスケールしてくれたりするので、かなり便利になります。
どちらについても、かなりざっくりとした説明ですが、なるほどそれは便利だよねと大流行の理由はわかったような気がします。

では、いよいよAWSでのコンテナ関連サービスをみていきましょう。いろいろありますが、今回は独断と偏見に基づいて3つをピックアップ！

まずはAmazon Elastic Container Service（Amazon ECS）です。AWSでコンテナ、と考えたときに最初に使う候補になるサービス、と言えるでしょう。これはコンテナのオーケストレーションサービスで、要するにKubernetesと同じポジションに当たります。AWS上で稼働させるDockerをAmazon ECSが管理してくれる、ということですね。「6つのEC2インスタンスに対して、コンテナを実行する。コンテナは3つのAZに分散させて、同時に10個実行して、ロードバランサ―につなぐ」という指示をすると自動でやってくれる、という代物。Kubernetesでも同じことができますが、Amazon ECSはAWSのネイティブなサービスなので、ほかのAWSサービスと連携しやすいことが特長。また、機能がシンプルで使いやすく、コンテナ活用の第一歩としておすすめ、ということのようです。

そして、2つ目はAmazon Elastic Kubernetes Service（Amazon EKS）。そう、Kubernetesをマネージドで使えるサービスです。Amazon ECSがあるし、同じことをできるのでは……？という疑問がわきますが、Kubernetesはより細かく、高度な運用ができることが特長（その分、運用が難しいとも言う）。豊富な機能をもつKubernetesをAWS上でも使いたい、でもKubernetesそのものの管理や運用は面倒くさい、というニーズに応えるのがAmazon EKSです。AWSとの親和性、という観点だとAmazon ECSに軍配があがるかもしれませんが、逆に、Kubernetesはオンプレミスを含めた多様なリソースに対応していることが強み。このあたりは自社の環境や運用体制などにあわせて使い分けたいというニーズがありそうです。

そして最後は、AWS Fargateを紹介します。これは、コンテナを実行する環境運用を自動化するサービスです。コンテナを実行するには仮想マシンが必要なので、AWSだとEC2インスタンスを必要なだけ用意することになります。となると、このEC2インスタンスの運用管理も必要になります。つまり、セキュリティパッチをあてたり、足りなくなったら増やしたり、異常が発生したら違うマシンを用意したり。……面倒ですね、はい。そこで！これを全部おまかせできるのがAWS Fargate、ということです。

AWS FargateはAmazon ECS、Amazon EKSのどちらからでも利用でき、コスト的にもAWS Fargateは2019年1月に50％（！）の値下げをしていて、かなりハードルが下がっています。コンテナをスタートするならば、まずはAmazon ECSとAWS Fargateの組み合わせを検討するのがよさそうです。

今回のコラムで紹介したのは、各サービスの機能もごくごく一部にすぎません。セッションではほかにもAmazon EKSでデータプレーンの管理を実現する「Amazon EKS Managed Node Groups」や、コンテナのイメージを管理するイメージレジストリ「Amazon Elastic Container Registry（Amazon ECR）」が紹介されていました。正直、すべてのサービスをきちんと理解できたとは思えませんが、セッションを聞いていても、これは便利なんだな、使いこなせたら相当楽になるんだろうな、一定規模以上のシステムだったら使わない選択肢はないよな、と思いました。AWSなどクラウドの普及もありますが、システムを支えるインフラはどんどん複雑化しています。分散化や冗長化のほか、負荷にあわせてスケールするのも当たり前になってきました。これ、全部人力で管理するのは、無理がありますよね。コンテナ、流行るワケです。

ちなみに、ソニービズネットワークスのマネージドクラウド with AWSで標準提供する管理ツール「クラウドポータル」でもAmazon ECSに対応しておりまして、Amazon ECSだと消えていってしまうログを保存して検索できたりと、効率的な管理をサポートする機能を提供しております。え、それどういうこと？ちょっと詳しく聞かせてくれる？など疑問・質問がありましたら、ぜひぜひお気軽にお問い合わせください。
以上、シイノキでした！