AWS Fargateのユースケース&Lambda関数との使い分けを解説!サーバーレスとコンテナーサービスの思考フロー🤔

AWS Fargateのユースケース&Lambda関数との使い分けを解説!サーバーレスとコンテナーサービスの思考フロー🤔

こんにちは!

今回はフルマネージドでサーバーレスなサービスだけど用途が異なる、Fargate と Lambda のユースケースについて解説していきます。ぜひ参考にして、アーキテクチャを組む判断材料としてくれたら嬉しいです!

想定する読者

  • Fargate と Lambda のユースケースを理解したいヒト
  • Fargate と Lambda について詳しくなりたいヒト

はじめに

Fargate と Lambda はコンテナとサーバーレスなので、利用方法が多少異なります。しかしながら冪等性を担保できるという意味では、どちらも素晴らしいサービスです。冪等性とは、何度実行しても同じ結果が返ってくることを指します。

古いアプリケーションにおいて冪等性を担保している実行基盤を整えることは難しいことでしたが、現在は AWS などのクラウドプロバイダーが抽象化してくれた基盤を借りることでそれを容易に実現できます。

今回はコンテナサービスである Fargate とサーバーレスサービスである Lambda の使い分けを整理しながら本番で導入することを想定して解説していきたいと思います。

Fargate と Lambda の使い分け

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

FargateLambda
スケーリング    マネージドされている
ただし起動するコンテナの最大数は指定する必要あり
マネージドされている
実行時間制約なし15分以内
同時実行数にも制限あり
メンテナンスマネージドされている
CPU やメモリなどは指定する必要あり
マネージドされている
CPU やメモリなどは指定する必要あり
起動のタイミング         任意イベントが発生したら起動
料金体系1 時間あたりの vCPU 単位 0.05056USD
1 時間あたりの GB 単位 0.00553USD
(東京リージョン)
リクエスト 100 万件あたり 0.20USD
(東京リージョン)
コスト面EC2同様、リクエストがなくともサービスを提供している時間であれば起動していなければならないため、使われていなくともコストは発生する。Auto Scaling で多少はコストを節約することができる。必要なときにしか起動しないため、かなりコストが低くなる。また毎月リクエスト 100 万件 は無期限で無料枠となるため、少ないリクエスト数であれば実質無料で使える。
学習コストECS というコンテナオーケストレーションについて
ある程度理解する必要がある
特性さえ理解すれば
ほかに学習することはない
※ 2021年11月4日現在の情報です

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

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

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

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

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

処理の時間以外で使い分けを考える

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

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

  • バーストが発生しがちな処理は可能な限り Lambda で行う
  • 重たい処理や容量の大きいファイルを扱う場合は Fargate を利用する
  • AWS 内の運用や開発に関する自動化は Lambda を使う
  • ほかの AWS サービスと連携する場合は、トリガーが簡単に設定できる Lambda を使う
  • Docker Compose を利用したい場合は、Fargate を使う(数十個の Lambda を管理したくない場合など、Lambda よりはシステムの可読性が高くなります)

上記のように機能の特性に応じて Lambda や Fargate を使い分けます。とくにサーバーレスサービスはバーストに強いので、そういった可能性がある場合は Lambda に処理を任せるのがよいでしょう。実行数に制限はありますが AWS サポートを通じて上限緩和申請ができますので、AWS サポートにこの点は必ず問い合わせして実現可能かどうかを判断していきましょう。

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

ちなみに Lambda でも Docker はサポートされています。この場合、小さな単位でかつOSに依存する処理ので使用するケースが多いです。

運用面ではどちらもフルマネージドされたサービスになりますので、特別注意する点は少ないかと思います。なのでまずはアプリケーションの要件に応じてどれが適切なのかを考えてみてください。

関連記事

まとめ

アプリケーションの複雑さにもよりますが、ほとんどのパターンで Lambda は利用できます。Lambda でできなくても、Fargate という心強いコンテナサービスがありますので、アプリケーションを柔軟に実装できます。本記事でそれぞれのメリットが理解できれば幸いです。どんどん管理や運用面の負担を軽減して、サーバーレスなアーキテクチャにしていきましょう!

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

AWS に関する開発は、お気軽にお問い合わせください。