
AWS ECS の活用シーンは?
こんにちは。Build サービス推進チームで Solution Architect として活動している t_maru です。 前回は Fargate の利用料金について書きましたが、今回は ECS がどのようなシーンで活用できるかを書いてみたいと思います。
Fargate の概要については簡単に前回の記事でまとめていますので興味があればどうぞ。
ECS 上でのコンテナ実行タイプ
ECS 上でコンテナを実行する方法は大きく分けて以下の 2 パターンがあります。
1. Service として実行
2. Task として実行
1 の Service として実行する方法は、例えば Web サーバのように常に動いている必要があるアプリケーションを動作させるときに使います。 Service の定義をする際に、いくつコンテナが起動している状態が望ましいのかなどの設定をすることができ、この Service の設定に従って Task (コンテナ) が必要な数だけ起動されることになります。(Auto Scaling の設定もできるのですが、ここでは簡略化のため説明を省いています。)
Service タイプの場合、常に指定した数の Task が実行されている状態になりますので、Service の設定で指定した Task が 1 以上の場合は動いている Task の分だけ常に課金される点は注意が必要です。
2 の Task として実行する方法は、AWS 上で起きた Event をトリガーに Task を実行したり、定期的に実行するバッチ処理などを行うため利用することになります。
このタイプは、処理が終わると Task を実行していたコンテナも停止されるため、処理にかかった時間のみ課金されることになります。
Event trigger による処理
前述で説明した Task として実行する場合の Event trigger についてもう少し説明します。 ECS の Task は CloudWatch Events と連携することができ、これにより AWS の各種リソースで発行される Event をきっかけに Task 起動や、定期実行なども可能になります。
Event 駆動による処理実行ですと、 Lambda の利用がまず頭に浮かぶんじゃないかなと思います。 大体の場合は Lambda にて処理可能かとは思いますが、以下のような場合においては ECS Task の利用も視野に入るのではないでしょうか。
- Lambda で割当できるメモリ容量では足りない
- Lambda のタイムアウトまでに処理が終わらない可能性がある
- Lambda がネイティブでサポートしている言語以外を使いたい
以下、 Lambda と ECS Task (Fargate 利用時) のメモリ容量とタイムアウトの比較表です。
| Service | Max Memory | Timeout |
|---------------|------------|------------|
| Lambda | 10 GB | 15 minutes |
| ECS (Fargate) | 30 GB | none |
箇条書きで記載した最後の Lambda がネイティブサポートしている言語以外を使いたい ですが、 Lambda にはカスタムランタイムというものが存在しており、任意の言語を使うことが可能ではありますが、 Docker Image で運用できる ECS の方が使い勝手が良いのではないかなと思います。
まとめ
今回の記事では ECS 上で動くコンテナの実行タイプと、Lambda との違いについて簡単に説明しました。
あらためて ECS の利用シーンの一例を挙げると以下のようなものがあるのではないでしょうか。
- 既にコンテナ化されているアプリケーションを手軽に実行したい
- EC2 の Auto Scaling よりも短時間で自動スケールさせたい
- Lambda では処理できないような重いバッチ処理を実行したい
- Lambda がネイティブで対応してない言語を使いたい
CloudWatch Events との連携により非常に多くのことができるようになっていますので、 Event 駆動の処理を考える際には Lambda だけでなく ECS も使えることを頭の片隅においておくと良いことがあるかもしれません。