DVAトラブルシューティングと最適化
あるLambda関数（同時実行数が高く、毎分数万回呼び出される）は、注文金額やカテゴリといったビジネスメトリクスを記録するため、呼び出しごとにCloudWatchのPutMetricData APIを同期的に呼び出しています。最近、関数のレイテンシ増加とPutMetricDataのスロットリング（Rate exceeded）が発生しています。メトリクス記録のオーバーヘッドとスロットリングを最小化しつつ、カスタムメトリクスを取得し続ける最も効率的な方法はどれですか。
ACloudWatch Embedded Metric Format(EMF)で構造化ログをstdoutに出力し、CloudWatchに非同期でメトリクスを抽出させる
✓ 正解
EMFは構造化JSONログをstdoutへ書き出すだけでメトリクス化でき、実行中にAPIコールを行わないためレイテンシを増やさず、メトリクス抽出はCloudWatchが非同期で実施するためPutMetricDataのスロットリングも発生しない。最も効率的な方法。
BPutMetricDataの呼び出しを高解像度メトリクス(1秒粒度)に変更し、StorageResolutionを1に設定する
高解像度メトリクスにしてもPutMetricDataを同期的に呼び出す構造は変わらず、レイテンシとRate exceededは解消されない。むしろ1秒粒度のメトリクス保存はコストを増加させるため要件に反する。
C複数の呼び出し結果をLambda内の配列にバッファし、最大1000データポイントをまとめてPutMetricDataで送信する
Lambdaは呼び出しごとに独立したインスタンスで処理が完結するため、配列にバッファしても複数呼び出しを跨いで1000件を蓄積できない。結局各実行で同期APIコールが残り、レイテンシ問題は解決しない。
DCloudWatchのサービスクォータ引き上げをリクエストし、PutMetricDataのTPS上限を緩和する
クォータを引き上げてもLambda実行中に同期APIを呼ぶ構造は変わらず、レイテンシの根本原因は残る。上限緩和は一時しのぎで運用負荷とコストの面でも最適解ではない。
解説
CloudWatch Embedded Metric Format(EMF)は、特定のJSON構造でログをstdoutへ出力するだけでメトリクスを生成できる仕組みです。
Lambdaの実行内でAPIコールを行わないため同期的なレイテンシが発生せず、CloudWatch側がログから非同期にメトリクスを抽出するためPutMetricDataのスロットリングも回避できます。高カーディナリティのディメンションも扱いやすく、Lambda環境ではPowertoolsで容易に実装できます。
選択肢Bの高解像度メトリクスは、依然としてPutMetricDataを同期呼び出しするためレイテンシとスロットリングは解消されず、むしろコストが増えます。
選択肢CのバッチPutMetricDataは呼び出し回数を減らせますが、Lambdaは呼び出しごとに別インスタンスで終了するためバッファを跨いで蓄積できず、同期APIコール自体も残ります。
選択肢Dのクォータ引き上げは根本のレイテンシ要因(同期API呼び出し)を解消せず、運用負荷とコストの観点でも適切ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →