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などの相性は良さそうです。
※追記 下の方に記載のあるRDS Proxyを使用した構成によりこの同時接続数問題が解消されました。AWSは日々バージョンアップしていくので最新情報を追う必要があります。
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構築がうまく進められないという事態に陥ります。
Lambda + RDS Proxy + Secrets Manager + RDS 構成
LambdaからRDSに接続しようとした際のベストプラクティスを模索して辿り着いた１つの箇所として記録しておきます。
LambdaからRDSに直接接続すると、Lambdaが連続で実行された際にすぐに接続数上限に達してしまいます。ここでRDS Proxyを使用すると、接続が再利用される為これを回避することが可能となりました。
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として計算されるので注意が必要です。
※2021/02 追記です。バージョンアップにより1ms単位になったので小さい処理でも最低限の値段になりました。
メモリを上げると実行時間用の料金マスタから料金が高いテーブルが選択されてしまいますが、実行時間は短縮されるのでその分は安くなります。
この辺ありがたい事に「テスト」ボタンから実行時間やメモリ使用量など確認出来るので試してみると良いと思います。
単体実行のテストだけで、同時実行のテストはまだないので、実際に負荷かけてみないとわからない部分はありますが。
メモリ変えて試してみたというサイト様の情報が非常に参考になったのでリンク貼っておきます。
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の調査対応した記録
