AWS Lambda は FaaS (Function as a service) と呼ばれるサービスで、 その名の通り、関数を実行するというシンプルな機能をサービス化したものです。
もちろん、その関数はどこかのコンピュータで動いている はず なのですが、開発者はそれを意識する必要はありません1。 AWSのマネージドサーバで実行されるので、コンピュータを管理する必要もないし勝手にスケールもしてくれます。 関数は様々な方法で呼び出すことができ、直接実行するだけでなく、AWSの他のサービスから実行されるようにトリガーを設定することもできます。
メジャーな使い方としては大きく2つあり、
- 他のAWSサービスからイベントを受けバッチ処理などを非同期で行う
- ALBやAPI Gatewayが受けたリクエストをリアルタイム処理する
に分けられます。 特に後半の使い方がサーバレステクノロジーと言われて最近人気です。
Lamdaでのプログラミングは、既存のプログラミング手法とは思想を変える必要があります。 ひとつの関数は、UNIX哲学にもある ひとつのことを上手くやる ような作り方をします。 Railsアプリのような モノリシック な巨大な機能群のかたまりはLambdaの思想とマッチしません。 環境はリセットされ、毎回ロードされるので、そもそも大きなライブラリを読み込むことは間違ったやり方です。 当然、状態を保存するようなこともできないので、関数の 副作用 にあたるものは、AWSの様々なサービスを組み合わせて実現する必要があります。
ここで例として、Webアプリケーションでありがちな、「画像をアップロードしてついでにサムネイルを作る」という機能を考えてみましょう。
既存のアプリケーションでは、
- ファイルアップロードのリクエストを受け付ける
- アップロードされた画像をS3に保存する
- サムネイルを作ってS3に保存する
- S3のURLをデータベースに保存する
- レスポンスを返す
というような1つのエンドポイントを作ることが多いでしょう。 言語やフレームワークによっては、何も考えなくても全てやってくれるライブラリ2が存在することもあるでしょう。
これを、AWSの機能とLambdaを使うと、このように作れます。
- Cognitoで一時的な権限を発行する
- ブラウザから直接S3に画像をアップロードさせる
- S3に画像がアップロードされたことをトリガーにしてLambdaが実行される
- Lambdaでサムネイルを作ってS3に保存
S3のURLを保存するには、Lambda内でデータベースに登録することもできるし、 ファイルをアップロードする代わりにURLを渡すエンドポイントを作ってもいいでしょう。
これだけでも、登場人物は Cognito, S3, Lambda と、裏で重要な働きをしている IAM と、どう実装されてるかさっぱりわからない トリガー がいます。 小さな機能が有機的に繋がってシステムを作り上げる感覚です。
大きな違いは、サーバとファイルのやり取りをしないことです。 サーバがファイルを扱わないので、余計な通信も発生しないし、サーバのI/O待ち時間も減らせます3。
難点としては、やはりAWSの広い知識が求められることです。 実現したい機能のためにはどのようなAWSのサービスが利用できるのか、 従来の方法で使ってきた範囲のAWSの知識でとはまるでかすりもしないということも多々あります。 今まで存在すら知らなかったサービスを、ひとつひとつ調べることになるかもしれません。 特に、従来の方法では結構雑でも問題なかった 権限設計 がとても重要になるので、 IAMの高い理解が必要になります。