あるIoT企業が、数千台のデバイスからのセンサーデータをAmazon Kinesis Data Streams（4シャード構成）で受信しています。同じストリームを3つの独立したコンシューマーアプリケーション（リアルタイムアラート処理・データウェアハウス書き込み・機械学習パイプライン）がGetRecords APIを用いて並列読み取りしています。1シャードあたり2MB/秒の読み取りスループットを全コンシューマーで共有しているため処理ラグが増大しています。コンシューマーアプリケーションへの変更を最小限に抑えながら、この問題を解決する最も適切な方法はどれですか？
通常のGetRecords APIでは1シャードあたりの読み取りスループット2MB/秒を全コンシューマーで共有します。Kinesis Enhanced Fan-Out（拡張ファンアウト）を使用すると、登録されたコンシューマーごとにシャードあたり専用2MB/秒が割り当てられ、HTTP/2プッシュ型のSubscribeToShard APIで低レイテンシー配信されます。3コンシューマーをAWSコンソールまたはAPIで登録するだけで有効化でき、アプリケーションコードの変更を最小化できます。 選択肢A（Kinesisシャード数を12に増加）ではシャード費用も3倍に増加し、コンシューマー間の帯域共有問題は根本解決されない。 選択肢C（Amazon SQSに移行）はアーキテクチャの根本的な再設計が必要であり、変更最小化の要件に反する。また、SQSはストリーム処理向けではなくKinesisの時系列・順序保証の特性を失う。 選択肢D（AWS Lambda + Amazon SNS）はパイプライン全体の再設計が必要で、既存の3つのコンシューマーアプリを大幅に変更しなければならない。