AWS Fargate のすヽめ

Created
Aug 7, 2023 5:47 AM
Tags
Fargate
Editor
Haruki Wada
image

エンジニアの和田です。

お客様の Amazon EC2 Container Service (ECS) を利用したサービスの構築・運用をさせていただいているのですが、

これまで Amazon EKS と比べると「あと一歩」という感じが拭えないサービスでした。

(EKSの東京リージョン対応を熱望しています)

それが、2018/07/04 に AWS Fargate が東京リージョンで利用可能になり、かなり状況が変わりましたのでお伝えします。

今までの ECS の辛いところ

これまでは ECS cluster に紐づくEC2 インスタンスが必要でした。

EC2 上で動くタスクを定義するため、コスト面を考えて EC2 インスタンスのリソースを使い切るようなタスク定義にするという要件をいただくことがありました。

ECS Cluster

image

インスタンスタイプ

instance type
vCPU
Memory(*1)
c5.large
2
4GB

タスク定義

task
cpu (*2)
memory
ECS task1
1024
2.5GB
ECS task2
1024
1GB

(*1) ECS_RESERVED_MEMORY=512 として、メモリの 512MB は Amazon ECS コンテナエージェントが利用する想定です

(*2) cpu の項目は unit 数になります。vCPU 2 であれば 2048 まで指定が可能になります。

タスクのサイズを変えたい

すでに EC2 インスタンスのリソースをフルに使っていますので、

例えば ECS task1 にmemory を 3.5GB 割り当てたい、という場合は、 EC2 インスタンスをスケールアップ、あるいはスケールアウトして余剰リソースを出すような形になります。

また、 4GB など EC2 インスタンスのリソースを超えるタスクを起動したい場合もスケールアップが必要です。

スケールアップ

image

スケールアウト

image

deploy したい

deploy 時は、既存タスクと同じ数のタスクが起動して、 ELB に組み込まれ正常にヘルスチェックを返したら旧タスクがスケールインされる、というのが理想形です。

deploy前

image

deploy中

image

deploy完了

image

この方法を取るためには以下の方法が考えられますが、それぞれに課題があります。

  • deploy に備えて常時2倍のリソースを確保しておく
    • リソースを使いきる運用が達成できない
  • deploy 時のみ2倍のリソースを確保する
    • deploy 時に Lambda で Autoscaling group を変更することで実現できる
      • スケールイン対象の EC2 インスタンスに別のタスクが起動しているとスケールインされないため、その掃除を考慮する必要もある

オートスケールしたい

EC2 を利用した ECS でのオートスケールには、2種類のオートスケールを構成する必要があります。

  • EC2 インスタンスのオートスケール設定
  • タスク ( ECS Service ) のオートスケール設定

この際、タスクのオートスケールが発動しても、 EC2 のリソースが無ければオートスケールは失敗します。設定によっては、タスクだけ、 EC2 だけのオートスケールによるスケールアウトが発動するということもあり、 EC2 だけスケールアウト -> タスクは増えないので負荷が変わらず -> 再度 EC2 のスケールアウトが発動...

という無限ループに陥ってしまうこともありえます。

完全に連動させるには、 Cloudwatch alarm の閾値を超えたら Lambda で、というようなやり方になります。

参考: Amazon ECSのDockerコンテナをLambdaでAuto Scalingに連携させる

## Fargate なら全て解決!

EC2 の制限から解放

Fargate では EC2 のリソース制限がなくなり、 ECS Cluster に Fargate というプールが用意され、

その中からリソースを借りるようなイメージとなります。

Fargate イメージ

image

タスクのリソース変更と deploy

EC2 のリソースを気にする必要が無いため、リソース変更と deploy は同じ動作となります。

新しいリソース・コードのタスクを立ち上げ、旧タスクを落とすだけです。

deploy前

image

deploy中

image

deploy後

image

オートスケール

こちらも EC2 を気にする必要が無くなるので、タスクのオートスケール設定のみで良くなります。

Fargateのデメリット

参考: AWS Fargateの機能制限とかできないこととか

ここに綺麗にまとまっていますが、特に移行の障害となりそうな部分をピックアップします。

指定できるリソースが固定されている

EC2 と比べると、利用できる最大メモリ、 vCPU が低くなっています。

参考: AWS Fargate の料金 のサポートされる設定 を参照

Link 機能が使えない

コンテナ間通信を使っている場合は、参考サイトにある代替方法を使う必要があります。

ログドライバが awslogs のみ

fluentd などを使っている場合、修正する必要があります。

コンテナホストに ssh できない

コンテナホストに ssh して tcpdump や docker exec しての env の確認などをしたい場合があると思います。 Fargate ではコンテナホストへのログイン手段が提供されていません。

どうしても ssh したい場合は、 docker image で sshd を起動して security group を修正するなどの作業が必要です。

開発中であれば EC2 で ECS を組むというのもありだと思います。

まとめ

Fargate により、今まで EC2 の制限で deploy やオートスケールなど、頭を悩ませることが多かった部分が解決されました。現在 EC2 ベースの ECS を利用されている方でデメリットが許容できるサービスであれば、ぜひ移行をご検討ください。

移行について不安や課題がある方は、弊社の運用支援・技術サポートのご利用も合わせてご検討いただければと思います。