Amazon Managed Service for Apache Flink

解決する課題

Apache Flink は低遅延でステートフルなストリーム処理を行えるフレームワークですが、自前運用にはクラスタ構築・スケール・状態（ステート）の保存・障害復旧など重い運用負荷が伴います。Amazon Managed Service for Apache Flink（旧称 Kinesis Data Analytics）はこの運用部分を肩代わりします。

• 流れ続けるストリームを届いた端からミリ秒〜秒単位で集計・変換・分析したい
• ウィンドウ集計や結合など状態を持つ処理を、状態管理を自前で作らずに実行したい
• 負荷変動に応じたスケールや障害復旧を AWS に任せ、運用負荷を下げたい

主要概念と用語

• Apache Flink: ステートフルなストリーム処理を行うオープンソースの分散処理エンジン
• アプリケーション: Flink のジョブを実行する単位。ソースから読み、処理し、シンクへ書く
• ソース / シンク: 入力元（Kinesis、MSK など）と出力先（S3、OpenSearch など）
• ステート（状態）: 集計途中の値など、レコードをまたいで保持されるデータ
• チェックポイント / スナップショット: ステートを定期的に永続化し、障害時に復元する仕組み
• ウィンドウ: 一定時間や件数でレコードをまとめる単位（タンブリング、スライディング、セッション）
• イベント時刻 / ウォーターマーク: レコード発生時刻を基準に処理し、遅延データの扱いを制御する仕組み
• KPU（Kinesis Processing Unit）: 計算・メモリ容量の単位。料金とスケールの基準
• Studio ノートブック: ノートブック上でインタラクティブにストリームを分析・開発できる環境

仕様・制限・クォータ

• アプリケーションは Java / Scala / Python（PyFlink） で記述するほか、SQL ベースの記述や Studio ノートブックでの開発に対応する
• 並列度は KPU 数に応じて決まり、負荷に合わせてオートスケールを有効化できる
• ステートやチェックポイントは耐久性のあるストレージに保存され、障害時に前回スナップショットから復元される
• ソース・シンクには Kinesis Data Streams、Amazon MSK、Amazon S3 など Flink のコネクタ経由で接続する
• KPU 数・アプリケーション数・並列度などには上限があり、設計時に確認が必要

具体的な KPU 上限・並列度の既定値・対応 Flink バージョンはリージョンや時期で変わるため、最新の公式ドキュメントで確認してください。

内部の仕組み

アプリケーションは Flink のジョブグラフとして実行され、ソースから読み込んだレコードを並列に処理してシンクへ書き出します。集計や結合の途中結果はステートとして保持され、ウィンドウやイベント時刻に基づいて確定したタイミングで出力されます。

可用性と正確性はチェックポイントが支えます。サービスはステートを定期的に永続ストレージへ保存し、ノード障害が起きてもジョブを自動的に再起動して前回のチェックポイントから処理を再開します。これにより、設定に応じて**厳密に1回（exactly-once）**または最低1回の処理セマンティクスを実現できます。

設計パターン / ベストプラクティス

• 取り込みは Kinesis Data Streams / MSK、処理は本サービス、結果の蓄積は S3、検索・可視化は OpenSearch という流れで組む
• ウィンドウ集計は要件に応じてタンブリング（重複なし）/ スライディング（重複あり）/ セッションを使い分ける
• 並列度はソースのパーティション（シャード）数と整合させ、ボトルネックを避ける
• 負荷変動が読めない場合はオートスケールを有効化し、KPU を需要に追従させる
• 簡単な集計や試作は Studio ノートブックや SQL ベースで素早く検証し、本番は Java/Python アプリへ移す

運用・監視

• CloudWatch で numRecordsInPerSecond などのスループットや、KPU 使用率、処理遅延を監視する
• チェックポイントの所要時間や失敗回数を監視し、ステートが肥大化していないか確認する
• 入力ストリームの**コンシューマ遅延（イテレータ年齢）**を見て、処理が追いついているかを判断する
• デプロイ更新や障害復旧ではスナップショットを活用し、ステートを失わずにアプリを再開する
• 詳細なジョブ状態の確認には Flink ダッシュボードを利用する

コスト

• 主なコストは実行に使う KPU の稼働時間で、並列度とオートスケールの設定が費用に直結する
• アプリケーションのステート保存に使うストレージや、関連サービス（Kinesis、MSK、S3 など）の利用料も別途かかる
• 常時稼働するため、不要なアプリは停止し、並列度を実負荷に合わせて見直すとコストを抑えられる

実際の料金は KPU 数・リージョン・構成で変わるため、見積もりは公式の料金ページで確認してください。

セキュリティ

• アプリケーションは VPC 内のリソース（MSK ブローカや RDS など）へ接続でき、ネットワークを閉域に保てる
• ソース・シンクや他サービスへのアクセスは IAM ロールで最小権限を付与する
• 保存データは KMS による暗号化、転送時は TLS で保護される
• アプリケーションコードやアーティファクトは S3 などに置き、アクセスを IAM で制御する

関連サービス・比較

リアルタイム処理でよく比較される Amazon EMR（Spark Streaming など） との違いを押さえます。本サービスは Flink に特化した低遅延・ステートフル処理をフルマネージドで提供し、EMR はバッチを含む汎用的なビッグデータ処理基盤を柔軟に構成できる点が異なります。

ハンズオン / CLI例

# Flink アプリケーションの作成（コードは S3 に配置、ロールは事前作成）
aws kinesisanalyticsv2 create-application \
  --application-name demo-flink \
  --runtime-environment FLINK-1_18 \
  --service-execution-role arn:aws:iam::111122223333:role/flink-app-role \
  --application-configuration '{
    "ApplicationCodeConfiguration": {
      "CodeContent": {
        "S3ContentLocation": {
          "BucketARN": "arn:aws:s3:::my-flink-code",
          "FileKey": "app.jar"
        }
      },
      "CodeContentType": "ZIPFILE"
    }
  }'

# 作成したアプリケーションの起動
aws kinesisanalyticsv2 start-application \
  --application-name demo-flink