JAWS-UG 初心者支部 #31 監視編サーバーのモニタリングの基本を学ぼう

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark.
アマゾンウェブサービスジャパン株式会社
Solution Architect
内田大樹 / Hiroki Uchida
＠nikuyoshi
JAWS-UG 初心者支部 #31 監視編
サーバーのモニタリングの基本を学ぼう
#jawsug_bgnr
資料: SlideShareのURL
資材: https://bit.ly/2TeM2wT

自己紹介
内田大樹 (うちだひろき)
インダストリソリューション部
ソリューションアーキテクト
前職までの経験
通信会社でアプリケーション開発、監視、インフラ構
築する部署に所属。
好きなAWSのサービス
AWS Command Line Interface
AWS CDK
@nikuyoshi
2

本ハンズオンの狙い
• 110 分でAWSにおけるサーバーの監視
方法をクイックに学んでいただく
• 説明よりも体験を重視
• Next Action に繋げていただきたい
ラーニングピラミッド
👉
講義
読書
視聴覚
デモ
グループ討論
自ら体験する
他の人に教える
3

本コースのゴール/前提条件、前提知識
• 本コースのゴール
• クラウドにおける監視の考え方を理解する
• Amazon Elastic Computing Cloud(EC2)、Elastic Load Balancing(ELB)、Amazon
Relational Database Service(RDS)を利用したWebシステムの監視方法を学ぶこと
• 本コースの前提条件、前提知識
• AWS アカウントをお持ちであること
• ハンズオンの作業が同一AWSアカウントの他のリソースに影響が出る場合がある
• ハンズオン用にAWSアカウントを取得していただくことを推奨する
• 以下のAWS サービスの基礎知識を持っていること。必須ではない。
• Amazon Virtual Private Cloud (VPC)
• Amazon EC2
• Amazon RDS
4

本日のアジェンダ
1. 事前準備と関連サービス紹介
2. Amazon CloudWatchのハンズオン ①EC2、ALB、RDSのメトリクス確認
3. Amazon CloudWatchのハンズオン ②EC2のディスク使用率90%以上時のアラー
ト発報
4. Amazon CloudWatchのハンズオン ③WordPressのアクセスログ、エラーログ確
認
5. 本コースのまとめ、リソース削除
5

3. Amazon CloudWatchのハンズオン ②EC2のディスク使用率90%以上時のアラー
ト発報
4. Amazon CloudWatchのハンズオン ③WordPressのアクセスログ、エラーログ確
認
6

事前準備と関連サービス紹介

資材のダウンロード
以下のURLから資材と手順書をダウンロードしてください。
資材: https://bit.ly/2TeM2wT
手順書: SlideShareのURL
8

事前準備 #1
画面右上のリージョンを
選択し、東京リージョンに
なっていることを確認
↓
サービス検索窓に
CloudFormationと入力し、
管理画面に移動
9

事前準備 #2
スタックの作成ボタンをクリック
10

事前準備 #3
以下の通りに選択し、ダウンロードした資材の monitoring-1.yaml をアップ
ロード後、次へボタンをクリック
11

事前準備 #4
スタックの名前に monitoring-1 を入力し、他の項目はデフォルト値のまま
次へボタンをクリック。次の画面も変更することなく、次へボタンをクリック
12

事前準備 #5
以下のチェックボックスにチェックを入れて、スタックの作成ボタンをクリック
13

事前準備 #6
スタックの作成の完了を待つ間、後続の手順を読んでおいてください。
10分程度かかります。
14

CloudFormation実行時の注意点
• AWS Hands-on for Beginners スケーラブルウェブサイト構築編※１で作成
した構成と異なる。 CloudWatch Agentがインストールされている構成に
なっているため、別物だと思ってCloudFormationを必ず実行すること
• デフォルトでは1つのリージョンで作成できるVPCは5個までとなっているた
め、既に5個作られている場合は既存のVPCを削除するか、別リージョンで
実行すること
• 同一のスタック名(例: monitoring-1)がCloudFormationで実行されていな
いこと。既に実行されていた場合、そのスタックを消すか、別名称のスタッ
クで作成すること
• 新規のAWSアカウントでない場合、デフォルトVPCが存在せず失敗すること
があるため、デフォルトVPCを作成すること
※１実施していなければ無視して問題ありません。
15

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark.© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark.
作業が終わりましたら説明に移ります
講師の画面を見てください

Amazon VPC (Virtual Private Cloud)
• VPCでクラウド内にプライベートネットワークを構築
• 既存データセンターの延長としてAWSを利用
VPC
AWS Cloud
オンプレミス
VPN
Connection
ユーザ（社内）
プライベート
サブネット
Direct
Connect
パブリック
サブネット
インターネット
分離したネットワーク領域を作成
17

Amazon EC2 (Elastic Compute Cloud)
• 数分で起動、1秒ごとの従量課金で利用可能な仮想サーバ
• 独自のHW/Hypervisorにより最適化された性能を提供
• 多数のOSをサポート、ライセンス費用込みで従量課金
• 自由にソフトウェアのインストールが可能
Nitro hypervisor
Network Storage Nitro Security Chip
EC2インスタンス
Server
Nitro
System
ミドルウェア
アプリケーション
OS
リクエストしてから数分で、
ここまで準備される
電源、ラック等
ハイパーバイザー
ネットワーク
仮想マシン
アプリ、ミドルウェア、
監視ツール等を自由に導入可能
18

Elastic Load Balancing (ELB)
オンプレミスの「L4/L7ロードバランサ」に相当
VPC
AWS Cloud
Availability Zone 1 Availability Zone 2
Elastic Load
Balancing
EC2 EC2
myELBxxx.elb.amazonaws.com
• 複数EC2インスタンスに負荷分散
• 高い耐障害性を実現
• ELBの性能増減は自動的に実施
• 複数アベイラビリティゾーンに
跨った負荷分散
ALB(Application Load Balancer) レイヤー7
NLB(Network Load Balancer) レイヤー4
数百万リクエスト/秒
19

Amazon RDS (Relational Database Service)
• フルマネージドなリレーショナルデータベースサービス
• MySQL、Oracle、 SQL Server、 PostgreSQL、MariaDB、Auroraを選択可
能
• バックアップやフェイルオーバー、パッチ適用の自動化、さらには以下の構
成に対応したDBを数クリックで利用可能
スケールアップマルチAZ構成リードレプリカ
AZ1 AZ2
耐障害性向上読み込みの負荷分散処理能力向上
20

AWS CloudFormation
• シンプルなテキストファイル（テンプレート）を使用して、リージョンとアカウントで
アプリケーションに必要とされるAWSリソースをプロビジョニングできるサービス
• プロビジョニングされたAWSリソースに対する変更/削除も可能で、ソフトウェアに対
して行うのと同じ方法でAWSインフラを管理できる
• 追加料金なし（プロビジョニングされたAWSリソース分の料金のみ発生）
作成/変更/削除
作成するリソースの定義リソースの集合
リソースの
作成/変更/削除
Template
CloudFormation
Stack
Amazon RDS
VPC
Amazon EC2
21

Amazon CloudWatch の概要
CloudWatch はモニタリングに関する様々な機能を提供
CloudWatch Alarms
CloudWatch Events
CloudWatch Metrics
CloudWatch Logs
CloudWatch Logs Insights
AWSサービス
お客様システム
CloudWatch Dashboardstime-baseevent-base
メトリクスを送信
ログを送信
メトリクスに応じた
アクションの実行
ログの可視化
イベントに応じた
ターゲットによる処理
22

CloudFormationでデプロイする
プライベートサブネット-1c
10.0.3.0/24
パブリックサブネット-1a
10.0.0.0/24
プライベートサブネット-1a
10.0.2.0/24
パブリックサブネット-1c
10.0.1.0/24
ゲートウェイ
VPC: 10.0.0.0/16
RDS
(Master)
ELB
EC2
ユーザー
RDS
(Slave)
Word
Press
アベイラビリティーゾーン 1c
アベイラビリティーゾーン 1a
EC2
Word
Press
CloudWatch Metrics CloudWatch Logs
VPC、EC2、RDS、ELBをま
とめてCloudFormationでデ
プロイします
23

事前準備 #7
以下のように、CloudFormationの管理画面にてステータスが CREATE_COMPLETE になってい
れば準備完了です。
24

事前準備 #8
CloudFormationの管理コンソール > monitoring-1 > 出力タブから、EC2の
DNS名をコピーし、WordPressサーバーにアクセスします。EC2WebServer01、
EC2WebServer02の2つを設定していきます。
25

事前準備 #9
作成した RDS の DB 設定に基づき、WordPressのデータベース設定を行います
※ダウンロードした資材の中にもテキストファイル
( wordpress-settings.md ) があるためご活用ください
データベース名: wordpress
ユーザー名: dbmaster
パスワード: H&ppyHands0n
データベースのホスト名: RDSのエン
ドポイント
テーブル接頭辞: wp_
26

事前準備 #10
サイトのタイトル: Monitoring #1
ユーザー名: admin
パスワード: 出力された文字列をコ
ピーしておいてください
メールアドレス:
username@example.com (実際には
送信されません)
検索エンジンでの表示: チェックを入
れる
※ダウンロードした資材の中にもテキストファイル
( wordpress-settings.md ) があるためご活用ください 27

3. Amazon CloudWatchのハンズオン ②EC2のディスク使用率90%以上時の
アラート発報
4. Amazon CloudWatchのハンズオン ③WordPressのアクセスログ、
エラーログ確認
29

メトリクス監視が何故必要か
よくある問題
• サーバーが過負荷で応答できない
• サービスが使えない
• 良い顧客体験を提供できない
測定すべき項目
• リソース監視 (例: CPU使用率、メモリ使用率)
• アプリケーション性能管理 (例: アプリケーションの処理時間)
30

CloudWatch Metrics
CloudWatch に発行されたメトリクスを収集し、統計を取得
CloudWatch Alarms
CloudWatch Events
CloudWatch Metrics
CloudWatch Logs
AWSサービス
ログを送信
ログの可視化
31

CloudWatch Metrics
メトリクス
• CloudWatchに発行された時系列のデータポイントのセット
• メトリクス名を持つ
• データポイントはタイムプスタンプと測定単位を保持
• メトリクスは作成されたリージョンにのみ存在
名前空間
• CloudWatchメトリクスのコンテナ
• 異なる名前空間のメトリクスは相互に切り離される
• AWSサービスでは AWS/<service>が使用される(例: AWS/EC2)
ディメンション
• メトリクスを一意に識別する名前/値のペア(例：InstanceId=i-12345678)
32

CloudWatch の利用イメージ
名前空間
33

CloudWatch の利用イメージ
ディメンション標準メトリクス
統計、期間
ディメンション、メトリクス、統計、期間を選択して任意のグラフを表示
34

EC2のメトリクス収集
標準メトリクス(EC2) カスタムメトリクス
標準メトリクスでは
収集できないメトリクス
• CPUUtilization
• CPUCreditBalance
• CPUCreditUsage
• CPUSurplusCreditBalance
• CPUSurplusCreditsCharged
• DiskReadBytes ・DiskReadOps
• DiskWriteBytes ・DiskWriteOps
• NetworkOut ・NetworkPacketsOut
• NetworkIn ・NetworkPacketsIn
• StatusCheckFailed_Instance
• StatusCheckFailed
• StatusCheckFailed_System Amazon EC2
35

①EC2、ALB、RDSのメトリクス確認 #1
画面左上のサービスを選択し、CloudWatchと入力後、CloudWatchの管理画
面に移動してください。
36

左側のメニューのメトリクスをクリックすると、以下の画面が表示されます
37

EC2 → インスタンス別メトリクスをクリックしてください。
38

各種メトリクスが表示されております。検索ボックスにCPUを入力すると、CPU
関連のメトリクスに絞って表示できます。
39

チェックボックスを入れると、各種メトリクスをグラフで確認できます。
現在表示しているCPUUtilization（CPU使用率）です。
グラフにマウスオーバーすると、実際の値も表示できます。
40

日時が現地時刻とずれている可能性があるため、必要に応じてグラフの設定を変
えてください。
41

CPUUtilizationのチェックを外した後、ネットワークのメトリクスを確認するた
め、NetworkIn、NetworkOutのメトリクスにチェックを入れてください。
42

NetworkIn、NetworkOutのチェックを外した後、（検索ボックスのnetworkの
チェックも外す）パンくずリストのすべてを選択してください
43

ApplicationELBを選択します。その後、EC2同様表示される項目の中でも気にな
るメトリクスにチェックを入れて、グラフがどのように表示されるか確認してみ
てください。
44

続いて、RDSのメトリクスを確認していきます。RDSをクリック後、
データベース別メトリクスをクリックします。
45

WriteIOPS、ReadIOPSのチェックを入れます。
46

グラフ化したメトリクスのタブに切り替え、WriteIOPS、ReadIOPSの期間を5
分から1分に切り替えます（切り替え後のグラフは次スライド参照）
47

切り替えると以下の図のようなグラフに切り替わります。RDSはデフォルトで1
分間隔でメトリクスが取得されています。（EC2、ALBは5分間隔）
1分間隔の平均グラフの方が、
グラフがならされず、数値の
詳細が分かる
48

本セクションのまとめ
• メトリクス監視が何故必要か
• Amazon CloudWatch Metricsの概要
• EC2、ALB、RDSのメトリクス確認
49

アラート発報
5. Amazon CloudWatchのハンズオン ④WordPressのアクセスログの分析
51

アラートが何故必要か
システムやシステムのコンポーネントの振る舞いに変化が起きた際にビジネスへ
の影響を無くすため。
例: ディスク使用量が50%増加した際にアラートをあげる
すぐに対応すべきアラートがあれば、SMSや電話を利用して通知し、人手で対応
することもある。理想としては、自動復旧できる仕組みがあると望ましい。
52

CloudWatch Alarms
CloudWatch メトリクスを監視するアラームと関連サービスのアクション
CloudWatch Alarms
CloudWatch Events
CloudWatch Metrics
CloudWatch Logs
AWSサービス
ログを送信
ログの可視化
53

CloudWatch Alarms
• CloudWatch Metricsをモニタリングしてアラームを発行可能
• 条件を指定して、自動アクションを実行が可能
• 例えば、CPU利用率が80%を超えた時にアラートメールを通知等
• アラームの状態はOK, ALARM, INSUFFICIENT_DATAの３種類
OK ALARM INSUFFICIENT_DATA
正常値
✓ 定義された閾値を下
回っている
異常値
✓ 定義された閾値を上
回っている
判定不能
✓ データ不足のため状態
を判定できない
✓ CloudWatch特有
• データポイントとはCloudWatchに送信される値(CPU値など)
• OK / アラーム時は入力されたデータポイントを基準に状態評価
• INSUFFIENT_DATA時はCloudWatchにテータポイントの入力が十分に無い状態
→ “INSUFFICIENT_DATA”は必ずしも障害を表すステータスではない
54

CloudWatchアラームの設定 CPU使用率80%以上が5分以上続いた場
合にアラートが発報される
55

CloudWatch Alarmsのアクション機能
メトリクス
CPUUtilization
DiskReadBytes / DiskReadOps
DiskWriteBytes / DiskWriteOps
NetworkIn / NetworkOut
StatusCheckFailed_Instance
StatusCheckFailed_System
Custom Metric
Memory Free / Filesystem Free
アクション
Amazon EC2 Amazon CloudWatch Amazon EC2
Amazon Simple
Notification Service
Amazon EC2 Auto Scaling
Alarm
56

ユースケース：アクションの設定例
• SNS トピックを追加して、アラー
ムの状態が変わったときにトピッ
クを発行
• サブスクライブにEメールを選択
して、指定アドレスにメール通知
• サブスクライブにLambda 関数を
選択して、処理を実行
Amazon Simple
Notification Service
例：GetMetricWidgetImage APIによるグラフ送付
1. CloudWatch MetricsにEC2からメトリクスを送付
2. 指定したしきい値を超えた時にSNS のアクション
を実行
3. SNS をトリガーにAWS Lambdaを実行
4. GetMetricWidgetImage APIを利用して
CloudWatch Metricsのグラフを取得する
5. 取得したグラフの画像ファイルを添付してEmailを
送信/運用システムに連携
EC2 SNSCloudWatch
Alarm
CloudWatch
57

②EC2のディスク使用率90%以上時のアラート発報 #1
左側のメニューからアラートをクリックします
58

アラームの作成をクリック後、メトリクスの選択をクリックします
59

CWAgent > ImageId.InstanceId.InstanceType.device.fstype…
を選択します。
60

monitoring-1-Web インスタンスの disk_used_percent を選択し、
その後画面右下のメトリクスの選択をクリックします
61
device: xvda1
fstype: xfs
path: /

選択すると、以下のような画面が表示されます。
62

期間を 15分間隔に変更します
63

条件を以下のとおりに変更し、(ディスク使用率 90％以下)
次へのボタンをクリックします
64
本来であれば、90% 以上と
設定しますが、アラートを
必ず発生させるために
あえて設定しています

以下の画像のとおりの設定を行い、メールアドレスにはご自身が使っているアド
レスを入力して、トピックの作成ボタンをクリックします
トピックができあがると、
指定したメールアドレス
宛にメールが飛びます
65
トピック名は
monitoring-1-topic
で設定してください。
変更する場合は忘れないように
メモを取っておいてください

メールのサンプル
メール通知を受け取るために、Confirm
subscription をクリックします
66
上記URLをクリックするとこのような
画面が表示されます

次へボタンをクリックします
（興味のある人はAuto Scalingアクション、EC2アクションの追加ボタンを
クリックして、どんな設定ができるか見てみましょう！）
67

monitoring-1-alarm を入力し、次へボタンをクリックします
68

各設定値を確認し、アラームの作成ボタンをクリックします
69

アラーム作成直後はデータ不足と表示されますが、時間が経つと解消されます。
実際にアラートを発報させたい場合は、ディスク使用率が90%以上にすると
メールが送信されます。
70

• アラートが何故必要か
• Amazon CloudWatch Alarmsの概要
• EC2のディスク使用率90%以上時のアラート発報の設定
71

アラート発報
73

ログの集約が何故必要か
よくある問題
• サーバーが増加した際に、各サーバーにログインしてログを確認する必要が
あり、運用が辛い
• 障害やディスク容量不足でサーバーにログインできず、ログを確認できない
ログの集約することで、運用の手間をなくし、問題を分析しやすくなる
CloudWatch Logs
… …
74

CloudWatch Logs とは
• AWSサービスおよび顧客システムのログの監視、保存、アクセスを提供
• エージェント経由でログメッセージをCloudWatchエンドポイントに転送
• ログデータの保存期間を設定可能(1日~永久保存で選択可能)
• Amazon S3へのログのエクスポートが可能
CloudWatch Logs
サブスクリプション
フィルタ
メトリクスフィルタ
AWS Lambda
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWSサービス
S3へのログの送信
75

CloudWatch Logsのディレクトリ階層
Web Server
web001.ap-northeast-1
ロググループログストリームログイベント
ログイベント
• 1つのログエントリ
• モニタリングしているリ
ソースによって記録された
アクティビティのレコード
• イベント発生時のタイムス
タンプおよび生のイベント
メッセージで構成
ログストリーム
• 複数のログイベントで構成
• モニタリングしているリソースの
タイムスタンプ順でイベントを表
す
ロググループ
• 複数のログストリームで構成
• 保持、監視、アクセス制御につい
て同じ設定を共有するログスト
リームのグループを定義
76

ログイベントのイメージ
ログ内容はタイムスタンプとログメッセージ（UTF-8）で構成
77

③WordPressのアクセスログ、エラーログ確認 #1
左側のメニューから、ロググループをクリックします
78

今回構築したEC2インスタンス上に存在するWordPressのログを確認していきま
す。まず、wordpress_access_log をクリックします
ログの有効期限も設定できます
79

一番上のログストリームを選択してください。
80

すると、以下のようなWordPressのアクセスログが表示されます。
81

GETメソッドに関連するアクセスログを表示する場合は、検索バーに GET の
ような文字列を入力して検索できます。
検索期間の絞り込みも可能です
82

表示されている時刻がずれていることもあるため、必要に応じてタイムゾーンを
変更してください
83

アクセスログを確認できたため、次はエラーログを確認します。パンくずリスト
から、 Log groups をクリックします
84

wordpress_error_log をクリックし、任意のログストリームを選択します。
ログの有効期限も設定できます
85

アクセスログ同様、以下のような画面が表示されます。
86

（補足情報）CloudWatch Agent の設定ファイル
アクセスログ、エラーログは以下のようなCloudWatch Agentの設定を
入れることで実現可能です。ダウンロードした資材の中の
amazon-cloud-watch-agent.json が該当しているファイルです。
アクセスログの設定
エラーログの設定
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html
87

• ログの集約が何故必要か
• Amazon CloudWatch Logsの概要
• WordPressのアクセスログ、エラーログ確認
89

（オプション）ハンズオンを完走した方向け情報
以下のURLから、動画を見ながら是非続きをやってみてください！
https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-monitoring-2020-reg-event-LP.html
90

アラート発報
91

各リソースの削除 (1/2)
CloudFormationの画面からmonitoring-1を削除してください。
今回作られたCloudWatch関連リソースに関しても必要に応じて削除をお願いします。
※CloudWatchメトリクスに関しては削除できない仕様ですが、EC2、RDSといった各リソースが削除されればメト
リクスが出力されなくなります。
92

各リソースの削除 (2/2)
削除するリソース一覧
サービスリソース
CloudFormation スタック (monitoring-1)
CloudWatch アラーム (monitoring-1-alarm)
ロググループ (wordpress_access_log,
wordpress_error_log)
93

参考資料
AWS Black Belt Online Seminar - Amazon CloudWatch
https://www.slideshare.net/AmazonWebServicesJapan/20190326-aws-black-belt-online-
seminar-amazon-cloudwatch
Amazon CloudWatch ドキュメント
https://docs.aws.amazon.com/cloudwatch/index.html
CloudWatch Logs - ウィザードを使用して CloudWatch エージェント設定ファイルを作成する
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-
file-wizard.html
95

本ハンズオンの狙い
• 110 分でAWSにおけるサーバーの監視
方法をクイックに学んでいただく
• 説明よりも体験を重視
• Next Action に繋げていただきたい
ラーニングピラミッド
👉
講義
読書
視聴覚
デモ
グループ討論
自ら体験する
他の人に教える
96

Thank you!

JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう

More Related Content

What's hot

Similar to JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう