[Kinesis] Lambdaのイベント設定時、開始時刻(AT_TIMESTAMP)の指定が可能になりました

はじめに

AWSチームのすずきです。

2016年12月のアップデートにより、LambdaのイベントソースとしてKinesis Streamsを利用する際、 「AT_TIMESTAMP」、指定時刻以降に登録されたレコードを対象とした利用が可能となりました。

今回、Lambdaのサンプルコードを利用し、イベントソースのKinesis Streamsから 指定時刻以降に登録されたデータの取得を試みる機会がありましたので、紹介させていただきます。

手順

Lambda関数作成

サンプルコードの選択

• AWSのマネジメントコンソール上でBlueprintとして公開されている、 Lambdaのサンプルコード(kinesis-process-record-python)を利用しました

Lambda関数設定

• コードはサンプル、ロールはデフォルト(Create new role from template)のものを利用しました。

トリガ設定

• データ登録済のKinesis streamsを、データソースとして指定します
• Starting Positionとして、今回利用可能となった「At timestamp」を指定します

• 時刻(Timestamp)は、UTCで指定します。

トリガ有効化

• トリガを有効化し、Lambda関数を実行します。

Lambda実行結果の確認

• Cloudwatch Logsのログを確認します。

• ログストリームを確認します

ログ出力結果

• ログストリームを指定し、最も古いレコードに遡ります。

• 指定時刻(UTC時刻で12/7 12時、JTCでは12/7 21時)以降のレコードから、処理が開始された事が確認できました。

• レコードに記録された時刻情報はデータ送信元の時刻をJSTで示します。
• Kinesis送信前のバッファリングや、送信完了までのタイムラグが存在します。

まとめ

従来、Kinesis StreamsをLambdaのイベントソースとして利用する場合、取得開始地点の指定は、

• TRIM_HORIZON : ストリームに存在する最も古いレコード
• LATEST : 現在以降に登録されたレコード

から選択する必要がありました。

しなしながら、多くのレコードが登録されるストリームや、ストリーム上のデータ保存期間を延長していた場合には、 TRIM_HORIZONでは対象データが多くなりすぎ、エラー発生時に再処理が困難。 また、データの登録元が夜間に停止するなど、稼働時間が限定されるシステムでは、データが届かない時間の検証が 難しいこともありました。

• AT_TIMESTAMP : 指定した時刻以降にストリームに登録されたレコード

の利用、APIやCLIでは2016年春より利用可能となっていた機能でしたが、Lambdaでも利用が可能となった事で、 べき等性の確保が容易となり、運用性や開発効率の向上が期待できます。

先日リリースされたLambdaのDLQ対応など、確実に進化を続けるAmazon Kinesis。これからも注目です。

参考

• [新機能]Kinesis Streamsが時刻ベースのイテレーターに対応しました
• 【新機能】AWS LambdaがDead Letter Queueをサポートしました #reinvent