Amazon Managed Service for Apache Flink

は、オープンソースののアプリケーションをサーバー管理なしで動かし、ストリーミングデータをリアルタイムに集計・結合・判定するサービスです。やを読み、5分ごとの集計やのような、過去のデータ (状態) を使う処理を秒単位の遅れで実行します。旧称は Amazon Kinesis Data Analytics です。

Point

旧称の Kinesis Data Analytics には SQL アプリケーションと Apache Flink アプリケーションがありました。SQL アプリケーション (Kinesis Data Analytics for SQL) は提供を終えており、今は Flink に一本化されています。SQL で書きたい場合も Flink SQL を使います。
Window (ウィンドウ) は、無限に続くストリームを時間で区切る「窓」です。
和訳
- Window: 窓
- Weblio英和辞書「window」

概要

のアプリケーションは、ソース (読み込み元) からレコードを読み、演算子で変換し、シンク (書き込み先) へ出力します。集計の途中結果などの状態はサービスが管理し、定期的にとして保存します。

開発方法	内容	向くケース
(アプリケーション)	Java、Scala、Python で DataStream や Table API、Flink を使って書き、JAR や ZIP をに置いてデプロイ	長時間動くストリーミング、本番運用、とテスト
Managed Service for Apache Flink Studio (ノートブック)	ノートブックで SQL、Python、Scala を対話的に実行	ストリームのアドホックな探索、試作。長時間動くアプリケーションへ昇格もできる

主要技術

①ウィンドウ集計 ⚠️ 頻出

ウィンドウ	区切り方	例
タンブリング (Tumbling)	重ならない固定長の区間	1分ごとの売上合計 (0:00〜0:01、0:01〜0:02 …)
スライディング (Sliding / Hopping)	固定長の区間を、それより短い間隔でずらす。区間が重なる	直近5分の平均を1分ごとに更新 (移動平均)
セッション (Session)	一定時間イベントが来なければ区切る。長さは可変	ユーザーの操作のまとまり (30分無操作で終了)

イベント時刻 (データが発生した時刻) で集計するか、処理時刻 ( が受け取った時刻) で集計するかも選びます。遅れて届くデータを正しい区間に入れたいならイベント時刻とウォーターマーク (どこまでのデータが揃ったとみなすかの目印) を使います。

⚠️ 頻出: 「1分ごとに重複なく集計」はタンブリング、「直近10分の移動平均を1分ごとに」はスライディング、「操作が途切れるまでを1回の訪問とする」はセッションです。

②状態とチェックポイント (ステートフル処理) ⚠️ 頻出

機能	内容
状態 (state)	ウィンドウの途中の合計、キーごとの前回の値、重複排除のための既出 ID など
	サービスが自動で定期的に状態を保存する。障害時はここから再開し、状態を失わない
	手動または停止時に作る状態の保存。アプリケーションの更新や復元に使う

チェックポイントとソース側の位置 ( のシーケンス番号、のオフセット) を一緒に保存するため、障害の後も状態と読み取り位置がずれません。の内部の状態については「正確に1回 (exactly-once)」の処理になります。外部への書き込みも正確に1回にするには、シンク側が対応している必要があります。

はで、関数の呼び出しをまたいで状態を持てません。長いウィンドウ、ストリーム同士の結合、キーごとの状態が必要なら Flink を選びます。

③ソースとシンク

種類	主なもの
ソース	、、 (静的な参照データ)
シンク	Kinesis Data Streams、、MSK、S3、、など

参照データ (例: 商品マスター) を S3 から読み込み、ストリームと結合して情報を補う (エンリッチメント) こともできます。

④スケーリングとコスト

項目	内容
KPU ( Processing Unit)	容量の単位。1 KPU は 1 vCPU と 4 GB のメモリ、50 GB のアプリケーション用ストレージ
Parallelism	アプリケーションの並列度 (既定 1)
ParallelismPerKPU	1 KPU あたりの並列タスク数 (既定 1、最大 8)。I/O 待ちが多い処理は大きくする
割り当て KPU	Parallelism ÷ ParallelismPerKPU
自動スケーリング	負荷の急増に合わせて KPU を増やし、落ち着くと徐々に減らす

アプリケーションごとに KPU の上限 (既定 64) があり、用に1 KPU が追加で課金されます。常時動くため、日次の集計のような処理に使うとコストが無駄になります。

⑤他のストリーム処理との選び分け

要件	選ぶもの
ウィンドウ集計、ストリームの結合、を秒単位で
1件ごとの軽い変換、通知	( のイベントソースマッピング)
変換してへためる (数分の遅れは許容)	(+ Lambda 変換)
の資産でマイクロバッチ処理	ストリーミング、の Spark Structured Streaming
Kinesis のデータをで分析	Redshift のストリーミング取り込み

試験対策

①判断マトリクス

問題文のキーワード	選ぶ機能・サービス
ストリームをリアルタイムに集計・分析、運用最小
1分ごとに重ならない集計	タンブリングウィンドウ
直近 N 分の移動平均	スライディングウィンドウ
無操作で区切るユーザーのまとまり	セッションウィンドウ
障害時に集計の途中結果を失わない	(処理)
ストリームをノートブックで対話的に探索	Managed Service for Apache Flink Studio
でストリームを処理	SQL (Kinesis Data Analytics for SQL は終了)
遅れて届くデータも正しい区間に	イベント時刻とウォーターマーク

②よくある誤答

for を新規の構成に選ぶこと。提供を終えています。
状態を持つ長い集計をで行うこと。状態はに任せます。
ストリームの集計を、いったんへ保存してで定期的に問い合わせる構成で代用すること。リアルタイム性の要件を満たせません。