スケーラブルWebシステム工房 第6回
見逃さない通知の極意

この文書は2008/2/23に書かれたもので、ソフトウエアの名称、バージョン、設定項目、社名などの固有名詞などなどは当時のまま掲載しています。

ですので、インストール手順や設定内容は最新版のドキュメントを参照していただき、この文書からは理論や考え方、構成のヒントなどを読み取っていただければと思います。

今回は監視にまつわるお話です。

監視の意義は異常を検知することにあるので、サービスを正常な状態に保ち続ける上で監視は必要不可欠な要素である、といいきってもいいと思っています。

さてその監視機構については、Nagios(注1)を筆頭にすぐれたソフトウェアが数多く存在しますし、使い方やノウハウの情報も豊富にあります。そこで、今回はちょっと変わったところを攻めて、監視そのものではなく、その通知方法にスポットをあててみたいと思います。

障害発生時の初動を早めるという点で、サービス監視の重要性はここで改めて説く必要はないと思います。さらにわたしは、異常を検知した後の通知という行為も負けず劣らず重要だと考えています。

なぜか？

せっかく、異常を検知して通知を行っても、関係者がその通知に気がつかなければ意味がないからです。

「そんなのあたりまえじゃないか」とか「いつでも気がつくように携帯電話にメールを送ればいい」とか思う方がいるかもしれません。確かに、携帯電話ならば一日中持ち歩くことができるので、よい選択肢だと思いますし、実際わたしも通知に使っています。

でも、わたしたちは一日中、携帯電話をにぎりしめて生活しているわけではありません。特に、平日はPCのモニタを見ていることが多いので、モニタ上に通知を表示した方が目に入りやすいでしょう。

ここまでをまとめるとこうなります。

通知方法あれこれ

というわけで、通知方法をいくつか考えてみます。

以降では、いまあげたそれぞれの手法について掘り下げてみます。

最初に紹介する通知方法は、携帯電話へのメール送信です。

これがいちばん効果が高く導入も楽な通知方法といえるでしょう。なぜなら、携帯電話はほとんどの人が持ち歩いているデバイスであることと、通知方法はインターネットメールと同じ方法でメールを送ればいいので、通知処理に慣れているというのがその理由です。

携帯電話へのメール送信のポイント

メールを送信する処理はPC宛てのメールと同じなので、手になじんだ言語やコマンドを使えばOKです。

ただ、携帯固有の事情や注意点があります。

ドメイン指定の受信許可/拒否設定

携帯電話キャリアが提供している機能で、特定のドメインからのメールを許可したり拒否したりを、携帯電話の使用者が設定することができます。

うっかり許可指定を忘れていると、さっぱり通知メールが届かないことになるので、許可設定と受信確認は忘れずに行うようにしましょう。

また、最近では各キャリアとも、迷惑メール対策の一環としてSPF(注2)やSender ID(注3)を導入していますので、拒否されてしまうような設定になっていないか、これもあわせて確認しましょう。

キャリア側での拒否

迷惑メールの送り手を排除するために、各キャリアとも、SMTPコネクションの同時接続数の制限や、宛先不明のメールをたくさん送りつけてくる送り手の接続を拒否するといった処置を行っています。

いくら緊急度が高い障害だからといっても通知メールを送りまくったり、携帯のメールアドレスを変えたのを忘れて宛先不明のメールを送りまくったりしていると、迷惑メールの送り手とみなされ、キャリアにブロックされてしまいます。

ブロックされる基準となる閾値やロジックは各キャリアで異なりその内容は公開されてないので、完璧に回避する方法はありません。したがって、キャリアが公開しているガイドラインを守り、行儀よくメールを送るようにしましょう。ブロックされてからでは遅いので、キャリアが公開しているガイドラインを参照して、行儀よくメールを送るようにしましょう。

mailbox is full

携帯キャリアによりますが、キャリアのメールサーバに溜めておけるメールの数や総容量に上限がある場合があります。サイズが大きいメールをたくさん送ると、ちょっと電波が入らないところにいたり電源を切っていたりすると、メールボックスが溢れて届かない可能性があります。

メール本文

最近はだいぶ大きくなりましたが、一通のメールの本文のサイズには上限があるので、必要最低限のメッセージだけをコンパクトに書くようにしましょう。

また、メールが遅延して届く場合もあるので、メールの本文中に、送信時刻を書いておくといいと思います（図1）。

To: scramble-emerg@example.jp
Subject: EMERG example.top DOWN
From: watchcat@example.jp
Date: 7 Jan 2008 20:59:10 +0900

example.top
2008-01-07 20:59:10
500 read timeout
http://example.jp/

次はインスタントメッセンジャ（IM）を使った通知方法を紹介します。

多くのIMクライアントは、新しいメッセージを受信したときに注意を引くアクション（ポップアップや点滅など）をするので、監視の通知としてはうってつけです。

どのIMを使うか

世の中にはいろいろなIMサービスがあります。

監視プログラムからメッセージを送信する必要があるので、お使いの言語でクライアントライブラリが提供されているサービスならば、どれを使ってもOKです。わたしの場合はXMPPを使っています。

XMPPとはなにか？

XMPP (Extensible Messaging and Presence Protocol) とはなにかというと、IMのためのプロトコルセットです。

めずらしいことにその仕様は公開されており、XMPPのWebサイト(注4)やRFC(注5)で参照することができます。

実際に、JabberやGoogle TalkといったサービスはこのXMPPを使っていますし、仕様がオープンなため、XMPPのクライアントや各言語のライブラリが豊富にあります。また、なんとサーバの実装までオープンソースであるので、自分でXMPPサーバを立てれば、社内イントラ専用のIMサービスを行うこともできます。

実例：メールキューに溜まっているメール数の監視

わたしが行っているIM通知の実例をひとつ紹介したいと思います。

どんなものかというと、メールの配信状況の監視のため、メールキューに溜まっているメールの数を確認している監視です。

さて仮に、なにかしらの理由で外部へのメール送信ができなくなってしまったとします。送信が完了しないので、メールキューにはどんどんメールがたまり続け、監視の閾値を越えた時点で異常の通知が実行されます。ではこのとき、通知を携帯電話へのメールで行っているとどうなるでしょうか。今は外部へのメール配送ができないので、通知メールもキューに溜まってしまいます。したがって、ますますメールキューにメールが溜まる悪循環に突入してしまいます。

というわけで、通知をメール以外のもの、IMでやってみようというのがIM通知をやりはじめた動機です。

概要図

全体を図示したのが図2です。

まず、監視の目的であるメールキューに溜まっているメールの数の確認方法です。これはMTAによって確認方法が異なるのですが、mailqコマンド（qmailの場合はqmail-qstat）を使えば、目的の値が得られるでしょう。

さて、本題の通知処理の部分ですが、Perlモジュール（Scramble::XMPP(注6)）を自作して使っています。PerlにはNet::XMPP(注7)というXMPPクライアントのモジュールがあるので、これを使ってメッセージを送ればOKです。が、XMPPサーバの指定や定型のコードをいちいち書くのが面倒なので、ラップしたものを使っているわけです。

これで、リストlist_scramble_xmpp_egのような感じでスマートに通知メッセージを送ることができるようになります。実際にXMPPのクライアント(注8)でメッセージを受信した様子が図3です。

図2: IM通知の概要図

#!/usr/bin/env perl
use strict;
use warnings;
use utf8;
use Carp;

use Scramble::XMPP;

my $sc = Scramble::XMPP->new;
$sc->send_info( body => "do ko ka ga okashii!");
$sc->send_warn( body => "i ma su gu taiou site!");
$sc->send_emerg(body => "mo u da me da...");
$sc->send_emerg(body => "e level: emergency!",
                rcpt => ['hirose@jabber.org'] );

__END__

図3: IMで通知を受信した様子

次はIRCを使った通知方法を紹介します。

IRCとは？

IRC（Internet Relay Chat）とは、テキストベースの多人数でのチャットシステムです。その歴史は古く、誕生したのは1988年だそうですが、OSS系のコミュニティを中心に、いまでもよく使われているようです。

IRCもプロトコルが公開されています。クライアントアプリケーションだけでなく、サーバの実装や各言語用のライブラリもかなり豊富にあるのがIRCの魅力の一つでしょう。

なぜIRCか？

弊社では社内のコミュニケーションツールとしてIRCを使っています。

弊社の場合、オフィスが数か所あり互いに地理的に離れているので、連絡の手段はメーリングリストやIMがもっぱらでした。しかし、メールだとどうしても会話のスピードが遅いですし、IMだと基本的に1対1の会話のため多人数の会話には向きません。そこで導入したのがIRCでした。最初はシステム管理者用のチャンネルと、テクニカルな話題全般のチャンネルだけでしたが、いまではプロジェクトごとにIRCチャンネルを作り、プロジェクト進行上の会話はIRCで行っています。そんなわけで、IRCはなくてはならないツールになりました。

IRCのいいところ

IRCのクライアントアプリケーションによりますが、キーワードという機能があります。わたしが使っているLimeChatというクライアント(注9)の場合は、他人の発言に私がキーワードとして指定した文字列（「ひろせ」「hirose」「カレー」など）が含まれていた場合に、タスクバーのアイコンをピコピコさせたり、Growl(注10)がお知らせしてくれたり、といったことができ、大切なメッセージの見逃しを防ぐことができます。

作業に集中したいときは、割り込まれないようにメールもみませんしIMも落としますしLimeChatもバックグラウンドにして見えなくしておくのですが、それでも重要な連絡は、このキーワード機能で気がつけるようにしています。

というわけで、監視メッセージもこのキーワードに登録して、IRCを仕事中の通知クライアントとして使おうというわけです。

実例：メールキューに溜まっているメール数の監視

監視対象は先ほどのIMのときと同じメールキューなのですが、ちょっと一工夫して、IM通知のシステムを拡張するような感じでIRC通知のシステムを作ってみます。

前提として、既に社内にIRCサーバがあり、そのチャンネルに参加しているクライアントに通知を届ける場合を考えます。

概要図

監視が動いているのが社外のデータセンタの場合、なんとかしてメッセージを社内のIRCサーバまで届けないといけません。

まともに通信経路を確保しようとすると、VPNだのパケットフィルタリングの許可だのめんどうなことになるので、さきほどのIMの通知のしくみを流用することにします。

図4をみてください。

IM通知のとき（図2）は、XMPPのクライアントアプリケーションだった部分がボットになっています。このボットは社内のネットワーク上にいて、外部のXMPPサーバからメッセージを受けるXMPPクライアントの部分と、社内のIRCサーバにメッセージを発言するIRCクライアントの2つの機能を持っています。

こんなふうにボットをブリッジ的に使うことにより、VPNやパケットフィルタリングといったネットワーク的な変更をすることなく、情報の経路を作ることができます。

図4: IRC通知の概要図

IMもIRCもソフトウェア的に通知するものです。ソフトウェア的な通知の場合、ぼんやりしていると見逃してしまうという重大な問題があります。そこで次はハードウェア的な通知を考えてみます。

ネットで探してみると、PCやネットワーク経由で制御できる回転灯やブザーなど、五感にうったえるデバイスがいろいろとみつかります。その中でも今回は、触覚―とくに痛覚―を刺激するデバイスであるUSBミサイルを取り上げたいと思います。

USBミサイル

いろいろな製品が出ていますが、わたしが配備しているのは赤いボディの図5のような外観のミサイル(注11)です。

砲台の向き（上下左右）の変更と、ミサイルの発射（3発まで）がUSB経由でPCから制御可能です。製品には制御用のWindowsアプリケーションが付属していますが、先人のHackのおかげで、Perl、PHP、Pythonなどの言語用の制御ライブラリが公開されています。

今回はこのライブラリを使って、IRCの発言に「emergency」という文字列が含まれていたら、ミサイルを発射するIRCボットを作ってみたいと思います。

図5: USBミサイル

実例：IRCのキーワードをひろって発射

今回、ボットはPerlのPOE(注12)というフレームワークを使って書きました。POEを使うと、イベントドリブンなデーモンやボットをササっと作ることができるのでとても重宝しています。

さて、今回はこんなふうにしました。まず、発言を受け取ったときに実行されるイベントハンドラがあるので、そのイベントハンドラに、指定されたキーワード（「emergency」など）にマッチする発言があったら、ミサイル発射イベントを起こす処理を書きます。そしてミサイル発射イベントのハンドラではDevice::USB::MissileLauncher::RocketBabyモジュール(注13)を使って実際にミサイルを発射する処理を行います。

ソースコードはCodeRepos(注14)に置いておきますので、ご自由にお使いください。

最後に紹介するデバイスは電光掲示板です。

今回は、インフォマークス株式会社さんにおじゃまして、「しあわせさ〜ち」(注15)で使われている電光掲示板をさわらせていただきました。

インフォマークスの社員の方が書かれている『新宿御苑前ではたらく社員のぶろぐ』(注16)によれば、このデバイスはVFD（真空蛍光ディスプレイ）というもので、キットで販売されているものを購入して、ケースなどを自作して仕上げたものだそうです。

機能的には、かなだけでなく漢字も表示することができ、右から左へのスクロールやその逆スクロール、点滅、センタリング、縦表示などなどのエフェクト機能ももっています。PCとのインターフェースはシリアル接続（RS-232C）で、制御プログラムは付属していませんが、この製品との通信プロトコルの仕様は公開されているので、ユーザの方が作って公開しているWindows用の制御プログラムやPerlモジュールDevice::VFD::GP1022(注17)があります。

試しに警告メッセージっぽいものを表示させてみたのが図6です。ブザーや回転灯やミサイルなどけたたましいのに疲れたら、こんなデバイスでゆっくり警告メッセージをスクロールさせてみてもいいのではないでしょうか。

図6: 電光掲示板

監視通知をみのがさないようにするため、その通知方法をいくつか考えてみました。

基本は携帯電話へのメール通知がいいと思いますし、みなさんもすでに実践されているのではないかと思います。

しかし、もっと場面に適した通知方法があるのではないかと考え、PCの前にいる場面を例として、より効率的だ思う通知方法を2つ紹介しました。

また、物理的な通知方法も2つ紹介しました。実用性はさておき、とかく苦痛なイメージのある監視ですが、仕事にかこつけて作る楽しみにかえるには、監視通知はいい題材なのではないかと思います。物理デバイスは現実に動くのでほんとおもしろいですね。

ところで、今回でこの連載はおしまいです。

ネットワーク、サーバといったインフラ系の話題を1年間全6回でお送りしてきました。

本連載は、できるだけほかではみかけないトピックや内容をこころがけたつもりでしたが、いかがだったでしょうか？ そんなちょっと変化球なわたしの記事が、だれのかの役に立てればいいなと思いつつ、この連載をおわりたいと思います。ご愛読、ありがとうございました！

IRC通知のところで、「社外から社内への経路を作るのがめんどうだ」といいました。

本文中では、IMを経路インフラとして使いましたが、もうちょっといい方法がないか考えてみましょう。

まずは、IMに代わる経路インフラはないかと考えると、メール（SMTP）があげられるのではないかと思います。サーバファームでもイントラでも、多くの場合メールならば通じる状態になっていると思うので、経路インフラとしてはうってつけなのではないかと思います。これを図にしたのが図7です。「？」のもやもやの部分がSMTPを使った通知経路で、ここは既存のメール配送経路ということになります。ついでに、社内で通知（のメール）を受ける部分（図中の「Junction」）に、IMやIRCなどお好みの通知手段に変換してユーザに通知する仕組みを実装すると、なおよいのではないかと思います。なぜなら、こんな構成にすれば、通知経路と最終的な通知方法をわけて実装、管理できるからです。

ふたつめは、株式会社カヤックのBM11で公開されているIM API(注18)のような、通知送信処理をWebAPI化する、というアイディアです。これはどういうものかというと、図8のように、とあるURLにHTTP POSTリクエストでメッセージを投げると、予め指定しておいたユーザの元へIMでそのメッセージが届く、というしくみです。メッセージを送る側は、IMサービス用のクライアントライブラリは必要なく、HTTPアクセスさえできればよいので、経路の問題に加えて送信処理が簡単というメリットもあります。

図7: SMTPを経路として使う

図8: IM APIを使う

[24時間365日] サーバ/インフラを支える技術
スケーラビリティ、ハイパフォーマンス、省力運用
(WEB+DB PRESS plusシリーズ)

[Web開発者のための]大規模サービス技術入門
―データ構造、メモリ、OS、DB、サーバ/インフラ
(WEB+DB PRESS plusシリーズ)

ウェブオペレーション ―サイト運用管理の実践テクニック