あるグローバルゲーム会社が、DynamoDBとKinesis Data Streamsを組み合わせたリアルタイムランキングシステムを構築している。Kinesis Data Streamsのシャードをコンシューマー（Lambda）が処理するとき、特定のシャードで処理遅延が発生しており、最終的にIteratorAgeが急増している。コードの変更を最小限に抑えてスループットを改善する方法として最も適切なものはどれか。
- A. Kinesis拡張ファンアウト（Enhanced Fan-Out）を有効化してプッシュ型配信に変更し、コンシューマーをKinesis Data Streamsに登録する。同時に並列係数（parallelizationFactor）を2〜10に設定してシャードあたりのLambda並列数を増やす
- B. Kinesis Data StreamsをSQS標準キューに置き換え、LambdaのSQSトリガーでメッセージを並列処理する
- C. Kinesisシャード数を増やして各シャードのレコード数を減らし、LambdaのイベントソースマッピングのbatchSizeを減らす
- D. LambdaコンシューマーをKinesis Data Streamsから切り離し、Kinesis Data FirehoseでS3に書き込んだ後、S3イベント通知でLambdaを起動する
解答と解説を見る
正解: A
Kinesis拡張ファンアウト（Enhanced Fan-Out）はポーリングベースからプッシュベースに変わり、シャードあたり2MB/秒の専用スループットが得られる（通常の2MB/秒制限はすべてのコンシューマーで共有）。さらにparallelizationFactor（1〜10）を設定することで、1シャードに対して最大10のLambda関数を並列実行できる。この組み合わせでIteratorAge（処理遅延）の急増を効率的に解消できる。Cのシャード数増加は効果はあるが、シャード数を増やすとコストが線形に増加し、データのパーティション設計も変更が必要なため「コードの変更最小限」の制約に反する可能性がある。batchSizeを減らすとスループットは逆に低下する。DのFirehose+S3経由はリアルタイムランキング（低遅延要件）に対してS3のバッファリングが発生するため不適切で、アーキテクチャの大改修が必要。BのSQSへの置き換えはシャードの順序保証がなくなり、アーキテクチャの大改修でコードの変更量が大きい。
📚 関連サービスの解説: Amazon Kinesis ・ AWS Lambda