ある広告テクノロジー企業は、リアルタイムの広告インプレッションデータをAmazon Kinesis Data Streamsに毎秒100万件送信しています。5分間のタンブリングウィンドウで広告ごとのクリック率（CTR）をリアルタイムに集計し、閾値を超えた広告IDをAmazon DynamoDBに即時書き込む必要があります。さらに、ストリーム処理においてexactly-onceセマンティクスによる重複排除も必須です。最適なアーキテクチャはどれですか？
Amazon Managed Service for Apache Flink（旧Kinesis Data Analytics for Apache Flink）は、Apache Flinkベースのストリーム処理エンジンをフルマネージドで提供します。タンブリングウィンドウ・スライディングウィンドウなどの時間ベースのウィンドウ集計をネイティブにサポートし、チェックポイントメカニズムによるexactly-onceセマンティクスも標準機能として提供されます。Kinesis Data Streamsとのネイティブ統合により低レイテンシの処理が実現でき、DynamoDBへの書き込みコネクタも利用可能です。 選択肢BのAWS Lambdaはイベント単位の処理が得意ですが、タンブリングウィンドウの時間ベース状態管理にElastiCacheの追加管理が必要で、exactly-onceの保証の実装も複雑になります。 選択肢CのKinesis Data Firehose + S3 + Athena経由のアーキテクチャは分析バッチ処理向けであり、リアルタイムのウィンドウ集計と即時DynamoDB書き込みには遅延が大きく適していません。 選択肢DのEMR上のSpark Streamingはマイクロバッチ処理モデルであり、真のリアルタイムウィンドウ集計にはFlinkより不向きで、常時稼働クラスターの管理コストも増大します。