AWS SAA(Solutions Architect - Associate)対策
監視の設計
このレッスンでできるようになること。障害調査のシナリオを読んで、「その問いに答えられるのはどの道具か」から監視サービスを選べるようになります。
要件の文から入る
ある会社のマイクロサービス構成の API が、ある時間帯だけ応答に時間がかかります。API Gateway の後ろに Lambda が並び、その先に DynamoDB と外部 API があります。運用チームは「遅いのは分かるが、どこで時間を食っているのか分からない」と言っています。アプリの改修は最小限にしたいという要件です。
答えは AWS X-Ray を有効にして分散トレースを見るです。決め手は「どこで時間を食っているのか分からない」という一文です。CloudWatch のメトリクスは「遅い」ことは教えてくれますが、「どのサービスで遅いか」は教えてくれません。調査の問いの形が、そのまま道具を決めます。
調査の問いから逆算する
監視の 3 つの道具は、答えられる問いが違います。ここを問いの形で覚えると、シナリオ問題がほぼ機械的に解けます。
| 調査の問い | 答えられる道具 | 見えるもの |
|---|---|---|
| いつから、どのくらい悪化したのか | CloudWatch メトリクス | 数値の時系列。しきい値を超えたらアラーム |
| どのリクエストで、何のエラーが出たのか | CloudWatch Logs と Logs Insights | 生のログ本文。検索と集計 |
| 一連の処理のうち、どのサービスで時間を食っているか | AWS X-Ray | サービス間の呼び出しと各区間の所要時間 |
| 誰がどの API を呼んだのか | CloudTrail | 管理操作の証跡 (監視ではなく監査) |
最後の行を混ぜているのは、本番で CloudTrail が誤答として並ぶからです。CloudTrail は誰が何をしたかの記録で、アプリの遅さやエラーの調査には答えません。
Logs Insights が要る場面
ログをただ保存するだけなら CloudWatch Logs で足ります。しかし「過去 1 週間のログから、エラーコードごとの件数を数えたい」「特定のリクエスト ID の流れを追いたい」といった要件が出たら、CloudWatch Logs Insights です。専用のクエリ構文でログを検索し、集計し、可視化まで持っていけます。
ここで並びやすい誤答が、ログを S3 に出して Athena で集計する案です。動きますし、長期の大量ログを安く分析したい要件なら正解にもなります。ただし「今起きている障害をすぐ調べたい」という文脈では、パイプラインを組む分だけ遠回りです。即応性を問われたら Logs Insights、長期保管と大規模分析を問われたら S3 と Athenaと切り分けます。
メモリとディスクは標準では見えない
監視の設計で最も落としやすいのが、EC2 の標準メトリクスの範囲です。CPU 使用率、ネットワークの入出力、EBS の入出力はハイパーバイザー側から取れるので標準で出ます。しかしメモリ使用率とディスクの空き容量は標準メトリクスに含まれません。 これらはゲスト OS の内側の情報だからです。
ですから「メモリ枯渇でプロセスが落ちる事象を検知したい」「ディスクフルの前に気づきたい」という要件が出たら、答えは必ず CloudWatch エージェントを導入してカスタムメトリクスを送るです。「CloudWatch でメモリ使用率のアラームを設定する」とだけ書かれた選択肢は、エージェントの導入が抜けているので落ちます。オンプレミスのサーバーやアプリのログをまとめて CloudWatch に集めたい場合も、同じエージェントが答えになります。
要件語から構成への対応表
| 要件文の言い回し | 選ぶもの |
|---|---|
| しきい値を超えたら通知したい | CloudWatch アラームと SNS |
| ログからエラーの件数を集計したい | CloudWatch Logs Insights |
| どのマイクロサービスがボトルネックか知りたい | X-Ray の分散トレースとサービスマップ |
| メモリ使用率やディスク空き容量を監視したい | CloudWatch エージェントを導入する |
| 誰がリソースを変更したのか調べたい | CloudTrail |
| 数年分のログを安く保管して後で分析したい | S3 へエクスポートし Athena で分析する |
| 特定のログ文言が出たら自動で対処したい | メトリクスフィルタでアラーム化し、Lambda を起動する |
よくある引っ掛け
1 つめは、遅延の原因調査に CloudWatch のメトリクスを選んでしまうものです。メトリクスは症状の推移を示しますが、原因の場所は示しません。「どこで」と書かれていたら X-Ray です。
2 つめは、メモリのアラームをエージェント抜きで設定する選択肢です。標準では取れないメトリクスにアラームは張れません。
まとめ
- 数値の推移は CloudWatch メトリクス、ログの検索と集計は Logs Insights、区間ごとの所要時間は X-Ray です
- 「どこで時間を食っているか」という問いは X-Ray の指定と読み替えます
- EC2 の標準メトリクスにメモリとディスク空き容量は含まれません。エージェントが前提です
- CloudTrail は監査の証跡で、性能障害の調査には答えません
- 即応の調査は Logs Insights、長期の大量分析は S3 と Athena で切り分けます
復習ミニクイズ
ある企業が API Gateway、複数の Lambda、DynamoDB、外部 API から成るマイクロサービスを運用しています。CloudWatch のメトリクスでは特定の時間帯に応答時間が伸びていることまでは分かりますが、一連の処理のうちどのコンポーネントで時間を消費しているかが特定できません。アプリの改修は最小限に抑えたいという要件です。最も適切な対応はどれですか。