△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△ 　　　　　　　　　　　　まほろば工房ニュース 13号 　　　　　　　　　　　　　　 2009年3月18日 　　　　　　　　　　　 http://www.ate-mahoroba.jp/ △▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△ 　年を明けたと思えばもう３月、気温も上がってきて心地よい日が続くように なってきましたが、一方で花粉も大変なことに・・・。 　年度末の忙しい時期ですが、ぜひ、息抜きがてらひと時をお付き合いくださ い。 さて、今回のまほろば工房ニュースのトピックは以下のとおりです。 　1) ネットワーク・サーバーの監視。適切な異常通報って？ 　2) BGPコンサルテーションサービス開始！ ＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝ サーバーの監視、滞っていませんか？ 　まほろば工房が提供するSPEED Solutionを活用し、SPEED本来の力を存分に 　発揮して開発された、SPEED Callサービス。インターネットからの死活・ 　サービス監視はもとより、Webサービスのアクセス性能を検査する性能監視 　機能にも活用できます。 　また、SPEEDソリューションならではの異常発見時の登録電話番号への自動 　通報機能もあり、発見した異常は絶対に見逃さない環境を安価にご提供しま 　す。 　24H365Dのオペレーターの契約は高いが、何とか確実な監視をしたいと思っ 　たら是非、導入をご検討ください。 ＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝ ■ ネットワーク・サーバーの監視。適切な異常通報って？ 　ネットワークやサーバーを運用している方なら監視というのは行っていると 思います。監視と一言でいっても、単純な死活監視から、サーバーで動いてい るアプリケーションの稼働確認やサーバー自身のリソース（メモリやディスク など）の監視まで様々です。 　もちろん、これらの監視は種類も違えば、その方式も異なります。このため 監視で発見したいわゆる「異常」を通知する方法もそれぞれ異なると考えるの が適切といえるでしょう。特に通知は、その緊急性や通知先の適性を考えなく ては、せっかく通知してもその対応にかえって時間がかかってしまうことが考 えられるのです。 　今回は、このような「異常」とその「通知方法」の関係について考えてみま しょう。 　●通報の緊急性と通報先の適性 　　　監視システムなどによって異常を発見した場合、その異常の種類によっ 　　て1)異常の緊急性と2)通知先の適性という二つのことを考えなくてはなり 　　ません。この二つについて少し詳しく考察してみましょう。 　　　1) 異常の緊急性 　　　　　　こちらは言うまでもなく、発見した異常をどれだけ即座に通報し 　　　　　なくてはならないということです。 　　　　　　たとえばサービスの停止などを伴うような異常は見逃すことが 　　　　　できませんから、緊急性は非常に高いといえます。 　　　　　　一方でディスクの残りが少なくなったとか、CPUの稼働状況が一時 　　　　　的に高くなったという場合は、緊急性はそれほど高くなく、原因を 　　　　　じっくり調べて対応するということが望まれます。 　　　　　　特に緊急性の高い通知の場合は、単純に即座に通報するだけでな 　　　　　くより適切に情報を知る必要があります。そこで、二つのタイミン 　　　　　グで異常を知る必要が出てきます。 　　　　　　まずは異常を検知しますから、サービスに影響があるような異常 　　　　　がでていることを「まずは通知する」という「第一報通報」です。 　　　　　第一報通報では、「何が起きている」というよりも「何かが起きて 　　　　　いる」ということを通知することに注力し、異常が起きてから運用 　　　　　者が認知するまでは、非常に短い時間で完了させる必要があります。 　　　　　これにより、まずは運用システムに何かが起きていることを知り、 　　　　　対応体制を整えることができます。このときに必要な情報としては、 　　　　　　- いつ 　　　　　　- どのサービス、またはどの機材で 　　　　　　- どのような監視で異常が発見されたのか 　　　　　という情報がわかればよいでしょう。 　　　　　　次に必要なのが、「異常のより詳しい内容」です。異常に関する 　　　　　情報のレベルは「第一報通報」よりも、より詳しく確認が取れたも 　　　　　ので、ほとんどの場合、この情報によって異常対応の行動がどのよ 　　　　　うなものになるのかが決まります。これを「第二報通報」と呼ぶこ 　　　　　とにしましょう。 　　　　　　このようにサービスの停止などの確実に対応する必要がある異常 　　　　　に対する通知は二つのフェーズに分けて考えることで、より短時間 　　　　　で対処に望めるようになるのです。 　　　　　　比較的小さいネットワークやシステムの場合、より詳しい確認が 　　　　　必要な第二報通報に必要な情報を集める作業を第一報通報を受けた 　　　　　運用者が行う場合もありますから、場合によっては、第二報通報は 　　　　　必要がない場合があります。 　　　2) 通知先の適性 　　　　　　通知先の適性は、「誰に通知するか」という問題です。 　　　　　　比較的小さいネットワークやシステムの場合は、「運用者全員に 　　　　　常に同じ情報を伝える」という対応でもよいですが、担当が分かれ 　　　　　ている場合などは少し対処が必要です。 　　　　　　多くの場合、ネットワークの面倒を見る運用者とサーバーやアプ 　　　　　リケーションの面倒をみる担当者がわかれているます。ですから、 　　　　　できれば通知は適切な担当者に連絡することが好ましく、これによ 　　　　　り対応時間を短縮することができます。なぜなら、全く違う担当者 　　　　　に連絡してしまった場合、見当違いの解析を行って対応が遅れてし 　　　　　まう可能性があるからです。 　　　　　　たとえば、サーバーＡで稼働しているＷＷＷサービスを考えてみ 　　　　　ましょう。このとき、サーバーＡまでのネットワーク経由での到達 　　　　　性に異常がある場合はネットワーク担当者を、ＷＷＷサービスの閲 　　　　　覧に異常がある場合はサーバー担当者を呼び出すことで、通知の適 　　　　　性は上がります。これを監視サービスと照らし合わせてみましょう。 　　　　　　サーバーＡに対して、PINGによる死活監視とHTTPのサービス監視 　　　　　の２種類を実施します。PINGによる死活監視は、多くはネットワー 　　　　　ク経由でのサーバーへの到達性に関する異常を示します。一方、HTTP のサービス監視の場合は、Webサービスの異常を示します。 　　　　　　つまり、この二つの監視を実施し、監視種別の違いにより通知す 　　　　　る担当者を変えることでより適切な通知が可能になるのです。 　　　このように通知先や通知方法を適切に検討することで、より適切な通報 　　が可能になり、それにより異常発生から対応までの時間を短縮することも 　　可能になるのです。 　●どのような手段によって通知すべきか？ 　　　さて、もう一つ考えなくてはなりません。それは、どのような手段を使っ 　　て通知を行うかです。 　　　せっかく、適切な異常通知方法や通知先の選択を行ってもそれらが、確 　　実に通知できなくては意味がありません。これも緊急性や情報量などを鑑 　　みながら選択する必要があるのです。 　　　下記に通知手段とその特徴を整理してみました。 　　1) 電子メール 　　　　　電子メールによる通知は、高い同報性や他システムとの連携性を持 　　　　つため非常に多く利用されている通知方法です。 　　　　　一方で、電子メールの場合は、通知方向が一方向であるため、その 　　　　通知が確実に通達できたかという確達性は低く、緊急性の高い場合に 　　　　その通知が見逃された場合でも、そのことがわかりません。 　　　　　また、電子メールは送りだしてしまえば終わりですから、送付エラー 　　　　などによってサーバーにメールが滞留した場合の遅延も管理できず、 　　　　緊急性の高い場合には必ずしも適切な方法とは言えません。 　　2) 携帯メール 　　　　　携帯メールも電子メールと同様に多く使われる方法ですが、こちら 　　　　の特徴もほとんど電子メールと同じですが、携帯メールの特徴は、見 　　　　逃しが起きやすいということです。 　　　　　数秒のアラーム１度だけで着信を通知しますから、どこでもメール 　　　　を受けられる一方、気付かないと長時間見逃す危険性が高いのです。 　　3) オペレーターによる電話 　　　　　コールセンターなどと契約し、異常を検知した場合、オペレーター 　　　　が担当者に電話をすることで確実に異常を通知します。 　　　　　緊急性の高い通報の場合は非常に確実な方法ですが、オペレーター 　　　　の質によって対応が異なる場合も多くあります。また、オペレーター 　　　　が運用経験者の場合、通知とともに通知する異常の情報も求められる 　　　　ことがあるため、通報に先立って情報を収集するなどの手間もかかり 　　　　ます。結果、通報までの時間が遅くなる可能性が出てきます。 　　　　　つまり、情報レベルは多少はあるが、第一報通報レベルの緊急性の 　　　　高い通報には適さない場合が多いのです。 　　　　　また、オペレーターを利用した場合は、サービス料金が高くなるケー 　　　　スもあります。 　　4) 自動音声による電話 　　　　　自動音声は、電子メールとオペレーターによる電話の中間といえま 　　　　す。 　　　　　電子メールなどによる通報の場合は、システムの連携性や即応性は 　　　　高い一方、確達性は低いことが問題です。そこで、システム的に検知 　　　　した異常を電話によって通報し自動音声で要点だけを伝えることで、 　　　　オペレーターによる電話通知の良い面を取り込むことができるのです。 　　　　　ただし、異常に関する解析などは一切行っていませんから、情報レ 　　　　ベルは電子メールレベルと変わりません。 　　5) FAX 　　　　　FAXは、記録を残す。という点について非常にすぐれた方法です。 　　　　　即応性は低いですが、情報量が高く、多くの場合、対応終了後の対 　　　　応報告などの用途で利用されます。 　　　このように通報手段は、その特徴によって第一報通報に適するもの、第 　　二報通報に適するものなどが分かれてくるため、通知方法や通知内容など 　　に合わせて選択することが重要になってくることがお分かりになるかと思 　　います。 　ネットワークやサーバー監視の分野では、「異常の検知」という部分に注目 が集まりがちですが、集めた異常は必ず通知の必要性が出てきます。通知方法 や通知手段を適切しておくことで、これらの検知された異常はより適切な情報 として利用することができるようになるのです。 　ここでいま一つ通報のあり方について考えてみてはいかがでしょうか？ ====================================================================== ※SPEED Call : 自動音声によるネットワーク・サーバー監視の通報ASPサービス 　http://www.speedcall.jp/ ＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝ IPv6の準備はできていますか? 　　~~~~~~~~~~~~~~~~~~~~~~~~~~~ 　まほろば工房では、IPv6対応へのご相談を随時受け付けております。 　IPv6への対応は、ネットワークだけの問題ではありません。皆さんが利用し 　ているサーバーなどでも必要になるものです。特に、オンラインでビジネス 　をされている方にとっては、IPv4枯渇の問題は企業の死活問題につながりか 　ねません。IPv4枯渇まであと数年。ぜひこの機会に準備状況をご確認くださ 　い。まほろば工房は、IPv4の現在の状況などと照らして適切なアドバイスを 　させていただきます。 　 　IPv6移行コンサルテーション：http://www.ate-mahoroba.jp/ipv6/index.html ＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝□＝ ■ BGPコンサルテーションサービス 開始！ 　1月より、株式会社メディアエクスチェンジと当社の提携で 　「BGPコンサルテーションサービス」を開始しました。 　BGPというのは、インターネット全体の経路情報を制御するための経路制御 　プロトコルですが、ISPなどはこのBGPを利用してISPやデータセンターなど 　の大規模ネットワークを相互接続しているのです。 　BGPの特徴は、複数の組織間を相互接続するためのプロトコルであるという 　ところで、これにより、上流ISPを１社に限定するような接続ではなく、複 　数にすることができるようになります。（これを「マルチホーミング」と 　いいます。） 　問題は、このBGPを利用するに当たってはそれ相応の経験が必要であると 　いうことです。 　しかし、昨今の動向として多くのコンテンツプロバイダや比較的小さいネッ 　トワークでも、インターネットに対する冗長性確保のためにBGPを使い始め 　る傾向が出てきました。 　そこで、メディアエクスチェンジでは、BGPの運用を支援することを目的に 　このBGPコンサルテーションサービスを始めることになったのです。 　サービスとしては、 　　- BGPルータの運用代行 　　- BGP制御に関するポリシ策定等の運用支援 　を主な内容としてお手伝いさせていただきます。 　ご要望があれば、そのほかのご協力もさせていただくことも可能です。 　御興味のある方は、是非お問い合わせいただければと思います。 　http://www.mex.ad.jp/news/ir/2009_0128.pdf 　お問合わせ：http://www.ate-mahoroba.jp/contactus.html ====================================================================== ■まほろばBlog、つれづれなるままに更新中 　http://www.ate-mahoroba.jp/blog/ ====================================================================== ■ IP-PBXアプライアンス「MAHO-PBX」（３月出荷開始！） 　MAHO-PBXは、SPEEDで培ったSIP(Session Initiation Protocol、IP電話など 　の通話制御プロトコル)技術を生かしたAsteriskベースの小型IP-PBXアプライ 　アンスです。 　MAHO-PBXは、小型ながら、PBXとして必要な多くの機能を実装し、それらは 　すべてWebから設定・制御可能な、手軽に使えるPBX製品です。 　小規模なオフィスでも、PBXが提供する様々な機能は非常に便利です。 　http://www.ate-mahoroba.jp/maho_pbx/ ====================================================================== ■ 無料で使える「会議・宴会出欠登録システム - ConfReg」 　通常の出欠調査システムなどの場合、あらかじめ参加者がわかっていなけれ 　ばいけないなど、カンファレンスの出欠調査やグループでの宴会の出欠調査 　などでは不便な部分もありました。 　ConfRegでは、これまで経験からこれらの不便さを改善してあります。 　ご利用は無料ですので、ぜひご利用ください。 　http://confreg.ate-mahoroba.jp/ ====================================================================== ■D-COMMUNE体験アカウントをご利用ください 　D-COMMUNEをより具体的に体感していただくために、まほろば工房では、 　D-COMMUNEを利用したまほろば工房ユーザページにゲストアカウントを用意 　しました。ぜひともご利用ください。 　感想などありましたら、トピックに記載ください。 D-COMMUNEホームページ： http://www.d-commune.jp/ 　まほろば工房D-COMMUNEゲストアカウント 　　URL ： http://dcm.ate-mahoroba.jp/ 　　ユーザ名　： guest 　　パスワード： guest1 ■D-COMMUNE無料ダウンロード 　D-COMMUNEのソフトウエアライセンスサービスをより多くの方に使っていた 　だこうと、D-COMMUNEソフトウエアがホームページから無料でダウンロード 　していただけるようになりました！ 　http://www.ate-mahoroba.jp/products.html ■当社商品・ソリューション・その他お問い合わせ先 　株式会社まほろば工房　近藤邦昭 　Tel: 044-812-3288 Fax: 044-812-3287 eMail: question@ate-mahoroba.jp 　Web: 　http://www.ate-mahoroba.jp/contactus.html △▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△ ■連絡先 ご意見・ご質問・配送中止などについては下記までご連絡ください。 　よろしくお願いいたします。 　また、今後取り上げてほしい話題などについてもご意見をお寄せ下さい。 　株式会社まほろば工房　近藤邦昭 　Tel: 044-812-3288 Fax: 044-812-3287 eMail: question@ate-mahoroba.jp 　Web: 　http://www.ate-mahoroba.jp/ △▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△▼△