仮想環境を利用している場合に、仮想マシン上のアプリケーションの障害対策をどうしたら良いか。
それも、これまで導入していたアプリケーション保護システムが近い将来に使えなくなることが判明したとき、その後もアプリケーションを守る手立てを維持しなければならないとしたら。
こんな事態に直面したのが、ネットワンシステムズがシステムインテグレーションを手掛けるクラウドサービス提供事業者のA社のシステムだった。
今回の対象となったシステムは、A社のサービスの中でも、サーバーやストレージ、ネットワークなどのハードウエアやインフラをサービスとして提供するIaaS（Infrastructure as a Service）を構成するうちの1つ。
ネットワンシステムズでこの事例を担当した東日本第2事業本部 第2営業部 営業第2チームの鎌田隆志氏は、「アプリケーション保護システムは、エンドユーザーに提供するファイアウォールのポリシーなどをカスタマイズするためのユーザーインタフェース（UI）を提供するアプリケーションを対象としたものです。このアプリケーションを保護するためのシステムの更新を担当しました」と説明する。
UIを提供するアプリケーションや、アプリケーションを動かす仮想マシンに障害が起きても、最大限の可用性を保ちサービスの提供を維持することが求められる。
EOSLで既存システムから移行を検討
後継システムはコストや機能でマッチせず
A社では、これまで稼働してきたアプリケーション保護システムに大きく2つの課題を抱えることになった。既存のアプリケーション保護システムとしては、ベリタステクノロジーズ（シマンテックから分社）が提供する「ApplicationHA」を利用していた。VMware vCenter Server が管理する仮想マシン上で稼働しているアプリケーションを監視するシステムである。
ところが、このApplicationHAが2021年4月にEOSL（End Of Service Life）を迎え、サポートが終了することになった。
A社とネットワンシステムズは、ApplicationHAの後継となるシステムを導入し、アプリケーションの可用性を維持しようと考えた。
ベリタステクノロジーズは、ApplicationHAの後継として高可用性を備えたストレージ仮想化システムの「Infoscale availability」を提供していた。A社とネットワンシステムズは、素直にまずはInfoScaleの採用を検討した。結論としては、A社のアプリケーション保護システムに対してInfoScaleはコストや機能などの複数の点でマッチすることができず、対象から外れることになった。
しかし、何らかの対策は打たなければならない。すでに検討の開始から数カ月が経ち、時間もかけられなくなっていた。A社がUIを提供するアプリケーションはシングルサーバーで稼働している。これをVMwareのクラスターの仕組みを使って、複数の仮想サーバーを立てれば可用性を保つことはできる。
しかし、ネットワンシステムズ東日本第２事業本部第２営業部営業第２チームの荒海氏は、
「今回の製品更新のタイミングでは、時間的にもコスト的にも、サーバー数が増加するようなクラスターへの移行といった工数はかけられませんでした」と振り返る。このほかに独自にスクリプトを組んで可用性を維持する提案もあったが、「開発や保守の側面を考えると、サポート体制がしっかりした製品を使いたかったのです。その意味で、ネットワンシステムズもA社も同じ思いでした」（荒海氏）。
シングルサーバーで可用性を保つ
Single Server Protectionに白羽の矢
シングルサーバーでアプリケーションを保護できる製品はないか、そうした検討の中でサイオステクノロジーが提供するアプリケーション保護ソフト「Single Server Protection（SSP）」が浮かび上がってきた。
SSPはその名の通り、シングルサーバー構成でアプリケーションを監視し、障害時にアプリケーション再起動や仮想マシンの再起動により復旧を試みるソフトウェアである。
ネットワンシステムズでは、サイオステクノロジーから早速SSPの評価版を入手した。A社への提案の期日は、実は評価版の入手の2日後に迫っていた。急ぎ検証したところ、設定に複雑なところがなく、動作もシンプルな考え方であることがわかった。VMwareとの連携機能や対象のアプリケーションとの相性などをチェックし、問題なく動くことを確認し終わるまでの間は、およそ1日半という超特急の作業だった。コストも、当初の想定の範囲内に収まることがわかった。ネットワンシステムズはA社にSSPの導入を提案したところ、A社では他のシステムで同じくサイオステクノロジーが提供しているHAクラスターソフト「LifeKeeper」を導入済みだったこともあり、SSPの導入にゴーサインが出た。
ゾーンごとに3回にわけてSSPへ移行
導入後トラブルは発生なし
A社のアプリケーション監視システムでは、SSPは2種類のサーバーアプリケーションを監視している。いずれもVMwareの仮想サーバー上で稼働するものだ。1つはUIを提供するサーバーアプリケーション。もう1つはファイアウォールの機能やログを中継するサーバーアプリケーションで、1つ目のUIを提供するアプリケーションとファイアウォールの間をつなぐ。
SSPはアプリケーションを監視し、異常を検知したらそのアプリケーションを再起動してリカバリーする。アプリケーションの再起動でも改善されない場合には、SSPからVMware vCenterを経由して仮想マシンを再起動してリセットする。このVMwareと連携して仮想マシンを再起動する機能が、当初検討に上っていたInfoScaleでは実現できなかったが、SSPでは問題なく稼働した。
SSPの基本コンポーネント・機能構成
実際のSSPの導入は、同じクラウド基盤上に3つの案件として順次進められている。まず2020年5月から6月にかけて、最初の複数拠点でのリリースが完了した。ついで、7月から8月にかけて2つ目の複数拠点のリリースを行い、最後に11月にゾーンの増設による新拠点のリリースを行う予定だ。
荒海氏はA社の状況として「リリース以降、現在まで（取材時点は2020年7月中旬）は問題なく動いています。アプリケーションや仮想マシンに障害が起きていないため、SSPの効果を直接は体感していただいていない状況です」と語る。本番の商用環境ではトラブルは発生していないが、検証時点ではトラブルからの復旧を試行している。「障害を検知してからアプリケーションのリカバリーや仮想マシンのリセットまでの動きが従来のシステムよりも速い結果が出ています。復旧のスピードは大事で、SSPを使ったシステムは高い評価を得られました」（荒海氏）。
従来のシステムのEOSLに端を発したA社のアプリケーション監視システムの刷新は、シングルサーバーの可用性を保つソフトのSSPと出会ったことでスムーズに進み、コスト的にも満足がいくものだった。ミッションクリティカルなシステムに比較してコストをかけにくいシングルサーバー運用のシステムで、高い可用性を確保する際にSSPが有効に機能した事例として着目したい。
◆その他のSSP事例はこちら
