Feedforce Developer Blog

フィードフォース開発者ブログ

AWS でコンテナを動かすためのサービスまとめ

こんにちは、バックエンドエンジニアの tsub (id:tsub511) です。

本日 AWS Re:Invent 2017 でコンテナ実行環境として新たに AWS Fargate と Amazon Elastic Container Service for Kubernetes (EKS) が発表されました。

昨日は発表が待ち遠しくて気が気じゃなかったですが、無事に予想通りマネージド Kubernetes サービスが発表されて大喜びです。

今回は AWS でコンテナを扱う上で、今までのサービスと合わせて選択肢がいくつかあって混乱すると思うので簡単にまとめました。

AWS でコンテナを動かすためのサービス

新しく 2 つのサービスが追加されたことで、これだけあります。 (見落としがなければ)

それぞれの特徴について説明していきます。

Amazon Elastic Beanstalk (EB)

※ EB については自分は全く触ったことがないので分からないままで書きます。

EB は Heroku のような PaaS です。 本来は Heroku と同じようにアプリケーションのコードをそのままデプロイして動かしますが、Docker もサポートしていて、コンテナとしてデプロイして動かすことができます。

小規模なサービス、チームなどでインフラの管理をしたくないというユースケースで使うことが多いと思います。

Amazon Elastic Container Service (ECS)

ECS は AWS が独自に開発しているマネージドなコンテナのオーケストレーションサービスです。 (コンテナのオーケストレーションについては おまけ: コンテナのオーケストレーションについて を参照)

EC2 の上で ecs-agent を動かすことで、ECS のクラスタとして認識させることができるため、非常にシンプルです。 ecs-agent が動いていれば、ECS を通して EC2 の上でコンテナを簡単に動かすことができます。

ECS 向けに awslogs という Docker 用の logging driver を提供していて、CloudWatch Logs との連携も簡単に行えます。

ECS 上でのコンテナは、ECS Task や ECS Service として動かします。 ECS Task には IAM Role を使った権限管理や VPC ネットワーク上で直接 Task を動かすことができ、セキュリティグループなどを利用することもできます。

ECS Service は ELB との連携があり、コンテナが起動したら自動的に ELB に紐付けたり、コンテナが終了したら ELB から外したり、といったことをやってくれます。

上記のように、他の AWS サービスとの連携がスムーズにできる点は非常に魅力的です。

AWS Batch

Batch はコンテナを使ったバッチコンピューティングに特化したサービスです。

バッチコンピューティングと言っても、決まった時間に決まった処理をするという cron のようなものではなく、 機械学習やスーパーコンピュータなどで利用するような大量の計算処理を必要とする場合に利用されるような基盤となります。

そういう背景もあり、主に CPU ベースでのコンテナの割り振り、ホストのオートスケーリングなどに強いです。

また、Batch はバックエンドで ECS を使っており、ジョブを動かすと実際に ECS Cluster が作られその上で Task が動いている様子を見ることもできます。 ECS を使っていることもあり、ログは自動的に awslogs logging driver によって CloudWatch Logs に送られたり、CloudWatch による ECS のメトリクスを見ることが可能です。

また、ECS と違って Job Queue も提供されていて、ジョブの状態管理なども可能となっています。 CloudWatch Events によりジョブの状態変化によるイベントドリブンな処理も可能です。

Amazon Elastic Container Service for Kubernetes (EKS) new!

aws.amazon.com

EKS はマネージドな Kubernetes を提供してくれるサービスです。 (現在はプレビュー版のみの提供)

ECS は AWS が独自に開発しているコンテナのオーケストレーションサービスでしたが、Kubernetes は Google が開発している OSS プロジェクトのコンテナのオーケストレーションツールです。 (コンテナのオーケストレーションについては おまけ: コンテナのオーケストレーションについて を参照)

Kubernetes は OSS ということもあり、コミュニティが非常に活発で多くの開発者・企業が開発に協力しています。

Kubernetes を動かすための基盤はかなりたくさんの選択肢があり、あくまで EKS はそのうちの一つです。

特に、今まで AWS 上で Kubernetes 環境を構築するために様々なツールがありました (私が知っている範囲で)。

実際、今まで AWS 上で Kubernetes を利用していた人が多いようで、おそらくその方々は何らかのツールを用いて自前で構築していたと思います。

https://aws.amazon.com/jp/blogs/news/amazon-elastic-container-service-for-kubernetes/

AWS 上で Kubernetes を利用している多くのお客様がいます。実際、Cloud Native Computing Foundationによると、Kubernetes のワークロードの63%が AWS 上で動作しています。AWS は Kubernetes を実行するうえで人気の場所

これらのツールを使って、Kubernetes クラスタの構築・管理を簡単にすることができますが、やはりマスターノードを管理する必要はでてくると思います。

そこを AWS 側で管理・提供してくれるのが EKS となります。

EKS としては Kubernetes クラスタの管理だけでなく、ELB や IAM、VPC、Private Link、CloudTrail などとの連携も提供してくれているため、自前で Kubernetes クラスタを構築するよりも便利になっています。 後述の Fargate との連携も今後できるようになるとのことです。

また、既存の Kubernetes 用ツール群を使えるのも大きな強みです。

AWS Fargate new!

aws.amazon.com

Fargate は単体のサービスではなく ECS や EKS の上で使うことのできるサービスです。 (現在は北部バージニアリージョンのみの提供)

前述した ECS や EKS と違い、コンテナを動かすホストについて意識せず、コンテナそのものを動かすことだけに集中することができます。

どういうことかと言うと、Fargate では事前にホストを動かしておく必要はありません。

AWS VPC 環境と ECS のクラスター (名前空間的な意味で) を作っておけば、後はコンテナを起動するだけで自動的にホストを用意し、コンテナを実行してくれます。

また、ECS の上に乗っかっているので、使い方は簡単で ECS Task として起動する時に launch type として Fargate を指定するだけです。 その他、ECS Service でも使うことができます。 (EKS との連携についてはまだ情報が公開されていないため不明です)

ホストをこちら側で管理しないため、ホストの監視の方法などは気になるところですが、CloudWatch を通してホストのメトリクスは取れるようです。

https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overview

FargateではアプリケーションのログをCloudWatch Logsに送ることができます。サービスのメトリクス(CPUとメモリの利用率)もCloudWatchメトリクスとして利用可能です。可視化や監視、アプリケーションパフォーマンスの領域での我々のパートナーである、DataDog、Aquasec、Splunk、Twistlock、そしてNew RelicもFargateタスクをサポートしています。

また、Fargate に似たサービスとして Azure Container Instances (ACI)Hyper.sh といったサービスも AWS 以外で提供されています。

おまけ: コンテナのオーケストレーションについて

コンテナを本番環境で動かそうとした時、コンテナをどのインスタンスで動かすか、どのインスタンスでコンテナが動いているのか、などコンテナの管理方法でいくつか問題が出てきます (あくまで一例です)。

そういった問題を解決するため、コンテナのスケジューリングやマネージングをするツールを用意する必要がありますが、それらを解決するためのツールが ECS や Kubernetes, Docker Swarm などと言ったオーケストレーションツールとなります。

ただし、どこにコンテナのスケジューリングやマネージングをする人が必要になってきます。 その人をマスターノードなどと呼び、次はこれを管理・冗長化などしなければいけないという問題がでてきます。

そのマスターノードの管理までマネージドで提供してくれているのが、ECS や EKS, GKE (Google Kubernetes Engine), AKS (Azure Container Service) などになります。

まとめ

  • EB
    • 小規模なサービス・チームで使うと良さそう
  • ECS
    • AWS 独自のコンテナのオーケストレーションサービス
  • Batch
    • バッチコンピューティング基盤として使う
  • EKS
    • Kubernetes を使ったコンテナのオーケストレーションサービス
  • Fargate
    • 検証環境・本番環境・ちょっとした処理など幅広く使える

機能的に ECS と EKS の使い分けは難しいですが、学習コスト・導入コストの面で ECS に軍配は上がると思います。 ただ、コンテナを使う以上コミュニティが巨大な Kubernetes を使うことも大きなメリットです。

個人的には EKS を推していきたいです。