AWS Certified Developer - Associate (DVA-C02) #13 Domain 4-2 トラブルシューティングと最適化 — 最適化と問題解決

インフラ AWS Certification
読了 4分

#12 オブザーバビリティ で何が起きているかを見る方法を押さえました。最後の記事は それを改善し、よくあるエラーを解決する方法 です。試験は性能・コスト最適化とともに、具体的な エラーコードを解釈する 能力を問います。

キャッシュレイヤー #

同じデータを繰り返し照会するなら、キャッシュで遅延・コスト・バックエンド負荷を減らします。どのレイヤーのキャッシュかが核心の区別です。

キャッシュ位置用途
CloudFrontエッジ (全世界)静的・動的コンテンツの CDN
API Gateway キャッシュAPI ステージREST API レスポンスのキャッシング
ElastiCacheアプリケーションレイヤーDB の前の汎用インメモリキャッシュ (Redis/Memcached)
DAXDynamoDB の前DynamoDB 専用のマイクロ秒キャッシュ
  • 「全世界のユーザーに静的アセットを高速に」 → CloudFront。
  • 「リレーショナル DB の繰り返しクエリ結果をキャッシュ」 → ElastiCache。
  • 「DynamoDB の読み取りをマイクロ秒で」 → DAX。
  • 「API Gateway の同じレスポンスの繰り返し呼び出しを減らす」 → API Gateway キャッシュ。

キャッシング戦略 #

  • Lazy Loading (Cache-Aside) — キャッシュになければ DB から読んで埋める。使われないデータはキャッシュしない。
  • Write-Through — 書き込み時にキャッシュも一緒に更新。常に最新だが読まれないデータもキャッシュ。
  • TTL — 有効期限で古いデータ (stale) を防ぐ。

Lambda 性能チューニング #

つまみ効果
メモリ設定メモリを上げると CPU・ネットワークも比例して増加。しばしば大きなメモリの方が安く速い
コールドスタートプロビジョニング済み同時実行、ハンドラー外の初期化の再利用
同時実行予約済み同時実行で分離、スロットリング防止
パッケージサイズ小さく保つ、レイヤーで依存関係を分離

試験の核心: Lambda は メモリのみ設定 し CPU はそれに比例します。「CPU が不足して遅い」の答えは メモリを上げること です。Lambda Power Tuning でコスト・性能の最適点を見つけます。

よく出るエラーコード #

トラブルシューティングドメインは エラーコードを見て原因を当てる問題 を出します。覚えておけば即答できます。

コード意味対応
429 Too Many Requests / ThrottlingExceptionスロットリング (API Gateway・SDK・サービス上限)指数バックオフ再試行、上限引き上げ
ProvisionedThroughputExceededExceptionDynamoDB の容量超過容量引き上げ・キー分散・バックオフ
502 Bad GatewayAPI GW プロキシ統合 Lambda のレスポンス形式エラーレスポンス statusCode/body 形式の修正
504 Gateway Timeout統合タイムアウト (29 秒) の超過処理短縮・非同期パターン
403 / AccessDenied権限不足IAM ポリシー・リソースポリシーの確認
ConditionalCheckFailedException条件付き書き込みの条件不一致楽観的ロックの競合 → 再試行
ProvisionedConcurrency / TooManyRequestsException(Lambda)同時実行上限の超過予約/アカウント上限の調整

核心となるマッピングをいくつか:

  • 502 = Lambda のレスポンス形式の問題 (プロキシ統合での誤った返却)。
  • 504 = 時間がかかりすぎ (29 秒の統合タイムアウト)。
  • 429 = スロットリング → 指数バックオフ。
  • ConditionalCheckFailed = 同時修正の競合 → 再試行。

コスト最適化ポイント #

  • Lambda メモリの適正化 — 小さすぎると遅くてかえって高く、大きすぎると無駄。Power Tuning で最適点。
  • DynamoDB の容量モード — トラフィックが断続的なら オンデマンド、予測可能ならプロビジョニング + Auto Scaling。
  • S3 ライフサイクル + ストレージクラス — 古いデータを安価なレイヤーへ。
  • キャッシング — バックエンド呼び出し・データ転送コストの削減。

試験の出題パターン #

  • 「Lambda が遅く CPU が不足している。」 → メモリ引き上げ (CPU 比例)。
  • 「API で 502 が出る。」 → プロキシ統合 Lambda のレスポンス形式。
  • 「API で 504 が出る。」 → 29 秒タイムアウトの超過、処理短縮/非同期化。
  • 「DynamoDB の読み取りで throughput exceeded。」 → 容量・キー分散・バックオフ。
  • 「条件付き更新が失敗する。」 → 同時修正の競合、再試行。
  • 「DynamoDB の繰り返し読み取りをマイクロ秒で。」 → DAX。
  • 「全世界の静的コンテンツの遅延を減らす。」 → CloudFront。
  • 「スロットリング (429) にどう対応。」 → 指数バックオフ再試行。

よく出会う落とし穴 #

1) Lambda の CPU を直接設定しようとする #

CPU は直接設定できません。メモリに比例します。

2) 502 と 504 の混同 #

502 はレスポンス形式エラー、504 はタイムアウトです。

3) キャッシュレイヤーの混同 #

DynamoDB 専用は DAX、汎用は ElastiCache、エッジは CloudFront です。

まとめ #

この記事の要点:

  • キャッシング — CloudFront (エッジ)・ElastiCache (汎用)・DAX (DynamoDB)・API GW キャッシュ。Lazy Loading vs Write-Through
  • Lambda は メモリ = CPU。遅ければメモリ引き上げ
  • エラーコード — 502 (レスポンス形式)・504 (タイムアウト)・429 (スロットリング)・ConditionalCheckFailed (同時競合)
  • コスト — メモリ適正化、容量モード、ライフサイクル、キャッシング

次へ — 試験のヒント #

13 本で 4 つのドメインを一巡しました。#14 試験のヒント では、時間管理、制約キーワードで選択肢を絞る方法、よく混同する概念ペア、そして受験直前のチェックリストを整理します。

X