バッチ処理ミドルウェアとしてのメッセージブローカー
Kinesis Stream
2020/11に最大1年までデータ保持が可能になった
その前は最大7日程度までだったためストリーム処理メインでの使用だったがストリーム処理とバッチ処理のどちらにも利用出来るようになった
例えば最大1年保持しておいてバッチ処理が必要な1年以内のレコードであればタイムスタンプを指定して○月から○月までのレコードを取得してストリーム処理と同じコードでバッチ処理ということが出来る
get-record出来るのは特定のタイムスタンプからなのでiterateして終わりはコンシューマが判断する必要がある
ストリーム処理とバッチ処理の境界があいまいになってきた例
KafkaなどKinesisと同様なログベースのメッセージブローカー(LBMB)はストレージの保存容量だけログを保存出来るので以前からバッチ処理とストリーム処理を同じ処理系にすることは出来るが運用面で気軽に手を出せないところはあった
Kafka自体の運用、耐障害性の考慮、ストレージのモニタリング等
Amazon MSK というフルマネージドなKafkaも2019年より一般公開され東京リージョンでも既にGAで使えるので手は出しやすくなっている ストレージ容量、秒間スループット等キャパシティプランニングする必要はあるがより高度なユースケースに対応したストリーミングアプリケーション、バッチ処理プラットフォームを構築出来る
exactly-onceセマンティクス等も提供する
クラウド環境でのフルマネージドかつ気軽に利用出来るメッセージブローカーとしては現状Kinesisが最も長期間保証出来、メッセージのパーティショニング等も可能なため様々な用途へ使うことが可能になった
例えばデータ志向アプリケーションデザインにもあったスケーラブルで線型化可能なリクエスト処理バスとしてのメッセージブローカーにも使える
WebでのリクエストをWebSocketベースで行い、クライアントは特定のリクエストIDへのレスポンスをSubscribeする
サーバはリクエストしたユーザIDでパーティショニングしたKinesis StreamへリクエストIDと共にリクエストメッセージを送信しメッセージプロセッサは該当のリクエストを処理、レスポンスを構築しクライアントがsubscribeするリクエストIDへのレスポンスをpublishする
トランザクションによる抽象化が必要と思われる箇所はそれぞれパーティショニングし線型化が出来る
ユーザIDごとにパーティショニングされるためリクエストの順序保証がされる
ローカルでの再現性はKafkaほどではない(localstack等でemulateは出来るが完全なローカルコピーではない)のでローカルテストが難しくなる点はある
リソースに余裕があればフルマネージドKafkaで構築するとより広いユースケースに対応出来るだろう
初期のオーバーヘッドが小さいのはKinesis
バッチ処理ミドルウェアとしても使えるメッセージブローカー環境がクラウドで手を出しやすくなってきたためマイクロバッチでのストリーム処理が現実的になってきた
任意の期間のバッチ処理をしたい場合はその期間でのログを取得しメッセージをリプレイする
OLAP的な分析バッチ処理の場合はストリーム分析で特定のTumbling Windowまたはスライディングウィンドウへメッセージブローカーから取得したログを流しこむ
1ヶ月程度のTumbling Windowを設定しKafkaから取得したメッセージを全部流し込む等
ストリームとテーブルの結合が必要な場合はバッチ実行当時のDBスナップショットのローカルコピーをストリームコンシューマのローカルに復元する等でネットワークリクエストを無くせる
過去の時点でのテーブルを結合したい場合RDS等はPITRで戻せる上限等もあるため現実的にはバッチ実行の度にそのバッチを実行した時のDBの結合が必要なテーブルのローカルコピーを取得しバックアップしておくぐらいしか出来なそうではある
秒単位での完全なスナップショットは日単位での完全なスナップショットとレプリケーションログの再実行ぐらいしかなさそう