s3:ObjectCreatedをイベントソースにするLambdaはオブジェクト作成時のメソッドに気をつける
丹内です。S3へのオブジェクト作成で起動するLambdaと関わるRailsアプリを作るときに、すこしハマりました。
背景
carrierwaveuploader/carrierwave gemは、Ruby製webアプリからファイルをクラウドにアップロードする際によく使われる便利なgemです。
S3へアップロードさせたいときは、ストレージアダプタとしてsorentwo/carrierwave-awsやfog/fogが使われることが多いと思います。
今回のアプリでは、最初carrierwave-awsを使っていましたが、諸事情によりfogへ切り替えたのですが、その時に問題が起こりました。
s3:ObjectCreated
「S3にオブジェクトが作成されたとき」というよくあるLambdaのイベントソースは、以下のものがあります。
- s3:ObjectCreated:*
- s3:ObjectCreated:Put
- s3:ObjectCreated:Post
- s3:ObjectCreated:Copy
- s3:ObjectCreated:CompleteMultipartUpload
それぞれPUT、POST、COPYなどのS3 APIに対応しており、指定したメソッドでのみ起動するLambda Functionを設定できます。 ワイルドカードを使うと全てのメソッドで起動するLambda Functionとすることができます。
注意点
S3バケットへのオブジェクト作成方法のうち、ここではPUTとPOSTを考えます。
どちらもオブジェクトの作成ですが、POSTを使うとサーバを介さず直接S3にオブジェクトを作成することができます。
詳細はドキュメントをご覧ください。
Lambda Functionに指定したイベントソースに一致したメソッドでオブジェクトが作成された時のみ、Lambda Functionは起動します。
gemなどサードパーティ製のライブラリを使う場合は、どちらのメソッドを使っているかを確認しないと、ライブラリを変更した時に意図せずLambda Functionが起動しなくなるかもしれません。
あるいは、s3:ObjectCreated:*とワイルドカードを指定する必要があるかもしれません。
まとめ
ライブラリ自体がプラガブルでも、隠蔽しているAWSの操作には注意が必要です。
ライブラリを変更してから突然Lambda Funcitonが起動しなくなった際には、適切なイベントソースになっているかを確認してみてください。
