あるIoTプラットフォームがAmazon Kinesis Data Streamsを使用して、毎秒数万件のデバイステレメトリデータをリアルタイム処理しています。同一ストリームを5つのLambda関数が並行してコンシューム（消費）しており、それぞれリアルタイムアラート・データ変換・ML推論・監査ログ・データウェアハウス連携の用途に使用しています。最近、全コンシューマーがシャードあたり2MB/秒の読み込みスループットを共有するため処理遅延が増加しています。アーキテクチャを大幅に変更せずにこの問題を解決するための最も適切な方法はどれですか？
標準的なKinesisのGetRecords APIはポーリング型であり、シャードあたり2MB/秒の読み込みスループットを全コンシューマーが共有します。拡張ファンアウト（Enhanced Fan-Out）はHTTP/2のSubscribeToShard APIを使用するプッシュ型であり、登録済みの各コンシューマーにシャードあたり2MB/秒の専用スループットを独立して付与します。5つのコンシューマーそれぞれが専用2MB/秒帯域を確保できるためスループット競合が解消されます。 選択肢AのKinesisストリームのシャード数を現在の5倍に増やすことは各シャードで依然5つのコンシューマーがスループットを共有するため根本解決にならず、コストが大幅に増加します。 選択肢CのAmazon Data Firehoseを中間層として追加することはS3等へのバッチ配信を目的としており、リアルタイム処理用ではなく遅延が増加するためシナリオ要件を満たしません。 選択肢DAmazon SQSのFIFOキューを5つ作成することはアーキテクチャの大幅な変更と追加のデータコピー機構が必要であり、Kinesisのシーケンシャル処理・リプレイ機能等の特性も失われます。