最低限見ておきたい監視項目はCPU/Memory/ディスク/NWでどれもCloudWatchで監視可能。 関しのしきい値は各サーバーに寄ってまちまちなので運用開始してから調整する必要がある。

CloudWatch+CloudWatch Alarm

AWSを使って学ぶ監視設計

監視対象何を監視スべきか
監視内容何を確認スべきか
監視項目ユーザー視点で考える。メトリクスとしてのCPUやI/Oではそれ自体はユーザーには遠いメトリクスで、重要なのはレスポンスタイムなど
メトリクス原因究明には役立つので取れるものは取っておく
アラート多すぎても誰も対応しなくなるので本当に必要なものにする

監視SaaS

DataDog/mackerelなどがあるが、CloudWatchに比べるとコストがかかる。複数AWSアカウントの監視をまとめて実行したいなどのCloudWatch+αの要件が求められた時に導入を検討する。

保存期間

一年のうちでイベント(夏休みや年末年始のアクセス増加)がある場合を考えて最低1年は保存しておく。

アラート

アラートの通知先は柔軟に選択できると良い。AWSの場合はSNSを使っておくとその先の切り替えができる。

SLO/SLIの設定

500エラー率。0.01% レイテンシー。99%が1秒以内など

不変なものではなく、運用してみて達成が難しいものは実情に合わせて見直す。

機能ごとの重要度たいしてSLOを設定する。ユーザーログイン機能が使えないとすべてが使えない場合はユーザーログイン機能は最重要になる

外形監視/異常検知

Synthetics anomaly detection

バックアップ

  1. 目標復旧時間(RTO)目標復旧時点(RPO)を決める
  2. バックアップ種別はシステムバックアップとデータバックアップ。システムバックアップはクラウドにおいては構築後に取っておけば良い。問題はデータバックアップ。 RPOによってバックアップ周期を決める。
EC2初期構築時にAMI取得、以後はパッチ当て前にAMI取得の手動バックアップで良いと思われる。
静的コンテンツS3に配置しているのであれば、S3の可用性が高いため特にバックアップは必要ない。オペミスなどに備える場合はバージョニングを有効にしておくと対応できるが、その分保持容量が増えるので、頻繁に更新されるものについては古いバージョンを消すようにする
データベースAuroraを利用しているのであれば、データが消えてしまう可能性は限りなく低い。Auroraのバックアップ保持期間内であれば、特定の時点のデータで、DBクラスタを作成できる機能があり、別DBに復元することでオペミスによるデータロスにも対応可能

トップ   編集 凍結 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-12-25 (日) 08:26:44