JP2020181272A

JP2020181272A - 管理装置及びプログラム

Info

Publication number: JP2020181272A
Application number: JP2019082308A
Authority: JP
Inventors: 大輔南; Daisuke Minami; 貴啓石福; Takahiro Ishifuku; 惇史福元; Atsushi Fukumoto
Original assignee: MUFG Bank Ltd
Current assignee: MUFG Bank Ltd
Priority date: 2019-04-23
Filing date: 2019-04-23
Publication date: 2020-11-05

Abstract

【課題】現用システムと予備リソースとを運用する際の重複したソフトウェアの稼働を回避するためのクラウドシステムを提供することである。【解決手段】本発明の一態様は、第１のシステムの第１のサーバの監視情報を取得する監視情報取得部と、前記第１のサーバの処理の稼働状態を取得する稼働状態取得部と、前記監視情報と前記稼働状態とに基づき、第２のシステムの第２のサーバに前記処理を復旧させる復旧部と、を有する管理装置に関する。【選択図】図３

Description

本発明は、クラウドシステムに関する。

分散配置された各種計算リソースをインターネットなどのコンピュータネットワークを経由して利用するクラウドコンピューティングが、様々なビジネス分野に導入されてきている。高度な安全性が求められる金融分野においても、クラウドシステムが導入され始めており、銀行の勘定系システムを含む基幹系システムにもクラウドシステムの導入が検討され始めている。

例えば、商用のクラウドシステムでは、図１に示されるように、一定の地理的範囲（アベイラビリティゾーン（ＡＺ）と呼ばれうる）内にデータセンタ、サーバ等から構成される現用システムが構築されると共に、当該現用システムと同一地域（リージョンと呼ばれうる）における地理的に遠隔した場所に予備リソースが構築される（例えば、マルチアベイラビリティゾーンなど）。

このようなマルチＡＺによるクラウドシステムでは、現用システムが配置されるアベイラビリティゾーンと予備リソースが配置されるアベイラビリティゾーンとは地理的に離間し、各アベイラビリティゾーンは物理的に完全に独立したインフラストラクチャ上で稼働している。このため、現用システムに障害又は機能停止が発生した場合、他方の予備リソースによって継続的なサービスの提供が確保される。

特開２０１４−０５３０５０号公報

一方、典型的なマルチＡＺによるクラウドシステムでは、現用システムと予備リソースとの双方のサーバ等に同一のソフトウェアがインストールされ、インストールされるソフトウェアもサーバ数に応じて重複して稼働される。このため、ソフトウェアのライセンス費用や作り込みに係るコストが増大する可能性がある。

上記問題点に鑑み、本発明の課題は、現用システムと予備リソースとを運用する際の重複したソフトウェアの稼働を回避するためのクラウドシステムを提供することである。

上記課題を解決するため、本発明の一態様は、第１のシステムの第１のサーバの監視情報を取得する監視情報取得部と、前記第１のサーバの処理の稼働状態を取得する稼働状態取得部と、前記監視情報と前記稼働状態とに基づき、第２のシステムの第２のサーバに前記処理を復旧させる復旧部と、を有する管理装置に関する。

本発明によると、、復旧処理において自動的に現用システムにおけるソフトウェアの稼働を停止し、予備リソース上で当該ソフトウェアを稼働させることによって、現用システムと予備リソースとを運用する際に重複してソフトウェアが稼働することなくクラウドシステムが運用され、ソフトウェアの利用に係るコストを低減することが可能である。

クラウドシステムにおけるマルチＡＺによる計算リソース配置を示す概略図である。本発明の一実施例によるアベイラビリティゾーン間の復旧処理を示す概略図である。本発明の一実施例によるクラウドシステムを示す概略図である。本発明の一実施例による監視処理を示す概略図である。本発明の一実施例による管理装置のハードウェア構成を示すブロック図である。本発明の一実施例による管理装置の機能構成を示すブロック図である。本発明の一実施例による復旧処理を示す概略図である。本発明の他の実施例による復旧処理を示す概略図である。本発明の一実施例による管理処理を示すフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。

以下の実施例では、クラウドシステムに利用される管理装置が開示される。後述される実施例を概略すると、図２に示されるように、異なるアベイラビリティゾーンに配置された現用システムと予備リソースとを含むクラウドシステムにおいて、監視サーバは、現用システムの疎通状態を監視する。監視サーバによって疎通異常が検知されると、管理装置は、疎通異常が検知された現用システムのサーバにおける実行中の処理（インスタンスなど）の稼働状態を取得し、稼働異常を検知すると、現用システムにおける故障したサーバの利用を停止し、異なるアベイラビリティゾーンに属する予備リソースへの復旧処理を起動する。

これにより、現用システムの正常稼働時には、現用システムのアプリケーション（ＡＰ）サーバ及びデータベース（ＤＢ）サーバのみにおいてソフトウェアが稼働し、予備リソースではソフトウェアは利用されず、予備リソースについては利用に応じた課金はされない。また、予備リソースへの移行時、現用システムにおいてソフトウェアは利用停止されるため、重複した課金を回避できる。

まず、図３を参照して、本発明の一実施例によるクラウドシステムを説明する。図３は、本発明の一実施例によるクラウドシステムを示す概略図である。

図３に示されるように、クラウドシステム１０は、現用システム２０、予備リソース３０、監視サーバ４０、ステータス管理データベース（ＤＢ）５０及び管理装置１００を有する。クラウドシステム１０には、マルチＡＺポリシーが適用され、現用システム２０と予備リソース３０とは、例えば、自然災害等によるリスク分散のために数十〜数百キロ離間されるなど遠隔に配置されると共に、物理的に独立したインフラストラクチャ上に構築される。例えば、このようなクラウドシステム１０は、銀行等の金融機関のシステムにおいても運用されうる。

現用システム２０は、稼働中のＡＰサーバ及びＤＢサーバを含む、あるアベイラビリティゾーンに配備されたサーバ群から構成される。ＡＰサーバ及びＤＢサーバでは、例えば、ライセンス契約したソフトウェアが実行され、ソフトウェアの利用に応じた課金が発生する。

予備リソース３０は、マルチＡＺポリシーによって、現用システム２０と異なるアベイラビリティゾーンに配備されたサーバ群から構成される。本発明によるクラウドシステム１０では、現用システム２０の稼働中は予備リソース３０におけるＡＰサーバ及びＤＢサーバは稼働されず、現用システム２０における障害発生時に復旧処理によって、予備リソース３０のサーバの稼働が開始される。すなわち、現用システム２０の正常稼働中、予備リソース３０では、ソフトウェアは実行されず、ソフトウェアの利用に応じた課金は発生しない。

監視サーバ４０は、現用システム２０のＡＰサーバ及びＤＢサーバの疎通状態を監視する。具体的には、複数の監視サーバ４０が配設され、各監視サーバ４０は、定期的にｎｃ（ｎｅｔｃａｔ）コマンドなどの疎通確認コマンドを現用システム２０のＡＰサーバ及びＤＢサーバに送信することによってＡＰサーバ及びＤＢサーバに対して疎通確認を実行し、確認結果を監視情報としてステータス管理ＤＢ５０に記録する。例えば、疎通状態が所定の（連続）回数以上異常値を示した場合、監視サーバ４０は、該当するサーバに障害が発生していると判断し、疎通異常を示す監視情報をステータス管理ＤＢ５０に通知する。

ステータス管理ＤＢ５０は、監視サーバ４０から取得した監視情報を格納すると共に、管理装置１００に監視情報を提供する。例えば、監視情報は、図４に示されるようなデータ形式によりステータス管理ＤＢ５０に格納されてもよい。図示された具体例では、ホスト名（ｈｏｓｔ）、デバイス名（ｄｅｖｉｃｅ）、配置場所（ａｚ）、疎通状態（ｓｔａｔｕｓ）、復旧状態（ｒｅｃｏｖｅｒｙ）及び関係（ｒｅｌａｔｉｏｎ）のデータ項目が設定され、当該データ形式によって監視サーバ４０から提供された監視情報が格納される。例えば、ｄｅｖｉｃｅが"ＥＣ２"である場合、当該デバイスはＡＰサーバであり、ｄｅｖｉｃｅが"ＲＤＳ"である場合、当該デバイスはＤＢサーバである。また、ｓｔａｔｕｓが"０"である場合、疎通状態が正常であることを示し、ｓｔａｔｕｓが"１"である場合、疎通状態が異常であることを示す。

管理装置１００は、以降において詳述されるように、ステータス管理ＤＢ５０から監視情報を取得し、疎通異常を示すサーバを検出すると、当該サーバにおいて実行されている処理（例えば、インスタンスなど）の稼働状態を確認し、復旧処理の要否を判定する。復旧処理が必要である場合、管理装置１００は、例えば、現用システム２０のＤＢサーバのスナップショットから、予備リソース３０のＤＢサーバを復元し、予備リソース３０においてＡＰサーバ及び／又はＤＢサーバを稼働させる。

ここで、管理装置１００は、典型的には、サーバにより実現され、例えば、図５に示されるようなハードウェア構成を有してもよい。すなわち、管理装置１００は、バスＢを介し相互接続されるドライブ装置１０１、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１０４、インタフェース装置１０５及び通信装置１０６を有する。

管理装置１００における後述される各種機能及び処理を実現するプログラムを含む各種コンピュータプログラムは、ＣＤ−ＲＯＭ（ＣｏｍｐａｃｔＤｉｓｋ−ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）などの記録媒体１０７によって提供されてもよい。プログラムを記憶した記録媒体１０７がドライブ装置１０１にセットされると、プログラムが記録媒体１０７からドライブ装置１０１を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０７により行う必要はなく、ネットワークなどを介し何れかの外部装置からダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータなどを格納する。メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムやデータを読み出して格納する。プロセッサとして機能するＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムやプログラムを実行するのに必要なパラメータなどの各種データに従って、後述されるような管理装置１００の各種機能及び処理を実行する。インタフェース装置１０５は、ネットワーク又は外部装置に接続するための通信インタフェースとして用いられる。通信装置１０６は、外部装置と通信するための各種通信処理を実行する。しかしながら、管理装置１００は、上述したハードウェア構成に限定されるものでなく、他の何れか適切なハードウェア構成により実現されてもよい。

次に、図６〜８を参照して、本発明の一実施例による管理装置１００を説明する。図６は、本発明の一実施例による管理装置１００の機能構成を示すブロック図である。

図６に示されるように、管理装置１００は、監視情報取得部１１０、稼働状態取得部１２０及び復旧部１３０を有する。

監視情報取得部１１０は、現用システム２０のサーバの監視情報を取得する。具体的には、監視情報取得部１１０は、定期的にステータス管理ＤＢ５０にアクセスし、ステータス管理ＤＢ５０から監視情報を取得する。取得した監視情報から疎通異常を示すサーバを検出すると、監視情報取得部１１０は、疎通異常と検出されたサーバを稼働状態取得部１２０に通知する。

稼働状態取得部１２０は、通知されたサーバの処理の稼働状態を取得する。具体的には、監視情報取得部１１０から疎通異常を示すサーバが通知されると、稼働状態取得部１２０は、例えば、クラウドシステム１０におけるＡＷＳコマンドなどの稼働確認コマンドを利用して、通知されたサーバにおいて実行中の処理のインスタンスの稼働状態を確認する。インスタンスが稼働異常を示す場合、稼働状態取得部１２０は、当該サーバに対して復旧処理が必要であると判定し、当該サーバに対して復旧処理を実行するよう復旧部１３０に通知する。

復旧部１３０は、監視情報と稼働状態とに基づき、予備リソース３０のサーバに処理を復旧させる。具体的には、復旧部１３０は、監視情報が疎通異常であって、稼働状態が稼働異常である場合に現用システム２０のサーバに対して復旧処理が必要であると稼働状態取得部１２０から通知されると、当該サーバにおけるインスタンスの実行を停止し、予備リソース３０のサーバにおいて当該インスタンスを起動する。このため、例えば、予備リソース３０のＤＢサーバに現用システム２０のＤＢサーバのスナップショットを転送すると共にＤＢサーバ及び／又はＡＰサーバを起動してもよい。

図７に示される具体例では、監視サーバ４０によって現用システム２０のＡＰサーバとＤＢサーバとの双方に疎通異常が検出され、さらにＡＰサーバとＤＢサーバとの双方に稼働異常も検出された場合、管理装置１００は、現用システム２０のＡＰサーバ及びＤＢサーバの稼働を停止し、現用システム２０のＡＰサーバ及びＤＢサーバから予備リソース３０のＡＰサーバ及びＤＢサーバへのフェイルオーバを実行する。この際、現用システム２０のＤＢサーバのスナップショットが予備リソース３０のＤＢサーバに移入され、当該スナップショット取得時の状態で予備リソース３０のＡＰサーバ及びＤＢサーバが稼働可能になる。

一実施例では、復旧部１３０は、所定の復旧順序により予備リソース３０のサーバにインスタンスを復旧させてもよい。具体的には、当該復旧順序は、サーバ間の依存関係に基づき決定されてもよい。例えば、現用システム２０のＡＰサーバとＤＢサーバとの双方に障害が発生していると判断された場合、予備リソース３０のＤＢサーバを先行して復旧させ、当該復旧後に予備リソース３０のＡＰサーバを復旧させるようにしてもよい。これは、仮に予備リソース３０のＡＰサーバがＤＢサーバに先行して復旧されると、ＡＰサーバはその後にＤＢサーバに接続を開始するが、ＤＢサーバはまだ復旧されていないため、当該接続は失敗することになるためである。

また、図８に示される具体例では、監視サーバ４０によって現用システム２０のＡＰサーバに疎通異常が検出され、さらに当該ＡＰサーバに稼働異常も検出された場合、管理装置１００は、現用システム２０のＡＰサーバの稼働を停止し、現用システム２０のＡＰサーバから予備リソース３０のＡＰサーバへの復旧処理を実行する。この場合、現用システム２０のＤＢサーバは稼働したままとされ、図示されるように、現用システム２０のＤＢサーバと予備リソース３０のＡＰサーバとによって処理が継続される。

しかしながら、本発明による復旧処理は、これに限定されず、例えば、当該サーバを再起動させてもよいし、あるいは、現用システム１０の他のサーバに当該インスタンスを移してもよい。

次に、図９を参照して、本発明の一実施例による管理処理を説明する。図９は、本発明の一実施例による管理処理を示すフローチャートである。当該管理処理は、管理装置１００によって実行され、例えば、当該管理処理を実現するためのプログラムを管理装置１００のプロセッサが実行することによって実現されてもよい。

図９に示されるように、ステップＳ１０１において、管理装置１００は、ステップＳ１０１において、現用システム２０のサーバに疎通異常が発生しているか判定する。具体的には、管理装置１００は、ステータス管理ＤＢ５０に格納される監視サーバ４０からの監視情報を定期的に確認し、疎通異常を示す監視情報を検出すると、疎通異常が検出されたサーバを特定する。

ステップＳ１０２において、管理装置１００は、当該サーバにおける処理に稼働異常が発生しているか判定する。具体的には、ステップＳ１０１において疎通異常が検出されたサーバを特定すると、管理装置１００は、当該サーバにおいて実行されている処理（インスタンス）の稼働状態を判断し、当該サーバにおける処理に稼働異常が発生しているか判定する。

ステップＳ１０３において、管理装置１００は、予備リソース３０のサーバに対して復旧処理を実行し、現用システム２０の異常と判定されたサーバにおける処理を停止すると共に、当該処理を予備リソース３０のサーバにおいて継続する。

以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０クラウドシステム
２０現用システム
３０予備リソース
４０監視サーバ
５０ステータス管理データベース（ＤＢ）
１００管理装置
１１０監視情報取得部
１２０稼働状態取得部
１３０復旧部

Claims

第１のシステムの第１のサーバの監視情報を取得する監視情報取得部と、
前記第１のサーバの処理の稼働状態を取得する稼働状態取得部と、
前記監視情報と前記稼働状態とに基づき、第２のシステムの第２のサーバに前記処理を復旧させる復旧部と、
を有する管理装置。
前記監視情報は、前記第１のサーバに対する疎通確認の結果を含む、請求項１記載の管理装置。
前記第１のサーバに対する疎通確認において異常値が所定回数以上検知されると、前記疎通確認の結果は疎通異常と判定される、請求項２記載の管理装置。
前記取得した監視情報が疎通異常を示すと、前記稼働状態取得部は、前記第１のサーバの処理の稼働状態を取得する、請求項１乃至３何れか一項記載の管理装置。
前記復旧部は、前記監視情報が疎通異常を示すと共に、前記稼働状態が稼働異常を示す場合、前記第２のサーバに前記処理を復旧させる、請求項１乃至４何れか一項記載の管理装置。
前記復旧部は、所定の復旧順序により前記第２のサーバに前記処理を復旧させる、請求項１乃至５何れか一項記載の管理装置。
前記第１のシステムと前記第２のシステムとは、遠隔に配置される、請求項１乃至６何れか一項記載の管理装置。
第１のシステムの第１のサーバの監視情報を取得するステップと、
前記第１のサーバの処理の稼働状態を取得するステップと、
前記監視情報と前記稼働状態とに基づき、第２のシステムの第２のサーバに前記処理を復旧させるステップと、
をコンピュータに実行させるプログラム。