Things:モノのインターネット)ソリューションの構築について考えた。今回は、そうしたIoTにも活かせるテーマとして「通知システム」を取り上げる。構築したシステムの運用は“もしものとき”には大きな問題になるが、通常は、できるだけ自動化したい業務である。システムに障害が起きた際、皆さんの会社では、どのような通知がなされているだろうか。公開しているWebサイトが「500エラー」を出している、バッチシステムが構築されているサーバーが落ちた、といったケースである。現実には「誰か障害に気付いた人がシステム管理者にメールや電話で知らせる」という企業も少なくない。休日に「サイトが落ちている」という緊急電話をもらって自宅でPCを立ち上げたという経験がある方も多いのではないだろうか。障害の検知/認知は早ければ早いほど復旧も早いこうした障害時の通知を自動で行うのが「通知システム」である。通知を自動化するメリットは、まず障害が起きた瞬間に通知を受けられる点だ。障害の検知/認知が早ければ早いほど復旧作業が早くなり、エンドユーザーへの影響が少なくなる。1つは、通知の方法を色々選べることである。メールや電話は受ける側の作業が必要になる。単純な一次対応、例えばサーバーを再起動すれば直るような障害であれば、通知を別のサーバーに送り、そのサーバーに対象のサーバーを再起動させるようプログラムを組んでおけば、管理者は休日をゆっくりと楽しめる。エンドユーザーでは気付かないような小さな異常の通知を受けられるようになる。メモリーの使用量が通常より多い、ハードディスクがもうすぐ一杯になるといったことだ。このような通知に対し、スケーリングなどの安全策を事前に取る、不具合のありそうなサーバーのみを取り外し問題のないサーバーと入れ替えるなど、影響が顕在化する前に手を打つことが可能になる。保守・運用は、直接利益を生み出すような作業ではないが、それを怠ると、いざ問題が起こった時の損失が大きい。システムにおける“ディフェンス(防御)”は、24時間365日、確実な検知と対応作業が行える機械に任せ、エンジニアは、より利益を生み出しやすい“オフェンス(攻撃)”に注力できるようにしたい。以下では、段階を踏みながら、様々な通知システムの構築を紹介していく。Logs」に基本的な通知は一任する通知を自動化するためには、様々なスペックを監視する必要がある。Services)においては、基本的なメトリクスの監視システムは「CloudWatch」に一本化されている。ここにデフォルトのスペックの他、カスタムな数値に関しても集めてしまうのが効率的である。Cloudwatchは15カ月分(2017年7月時点)のデータを保持できるので、通常の監視・通知システムを組むには充分に使える。サーバーの基本的なスペックデータ、例えばCPU数値やディスク容量、ネットワーク帯域の使用量などは特段の設定なしで、そのまま確認できる。そこに「アラート」と呼ばれるトリガーを仕込むと「一定のしきい値を何分間に何回超えたら、どのような手段で通知を出す」という細かい通知システムをGUI上で簡単に組み込める。メモリー使用量はCloudWatchのデフォルトメトリクスには入っていないため、カスタムで仕込む必要がある。「yum」や「apt-get」のパッケージにAWSが提供しているスクリプトがあるので、それをそのままインストールし設定すれば済むだけに、確実に仕込んでおこう(参考文献)。実証実験でRPAの大幅な業務削減効果を確認。Libraryもご利用いただけます。実証実験でRPAの大幅な業務削減効果を確認。ご所属のお客様でも、ご所属企業(または団体)におけるIT化を推進されるお立場の方にもお読みいただけます。Things:モノのインターネット)ソリューションの構築について考えた。今回は、そうしたIoTにも活かせるテーマとして「通知システム」を取り上げる。構築したシステムの運用は“もしものとき”には大きな問題になるが、通常は、できるだけ自動化したい業務である。