AWS EKSとは？Fargateの有無で何が違う？

Amazon EKS は、AWSで稼働するマネージドKubernetesサービスで、コンテナのオーケストレーションやスケジューリングに活用されます。

混同されがちなものとしてECSがあります。EKSと同じようなことができるコンテナ・オーケストレーターと思われがちですが、厳密には明確な違いがあるのです。さらにFargateの有り無しでも、特徴が大きく変わります。

これらの違いを正確に理解すれば、ツールを適切に使い分けられることから、より良いAWSコンテナ戦略を立てやすくなるはずです。

この記事では、Amazon EKS（AWS EKS）の概要、EKSとECSの違いを説明したうえで、標準モードとFargateモードの違いを知りたい方のために、AWS Fargateの有無がEKSにどのような影響を与えるかを詳しく解説します。

関 連 記 事

Kubernetesとは？	Kubernetesセキュリティ の基礎	Kubernetesアーキテクチャの 設計方法
AWSのEKS （Elastic Kubernetes Service）	Kubernetesの クラスターとは？	Kubernetes のノードとは？
KubernetesのPodとは？	KubernetesのHelmとは？	クラウドセキュリティと ランタイムインサイト

AWS EKSとは？

Amazon EKSとは、「Amazon Elastic Kubernetes Service」の略で、Amazonが提供するKubernetesのマネージド型サービスです。AWS（Amazon Web Services）上で稼働することから「AWS EKS」と呼ばれることもあります。

導入により、AWSクラウド上でKubernetesを利用し、コンテナのオーケストレーションやスケジューリングを実現可能です。Kubernetesはオーケストレーションプラットフォームの事実上の標準ツールであることから、多くのシステムで採用されています。

スケーラビリティなどを意味する「Elastic」が使われているとおり、最大の特徴は高い拡張性です。ただし使用するアプリケーションやワークロードなどの状況により、拡張できる機能が異なる点には注意する必要があります。

EKSとECSの違い

Amazonが提供する主要なサービスであるEKSとECSの違いを知っておくと、コンテナ化されたアプリケーションをデプロイする際に役立ちます。それぞれの定義は以下となります。

• Elastic Kubernetes Service（EKS）： EKSはオープンソースのKubernetesをベースにしたコンテナデプロイサービスです。KubernetesディストリビューションやKubernetes-as-a-Serviceと呼ぶこともできます。
• Elastic Container Engine（ECS）： ECSは、Amazonが独自に開発したコンテナオーケストレーションエンジンを搭載したコンテナデプロイサービスです。AWSがECSを構築したのは “オーケストレーター戦争 “の時代で、Kubernetesがコンテナ・オーケストレーション・プラットフォームのリーダー的存在になることが明らかになる前でした。

どちらもマネージドコンテナプラットフォームですが、採用しているソフトウェア（オーケストレーションツール）が違います。EKSはKubernetesのため、オンプレミスでKubernetesを採用していた場合はクラウド上で同じものを採用できます。対してECSはオリジナルのため、AWSでのみ稼働する形です。

共通点としては、AWSクラウドでホストされているオーケストレーションレイヤーを使ってコンテナ化されたアプリケーションをデプロイすることです。多くの場合、ECSとEKSもAWSがホストするインフラに依存しています。

ただし、例外として、EKS Anywhereを使用する場合、またはAWSのハイブリッドクラウドフレームワークであるAWS Outposts経由でECSまたはEKSを実行する場合が挙げられます。これらの状況では、オーケストレーションコントロールプレーンはAWSパブリッククラウドでホストされたままであっても、アプリケーションをホストするためにプライベートインフラストラクチャを使用可能です。

Fargateの有無に注目する理由

EKSとECSは一見シンプルです。しかしFargateの有無によって、構造は大きく変わって複雑化する傾向にあります。

AWS Fargateとは、AWSクラウド上でサーバーレスにコンテナを実行できる機能を持つサービスです。これ自体はコンテナデプロイメントサービスではなく、実際のオーケストレーションはEKSやECSといったオーケストレーターに依存します。つまり、EKSやECSの代替でも競合でなく、これらに組み合わせて使うものです。

いうなれば、AWSのコンテナサービスと組み合わせて、インフラストラクチャのセットアップとコンテナのデプロイ方法を管理するオプションの “デプロイモード “だと考えてください。

しかし、必ず採用しなければならないわけではありません。ECSやEKSを「標準モード」つまり「Fargate無し」で使うこともできます。この場合、ECSやEKSは、コンテナのデプロイとスケジューリングを独自に処理する形で稼働します。

Fargateの有り無しで仕組みが大きく変わるからこそ、その違いを知ることにより、環境に合わせた構築を実現しやすくなります。

Fargateの仕組み

Fargateは、コンテナをホストするインフラストラクチャをセットアップしたり管理したりすることなく、コンテナをデプロイできるようにします。

操作としては、「どのコンテナイメージを実行したいか」をFargateに伝え、「どれだけのコンピュート・リソースとメモリ・リソースを割り当てるか」についての詳細を提供するだけです。Fargateが自動的にホストサーバをプロビジョニングするので、利用者はコンテナ実行時に消費されたリソースに対してのみ料金を支払います。

原則として、Fargateはコンテナのオーケストレーションタスクを処理するためにECSやEKSに依存しています。同時に、インフラストラクチャのセットアップとコンテナのデプロイの自動化により、プロセス全体をシンプルにしています。

AWSは、Fargateを「サーバーレス・コンピュート・エンジン」と表現しています。その理由は、採用によりエンドユーザーがコンテナをホストするサーバーを管理する必要がなくなるからです。ただし、コンテナ専用のサーバーレス・コンピューティング・サービスではなく、AWS Lambdaとは別物です。Lambaの場合は、コンテナ・イメージのデプロイをサポートしています。

Fargateとオートスケールやマネージドノードとの比較

EKSやECS上で動作するコンテナをホストするインフラストラクチャを管理する必要がないなら、オートスケーリングを設定したり、EKSのマネージドノード（管理ノード）グループを使用したりするだけでは駄目なのでしょうか？

答えは「基本的にはイエス」です。EKSとECSはどちらもオプションでオートスケーリングを設定することができ、AWSにコンテナホストインフラを自動的にスケールアップまたはスケールダウンするように指示することができます。さらにEKSでは、ノードのプロビジョニングとライフサイクル管理を自動化する機能であるマネージドノードグループを利用することができます。

オートスケーリングとマネージドノードグループはFargateと似ています。しかし、重要な違いもあります。

• セットアップ： オートスケーリングでは、最初のインフラをセットアップする必要があります。Fargateはセットアップ・プロセスを完全に排除します。
• コントロール： 自動スケーリングでは、スケーリングがどのように管理されるかを正確にコントロールできます。Fargateモードでは、AWSは完全に独自にスケーリングを処理します。
• コスト： EKSのオートスケーリングとマネージドノードの利用には特にコストはかかりませんが、EKSのコスト構造はFargateのそれとは異なります。
• リージョンのサポート： FargateとEKSマネージドノードグループのサポートはAWSリージョンによって異なります。設定を試す前に、使用したいデプロイメントモードがリージョン（または複数のリージョン）でサポートされていることを確認してください。

EKSにおけるFargate有無の例

Fargateを使用するEKSと使用しないEKSの違いを説明するために、基本的なクラスタ作成の例をいくつか見てみましょう。これらはEKSで作業するためのさまざまなアプローチとなります。

オートスケールを使用しない標準モードのEKS

EKSクラスタを標準モードでセットアップする場合、つまりFargateを使用せず、マネージドノードグループやオートスケールを使用しない場合、クラスタをセットアップする際に以下のようなeksctlコマンドを使用して作成するノード数を指定する必要があります：

eksctl create cluster --name=cluster-1 --nodes=4Code language: JavaScript (javascript)

このプロセスはとても簡単ですが、クラスタのサイズを前もって決めておかなければならないことに注意してください。後で手動でノードを追加したり削除したりすることはいつでもできますが、最初から完璧なクラスタサイズを指定するよりは理想的ではありません。

オートスケールを使用する付き標準モードのEKS

自動スケーリングを設定したい場合は、–nodes-minフラグと–nodes-maxフラグを使用して、設定したいクラスタサイズの範囲を指定します。例えば以下の記述です。

eksctl create cluster --name=cluster-5 --nodes-min=3 --nodes-max=5Code language: JavaScript (javascript)

自動スケーリングが設定されたことで、ワークロードのニーズが変化しても、クラスタサイズがワークロードのニーズにマッチするという確信が持ちやすくなりました。ただし、それでもクラスタの規模について前もって明確な決定を下す必要があります。

マネージドノードによるEKS

ノード数を指定しない場合、EKSクラスタは管理ノードグループを使用します。例えば、以下のような形です。

eksctl create cluster --name my-cluster --region region-codeCode language: JavaScript (javascript)

これはとても簡単でした。クラスタの規模はEKSに決めてもらいました。もちろん、クラスタ管理をAWSの手に委ねることになるので、コントロールの幅が狭くなるというデメリットもあります。

EKSとFargate

Fargateモードで使用するクラスタを作成するには、-fargateフラグを使用します。例えば、以下の形です。

eksctl create cluster --name my-cluster --region region-code --fargateCode language: JavaScript (javascript)

これも簡単です。注意点は、クラスタのスケーリングを明確に制御できないことです。さらに、このクラスタの課金はFargateの価格に基づいて行われる点に気をつけましょう。

Fargateの有無による違い

ここまでの例もふまえ、Fargateの有り無しによる一般的な違いをまとめます。「Fargateモードをいつ使うか、いつ使わないか」を決めるために役立つはずです。

コントロール

Fargateでは、さまざまな点でコントロールが制限されます。クラスタのサイジングを制御できないだけでなく、Fargateモードで実行するコンテナに対してHostPortやHostNetworkといった設定変数を指定することもできません。また、特権モードでコンテナを実行することもできず、DaemonSetsを設定することもできません。

一般的に、コンテナの実行方法を細かく制御する必要がない場合、Fargateは最も理にかなっています。できるだけ多くの制御が必要な場合は、標準モードのEKSを使用してください。

セキュリティ

Fargate経由でデプロイされたコンテナは、専用の仮想マシン内で実行されるため、見方によっては安全性を少し上げることができます。このレベルの分離は確かにすべての脅威を阻止するわけではありませんが、損にはなりません。

Fargateが特権モードをサポートしていないことも、特権コンテナを実行するリスクを回避するための一種のセキュリティ機能です。

一方、標準モードのEKSが与えてくれるコントロールの幅が広がることで、より良いセキュリティ結果につながるかもしれません。

サポート地域と構成

FargateのサポートはAWSリージョンによって異なります。また、AWS OutpostsやEKS Anywhereを利用している場合は利用できません。そのため、場合によってはより広範なAWSデプロイ戦略によってFargateが使えるかどうかが決まります。

価格

上述の通り、標準的なEKSとFargateは異なる価格体系が適用されます。正確な価格はAWSのリージョンやワークロードの種類によって異なります。Fargateと標準EKSのどちらが費用対効果が高いかは、標準EKSを使用する場合、適切なクラスタサイズを構成することにどれだけ長けているかに大きく依存します。

一般的には、EKSの自動スケーリングをうまく設定できない場合や、ワークロードが頻繁に大規模にスケールアップ/ダウンする場合は、長期的にはFargateの方が安くなる傾向があります。

しかし、頻繁にスケーリングする必要のないワークロードや、コストとパフォーマンスのニーズに基づいてクラスタを慎重にサイズ変更する場合は、標準的なEKSの方がコストが低くなる可能性が高いでしょう。

利便性

シンプルさと使いやすさを最優先するのであれば、Fargateに軍配が上がります。標準モードのEKSも決して使いにくいわけではありませんが、それでもFargateモードよりは労力が必要な傾向です.

まとめ

標準モードの EKS と Fargate モードの EKS のどちらを選択するかということになると、一概にどちらが正しいということはありません。

どのような種類のワークロードをデプロイするのか、そのスケーリング要件はどのようなものなのか、どの程度の管理工数にコミットできるのかをよく考えて、EKSでFargateを使用するかどうかを決定する必要があります。