Amazon ECSとEKSの違い

2024/08/25に公開

Amazon ECS と Amazon EKS について

AWSは、Amazon ECSとAmazon EKSという、2つの主要なコンテナオーケストラーションサービスを提供しています。ECSは2014年に発表された AWS ネイティブなコンテナオーケストラタであり、一方、EKSはOSSのコンテナオーケストラタである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました。

今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います。

ECSとEKSの違い

実際には ECS がコンテナオーケストレーターであるのに対して EKS は Kubernetes クラスタそのものを管理するサービスなので、質問と比較の意図は ECS vs. Kubernetes ということになるかと思います

これらのサービスはしばしば比較されますが、ECSはコンテナオーケストレータとして機能し、EKSは Kubernetes クラスタそのものを管理するサービスです。
したがって、実際の比較は ECS と Kubernetes の間で行われるべきです。ちなみに、多くの機能が Kubernetes には存在するが ECS には存在していません。

ECS には秘密情報管理の機能がありません. ECS には時間指定でのコンテナ実行機能はありません. One-off なコンテナ実行時の成功保証もやらなければ、いわゆる設定情報管理も ECS の責務の範囲外です.

これらは Kubernetes においてはすべて単体で実現可能です. Secrets(秘密情報管理)、Jobs(成功保証)、CronJobs(時間指定実行)、ConfigMaps(設定情報管理) といったリソースを利用することによって、ECS では実現できない上記のような機能性がカバーされています. これらの例から明らかな通り、横並びで◯×表を作ると間違いなく Kubernetes の方が多機能です.

システム構築のための哲学とプラットフォーム

システムを構築する際,通常、何らかの思想や哲学を持つプラットフォームが存在します。AWS自体がプラットフォームであり、ECSはその一部です。それに対し、Kubernetesは、ユーザーが独自の哲学に基づくプラットフォームを創造することを可能にします。

ECSとKubernetesの機能の違い

一部の機能は、Kubernetesに存在しますが、ECSには存在しないことに触れましたが、その理由は「各オーケストレータにとって何がプラットフォームなのか」という観点に見つけることができます。

ECSの役割

ECSはあくまでもAWSというプラットフォームの一部です。そのため、秘密情報の管理、時間指定での処理実行、成功保証のためのリトライ、設定情報管理などの機能は、ECSではなく、AWSの他のサービスで実装されています。その具体的な例としては、AWS Secrets Managerが秘密情報管理、Amazon EventBridgeが時間指定での処理実行、AWS Step Functionsが成功保証とリトライ、そしてAWS Systems ManagerのParameter Storeが設定情報管理を担当します。そして、ECSはこれらのサービスと統合されています。これにより、例えば、私たちはECSで実行するコンテナから安全に秘密情報にアクセスできます。

しかし、ECSには秘密情報管理の機能はありません。また、時間指定でのコンテナ実行機能も存在しないし、One-offなコンテナ実行時の成功保証もありません。言い換えれば、いわゆる設定情報の管理もECSの責務の範囲外です。

この文章を見てみてください。ここでの“ECS”を“Lambda”に置き換えてみてください。すべてがLambdaで存在し、使用されているケースです。

これは、AWSというプラットフォームの思想であり、哲学の一部です。各AWSサービスはそれぞれのAPIを呼び出す形で疎結合に組み合わせることができ、その一部、例えばECSからLambdaへと置き換えることも可能です。この思想と哲学が、AWSの幅広いユースケースをカバーする能力を提供し、ユーザーがAWS上で持続可能なシステム構築と運用を行うことを可能にしています。

AWS自体がプラットフォームであり、ECSはその一部という関係性があります。しかしながら、Kubernetesというソフトウェアは、ユーザー自身が独自の哲学に基づいてプラットフォームを創り上げるのを可能にします。

Kubernetesの複雑さ

一般的には、「Kubernetesは難しい」という見解がありますが、デプロイメントモデルは利用者にとって単純で美しく、システム構築を一貫性もって実現することに強みがあります。さらに、そのカスタムリソースやカスタムコントローラによるオブジェクト管理は、Kubernetesを一つに絞り込む存在にしています。KubernetesのAPIを自分たちのワークフローやワークロードに折り合いをつけながら拡張すると、全てが一貫した動きを示すプラットフォームを作り出します。

しかし、多くの人が「Kubernetesは難しい」と言います。その理由の一つは、Kubernetesクラスタ自体をコードで管理し、同一のクラスタ設定を再現したいと思っているからです。しかし、それが必ずしも可能な状態にあるわけではありません。

Kubernetesが難易度を上げる一方で、ECSとEKSの選択は「プラットフォームの選択」という側面を持ちます。これは、システムの構築、運用、管理の方法を決定する重要な要素になります。どのようなシステムを、どのように作り上げ、どのように運用していきたいか、これにより選択が決まります。

プラットフォームの選択

どのようなシステムを、どう作り、どう運用していきたいか?は常に悩み、考え続けていきたいです

Discussion