MENU
会員登録（無料）
  1. ホーム
  2. 【DVA-C02】WEB問題集：AWSサービスでの開発編

【DVA-C02】WEB問題集：AWSサービスでの開発編

WEB問題集

DVA-C02#1(development)

あるチームは API Gateway REST API の背後で Lambda 関数を呼び出しています。Lambda は外部 SaaS への HTTP 呼び出しを行い、平均 800 ms かかります。同時実行が 200 を超えるとスロットリングが発生するため、コードを変更せずに長時間実行のレイテンシを下げる最も効果的な方法はどれですか。

ディスカッション 0

正解：B

正解の根拠

同時実行スロットリングが課題であり、コードや動作を変更せずに緩和するには関数レベルで予約済み同時実行枠を確保し、アカウント上限を引き上げて実行枠の競合を解消するのが最も直接的に効きます。

Lambda 同時実行設定の比較

設定目的コスト影響
Reserved Concurrency関数の枠確保と上限制御追加課金なし
Provisioned Concurrencyコールドスタート排除常時課金
Account Limitリージョン全体の最大値申請で増枠

不正解の理由

  • C: メモリ増は CPU を増やしますが、待ち時間が外部 I/O 中心のため改善は限定的です。
  • A: SaaS 呼び出しの結果はリクエストごとに動的で、汎用キャッシュは適用しにくいです。
  • D: Provisioned Concurrency はコールドスタート対策で、スロットリングそのものは解消しません。

参考：Lambda Concurrency

DVA-C02#2(development)

開発者は DynamoDB テーブルでホットパーティションが発生し、書き込みが断続的にスロットリングされます。アプリ側コードは Item Key として userId を直接使用しています。書き込みスループットを安定させるための最適な再設計はどれですか。

ディスカッション 0

正解：C

正解の根拠

ホットパーティションの根本原因はキー設計の偏りであり、書き込みシャーディングでパーティションキーの分布を平準化するのが王道です。10 シャードに分散すれば 10 倍のスループットを 1 ユーザー分でも確保できます。

パーティション設計手法

手法効果注意
Random Suffix書き込み分散読み出しでスキャター/ギャザー
Calculated Suffix決定論的分散ハッシュ計算が必要
Composite Key論理分割キー設計が複雑化

コード例

shard = random.randint(0, 9)
pk = f"{userId}#{shard}"
table.put_item(Item={"pk": pk, "sk": ts})

不正解の理由

  • D: Streams は変更データ伝播用で書き込みの再分散はできません。
  • B: オンデマンドでもパーティション偏りは残り、即時には解消しません。
  • A: DAX は読み取りキャッシュで、書き込みのホットスポットには効きません。

参考：DynamoDB Sharding

DVA-C02#3(development)

開発者は SQS Standard キューを購読する Lambda 関数で、まれに同一メッセージが二重処理される問題に直面しています。順序は不要ですが、副作用は冪等にしたいです。最も効果的な実装はどれですか。

ディスカッション 0

正解：A

正解の根拠

SQS Standard は少なくとも 1 回配信を保証するため、二重処理は発生し得ます。冪等性を担保するにはアプリ側で処理済みトークンを耐久ストアに記録し、条件付き書き込みで重複処理を弾くのが最も信頼性の高い設計です。

冪等化アプローチ

方法長所短所
DynamoDB 条件付き Putシンプル・スケールテーブル設計が必要
Lambda Powertools Idempotency標準実装ライブラリ依存
FIFO キュー5 分内重複排除スループット制約

コード例

table.put_item(
  Item={"pk": msg_id, "ts": now},
  ConditionExpression="attribute_not_exists(pk)"
)

不正解の理由

  • B: 同時実行 1 はスループットを犠牲にし、リトライによる重複は依然発生します。
  • C: FIFO 重複排除は 5 分間のみ有効で、長期の冪等性は保証できません。
  • D: VisibilityTimeout の延長は再配信を遅らせるだけで、根本解決ではありません。

参考：Lambda+SQS Idempotency

DVA-C02#4(development)

開発者は API Gateway REST API でクライアントから 6 MB の画像を受信して S3 に保存する処理を実装しています。Lambda Proxy 統合では 10 MB 制限に引っかかる懸念があり、ペイロードを最小化したいです。最適な設計はどれですか。

ディスカッション 0

正解：C

正解の根拠

大容量データを API Gateway 経由で送らず、クライアントから S3 への presigned URL アップロードに切り替えると、API Gateway/Lambda のペイロード制限を回避でき、Lambda の課金時間とリソース使用も削減されます。

大容量アップロード設計

方式制限用途
Presigned URLS3 オブジェクト 5 TB大容量直アップロード
API GW Proxy10 MB小サイズ JSON 中心
Multipart5 MB 越え巨大ファイル

コード例

url = s3.generate_presigned_url(
  "put_object",
  Params={"Bucket": b, "Key": k},
  ExpiresIn=900)
return {"upload_url": url}

不正解の理由

  • A: バイナリメディアタイプ設定でも 10 MB 制限自体は変わりません。
  • B: HTTP API のペイロード制限も同様に存在し、根本解決にはなりません。
  • D: Multipart 経由でも Lambda を通る限り API Gateway 制限は回避できません。

参考：S3 Presigned URL

DVA-C02#5(development)

Step Functions Standard ワークフローで、外部承認に最大 7 日間かかるステップがあります。承認待ちで余分な実行コストを発生させず、長期間の人間タスクを表現する最適な実装はどれですか。

ディスカッション 0

正解：D

正解の根拠

Standard ワークフローでは waitForTaskToken パターンにより最大 1 年まで待機が可能で、外部システムが SendTaskSuccess を呼び出すまで状態遷移費用を発生させずに停止します。これがヒューマン承認の標準的な実装です。

長時間タスク表現の比較

パターン最大待機コスト
waitForTaskToken1 年状態遷移課金のみ
Polling制限なし呼出毎課金
Wait + Loop制限なし状態遷移増

コード例

"Approval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {"Message.$": "$$.Task.Token"}
}

不正解の理由

  • B: Polling は無駄な Lambda 呼出と遷移費用を増やします。
  • C: ステートマシン再起動は文脈の引き継ぎが煩雑で、運用が複雑化します。
  • A: Wait state は最大期間まで設定できますが、Token 更新では状態管理ができません。

参考：Wait For Callback

前のページ
次のページ