DVAトラブルシューティングと最適化
高頻度で実行されるLambda関数から、顧客ティア・リージョン・APIバージョンといった高カーディナリティのディメンションを持つカスタムメトリクスをCloudWatchへ送信したい。現在は処理中にPutMetricData APIを同期呼び出ししているが、API呼び出しのレイテンシと、TransactionsPerSecond制限によるスロットリングが発生している。関数のレイテンシを増やさず、確実にメトリクスを記録する最も効率的な方法はどれか。
ACloudWatch Embedded Metric Format (EMF) で構造化ログをstdoutに出力し、CloudWatchにメトリクスを自動抽出させる
✓ 正解
EMFは特定フォーマットのJSONログをstdoutへ書き出すだけでCloudWatchが非同期にメトリクスを抽出するため、PutMetricData呼び出しが不要になりレイテンシもAPIスロットリングも発生しない。高カーディナリティのディメンションもログとして保持でき、要件を満たす唯一の方法。
BPutMetricDataの呼び出しを最大1000データポイント単位でバッチ化し、関数終了時にまとめて送信する
バッチ化してもPutMetricDataの同期API呼び出し自体は残り、ネットワークレイテンシとTPS制限のリスクが消えない。さらにディメンションの組み合わせが多い高カーディナリティ環境では制限に達しやすく、根本的な解決にならない。
Cロググループにメトリクスフィルタを設定し、ログ中の数値からカスタムメトリクスを生成する
メトリクスフィルタはログから数値を抽出できるが、ディメンションは事前定義した少数のみで、顧客ティアなど高カーディナリティの値を動的にディメンション展開できない。要件のメトリクス設計を満たせない。
DメトリクスをSQSキューへ送信し、別のLambda関数が集約してPutMetricDataを呼び出す
SQSと集約用Lambdaを追加する構成は運用負荷とコストが増え、メトリクス反映に遅延が生じる。最終的にPutMetricDataのTPS制限も残るため、最も効率的とは言えず過剰な構成になる。
解説
CloudWatch Embedded Metric Format (EMF) は、所定のスキーマに沿った構造化JSONをアプリケーションログとして標準出力に書き出すだけで、CloudWatchがログから自動的にカスタムメトリクスを抽出する仕組み。
PutMetricDataのような同期API呼び出しが不要なため、関数のレイテンシに影響せず、API TPS制限によるスロットリングも回避できる。高カーディナリティのディメンションもログイベントとして保持される。
選択肢Bのバッチ化PutMetricDataは、同期API呼び出しとTPS制限が残るため根本解決にならない。
選択肢Cのメトリクスフィルタは、高カーディナリティのディメンションを動的に展開できない。
選択肢DのSQS経由集約は、追加コンポーネントによる運用負荷・遅延・最終的なAPI制限が残る。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →