DevとOpsの垣根が低くなり
システム障害の予兆検知から対応までが迅速化

気象災害から人命を守るための「クラウド防災IoTシステム」

株式会社ベクターデザイン
代表取締役 梅澤 幻 氏

——事業について教えてください。

梅澤氏　弊社の事業の中核は、IoTシステム事業、ICTインフラ事業、ライブオフィス事業の3つの領域になります。

IoTシステム事業では、センサーで雨量や河川の推移情報などをリアルタイムに計測し、関係者にいち早くお伝えするクラウド防災IoTシステムを提供しています。同システムは、PCブラウザやスマートフォンのみならず、SNS、サイネージ、電話通報、パトランプ、防災無線など、さまざまな通知に対応しています。自治体が独自に持つ観測データとクラウドにある気象や防災データのシームレスな連携を強みとし、自治体や交通インフラなど全国1,500箇所以上の観測点で24時間365日、今も稼働しています。

ICTインフラ事業では、企業におけるICT戦略の立案や調査、システム設計、構築作業、社内でのサポートデスク対応、インシデント発生時の対応など、企業の情報システム部門が抱えるさまざまな課題を解決するため、弊社のITインフラの運用ノウハウやシステム開発ナレッジなどをフルに活用し、企業経営におけるICT活用をバックアップしています。

ライブオフィス事業では、「集う、できる、作りたくなる」をコンセプトとしたクリエイターとエンジニア向けのものづくりのためのライブオフィス「PERCH」を東京都渋谷区と富山県富山市で提供しています。通常のコワーキングスペースと異なり、紹介制のスペースとなっているのが特徴で、XR、Webデザイン、システム開発、フォトグラファー、映像制作、ブランドマネジメントなど、トップレベルの人材と組織が集い、弊社と共同で数多くのプロジェクトに携わっています。

——Site24x7導入前のシステム監視における課題はどのようなものでしたか？

梅澤氏　主に2つありました。コスト削減とニーズの変化への対応です。

当時、監視コストを削減することを目的にOSSのZabbixを採用していました。しかし、導入から数年が経ちコストの検証を行ったところ、運用の手間自体が増えており、エンジニアの本業に割り振るべき稼働を取られてしまったり、Zabbixを担当するエンジニアを新たに雇用したりで本末転倒になっていました。具体的には、SNMPに関する監視対象ごとの個別の設定で苦労したり、オンプレミスの監視システムのため、システム障害やネットワーク機器や回線の障害、感染障害などにより肝心の監視が停止してしまう問題への対策（ラズパイと3Gモデムを組み合わせた監視ボックスの自作）、別ロケーションからの監視のための工夫などが手間となっていました。

また、この頃、中小企業でもICTインフラは本格的な普及期に入り、運用監視に関するニーズも変化していました。死活監視、パフォーマンス監視だけでは不十分とされ、サービスレベルでの監視が必要となり、複数ロケーションからの応答時間の監視、IaaSとの統合に加え、定期レポートなど、監査資料も必要となりました。お客様の求めるサービスも単なるホスティングではなく、アプリケーションサーバーなど目的ベースでのコンピューティングやITサービス全体にわたるマネジメントなど、高度化する要求に対応していく必要がありました。

そこで、Zabbixを互換する新たなサービスを模索することとし、調査の結果発見したのがSite24x7でした。2014年頃、国内のサイトで記事を見たのが初見だったと思います。

——主にどのような形でSite24x7を活用いただいていますか？

梅澤氏　当初、弊社では主に外部ロケーションからの応答時間の監視用に導入しました。Eメールを定期的に送信し、到達状況や時間を計る機能や監視、障害発生検出時の電話通報など、有力な機能が揃っていることに驚きました。当時はまだSlackなどまったく普及してない時代です。電話通報はかなり便利な機能で何度も助けられました。ただ、深夜にかかってくるSite24x7の独特で少し暗めのトーンの電話を深夜に聞いて、こちらも暗い気持ちになったのを今でも覚えています（笑）

当時のSite24x7は文字通り、日進月歩のペースで機能追加が行われていたので、弊社もその成長に歩調を合わせるようにさまざまな対象を監視に追加していきました。

そのような中、弊社ではオンプレミス環境のほとんどをAWSに以降するという方針転換を行いました。その時、オンプレミスにこだわりのあったインフラエンジニアは経営層との間で意見が衝突してしまい会社を去ってしまいます。そのエンジニアがZabbixの管理を担当していたため、ここまで構築してきたZabbixをどうするのかと宙ぶらりんな状況が生まれました。

エンジニアの退職がきっかけではありましたが、2018年にSite24x7へ全面的に移行することにしました。一本化に合わせ運用監視系サービスの棚卸を行い、主要な監視にSite24x7、ログ関連の対応はKIWI Syslog Server、端末管理にLansweeper、ネットワーク監視にFortiCloudを採用することにしました。この住み分けは2022年の現在も変わっていません。

今では、2つの自社設備と6つの客先ロケーション、そして1つのIaaSにて320以上の対象をSite24x7で監視し、顧客との情報共有基盤である「Site24x7 StatusIQ」の利用も開始しています。また、情報セキュリティマネジメントシステム（ISO27001）に基づく運用にも活用しています。

——導入構築時の印象を教えてください。

梅澤氏　あまり深く考えることなくDIYで構築を行いましたが特に問い合わせをすることもなく、ドキュメントのみですんなりと導入できました。

まず、外部ロケーションからのWebサイト監視機能からはじめ、次にエージェントによるサーバーパフォーマンス監視を開始。さらに、各拠点のホストにオンプレミスポーラーを導入し、ファイアウォールの内側の機器を検出・登録、監視しました。

また、保守先のオフィスにオンプレミスポーラーを導入したPCを設置したり、組み込みサーバーにも監視エージェントを導入して検証を行いました。AWS EC2の監視にはサーバーエージェント監視とクラウド監視（CloudWatch連携）の二通りのアプローチがあり少々混乱しましたが、EBSのディスク使用量の監視が必要で両方を導入することにしました。

ある程度運用が安定したところでメールからSlackへの通信基盤の移行を行い、ログのフロー監視も便利だったのでKIWI Syslogから一部の機能を移行しました。

——最もSite24x7の導入効果が現れているのはどのような部分ですか？

梅澤氏　導入後、目に見えて変わったことは、リアルタイムの監視に加え、週次・月次レポートをベースとした監視に移行したことで、インフラチームと開発チームの垣根が低くなったことです。定期レポートにインフラチームからのコメントを付け、開発チームとSlackで共有されています。開発チームでは、共有されたレポートを元にEC2インスタンスの数やクラスを調整することができます。

これはイベント連携の一例ですが、インフラチームはインシデントにつながる予兆を発見し開発チームにSlackで通知、開発チームは詳細監視でログの内容を確認し問題点を認識、両者が具体的な対応に入るという流れを確立できました。このような対応がひとつのシステムの中で行えるというのがSite24x7の強みだと言えます。

また、弊社では通知が複数のシステムから来る混乱を避けるため、自社開発しているシステムにステータス画面のWeb表示を実装しており、Site24x7のWebサイト監視機能でステータス文字列を定期的にチェックし、異常時には統合してアラームを出すかたちを取っています。

イベント通知などは自動化ツールのZapier経由でサイボウズkintoneに構築した管理情報データベースに情報を残しています。この「営業スタッフはSlackとkintoneですべての状況を把握でき、技術スタッフは必要に応じてSite24x7で詳細を確認できる」というシンプルでわかりやすい環境を作れたことも大きな成果と感じています。

——今後、Site24x7に期待していることはありますか？

梅澤氏　現在では、これまでのオンプレミスやその延長線上にあったEC2インスタンスベースではなく、システムを全体的に再設計し、サーバーレスアーキテクチャによるスケーラブルで堅牢なシステムに刷新しています。サーバーレスアーキテクチャはオンプレミスと比べてノウハウが少ないため試行錯誤しながらの構築となりました。同様に監視ノウハウも不足しており、こちらも手探り状態での構築となりました。

先日、ゾーホージャパン社に相談したところ「『AIベースしきい値』を使うことで指針になるのではないか」とのアドバイスをいただき早速検証を開始しています。この機能は、一定しきい値ベースではなくAIによる異常検出やリソース需要の予想ができるなど、効果に期待しています。