AWS EKS： Fargate有りと無しの違いを理解する

アマゾン ウェブ サービス（AWS）クラウドのコンテナデプロイメントサービスを理解しようとすると、アルファベットのスープに溺れているような気分になりがちです。

AmazonのマネージドKubernetesサービスであるEKS。ECSは、EKSと同じようなことをする別のコンテナ・オーケストレーターですが、実際にはそうではありません。そしてFargate – 確かに頭字語ではありませんが、その名前も解釈しやすいものではありません。

これらのサービスやツールはすべて、AWSクラウドにおけるコンテナのオーケストレーションやスケジューリングに一役買っています。しかし、それらは異なる方法で動作し、それらを取り巻く小さな詳細を理解することは、正しいAWSコンテナ戦略を計画するために重要です。

もしあなたが上記のすべての意味を理解するのに苦労しているなら、言い換えれば、スケジューラやオーケストレータや “Fargateモード “などについてのすべての話に混乱しているなら、この記事が役立つでしょう。下記では、AWS FargateとEKSの複雑な関係について説明します。また、ECSはこの記事の焦点ではありませんが、ECSがこの中でどのような位置づけにあるのかも明らかにします。

そして、多くのAWSユーザが今日直面している最大の疑問、それは、標準のEKSを使用するのとは対照的に、Fargateを使用してコンテナ化されたアプリケーションをデプロイするのはどのような時に有効なのか？、という疑問にお答えします。

AWSコンテナサービス： EKSとECS

まず、コンテナ化されたアプリケーションをデプロイするためにAmazonが提供する2つの主要なサービスを定義することから始めましょう：

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

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

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

Fargateはどう扱いますか?

表面的には、EKSとECSはシンプルに見えます。

物事が複雑になり始めるのは、Fargateが登場したときです。Fargateはそれ自体コンテナデプロイメントサービスではありません。実際のオーケストレーションは他のオーケストレーター、つまりEKSやECSに依存します。つまり、FargateはEKSやECSの代替でも競合でもありません。

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

言い換えれば、FargateはEKSとECSの両方にコンテナをデプロイするひとつの方法です。しかし、唯一の方法ではありません。ECSやEKSを標準モード、つまりFargateなしで使うこともできます。後者の場合、ECSまたはEKSはコンテナのデプロイとスケジューリングを独自に処理します。

Fargateの仕組み

Fargateは、コンテナをホストするインフラストラクチャをセットアップしたり管理したりすることなく、コンテナをデプロイできるようにします。どのコンテナイメージを実行したいかをFargateに伝え、どれだけのコンピュート・リソースとメモリ・リソースを割り当てるかについての詳細を提供するだけです。その後、Fargateが自動的にホストサーバをプロビジョニングします。あなたは、コンテナが実際に実行されているときに消費されたリソースに対してのみ料金を支払います。

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

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

Fargateとオートスケールおよびマネージド・ノードの比較

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

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

これら2つの機能（オートスケーリングとマネージドノードグループ）はFargateと似ています。しかし、重要な違いもあります：

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

Fargateを使用するEKSと使用しないEKS： 　2つの例

Fargateを使用するEKSと使用しないEKSの違いを説明するために、3つの基本的なクラスタ作成の例を見てみましょう。

オートスケールを使用しない標準モードの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を使用する時としない時

EKSで作業するためのさまざまなアプローチがわかったところで、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を使用するかどうかを決定する必要があります。