SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業はEC2インスタンス上でウェブアプリケーションを運用しています。CPU使用率80%超のアラームとメモリ使用率85%超のアラームをそれぞれ独立して設定していますが、どちらか一方だけが閾値を超えるたびにアラームが発報してオペレーターに通知されるため、アラート疲れが深刻な問題になっています。「CPUとメモリが同時に閾値を超えた場合にのみ通知を送る」という要件を、最も少ない追加設定で満たす方法はどれですか？
A既存の2つのアラームを参照するCloudWatch複合アラーム（Composite Alarm）をALARM_RULE = ALARM(CPU) AND ALARM(Memory)で作成し、複合アラームにのみSNS通知アクションを設定する
✓ 正解
CloudWatch Composite AlarmはAND/OR論理式で既存アラームを組み合わせる機能を持ち、新規リソース1つの追加だけでCPUとメモリが同時にALARMのときのみ通知できる。
B既存のアラームはそのままにして、SNSサブスクリプションのLambda関数で両アラームのCloudWatch API状態を取得し、両方がALARMの場合のみ別のSNSトピックに通知を転送するよう実装する
Lambda関数・追加SNSトピック・SNSサブスクリプションの3リソース作成が必要で、追加設定量が大幅に増加するため「最も少ない追加設定」の要件に合わない。
CCloudWatch Metric Mathを使ってCPU使用率とメモリ使用率を加算した合成メトリクスを定義し、合成値が所定の閾値を超えた場合にのみアラームを発報するよう新たに設定する
加算による合成メトリクスはAND条件を正確に表現できず、片方の値が極端に高い場合に閾値超過が起きうるため、誤検知の排除という目的を達成できない。
DAWS Systems Manager OpsCenterのCloudWatchアラーム統合を有効化し、2つのアラームが同時にALARM状態になったことをOpsItemダッシュボード上で確認してから手動で通知を送る
OpsItemを使った運用フローは目視確認と手動通知が前提であり、閾値超過を自動的に検知してリアルタイムで通知を送るという要件を満たさない。
解説
CloudWatch複合アラーム（Composite Alarm）は、既存の複数アラームをAND／OR論理式で組み合わせて評価する機能です。`ALARM_RULE = ALARM("cpu-alarm") AND ALARM("memory-alarm")`と設定することで、両方が同時にALARM状態になった場合のみ通知が発報されます。既存アラームをそのまま再利用でき、複合アラーム1つを追加するだけで要件を満たせます。
選択肢BのLambda＋APIポーリングは、SNSトリガー・Lambda関数・追加SNSトピックの3リソース作成が必要で設定が複雑になり、「最も少ない追加設定」の要件に反する。
選択肢CのMetric Math加算は、一方の値が低いときに合成値が閾値を下回る場合があり、AND条件を正確に表現できないため誤検知や見逃しが発生しうる。
選択肢DのOpsCenter活用は、手動確認が前提のワークフローであり、リアルタイム自動通知の要件を満たさない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →