WEB問題集
あるチームは API Gateway REST API の背後で Lambda 関数を呼び出しています。Lambda は外部 SaaS への HTTP 呼び出しを行い、平均 800 ms かかります。同時実行が 200 を超えるとスロットリングが発生するため、コードを変更せずに長時間実行のレイテンシを下げる最も効果的な方法はどれですか。
正解：B
正解の根拠
同時実行スロットリングが課題であり、コードや動作を変更せずに緩和するには関数レベルで予約済み同時実行枠を確保し、アカウント上限を引き上げて実行枠の競合を解消するのが最も直接的に効きます。
Lambda 同時実行設定の比較
| 設定 | 目的 | コスト影響 |
|---|---|---|
| Reserved Concurrency | 関数の枠確保と上限制御 | 追加課金なし |
| Provisioned Concurrency | コールドスタート排除 | 常時課金 |
| Account Limit | リージョン全体の最大値 | 申請で増枠 |
不正解の理由
- C: メモリ増は CPU を増やしますが、待ち時間が外部 I/O 中心のため改善は限定的です。
- A: SaaS 呼び出しの結果はリクエストごとに動的で、汎用キャッシュは適用しにくいです。
- D: Provisioned Concurrency はコールドスタート対策で、スロットリングそのものは解消しません。
開発者は DynamoDB テーブルでホットパーティションが発生し、書き込みが断続的にスロットリングされます。アプリ側コードは Item Key として userId を直接使用しています。書き込みスループットを安定させるための最適な再設計はどれですか。
正解：C
正解の根拠
ホットパーティションの根本原因はキー設計の偏りであり、書き込みシャーディングでパーティションキーの分布を平準化するのが王道です。10 シャードに分散すれば 10 倍のスループットを 1 ユーザー分でも確保できます。
パーティション設計手法
| 手法 | 効果 | 注意 |
|---|---|---|
| Random Suffix | 書き込み分散 | 読み出しでスキャター/ギャザー |
| Calculated Suffix | 決定論的分散 | ハッシュ計算が必要 |
| Composite Key | 論理分割 | キー設計が複雑化 |
不正解の理由
- A: DAX は読み取りキャッシュ機能で、書き込みのホットスポット解消には機能を提供せず根本対策になりません。
- B: オンデマンドでもパーティション偏りは残存する副作用があり、即時解消には書き込みキー分散が必須です。
- D: Streams は変更データ伝播用の機能で、書き込みの再分散機構そのものを提供する仕組みではありません。
開発者は SQS Standard キューを購読する Lambda 関数で、まれに同一メッセージが二重処理される問題に直面しています。順序は不要ですが、副作用は冪等にしたいです。最も効果的な実装はどれですか。
正解：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 の延長は再配信を遅らせるだけで、根本解決ではありません。
開発者は API Gateway REST API でクライアントから 6 MB の画像を受信して S3 に保存する処理を実装しています。Lambda Proxy 統合では 10 MB 制限に引っかかる懸念があり、ペイロードを最小化したいです。最適な設計はどれですか。
正解：C
正解の根拠
大容量データを 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 経由の制限は回避できず本質解にはなりません。
Step Functions Standard ワークフローで、外部承認に最大 7 日間かかるステップがあります。承認待ちで余分な実行コストを発生させず、長期間の人間タスクを表現する最適な実装はどれですか。
正解：D
正解の根拠
Standard ワークフローでは waitForTaskToken パターンにより最大 1 年まで待機が可能で、外部システムが SendTaskSuccess を呼び出すまで状態遷移費用を発生させずに停止します。これがヒューマン承認の標準的な実装です。
長時間タスク表現の比較
| パターン | 最大待機 | コスト |
|---|---|---|
| waitForTaskToken | 1 年 | 状態遷移課金のみ |
| Polling | 制限なし | 呼出毎課金 |
| Wait + Loop | 制限なし | 状態遷移増 |
不正解の理由
- A: Wait state は最大期間まで設定できますが、Token 更新では状態管理ができず継続的な状態遷移課金も発生します。
- B: Polling 方式は無駄な Lambda 呼出と状態遷移費用を増やす副作用があり、長時間待機としてはコスト効率が悪い実装です。
- C: ステートマシン再起動は文脈の引き継ぎが煩雑で、運用が複雑化する副作用があり標準パターンと比べ非推奨です。