ECS（Fargate）でDockerを試してみる

ちょっとAWSで動かしたいDockerイメージがある。中身はコマンドから常駐プロセスが立ち上がるものになっている。Lambdaでなんとかできないかなーと思って、いろいろやってみたけどダメだった。

ということで、ECS（Fargate）でやってみる。

なお、EKSは業務でもいろいろやったけど、ECSは全く触ったことがないので、イチからやる。

公式のハンズオンはこの辺

とりあえずざっと流してみる。

色々画面構成が変わっていて、古い画面のハンズオンになっていたけど、以下が一番近かった。あと、EC2とFargateの両方がカバーされていた。

とりあえず自分的にはやっぱりFargateのほうが楽で良い感じ。EC2でどういう運用が必要になるのかがイメージがまだないし、めんどくさそう。コストが許容されるならばFargate使いたい感はある。

次はSAMで実際に使いたいDockerイメージでやってみる予定。

ちょっとAWSで動かしたいDockerイメージがある。中身はコマンドから常駐プロセスが立ち上がるものになっている。Lambdaでなんとかできないかなーと思って、いろいろやってみたけどダメだった。

Lambdaでも動かせた。

Lambda Web Adapterと使ってやる、ってのは最初からやっていたのだけども、LiteLM公式のDockerイメージ　を使ってやろうとしてたのがよくなくて、自分でLambda用Pythonイメージに必要なパッケージと設定組み込めば動かせた。

一応やりたいことはできたので、ECSを使う必要はなくなったのだけども、まあDockerで常駐させれたら、っていうケースは他にもあるし、これはこれで良しとする。

ECS+Fargateでいくつか気になったこと。

ECSからALBを作成すると、CloudFormationの管理下になる。
- この場合、細かいリスナールールまでは設定できない（マネコン上そういう設定はない）。
- 後付で設定することはできるんだけど、IaaSとかを使って構築・管理したいようなケースだとはここはちょっと物足りない。
- 先にALB＋リスナールール＋ターゲットグループを作っておいて、ECSからはターゲットを紐づける、ということも可能ではある
- これをIaaSでやる場合、SAM出やるべきなのか？CDKでやるべきなのか？

自分の経験的に、SAM＋CDKの併用みたいなのをやったことがあるのだけど、どっちで作るべきなのか、みたいなことを考えるのが面倒な感がある。あくまでも個人的な話ではあるけど、どっちかっていうとCDKがしんどいのよね。

結局のところ自分のスキルレベル＋好みの問題かもしれないけど、インフラは宣言的に書きたいのだよな。コードでロジック書けるのは便利な場合もあるんだけど、そこまで必要ないというか。しかもSAMとCDKみたいな複数の手段があるのが余計に悩みを生んでいるというか。

まあ未だにCloudFormationに慣れてないというのもある。もういっそ慣れたTerraformで全部作りたいかなーと思ったり。

ちなみに自分がECSでやりたいなと思ったのは、

みたいな、メインのLLMアプリの周辺ツールを動かしたいというのがもともとの経緯。

コード側でそれぞれをSDK的に組み込むこともできるんだけど、

というところで、いろいろやろうと思うと、Dockerでいろいろ動かせるプラットフォームが欲しい、AWSだとECSあたりが良さそう、と。

k8s/EKSとかまでいくと、メインでやりたいことと、結果としてやらないといけないこと、がさすがに逆転してきそう。

ただECS Fargateでこれだけ動かそうと思うと料金体系的にコストが気になるところ。EC2で集約したほうが安くなるけど、それって単なる運用コストの付け替えだし悩ましいところ。まあいきなり全部じゃなくて少しづつ追加していって、運用稼働確保できそうならEC2で、とかなら良さそう。

なお、LangFuse/Presidio/LiteLLMについては以下でまとめている。