こんにちは!
AWSサーバーレスによる開発を検討されている方は、FargateとLambdaの使い分け方法について一度は悩まれたことがあるかと思います。それぞれ実現できることに大きな差はないですが、サーバーレス開発者から言えば、インフラにおける制約、コストメリットにおいて差があるため、慎重に使い分けを検討する必要があります。
フルマネージドなサーバーレス製品だけど用途が異なる、Fargate と Lambda のユースケースについて、本記事では解説します。ぜひ参考にしていただき、サーバーレスアーキテクチャを組む判断材料としてもらえたら嬉しいです!
Fargate と Lambda は、それぞれサーバーレスですがコスト面で大きな差が有り、特にLambdaの方は実行に対するコストメリットがFargateよりも高い製品となっています。但しLambdaは後述で詳しく記載しますが、同時実行数の制約があるため、バーストアクセスや秒間数万件の処理にも不向きと言えます。
2020年末に、LambdaはDockerイメージのデプロイに対応しましたので、どちらも実行環境においては大差ないと言えますが、ECSのほうがインフラに対する柔軟性は高いので、柔軟性を求められる実行であればECSを選択するのも一つと言えます。
またそれぞれ、冪等性を担保できるという意味では、どちらも素晴らしいコンピューティングサービスです。冪等性とは、何度実行しても同じ結果が返ってくることを指します。
レガシーなシステム構成において冪等性を担保、実行する基盤を整えることは難しいことでしたが、現在は AWS などのクラウドプロバイダーが、インフラ面を抽象化してくれるため、開発者はインフラの意識を最小限に開発に集中することが可能です。
今回は Fargate と Lambda それぞれの使い分けを整理しながら本番で導入することを想定して解説していきたいと思います。
2つの違いをまとめたので以下の表をご覧ください。
Fargate | Lambda | |
---|---|---|
スケーリング | 常時起動するタスク数や実行コンテナの最大数等を指定可能 | 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や制約を抑えれば、その他学習することはない。 |
上記を見て分かる通り、Lambda には一部制約があります。その代わり低コストでアプリケーションのロジックを実行することができます。またイベントドリブンな動きをするため、必要なときに起動されるというコストパフォーマンスの高いサービスでもあります。
反対に Fargate はコンテナを利用するので、基本的には常時最低で 1 台は起動している状態です。そのためコストも必然と高くなっていきます。メリットはフルマネージドで制約が少ないため、重たい処理や長時間の実行が可能です。
2つのサービスを整理すると、以下の使い分けが考えられます。
これを踏まえると、まず Lambda が活躍できる場所はないかを考え、Lambda で実現が難しいことは Fargate に任せるといった思考フローでアーキテクチャを検討します。
また、上記以外にもLambdaはデプロイサイズの制約があるため、フロントエンドのSSRの実行にも不向きです。NuxtJSやNextJSなどのフレームワークをSSRさせる場合、しばしば制約との戦いとなります。SSRの実行環境には、Fargateを使用しましょう。
Lambda や Fargate を利用する上で考えていかなければならないのが、マイクロサービスアーキテクチャです。マイクロサービスとは、機能単位などに小さくシステムを切り分けることで疎結合なアーキテクチャになっているサービスのことを指します。対義としてモノリシックアーキテクチャーがあります。
マイクロサービスを前提にアーキテクチャを組んでいくと、AWS においては以下のようなユースケースでそれぞれを活かすことができます。
上記のように機能の特性に応じて Lambda や Fargate を使い分けます。とくにサーバーレスサービスはバーストに強いので、そういった可能性がある場合は Lambda に処理を任せるのがよいでしょう。同時実行数に制限がありますので、事前にアクセス数を試算の上、AWS サポートを通じた上限緩和申請が可能です。
またユースケースで挙げた最後の項目についてですが、こちらは開発者側のメリットが高いものとなります。Docker によるコンテナ開発に慣れた開発環境下では、数十個、数百個ある Lambda のアーキテクチャに対する把握が難しくなってくると思います。しかし Fargate であれば Docker 基盤で、Docker Compose などを利用してデプロイできるので、アプリケーションのアーキテクチャが把握しやすいです。
ちなみに Lambda でも Docker の実行がサポートされていますので、小さな単位でかつOSに依存する処理でも使用する事が可能です。バイナリー操作や文字コードの変換、その他OSに依存する処理でも心強いです。
運用面ではどちらもフルマネージドされたサービスになりますので、特別に注意する点は少ないかと思います。強いて言えば、Fargateではアクセス数に応じた実行タスク数の設定、実行中に発生するリソースの消費(CPU,RAM)を意識し、Lambdaは同時実行数と同じくリソースの消費(CPU,RAM)を意識すればよいかと思います。
インシデント監視には、どちらもCloudWatchAlarmが設定可能なので是非有効活用してみてください。
アプリケーションの複雑さにもよりますが、ほとんどのマイクロアーキテクチャーは Lambda は利用できます。Lambda でできないことも、Fargate という心強いコンテナサービスがありますので、アプリケーションを柔軟に実装できます。本記事でそれぞれのメリットが理解できれば幸いです。それぞれを上手く使い分け、運用面の負担軽減と開発の効率化で、幸せなサーバーレス開発を行ってください!
当ブログでは、AWS の記事をどんどん公開しておりますので、ご興味のある方は他の記事もご覧いただければと思います。
AWSサーバーレス・コンテナー に関する開発は、お気軽にお問い合わせください。
スモールスタート開発支援、サーバーレス・NoSQLのことなら
ラーゲイトまでご相談ください
低コスト、サーバーレスの
モダナイズ開発をご検討なら
下請け対応可能
Sler企業様からの依頼も歓迎