DOPモニタリングとロギング
ある企業のAWS Lambda関数群が、注文件数・決済金額などのビジネスメトリクスをCloudWatch PutMetricData APIで直接発行しています。タイムセール期間中はLambdaの同時実行数が毎分数万回を超え、PutMetricData APIのスロットリングが頻発して一部のメトリクスが欠損します。また、APIコール単位のコストも問題になっています。追加の外部サービスを使わずにこの問題を根本的に解決し、スケーラブルで低コストなカスタムメトリクス発行の仕組みに移行するための最善の方法はどれですか？
ASQSキューを導入し、PutMetricData呼び出しをキューでバッファリングして別のLambda関数が1分ごとにバッチ送信するアーキテクチャに変更する
SQSキューの導入はPutMetricData呼び出しを遅延させるだけで、スロットリング問題の根本解決にはなりません。SQS・Lambda追加実行コストも発生します。
BCloudWatch Embedded Metrics Format（EMF）を採用し、Lambda関数がCloudWatch Logsに構造化JSONを書き込むことでPutMetricData APIを介さずにカスタムメトリクスを自動的に登録する
✓ 正解
CloudWatch EMFではCloudWatch Logsに構造化JSONを書き込むだけでカスタムメトリクスが自動登録され、PutMetricData API呼び出し不要でスロットリング回避。AWS Lambda Powertoolsがネイティブサポートしコード変更も最小限です。
CCloudWatch Metric StreamsをAmazon Data Firehoseに接続し、メトリクスをリアルタイムでS3に転送することでAPIコストを削減する
Metric StreamsはすでにCloudWatchに保存されたメトリクスを外部転送するサービスで、PutMetricData呼び出しのスロットリング問題は解決しません。
DLambda関数内でメトリクスをAmazon DynamoDBにバッファリングし、EventBridgeスケジューラーで1分ごとに集計してPutMetricDataでバッチ発行する
Lambda・DynamoDB・EventBridge組み合わせ構成は最も複雑で、DynamoDBコスト・Lambda実行コスト・運用負荷がいずれも増大し、スロットリング根本解決にもなりません。
解説
CloudWatch EMF（Embedded Metrics Format：埋め込みメトリクス形式）では、Lambda関数がstdout経由でCloudWatch Logsに特定の構造化JSONスキーマを書き込むと、CloudWatchが自動的にカスタムメトリクスとして解析・登録します。PutMetricData APIを一切呼び出さないためスロットリングは発生せず、追加コストもCloudWatch Logsへのログ書き込み分のみです。AWS Lambda Powertools（Python/TypeScript/Java）がEMFをネイティブサポートしており、コード変更は最小限です。
選択肢A（SQS + バッチLambda）はスロットリングを遅延させるだけで根本解決にならず、SQSコストと追加Lambda実行コストが発生します。
選択肢C（Metric Streams）はすでにCloudWatchに保存されたメトリクスを外部転送するサービスであり、書き込みのスロットリング問題を解決しません。
選択肢D（DynamoDB + EventBridge）は最も複雑な構成で、DynamoDBコスト・Lambda実行コスト・運用負荷がいずれも増大します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →