今回は CloudWatch というか、ヘルスチェック機能(AWSではAlarmと呼ぶらしい)を設定してみます。


・WEBサーバの作成
web01、web02 という名前で、二台のWEBサーバを作成しておく。
中身は以前作ったものと同様。
※もっとも、今回はWEBサーバとしては利用しないので、単なるLinuxインスタンスでOKですが…。


・SNS Topic の作成と、通知先設定

alarm01
AWS Management Console から SNS を選択
⇒ SNS は Simple Notification Service の略




alarm02
SNS Dashboard が表示されるので、中央の Create New Topic をクリック




alarm03
TopicName と DisplayName をテキトーに設定します。
ここでは、server-alarm としておきます。




alarm04
作成した Topic に対して通知先を設定する必要があるので、
MyTopic の server-alarm を選択して、Create New Subscription をクリック。




alarm05
通知先の設定。
ここでは、Protocol を Email とし、Endpoint に自分のメールアドレスを設定します。




alarm07
Topic 設定完了後の画面。
server-alarm の topic に登録(subscription)された email アドレスは、PendingConfirmation (確認/認証待ち)状態になっています。


登録したメールアドレス宛てに no-reply@sns.amazonaes.com から、Subscription の確認メールが届いているはずなので、確認します。

(メール文面は省略)


alarm09
no-reply@sns.amazonaes.com
からのメールに含まれているURLをクリックすると、Confirmation が完了し、上記のようなブラウザ画面が表示されます。



・Alarmの作成
alarm10
EC2 Dashboard から web01 の監視状況を確認します。
自分では特に何も設定していなくても、基本的な監視(だけ)は実施されているようです。
その中から Avg CPU Utilization をクリックしてみます。
※Avg は Average (平均) の略でしょう。



alarm11
Alarm 作成画面が表示されるので、適当な値を入力します。
ここでは、CPU 利用率が 25% 以上になったら Alarm を飛ばすように設定します。
対象topic(= Send a notification to) には、先ほど作成した topic である server-alarm を指定しておきます。




alarm12
Alarm 作成完了画面。特に気になる文面はないですね…。




alarm13
似たような手順で、今度は web01 の Disk Writes 用の Alarm も設定します。




・サーバ負荷をかけてみる
サーバー負荷をかけるためには、負荷をかけるためのプログラムが必要なのですが…。
特にこだわりは無いので、sysbench というソフトを使ってみることにします。

まずはインストール。

  sudo apt-get install sysbench

特に難しいこともなくインストールは完了します。

まずは sysbench で CPU 負荷をかけてみましょう。コマンドは「sysbench --max-requests=9999999 --max-time=300 --test=cpu run」とします。詳細は man sysbench とかして調べてみてください。

上記コマンドを使って、web01 上で CPU 負荷をかけるように実行してみます。
ssh で web01 にログインして実行すると、以下のようになります。

ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=cpu run

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Time limit exceeded, exiting...
Done.

Maximum prime number checked in CPU test: 10000


Test execution summary:
    total time:                          300.0011s
    total number of events:              68805
    total time taken by event execution: 299.5721
    per-request statistics:
         min:                                  1.47ms
         avg:                                  4.35ms
         max:                                157.60ms
         approx.  95 percentile:               1.50ms

Threads fairness:
    events (avg/stddev):           68805.0000/0.00
    execution time (avg/stddev):   299.5721/0.00




alarm15
EC2 Dashboard から、負荷のかかり具合を確認してみます。

グラフだと80% までCPUパワーを消費していますね。

負荷が設定した閾値を超えたので、AWS から Alarm メヘールが届いているハズです。
監視は 5分ごとのデータに依存しているので、すぐにメールが来るかどうかは分かりませんが…。




次は、HDD に負荷をかけてみます。
HDD 負荷をかける場合は、sysbench に対して、「prepare → run → cleanup」という順序で操作するようです。
テンポラリファイルがたくさん作成されるので、サブディレクトリを作成して、その中で実行するのが良いでしょう。
以下の3行のコマンドを実行してください。

  sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  prepare
  sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  run
  sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  cleanup
結果は以下のような感じ。

ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  prepare

sysbench 0.4.12:  multi-threaded system evaluation benchmark

128 files, 16384Kb each, 2048Mb total
Creating files for the test...
ubuntu@ip-10-120-3-7:~$

ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  run

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Extra file open flags: 0
128 files, 16Mb each
2Gb total file size
Block size 16Kb
Number of random requests for random IO: 9999999
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Threads started!
Time limit exceeded, exiting...
Done.

Operations performed:  98880 Read, 65920 Write, 210931 Other = 375731 Total
Read 1.5088Gb  Written 1.0059Gb  Total transferred 2.5146Gb  (8.5832Mb/sec)
  549.33 Requests/sec executed

Test execution summary:
    total time:                          300.0037s
    total number of events:              164800
    total time taken by event execution: 50.8981
    per-request statistics:
         min:                                  0.01ms
         avg:                                  0.31ms
         max:                                207.43ms
         approx.  95 percentile:               0.99ms

Threads fairness:
    events (avg/stddev):           164800.0000/0.00
    execution time (avg/stddev):   50.8981/0.00

ubuntu@ip-10-120-3-7:~$


ubuntu@ip-10-120-3-7:~$ sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  cleanup

sysbench 0.4.12:  multi-threaded system evaluation benchmark

Removing test files...

ubuntu@ip-10-120-3-7:~$


特に問題なく実行できているようです。




alarm16
AWS Management Conosole の EC" Dashboard から結果(HDDの DiskWriteのグラフ)を確認してみます。

あれ……?
負荷ゼロですね...?


.
.
.

嗚呼!!

作成したインスタンスは HDD として EBS を利用しているので、ローカルのHDD(Ephemeral Disk と呼ばれるらしい)は利用していないのですね。
なので、負荷を計測するべき対象は web01 サーバ(EC2)ではなく、そこにアタッチされている EBS になります。


alarm17
EC2にアタッチされている EBS を調べてみましょう。
EC2 インスタンスにアタッチされている EBS の ID を調べるには、上記のようにします。
EC2 インスタンスから見た場合、/dev/sda1 としてマウントされているので、そのデバイスの状態を確認すると、EBS の ID が入手できます。




・EBS に Alarm を設定する
alarm18
AWS Management Console の Cloud Watch から、Metrics をクリックし、先ほどの EBS ID を使って検索します。
ここでは、DiskWriteBytes で Alarm を設定します。




alarm19
名前と閾値をテキトーに設定します。




alarm20
通知先となる SNS Topic を選択します。
ここでは server-alarm を指定します。

この後、「確認画面」と「完了画面」が出ますが、特に困ることもないので省略します。




似たような感じで、EBS の 「TotalWriteTime」「TotalWriteOps」 に対する Alarm も設定しておきます。


↓ CloudWatch から 指定した EBS ID の TotalWriteBytes を検索
alarm29

↓ EBS の TotalWriteBytes に対する Alarm を設定
alarm30

↓ CloudWatch から 指定した EBS ID の TotalWriteOps を検索
alarm37

↓ EBS TotalWriteOps に対する Alarm を設定
alarm38



・再度サーバに負荷をかける

先ほどと同じ手順で HDD に負荷をかけてみます。

sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  prepare
sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  run
sysbench --max-requests=9999999 --max-time=300 --test=fileio --file-test-mode=rndrw  cleanup

状況/負荷のかかり具合にもよりますが、負荷をかけた後、設定した Alarm がメールで通知されているはずです。





alarm42
Alarm の閾値によっては、通知が来ないこともあるようですが...。

CPU 負荷の場合は期待通りに負荷がかかるのですが、EBS の場合 イマヒトツ負荷のかかり具合が不明です。何度か負荷をかけると、Alarm が発生したりしなかったりするので、キャッシュが設定されているように思えます。もっとも、詳細は不明(調べればどこかに記載されている???)。

実際に運用するか、一般的な想定値から閾値を設定してみる必要があると思います…。
(つまり、ここでは閾値の妥当性については分からない…ということです)




・INSUFFICIENT_DATA とは?

alarm44
負荷をかけずにしばらく放置しておくと、EBS の TotalWriteTime に対する Alarm が「INSUFFICIENT_DATA」という状態になります。

これは、いったい何?!
.
.
.

そうか、「書き込むべきデータが無い」状態では「書き込み回数(WriteOps)」はゼロで、
「書き込みに要した時間(write time)」もゼロだから、「0÷0=計算不可」となるのかな…たぶん…。




・後始末
alarm45
Alarm も(数が多いと)課金対象らしいので実験が終わったらサッサと削除しておきます。
Alarm の一覧で、全Alarm をチックして Delete ボタンを押下するだけです。




alarm47
EC2インスタンスとEBSも削除して、課金されないようにしておきます。
EC2 dashboard で、利用中のサービス状態を確認しておいてください。




・TIPS

  1. Alarm のメールには display name が記載される。そのため、display name には「障害の内容」あるいは「受信者に対処して欲しい作業」を記載しておくと良いかも。
  2. Alarm に設定する閾値は、実際に運用して決定する必要がある。EBS は仕組みと計測単位の詳細が良く分からないので、それも調べてみる必要がある。



今回はここまで。


次は AutoScaling を試してみたい。