私はサーバーレスの分野にかなり不慣れなので、Fargate と Lambda をいつ使用すればよいのかを理解しようとしています。
Fargate は ECS のサーバーレス サブセットであり、Lambda もサーバーレスですがイベントによって駆動されることは承知しています。しかし、コンテナには精通しているものの AWS やサーバーレスにはあまり精通していない人たちに、この 2 つのパラダイムをわかりやすく説明できるようになりたいです。
現在、テキスト ファイルの受信、解析、および結果を使用して複数の DB テーブルを作成する物理サーバーが 2 台あります。私の理解では、テキスト ファイルを解析するプロセスはスケジュールによってトリガーされ、長時間実行されず、使用されていないときは減速するため、これは Lambda に適したユース ケースになると思います。
ただし、API 呼び出しを受信するサーバーの 1 つを移植する場合は、少なくとも 1 つのイメージ インスタンスが常に稼働している必要があるため、おそらく Fargate を使用することになります。
コンテナに関して、非常に一般的な観点から言えば、コンテナが次のことを行うように設計されていると言っても差し支えないでしょう。
docker run <some_input>
そうなると、それはLambdaの仕事です。
しかし、コンテナが次のようなことを行うように設計されている場合:
docker run --expose 80
そうなると、それは Fargate の仕事になります。
これは良い例えでしょうか？
ベストアンサー1
これは良い例えの始まりです。ただし、Lambda には利用可能な CPU と RAM の制限があり、呼び出しごとに最大 15 分の実行時間に制限があります。したがって、より多くのリソースを必要とするものや、15 分以上実行する必要があるものは、Fargate の方が適しています。
また、「少なくとも 1 つのインスタンスを常に実行する必要がある」という理由で、何かが Fargate に適しているとおっしゃる理由がよくわかりません。Lambda + API Gateway は、API 呼び出しに最適です。API Gateway は常に API 呼び出しを受信する準備ができており、その後、Lambda 関数を呼び出してそれを処理します (応答がまだキャッシュされていない場合)。