CloudWatchアラームによる
 サービス継続のための監視入門
 2022/7/29
 AWS事業本部コンサルティング部 猪股翔


2 自己紹介 猪股 翔（inomaso） ● 2021年1月入社 (元金融系SIer)
 ● AWS事業本部コンサルティング部
 ● 好きなAWSサービス
 ○ AWS Certificate Manager
 ○ Amazon CloudWatch
 ● 好きなIaCツール
 ○ Terraform @inomasosan


3 この動画は… 想定聴講者 ● シンプルなWebシステム(ELB+EC2+RDS)を構築予定 ● 監視をどこから手をつけていいかわからない ゴール ● スモールスタートな監視の導入方法がわかる ● 監視すべきポイントが理解できる


4 よくあるご要望 AWSに構築したリソースに対して 最小コストで最低限の監視をしたい

5 従来の監視システムの利用を検討

6 昔からよくある監視構成

7 昔からよくある監視構成 メリット ● 従来と同様の方法で監視設定が可能 ● 無料の監視ソフトの採用で、ランニングコストを抑えること ができる ● バージョンアップで機能が充実している

8 昔からよくある監視構成 デメリット ● 監視設定が秘伝のタレ化しやすい ● Amazon CloudWatchのメトリクスを監視するためには、専 用のテンプレートやスクリプトが必要 ● 監視ソフトのバージョンアップが大規模になるケースがあ る ● 監視サーバ自体の運用・保守が必要

9 クラウド監視サービスを検討

10 クラウド監視サービス 色々なクラウド監視サービスが世にでており、ほとんどの サービスでフルスタック的(APM、インフラ監視、Synthetics等) な監視が可能

11 どのクラウド監視サービスがいいの？

12 スモールスタートで始める監視 特に監視要件が決まっておらず、最低限のコストで監視を導 入したいのであれば、スモールスタートで始めることができる Amazon CloudWatch(以下、CloudWatch)がオススメ

13 CloudWatchとは？ ● CloudWatchは、AWSリソースやアプリケーションをモニタリ ングすることができるフルマネージドサービス ● メトリクスと呼ばれる数値化された時系列データを収集し、 システム全体のリソース使用率、パフォーマンス、ステー タス等を可視化することが可能

14 CloudWatchの概要 AWS サービス別資料: Amazon CloudWatch(2019/03/26) https://d1.awsstatic.com/webinars/jp/pdf/services/20190326_AWS-BlackBelt_CloudWatch.pdf

15 監視するメトリクスの選び方

16 EC2の標準メトリクス関連だけでも結構ある CPU 使用率 EC2 ステータスチェック EBS 読み書き操作 CPU クレジット ネットワーク送受信 バイト数 インスタンスストア 読み書き バイト数 インスタンスストア 書き込み操作数 EBS 読み書きバイト数

17 よくある監視アンチパターン ● CPUやメモリ使用量を80%で一律監視 ○ バッチ処理等で夜間にCPU使用率が急上昇するのは正常動作 ○ CPUが100%でもサービス継続に問題ない ● 「*error* || *warn*」等のログ監視 ○ 大量のアラートが出力され狼少年になってしまう ● 通知後の復旧手順がない ○ 通知に対して次に何を実行すべきかの手順が必要

18 監視の重要なポイント ● 顧客視点でクレームにつながる障害 ○ サービス停止に伴うアクセス不可 ○ レスポンスの低下

19 シンプルなWebシステムの構成を例に 考えてみる

20 シンプルなWebシステムの構成

21 監視対象のメトリクスを決める方針 以下のメトリクスをCloudWatchアラームで監視する ● サービスの可用性やパフォーマンスに直接的な影響のあ るメトリクス ● リソースが枯渇した場合にサービス停止に直結するメトリ クス

22 ELB(ALB) ● TargetResponseTime ○ リクエストがロードバランサーから送信され、ターゲット(EC2)か らの応答を受信するまでの経過時間 (秒) ○ Webサイトやアプリケーションの応答遅延に直結 ● UnHealthyHostCount ○ ロードバランサーに登録された異常なターゲット(EC2)の数 ○ EC2のWebサーバソフトや応答遅延等が原因で、ロードバラン サーからのヘルスチェックが失敗することで発生する

23 ELB(ALB) ● HTTPCode_ELB_5XX_Count、HTTPCode_Target_5XX_Count ○ ロードバランサーやターゲット(EC2)のHTTP 5XX サーバーエ ラーコードの数 ○ EC2のWebサーバソフトや応答遅延等や、AWS基盤障害で発 生

24 ELB(ALB) https://dev.classmethod.jp/articles/elb-trouble-shooting/ https://dev.classmethod.jp/articles/what-is-elb-5xx-count/

25 EC2 ● StatusCheckFailed_Instance ○ 1 分間にEC2インスタンスがインスタンスステータスチェックに失 敗した場合に1 (失敗) となる ○ EC2内のソフトウェア、ネットワーク起因によるEC2自体の障害 を検知可能 ○ CloudWatchアラームのアクションからEC2の再起動を実行する ことで、OSが再起動されるため一時的原因の場合は回復が見 込める。

26 EC2 ● StatusCheckFailed_System ○ 1 分間にインスタンスがシステムステータスチェックに失敗した 場合に1 (失敗) となる ○ 物理ホストの電源障害やネットワーク接続喪失など、AWSの基 盤の問題によるダウンを検知可能 ○ Auto Recoveryと呼ばれる、CloudWatchのアクションからEC2の 復旧を実行することで、EC2インスタンスを新しいホストへ置き 換えられる ■ 2022/3/30のアップデートで、EC2インスタンスのAuto Recoveryはデ フォルトで有効 ■ https://dev.classmethod.jp/articles/amazon-ec2-now-performs-auto matic-recovery-of-instances-by-default/

27 EC2 ● メモリやディスク使用率のカスタムメトリクス ○ メモリやディスク不足を検知可能 ○ EC2内のプロセス停止やファイル作成・更新不可等を防ぐこと が可能 ○ EC2のメモリや、EBSのディスク使用率は標準メトリクスにないた め、CloudWatch Agentを導入し追加取得が必要 ■ https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitorin g/create-cloudwatch-agent-configuration-file-wizard.html#cloudwatc h-agent-preset-metrics

28 RDS ● FreeStorageSpace ○ RDSの使用可能なストレージ容量 ○ ストレージの枯渇により、DBインスタンスの停止を防ぐことが可 能 ○ ストレージの自動スケーリング機能はあるが、以下の制約があ るため、急激かつ継続的にストレージの使用量が増加する場 合に監視が必要 ■ 最後のストレージ変更から 6 時間以上経過しないと、スケーリングで きない

29 まとめ ● まずはCloudWatchアラームのシンプルな監視からやって みる ● WebページやAPIエンドポイントの外形監視(URL監視等)が 必要であれば、CloudWatch Syntheticsの導入検討 ○ https://dev.classmethod.jp/articles/amazon-cloudwatch-synthe tics/ ● CloudWatchの運用知見が溜まり、追加の要望が見えてき たら他のクラウド監視サービスも検討してみる

30 この動画は… 想定聴講者 ● シンプルなWebシステム(ELB+EC2+RDS)を構築予定 ● 監視をどこから手をつけていいかわからない ゴール ● スモールスタートな監視の導入方法がわかる ● 監視すべきポイントが理解できる


31 参考資料 ● モダンな監視を今こそ実装する について登壇しましたの で資料を公開します #cmregrowth ○ https://dev.classmethod.jp/articles/20210205-regrowth-infra-o bservability/ ● システム監視、何からはじめる？ ○ https://speakerdeck.com/takumanakagame/what-is-the-first-st ep-for-system-monitoring

No content