実施形態1.
[構成の説明]
以下、本発明の実施形態を、図面を参照して説明する。図1は、本発明による監視システムの第1の実施形態の使用例を示す説明図である。
図1は、本発明による監視システムと外部のコンポーネントとの関係の概要を示す。図1に示すように、本実施形態の監視システム100は、端末200と、コンテナ管理システム300と、コンテナインスタンス400~コンテナインスタンス40N(Nは1以上の整数)とそれぞれ通信可能に接続されている。
また、図1に示すように、コンテナ管理システム300は、コンテナインスタンス400~コンテナインスタンス40Nとそれぞれ通信可能に接続されている。以下、図1に示す各コンポーネントが有する役割を説明する。
上記の課題を解決するために、本実施形態では、高頻度でバージョンが更新される情報システムに対して、ベースラインによる監視を行う監視システム100が使用される。ベースラインは、既知の技術と同様に、同一のオートスケーリンググループに属するコンテナインスタンスの性能情報の平均と分散が利用されて生成される。
本実施形態では高頻度にバージョンが更新される環境としてコンテナ型仮想化技術が利用された情報システムが想定されているため、性能情報の取得対象をコンテナインスタンスとして説明する。
なお、コンテナ型仮想化技術に依存しない場合、既知の技術と同様に、性能情報の取得対象を仮想演算部としてもよい。本実施形態の監視対象は、コンテナ型の仮想化環境に限らず、物理計算機環境、またはハイパーバイザ型の仮想化環境でもよい。
また、本実施形態の監視システム100は、バージョンの更新前後に渡って、ベースラインを再生成せずに継続して監視を実行できることを特徴とする。バージョンの更新は、通常コンテナインスタンスで用いられるローリングアップデートによる更新である。
監視システム100は、ローリングアップデート時に1つずつ起動する新しいバージョンのコンテナインスタンスの性能情報を利用して、旧バージョンのコンテナインスタンスの性能情報を基に生成されたベースラインを逐次更新する。
監視システム100は、バージョンの更新中およびバージョンの更新完了後、逐次更新されたベースラインを使用してコンテナインスタンスを監視することによって、バージョンの更新に合わせてベースラインを再生成せずに済む。
他にも、本実施形態の監視システム100は、監視対象の情報システムから性能情報を定期的に収集して蓄積する機能と、蓄積された性能情報を基にベースラインを生成する機能と、生成されたベースラインを用いて性能劣化を検知し、運用管理者へ通知する機能とを有する。また、監視システム100は、監視対象の情報システムのバージョンの更新状況を把握するために、構成情報を収集および管理する機能を有する。
端末200は、監視システム100が提供するコンポーネントの1つである。図1に示すように、端末200は、監視システム100の外部に配置される。
運用管理者等の監視システム100の利用者は、端末200を介して監視システム100に対する操作、監視システム100が収集した性能情報の参照、および監視システム100が検知した性能劣化の通知の受信等を実行できる。端末200は、監視システム100に対して一般的に利用者から求められる機能を備える。
コンテナインスタンス400~コンテナインスタンス40Nは、監視システム100の監視対象である、1つまたは複数の仮想演算装置である。本実施形態ではコンテナ型仮想化技術の利用が想定されているため、監視対象をコンテナインスタンスとする。
各コンテナインスタンスにおいて、任意のアプリケーションまたはプログラムが稼働する。監視システム100は、コンテナインスタンス400~コンテナインスタンス40Nの各性能情報をそれぞれ収集する。
コンテナ管理システム300は、各コンテナインスタンスの起動、停止、またはオートスケーリング等を実行することによって、各コンテナインスタンスを管理する機能を有する。一般的に、コンテナインスタンスを管理する装置は、オーケストレータ等と呼ばれる。
本実施形態では、コンテナインスタンスを管理する装置を、コンテナ管理システム300とする。コンテナ管理システム300は、各コンテナインスタンスとオートスケーリンググループとをそれぞれ対応付ける情報を有する。
コンテナ管理システム300は、可用性や負荷分散を目的として、所定の機能を有するコンテナインスタンスを複数生成し、生成された数のコンテナインスタンスを維持する機能を有する。また、コンテナ管理システム300は、負荷状況に応じて自動でコンテナインスタンスを増減させるオートスケーリングを行う機能を有する。
コンテナ管理システム300は、オートスケーリングをオートスケーリンググループごとに行う。本実施形態では、各コンテナインスタンスのバージョンの更新は、オートスケーリンググループごとに行われる。また、ベースラインも、オートスケーリンググループに属する全てのコンテナインスタンスの各性能情報が利用されて生成される。
コンテナ管理システム300は、各コンテナインスタンスに対するバージョンの更新要求を受け付け、ローリングアップデートで各コンテナインスタンスのバージョンを更新する。
監視システム100は、コンテナ管理システム300から同一オートスケーリンググループに属するコンテナインスタンスの情報や、コンテナインスタンスの起動状況等を示す情報を収集する。監視システム100は、収集された情報をベースラインの生成や更新に利用する。
上述した通り、本実施形態ではコンテナ型仮想化技術が利用された場合を例に説明する。しかし、監視システム100が情報を収集でき、バージョンの更新がローリングアップデートで行われ、また監視対象の仮想演算部の構成情報が監視システム100から取得できれば、監視対象の演算装置は、物理マシンでもよいし、ハイパーバイザ型仮想化技術で生成された仮想マシンでもよい。なお、仮想演算部の構成情報は、バージョンの更新状況を示す情報やオートスケーリンググループの情報である。
次に、監視システム100が内部および外部に有するコンポーネント、および各コンポーネントが有する役割を、図2を参照して説明する。図2は、第1の実施形態の監視システム100の構成例を示すブロック図である。
図2に示すように、監視システム100は、性能情報受付部101と、性能情報処理部102と、性能異常検知部103と、管理情報受付部104と、構成変更管理部105と、グループ情報管理部106と、ベースライン生成部107と、操作受付部108と、性能情報記憶部109と、グループ情報記憶部110と、構成変更情報記憶部111と、ベースライン記憶部112とを含む。
性能情報受付部101は、性能情報収集部410~性能情報収集部41Nがそれぞれ収集した、コンテナインスタンス400~コンテナインスタンス40Nの各性能情報を受け付ける機能を有する。性能情報受付部101は、受け付けられた各性能情報を性能情報処理部102に渡す。
性能情報処理部102は、性能情報受付部101から性能情報を受け取り、受け取られた性能情報を所定の第1形式に整形してから性能情報記憶部109に格納する機能を有する。
性能情報記憶部109は、監視対象の性能情報を、例えばファイルやデータベースで記憶する機能を有する。性能情報記憶部109は、性能情報を後述する図3に示す形式で保持する。また、提供の要求を受けた場合、性能情報記憶部109は、要求対象の性能情報を要求元に提供する。
性能異常検知部103は、任意のコンテナインスタンスに対して、コンテナインスタンスの性能情報とベースラインの情報とを取得し、コンテナインスタンスの性能値がベースラインの範囲を超過する場合に「性能に異常あり」として端末200へ通知する機能を有する。
また、性能異常検知部103は、ベースラインの範囲(閾値)を超えた値をユーザに通知する。通知されたユーザが異常か否かを判断しやすいように、性能異常検知部103は、ローリングアップデート等が行われるバージョン更新時に、新バージョンのベースラインの範囲と旧バージョンのベースラインの範囲とを合わせてユーザに通知してもよい。
性能異常検知部103は、例えば以下のように性能に異常があるか否かを判断する。変化の度合いが小さい場合、例えば新バージョンの性能情報の傾向は、旧バージョンの性能情報の傾向に類似する。よって、性能値が閾値を超えたら、異常である可能性が高い。
しかし、変化の度合いが大きい場合、新バージョンの性能情報の傾向が旧バージョンの性能情報の傾向から変化した可能性があるため、異常か否かの判断が困難になる。よって、例えばコンテナインスタンスで閾値を超えた性能値が他にもあるか否かが考慮される。他にも閾値を超えた性能値がある場合、異常である可能性が高い。
閾値を超えた性能値が他にない場合、異常か否かを判断することが困難であるため、性能異常検知部103は、例えばローリングアップデートが完了するまで待機する。
管理情報受付部104は、管理情報収集部310が収集した構成情報を受け付ける機能を有する。管理情報受付部104は、バージョン更新等の構成変更の情報を構成変更管理部105へ渡す。また、管理情報受付部104は、稼働中のコンテナインスタンスが属するオートスケーリンググループを示す情報をグループ情報管理部106へ渡す。
構成変更管理部105は、管理情報受付部104から渡された構成変更情報を所定の第2形式に整形してから構成変更情報記憶部111に格納する機能を有する。
構成変更情報記憶部111は、構成変更情報を、例えばファイルやデータベースで記憶する機能を有する。構成変更情報記憶部111は、構成変更情報を後述する図6に示す形式で保持する。また、提供の要求を受けた場合、構成変更情報記憶部111は、要求対象の構成変更情報を要求元に提供する。
グループ情報管理部106は、管理情報受付部104から渡されたオートスケーリンググループとコンテナインスタンスとを対応付ける情報であるグループ情報をグループ情報記憶部110に格納する機能を有する。
グループ情報記憶部110は、グループ情報を、例えばファイルやデータベースで記憶する機能を有する。グループ情報記憶部110は、グループ情報を後述する図4に示す形式で保持する。また、提供の要求を受けた場合、グループ情報記憶部110は、要求対象のグループ情報を要求元に提供する。
ベースライン生成部107は、性能情報に基づいて、オートスケーリンググループごとにベースラインの内容を示すベースライン情報を生成する機能を有する。ベースライン生成部107は、生成されたベースライン情報をベースライン記憶部112に格納する。
ベースライン記憶部112は、ベースライン情報を所定の第3形式で記憶する機能を有する。
操作受付部108は、端末200から操作を受け付ける機能を有する。受け付けられた操作に従って、操作受付部108は、ベースラインの再生成や閾値の変更等を、監視システム100内の各コンポーネントに指示する。
また、図2に示すように、監視システム100の外部に配置されるコンポーネントとして、端末200、管理情報収集部310、および性能情報収集部410~性能情報収集部41Nがある。端末200、管理情報収集部310、および性能情報収集部410~性能情報収集部41Nは、いずれも監視システム100が提供するコンポーネントである。
端末200は、運用管理者等の監視システム100の利用者がアクセス可能な端末である。端末200は、性能異常検知部103からの通知を受信し、受信された通知の内容を参照する機能と、監視システム100を操作する機能とを有する。
端末200が受信した通知を参照した監視システム100の利用者は、コンテナインスタンスにおける性能の異常に対して、コンテナ管理システム300にスケールアウトを実行させる指示を出すという対応をとることができる。
または、監視システム100の利用者は、監視システム100にベースラインを変更させる、アプリケーションを修正させる等の指示を出すという対応をとることができる。よって、利用者は、アプリケーションの性能劣化や異常による影響を抑止できる。
管理情報収集部310は、コンテナ管理システム300が保持するコンテナインスタンスの情報を収集する機能を有する。
性能情報収集部410~性能情報収集部41Nは、各コンテナインスタンスの性能情報をそれぞれ収集する機能を有する。性能情報収集部410~性能情報収集部41Nは、各コンテナインスタンスの内部に配置されてもよいし、外部に配置されてもよい。
以下、監視システム100内の各記憶部が保持する情報を説明する。図3は、性能情報記憶部109に記憶される性能情報の例を示す説明図である。図3に示すように、性能情報は、収集時刻と、インスタンス名と、CPU(Central Processing Unit)使用率と、メモリ使用量とで少なくとも構成されている。
収集時刻は、監視対象のコンテナインスタンスから性能情報が収集された時刻である。また、インスタンス名は、性能情報が収集されたコンテナインスタンスの名称である。インスタンス名は、監視対象を一意に特定できる情報である。
また、CPU使用率(%)およびメモリ使用量(MB)は、監視対象のコンテナインスタンスから収集された性能値である。なお、監視対象の項目は、CPU使用率およびメモリ使用量以外の項目でもよい。監視対象の項目は、任意で指定される。
性能値を収集する監視対象の項目は、運用管理者が任意に定義できる。ただし、同じオートスケーリンググループに属するコンテナインスタンスに対して、性能値が収集される監視対象の項目の種類は、統一されている。
例えば、図3に示す性能情報におけるCPU使用率とメモリ使用量に関して、運用管理者が端末200を介して「Postgres-v9グループに属するコンテナインスタンスからはメモリ使用量を収集しない」と定義できる。同様に、運用管理者が端末200を介して「nginxグループに属するコンテナインスタンスからはディスク使用率(%)の情報を追加で収集する」と定義できる。
しかし、運用管理者は、「CPU使用率を、Nginx-01からは収集するが、Nginx-02からは収集しない」と定義しない。定義しない理由は、ベースラインの生成にあたり、ベースライン生成部107が同一のオートスケーリンググループに属する各コンテナインスタンスの性能情報を利用するためである。
換言すると、同一のオートスケーリンググループに属するコンテナインスタンスから収集される性能情報が異なると、ベースラインの生成に求められる分だけ性能情報が十分に集まらず、ベースラインの生成に時間がかかるリスクがあるためである。
または、特定のコンテナインスタンスから収集された性能情報に偏って生成されたベースラインが利用されると、他のコンテナインスタンスの監視の精度が低下するリスクがあるためである。
図4は、グループ情報記憶部110に記憶されるグループ情報の例を示す説明図である。図4に示すように、グループ情報は、グループ名と、インスタンス名とで構成されている。
グループ名は、上述したオートスケーリングが行われるオートスケーリンググループの名称である。グループ名は、オートスケーリンググループを一意に特定する名称である。
また、インスタンス名は、コンテナインスタンスを一意に特定する名称である。図4に示すインスタンス名は、図3に示すインスタンス名と同一である。
図5は、ベースライン記憶部112に記憶されるベースライン情報の例を示す説明図である。図5に示すように、ベースライン情報は、ベースライン時刻と、グループ名と、CPU使用率と、メモリ使用量とで少なくとも構成されている。
ベースライン情報は、情報システムの負荷状況等には周期性が存在するという前提の下で、所定の期間ごとに生成される。図5に示す例では、負荷状況の周期が1週間と想定されている。
ベースライン時刻は、性能情報の収集時刻とベースラインとを対応させるための時刻である。図5に示す例では、ベースラインが対応する負荷状況の周期が1週間であるため、ベースライン時刻は、曜日と時刻で表示されている。
もしベースラインが対応する負荷状況の周期が1ヶ月であれば、ベースライン時刻は、「○○日 時刻」のように表示される。ベースラインが対応する負荷状況の周期には、任意の周期が指定されてよい。
グループ名は、オートスケーリンググループの名称である。図5に示すグループ名は、図4に示すグループ名と同一である。すなわち、ベースラインは、特許文献2に記載されているベースラインと同様に、同一のオートスケーリンググループに属する各コンテナインスタンスに共有される。
また、CPU使用率およびメモリ使用量は、グループ名が示すオートスケーリンググループに属するコンテナインスタンスに対する、ベースライン時刻におけるベースラインである。ベースラインの計算式は、例えば以下の式である。
式(1)の第2項が、図5に示すσ(標準偏差)である。なお、式(1)におけるxiは、グループ名が示すオートスケーリンググループに属する任意のコンテナインスタンスの、ベースライン時刻における性能値である。
また、式(1)の第1項は、グループ名が示すオートスケーリンググループに属する全てのコンテナインスタンスの、ベースライン時刻における性能値の平均値である。また、nは、グループ名が示すオートスケーリンググループに属するコンテナインスタンスの数である。
なお、ベースラインの生成対象の項目は、CPU使用率およびメモリ使用量以外の項目でもよい。ベースラインは、図3に示す監視対象の項目毎に生成される。
また、バージョン更新時、ベースライン生成部107は、以下の式に従ってベースラインを計算する。
なお、式(2)におけるmは、旧バージョンのコンテナインスタンス数と新バージョンのコンテナインスタンス数の和である。また、式(2)におけるm_oldは、旧バージョンのコンテナインスタンス数である。
ベースライン生成部107は、グループ情報記憶部110から取得された旧バージョンのグループ情報、および新バージョンのグループ情報を基に、稼働しているコンテナインスタンスの情報を取得する。取得した情報を基に、ベースライン生成部107は、ベースラインを更新する。
なお、式(2)において式(1)と異なる項である((m+m_old)/m)は、1から2の間の値をとる。((m+m_old)/m)は、旧バージョンのコンテナインスタンスが多く稼働しているほど2に近づき、新バージョンのコンテナインスタンスが多く稼働しているほど1に近づく。
ベースライン生成部107には、ローリングアップデートの序盤は、新バージョンのコンテナインスタンスの性能情報が少なく、旧バージョンのコンテナインスタンスの性能情報が多い状態でベースラインを更新することが求められる。
よって、ベースラインの幅(図5に示すσ)を最大2倍にすることによって、ベースライン生成部107は、新バージョンの性能情報に対する誤検知を抑制する。しかし、明らかな異常値等は、ベースラインの範囲を超過する。すなわち、監視を継続して実行する性能異常検知部103は、性能の異常を検知できる。
旧バージョンのコンテナインスタンスが全て停止すると、ベースラインの幅は1倍になる。すなわち、ベースラインの計算式(2)が、通常時の計算式(1)と一致する。旧バージョンのコンテナインスタンスが全て停止した時、新バージョンのコンテナインスタンスの性能情報に基づいたベースラインの更新が完了する。
なお、ローリングアップデート等が行われるバージョン更新時にベースラインの計算に使用される計算式は、式(2)以外の計算式でもよい。
図6は、構成変更情報記憶部111に記憶される構成変更情報の例を示す説明図である。図6に示すように、構成変更情報は、最終更新時刻と、変更の種類と、旧バージョングループ名と、新バージョングループ名と、旧バージョンインスタンス数と、新バージョンインスタンス数とで構成されている。
旧バージョングループ名は、構成が変更される前のコンテナインスタンスが属するオートスケーリンググループの名称として定義された名称である。また、新バージョングループ名は、構成変更で新たにリリースされるコンテナインスタンスが属するオートスケーリンググループの名称として定義される名称である。
上述したように、グループ名は、オートスケーリンググループを一意に特定する名称である。すなわち、旧バージョングループ名と新バージョングループ名が異なる場合、旧バージョンのコンテナインスタンスが属するオートスケーリンググループと新バージョンのコンテナインスタンスが属するオートスケーリンググループは異なる。
なお、グループ名でバージョンが区別されないように、構成変更情報が他のバージョンの情報を有してもよい。本実施形態では、図6に示す例のように、グループ名でバージョンが区別される。
また、旧バージョンインスタンス数は、構成変更処理が開始された後、旧バージョングループ名が示すオートスケーリンググループに属し、かつ稼働しているコンテナインスタンスの数である。
また、新バージョンインスタンス数は、構成変更処理が開始された後、新バージョングループ名が示すオートスケーリンググループに属し、かつ稼働しているコンテナインスタンスの数である。
図7は、ローリングアップデート時のコンテナインスタンス数の変化の例を示す説明図である。図7に示す黒色の矩形は、稼働しているコンテナインスタンスを表す。また、図7に示す破線の矩形は、停止しているコンテナインスタンスを表す。
ローリングアップデートは、システムを停止させずにシステムを更新する方法である。具体的には、ローリングアップデートは、新バージョンのコンテナインスタンスを1つずつ起動し、代わりに旧バージョンのコンテナインスタンスを1つずつ停止する。なお、ローリングアップデートが1度に起動または停止させるコンテナインスタンスの数は、1つに限られない。
図7(a)は、更新開始直後のコンテナインスタンスを示す。図7(a)に示すように、ローリングアップデートは、旧バージョンのコンテナインスタンスを1つ停止させた時、新バージョンのコンテナインスタンスを1つだけ稼働させている。
図7(b)は、更新終了直前のコンテナインスタンスを示す。図7(b)に示すように、ローリングアップデートは、新バージョンのコンテナインスタンスを4つ起動させた時。旧バージョンのコンテナインスタンスを1つだけ稼働させている。
上記のように、図6に示す旧バージョンインスタンス数は、図7に示すバージョン更新中に稼働している旧バージョンのコンテナインスタンスの数である。また、図6に示す新バージョンインスタンス数は、図7に示すバージョン更新中に稼働している新バージョンのコンテナインスタンスの数である。
また、変更の種類は、構成変更の種類である。構成変更の種類には、バージョンの更新の他にもスケールアウト、スケールイン、新規追加、および削除等がある。変更の種類には、いずれの情報も指定可能である。本実施形態では、変更の種類は、主にバージョンの更新を意味する。また、最終更新時刻は、構成変更情報が更新された最終時刻である。
[動作の説明]
以下、本実施形態の監視システム100の動作を図8~図10を参照して説明する。
ベースラインを利用した監視システム100の特徴は、バージョン更新時に通常時と異なる方法でベースラインを生成および更新することである。本実施形態の監視システム100は、図8に示すベースラインを利用した性能異常検知処理と、図9に示すバージョン更新時のベースライン更新処理が組み合わせられた処理を行う。
また、バージョン更新中に新バージョンのコンテナインスタンスに異常を検出した時の処理は、図8に示す処理と異なる。よって、図8に示す処理と異なる部分のみを、図10に示すバージョン更新時の性能異常検知処理を参照して説明する。以下、各処理を説明する。
最初に、本実施形態の監視システム100のベースラインを利用した性能の異常を検知する動作を図8を参照して説明する。図8は、第1の実施形態の監視システム100による通常時の性能異常検知処理の動作を示すフローチャートである。
最初に、性能情報収集部410~性能情報収集部41Nは、監視システム100で指定された収集間隔ごとに、監視対象の各コンテナインスタンスからそれぞれ性能情報を収集する(ステップS101)。性能情報は、図3に示す情報を少なくとも含む。
性能情報収集部410~性能情報収集部41Nは、収集された各性能情報を性能情報受付部101に送信する。送信した後、性能情報収集部410~性能情報収集部41Nは、次の収集のタイミングまで待機する。図8に示す性能異常検知処理は、性能情報の収集を契機に、定期的に実行される。
次いで、性能情報受付部101は、性能情報収集部410~性能情報収集部41Nよりそれぞれ受信した各性能情報を、性能情報処理部102に入力する(ステップS102)。
次いで、性能情報処理部102は、性能情報受付部101から入力された各性能情報を性能情報記憶部109に格納する(ステップS103)。
各性能情報を性能情報記憶部109に格納した後、性能情報処理部102は、格納した各性能情報を性能異常検知部103に入力する(ステップS104)。
次いで、性能異常検知部103は、性能情報処理部102から各性能情報が入力されると、入力された性能情報に対応するコンテナインスタンスが属するオートスケーリンググループのグループ名を、インスタンス名を基にグループ情報記憶部110に問い合わせる。問い合わせた後、性能異常検知部103は、グループ情報記憶部110からグループ名を取得する(ステップS105)。
例えば、コンテナインスタンス「Nginx-01」の性能情報が入力された場合、性能異常検知部103は、コンテナインスタンス「Nginx-01」が属するオートスケ-リンググループをグループ情報記憶部110に問い合わせる。問い合わせた後、性能異常検知部103は、グループ「nginx」に属するという通知をグループ情報記憶部110から受ける。
次いで、性能異常検知部103は、ベースライン記憶部112に格納されたベースライン情報を参照し、グループ名と性能情報の収集時刻が適合するベースライン情報を取得する(ステップS106)。
例えば、性能情報に含まれる収集時刻(例えば、水曜21時30分)と、グループ情報記憶部110から取得されたグループ名「nginx」を基に、性能異常検知部103は、ベースライン情報を取得する。
次いで、性能異常検知部103は、取得されたベースライン情報のベースラインと、性能情報の対応する監視対象の項目の値とを、各性能情報に渡ってそれぞれ比較する(ステップS107)。比較することによって、性能異常検知部103は、各性能情報が示す性能項目に異常があるか否かを判断する(ステップS108)。
具体的には、監視対象の項目の値がベースラインの範囲を超えている場合、性能異常検知部103は、監視対象の項目に劣化の兆候や異常があると判断する。例えば、コンテナインスタンス「Nginx-01」のCPU使用率が対応するベースライン情報のCPU使用率「60±3σ」の範囲を超えた場合、性能異常検知部103は、CPU使用率が異常であると判断する。
監視対象の項目に異常がないと判断した場合(ステップS108におけるNo)、監視システム100は、性能異常検知処理を終了する。
監視対象の項目に異常があると判断した場合(ステップS108におけるYes)、性能異常検知部103は、異常があると判断された性能情報を端末200に送信する(ステップS109)。
次いで、監視システム100の利用者は、送信された性能情報を参照して、操作受付部108に異常を解消するための操作を端末200を介して入力する(ステップS110)。操作が入力された後、監視システム100は、性能異常検知処理を終了する。
次に、本実施形態の監視システム100のバージョン更新時のベースラインを更新する動作を図9を参照して説明する。図9は、第1の実施形態の監視システム100によるベースライン更新処理の動作を示すフローチャートである。
なお、通常時のベースラインの生成方法は、上述したベースライン生成部107が有する機能に基づいた方法である。図9は、バージョン更新時のベースライン更新処理を示す。図9に示す処理は、コンテナ管理システム300に対するバージョンの更新要求を契機に開始される。
コンテナ管理システム300において常時稼働している管理情報収集部310は、コンテナ管理システム300がバージョンの更新要求を受け付けたことを検知する。検知した後、管理情報収集部310は、バージョン更新による構成の変更内容と現在の構成内容とを管理情報受付部104に送信する(ステップS201)。
次いで、管理情報受付部104は、受信された情報を構成変更情報とグループ情報に分類する。分類した後、管理情報受付部104は、構成変更情報を構成変更管理部105に入力する(ステップS202)。また、管理情報受付部104は、グループ情報をグループ情報管理部106に入力する(ステップS203)。
次いで、構成変更管理部105は、入力された構成変更情報を構成変更情報記憶部111に格納する(ステップS204)。次いで、グループ情報管理部106は、入力されたグループ情報をグループ情報記憶部110に格納する(ステップS205)。
例えば、グループ情報管理部106は、ローリングアップデートにより起動した新バージョンのコンテナインスタンスのグループ情報をグループ情報記憶部110に追加する。また、グループ情報管理部106は、停止した旧バージョンのコンテナインスタンスのグループ情報をグループ情報記憶部110から削除してもよい。
次いで、構成変更情報記憶部111およびグループ情報記憶部110は、ベースライン生成部107に更新された情報を入力する(ステップS206)。
次いで、ベースライン生成部107は、入力された更新された情報を基に、新規で追加されたコンテナインスタンスの性能情報を性能情報記憶部109から取得する(ステップS207)。
次いで、ベースライン生成部107は、取得された性能情報を基に、式(2)を用いてベースライン情報を更新する(ステップS208)。
次いで、ベースライン生成部107は、更新されたベースライン情報をベースライン記憶部112に格納する(ステップS209)。格納した後、監視システム100は、ベースライン更新処理を終了する。
ベースライン記憶部112は、更新されたベースライン情報を、新バージョンのオートスケーリンググループのベースライン情報として登録する。なお、旧バージョンのコンテナインスタンスが全て停止した場合、ベースライン記憶部112は、旧バージョンのベースライン情報を削除してもよい。
次に、本実施形態の監視システム100の、図9に示すベースライン更新処理で更新されたバージョン更新時のベースライン情報を利用した、新バージョンのコンテナインスタンスの異常を検知する動作を図10を参照して説明する。
図10は、第1の実施形態の監視システム100によるバージョン更新時の性能異常検知処理の動作を示すフローチャートである。なお、通常時の性能異常検知処理は、図8に示す処理である。
ステップS301~ステップS305の各処理は、図8に示すステップS101~ステップS105の各処理とそれぞれ同様である。
次いで、性能異常検知部103は、取得されたグループ名を基に、構成変更情報記憶部111から構成変更情報を取得する(ステップS306)。取得された構成変更情報を基に、性能異常検知部103は、稼働している新バージョンのコンテナインスタンスの数を確認する(ステップS307)。
新バージョンのコンテナインスタンスが1つしか稼働していない場合、稼働しているコンテナインスタンスが1つ目の新バージョンのコンテナインスタンスである。すなわち、新バージョンのコンテナインスタンスの性能情報で、ベースラインはまだ生成されていない。
よって、新バージョンのコンテナインスタンスが1つしか稼働していない場合(ステップS308におけるNo)、性能異常検知部103は、更新されたベースライン情報を取得対象に変更せず、ステップS310の処理に進む。
新バージョンのコンテナインスタンスが2つ以上稼働している場合(ステップS308におけるYes)、性能異常検知部103は、更新されたベースライン情報を取得対象に変更する(ステップS309)。なお、取得対象に変更されるベースライン情報は、図9に示す処理で更新されたベースライン情報である。
ステップS310~ステップS314の各処理は、図8に示すステップS106~ステップS110の各処理とそれぞれ同様である。
なお、ローリングアップデート中、性能値がベースラインの範囲を超えない場合であっても、旧バージョンのベースラインの範囲を超えるようであれば、性能異常検知部103は、異常の可能性があるとしてユーザに通知してもよい。
[効果の説明]
ローリングアップデートによるバージョン更新中等、新バージョンのコンテナインスタンスの性能を監視する際に旧バージョンのコンテナインスタンスの性能情報が利用されて生成されたベースラインが利用される場合がある。
旧バージョンのベースラインが利用される場合、分散の幅が小さい、安定状態にある時間帯の監視では、新バージョンのコンテナインスタンスの性能の傾向の変化により誤った異常が検知される懸念がある。
本実施形態の監視システム100は、バージョン更新中、通常時のベースラインの計算に使用される計算式を変更し、使用されるベースラインの分散の幅を広げる。分散の幅を広げることによって、監視システム100は、性能の傾向や負荷状況の変化を誤って検知しないようにする。
また、単純に分散の幅を広げるだけでは誤った検知を防げても、本来検知された異常が見過ごされてしまうリスクがある。よって、監視システム100は、分散の幅を固定せずに、新バージョンの性能情報がまだ少ない時点や、新バージョンの性能情報が十分集まってきた時点等、ローリングアップデートの進行状況に合わせて更新中のベースラインの分散の幅が動的に変更されるような計算式を用いる。
以上により、高頻度でバージョンが更新されるような情報システムにおいても、運用管理者は、監視システム100を用いて、バージョンの更新を意識することなくベースラインによる監視を継続して実行できる。かつ、バージョンの更新中であっても、運用管理者は、精度を保ったまま監視を実行できる。
コンテナ型仮想化技術やDevOps等の普及により、大規模なサービスのバージョンであっても、ユーザの需要が取り込まれた新しいバージョンが容易にリリースされている。すなわち、バージョンの更新と、更新されたバージョンのリリースが以前よりも高頻度で行われている。
本実施形態の監視システム100を利用する運用管理者は、高頻度でバージョンが更新されるような情報システムの監視において、バージョンの更新を契機に監視の再設定を行わずに済む。運用管理者は、異常を誤検知せずに継続して情報システムを監視できる。
具体的には、高頻度でバージョンが更新される情報システムと情報システムにおいて稼働するアプリケーションの性能状況とをベースラインを用いて監視する監視システム100は、ローリングアップデートによるバージョン更新中にベースラインを自動で更新する。
よって、ユーザは、ベースラインの再生成等、バージョンの更新前またはバージョンの更新後にバージョン更新を契機とする作業を実施することなく、継続して情報システムを監視できる。
特許文献3に記載されているアプリケーション管理システムは、バージョンの更新前のアプリケーションの性能情報とバージョンの更新後のアプリケーションの性能情報とを比較し、バージョン更新により性能に変化が生じているメトリクスを抽出する。
特許文献3に記載されているアプリケーション管理システムは、変化の生じているメトリクスの抽出とユーザへのフィードバックを実行できる。しかし、ユーザには、監視や閾値設定の変更等、実行後に措置をとることが求められる。
本実施形態の監視システム100も、バージョン更新の前後に渡る性能情報を利用している。しかし、監視システム100が利用されると、ローリングアップデートによるバージョン更新に伴う性能情報の変化に対する措置をユーザがとらなくても、自動で適切な監視が継続して実行される。
本実施形態の監視システム100は、ベースラインによる監視が可能な情報システムに対して利用可能である。また、監視システム100は、バージョンが高頻度で更新されるクラウドコンピューティング、またはコンテナ型仮想化技術等が利用された情報システムに対してより利用可能である。
以下、本実施形態の監視システム100のハードウェア構成の具体例を説明する。図11は、本発明による監視システムのハードウェア構成例を示す説明図である。
図11に示す監視システム100は、CPU11と、主記憶部12と、通信部13と、補助記憶部14とを備える。また、ユーザが操作するための入力部15や、ユーザに処理結果または処理内容の経過を提示するための出力部16を備えてもよい。
監視システム100は、図11に示すCPU11が各構成要素が有する機能を提供するプログラムを実行することによって、ソフトウェアにより実現される。
すなわち、CPU11が補助記憶部14に格納されているプログラムを、主記憶部12にロードして実行し、監視システム100の動作を制御することによって、各機能がソフトウェアにより実現される。
なお、図11に示す監視システム100は、CPU11の代わりにDSP(Digital Signal Processor)を備えてもよい。または、図11に示す監視システム100は、CPU11とDSPとを併せて備えてもよい。
主記憶部12は、データの作業領域やデータの一時退避領域として用いられる。主記憶部12は、例えばRAM(Random Access Memory)である。
通信部13は、有線のネットワークまたは無線のネットワーク(情報通信ネットワーク)を介して、周辺機器との間でデータを入力および出力する機能を有する。
補助記憶部14は、一時的でない有形の記憶媒体である。一時的でない有形の記憶媒体として、例えば磁気ディスク、光磁気ディスク、CD-ROM(Compact Disk Read Only Memory)、DVD-ROM(Digital Versatile Disk Read Only Memory)、半導体メモリが挙げられる。
入力部15は、データや処理命令を入力する機能を有する。入力部15は、例えばキーボードやマウス等の入力デバイスである。
出力部16は、データを出力する機能を有する。出力部16は、例えば液晶ディスプレイ装置等の表示装置、またはプリンタ等の印刷装置である。
また、図11に示すように、監視システム100において、各構成要素は、システムバス17に接続されている。
補助記憶部14は、例えば性能情報受付部101、性能情報処理部102、性能異常検知部103、管理情報受付部104、構成変更管理部105、グループ情報管理部106、ベースライン生成部107、および操作受付部108を実現するためのプログラムを記憶している。
また、性能情報記憶部109、グループ情報記憶部110、構成変更情報記憶部111、およびベースライン記憶部112は、例えば主記憶部12で実現される。また、性能情報受付部101、性能異常検知部103、管理情報受付部104、および操作受付部108は、例えば通信部13で実現される。
なお、監視システム100は、ハードウェアにより実現されてもよい。例えば、監視システム100は、内部に図2に示すような機能を実現するLSI(Large Scale Integration)等のハードウェア部品が含まれる回路が実装されてもよい。
また、各構成要素の一部または全部は、汎用の回路(circuitry)または専用の回路、プロセッサ等やこれらの組み合わせによって実現されてもよい。これらは、単一のチップ(例えば、上記のLSI)によって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。各構成要素の一部または全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
各構成要素の一部または全部が複数の情報処理装置や回路等により実現される場合には、複数の情報処理装置や回路等は集中配置されてもよいし、分散配置されてもよい。例えば、情報処理装置や回路等は、クライアントアンドサーバシステム、クラウドコンピューティングシステム等、各々が通信ネットワークを介して接続される形態として実現されてもよい。
次に、本発明の概要を説明する。図12は、本発明による監視システムの概要を示すブロック図である。本発明による監視システム20は、複数の監視対象装置の所定の監視項目の各性能値を基に生成された範囲(例えば、ベースライン)であって、性能値が超過すると所定の監視項目が異常であると判断される範囲を、複数の監視対象装置のうち1つ以上の監視対象装置の各バージョンがそれぞれ更新されると1つ以上の監視対象装置の各性能値を基に更新する更新部21(例えば、ベースライン生成部107)を含む。
そのような構成により、監視システムは、バージョンが更新される情報システムの監視用の閾値を利用者が再設定する手間を省くことができる。
また、監視システム20は、更新された範囲を用いて、各バージョンがそれぞれ更新された1つ以上の監視対象装置を含む複数の監視対象装置の所定の監視項目をそれぞれ監視する監視部(例えば、性能異常検知部103)を含んでもよい。
そのような構成により、監視システムは、高頻度でバージョンが更新される情報システムを、監視の内容を再設定することなく継続して監視できる。
また、監視対象装置は、コンテナインスタンスでもよい。
そのような構成により、監視システムは、コンテナ型の仮想化環境に対応できる。
また、監視部は、同じグループに属する複数のコンテナインスタンスを同一の範囲を用いてそれぞれ監視してもよい。
そのような構成により、監視システムは、オートスケーリングが行われるコンテナインスタンスに対応できる。
また、更新部21は、同じグループに属する複数のコンテナインスタンスのうち2つ以上のコンテナインスタンスの各バージョンがそれぞれ更新されると範囲を更新し、監視部は、更新された範囲を用いて複数のコンテナインスタンスをそれぞれ監視してもよい。
そのような構成により、監視システムは、バージョンが新しい方のコンテナインスタンスの性能情報を基に監視できる。
また、範囲の上限値は、各性能値の平均値に各性能値の標準偏差が加算された値であり、範囲の下限値は、平均値から標準偏差が減算された値であり、更新部21は、1以上2以下の値を標準偏差に乗じることによって範囲を更新してもよい。
そのような構成により、監視システムは、バージョンが古い方のコンテナインスタンスの性能の異常も漏れなく検知できる。