DOPモニタリングとロギング
あるオンライン旅行予約サービスでは、ログイン→検索→予約→決済という複数ステップから成る重要なユーザーフローがあります。過去に、個々のコンポーネントは正常でもステップ間の連携不具合により決済が完了しない障害が発生し、顧客からの問い合わせで初めて気づく事態となりました。DevOpsチームは、実ユーザーのトラフィックに依存せず、このエンドツーエンドのフローを定期的に外部から検証し、問題を顧客より先に検知したいと考えています。最も適切なソリューションはどれですか。
ARoute 53のヘルスチェックで複数リージョンのエンドポイントのHTTP応答コードとレイテンシーを監視し、異常検知時にDNSフェイルオーバールーティングを実行してCloudWatchアラームで通知する
Route 53のヘルスチェックはエンドポイント単体のHTTP到達性やレイテンシーを監視するもので、ログインから決済までの複数ステップにわたる業務フローの連携を擬似実行して検証することはできず、要件を満たさない。
BCloudWatch Syntheticsのカナリアでログインから決済までの複数ステップをスクリプト化して定期実行し、SuccessPercentとDurationのメトリクスにCloudWatchアラームを設定する
✓ 正解
Syntheticsカナリアはスクリプトでユーザー操作を再現し、実トラフィックに依存せず複数ステップのフローを定期実行できる。各ステップの成否をSuccessPercentやDurationメトリクスで捕捉しアラーム化でき、顧客より先に検知できる。
CCloudWatch RUMをWebアプリケーションに組み込み、実ユーザーのページロード時間やJavaScriptエラーを収集してダッシュボードで継続的に監視する
CloudWatch RUMは実ユーザーのブラウザからテレメトリを収集する受動的な監視で、トラフィックが無い時間帯には検証できず、ユーザーが問題に遭遇する前に先回りして検知する能動的な合成監視の要件には合致しない。
DALBのターゲットグループのヘルスチェックとHealthyHostCountメトリクスを監視し、異常時にAuto Scalingとアラームアクションを発動して自動復旧させる
ALBのヘルスチェックとHealthyHostCountはターゲットインスタンスの正常性を示すだけで、個々のコンポーネントが正常でも起こり得るステップ間の連携不具合を検知できないため、エンドツーエンド検証の要件を満たさない。
解説
CloudWatch Synthetics のカナリアは、Puppeteer/Selenium ベースのスクリプトでユーザー操作を再現し、実トラフィックに依存せず定期的にエンドツーエンドのフローを検証できる。ログイン→検索→予約→決済といった複数ステップを1つのカナリアで擬似実行し、各ステップの成否や所要時間を SuccessPercent・Duration メトリクスとして発行できる。これにアラームを設定すれば、顧客が問題に遭遇する前にステップ間連携の不具合を検知できる。
選択肢Aの Route 53 ヘルスチェックは単一エンドポイントの到達性監視であり、複数ステップの業務フローを再現できない。
選択肢Cの CloudWatch RUM は実ユーザーのテレメトリを収集する受動的な手法で、トラフィックがない時間帯やユーザーが遭遇する前の事前検知には向かない。
選択肢Dの ALB ヘルスチェックはターゲットの正常性のみを見るため、各コンポーネントが正常でも成立するステップ間連携の障害は検知できない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →