ECS FargateとElasticBeastalk（Ruby Platform）の比較

昨年、本番稼働を意識したECS Fargateを用いたFastAPIの環境構築（ALB、SSM、BlueGreenデプロイ）という記事を投稿しました。その後、仕事にて実運用でECS Fargateを利用し始め、ある程度感覚がわかってきましたので、以前利用していたElasticBeanstalk（Ruby Platform）との比較を簡単に紹介したいと思います。
仕事では、ECS Fargateは2022年2月末に本番運用を開始しています。また、ElasticBeanstalkに関しては、2017年より仕事で使っています（既にある環境の運用から始まり、新規構築も何度か行いました）。その経験を踏まえて感じたことですので、使用している機能が限定的だったり、詳しい方から見れば容易に改善できる面もあるかと思います。ご教授いただけましたら幸いです。

1. デプロイのしやすさ

	ElasticBeanstalk	ECS Fargate
良い点	eb deployコマンドを叩けばデプロイできる簡単。	イメージのビルドは事前に済ませているのでデプロイが早い。
気になる点	デプロイに時間がかかる。特に.platform(AL2)や.ebextensions(AL)などで処理をたくさんしている場合や、assets:precompileをデプロイ時に行うようにした場合に顕著。	Dockerイメージのビルド、タスク定義の追加、サービスの更新などを行う必要があり煩雑。いろいろな方法が提示されているが、CodePipelineなどで自動化していけばよい。

2. アプリケーションログ

	ElasticBeanstalk	ECS Fargate
良い点		CloudWatchとの連携がしやすい。
気になる点	どこかのファイルに吐かれたログをkinesis firehoseなどの仕組みを利用してs3などに退避させる必要があり構築が面倒。

3. コスト

• 運用上はそこまで違いはない気がする。

	ElasticBeanstalk	ECS Fargate
良い点
気になる点		プライベートサブネットにおくとイメージのpullでNAT費が増大になる。PrivateLink（エンドポイントサービス）を正しく設定する必要がある。

4. メンテナンス性

	ElasticBeanstalk	ECS Fargate
良い点	プラットフォームのマイナーバージョンは（設定にもよるが）自動で上げてくれる。	Dockerのイメージは自分たちで管理するので、OSやopensslなどのアップデートなどは自分たちでやらなければいけない。
気になる点	プラットフォームバージョンを上げる（AL2移行、RubyやPythonのバージョンアップ）といったときにはサービスを別で作らなければいけない。組織にもよるが弊社の場合はTerraformで管理しておりインフラチームが作業してくれおり、AL2のバージョンアップなどは同じ時期にくるのでインフラチームの負担が一時的に増大する。	RubyやOSDockerのイメージを更新するだけでよい。弊社の場合はDockerfileはアプリエンジニアが修正するのでインフラチームに頼る必要がなくなり気軽に上げやすい。

5. 構築のしやすさ

	ElasticBeanstalk	ECS Fargate
良い点	nginxなども含まれているので簡単にできる。	Dockerに慣れていれば容易い。
気になる点	カスタマイズしていこうと思うとElasticBeanstalkのプラットフォームの独特の挙動に悩まされることがある。	良くも悪くもDockerに慣れ親しんでいるかどうかで変わる。Fargate特有の設定もある。

他にもあると思いますが、思いついたタイミングで随時更新していければと思います。