この記事ではHULFTをクラウド移行する際にオンプレミスと同等の可用性を保てないという課題をいかに手間なく解決するのか、その方法をユースケースを交え、いくつかのパターンについて解説します。
HULFTのクラウドでの利用状況
さまざまな業界で利用されているHULFTですが、以前の記事でもご紹介していますが、クラウドでの利用が進んでいます。
HULFTはシステムの特性上、夜間も各所と通信を行っています。HULFTはファイルの整合性確認機能などが提供されていますが、サービスそのものが止まってしまうと整合性確認はもちろん、ファイル転送自体もできなくなってしまいます。夜間にファイル転送機能が止まってしまうと、翌日の業務に支障が出るケースも少なくありません。翌朝出社した担当者の方はリカバリ対応に追われることになります。
そうならないためにオンプレミスと同等の可用性をしっかり担保したいというご相談はサイオステクノロジーにも沢山いただいており、実際に弊社が提供するHAクラスタリングソフトウェアの LifeKeeperで HULFTを冗長化いただくケースも2019年から比較しても2倍に伸びています。
システムのリプレイス時にはクラウドファーストで検討するのが当たり前になりつつある昨今ですので、クラウド利用時の注意点や解決方法について見ていきましょう。
HULFTを安心してクラウドで利用するには
前述のようにシステムのリプレイスの際、まずはクラウドで検討を行うというのはもはや当たり前のようになってきていますが、その際に挙がる課題の一つが可用性の部分です。
「クラウドを利用すればシステムの可用性はクラウドベンダーが責任を持って担保してくれますよね」といったお声を良くいただきます。
IaaSでクラウドを利用する場合の責任共有モデルについては認知が進んでいますがそれでもなおクラウドベンダーのSLAがシステム全体の可用性を担保しているように受け止められるケースもあるようです。
そこで、責任共有モデルを改めて確認しておきたいと思います。
ミドルウェア、アプリケーションレイヤーはユーザが責任
上記のようにミドルウェア、アプリケーションレイヤーはユーザが責任を持って設計・運用する必要があります。オンプレミス環境をそのままクラウドリフトした場合、システム全体での可用性を考えた際オンプレミス同様にはなりません。
「ソフトウェア障害」と「管理面・人的要因」によるシステム障害が全体の3分の2
ソフトウェア障害が増えているという事は「金融機関のシステム障害に関する分析レポート」からも見て取ることができます。※https://www.fsa.go.jp/news/r2/20210630/system_01.pdf P32 より
金融庁のレポートを例にあげましたが、この傾向は特定の業種に限った話では無いと考えられます。つまりユーザ側でしっかり可用性について考慮しておかなければ、システム障害がビジネスインパクトが大きい事案に発展してしまうことは容易に想像頂けると思います。
Availability Zone （可用性ゾーン）全域の障害
ニュースでたまに耳にするクラウドのシステム障害、データセンター（Availavility Zone）全体に及ぶような障害の場合、サービスを継続することはできません。
そこで、障害が伝搬しない Availability Zoneを跨いだ冗長化対策が選択肢の一つになりますが、AZを跨ぐということはサブネットも跨ぐことになり、実装には高度な制御が必要になってしまいます。
解決策は！？
そこでこうした課題に対して様々なシステム障害対策が検討されますが、コストと求められる稼働率のバランスが良いとされるHAクラスタリングソフトウェアの導入です。
弊社もLifeKeeperというHAクラスタリングソフトウェアを提供しており、これらの課題を解決する手段として多くの企業で採用頂いています。サードパーティー製品を利用することで、AZを跨ぐHA構成も自前よりははるかに短期間で構築することができ、クラウド環境での利用実績がある点も安心材料となります。
可用性担保の選択肢（ユースケース）
ではここからは具体的なユースケースを紹介していきます。
某小売業のお客様の例（店舗とのデータ受け渡しの例）
老朽化した基幹システムをクラウドリフト、その際にシステムの稼働率を担保するためにクラウド標準の可用性だけでは対応しきれないと判断。自社で要件に合った稼働率を担保するために追加で開発を行うかサードパーティー製品を利用するか検討、構築期間や実績などから信頼性の観点でLinux版のLifeKeeper + DataKeeperを選択いただきました。
AWS上でAZを跨いだ構成でHAクラスターを構築し、稼働率の課題を解決いただきました。
某流通業界のお客様例
こちらも社外とやり取りされている例になりますが、HULFTが稼働しているサーバーはWindowsです。こちらのお客様の場合、クラスタリングはWSFC（Windows Server Failover Cluster）を利用し、DataKeeperでデータミラー構成を取ることによって共有ストレージ無しでHAクラスターを構築していただいています。
WSFCを利用しオンプレミスのようにクラウドで冗長化構成がとれる点を評価いただきました。
クラウド上での課題はHAクラスターのクォーラム ディスクで使用する共有ストレージを持つのが難しかった点でしたが、DataKeeperを使うことで共有ストレージが不要になり、クラウド環境でもHAクラスター構成をシンプルかつ低コストで実現いただきました。
某金融業のお客様の例
HAクラスターを構築するほどミッションクリティカルではないけれど、停止すると業務に使用がでるサブシステムのサーバとHULFTの保護に Single Server Protection を採用いただきました。
Single Server Protection は冗長化構成ではなく、その名の通りサーバ上のOSやアプリケーションに問題が発生した場合にEC2インスタンスの再起動を試み、サービスが停止しないようにするためのソフトウェアです。
HAクラスターほどの可用性にはなりませんがコストを抑えつつ、責任共有モデルでユーザの責任とされるミドルウェアやアプリケーションの保護にご利用いただいています。
基幹システムにはHAクラスター、サブシステムはシングルサーバーの保護といったように、可用性要件に応じて使い分けることで、コストと運用負荷をうまく両立して頂いています。
対応表
LifeKeeperは以下のような構成に対応しています。
※1：一般的なクラウド環境は共有ストレージがサポートされていません。当表では、ベアメタル環境は物理環境と見なしてあります。
※2：WSFCはWindows Server標準のHAクラスター機能のため、Linux環境では使えません。
※3：サポートされるクラウド環境については下記よりお問い合わせください。
※4：Windows版はv8.8.0以降対応しています。
HULFTの保護をさらに容易にする方法
これまで見てきたように、クラウドでの利用が増加しているHULFTですが、クラウド利用の場合の課題と解決方法はご理解頂けたと思います。
HAクラスタリングソフトウェアを利用することで、自前で実装するより手間なくHA構成を実現することができますが、LifeKeeperはさらに構築を簡単にするARKというものが用意されています。
一般にHAクラスタリングソフトウェアはクラスター化したいアプリケーションごとに制御を行うスクリプトを準備する必要があります。LifeKeeperにはARK（Application Recovery Kit）というオプション製品が用意されていて下の図のように「スクリプト設計」、「スクリプトテスト」、「スクリプト実装」の工程を省くことができます。
LifeKeeperではHULFTと合わせて利用されることの多い、SAPやJP1、OracleをはじめAWSやOCIのARKをご用意しています。
ARKはウィザード形式で値は自動入力済みなので人的入力ミスを減らすことにも繋がります。
まとめ
HULFTに限らずクラウド移行すれば、システムの安定稼働はクラウドベンダーが全て責任を持ってくれるわけではなく、ソフトウェアの安定稼働がユーザ責任であることはお判りいただけたかと思います。
システム障害の原因の3分の2を占めるとも言われる、「ソフトウェア障害」と「管理面・人的要因」これらのリスクをいかに効率よく減らすかはIT担当者の重要なミッションとなります。
そしてこういったリスクの大部分をLifeKeeperやARKでカバーできますので、HULFTをクラウド移行する際には是非ご検討頂ければと思います。
ご検討に役立つ資料も豊富にご用意していますので是非ダウンロードください！
