【エンジニア必見】AWS Lambdaのざっくり解説(2/2)【費用削減方法も】

今回はエンジニア向けのがっつり技術系の話になります。

前回に引き続き、個人開発やITベンキャーなど小規模システム開発で話題？のAWS Lambdaについて紹介します。
ぼく自身の開発にも取り入れようと思い、調べてみたので共有します。

前回の記事をまだ読まれていない方は、こちらからお読みください。

前回の記事の簡単な復習

前回は、AWS Lambdaが、アプリのコードを書けば、あとはAWSがいい感じに実行してくれるサービスであることを以下の項目から紹介しました。

・起動の準備：AWS Lambdaにコードをアップロードしておく。
・起動のトリガー：他のAWSサービス(API Gateway,S3,SES,SQS,,,,)から起動される。
・動作方法：起動したタイミングでLambdaコンテナが作成され、そこで処理が実行される。コンテナは処理終了後、消滅する。
・課金制度：動かした時間分が課金される。

前回の記事では、「起動の準備」「起動のトリガー」について紹介しました。

AWS Lambdaの開発に利用できる言語、Lambdaは他のAWSサービスと連携することで機能すること、API Gatewayと連携することでAPIサーバの代替となり、APIサーバと比べ、コスト・スケーラビリティの上で優位であることを紹介させていただきました。

今回はその続き、「動作方法」から紹介していきます。

■動作方法：起動したタイミングでLambdaコンテナが作成され、そこで処理が実行される。コンテナは処理終了後、消滅する。

AWS Lambdaは、起動されたタイミングでLambdaコンテナというものが作成され、そこで処理が実行されます。そして、処理が完了したタイミングで”基本的に”消滅します。（”基本的に”については、あとで解説します。）

Lambdaコンテナは、実行環境、サーバーだと思っておけばよいでしょう。

このコンテナは呼び出された分だけ、作成されます。
つまり、2回呼び出されたら、2個のLambdaコンテナが作成され、並列処理で実行されます。呼び出された回数だけ、必要な分を自動で作成してくれます。アクセスが増えた際も、増えた分だけLambdaコンテナを作成してくれるので、スケーラビリティが高いです。安心ですね。

加えて、コストパフォーマンス面でもこの特徴は活きてきます。AWS Lambdaへの課金は、処理実行時間によって加算されます。そのため、サイトへのアクセスが少なかった場合は、費用がかかることはなく、アクセスが増えたさいに徐々にアクセス数に応じて費用がかかるようになることになります。その面から、AWS利用費用を必要最低限に抑えられるので、コストパフォーマンスとしても優秀です。

ここまでなんだか良いことづくしのAWS Lambdaちゃんですが、利用にあたっていくつか注意点があります。それがこちら。

注意①：1個のLambdaコンテナの最大実行可能時間は5分まで
注意②：Lambdaコンテナは再利用される
注意③：Lambdaコンテナの呼び出し数には上限がある

1つずつ見ていきましょう。

注意①：1個のLambdaコンテナの最大実行可能時間は5分まで

1個のLambdaコンテナの最大実行可能時間は5分までです。

Lambdaコンテナが、5分以上存在することはできない仕様となっています。

初見の方は、なかなか特殊な仕様に感じると思います。
ここが一番特殊にして、一番考えておかないといけない部分です。

え？！じゃあ処理の途中で5分が過ぎてしまったらどうなるの？？？
その実行可能時間は、課金したら伸びるの？？

結論：処理の途中で落ちます。そして伸ばすことは出来ません。

この特徴から、AWS Lambdaで実行される処理は5分以内の処理に収まるように、短くまとめる必要があります。従来のプログラミングのイメージで、日次の集計処理などを走らせると、途中でLambdaコンテナが消滅して、翌日変なデータになっちゃってるなんてことが起こってしまいます。

コードを短くすること以外の処理時間への対策としては、AWS Lambdaのメモリを増築するという方法もあります。AWS Lambdaのメモリは128MB～3GMまで、64MBごとに増加可能で、CPUパワーはだいたい「128MB：256MB：512MB　＝　1 : 2 : 4」になるそうです。メモリを増築することで、処理時間の短縮も検討してみてください。

注意②：Lambdaコンテナは再利用される

さきほど、Lambdaコンテナは呼ばれた数だけ作成され、その後消滅するということを紹介しました。しかし、いつもLambdaコンテナが削除、完全にリフレッシュされるわけではないようです。Lambdaコンテナ作成処理時間の短縮の為に、処理終了後、一定時間、Lambdaコンテナは残り、また呼び出されたときに再利用されます。

このLambdaコンテナの再利用で気を付けたいことは、これを意識せずコーディングすると、前の処理でのゴミが残ってしまうということです。それゆえ、使いまわされることを前提としたコーディングが必要となります。

注意③：Lambdaコンテナの呼び出し数には上限がある

Lambdaコンテナの呼び出し数には上限がある、そうです。
具体的にいくつかは調査できてません。もうしわけなしです。

■課金制度：動かした時間分が課金される。

AWS Lambdaは、動かした時間分が課金されます。

この動かした時間というのは、Lambdaコンテナが呼び出されて、処理が終わるまでの加算になります。そのため、呼び出された分だけの課金となるので、必要最低限の費用に抑えることができ、コストパフォーマンスが優秀であるということを先ほど紹介しました。

時間ごとの料金はメモリによって変化します。AWS Lambdaのメモリは128MB～3GMまで、64MBごとに増加可能で、CPUパワーはだいたい「128MB：256MB：512MB　＝　1 : 2 : 4」になるそうです。

メモリを増やすことで単純に処理時間が短くなるので、時間課金の面と合わせて考えると、「メモリを増築した方が結果として費用が抑えられる」ということもあるかもしれません。

最後に

2回にわたるAWS Lambda概要、参考になりましたでしょうか。

参考になりましたら、いいね！フォローをよろしくお願いします！筆者のやる気につながります！

今後は、具体的な実装についても書いていこうと思っています。

では

ばいやい。