AWS Lambdaは、サーバーレスアーキテクチャーのコンピュート層を支える中核のサービスだ。2014年の登場から4年以上が経過し、今では企業の中核的な処理でも使われようになっている。
基本機能は、データ格納や通知の到達などのイベント発生やスケジューラーをトリガーにして、JavaやNode.js、Pythonなどで書いたコードを、サーバーレスで実行するというものだ。コードはAWSがホストする基盤のコンテナにデプロイされ、独立したプロセス空間で実行される。
実際の処理時間にしか課金されないため、コスト効率に優れている。しかもスケーラビリティーが高く、実質的に無制限にLambdaファンクション（コードやミドルウエアをロードしたコンテナを指す）を立ち上げることができる。
Lambdaは2017年5月号で取り上げて、今回は2回目となる。そこで、2017年5月以降のアップデート情報を中心に解説する。
最初に、対応するプログラム言語とトリガーの拡充について紹介したうえで、他の新機能を見ていく。さらにアーキテクチャーパターンを二つ取り上げ、検証ではLambdaファンクションの起動時間を測定する。
キューを持つSQSがトリガーに
従来、コードのプログラム言語が限られたり、トリガー（イベントソース）になり得るAWSのサービスが少なかったりするといった制約があったが、これが改善され用途が広がっている。
プログラム言語は標準で、JavaScript（Node.js）、Python、Java、Go、C#（.NET）、Rubyが利用できる。このうちRubyは2018年11月に追加されたものだ。同じタイミングで、「Lambda Runtime Interface」が登場し、COBOLやPHPなども使えるようになった。Lambda Runtime Interfaceについては後述する。
トリガーになるサービスも、拡充されている（図1）。
2018年6月には、メッセージキューイングサービスのAmazon SQSが追加された。SQSでは内部で、キューから新しいメッセージを取り出しLambdaをコールする。その際のリトライ（再試行）の動作に特徴がある。
SQSは、Lambdaの呼び出しに失敗した場合、メッセージがキューに返り、再度呼び出しを行う（可視性タイムアウトという機能によって重複の呼び出しを防ぐ）。そのためLambdaの不具合でLambdaファンクションが起動しない、といった問題を回避できる。何度呼び出しても成功しない場合、メッセージはデッドレターキューに格納される。
従来は運用担当者がログを見て対応する必要があったが、この手間を軽減できる。
ただしLambdaの呼び出しに成功したら、Lambdaファンクションでの処理に失敗したとしても、メッセージはキューから消える。
