無限ノック › DOP 練習問題一覧 › 問題
DOPモニタリングとロギング

ある企業はAmazon EKS上で多数のマイクロサービスを運用している。DevOpsチームは、ポッド/ノード/クラスターレベルのCPU・メモリ・ネットワーク使用率などのパフォーマンスメトリクスと、コンテナのログを一元的に収集し、CloudWatch上で相関分析やアラート設定を行いたい。アプリケーションコードの変更は避け、標準化された方法で実装したい。最も適切な方法はどれか。

A
CloudWatch Container InsightsをEKSクラスターで有効化し、CloudWatch agentでインフラメトリクスを、Fluent BitでコンテナログをDaemonSetとして収集する
✓ 正解
Container Insightsを有効化しCloudWatch agentをDaemonSetで配置すると、ポッド/ノード/クラスターのCPU・メモリ・ネットワーク等のメトリクスを自動収集し、Fluent BitでコンテナログをCloudWatch Logsへ集約できる。アプリ改修不要で相関分析・アラートも実現できる。
B
各マイクロサービスにX-Ray SDKを組み込み、生成されるサービスマップとトレースからノードおよびポッドのリソース使用率を取得する
X-Rayは分散トレースとサービスマップでリクエストの経路やレイテンシを可視化するサービスで、ノードやポッドのCPU・メモリ使用率などインフラ性能メトリクスは収集できない。SDKの組み込みが必要でアプリ改修も避けられない。
C
CloudWatch agentをPrometheusモードで単一ノードに配置し、スクレイプした一部のメトリクスのみをCloudWatchへ送信する
CloudWatch agentのPrometheus対応は有用だが、単一ノードへの配置ではクラスター全体のポッド/ノードを網羅できず、標準化された一元収集にならない。コンテナログの収集も別途必要で、要件を部分的にしか満たせない。
D
各ノードでkubectl topの結果を定期実行するCronJobで収集し、Lambda関数経由でCloudWatchカスタムメトリクスとしてPutMetricDataし、別途DaemonSetでコンテナログも収集する
kubectl topとCronJob、Lambda経由のPutMetricDataは独自実装の作り込みが多く保守負荷が高い。取得できるメトリクスの粒度も粗く、標準化された方法という要件を満たさず、運用の一貫性や信頼性の面でも劣る。

解説

CloudWatch Container Insightsを有効化し、CloudWatch agentをDaemonSetとして配置すると、ポッド/ノード/クラスターのCPU・メモリ・ネットワーク等のパフォーマンスメトリクスを自動収集できます。あわせてFluent BitでコンテナログをCloudWatch Logsへ集約でき、メトリクスとログを相関分析・アラート設定できます。アプリコードの改修は不要で標準化された実装が可能です。 選択肢1のX-Rayはトレースとサービスマップ用でインフラ性能メトリクスは収集できません。 選択肢2のPrometheusモード単一ノード配置はクラスター全体を網羅できません。 選択肢3のkubectl top+Lambdaは独自実装で保守負荷が高く粒度も粗くなります。

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

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

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