日本のAWS関係者がre:Inventの発表で盛り上がっているなか、風邪ひいて寝込んでました。季節の変わり目には、気をつけましょう。
さて、そんな感じで全然追いつけていませんが、特に面白いなぁと思ったのが、S3 Event NotificationsとAWS Lambdaです。Lambdaについてはまだ触っていないので何ともいえない部分がありますが、発表内容を見る限りインフラの在り方を変えるような存在かもしれません。そして、S3のEvent Notifications。これ、めちゃくちゃ便利です。S3のイベント(現在は、putとpushとcopy)が発生したら、SNSやSQSに通知を送れるという機能です。何が便利かというと、ファイルのアップロードをトリガーに処理を書けるということです。頭に浮かんだユースケースを1つ書いてみます。
S3 Event Notificationsを使ったクローラーのユースケース
最近、クローラー開発のステマばかりしているので、今回もそのケースで説明してみます。処理の流れとしては、下記のようなものを想定します。
- データをダウンロードする
- ダウンロードしたデータを生データとしてS3に保存する
- S3の未処理の生データを取得して、加工処理をおこなう
この処理の中で、3の部分が少し曲者になります。未処理のデータが何かというのを特定する方法が必要になるからです。今までの対処方法としては、次のような方法が考えられます。
- 処理前/済みのデータを管理するデータベース等を用意する
- 処理前と処理済みでディレクトリをわけて、処理が終わったら移動させる
- 2の保存と同時に、SQSに登録する
一手間があって面倒くさいというのが実情でした。また、処理サーバを複数にすると排他制御の仕組みが必要になり、複雑になります。3の処理が一番楽なのですが、S3に直接データだけアップしたいというようなケースには対応できません。
S3 Event Notificationsを使えばどうなるのでしょうか?
下に簡単な図を載せていますが、クローラーはただデータを集めて保存するだけに徹すればよいことになります。その後のS3⇒SQS⇒(EC2上での)処理は、良きに計らえという状態になります。疎結合なアーキテクチャになりますよね。また処理サーバをキューの数に応じたAutoScaleにしておいたら、処理が溜まったら自動的に増強してくれます。
S3 Event Notificationsをユースケースの妄想
この他にも、いろいろな使い道が考えられます。みなさん、いろいろ妄想してみてください。
- ElasticTranscodeと連携して、アップロードしたら動画変換
- サーバーレスで、SNSを発行するトリガー
- (Getイベントに対応したら)メッセージを読んだら自動的に削除
- (Getイベントに対応したら)メッセージを読んだら自動的に爆発
S3 Event Notificationsの使い方
未来有望なS3 Event Notificationsです。妄想するだけでなく、実際に使ってみましょう。通知を送るだけであればAWSマネージメントコンソールだけで簡潔できます。
手順としては、次の通りです。
- SQS(SNS)を作成し、パーミッションの設定をする
- 新規もしくは既存のS3バケットに、Event設定をする
- ファイルをアップロードする
- SQS(SNS)を確認する
まず1つ目ですが、今回はSQSの例を紹介します。ポイントは、パーミッション設定です。
対象のバケットからの通知を許可します。具体的には、SourceARNでStringLikeの条件をつけます。
2つ目のS3バケットへの設定は、簡単です。
バケットのPropertyの、Eventの項目を設定します。
先ほどの権限設定がうまくいっていないと、下記のようなエラーがでます。
Unable to validate the following destination configurations :Permissions on the destination queue to not allow S3 to push notifications from this bucket
ファイルをアップロードすると、設定が上手くいっていればSQSの画面からキューが登録されているのを確認できます。