昨年、本番稼働を意識した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特有の設定もある。 |
他にもあると思いますが、思いついたタイミングで随時更新していければと思います。
