稼働状況をサイトロックが監視

　そこで目をつけたのが，システム監視を代行してくれるサービス。監視を外注すれば，最小限のエンジニアで効率的にシステムを運用できる。そこで，数社を候補として選び，各社に見積もりを要求した。各社の提案を比較し，最終的にサイトロックを選択。2001年3月からシステム監視を委託した。

　サイトロック選択の決め手はいくつかあった。1つは「サービス内容がロジカルで一番明確だった」（青嶋社長）こと。何をどう監視してくれるか，監視の結果をどう伝えてくれるかがわかりやすかったという。

写真1●システム監視内容をWebブラウザ上で閲覧できる サイトロックは，ユーザー向けに，ほぼリアルタイムに監視対象のステータスがわかるツールを提供している。（a）はWebサーバーのCPU使用率，（b）はWebサーバーに対してpingコマンドを実行した場合の応答時間を監視したもの。

　監視項目は，アイ・エスクロウの希望に応じてカスタマイズされている。アイ・エスクロウの場合は，サービスそのものの稼働状況，WebサーバーのCPU使用率などの監視である。これらの監視ステータスは，サイトロックが各ユーザー向けに提供しているWebページからほぼリアルタイムで確認できる。写真1（a）はWebサーバーのCPU使用率を監視した様子。写真１（ｂ）はpingコマンド（ICMPエコー）によるサーバーの稼働状況と，ネットワークの遅延（ラウンド・トリップ）時間である。

　もう1つの決め手はコスト。あるベンダーは監視のためにデータセンターまで専用線を引くように提案してきた。しかし，それではランニング・コストがかかり過ぎる。この点，サイトロックはインターネット経由でデータセンター内に設置したシステムをリモート監視してくれる。料金も月々100万円を大きく下回り，他社よりも安価だった。現状では，エンジニアを3人雇用しているものの，24時間監視についてはほぼ人件費1人分で実現されている計算である。

　しかもサイトロックは，ユーザーに伝えるべき重要な警告だけを抽出してくれる。自社のエンジニアは，クリティカルな問題にだけ対処すればよく，効率的にシステムを運用できる。

　監視の効果はすぐに表れた。「Apacheが止まった」とアラートが送られてきたのである。実際には，これはエスクロウ・サービス開始直後から発生していた問題。ただ，それが，サイトロックのサービスを利用してみて，初めて浮き彫りになった。

　サーバーのリソースを監視してみると，Apacheが止まってしまう直接の原因は，メモリー不足にあると推測できた。システムを詳細に調べて，米国アイ・エスクロウが開発したソフトの欠陥（バグ）のせいで，メモリーが完全に解放されないために利用可能な容量が徐々に減ってしまう「メモリー・リーク」が発生していることを突き止めた。早速，ソフトのバグを修正し，大事に至らずに済んだ。

写真2●Webサービスとして他のWebサイトのサービスに組み込まれる Webサイトの決済部分にアイ・エスクロウのサービスが組み込まれる。この際，自社のシステムをきちんと監視しておけば，障害の切り分けが容易になると同時に，サービス・レベルが劣化していないかを証明できる。

サービスの品質保証にも有効

　実は，同社はもう1つ別のシステムで，サイトロックの監視サービスを一時的に利用したことがある。あるWebサイトに向けてカスタマイズしたエスクロウ・サービス用のサイトだ。

　同社は，一般ユーザー向けのほかにも，マーケットプレイスなどに向けて，それぞれ専用のエスクロウ・サービスを提供している。仕組みそのものはほとんど変わらないが，マーケットプレイスとエスクロウ・サービスの間で売買契約や顧客管理，決済などの機能を連携させられる（写真2）。

　このカスタマイズ・サービスを始めた2001年4月，あるマーケットプレイスとの間で，データが途中で消えてしまい，連携が途切れるトラブルに陥った。青嶋社長は「はじめはどこに問題があるのか見当がつかなかった。こちらのシステム側の問題かと考え，ソフトを逐一チェック。米アイ・エスクロウの技術者とも何度もやり取りしたが，米国からはそんなはずはないという答えばかりだった」と苦笑する。

　そこで，このカスタマイズ・サービス用のシステムについても，サイトロックに2週間ほど監視を依頼。結果は，同社のシステム側には何の障害もなし。紆余曲折の末，結局，相手側のシステムの一部が止まっていることが判明した。同社にとっては，監視サービスを利用することでエスクロウ・サービスの品質を証明できたことになる。

今後はコンポーネント監視も

　現状でも，頻度こそ高くないものの，サイトロックからはまだアラートが来る。「シビアなものはだいたい月に1回程度」（荒井氏）である。ただ，ほとんどは，サーバーのCPU使用率の増加。これについては，原因がわかっている。アラートが送られてくるのが，データのバックアップやデータベースのインデックスの再構成などを実行した時間帯だからだ。これ以外は，今のところ，深刻な警告は見られない。

　ただ，今のシステム監視だけで十分と考えているわけではない。特に気になっているのがデータベース部分。トランザクション処理の心臓部である。今後，ユーザー数や取引数が増え，データベースの負担が増大すると，パフォーマンス劣化やシステム障害の危険性は高まる。このため，今後はコンポーネントごとの監視が必要になると見ている。荒井氏は，「サイトロックが検討を進めているというデータベース監視サービスに期待を寄せている」。