MENU
会員登録（無料）
  1. ホーム
  2. 【DEA-C01】WEB問題集：データの取り込みと変換編

【DEA-C01】WEB問題集：データの取り込みと変換編

WEB問題集

DEA-C01#1(data-ingestion)

あるデータエンジニアは、IoT センサーから 1 秒あたり最大 10MB のデータを Amazon Kinesis Data Streams に送信するパイプラインを設計しています。各レコードは平均 5KB で、ピーク時には 1 秒あたり 2,000 レコードに達します。プロビジョンドモードで構成する場合、最低限必要なシャード数はいくつになりますか。

ディスカッション 0

正解：A

正解の根拠

Kinesis Data Streams のシャードは書込側で 1MB/秒 または 1,000 レコード/秒 のいずれか先に到達した上限で頭打ちになる仕様です。本問では書込量 10MB/秒で 10 シャード相当、レコード数 2,000 件/秒で 2 シャード相当が必要となるため、両者の最大値である 10 シャードを最小構成として採用することが正解となります。さらに余裕を持たせる場合はピーク時の 1.2〜1.5 倍を見込むのが一般的ですが、本問は最小構成の問いであるため 10 が解答です。

シャード上限と必要数の計算

観点シャード上限本問の値必要シャード数
書込スループット1 MB/秒10 MB/秒10
書込レコード数1,000 件/秒2,000 件/秒2
読込スループット2 MB/秒参考値用途次第
必要シャード数 (最大値)--10

シャード数算出の考え方

# 必要シャード数 = max(書込量/1MB, レコード数/1000)
shards = max(10_000_000 / 1_000_000, 2_000 / 1_000)
       = max(10, 2)
       = 10

不正解の理由

  • B: 20 シャードは安全マージンとしては妥当ですが、最小構成という設問条件を満たさないためコスト面で過剰となります。
  • C: 5 シャードでは書込量 5MB/秒までしか処理できず、ピーク時に ProvisionedThroughputExceededException が発生してしまいます。
  • D: 2 シャードはレコード数のみを根拠とした計算で、書込量上限 (2MB/秒) を 5 倍も超過するため即座にスロットリングが起きます。

参考：Kinesis Data Streams のクォータと制限

DEA-C01#2(data-ingestion)

ある企業では Kinesis Data Streams を使ってリアルタイムデータを処理しています。複数の独立したコンシューマーアプリケーションが同じストリームから低レイテンシで読取りを行いつつ、互いの読取り性能に影響を与えない構成にしたいと考えています。最も適切な機能はどれですか。

ディスカッション 0

正解：B

正解の根拠

拡張ファンアウト (Enhanced Fan-Out) は登録した各コンシューマーに対し 1 シャードあたり 2MB/秒の専用スループットを HTTP/2 push で割当てる機能です。これによりコンシューマー間でシャード帯域を取り合うことなく、平均レイテンシも約 70ms まで短縮できるため、複数コンシューマーが互いに影響しない低レイテンシ読取り要件に最適となります。

標準コンシューマー vs 拡張ファンアウト

方式スループットレイテンシ配信コンシューマー数
Standard (GetRecords)シャード毎 2MB/秒を共有約 200msPull (poll)実用上 2〜3
Enhanced Fan-Outコンシューマー毎に専用 2MB/秒約 70msPush (HTTP/2)最大 20

登録 CLI 例

aws kinesis register-stream-consumer   --stream-arn arn:aws:kinesis:ap-northeast-1:123456789012:stream/my-stream   --consumer-name analytics-consumer

不正解の理由

  • A: ストリーム複製はコストが倍増するうえ、整合性管理を自前で行う必要があり、Fan-Out の置き換えとしては非効率です。
  • C: Kinesis にはシャード数とコンシューマー数を 1:1 に対応させる仕組みは存在せず、シャードはあくまでスループット単位となります。
  • D: SQS FIFO Queue を経由する構成は二度手間であり、Kinesis の保持機能や順序保証も活かせず、Fan-Out 用途とは設計思想が異なります。

参考：Enhanced Fan-Out コンシューマー

DEA-C01#3(data-ingestion)

あるアプリケーションが Kinesis Data Streams の単一シャードに対して ProvisionedThroughputExceededException を頻繁に発生させており、調査の結果、特定のパーティションキーに書込が集中していると判明しました。最も適切な対処方法を 2 つ選んでください。

（2つ選択）

ディスカッション 0

正解：A, C

正解の根拠

ProvisionedThroughputExceededException がホットシャードで発生している場合、根本原因はパーティションキーの偏りです。これに対する直接的な解決策は、(A) パーティションキーに乱数サフィックスを付与してキー分散を改善するか、(C) UpdateShardCount API でホットシャードをスプリットして書込容量を増やす、の 2 つとなります。前者はアプリ側の即時対応、後者はキャパシティ側の構造改善であり、組合せて用いることもできます。

ホットシャード対策パターン

対策レイヤ効果制約
乱数サフィックス付与プロデューサーキー分散改善順序保証が緩む
UpdateShardCount でスプリットストリーム書込容量増加シャード時間課金増
オンデマンドモードへ切替ストリーム自動スケール本問では選択肢外
KPL Aggregationプロデューサーレコード上限緩和書込量上限には無効

パーティションキー分散実装例

import random
partition_key = f"{customer_id}#{random.randint(0, 9)}"
client.put_record(StreamName="my-stream", Data=payload, PartitionKey=partition_key)

不正解の理由

  • B: 保持期間の延長は障害時のリプレイ猶予を増やすだけであり、書込スロットリング自体は解消できません。
  • D: チェックポイント間隔は KCL の読取り側パラメータであるため、書込側の上限超過には影響しません。
  • E: コンシューマー並列度の引上げは読取り性能の話であり、書込スロットリングとは無関係となります。

参考：Kinesis プロデューサーのトラブルシューティング

DEA-C01#4(data-ingestion)

あるデータエンジニアは、Kinesis Data Streams で 1 日あたりのデータ量が大きく変動するワークロードを管理しています。ピークとオフピークで 10 倍以上の差があり、運用負荷を最小化しつつコストも最適化したい状況です。最も適切なキャパシティモードはどれですか。

ディスカッション 0

正解：C

正解の根拠

オンデマンドモードは AWS 側が書込トラフィックに応じて自動的にキャパシティを調整する課金形態であり、ピークとオフピークで 10 倍以上の差があるワークロードに最適となります。シャード数の事前見積もりや手動切替えが不要となるため、運用負荷とコスト最適化を同時に満たすことができます。前 30 日のピークの 2 倍まで自動追従するため、突発的な増加にも耐えられる設計となっています。

キャパシティモード比較

モード課金スケーリング適性
Provisionedシャード時間 + PUT 単位手動 / Auto Scaling予測可能で安定したワークロード
On-Demand取込量 GB / 取得量 GB自動 (前 30 日ピークの 2 倍まで)変動が大きく予測困難なワークロード

モード切替 CLI

aws kinesis update-stream-mode   --stream-arn arn:aws:kinesis:ap-northeast-1:123456789012:stream/my-stream   --stream-mode-details StreamMode=ON_DEMAND

不正解の理由

  • A: ピーク固定はオフピーク時に大幅な過剰プロビジョンとなり、コスト効率が悪化してしまいます。
  • B: 半分構成ではピーク時に頻繁なスロットリングが発生し、データ損失や処理遅延の原因となります。
  • D: 手動切替スクリプトは運用負荷が高いうえ、変動の予測ミスでサービス影響が出やすい構成です。

参考：Kinesis Data Streams のキャパシティモード

DEA-C01#5(data-ingestion)

あるデータエンジニアは、Kinesis Data Streams から読取って変換処理を行う Lambda 関数を運用しています。ストリームは 10 シャード構成で、シャードあたりの並列処理数を増やしてスループットを向上させたいと考えています。Event Source Mapping で調整すべきパラメータはどれですか。

ディスカッション 0

正解：C

正解の根拠

ParallelizationFactor は Lambda Event Source Mapping のパラメータで、1 シャードに対して同時起動する Lambda 実行数を 1〜10 で指定します。デフォルトは 1 のため、引上げることでシャードあたりのスループットを最大 10 倍まで向上できます。ただし同一パーティションキーのレコードは同じ Lambda 実行に集約されるため、キー単位の順序保証は維持される仕様となっています。

Lambda + Kinesis のチューニングパラメータ

パラメータ役割並列度への影響
ParallelizationFactorシャード毎の同時 Lambda 実行数あり (1〜10 倍)
BatchSize1 起動あたりのレコード数なし (バッチ効率のみ)
MaximumBatchingWindowInSecondsバッチ蓄積待機時間なし (レイテンシ調整)
MaximumRetryAttempts失敗時の再試行回数なし (エラー処理)

Event Source Mapping 設定例

aws lambda update-event-source-mapping   --uuid <mapping-uuid>   --parallelization-factor 10   --batch-size 100

不正解の理由

  • A: BatchSize は 1 回の起動で扱うレコード数の調整であり、シャードあたりの並列実行数自体は増加しません。
  • B: MaximumRetryAttempts はエラー時の再試行設定で、平常時のスループット向上には寄与しないパラメータです。
  • D: Enhanced Fan-Out は読取り帯域の拡大ですが、Lambda 側の並列実行数は別途 ParallelizationFactor で制御する必要があります。

参考：Lambda の Kinesis トリガー設定

前のページ
次のページ