Fargate vs Lambda: コンテナかfunctionか？
Fargateは時間制限なしでserverlessコンテナを実行し、Lambdaは呼び出しと実行時間に応じて課金される短命なserverless functionsを実行します。
Lambdaは、リクエスト単位の課金とほぼゼロのアイドルコストで、イベント駆動の短命なワークロードに優れていますが、実行時間とパッケージサイズに上限があります。Fargateは、既存のコンテナイメージを使い、サーバーを管理せずに、安定したまたは長時間動くサービス向けに長命なコンテナ (ECSまたはEKSで) を実行します。Lambdaはバースト的なイベントワークロードを重視し、Fargateは永続的なコンテナ化サービスを重視します。
| Fargate | Lambda | |
|---|---|---|
| 単位 | コンテナtask | Function |
| 実行時間 | 厳しい制限なし | 最大15分 |
| 課金 | vCPU/メモリを秒単位 | リクエスト単位 + 実行時間 |
| Cold start | taskの起動 | 高速、緩和可能 |
| 最適な用途 | 長時間動くサービス | バースト的なイベント駆動 |
ユースケースとコスト
Lambdaは、実行中のみ課金されるAPI、イベント処理、スパイク的なトラフィックに向いています。Fargateは、継続的に動く、Lambdaの制限を超える、またはすでにコンテナとして出荷されているサービスに向いています。安定した高い稼働率にはFargate (またはEC2) の方が安上がりなことが多く、バースト的またはアイドルの多いワークロードではLambdaが勝ります。
CIとdeployでは
Lambdaはzip/コンテナイメージ経由でdeployし、FargateはECRへのイメージpushにtask-definitionの更新を加えて、すべてOIDCでCIからdeployします。いずれもマネージドrunnerからdeployでき、より速いrunnerがパッケージング、イメージのbuild、rolloutを短縮します。
結論
短命、イベント駆動、またはスパイク的なワークロードでアイドルコストがほぼゼロなら: Lambda。長時間動くコンテナベースのサービスやLambdaの制限を超えるものなら: Fargate。多くのアーキテクチャは両方を組み合わせます - イベントとグルーにLambda、永続サービスにFargate。