【AWS】ハンズオン「サーバーのモニタリングの基本を学ぼう」（CloudWatch）にチャレンジ！(前編)

See More

目次

はじめに

こんにちは、クラウド事業部の木幡です。

AWS認定 SAA(ソリューションアーキテクト アソシエイト)の取得を目指して、日々勉強中です。
IT歴は2年ほどありますが、AWSはまだまだ初心者です。

SAAの試験勉強をしていると、監視サービスの「Amazon CloudWatch」が頻出トピックの一つであることが分かります。
しかし、テキストで「メトリクス」「アラーム」「ログ」...と覚えるだけでは、ピンと来ていませんでした。

そこで今回は、AWS公式が提供している
「AWS Hands-on for Beginners 監視編 サーバーのモニタリングの基本を学ぼう」に挑戦してみました。

本記事は、私と同じAWS初学者の皆さんに向けて、ハンズオンの体験記（やってみたブログ）として、手順や学び、躓いたポイントを共有するものです

どんなひとに読んで欲しい

• AWS SAAの認定試験を勉強中で、CloudWatchの実践的な理解を深めたい人
  
• AWSを使い始めたけれど、「監視」と言われても何から手をつければいいか分からない人
  
• EC2インスタンスは立てたことがあるけど、CloudWatchのコンソールはあまり触ったことがない人
  
• 公式ハンズオンの動画や資料は見たものの、一人で実践するのが少し不安な人
  

前提

この記事は、AWS公式のハンズオン資料「AWS Hands-on for Beginners 監視編」を基に、私の学習体験をまとめたものです。
ハンズオンでは、以下の図のような一般的なWebシステムの構成を、CloudFormationテンプレートを使って自動で構築します。

構成図

• VPC内にMulti-AZ(1a, 1c)で構成されています。

• ALB(Application Load Balancer)がパブリックサブネットに配置され、トラフィックを2台のEC2インスタンスに振り分けます。

• データベース(RDS)ã‚‚Multi-AZで、プライベートサブネットに配置されています 。

• まさにSAAの試験対策で学ぶ、耐障害性とセキュリティを考慮した基本的な構成です。
  この構成を「監視する」という体験ができるのは、非常に実践的だと感じました。

手順

[事前準備]：CloudFormationとWordPressセットアップ

まずは監視対象のWebサーバー群を構築します。

1.CloudFormationテンプレートの実行

• ハンズオンの資料ページから、資材(monitoring-1.yaml)をダウンロードします。

• AWSマネジメントコンソールで「CloudFormation」サービスを開き、「スタックの作成」→「新しいリソースを使用(標準)」を選択。

• 「テンプレートファイルのアップロード」を選び、ダウンロードしたmonitoring-1.yamlを指定します 。
  

注意点 ：EC2インスタンスクラスt2.microが今では対応していない為、t3.microに書き換える。
RDSのインスタンスクラスも同様にdb.t2.micro→db.t3.microへ

• スタック名は「monitoring-1」としました。

　　注意点: デフォルトのVPC上限（5個）に達している場合はエラーになります。
　　私は大丈夫でしたが、ハマりポイントかもしれません。

CloudFormationのスタック作成画面

• 全てのステップをデフォルトのまま「次へ」進み、最後に「スタックの作成」をクリックします。

• ステータスが CREATE_IN_PROGRESS から CREATE_COMPLETE になるまで10分程度待ちます 。
  

コーヒーでも淹れるかサンバでも踊って一息つきましょう。
私はスクワットしてました。

2.WordPressの初期設定

• スタックが CREATE_COMPLETE になったら、「出力」タブを開きます。

CloudFormationの「出力」タブ

• EC2WebServer01DNS のキーの「値」（DNS名）をコピーし、ブラウザでアクセスします 。

• WordPressのインストール画面が表示されます。「さあ、始めましょう！」をクリック。

WordPressの初期インストール画面

• 次の画面で、データベースの接続情報を入力します。
  この情報はハンズオン資料とCFnの「出力」タブに記載されています。

項目	値
データベース名	wordpress
ユーザー名	dbmaster
パスワード	H&ppyHandsOn
データベースのホスト名	CFn出力の RDSEndpointAddress の値
テーブル接頭辞	wp_ （デフォルト）

CFnの出力からRDSのエンドポイントをコピペする作業、いかにもクラウド構築っぽいですね。

WordPressのDB設定画面

• 「送信」をクリックし、次の画面でサイト情報を入力します 。

  項目	値
  サイトのタイトル	Monitoring #1
  ユーザー名	admin
  パスワード	(生成された強力なパスワードを必ずコピーしてメモ帳などに控えておきます)
  メールアドレス	[email protected]（ダミーでOK）
  検索エンジンでの表示	「検索エンジンがサイトをインデックスしないようにする」にチェックを入れます。

• 「WordPressをインストール」をクリック。
  成功画面が出たら、ログインしてWordPressのダッシュボードが表示されることを確認します。
  

• 同じことををもう一つのEC2インスタンスにも設定。EC2WebServer02DNSから設定すればOK！

[ハンズオン①]：EC2、ALB、RDSのメトリクス確認

1.CloudWatchコンソール操作

• 「メトリクス」→「すべてのメトリクス」を選択します。

2.EC2のメトリクス

• AWS/EC2 → インスタンス別メトリクスをクリック。

CloudWatchメトリクスのディメンション選択画面

• monitoring-1スタックで作成したインスタンス（monitoring-1-ec2-WebServer01など）の CPUUtilization を見つけ、チェックボックスをオンにします 。

CPUUtilizationのグラフが表示された画面

)

• これがEC2のCPU使用率のグラフです。
  

さっきWordPressをインストールしたので、少しスパイクが立っているのが分かりました。
これが「監視」の第一歩ですね。

3.ALBのメトリクス

• AWS/ApplicationELB → ELB 別 をクリック。

• monitoring-1-elb を見つけ、RequestCount にチェックを入れます。

今は自分しかアクセスしていないのでRequestCountは小さいですが、これが急増したり0になったりしたら「何かあった」と気づけます。

4.RDSのメトリクス

• AWS/RDS → DBClusterIdentifier をクリック。

• monitoring-1-rds を見つけ、CPUUtilization にチェックを入れます。

データベースのCPU使用率も監視できるんですね。
アプリケーション（EC2）だけでなく、バックエンド（RDS）も監視することがシステム全体の安定稼働に不可欠、とSAAの勉強で習った通りのことが確認できました。

[このハンズオンでの学び]

AWSの主要サービス(EC2, ALB, RDS)は、デフォルトで多くの「標準メトリクス」をCloudWatchに送信していること。

しかし、EC2の「メモリ使用率」や「ディスク使用率」はこの一覧に見当たらないこと。
これが次のハンズオンへの伏線回収されます。

[ハンズオン②]：EC2のディスク使用率90%以上時のアラート発報

ここが最初の「なるほど！」ポイントでした。

1.アラームの作成

• CloudWatchコンソールで「アラーム」→「すべてのアラーム」→「アラームの作成」をクリック。

• 「メトリクスの選択」をクリック。

先ほどのハンズオン①で、EC2のディスク使用率は「標準メトリクス」(AWS/EC2)に無いことを確認しました。
では、どこにあるのか？ 答えは「前提」で触れたCloudWatch Agentです。

• Agentが収集したメトリクスは、AWS/EC2のようなAWS/で始まる名前空間ではなく、カスタム名前空間（Agentの設定で決めた名前）に保存されます。

• このハンズオンでは、CWAgentというカスタム名前空間が作られていました。

• CWAgent をクリックします。

• InstanceId, path, fstypeなどのディメンションが表示されます。

• path = / (ルートディレクトリ)で、メトリクス名disk_used_percent を探します。

• monitoring-1-ec2-WebServer01 インスタンスの disk_used_percent を選択します。

カスタムメトリクス disk_used_percent を選択している画面

2.アラームの条件設定

• メトリクスがグラフ表示されたら、条件を設定します 。

• しきい値の種類: 「静的」

• 条件: より大きい (>)

• しきい値: 90

アラームのしきい値を90%に設定している画面

3.アクションの設定

• 「次へ」進み、アクションを設定します。

• アラーム状態トリガー: 「アラーム状態」

• 通知の送信先: 「新しいSNSトピックの作成」

• トピック名: monitoring-1-topic

• 通知用Eメールエンドポイント: 自分のEメールアドレスを入力します 。

• 「トピックの作成」をクリック。

重要: この直後、入力したメールアドレスに「AWS Notification - Subscription Confirmation」という件名のメールが届きます。
必ずメール本文の「Confirm subscription」リンクをクリックしてください。
これを忘れると、アラームが発報してもメールが届きません。（私はここで数分ハマりました）

SNSトピックとEメールエンドポイントの設定画面

4.アラーム名と作成

• アラーム名: monitoring-1-alarm

• 「アラームの作成」をクリックして完了です。

• アラーム一覧に monitoring-1-alarm が「データ不足」として表示されます（メトリクスを評価中）。
  しばらくすると「OK」（緑色）に変わります。

[このハンズオンでの学び]

標準メトリクスとカスタムメトリクスの決定的な違いを体感できました。

CloudWatch Agentの役割（ディスクやメモリ情報を収集してCloudWatchに送信する）が明確に理解できました。

Metric → Alarm → Action(SNS) という、CloudWatchアラームの基本的な流れを実際に手を動かして構築できました。
これはSAA試験でも超重要です。

[ハンズオン③]：WordPressのアクセスログ、エラーログ確認

メトリクス（数値データ）の次は、ログ（テキストデータ）の監視です。

1.CloudWatchコンソール操作

• 「ログ」→「ロググループ」を開きます 。

2.monitoring-1 ã‚„ wordpress で検索

• wordpress_access_log と wordpress_error_log という2つのロググループが見つかりました 。

• これも、CloudWatch AgentがEC2インスタンス上の
  /var/log/httpd/access_log などを監視して、CloudWatch Logsに転送してくれているおかげです。

wordpress_access_log ロググループが表示された一覧画面

3.wordpress_access_log をクリック

4.中に2つの「ログストリーム」が表示

• これは、monitoring-1-ec2-WebServer01 と WebServer02 の2台のEC2インスタンスからそれぞれ送られてきているログです。

5.どちらかのログストリームをクリック

アクセスログが時系列で表示されている画面

6.wordpress_error_log も同様に確認

• エラーログが収集されていることを確認しました。

[このハンズオンでの学び]

ログの集中管理の威力を体感しました 。これが100台のサーバーだったらと思うと...ぞっとします。

CloudWatch Logsの「ロググループ」（例：wordpress_access_log）と「ログストリーム」（例：各EC2インスタンス）という階層構造を理解できました。

[ハンズオン④]：WordPressのアクセスログの分析

ログが読めるのは便利ですが、障害調査の際は「大量のログから特定のエラーを探す」作業が必要です。
そこで登場するのが「Logs Insights」です 。

1.CloudWatchコンソール操作

• 「ログ」→「Logs Insights」を開きます。

2.「ロググループの選択」で、wordpress_access_log を選択

3.クエリエディタに、クエリを入力

• ハンズオン資料に記載されているクエリを確認。
  

• これは、Apacheの共通ログ形式をパース（解析）するクエリです。

SQL

parse '* - * [*] "* * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes, referrer, userAgent
| filter statusCode like /(4\d\d)/ 

※ここのクエリは配布資料が間違っています。上記が合っています。

* parse でログの1行を各フィールド（httpVerb,url, statusCodeなど）に分解し、* filter でステータスコードが200番台のものに絞り込み、 * stats でHTTPメソッドとURLごとに集計（count(*)）し、 * sort で件数が多い順に並び替えています。

4.「クエリの実行」をクリック

クエリ結果が棒グラフとテーブルで表示された画面

5.実行結果

• WordPressのどのURLに、どのメソッドで、どれくらいアクセス（400番台）があったかが一覧表示されました。

[このハンズオンでの学び]

CloudWatch Logs Insightsを使えば、テキストのログファイルが、まるでデータベース（SQL）のように検索・集計できることが分かりました 。

filter statusCode like /5\d\d/ のようにクエリを変えれば、サーバーエラー（500番台）だけを即座に抽出できます。
これは障害対応で絶大な威力を発揮しそうです。

ハンズオンの続きは後編へ

おわりに

前編では、CloudFormationでの環境構築から、CloudWatchを使った基本的なメトリクス監視、そしてログの分析（Insights）までを行いました。

「標準メトリクス」と「カスタムメトリクス」の違いや、ログをSQLライクに検索できるInsightsの便利さを体感できました。

後編では、これらを一つの画面にまとめる「ダッシュボード作成」と、サーバー停止を検知する「イベント監視」
そして最後のお片付けについてまとめます。

ぜひ後編もご覧ください！

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp