AWS認定資格 WEB問題集&徹底解説
データエンジニア-アソシエイト
問題文と選択肢
この要件を満たすには、どの方法を選択すべきですか。
- Amazon Data Firehose を経由してストリームのデータを一括バッファリングし、各アプリケーションに配信する
- Kinesis Data Streams の拡張ファンアウト(Enhanced Fan-Out)を有効にし、各アプリケーションを専用コンシューマーとして登録する
- 各アプリケーションが標準コンシューマーとしてポーリング間隔を可能な限り短く設定し、共有スループットの中で読み取る
- アプリケーションごとに同一データを送信する独立した Kinesis Data Stream を追加作成し、プロデューサーから重複して書き込む
A. Amazon Data Firehose を経由してストリームのデータを一括バッファリングし、各アプリケーションに配信する
Amazon Data Firehose は Kinesis Data Streams を入力にできますが、その役割は S3 や Redshift、OpenSearch などの「配信先」へバッファリングして届けることであり、複数のアプリケーションがそれぞれストリームを読むためのファンアウト機構ではありません。
バッファサイズ/バッファ間隔による待ち時間が必ず発生するため、「可能な限り低いレイテンシー」という要件にも真っ向から反します。
B. Kinesis Data Streams の拡張ファンアウト(Enhanced Fan-Out)を有効にし、各アプリケーションを専用コンシューマーとして登録する
拡張ファンアウト(Enhanced Fan-Out)では、アプリケーションを登録済みコンシューマーとして登録すると、シャードごと・コンシューマーごとに 2MB/秒 の専用読み取りスループットが割り当てられます。3 つのアプリケーションが互いの読み取り負荷に影響されません。
さらに SubscribeToShard による HTTP/2 のプッシュ配信となるため、ポーリングを繰り返す標準コンシューマーより伝播遅延が小さく(平均 70 ミリ秒程度)、低レイテンシー要件も同時に満たします。
ストリームを増やしたりプロデューサーを改修したりせずに要件を満たせる、唯一の選択肢です。
C. 各アプリケーションが標準コンシューマーとしてポーリング間隔を可能な限り短く設定し、共有スループットの中で読み取る
標準コンシューマーは、シャードあたり 2MB/秒 の読み取りスループットと GetRecords の呼び出し回数(1 秒あたり 5 回)を、そのシャードを読むすべてのコンシューマーで共有します。3 つのアプリケーションが同時に読めば帯域を奪い合い、「他の読み取り負荷に影響されない」という要件を満たせません。
ポーリング間隔を短くしても呼び出し回数の上限に当たり、ProvisionedThroughputExceededException(スロットリング)を誘発して、かえって遅延が悪化します。
D. アプリケーションごとに同一データを送信する独立した Kinesis Data Stream を追加作成し、プロデューサーから重複して書き込む
ストリームを 3 本用意すれば帯域は分離できますが、プロデューサーが同じデータを 3 回書き込む必要があり、書き込み側のコストとシャード料金がおよそ 3 倍になります。書き込み漏れによるストリーム間の不整合というリスクも新たに抱えます。
しかも各ストリームのコンシューマーが標準コンシューマーのままならポーリング由来のレイテンシーは改善しません。拡張ファンアウトなら 1 本のストリームで同じ目的を達成できます。
読み手が増えて 2MB/秒 を奪い合うなら拡張ファンアウト。コンシューマーごとに専用帯域+HTTP/2 プッシュ。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 3つの独立したアプリケーションが同一ストリームを読む | 標準コンシューマーはシャードあたり 2MB/秒 を全員で共有するため、読む側が増えるほど奪い合いになる →選択肢(C)を消す |
| 他のアプリの読み取り負荷に影響されない専用スループット | 拡張ファンアウトはコンシューマーごとにシャードあたり 2MB/秒 を専有する。これが「専用スループット」の直訳的な答え →選択肢(B)が正解 |
| 可能な限り低いレイテンシーで受け取る | HTTP/2 のプッシュ配信(SubscribeToShard)が最速。バッファリングやポーリングは遅延を積み増す →選択肢(A)を消す |
| 既存の取り込み構成を大きく変えずに実現する | ストリームの複製はプロデューサー改修とコスト増を招くうえ、レイテンシー要件は解決しない →選択肢(D)を消す |
ひっかけポイント
- Amazon Data Firehose は「複数の宛先に配れる」イメージから正解に見えるが、配信先へバッファして届けるサービスであり、アプリが自分のペースで読むコンシューマー機構ではない
- 「ポーリング間隔を短くする=速くなる」は誤り。GetRecords はシャードあたり 1 秒 5 回までで、コンシューマーが増えるほどスロットリングされる
- 選択肢 D は「専用スループット」だけを見ると成立しそうに見えるのが罠。重複書き込みのコストと整合性リスクを負ううえ、低レイテンシー要件は満たさない
- 拡張ファンアウトはコンシューマー時間とデータ取得量に対する追加料金が発生する。設問が「最もコスト効率が高い」ならば標準コンシューマーが正解に転ぶ
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「コンシューマーは1つだけで、コストを最小にしたい」 | 標準コンシューマーで十分。拡張ファンアウトは過剰でコスト増。 |
| 「ストリームのデータをS3 に貯めて後からバッチ分析したいだけ」 | Amazon Data Firehose による配信が正解軸に。 |
| 「既存の Kafka クライアントをそのまま使いたい」 | Amazon MSK(Managed Streaming for Apache Kafka)が正解軸に。 |
| 「ストリーム上でウィンドウ集計や異常検知をリアルタイムに行いたい」 | Amazon Managed Service for Apache Flink が登場する。 |
| 「シャードの追加・削除を意識せずスループットを自動調整したい」 | Kinesis Data Streams のオンデマンドモードが正解軸に。 |
この要件を満たすには、どの方法を選択すべきですか。
- Amazon Data Firehose を経由してストリームのデータを一括バッファリングし、各アプリケーションに配信する
- Kinesis Data Streams の拡張ファンアウト(Enhanced Fan-Out)を有効にし、各アプリケーションを専用コンシューマーとして登録する
- 各アプリケーションが標準コンシューマーとしてポーリング間隔を可能な限り短く設定し、共有スループットの中で読み取る
- アプリケーションごとに同一データを送信する独立した Kinesis Data Stream を追加作成し、プロデューサーから重複して書き込む
次の問題前の問題
会員機能
お役立ち情報
- プレミアム会員のご紹介
- 「徹底解説」のご紹介
- 「模擬試験」のご紹介
- 収録問題と試験ガイドの対応
- 会員機能のご紹介
- おすすめの勉強方法
- AWSサービスの解説
- AWS認定資格の種類・対象者・受験料・合格ライン
- スマホのホーム画面に登録する方法
姉妹サイト
- CLF:AWS 認定クラウドプラクティショナー
- SAA:AWS 認定ソリューションアーキテクト-アソシエイト
- AIF:AWS 認定AIプラクティショナー
- SOA:AWS 認定CloudOpsエンジニア-アソシエイト
- DVA:AWS 認定デベロッパー-アソシエイト
- DEA:AWS 認定データエンジニア-アソシエイト
- MLA:AWS 認定機械学習エンジニア-アソシエイト
- SAP:AWS 認定ソリューションアーキテクト-プロフェッショナル
- DOP:AWS 認定DevOpsエンジニア-プロフェッショナル
- AIP:AWS 認定生成AIデベロッパー-プロフェッショナル
- SCS:AWS 認定セキュリティ-専門知識
- AZ-900:Microsoft Azure Fundamentals
- AI-900:Microsoft Azure AI Fundamentals