AWS/監視 の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• AWS/監視 へ行く。
• AWS/監視 の差分を削除

#author("2022-12-24T23:18:53+00:00","default:wikiadmin","wikiadmin")
#author("2022-12-24T23:26:44+00:00","default:wikiadmin","wikiadmin")
-監視についてまとめる

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

CloudWatch+CloudWatch Alarm


*AWSを使って学ぶ監視設計 [#x6ee2a50]

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

*監視SaaS [#s0570e49]

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

*保存期間 [#ibe8c3e2]

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

*アラート [#be4f891f]

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

*SLO/SLIの設定 [#fe591f31]

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

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

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



*外形監視/異常検知 [#y5f5a167]

Synthetics
anomaly detection

*バックアップ [#t7f58e3d]

+目標復旧時間(RTO)目標復旧時点(RPO)を決める
+バックアップ種別はシステムバックアップとデータバックアップ。システムバックアップはクラウドにおいては構築後に取っておけば良い。問題はデータバックアップ。
RPOによってバックアップ周期を決める。

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