最低限見ておきたい監視項目はCPU/Memory/ディスク/NWでどれもCloudWatchで監視可能。 関しのしきい値は各サーバーに寄ってまちまちなので運用開始してから調整する必要がある。
CloudWatch+CloudWatch Alarm
監視対象 | 何を監視スべきか |
監視内容 | 何を確認スべきか |
監視項目 | ユーザー視点で考える。メトリクスとしてのCPUやI/Oではそれ自体はユーザーには遠いメトリクスで、重要なのはレスポンスタイムなど |
メトリクス | 原因究明には役立つので取れるものは取っておく |
アラート | 多すぎても誰も対応しなくなるので本当に必要なものにする |
DataDog/mackerelなどがあるが、CloudWatchに比べるとコストがかかる。複数AWSアカウントの監視をまとめて実行したいなどのCloudWatch+αの要件が求められた時に導入を検討する。
一年のうちでイベント(夏休みや年末年始のアクセス増加)がある場合を考えて最低1年は保存しておく。
アラートの通知先は柔軟に選択できると良い。AWSの場合はSNSを使っておくとその先の切り替えができる。
500エラー率。0.01% レイテンシー。99%が1秒以内など
不変なものではなく、運用してみて達成が難しいものは実情に合わせて見直す。
機能ごとの重要度たいしてSLOを設定する。ユーザーログイン機能が使えないとすべてが使えない場合はユーザーログイン機能は最重要になる
Synthetics anomaly detection
EC2 | 初期構築時にAMI取得、以後はパッチ当て前にAMI取得の手動バックアップで良いと思われる。 |
静的コンテンツ | S3に配置しているのであれば、S3の可用性が高いため特にバックアップは必要ない。オペミスなどに備える場合はバージョニングを有効にしておくと対応できるが、その分保持容量が増えるので、頻繁に更新されるものについては古いバージョンを消すようにする |
データベース | Auroraを利用しているのであれば、データが消えてしまう可能性は限りなく低い。Auroraのバックアップ保持期間内であれば、特定の時点のデータで、DBクラスタを作成できる機能があり、別DBに復元することでオペミスによるデータロスにも対応可能 |