【まとめ】AWS Lambdaポイント・どのようなサービスか?何と連携出来る?

https://aws.amazon.com/jp/lambda/

スポンサーリンク

概要

トリガー、処理、後処理を組み合わせて作れる機能です。AWSマネージド型の為、サーバレスでスケーラブルに使用出来ます。

AWSの機能をトリガーにして、自分で作った関数や用意されたテンプレートを実行出来ます。後処理も紐付けられるのでログ出力まで出来ます。

サーバレスで活躍が増えているサービスで、覚えておけば使いどころは多々ありそうです。小さくて試しやすいです。

サーバレス・マイクロサービス化時代の今、小さな処理がLambdaに置き換わっていってる感じがします。

Amazonは顧客至上主義で、ユーザの要望を聞いたりユーザの趣向を大事にしていますので、人気の高いLambdaは機能が凄い充実しているように感じます。

Lambdaで使用するメモリを128MBから約3GBまで64MB単位で設定出来たり、幅広いニーズに対応できるように、細かい段階設定が出来ます。

Lambda には node.js Ruby Python などを始め、Goでも処理を書けるようになりました。

LambaはAPIでコードから呼ぶ事も含めれば無限に組めますが、以下のLambda画面のようにAWSマネジメントコンソールでもぽちぽちと入力と出力を選択して組み込む事が出来ます。

AWS Lambdaを使う構成代表例

API Gateway + AWS Lambda構成

これまでメジャーだった構成です。Lambdaを使用してたREST APIを組む時に使われる事が多いように感じます。

注意点としては、 一気に同時実行される事が想定され、RDSはロック状態になる為、RDSとの相性は良くないようです。同時実行数のノウハウが必要になってきそうです。 DynamoDBなどの相性は良さそうです。

CloudFront + AWS Lambda@Edge構成

CDNとして世界各地に存在デプロイされたCloudFront・エッジに、Lambdaが付加出来ます。Lambda@Edgeは名の通り、エッジに存在しますので、よりユーザに近い場所でちょっとした処理(httpヘッダーを修正したり条件によって表示先を変えるABテストをしたり)を行う事が出来ます。

CloudFrontとのLambda@Edge構成については以下でも触れております。

https://normalblog.net/system/cloudfront-matome/

Application Load Balancer + AWS Lambda構成

ALB からLambdaをターゲットに出来るようになったので、LB の後段バックエンドとして小さな処理を任せる事も出来ます。また、Lambdaからhttpヘッダーを返せばリダイレクト処理やエラーページなど、httpステータスコードを返す簡単な処理などを気軽に実装する事も出来ます。

もちろんサーバとしても活用できますが、接続時間が現状では15分など決まりがある為、長い処理には向いていません。再帰処理でLambdaを呼び出したりする回避策もありますが。無限ループになる恐れ=料金無限の可能性がある為、再帰処理はしないでくださいとドキュメントには記載があります。

余談ですが、Lambdaが テキスト(http header)をLBに返しただけでリダイレクト処理が走ったりするところを見て、改めてクラウドは低レイヤーを意識しなくて済むようになったものの、低レイヤーの技術・仕組みを理解していないと、使いこなす事は出来ない。という事をしみじみと感じました。矛盾していますが。VPCの構築などにネットワークの知識が必要だったり、AWSを使用していて色々なところでこの低レイヤーの理解を深めないとAWS構築がうまく進められないという事態に陥ります。

ALB+Lambda構成手順概要
LambdaはALBにhttpヘッダーを返すだけなので、用途としては、一時的に503メンテナンス画面を出したい場合、30xリダイレクトをし...

Kinesis+Lambda構成

Kinesisはストリーミング配信をするサービスですが、ログなどの垂れ流しに使われ、ログから何かを検知する際や、整形する際にLambdaが使われます。これもぽちぽちと連携出来るパターンです。

S3+Lambda構成

S3に何かログ等がputされたら、それをトリガーとしてLambdaを稼働という構成も用意されております。S3にログが配置された時に整形したり出来ます。画像ディレクトリとしてS3を使用してれば、画像がアップロードされたタイミングで圧縮・変換したり、何かを実行する。といった事も想定の範囲内です。

各種通知にLambaを使用する構成

CLIを叩けばLambdaは動くのでスクリプトが組めればどこからでも動かす事は出来ますが、CloudWatch Eventsで何かのエラー等を検知させて、動作としてLambdaを選択し、Lambda内でメール送信やSlack通知等をするといった事も可能です。

などなど・・

Lambdaに関してはどこにでも設定出来るし人気サービスですので、EventBridgeを使用してDatadog外部サービスとの連携も可能です。Datadogで何かを検知したらLambdaが実行される。

自在な連携方法はありますが、なるべく用意されたもので構成を組み、出来なければ自在な連携で構成を組むといった方針が良いのかと思われます。

AWS Lambdaの料金ついて

リクエスト数による料金とメモリ別の実行時間による料金の合計となっています。

実行時間は100ms単位の切り上げとなっているので、例えば3msと早く終わっても100msとして計算されるので注意が必要です。

メモリを上げると実行時間用の料金マスタから料金が高いテーブルが選択されてしまいますが、実行時間は短縮されるのでその分は安くなります。

この辺ありがたい事に「テスト」ボタンから実行時間やメモリ使用量など確認出来るので試してみると良いと思います。

単体実行のテストだけで、同時実行のテストはまだないので、実際に負荷かけてみないとわからない部分はありますが。

メモリ変えて試してみたというサイト様の情報が非常に参考になったのでリンク貼っておきます。
https://recipe.kc-cloud.jp/archives/10437

AWS Lambdaの注意点

VPCでは遅くなる。インターネットインターフェースが再設定されるのに時間がかかるそうです。(そろそろこの問題の対応がされるそうです)

同時実行数は調整出来るものの、一気に同時実行される事が想定されるので、待ちになったりする為、RDSへの更新との相性は良くないようです。同時実行数のノウハウが必要になってきそうです。 DynamoDBなどの相性は良さそうです。

そもそも、LambdaはVPC内に設置する必要は原則的にはありません。AWSとしてもVPCのLambdaは非推奨です。ただし、プライベートDBに接続するなどであればVPCで接続する必要があります。ただ、それも上の方に書いたようにLambdaとRDSは相性が良くない為、バッドプラクティスなのではと感じました。しかも、VPC内に設置したのにLambdaから外部含めパブリック領域にアクセスしようとするにはNAT ゲートウェイの設定をする必要が出てきてしまい、またコストもかかってきます。

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html#lambda-vpc

AWS Lambdaの調査対応した記録

AWS Lambdaのログを出力・デバッグする為CloudWatchLogsに出力した
AWS Lambdaのデバッグ方法がわからず、とりあえずログを出力してデバッグしたかったのですが、調べるとCloudWatchLogに出力...
Lambdaデプロイ時の権限ポリシーにiam:Passroleも必要だった
Lambdaデプロイ時の権限ポリシーiam:Passroleも必要だったので記録しておきます。 Lambdaデプロイ時にはデプロイユ...