DOPモニタリングとロギング
あるSaaS企業では、数千のリソースにまたがるCloudWatchメトリクスを、自社VPC内のOpenSearchクラスターおよびDatadogなどのサードパーティ製オブザーバビリティ基盤へほぼリアルタイムで連携し、独自ダッシュボードで統合監視したい。現在はLambda関数が定期的にGetMetricData APIをポーリングして転送しているが、監視対象メトリクス数の増加に伴いAPIスロットリング、コスト増、数分単位の遅延が問題化している。最小限の運用負荷で低遅延にメトリクスを継続的にエクスポートする方法はどれか。
AGetMetricDataのポーリング間隔を短縮し、Lambda関数の同時実行数を引き上げてスループットを増やす
GetMetricDataのポーリングは間隔短縮や並列化を行ってもAPI呼び出し回数とコストが線形に増加し、アカウントのスロットリング上限に達する。プル型のため数分の遅延も残り、数千リソースの低遅延・継続エクスポートには不向き。
BEventBridgeのスケジュールルールでListMetricsとGetMetricStatisticsを定期実行し、取得結果をAmazon S3にエクスポートしてからOpenSearch Serviceへバッチで取り込む
ListMetricsはメトリクスの名前空間やディメンションの一覧を返すAPIで実際の値は取得できず、値の取得には別APIが必要になる。スケジュール実行とS3経由の取り込みはバッチ処理となり、ほぼリアルタイム連携の要件を満たせない。
CCloudWatch Metric Streamsを作成し、Amazon Data Firehose経由でOpenSearchおよびサードパーティ宛にメトリクスを継続的にストリーミングする
✓ 正解
Metric Streamsはメトリクスの更新をプッシュ型でAmazon Data Firehoseへ継続配信し、OpenSearchやDatadog等のサードパーティへ低遅延で連携できる。ポーリング不要でスロットリングを回避でき、フルマネージドで運用負荷も最小に抑えられる。
DCloudWatch Logsサブスクリプションフィルターを設定し、メトリクスデータをAmazon Data Firehoseにリアルタイム送信する
サブスクリプションフィルターはCloudWatch Logsのログイベントをストリーム配信する機能で、メトリクスの配信には利用できない。メトリクスの継続的なエクスポートにはMetric Streamsを用いる必要があり、この構成では要件を満たせない。
解説
CloudWatch Metric Streamsは指定した名前空間のメトリクス更新をプッシュ型でAmazon Data Firehoseへ継続配信し、OpenSearchやDatadog等のサードパーティ基盤へ低遅延でエクスポートできるマネージド機能です。ポーリング不要のためGetMetricDataのAPIスロットリングやコスト増を回避でき、運用負荷を最小化できます。
選択肢0のGetMetricDataポーリングは呼び出し回数の増加でスロットリングとコストが悪化し、プル型ゆえの遅延も残ります。
選択肢1のListMetricsはメトリクス一覧取得用でS3経由の取り込みはバッチ処理になります。
選択肢3のサブスクリプションフィルターはログ配信用でメトリクスには利用できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →