[セッションレポート] AWS Lambda Introduction #reinvent
本日 re:Inventで発表された「AWS Lambda」の紹介セッションに参加してきました。以下レポートです。
導入
- 例えばS3にアップロードされた画像ファイル全てに対して何か処理を実行したい時、やりたいことは少しでも大掛かりな仕掛けが必要になる。
- アップロードをプロキシするサーバを置く
- アップロードされたファイルのパスをSQSにエンキューする
- ワーカーが処理する
- それらのサーバが無停止で動いているかどうかを監視する
- And so on.
- もっとユーザにとって簡単なやり方があるはず、というのがLambdaのコンセプトの一つ
Lambda
- イベントドリブンなコンピュートリソース
- ステートレス
- 他のAWSサービスに対するアクションによりトリガーされる
- S3へのPutObject
- Dynamoへの書き込み
- EC2 Lifecycle Transition
- その他全てのAWSリソースの変化
- JSONをAPI経由で渡すことでカスタムイベントを引き起こすことも可能
特徴
- インフラの管理不要。ビジネスロジックを書くことに集中できる
- イベント数に応じた自動スケーリング
- 自分で書いたコードを利用できる。
- 低い利用料金
動作するコード
- 対応言語は、現状はNode.jsのみ。今後対応幅を広げていく
- AWS SDKとImageMagickはビルトインで入っている。その他の必要なライブラリはコードと一緒にアップロードすることで利用可能
- Lambdaはステートレスであるので、永続的なストレージ領域を持たない。保管が必要なデータはS3/Dynamoで管理する必要がある
- 実行されているOSにログインすることは出来ない。
- スレッドやソケット通信、/tmpへの書き込みなどは自由にできる。
- LambdaへのInbound通信はできない
- アプリケーションによって利用するメモリ領域を割り当てる。128MBから1GBまで64MB単位で指定可能
- 利用しているメモリ量などはCloudWatch Metricsにて追跡可能
- 実行ログはCloudWatch Logsに送られる
デモ
ここでデモが行われました。S3に画像がアップロードされたらその画像のサムネイル画像を作成してS3に保存する、というコードが実行され、成功すると会場から拍手が起こりました。
現在のベストプラクティス
- LambdaにはIAM Roleを紐付けることになるので、そこでの権限制御は重要になってくる。
- Lambda内で再帰的に処理することがないように注意する。
- 例えばデモのようなサムネイル作成のコードを書くときには、サムネイル画像のアップロード時にもLambdaがトリガーされるので、そこを考慮しないコードを書くと永久にサムネイルを作成し続けてしまうことになる。
まとめ
現状、AWS LambdaはLimited Preview版となっているため、まだ触ることはできませんが、今までEC2で構築していたワーカーのタスクなどを実施するためのインフラを管理する必要がなくなると考えれば非常に価値的なシステムではないでしょうか。対応言語や対応するイベントなどが今後拡張されていけば、本当にEC2を使わずにシステムが構築できてしまうかもしれません。夢が広がりますね!