Datadogに自動復旧機能を付加し、ウェブサーバーのトラブル対応を大きく改善!【SIOS社内事例】

    今回は、サイオス社内での運用事例をご紹介します。

    サイオステクノロジーでは、事業部ごとにウェブサーバーを持っており、これは非効率でメンテナンスも不十分でした。それを何とかしようと、DatadogとAppKeeperを活用したメンテナンスに名乗りを上げた、ウェブ関連でコーポレートサポートを担当している山根秀樹氏に話を聞きました。

    サイオスでは、公開しているウェブサーバーをDatadogで監視し、AppKeeperで自動復旧を行うという、DatadogとAppKeeperを連携させたサービスを活用しています。Datadogを利用中の方、またはAmazon EC2上でアプリケーションを稼働させている方のシステム運用改善の参考になれば幸いです。

    業者任せで管理が行き届いていなかった運用

    ―今回、このサービスを社内のウェブサーバーに導入した背景を教えてください。

    山根:全体の流れとしては、以前に外部の業者の方から、弊社の全社ウェブサイト(www.sios.com および sios.jp)へのSEO対策の提案があったので「そういえばうちが保持しているウェブサイトはどういう状態なのだろう?」と実態把握と棚卸しに着手したのがきっかけです。

    それまではwww.sios.com および sios.jpに関する作業はコンテンツ・インフラ含めてすべて同じ業者に委託していたのですが、委託先でのインフラ運用は費用が高額であるのにもかかわらず決して十分とは言えない状態でした。さらにこの実態調査の最中に残念ながら運用での問題が起きたのと対応が満足いくものではなかった為、サイトをAWSに移行・使用OSやCMSなどのソフトウェアも最新のものに更新するなどして改善を図り、すべて内製に切り替えました。

    また、運用サイト全体の整理整頓を始め、セキュリティ対策・メンテナンス等も私がすべて担当することになったので、各事業部で個々にサーバーを借りて立ち上げていたブログなどのサイトを集約し、不要サイトをシャットダウンして運用効率化とシステムの更新を実施しました。

    概ね順調に推移していたのですが、ある時に運用しているMovable Type(MT)を使おうとしたらエラーが出ている、と社内のユーザーから報告を受けたのです。これはMTパッケージのアップデートがトリガだったのですが、「MTのアップデート時に併せてデータベーススキーマを手動で更新しなければいけない」という仕様によるものでした。

    MTは静的なHTMLを吐き出すCMSですので、この問題によってサイトの閲覧自体には影響はなかったのですが、ユーザーから指摘を受けるまで動作異常に気づけなかったのは問題です。そこで対応として監視サービスを導入し、状態異常があった際にはSlackで通知するようにしました。

    …ただ、当たり前なのですが監視は「通知まで」です。その異常通知を受け取った担当者、つまり「私」が対応する必要があります。加えてSlackの通知に気づくまでにはタイムラグがありますし、休暇などでSlackを見ていないこともありえます。異常が発生した際、可能であればシステムのセルフヒーリングによって自動的に復旧してほしい…そう思うのは自然ですよね?

    「あぁ、そういえばうちの会社にはそういうサービスがあったのでは?」と運良く思い出したので、AppKeeper開発担当に相談して導入を実施したのです。

    システムトラブル時の課題

    ―導入前の課題は?

    山根:シンプルな死活監視とSlackによる通知は実施していましたが、担当者が24時間365日対応できるわけではありません。そのため、問題が発生した場合に数時間程度気づかなかったり、外出中で対応できないということが発生する可能性がありました。

    導入効果は初動対応と事後調査

    ―ソリューションを実際に導入して、どのような効果がありましたか。

    山根:導入効果は2つありました。1つ目は、異常時の初動対応が短時間でできるということを担保できる点です。ウェブサーバー(NGINX)・CMS(Movable Type)やDBのサービスの再起動はAppKeeperがやってくれます。AppKeeperを使うことにより、トラブル対応の初動が「数時間」から「数分」レベルまで短縮できます。「担当者が不在で、数時間対応できません」という状況から、「とりあえず不具合が起きたサービスを再起動して様子を見る」という状態にまで持っていけるのは大きなメリットです。

    多くの場合サービス再起動程度で対処できますし、たとえ対処療法的なものだったとしてもログの解析で原因を掴んで処置するまでの時間が稼げます。

    2つ目は、それまで使っていた監視ツールは死活監視と通知のみだったのですが、Datadogは後から時系列で数字を追っていけるのが非常に良かったです。応答速度の低下なども定量的に把握でき、具体的に時間帯や低下レベルについて提示できることで次のアクションがとりやすいです。また、Datadogがレスポンスタイムなどの必要なデータを取得し続けてくれるので、事後対応(原因調査)がしやすいという点も大きな強みだと思います。

    担当者のKPIについて話をする際に必要となる数値がパッとわかるのも良いですね。この辺りは後からひねり出そうとすると結構な手間になってしまいますので。

    今回社内で使用しているシステム構成は以下のようになっています。

    導入については、シンプルではあるものの多少迷う部分もあったので、まだ改善の余地はあるように思います。AppKeeperはインターフェースが良く言えばシンプル、悪く言えば味気ないと私は感じました。この辺りは好みによるかも知れません。次にやるべき操作がもう少し直感的にわかると嬉しいです。チュートリアルモード、またはドキュメントや操作説明の動画への誘導があると尚いいですね。Datadogの方は選択肢が多すぎて結構難しいので、ベーシックモードとアドバンストモードのようなものがあるといいなと思いました。

    費用は、AppKeeperが1インスタンスあたり1カ月約3600円(5円/時間)、Datadogが1インスタンスあたり1カ月5ドル(年払い)です。短時間での対応を担保するために人員を増やしたりシステムを自前で組むことを考えるとリーズナブルだと思います。

    ―今後、このサービスの監視対象にしたいと思っているものなどはありますか。

    山根:費用対効果を見ながら、PVを集めているシステムや社内的に重要なシステムにも拡大していけたらいいなと思います。また、Datadogによる外形監視以外のトリガーでAppKeeperが動作するといった拡張ができればいいですね。

    最後に

    今回利用した、SIOS AppKeeperは、Amazon EC2上のアプリケーションを監視し、Cloudwatchでは難しいサービスの再起動までを自動で行えるサービスです。Amazon EC2上のアプリケーションの自動復旧に興味がありましたら、ぜひSIOS AppKeeperのHPにて機能や事例をご覧ください。

     

    SNSでもご購読できます。