AWS Certified Solutions Architect - Associate 問題集

正解: C

正解の理由
信頼性の柱の設計原則「障害から自動的に復旧する」は、ワークロードを重要業績評価指標（KPI）で監視し、しきい値を超えたら自動化を動かすよう書き、その KPI はサービスの運用の技術的な側面ではなく、事業の価値を測るものにするべきだと書いている。注文の完了件数は事業の価値そのものなので、決済の外部接続のようにサーバーの外で起きた障害でも値に表れる。CloudWatch のメトリクスアラームは1つのメトリクスをしきい値と比べ、Amazon SNS トピックへの通知や、EC2・Auto Scaling のアクション、Systems Manager の OpsItem やインシデントの作成を動かせる。

違う選択肢
「CPU 使用率とディスクの読み書きのアラームを複合アラームにまとめ、注文が止まった状態を ALARM として、通知と手当ての自動化を動かす」… 複合アラームは、ほかのアラームの状態を組み合わせてノイズを減らす仕組みで、元のアラームが CPU とディスクのままなら、測っているのは技術の側面である。今回の障害では CPU は平常だったので、組み合わせても ALARM にならない。
「完了した注文の件数をカスタムメトリクスとして送り、その値で複合アラームを作って、ALARM で Auto Scaling のアクションを直接動かす」… 複合アラームは、ルール式でほかのアラームの状態を見るもので、メトリクスを直接見張るものではない。さらに CloudWatch のページは、複合アラームは SNS の通知や OpsItem の作成はできるが、EC2 や Auto Scaling のアクションは実行できないと書いている。
「EC2 のステータスチェックの失敗を示すメトリクスでアラームを作り、注文が止まる前にインスタンスを復旧させて、手当てを自動化する」… ステータスチェックは、EC2 のインスタンスやその載る基盤が動いているかを見る技術の指標である。今回のようにインスタンスは正常で外部接続が止まった場合は値が変わらず、注文が止まったことを捉えられない。

押さえどころ
可用性の目標を事業の言葉で決めたら、同じ言葉で測れるメトリクスを作ってアラームを掛ける。CPU やステータスチェックは原因を探すときの手がかりとして残し、通知と自動化の引き金は事業の KPI に置く。アラームが多すぎるときは、複合アラームにまとめて通知を絞る。