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

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

AWSチームのすずきです。

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

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

手順

Lambda関数作成

サンプルコードの選択

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

kinesis-lambda-at-time-01

Lambda関数設定

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

kinesis-lambda-at-timestamp-04

トリガ設定

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

kinesis-lambda-at-timestamp-02

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

kinesis-lambda-at-timestamp-03-2

トリガ有効化

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

kinesis-
lambda-at-timestamp-06

Lambda実行結果の確認

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

kinesis-lambda-at-timestamp-07

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

ログ出力結果

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

kinesis-lambda-at-timestamp-08

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

kinesis-lambda-at-timestamp-09

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

まとめ

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

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

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

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

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

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

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

参考