[クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す！〜]

2017年7月24日(月)清野 剛史（クラスメソッドAWS事業部ソリューションアーキテクト）

リスト

　システムに障害が起きた際、皆さんの会社では、どのような通知がなされているだろうか。例えば、公開しているWebサイトが「500エラー」を出している、バッチシステムが構築されているサーバーが落ちた、といったケースである。現実には「誰か障害に気付いた人がシステム管理者にメールや電話で知らせる」という企業も少なくない。せっかくの休日に「サイトが落ちている」という緊急電話をもらって自宅でPCを立ち上げたという経験がある方も多いのではないだろうか。

障害の検知／認知は早ければ早いほど復旧も早い

　こうした障害時の通知を自動で行うのが「通知システム」である。通知を自動化するメリットは、まず障害が起きた瞬間に通知を受けられる点だ。障害の検知／認知が早ければ早いほど復旧作業が早くなり、エンドユーザーへの影響が少なくなる。

　もう１つは、通知の方法を色々選べることである。メールや電話は受ける側の作業が必要になる。だが、もし単純な一次対応、例えばサーバーを再起動すれば直るような障害であれば、通知を別のサーバーに送り、そのサーバーに対象のサーバーを再起動させるようプログラムを組んでおけば、管理者は休日をゆっくりと楽しめる。

　さらに、エンドユーザーでは気付かないような小さな異常の通知を受けられるようになる。例えば、メモリーの使用量が通常より多い、ハードディスクがもうすぐ一杯になるといったことだ。このような通知に対し、スケーリングなどの安全策を事前に取る、不具合のありそうなサーバーのみを取り外し問題のないサーバーと入れ替えるなど、影響が顕在化する前に手を打つことが可能になる。

　保守・運用は、直接利益を生み出すような作業ではないが、それを怠ると、いざ問題が起こった時の損失が大きい。システムにおける“ディフェンス（防御）”は、24時間365日、確実な検知と対応作業が行える機械に任せ、エンジニアは、より利益を生み出しやすい“オフェンス（攻撃）”に注力できるようにしたい。以下では、段階を踏みながら、様々な通知システムの構築を紹介していく。

「Cloudwatch」「Cloudwatch Logs」に
基本的な通知は一任する

　通知を自動化するためには、様々なスペックを監視する必要がある。AWS（Amazon Web Services）においては、基本的なメトリクスの監視システムは「CloudWatch」に一本化されている。ここにデフォルトのスペックの他、カスタムな数値に関しても集めてしまうのが効率的である。Cloudwatchは15カ月分（2017年7月時点）のデータを保持できるので、通常の監視・通知システムを組むには充分に使える。是非とも活用しよう。

　サーバーの基本的なスペックデータ、例えばCPU数値やディスク容量、ネットワーク帯域の使用量などは特段の設定なしで、そのまま確認できる。そこに「アラート」と呼ばれるトリガーを仕込むと「一定のしきい値を何分間に何回超えたら、どのような手段で通知を出す」という細かい通知システムをGUI上で簡単に組み込める。

　特にメモリー使用量はCloudWatchのデフォルトメトリクスには入っていないため、カスタムで仕込む必要がある。「yum」や「apt-get」のパッケージにAWSが提供しているスクリプトがあるので、それをそのままインストールし設定すれば済むだけに確実に仕込んでおこう（関連リンク：AWSドキュメント）。

図1：各種スペックやログを「CloudWatch」に一本化する
拡大画像表示

　その他の監視項目、例えばログなどは「Cloudwatch Logs」に入れておこう。CloudWatch Logsにはフィルタ機能があり、特定の文字列に対してトリガーを反応させることができる。例えば「ERROR:」や「CAUTION:」など、クリティカルなエラーにつながりそうな文言をフィルタリングしアラートを設定しておけば、CPUやリクエスト数のような、しきい値と同じような手順で通知処理を組める（図1）。

●Next：Cloudwatchの最大の弱点、「Kinesis Analytics」の活用