WEB問題集
運用チームは本番 EC2 群の CPU 使用率について、夜間バッチ実行時にだけ閾値を変えたいと考えています。曜日や時間帯ごとの正常レンジを学習し、想定外のピークだけを検知したい場合、最も運用負荷が低い方法はどれですか。
解説
正解の根拠
CloudWatch Anomaly Detection はメトリクスの過去 2 週間のパターンから時間帯や曜日別の期待レンジを自動学習し、バンド外の値だけをアラーム化できます。固定閾値の切り替え運用が不要になり、夜間バッチで CPU が高くても期待範囲内なら誤検知を抑制できます。
主要監視手法の比較
| 方式 | 動的閾値 | 運用負荷 |
|---|---|---|
| 固定アラーム | 不可 | 高（時間帯ごとに調整） |
| Anomaly Detection | 可（自動学習） | 低 |
| カスタム Lambda | 可（自作） | 非常に高 |
| Synthetics | 不可（外形監視） | 中 |
設定例
aws cloudwatch put-metric-alarm
--alarm-name cpu-anomaly
--metric-name CPUUtilization
--namespace AWS/EC2
--threshold-metric-id ad1
--comparison-operator GreaterThanUpperThreshold
--evaluation-periods 2不正解の理由
- B: 固定閾値切替方式は時間帯ごとの正常レンジ学習機能を持たない副作用があり、運用負荷も高くなる方式です。
- C: Synthetics は外形監視が目的のサービスで、CPU メトリクスの異常検知機能は備えていない設計目的です。
- D: 自作モデル方式は実装と保守コストが大きい副作用があり、Anomaly Detection のマネージド機能の代替には設計負荷が大きい構成です。
マイクロサービス基盤で複数の Lambda 関数と ECS タスクが連携しています。トレースで遅延ボトルネックを特定し、サービスマップで依存関係を可視化したい場合、最も適切なソリューションはどれですか。
解説
正解の根拠
AWS X-Ray は分散トレースとサービスマップを提供し、リクエストごとのレイテンシ内訳を可視化できます。Lambda は組み込み統合、ECS は ADOT または X-Ray デーモンで送信でき、ボトルネック特定が容易になります。
分散観測手法の比較
| 機能 | X-Ray | Logs Insights |
|---|---|---|
| サービスマップ | あり | なし |
| セグメント時系列 | あり | なし |
| ログ全文検索 | 限定 | 得意 |
不正解の理由
- A: ALB アクセスログのみではマイクロサービス間の依存関係を把握できない副作用があり、サービスマップ相当の可視化には機能不足です。
- B: ログ結合では遅延の階層的内訳を視覚化できない副作用があり、トレースのセグメント時系列分析には機能対応していません。
- C: CloudTrail は管理 API 呼出が記録対象の機能で、アプリ間のリクエストトレース用途には設計目的とデータ範囲が異なります。
参考：AWS X-Ray
運用チームは ECS on Fargate のコンテナレベルの CPU・メモリ・ネットワーク使用率を可視化し、タスク単位でドリルダウン分析したいと考えています。最小設定で実現するソリューションはどれですか。
解説
正解の根拠
Container Insights は ECS / EKS 向けにクラスター・サービス・タスク・コンテナ単位のメトリクスとログを自動収集します。Fargate ではクラスター設定で有効化するだけでドリルダウン可能なダッシュボードが提供されます。
コンテナ可観測性の比較
| 方式 | セットアップ | 粒度 |
|---|---|---|
| Container Insights | 有効化のみ | タスク・コンテナ |
| サイドカー Agent | 個別実装 | 柔軟 |
| X-Ray | トレース用 | リクエスト |
| セルフ Prometheus | 運用負荷大 | 柔軟 |
不正解の理由
- D: サイドカー導入はタスク定義の改修が必要で運用負荷が高いです。
- A: X-Ray はトレース向けで、リソース使用率の可視化には不向きです。
- B: セルフ Prometheus は構築運用が複雑です。
運用チームは ALB 配下の Web アプリで、特定の URL パスに対するリアルユーザーの体感レイテンシを地域別に把握したいと考えています。最も適切なソリューションはどれですか。
解説
正解の根拠
CloudWatch RUM はリアルユーザーモニタリングで、ブラウザから収集した Core Web Vitals やページロード時間、地域別レイテンシを可視化します。実ユーザーの体感を把握するのに最適です。
監視サービスの比較
| サービス | 用途 |
|---|---|
| RUM | 実ユーザーの体感計測 |
| Synthetics | 合成監視 / 外形監視 |
| X-Ray | 分散トレース |
| ALB ログ | サーバ側応答時間 |
不正解の理由
- A: ALB ログはサーバ応答時間のみで、ブラウザ側のレンダリング時間や Core Web Vitals を含まずユーザー体感計測には不足です。
- B: X-Ray はサーバ側分散トレースが主目的で、ブラウザ側レンダリング時間や RUM 機能は計測対象外となります。
- C: Synthetics はスケジュール起動の合成監視で、実ユーザートラフィックの体感レイテンシを直接計測する用途とは設計目的が異なります。
運用チームは複数の AWS アカウントから CloudWatch メトリクスを単一のダッシュボードに集約し、リージョン横断で可視化したいと考えています。最小設定で実現する方法はどれですか。
解説
正解の根拠
CloudWatch クロスアカウント・クロスリージョン可観測性を使うと、モニタリングアカウントからソースアカウントのメトリクス、ログ、トレースを直接参照できます。Organizations と統合可能で集約用の Lambda を自作する必要がありません。
集約手法の比較
| 方式 | 運用負荷 |
|---|---|
| クロスアカウント可観測性 | 低（マネージド） |
| Lambda カスタム集約 | 高 |
| URL 共有 | 低だが集約不可 |
| CloudTrail Lake | API 監査用途 |
不正解の理由
- A: 自前実装は重複データ・運用負荷の問題があります。
- D: ダッシュボードを集約しません。
- C: CloudTrail Lake はメトリクスの集約には使えません。
参考：クロスアカウント可観測性