SAA弾力性に優れたアーキテクチャの設計
ある IoT プラットフォーム企業が、センサーデータを Amazon Kinesis Data Streams（4シャード）に取り込んでいます。リアルタイムアラート・機械学習パイプライン・データウェアハウス連携の3つの独立したコンシューマーアプリケーションが同じストリームを読み取っていますが、スループット（2MB/s/シャード）をコンシューマー間で共有するため各アプリケーションで遅延が発生しています。最小の運用負荷でこの問題を解消する方法はどれですか？
AKinesis Enhanced Fan-Out を有効にし、3つのコンシューマーをそれぞれ専用コンシューマー（registered consumer）として登録する。
✓ 正解
Enhanced Fan-Out を使用すると各登録済みコンシューマーがシャードごとに専用の 2MB/s スループットを HTTP/2 プッシュで受け取ります。既存の Kinesis 構成を変えずにコンシューマー登録設定のみで解決できるため運用負荷が最小です。
BKinesis Data Streams のシャード数を3倍（12シャード）に増やし、パーティションキーで各コンシューマーに専用シャードセットへデータを振り分けることで専有帯域を確保する。
シャード数を3倍に増やすとコストが3倍増加します。また全コンシューマーが全データを必要とする場合、パーティションキーでシャードを分割すると一部コンシューマーにデータが届かなくなる問題が生じます。
CAmazon Data Firehose を追加してストリームデータを Amazon S3 に書き出し、3つのコンシューマーがそれぞれ独立して S3 オブジェクトからデータを取得するアーキテクチャに変更する。
Amazon Data Firehose 経由で S3 に書き出す方法ではバッファリングにより数分単位の遅延が発生します。リアルタイムアラートが要件のコンシューマーが存在するため、このアーキテクチャでは要件を満たせません。
DKinesis Data Streams の前段に Amazon SNS を配置し、SNS から3つの SQS キューへファンアウトした上で各コンシューマーが専用 SQS キューからデータを取得する構成に変更する。
SNS + SQS ファンアウトは Kinesis ストリームをそのままプロデューサーとして利用できないため、データ取り込みからの再設計が必要です。インフラ追加と大規模なアーキテクチャ変更が伴い、運用負荷が大幅に増大します。
解説
Kinesis Enhanced Fan-Out は、ストリームの各シャードに対して登録済みコンシューマーごとに専用の 2MB/s スループットを提供します。標準の GetRecords ポーリングではシャードの 2MB/s を全コンシューマーで共有しますが、Enhanced Fan-Out では HTTP/2 プッシュベースでデータが各コンシューマーに独立して配信されます。既存のアーキテクチャを維持したままコンシューマー登録の設定変更のみで対応でき、運用負荷が最小です。
選択肢Bのシャード数を3倍に増やす方法はコストが3倍になり、かつ全コンシューマーが全データを必要とする場合パーティションキーによるシャード振り分けでは一部コンシューマーにデータが届かなくなります。
選択肢CのAmazon Data Firehose で S3 に書き出す方法はバッファリングにより数分単位の遅延が発生し、リアルタイムアラートを要件とするコンシューマーの要件を満たせません。
選択肢DのSNS + SQS ファンアウトパターンは Kinesis をプロデューサーとして直接利用できないため、データ取り込み部分からの再設計が必要となり大規模なアーキテクチャ変更が伴います。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →