あるデータエンジニアリングチームは、Amazon MSK（Managed Streaming for Apache Kafka）を使用してリアルタイムデータパイプラインを運用しています。 コンシューマーアプリケーション（Amazon EC2 上で稼働）が Kafka トピックのメッセージ処理に遅延した場合に早期検知し、チームへアラートを送信したいと考えています。 追加の開発コストを最小限に抑えながらコンシューマーの処理遅延（コンシューマーラグ）を監視するために最も適切な方法はどれですか？
Amazon MSK は CloudWatch に OffsetLag メトリクスをネイティブに公開しており、コンシューマーグループとトピックパーティションごとの処理遅延（最新オフセットとコミット済みオフセットの差）を追加開発なしに監視できます。CloudWatch Alarm と SNS を組み合わせることで処理遅延の早期通知が実現できます。 選択肢AのCloudWatch BytesInPerSec メトリクスはブローカーへのデータ到着量を示すメトリクスであり、コンシューマーが処理に追いついているかを直接示すものではありません。 選択肢Bの Lambda で Kafka 管理ツール定期実行は方法としても機能しますが、追加の開発・運用コストが必要であり、MSK のネイティブ機能を活用する方法と比べて複雑になります。 選択肢DのKinesis Data Streams へ移行は他のストリーミングサービスへの移行はコンシューマーラグ監視のためだけに行う変更としては過大であり、既存の MSK 環境への投資が無駄になります。