[レポート]JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう に参加しました #jawsug_bgnr

[レポート]JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう に参加しました #jawsug_bgnr

2020/09/01 に開催されたオンラインイベント「JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう」の参加レポートをかきました。 #jawsug_bgnr 「CloudWatchは難しそう」と思っている方にやってみてほしいハンズオンでした。
Clock Icon2020.09.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。オペレーション部のもっさん@福岡オフィス です。

本記事は、2020/09/01 に開催されたオンラインイベント「JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう」の参加レポートです。
ハンズオンによるメトリクスの確認方法だけでなく、「なぜサーバーのモニタリングが必要なのか」を確認することができる勉強会でした。

イベント概要

イベントの概要ページ(connpass)

今回のハンズオンの主役、CloudWatchの概要ページはこちらです。


ハンズオン

このハンズオンでできるようになること

資料に沿ってハンズオンを実施すると、下記の設定・確認ができるようになります。

  • EC2、ALB、RDSなどのメトリクスの確認方法がわかる
  • メトリクスの状態によってアラート通知を行うよう設定ができる
  • EC2(WordPress)のアクセスログ・エラーログをAWSマネジメントコンソール上で確認できるようになる


資料

また、ハンズオンではCloudFormationを利用して監視対象の環境を構築する手順となっています。
スタックの作成時には、事前にVPCの作成上限数に達していないか、デフォルトVPCが存在するかを確認してください。
参考(運営の方からのアナウンス):【連絡】ハンズオンでCloudFormationを利用する時の注意点|せっきゅん|note

CloudWatchによる監視を活用する利点

ここからは、講義内で解説があった「監視の重要性・利点」について、自分なりに整理した内容です。

なぜ監視が必要なのか(CloudWatch メトリクス)


サーバーの監視が重要である理由は、システム(サービス)を安定して提供できるようにするために不可欠な仕組みであるためです。
サーバー監視では、主に以下のことを見張り・記録しています。

  • サーバーが想定通りの応答をしているか
  • CPUやネットワーク帯域などのリソースは不足していないか

※あくまで一例です。監視するべき項目は、要件によって異なります。

予期せずサーバーが応答できない状態になった場合は、サービスが提供できず、ビジネスの機会損失に繋がることもありえます。
サーバーへのトラブルが発生した際は即座に復旧を行う必要がありますが、監視を行っていない場合は「サーバーに何が起きたのか」が特定できず、対処が困難になることがあります。
また、直接的なトラブルが発生していない場合でも、監視データを基にトラブルを未然に防ぐための対応が可能となります。
例えば、インスタンスのCPU使用率が一定の値を超えた場合、自動でAuto Scalingによるスケールアウトを行うよう設定することができます。この設定を行うことにより、あらかじめ準備していたインスタンスの処理性能を超える要求が見込まれる場合でも、過負荷によるサービスダウンの可能性を低く抑えることが可能です。
AWSでは、各リソースから送信されたメトリクスをCloudWatchに集約することで、手軽に監視を行うことができます。


アラートを通知させる利点

CloudWatch アラームを利用して、メトリクスが一定期間特定の状態を記録した際に、通知を行うよう設定することができます。
通知を設定することにより、システム(サービス)の振る舞いに変化が起こった際、いち早く対処を行うことができ、ビジネスへの影響を抑えることができます。


また、CloudWatch アラームの発行に連動してメール送信やリソースのスケーリング動作をさせる設定をすることも可能です。


ログを集約する利点

障害原因の特定や、コンピューティングリソースが需要とつりあっているかを判断するためには、ログを収集・確認することが有効です。
ログはシステムの状態や動作・エラーなどを記録しています。アプリケーションを動作させているサーバーそれぞれにログを蓄積することもありますが、CloudWatch Logsに集約することも可能です。


「ログの集約」は、リソースを自由にスケールできるクラウドインフラにとっては重要な考え方です。
例えば、各アプリケーションサーバーそのものが自分のログを保持していた場合、自動でサーバーがスケールインされた際はログも削除されてしまいます。
別の場所にログを集約していれば、自動スケールによるログデータ消失の心配もありません。また、なんらかの障害が発生し、サーバ自体にアクセス不能となった場合もログの確認が可能となります。
CloudWatch Logsを利用すればシステムのログを集約・保存することができます。


まとめ

CloudWatchなどの監視サービスは、最初の設定こそ少し大変ではあります。
しかし、ここでしっかりと監視するべきメトリクスを認識し、設定を行うことで、これからサービスを運用していく自分の業務負担を軽減することが可能です。
私はオペレーション部でAWSの運用サポートの対応を行っていますが、AWS側の障害が疑われる際に確認するのはまずメトリクスです。
このハンズオンで、メトリクスをうまく活用する方法を知ることができました。グラフの表示レンジの設定などは、今後の業務効率化にも活かせそうです。

このハンズオンを完走してしまった!もっとCloudWatchの活用方法が知りたい!という方は、以下のハンズオン動画が続編として案内されていましたので、チャレンジしてみてください。
AWS Hands-on for Beginners - 監視編 サーバーのモニタリングの基本を学ぼう | AWS 私も近日中に、こちらのレポートも書いてみたいです!
この記事を読んで、CloudWatchメトリクスの活用方法にワクワクする方が1人でも増えますように!
以上、もっさんがお送りしました!

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.