Kinesis Data Streams についてしらべたこと
基本
Kinesis Data Streams のアーキテクチャ、用語などについてはここをみる。 コンシューマー
コンシューマーは Lambda で作ると、運用含めて楽で良さそう。 1つめの方法では、Kinesisへの定期的なポーリングでデータの読み取りが行われる。
2つめの方法では、ストリームコンシューマと呼ばれる専用接続を作成し、これは HTTP/2 の持続的な接続のため、パフォーマンスが良い。また複数のコンシューマがある場合でも、独立したスループットを提供できるようだ。
これは、いわゆる拡張ファンアウト という後からアップデートで追加された機能で、追加料金が発生する。 Lambdaの実行
バッチサイズ
一回のlambdaで、まとめて処理するレコード量を設定できる
バッチサイズに満たなくてもストリームにレコードがあれば実行される
バッチサイズ以上のレコードがストリームにあれば、次のポーリングを待たずに連続実行される。
バッチサイズを増やせば、基本的にはスループットが上がるケースが多い？メモリの割り当ては増やす必要がある
エラー処理
処理中にエラーが発生した場合にどうするか。
Lambdaでは、呼び出しのタイプによって、エラー時の挙動が変わる。
ストリームベースでない、ポーリングベースのイベントソース – Kinesis Data Streams または DynamoDB で構成されます。Lambda 関数呼び出しが失敗した場合、AWS Lambda はデータの有効期限が切れるまで、最大 7 日間、レコードのエラーが発生したバッチを試みます。例外はブロックとして扱われ、失敗したレコードのバッチの有効期限が切れるか処理が成功するまで、AWS Lambda ではシャードから新しいレコードの読み込みが行われません。こうすることで、確実に AWS Lambda で順番にストリームイベントが処理されます。
注: これは多分訳が間違っており、 「ストリームベースである、ポーリングベースのイベントソース 」が正しいだろう
Kinesisでエラーが発生した場合は、同じバッチに対してリトライが行われる。Kinesis のストリームのデータ保持期限は(デフォルトで)24hなので、その間リトライが続く。
リトライ中はエラーが解消されるまで、後続の処理は行われない。 リトライの間隔は Exponential backoff で最大60sまで伸びる。
エラーの原因が一時的なものでない場合は、問題が大きくなるので、早めに気づいて復旧できるようにする必要がある。
また、同じレコードが複数回処理されても、問題がおきないようにしておく必要がある。(冪等性) 料金
Lambda の料金は リクエスト回数(実行回数) x メモリ割り当て量 x 実行時間 で決まる