【DVA-C02】WEB問題集：トラブルシューティングと最適化編

WEB問題集

DVA-C02#1(troubleshooting)

Lambda 関数のコールドスタートが断続的に発生し、p99 レイテンシが SLO を超過しています。Java 11 ランタイム、メモリ 1024 MB、初期化に DI コンテナの構築が含まれます。最も効果のある対策はどれですか。

A. 関数のメモリを 3008 MB に増やし、CPU 配分を最大化します。
B. Lambda の同時実行予約を 100 に設定し、関数の同時実行枠を確保します。
C. Lambda Layers にライブラリを分離し、デプロイパッケージサイズを縮小します。
D. Provisioned Concurrency を SLO に必要な数だけ設定し、Application Auto Scaling で日中の需要に追従させます。

正解と解説ディスカッション 0

正解：D

正解の根拠

Provisioned Concurrency は事前に初期化済みの実行環境を保持し、コールドスタートを排除します。Application Auto Scaling と組み合わせれば需要変化にも追従でき、コストも最小化できます。

コールドスタート対策の比較

対策	効果	コスト
Provisioned Concurrency	排除	常時課金
SnapStart (Java)	大幅短縮	追加なし
メモリ増	限定的	呼出単価増

不正解の理由

B: 同時実行予約はスロットリング対策で、コールドスタートそのものは消えません。
C: Layers はサイズ最適化に役立ちますが、Init 時間にはほぼ寄与しません。
A: メモリ増は CPU を上げますが、DI 構築の根本短縮にはつながりにくいです。

参考：Provisioned Concurrency

DVA-C02#2(troubleshooting)

API Gateway REST API で 5XX エラーが断続的に発生しています。CloudWatch メトリクスで IntegrationLatency が高く、Lambda 関数では Errors も Throttles も 0 です。原因として最も疑わしいのはどれですか。

A. API Gateway の CORS 設定が不正で、ブラウザが実行をブロックしています。
B. Lambda の Init Duration が長く、API Gateway 統合タイムアウト 29 秒を超えている可能性があります。
C. API Gateway の使用量プランで API キーが期限切れになっています。
D. Lambda の Reserved Concurrency が 0 に設定されており、すべての呼出が拒否されています。

正解と解説ディスカッション 0

正解：B

正解の根拠

5XX かつ IntegrationLatency が高いのに Lambda 側のエラー/スロットルが 0 という症状は、Lambda 自体は完了しているが API Gateway の 29 秒統合タイムアウトに引っかかっているケースを強く示唆します。Init Duration の長期化やバックエンド処理の長時間化が典型的原因です。

API Gateway 5XX 主要原因

原因	判別指標
統合タイムアウト	IntegrationLatency 高
Lambda エラー	Lambda Errors
スロットル	Lambda Throttles

不正解の理由

D: Reserved Concurrency 0 ならスロットルが計上されるはずです。
A: CORS 失敗はブラウザ側エラーで API Gateway 5XX にはなりません。
C: API キー失効は 403 を返し、5XX とは異なります。

参考：API Gateway Limits

DVA-C02#3(troubleshooting)

X-Ray を Lambda に有効化したが、ServiceMap に下流の DynamoDB が表示されません。コードは boto3 で DynamoDB を呼び出しており、関数のトレースは正常に出力されています。最も可能性の高い原因はどれですか。

A. X-Ray Daemon を Lambda 拡張機能として手動で起動していない。
B. Lambda トリガー側 (API Gateway) でトレース有効化が有効になっていない。
C. DynamoDB テーブル側で X-Ray の連携設定を有効化していない。
D. aws-xray-sdk で boto3 を patch せず、subsegment が生成されていない。

正解と解説ディスカッション 0

正解：D

正解の根拠

Lambda の X-Ray Active Tracing は実行環境のトレースを取得しますが、下流 AWS API 呼出のサブセグメントを取るには SDK のパッチが必要です。boto3 を patch_all または patch(['botocore']) で計装することで、ServiceMap に DynamoDB が現れます。

X-Ray 計装ポイント

対象	方法
Lambda 自体	Active Tracing 有効化
AWS SDK 呼出	SDK パッチ
外部 HTTP	requests/httpx パッチ

コード例

from aws_xray_sdk.core import patch_all
patch_all()
ddb = boto3.client("dynamodb")

不正解の理由

B: API Gateway の有効化はその上流のトレースで、下流計装には不要です。
A: Lambda は X-Ray Daemon を内蔵しており、手動起動不要です。
C: DynamoDB 側に X-Ray の有効化設定はありません。

参考：X-Ray Python SDK

DVA-C02#4(troubleshooting)

CloudWatch Logs Insights で Lambda 関数の重大エラーを発生時刻順に集計したいです。リクエスト ID と error メッセージをフィールド化して上位 20 件を返すクエリはどれですか。

A. stats count(*) by @logStream | sort @timestamp desc | limit 20
B. display @timestamp, @message | where errorType = 'ERROR' | top 20
C. query @logs as l : l.error == true | aggregate count by l.timestamp
D. fields @timestamp, @message | filter @message like /ERROR/ | parse @message "ERROR * REQ=*" as msg, reqId | sort @timestamp desc | limit 20

正解と解説ディスカッション 0

正解：D

正解の根拠

CloudWatch Logs Insights のクエリ言語は filter, parse, fields, sort, limit を組み合わせます。filter で ERROR を絞り込み、parse で構造化し、sort と limit で上位を取得するのが基本パターンです。

主要演算子

演算子	機能
filter	条件絞り込み
parse	正規表現抽出
stats	集計

不正解の理由

A: stats は集計用で、個別レコードの上位取得とは異なります。
B: display や top は Insights の構文ではありません。
C: 構文が SQL 風で Insights 言語ではありません。

参考：Logs Insights Syntax

DVA-C02#5(troubleshooting)

DynamoDB テーブルで突発的に書き込みスロットリングが発生し、ProvisionedThroughputExceeded メトリクスが上昇しています。短期的に解消する手段と、長期的に再発を防ぐ手段の組み合わせはどれですか。(2 つ選択)

（2つ選択）

A. DAX を導入して書き込みをキャッシュ層で吸収する。
B. Auto Scaling のターゲット使用率を 90% に上げてしきい値の余裕を減らす。
C. Streams の Kinesis Data Firehose 連携を有効化する。
D. オンデマンドモードへ一時的に切り替え、需要に追従させる。
E. パーティションキーの設計を見直し、書き込み分散を改善する。

正解と解説ディスカッション 0

正解：D, E

正解の根拠

緊急対応としてはオンデマンドへの切替で需要追従し、根本対策として PK 設計を見直して書き込みのホットスポットを解消します。これは AWS が公式に推奨する短期/長期施策の組み合わせです。

スロットリング対策

期間	対策
短期	オンデマンド切替/容量増
長期	PK 再設計

不正解の理由

B: ターゲット使用率を上げると余裕が減りスロットリング再発リスクが高まります。
C: Streams + Firehose は連携用で、書き込み性能改善ではありません。
A: DAX は読み込みキャッシュ専用で書き込みには効果がありません。

参考：DynamoDB PK Design