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

WEB問題集

DVA-C02#1(development)

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

A. API Gateway のキャッシュを 0.5 GB で有効化し、TTL 300 秒で SaaS 応答をエンドポイントレベルで保持します。 B. Lambda の同時実行予約を 500 に設定し、あわせて AWS アカウントの Lambda 同時実行数の上限引き上げを申請します。 C. Lambda 関数のメモリを 128 MB から 1024 MB に引き上げ、同時 vCPU を増やしてスループットを向上させます。 D. Provisioned Concurrency を 100 に設定し、AutoScaling を CloudWatch メトリクスで動的に調整します。

ディスカッション 0

解説

正解の根拠

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

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 を直接使用しています。書き込みスループットを安定させるための最適な再設計はどれですか。

A. DAX クラスターを前段に配置し、書き込みパススルーを並列化することでホットパーティションを緩和し、加えて Adaptive Capacity の到達を待機する設計とします。 B. オンデマンド課金へ切り替え、内部のアダプティブキャパシティが完全に均等化するまで待機します。 C. パーティションキーに乱数サフィックス (例: userId#0..9) を加える書き込みシャーディングを実装し、読み出し時は全シャードを並列クエリします。 D. DynamoDB Streams を有効化し、KCL ワーカーで書き込みをパーティション間に再分散させます。

ディスカッション 0

解説

正解の根拠

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

パーティション設計手法

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

不正解の理由

A: DAX は読み取りキャッシュ機能で、書き込みのホットスポット解消には機能を提供せず根本対策になりません。
B: オンデマンドでもパーティション偏りは残存する副作用があり、即時解消には書き込みキー分散が必須です。
D: Streams は変更データ伝播用の機能で、書き込みの再分散機構そのものを提供する仕組みではありません。

参考：DynamoDB Sharding

DVA-C02#3(development)

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

A. DynamoDB の条件付き書き込みでメッセージ ID を主キーにした冪等トークンレコードを Put し、既存ならスキップします。 B. Lambda の同時実行を 1 に固定し、ロック相当の挙動でメッセージを直列化します。 C. SQS を FIFO キューへ移行し、MessageDeduplicationId を全メッセージで省略してデフォルトの内容ハッシュ重複排除に依拠します。 D. Lambda 関数の VisibilityTimeout をハンドラ最大処理時間の 6 倍に設定し、再配信を抑制します。

ディスカッション 0

解説

正解の根拠

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 制限に引っかかる懸念があり、ペイロードを最小化したいです。最適な設計はどれですか。

A. API Gateway のバイナリメディアタイプを設定し、Lambda にバイナリを Base64 で渡してから S3 へ Put することで対応します。 B. API Gateway を HTTP API に切り替え、ペイロード上限が増えることに依拠して同期 PUT を継続します。 C. Lambda が S3 への presigned PUT URL を発行し、クライアントが直接 S3 へアップロードします。Lambda は完了通知のみ受け取ります。 D. S3 Multipart Upload API を Lambda 内部で呼び出し、6 MB を 1 MB チャンクに分割し並列送信して総転送時間を短縮しペイロード制限を回避する運用方式を採用します。

ディスカッション 0

解説

正解の根拠

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

大容量アップロード設計

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

不正解の理由

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

参考：S3 Presigned URL

DVA-C02#5(development)

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

A. Wait state を最大 60 秒まで連続して呼び出し Token を毎回更新して状態を持続させ最大 7 日の長期承認待ちにも対応するため定期的な再エントリで状態維持する独自実装の設計とします。 B. Lambda 関数を Polling で 5 分毎に呼び出し、承認 API を確認する loop を Choice + Wait で実装します。 C. 承認用 Lambda を起動しコンテキストオブジェクトを DynamoDB に保管し承認時にステートマシンを別 ARN で再起動して文脈引き継ぎも自前 ID で繋ぎ運用する設計選択とします。 D. Activity または .waitForTaskToken を使い、外部承認システムが SendTaskSuccess/Failure を呼び出すまで実行を停止します。

ディスカッション 0

解説

正解の根拠

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

長時間タスク表現の比較

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

不正解の理由

A: Wait state は最大期間まで設定できますが、Token 更新では状態管理ができず継続的な状態遷移課金も発生します。
B: Polling 方式は無駄な Lambda 呼出と状態遷移費用を増やす副作用があり、長時間待機としてはコスト効率が悪い実装です。
C: ステートマシン再起動は文脈の引き継ぎが煩雑で、運用が複雑化する副作用があり標準パターンと比べ非推奨です。

参考：Wait For Callback