スタートアップCTOが解説するECS Fargateのユースケース&Lambdaの使い分け!😎AWSのサーバーレスコンピューティングを使いこなしましょう🐕

スタートアップCTOが解説するECS Fargateのユースケース&Lambdaの使い分け!😎AWSのサーバーレスコンピューティングを使いこなしましょう🐕

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!

AWSサーバーレスによる開発を検討されている方は、FargateLambdaの使い分け方法について一度は悩まれたことがあるかと思います。それぞれ実現できることに大きな差はないですが、サーバーレス開発者から言えば、インフラにおける制約、コストメリットにおいて差があるため、慎重に使い分けを検討する必要があります。

フルマネージドなサーバーレス製品だけど用途が異なる、FargateLambda のユースケースについて、本記事では解説します。ぜひ参考にしていただき、サーバーレスアーキテクチャを組む判断材料としてもらえたら嬉しいです!

想定する読者

はじめに

FargateLambda は、それぞれサーバーレスですがコスト面で大きな差が有り、特にLambdaの方は実行に対するコストメリットがFargateよりも高い製品となっています。但しLambdaは後述で詳しく記載しますが、同時実行数の制約があるため、バーストアクセスや秒間数万件の処理にも不向きと言えます。

2020年末に、LambdaはDockerイメージのデプロイに対応しましたので、どちらも実行環境においては大差ないと言えますが、ECSのほうがインフラに対する柔軟性は高いので、柔軟性を求められる実行であればECSを選択するのも一つと言えます。

またそれぞれ、冪等性を担保できるという意味では、どちらも素晴らしいコンピューティングサービスです。冪等性とは、何度実行しても同じ結果が返ってくることを指します。

レガシーなシステム構成において冪等性を担保、実行する基盤を整えることは難しいことでしたが、現在は AWS などのクラウドプロバイダーが、インフラ面を抽象化してくれるため、開発者はインフラの意識を最小限に開発に集中することが可能です。

今回は FargateLambda それぞれの使い分けを整理しながら本番で導入することを想定して解説していきたいと思います。

FargateLambda の使い分け

2つの違いをまとめたので以下の表をご覧ください。

FargateLambda
スケーリング    常時起動するタスク数や実行コンテナの最大数等を指定可能AWSマネージドによるオートスケーリングと、1,000のデフォルト同時実行数
※ 同時実行数は上限緩和による引き上げが可能
実行時間制約なし最大15分以内の実行時間
メンテナンスマネージドされている
CPU やメモリなどは指定する必要あり
マネージドされている
CPU やメモリなどは指定する必要あり
起動のタイミング         任意イベントが発生したら起動
※ EventBridgeを組み合わせることで任意のタイミングで実行も可
料金体系1 時間あたりの vCPU 単位 0.05056USD
1 時間あたりの GB 単位 0.00553USD
2022年現在の東京リージョン料金
リクエスト 100 万件あたり 0.20USD
2022年現在の東京リージョン料金
コスト面最低実行数を設定するため、EC2同様に実行に対して料金発生。Lambdaと比較してコストが高い。Auto Scaling で実行台数を節約することでコスト減が可能。必要なときにしか起動しないため、極めてコストが低い。また毎月リクエスト 100 万件 は無期限で無料枠となるため、少ないリクエスト数であれば実質無料。
学習コストECS というコンテナオーケストレーションについての理解が必須。また当然Dockerの知見も必須。実行OSや制約を抑えれば、その他学習することはない。
※ 2021年11月4日現在の情報です

上記を見て分かる通り、Lambda には一部制約があります。その代わり低コストでアプリケーションのロジックを実行することができます。またイベントドリブンな動きをするため、必要なときに起動されるというコストパフォーマンスの高いサービスでもあります。

反対に Fargate はコンテナを利用するので、基本的には常時最低で 1 台は起動している状態です。そのためコストも必然と高くなっていきます。メリットはフルマネージドで制約が少ないため、重たい処理や長時間の実行が可能です。

2つのサービスを整理すると、以下の使い分けが考えられます。

  • Lambda は短い処理に向いている、長く時間がかかったり重たかったりする処理には不向き。そのため処理時間が短く中規模程度のシステムであれば Lambda のメリットを最大限に引き出せる。
  • Fargate はコンテナのため自由度が高い、そのため Lambda でできないことは Fargate でカバーできる。そのためどのようなワークロードにも適している。

これを踏まえると、まず Lambda が活躍できる場所はないかを考え、Lambda で実現が難しいことは Fargate に任せるといった思考フローでアーキテクチャを検討します。

また、上記以外にもLambdaはデプロイサイズの制約があるため、フロントエンドのSSRの実行にも不向きです。NuxtJSNextJSなどのフレームワークをSSRさせる場合、しばしば制約との戦いとなります。SSRの実行環境には、Fargateを使用しましょう。

処理の時間以外でも使い分けを考えましょう

LambdaFargate を利用する上で考えていかなければならないのが、マイクロサービスアーキテクチャです。マイクロサービスとは、機能単位などに小さくシステムを切り分けることで疎結合なアーキテクチャになっているサービスのことを指します。対義としてモノリシックアーキテクチャーがあります。

マイクロサービスを前提にアーキテクチャを組んでいくと、AWS においては以下のようなユースケースでそれぞれを活かすことができます。

  • オートスケールを要するバースト発生処理は可能な限り Lambda で行いコスト削減
  • 重たい処理や容量の大きいファイルを扱う場合は Fargate を利用し安全に実行
  • PHP Laravel、Java PlayFramework等によるモノリシックアーキテクチャーの場合は Fargate で実行
  • AWS 内のCI.CDの拡張、運用・開発に関する自動化は Lambda で行いコスト削減
  • 様々な AWS サービスと連携する場合は、トリガーが簡単に設定できる Lambda を使う
  • Docker Compose を利用したい場合は、Fargate を使う(数十個の Lambda を管理しないモノリシックなアーキテクチャーとする場合)

上記のように機能の特性に応じて LambdaFargate を使い分けます。とくにサーバーレスサービスはバーストに強いので、そういった可能性がある場合は Lambda に処理を任せるのがよいでしょう。同時実行数に制限がありますので、事前にアクセス数を試算の上、AWS サポートを通じた上限緩和申請が可能です。

またユースケースで挙げた最後の項目についてですが、こちらは開発者側のメリットが高いものとなります。Docker によるコンテナ開発に慣れた開発環境下では、数十個、数百個ある Lambda のアーキテクチャに対する把握が難しくなってくると思います。しかし Fargate であれば Docker 基盤で、Docker Compose などを利用してデプロイできるので、アプリケーションのアーキテクチャが把握しやすいです。

ちなみに Lambda でも Docker の実行がサポートされていますので、小さな単位でかつOSに依存する処理でも使用する事が可能です。バイナリー操作や文字コードの変換、その他OSに依存する処理でも心強いです。

運用面ではどちらもフルマネージドされたサービスになりますので、特別に注意する点は少ないかと思います。強いて言えば、Fargateではアクセス数に応じた実行タスク数の設定、実行中に発生するリソースの消費(CPU,RAM)を意識し、Lambdaは同時実行数と同じくリソースの消費(CPU,RAM)を意識すればよいかと思います。

インシデント監視には、どちらもCloudWatchAlarmが設定可能なので是非有効活用してみてください。

関連記事

まとめ

アプリケーションの複雑さにもよりますが、ほとんどのマイクロアーキテクチャーは Lambda は利用できます。Lambda でできないことも、Fargate という心強いコンテナサービスがありますので、アプリケーションを柔軟に実装できます。本記事でそれぞれのメリットが理解できれば幸いです。それぞれを上手く使い分け、運用面の負担軽減と開発の効率化で、幸せなサーバーレス開発を行ってください!

当ブログでは、AWS の記事をどんどん公開しておりますので、ご興味のある方は他の記事もご覧いただければと思います。

AWSサーバーレス・コンテナー に関する開発は、お気軽にお問い合わせください。