SPEED Callサービス利用事例紹介
■ 株式会社インターネット総合研究所様
SPEED Callサービスを活用されている株式会社インターネット総合研究所様にお邪魔してまいりました。インタビューは、インターネット黎明期からネットワークの運用に携わり現在は同社の取締役を務められている西野大様と、西野様と一緒に日々ネットワーク運用に奔走されている林明保様に御協力いただきました。
■ 目次 ■
最初にインターネット総合研究所様について伺いました
SPEED Call を御利用いただいた経緯について伺いました
SPEED Call を御利用いただいている様子について伺いました
SPEED Call を導入頂いた経緯について主に経営者側からの御意見を伺いました
SPEED Call の機能についてコメントを頂戴しました
最後に
■ 最初にインターネット総合研究所様について伺いました
菊池： まずは、株式会社インターネット総合研究所様の概要について教えてください。 西野： インターネット総合研究所は、グループ子会社を取りまとめる持ち株会社です。
グループ全体ではiDCやCDNといったインターネット関連事業を行っています。菊池： グループ全体ではかなり大きな企業体ですね。 西野： グループ全体では400名以上の社員を抱えております。当社自体は社員数が約40名で、インターネットに 関連するコンサルティング業務を行っております。この他、グループ内ではグループ会社に対する技術支援を行う立場にあります。また、インターネットの実際の運用を行いつつ、シンクタンク的な研究活動もしているのが特徴でしょうか。 菊池： 実際にネットワークを運用されているとのことですが、それらのネットワークにはどのような特徴がありますか？ 西野： グループ会社に対するインターネット接続の提供業務でネットワークを運用しています。
傘下ではデータセンターをはじめとする事業を行っているため、業務内容としては通常のISP同様の項目を持っていますし、厳しい信頼性が要求されます。
運用しているのはBGPルータ5台をはじめとしてルータとファイアウォール全部で20台弱、あとサーバが10台弱です。これを私を含めて4名で運用しております。菊池： SPEED Callサービスは、このような規模を想定して設計していますので、まさに典型的なユーザさんということになりますね。
■ SPEED Call を御利用いただいた経緯について伺いました
菊池： SPEED Callをご契約いただき、すでに数カ月にわたってご利用いただいているわけですが、それ以前も監視は行っていたのですよね。 林： サーバ自身はもちろん以前から監視をしていました。
これは社内のネットワーク上の監視サーバから行っていました。
しかしながら、携帯にアラートを上げるような措置は講じていませんでした。
これは、自分たちが運用者であると同時に利用者でもあり、サーバを常に利用していて不具合があればすぐに気づくから、という理由からです。菊池： そこで SPEED Call サービスを御利用になった経緯を教えてください。 林： ある時、社内でメールが使えなくなるトラブルが発生しました。インターネットとの疎通が失われていたのです。
サーバ自身は問題なく動作しており、社内のネットワークは正常だったのですが、これは当然ながら社内の監視システムでは検出できませんでした。菊池： 障害はどのようにしてわかったのですか。 林： 社内ユーザからの「何だかメールがおかしいぞ」という声でした。
SPEED Callの場合、インターネット経由の監視なので、弊社のシステムも含めてインターネット全体として、ちゃんと稼働しているかどうかを確認できるのがうれしいですね。
■ SPEED Call を御利用いただいている様子について伺いました
菊池： SPEED Callサービスを御利用いただくなかで、印象的な御経験などおありですか。 林： SPEED Callを契約して間もない頃、深夜に携帯電話が鳴りました。あわてて確認しましたが、大きなトラブルは発生していないようにみえました。ところが、よくよく調べてみたところ、深夜帯に負荷の高いバッチ処理がサーバで動いていたのです。 菊池： サービスが停止していたのではなく、過負荷で処理性能が落ちていたと。 林： はい。実は最初 SPEED Call が敏感なんだろうと思い、障害検出のパラメータを緩めてみたんですね。 菊池： パラメータを触れるのはSPEED Callに最近導入した機能ですね。 林： そうです。その機能を使って若干鈍感にしてみたのですが、しばらくするとまた深夜に電話がかかってきて… それで、これはおかしいと。
それでちゃんと調べたらサーバの問題と気づきました。菊池： 徐々に過負荷の程度が悪くなって行ったようですね。 林： サービス自体は稼働確認をしていまして、通常は問題なく稼働していたわけです。
ところが、深夜にわたってもまんべんなく、それもエンドユーザ側からの環境で稼働確認をすることはなかったんですね。この意味で、SPEED Callは単なる死活監視ではなく、サービス品質の監視としても使えますね。菊池： SPEED Callでは、監視の結果、異常を自動音声で通知しますが、この自動通知という仕組みをどう思われますか？ 林： 自動でそれも機械が電話をしてくるのが良いですね。人が電話をかけてくるより、SPEED Callのように機械が電話をかけてくる方が対処にとりかかる時間が短いんですよ。 菊池： もうすこし具体的に教えてください。 林： 人間が電話をかけてくると、人同士のやりとりが発生して、結局とりかかるのが遅れるんです。例えば「何をもって障害と判断したのか」とか「あれは調べた？」とか。 菊池： 確かに機械が相手なら会話にはなりませんね。 林： 結局、自分がリモートでシステム内を調べる方が状況把握をスムーズにでき、その方が全体として対処も早いのです。 菊池： 菊池：機械が人間を代替できるというだけでなく、むしろ機械の方が良いこともあるんですね。 林： エスカレーションのルールがあっても電話をかける方は躊躇することがあります。
特に夜だと、寝ている人間を起こすというミッションが暗黙の内に含まれていますので、起こされる側だけでなく、電話をかける側にも心理的な負担がかかります。
機械は躊躇せずに電話してきますし、障害と判断するに足る客観的な状況であることが明らかなので、そこが良いですね。
■ SPEED Call を導入頂いた経緯について主に経営者側からの御意見を伺いました
菊池： 人間ではなく機械が通知するということに関連して、完全に機械化することでSPEED Callは1監視あたり月額2500円という料金設定が可能になりました。
これはオペレータが障害を通知するようなMSPのサービスに比較してかなり安い設定にしたつもりです。西野： MSPとの比較において、確かに料金は大きなポイントでした。
ただし、それだけでなく、お手軽さが大きなメリットですね。MSPの障害通知サービスを利用しようとすると、それなりに大変なのです。菊池： 詳しく教えてください。 西野： まず、打合せしてどのようなシステムや運用体制なのかをMSPさんに理解してもらいます。
それからMSP側でやっていただく内容をきちんと書き下した文章を用意して、契約ができてから監視が始まります。監視しようかなと思ってから監視が始まるまでが長い。林： SPEED Callならとにかく監視を始めてしまえますし、後から別のサーバにしようとか、別のプロトコルの監視に変えようとか思ったら、Web でできてしまいますので。監視契約数を若干余分にしておいて、ちょっと使いたいときにボランチのように使うこともできますし。あと、見積を間違えて余分に契約してしまっても、減らすのも簡単ですし。 菊池： こちらとしては減らされると悲しいですが…（笑） 西野： いえいえ、減らすのが簡単にできるのも大きなメリットです。
一般に毎月かかるランニングコストを企業は嫌がります。実際、経営者の立場としてはそこに目がいきますから、減らしやすいということは、安心して契約できるということにつながるんですよ。菊池： なるほど。このほか、経営者としての視点で御覧になっていかがですか。 西野： SPEED Callを使うということは、監視システムの設置運用のアウトソーシングに相当します。まずランニングコストの点で、アウトソースする方が経費的に優位であると判断しました。 菊池： 優位性はどのあたりにあるでしょうか。 西野： 先日経験した障害で、インターネット経由での監視が重要とわかりましたが、さりとて、自社外に監視システムをハウジングするとなると、設置コストとランニングコスト、それに充てる人件費が馬鹿になりません。
余計な設備も持ちたくないですから、ここは外に出したいところなんです。菊池： SPEED Callを導入するにあたり、御社内の運用体制は変わりましたか。 林： そうですね、SPEED Callからの通知があったらどうするかを決める必要があり、この副産物で、これまで監視業務フローの曖昧だった部分をきちんとしたということがあります。 西野： 意外と思われるかもしれませんが、労務的な観点から見てもメリットがありました。 菊池： 労務でですか？ 西野： そうです。携帯電話にメールで通知させるのは弊社のエンジニアでも自分で仕込めます。
ところが、自分でサーバ設定して、その当人が監視も設定するとなると、休日であっても障害が出たら自分の問題として処理しがちになります。菊池： 結局、会社とプライベートとの境目を曖昧にしてしまうのですね。 西野： そうです。仮想サービス残業状態とでも申しましょうか。健全とは言えません。
その点、外部の監視システムから音声でアラートが上がりますと、これは誰もが明らかに会社の業務と認識できる訳です。菊池： 音声通知であることもポイントですか。 林： メールの通知の場合は、ちょうど他に抱えている業務があると、「まあいいや、後で見ておこう」と自分勝手に判断する傾向にあります。音声でアラートが来るとそうはなりません。
あと、音声通知だと自分のやっていることが割り込みを受けたという印象がはっきり出るので、休日の作業でもちゃんと会社に請求しようと言う気分になります。（笑）菊池： あと、オペレータさんが反応しているかどうかが、音声通知の最中に確認されるので、軽く流せないというのもあるかもしれませんね。 西野： SPEED Callのメリットとして、誰にいつアラートが上がったかだけでなく、誰が反応して誰が反応しなかったかも、ログとして残るのが良いです。
これは経営者からみると、監視サービスというよりは、むしろマネージャがオペレータの動きを管理して、運用が適切になされているかを確認するためのツールという風にも考えることができます。
■ SPEED Call の機能についてコメントを頂戴しました
菊池： ところで、SPEED CallサービスはIPv6に対応していますが、ご利用ですよね？ そのあたりについても教えてください。 林： IPv6に対応しているのも、選択の大きな理由の一つです。 菊池： ちなみに現在はIPv4で監視できるプロトコルは、全てIPv6でも監視できます。
これはインターネット総合研究所さまの他にも、IPv6を御利用のユーザさんがいらしたことで取り組みました。林： 最初は IPv6 については ping だけでしたよね。
サービス開始当初から完全対応していても良かったかと思いますよ。菊池： コメントありがとうございます。数ある機能アップ案の中でもユーザさんの声があると優先して取り組むことができます。 西野： IPv6対応であり、かつ通知をアウトバンドでできる、つまり社内ネットワークを一切使わないでアラートを受け取れるというサービスが他になかったのが採用理由として大きいですね。 菊池： アウトバンドということにつきましては、ほとんどのお客様が音声もメールも携帯電話を通知先としてお使いでいらっしゃいます。 林： 携帯電話の利便性もありますが、アラート用に携帯通話と携帯メールの2系統のアウトバンド通信を使うことができるということも重要です。 菊池： 最後になりますが、今後SPEED Callサービスを改良するにあたって、何か御気づきの点などアドバイスをいただけますでしょうか？ 西野： 現在のSPEED Callサービスは柔軟性に飛んでいるため、さまざまな監視が可能であるのが大変良いわけですが、一方で、お手軽にポンと監視を始めるには、多少手順が多く感じています。初心者向けに設定ウィザードをサポートするとか、定食のような監視パッケージを準備してもらえると良いかもしれません。 林： そのほか、契約が切れる前に監視同様に自動音声で通知があると面白いですね（笑） 菊池： アドバイスありがとうございます。 多くのご意見をいただき、また長時間にわたりありがとうございました。
■ 最後に
今回のインタビューで、障害通知は人間よりむしろ機械が行う方が望ましいという御意見や、労務も含めて管理体制の健全化にもつながるという御経験談を頂戴しました。
これは、我々サービス提供側が気づいていなかったSPEED Callのメリットです。
SPEED Callを御検討くださっているみなさまも是非参考にしてください。