AWSでDockerコンテナを使う方法を調べてみた

先日、GitlabのCI/CD機能でHerokuにDockerイメージをデプロイするという記事を書きました。Herokuは無料で使えるという面で練習用には非常に優れた選択肢ですが、業務で使うとなるとネームバリューや機能的に優れたAWSやGCP、Azureになりがちです。

実業務で使う可能性が高い、メジャーなクラウドサービスでもDockerコンテナをデプロイできるようになりたいので、勉強をすることにしてみます。

今回は、クラウドサービスの中でも最もシェアが高い（参考：https://www.imagazine.co.jp/synergy-cloud-share2022-01/）AWSでDockerコンテナを利用する方法を調べてみました。

最終的な目標は「GithubのCI/CD機能であるGithub ActionsでAWSにSpring Bootが動くコンテナをデプロイする」とします。今回の記事は最初の一歩です。

AWSにDockerコンテナをデプロイする方法は3つある

私が調べた限り、AWSにDockerコンテナをデプロイする方法は3つあるようです。

• ECS(Elastic Container Service)
• EKS(Elastic Kubernetes Service)
• Kops(Kubernetes Operations)

ECSとEKSはAWSが管理するコンテナ管理サービスで、ある程度設定済みのオーケストレーションツールを使うことができます。

KopsはKubernetesクラスタをAWS上に作成するツールで、EKSより低レベルでKubernetesの管理ができます。

以下にそれぞれの特徴とメリット、デメリットをまとめました。

ECS(Elastic Container Service)

ECS(Elastic Container Service)はAWS独自のコンテナオーケストレーションツールを利用するコンテナ管理サービスです。Dockerコンテナの実行、停止、管理を簡単に行うことができます。

メリット、デメリットは次の通りです。

ECSのメリット

Kubernetesに比べて学習が楽

ちょっと古いですがEKSは本当にECSより難しいのか？というページで詳細に比較しています。ECSに比べるとKubernetesの方が汎用的な分覚えなくてはならないことが多くて大変なようです。

また、AWSネイティブなサービスなので、その他のAWSの機能との相性も良いとのことでした。

情報が多い

Googleの検索件数を比較すると以下のような状態です。

検索件数はECSの方が多いことがわかります。また、「AWS Docker」で検索しても上位に出てくるのはECSのものばかり。EKSに比べると、オンラインでの情報はECSのもののほうが多いようです。

管理コストが安い

EKSではKubernetesのバージョンが上がるたびに更新作業が必要になります。大体3ヶ月に1回のバージョンアップが計画されていて、メンテナンス期間は1年です。

これが結構大変なようで、毎回バージョンが変わってもシステムが動くかどうかの確認、場合によってはシステムの修正が必要になります。

ECSでも更新はあるようですが、基本的に破壊的な変更はないようなので大きな手間はかかりません。

クラスタの維持費がかからない

EKSだとクラスタを1つ作るごとに費用が発生します。どのリージョンでも1時間あたり$0.1、1月でだいたい$72ほどです。

一方ECSだとクラスタには費用がかかりません。大きなプロジェクトなら月$72は大したことないでしょうけど、個人や小規模プロジェクトだと馬鹿にならない金額です。

ECSのデメリット

コンテナ間の通信に手間がかかる

Kubernetesではクラスタ内のコンテナ間通信はKubernetesの設定だけで完結できます。

一方、ECSは内部のコンテナ間で通信を行う場合でも別途設定が必要になります。コンテナが少ないうちは大した手間ではないでしょうけど、マイクロサービスで多くのコンテナを作る場合は通信の設定に手間がかかります。

外部との通信も少し面倒

コンテナ間通信と同じく、外部との通信でも別途設定が必要です。Kubernetesは内部の設定で完結できるので、こちらもちょっと面倒です。

ベンダーロックインされる

ECSはAWS独自のコンテナオーケストレーションツールを利用しています。そのため、AWS以外の環境では利用できません。ECSのためだけの勉強をすることになります。

KubernetesはOSSでAWS以外でも広く使われているため、ベンダーロックインされる事はありません。

EKS(Elastic Kubernetes Service)

EKS(Elastic Kubernetes Service)はOSSで広く使われているオーケストレーションツールKubernetesのコンテナ管理サービスです。他のクラウドサービスでもGCPではGKE（Google Kubernetes Engine）、AzureではAKS（Azure Kubernetes Service）があるのですが、それのAWS版ということになります。

メリット、デメリットは次の通り。

EKSのメリット

通信設定が楽

EKS、というかKubernetesはコンテナ間や外部との通信設定をKubernetes内で完結させることができます。ECSは外部ツールの設定が必要になるので、管理のしやすさはEKSの方が上です。

コンテナや外部通信が増えても、Kubernetesの設定だけを管理すれば良いので、ネットワーク設定の状況が把握しやすいのはメリットとなります。

GitOpsが利用可能

GitOpsは特定のツールではなく、Git プルリクエストを使用して、インフラストラクチャのプロビジョニングとデプロイメントを自動的に管理する仕組みのことです。この仕組をKubernetesは持っています。

GitOpsを利用すると、Kubernetesの環境を常にGitのマニュフェストに沿った状態であることを保証できるようです。

ECSだとマニュフェストの環境への反映はCI/CDツールを使うなり手動で反映するなりする必要があり、最新の状況が反映されていることを保証できません。

デファクトスタンダードなOSSなので情報が多い

ECSでも情報が多いことをメリットと書きました。ECSとEKSとの比較だと確かにECSの方が情報が多いです。

しかし、Kubernetes全体と比較するとまた違った結果になります。

この図のように、Kubernetesの検索ボリュームが圧倒的に多いことがわかります。EKS独自の部分については多少情報が少ない面もあるかもしれませんが、Kubernetesについての情報が足らないということはおそらくありえないでしょう。

EKSのデメリット

クラスタごとに費用がかかる

ECSはクラスタの構成自体に費用はかかりませんが、EKSはクラスタを作るごとに費用がかかります。1時間あたり$0.1、1月でだいたい$72ほどです。

ECSの項目でも書きましたが、小さなプロジェクトや個人にとっては無視できない金額でしょう。

学習コストが高い

EKSではKubernetesを使います。Kubernetesはデファクトスタンダードで多機能な分、どうしても学習に時間がかかります。

また、Kubernetes自体の使い方に追加して、AWSの機能の使い方を習得するのもECSよりより大変なようです。

メンテナンスに手間がかかる

ECSの項目にも書きましたが、Kubernetesのバージョンアップが3ヶ月に1回あり、メンテナンス期間は1年です。したがって、最低でも1年おきに新たなバージョンを使う必要があります。

Kubernetesはシステム全体に関わる部分なので、バージョンアップに伴う不具合の確認などメンテナンスのコストがかかります。

ECSは特にバージョンが存在せずパッチもAWSがやってくれるため、更新のコストはかかりません。

Kops(Kubernetes Operations)

Kops(Kubernetes Operations)はAWS上にKubernetesのクラスタを構築するためのツールです。ECSとEKSはAWSがオーケストレーションをある程度管理してくれますが、Kopsを使う場合は自力でクラスタを管理することになります。

メリット、デメリットは次の通りです。

Kopsのメリット

EKSより安くKubernetesクラスタを利用可能

EKSはAWSがマネージドしてくれるの分クラスタを作るごとにコストがかかります。KopsでもAWSのリソースを使うのでクラスタごとに費用はかかるのですが、EKSを使う場合より安くすることが可能です。

EKSより細かい制御が可能

Kopsでは自分でKubernetesのクラスタを作る分、より複雑で細かい制御が可能です。ただ、EKSでできる制御では物足りないプロジェクトがどのくらいあるのかはよくわかりません。

クラスタが素早く作成できる

EKSではクラスタの作成に数分かかります。しかし、Kopsで作るとそれよりかなり早く作成が可能です。最初の1回だけなので影響は少ないかもしれません。

Kopsのデメリット

EKSよりメンテナンスに手間がかかる

EKSはAWSがある程度準備してくれているので、導入が楽です。

一方KopsはKops自体のインストールから初めて、Kubernetesの設定も自分で行わなくては行けない部分が多いです。

情報が少ない

EKSやECSに比べると、明確に情報が少ないです。Kopsの検索ボリュームは少なすぎてEKSなどとは比較になりません。

私がEKSを選んだ理由

ここまで書いてきたとおり、AWSにDockerコンテナをデプロイする方法は3つあります。どれも一長一短ですが、私はGKEを使うことに決めました。理由は3つあります。

• ベンダーロックインされたくない
• 現在参画中のプロジェクトでGKEを使っている
• 細かい管理はしたくない

それぞれについて説明します。

ベンダーロックインされたくない

私は自分の技術が汎用的であることを望みます。ECSだとAWSだけが対象の技術になってしまい、使えん範囲が狭いです。

AWSだけにベンダーロックインされるのは避けたいと思いました。

現在参画中のプロジェクトでGKEを使っている

現在参画しているプロジェクトではGCPのKubernetesサービスであるGKEを使っています。

先程のベンダーロックインが嫌という話にもつながるのですが、EKSでKubernetesに触れておけば、GKEでもその経験を活かせるはずです。

細かい管理はしたくない

Kubernetesを使うならKopsという選択肢もありますが、こちらは細かい制御ができる反面管理も複雑になるようです。

今後どうしても細かい管理が必要になってしまったら仕方ないですが、できることならシステムに影響がない管理はしたくないと思います。

まとめ：一長一短の方法が3つある

AWSでDockerコンテナを使う方法は3つありました。

• ECS
• EKS
• Kops

それぞれ一長一短で、どれが悪いということもないみたいです。

ただ、私はその中でもEKSの勉強をしていくことにしました。Kubernetesがデファクトスタンダードであることと、Kopsよりは管理が楽そうというのがその理由です。

本当はDockerコンテナをEKSにデプロイするところまで話を進めたかったのですが、力尽きたので今回はAWSでDockerを使う方法をまとめるところで終わりにします。

EKSでClusterを作る方法はこちらにまとめました。

Cloud9でEKSのClusterの作成と削除をする

Cloud9の環境を作成し、EKSでClusterを作成します。Clusterの作成よりも環境構築が難しいはずです。

www.tsuchiya.blog

2022.04.03