ある IoT 企業は、50,000 台のデバイスからのセンサーデータを Amazon Kinesis Data Streams で収集し、AWS Lambda 関数でリアルタイム処理を行っています。ピーク時間帯（18:00〜22:00）に処理の遅延が発生し、ダウンストリームの分析ダッシュボードに古いデータが表示されるようになりました。 運用チームは以下の要件を満たすソリューションを求めています。 ・コンシューマーのラグ（処理遅延）を定量的に検出できること ・ラグがしきい値を超えた場合に自動アラートを送信すること ・追加インフラの構築を最小限に抑えること 最も適切なアプローチはどれですか？
Amazon Kinesis Data Streams の GetRecords.IteratorAgeMilliseconds メトリクスは、コンシューマーが最後に読み取ったレコードとシャード内の最新レコードとの時間差（ミリ秒）を示します。この値が増加するほどコンシューマーのラグが大きいことを意味するため、ピーク時の遅延検出に最適です。CloudWatch アラームと Amazon SNS を組み合わせることで、追加インフラを構築せずに自動アラートを実現でき、運用オーバーヘッドを最小化できます。 選択肢AのAmazon Kinesis Data Streams 拡張ファンアウト（Enhanced Fan-Out）は、複数コンシューマーが高スループットで独立読み取りするための機能です。SubscribeToShard.RateExceeded はリクエストレート超過を示すメトリクスであり、コンシューマーラグの定量計測には使用できません。 選択肢CのAmazon CloudWatch Logs Insightsによる分析は技術的に可能ですが、定期クエリの設定や集計ロジックの実装が必要で運用オーバーヘッドが増大し、ログ集計自体の遅延によりリアルタイム性も劣ります。 選択肢DのAmazon Data Firehose と AWS Glue を組み合わせるアーキテクチャはバッチ処理向けであり、リアルタイムのコンシューマーラグ検出には不向きで、コストと構成の複雑性が増加します。