DVAトラブルシューティングと最適化

あるLambda関数(毎秒数百回呼び出される)は、ビジネスメトリクスを記録するために呼び出しごとにCloudWatchのPutMetricData APIを同期的に呼び出しています。その結果、関数の実行時間が増加し、API呼び出しによるコストとスロットリングも問題になっています。アプリケーションのコードからメトリクスを発行しつつ、レイテンシとコストを最小化する最も適切な方法はどれですか。

A
CloudWatch Embedded Metric Format (EMF) で構造化ログを標準出力に書き出し、CloudWatchにメトリクスを非同期で抽出させる
✓ 正解
EMFは特定形式のJSONログを標準出力に書くだけで、CloudWatchがログから自動的にメトリクスを抽出する。同期API呼び出しが不要なので実行時間が延びず、PutMetricDataのコストとスロットリングも回避でき、要件を満たす。
B
PutMetricDataの呼び出しを複数メトリクスでバッチ化し、リトライ付きで同期送信を続ける
バッチ化はAPI呼び出し回数を減らすが、依然として同期的なネットワーク呼び出しが実行パスに残るためレイテンシが発生する。スロットリングのリスクも完全には解消されず、最小化にはならない。
C
メトリクスをCloudWatch Logsに通常のテキストで出力し、メトリクスフィルタは設定しない
通常のテキストで出力しメトリクスフィルタも設定しないと、CloudWatchメトリクスとして集計やアラーム設定ができない。メトリクスを発行するという要件そのものを満たさない。
D
メトリクスをDynamoDBに書き込み、別のLambdaで集計してPutMetricDataを呼び出す
DynamoDB書き込みと集計用Lambdaを追加すると構成が複雑化し、追加のコストとレイテンシが発生する。レイテンシとコストを最小化するという要件に反し、過剰な設計となる。

解説

CloudWatch Embedded Metric Format (EMF) は、特定形式のJSONログを標準出力に書き出すだけで、CloudWatchがログから自動的にメトリクスを抽出・集計する仕組みである。 同期的なAPI呼び出しが実行パスから排除されるため、関数の実行時間が延びず、PutMetricDataのコストやスロットリングも回避できる。 選択肢Bは同期呼び出しが残る。 選択肢Cはメトリクス化できない。 選択肢Dは構成が複雑化する。

ドメイン別正答率・予想スコアでリアルタイムに実力把握

無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。

無料で演習を始める →
DVA の問題一覧に戻る