(57)【要約】アプリケーションのバージョンアップを行ったとき、どのメトリックスに影響するのかが把握できない。複数の異なる環境の複数のメトリックス種別を計測する監視プログラム１６００と、アプリケーションの第１バージョン及び第２バージョンをそれぞれデプロイするデプロイメントプログラム１５００と、アプリケーションの第１バージョン及び第２バージョンがそれぞれ動作する環境の複数のメトリックス種別の計測値に基づいて、第１バージョンと第２バージョンとで差が生じているメトリックス種別を判定する分析プログラムと、を有する。
2018037561.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと記憶装置とを有し、コンピュータ上で動作するアプリケーションを監視するアプリケーション監視システムであって、
前記記憶装置は、
監視処理によって計測された、複数の異なる環境の複数のメトリックス種別の計測値と、
デプロイメント処理によって、前記アプリケーションの第１バージョン及び第２バージョンがそれぞれデプロイされた、前記デプロイ後の状態と、を記憶し、
前記プロセッサは、
前記アプリケーションの第１バージョン及び第２バージョンがそれぞれ動作する環境の複数のメトリックス種別の計測値に基づいて、第１バージョンと第２バージョンとで差が生じているメトリックス種別を判定する分析処理を行う、アプリケーション管理システム。
【請求項２】
前記分析処理は、第１バージョンに係る複数種類のメトリックスの計測値と、第２バージョンに係る複数種類のメトリックスの計測値とに基づいて、メトリックス種別ごとに有意差検定を行い、第１のバージョンと第２のバージョンとで有意差があるメトリックス種別を判定する、請求項１記載のアプリケーション管理システム。
【請求項３】
前記プロセッサは、
前記分析処理において、複数のメトリックス種別について定められた優先順位に従って、優先順位が高い所定数のメトリックス種別について、メトリックス種別ごとに有意差検定を行い、第１のバージョンと第２のバージョンとで有意差があるメトリックス種別を特定する、請求項２記載のアプリケーション管理システム。
【請求項４】
前記優先順位は、前記分析処理において、メトリックス種別ごとに有意差があるとされた回数に基づいて定まる、請求項３に記載のアプリケーション管理システム。
【請求項５】
前記プロセッサは、
所定の判定基準に従って、前記複数のメトリックス種別の計測値の中から外れ値を除外する処理をさらに行い、
前記分析処理は、外れ値が除外された複数のメトリックス種別の計測値を用いて行われる、請求項２記載に記載のアプリケーション管理システム。
【請求項６】
前記プロセッサは、
前記分析処理の判定結果を画面に出力するか、または、ＡＰＩにより通知する処理をさらに行う、請求項１記載に記載のアプリケーション管理システム。
【請求項７】
前記分析処理は、前記デプロイ処理により前記アプリケーションの第１バージョンがデプロイされると、第１バージョンより古い第２バージョンを特定して処理を行う、請求項１に記載のアプリケーション管理システム。
【請求項８】
プロセッサと記憶装置とを有し、コンピュータ上で動作するアプリケーションを監視するアプリケーション監視システムが行う方法であって、
前記プロセッサが所定のプログラムを実行することにより、
複数の異なる環境の複数のメトリックス種別を計測し、その計測値を前記記憶装置に記憶する監視処理と、
前記アプリケーションの第１バージョン及び第２バージョンをそれぞれデプロイし、前記デプロイ後の状態を前記記憶装置に記憶するデプロイ処理と、
前記アプリケーションの第１バージョン及び第２バージョンがそれぞれ動作する環境の複数のメトリックス種別の計測値に基づいて、第１バージョンと第２バージョンとで差が生じているメトリックス種別を判定する分析処理と、を行う方法。
【請求項９】
プロセッサと記憶装置とを有し、コンピュータ上で動作するアプリケーションを監視するアプリケーション監視システムのためのコンピュータプログラムであって、
前記コンピュータプログラムが前記プロセッサに実行されると、
複数の異なる環境の複数のメトリックス種別を計測し、その計測値を前記記憶装置に記憶する監視処理と、
前記アプリケーションの第１バージョン及び第２バージョンをそれぞれデプロイし、前記デプロイ後の状態を前記記憶装置に記憶するデプロイ処理と、
前記アプリケーションの第１バージョン及び第２バージョンがそれぞれ動作する環境の複数のメトリックス種別の計測値に基づいて、第１バージョンと第２バージョンとで差が生じているメトリックス種別を判定する分析処理と、が行われるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高頻度で更新されるアプリケーションの監視方法に関する。
【背景技術】
【０００２】
ＤｅｖＯｐｓの普及に伴い、従来は困難であった１日１０回以上といった高頻度のアプリケーションデプロイが現実的となりつつある。【０００３】
特許文献１では、同一のバージョンのアプリケーションが複数デプロイされるスケールアウト型の構成になっていることを前提に、複数デプロイされている一部のインスタンスのみを新しいバージョンに置き換え、ロードバランサによってリクエストの一部を新しいバージョンのインスタンスに振り分けるカナリアテストと呼ばれる手法が記載されている。本文献では、新しいバージョンのインスタンスをカナリアインスタンスと呼称し、オリジナルのアプリケーションが稼働しているインスタンスから取得したメトリックスのベースラインと、カナリアインスタンスから取得したメトリックスとの相対性能値を算出し、グラフ表示することにより、新バージョンの効果を評価する手段を提供する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許出願公開第２０１４／０２８２４２２号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
システムの運用管理者は、高頻度で行われるアプリケーションの変更に応じて、関連するメトリックス（性能情報）の閾値変更や、アラート設定を見直す必要がある。さらに、運用管理者は、デプロイされた新バージョンのアプリケーションの効果や副作用をアプリケーション開発者（開発者）にフィードバックする必要がある。これを行うためには、アプリケーションのバージョンアップを行うことにより、どのメトリックスに影響がでるのかを把握する必要がある。【０００６】
しかし、監視しなければならないメトリックス種別の数が非常に多いので、開発者ですらアプリケーションを変更することにより影響が生じる可能性のあるメトリックスを事前に判断することは難しい。
【課題を解決するための手段】
【０００７】
本発明の一つの実施態様に従うアプリケーション管理システムは、プロセッサと記憶装置とを有し、コンピュータ上で動作するアプリケーションを監視する。前記記憶装置は、監視処理によって計測された、複数の異なる環境の複数のメトリックス種別の計測値と、デプロイメント処理によって、前記アプリケーションの第１バージョン及び第２バージョンがそれぞれデプロイされた、前記デプロイ後の状態と、を記憶する。前記プロセッサは、前記アプリケーションの第１バージョン及び第２バージョンがそれぞれ動作する環境の複数のメトリックス種別の計測値に基づいて、第１バージョンと第２バージョンとで差が生じているメトリックス種別を判定する分析処理を行う。
【発明の効果】
【０００８】
本発明により、数多くのメトリックスの中から、アプリケーションのバージョンの違いに起因するメトリックスを抽出することが出来る。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態におけるＩＴシステムの論理構成図である。
【図２】本発明の実施形態におけるＩＴシステムの物理構成図である。
【図３】本発明の実施形態においてデプロイメントプログラム１５００が稼働する管理計算機システム２２００Ａの構成図である。
【図４】本発明の実施形態において監視プログラム１６００が稼働する管理計算機システム２２００Ｂの構成図である。
【図５】本発明の実施形態において分析プログラム１７００が稼働する管理計算機システム２２００Ｃの構成図である。
【図６】本発明の実施形態の管理計算機システム２１００Ａのストレージメディア２２５０に格納されるデプロイメント管理テーブル６０００の構成図である。
【図７】本発明の実施形態の管理計算機システム２１００Ｂのストレージメディア２２５０に格納されるメトリックステーブル７０００の構成図である。
【図８】本発明の実施形態の管理計算機システム２１００Ｃのストレージメディア２２５０に格納されるアプリケーション管理テーブル８０００の構成図である。
【図９】本発明の実施形態の計算機システム２１００Ｃにおける分析プログラム１７００の処理手順を示すフローチャートである。
【図１０】本発明の実施形態の計算機システム２１００Ｃにおいて、分析プログラム１７００が表示する分析結果表示ＧＵＩである。
【発明を実施するための形態】
【００１０】
以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素およびその組み合わせのすべてが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。なお、以降の説明では「ａａａテーブル」等の表現にて本発明の情報を説明するが、これら情報はテーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名称」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。
【００１１】
以降の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリおよび通信ポート（通信デバイス、管理Ｉ／Ｆ、データＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部またはすべては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。また、各種プログラムは、ハイパーバイザ型もしくはコンテナ型といった仮想化環境上で実行されてもよい。
【００１２】
以下、本発明の一実施形態について図面を用いて説明する。
【００１３】
図１は、本実施形態におけるＩＴシステム１０００の論理構成図である。
【００１４】
実施形態におけるＩＴシステム１０００は、複数のプログラムが所定のハードウェアで動作することにより実現される。ＩＴシステム１０００では、バージョンが異なる複数のアプリケーションプログラム（例えば、バージョンＮとバージョンＮ−１）が同時に動作している。例えば、アプリケーションプログラム１１０１、１１０２は、バージョンＮ−１（第１のバージョン）のアプリケーションＡのインスタンスである。アプリケーションプログラム１２０１、１２０２はバージョンＮ（第２のバージョン）のアプリケーションＡのインスタンスである。本実施形態では、各々のバージョンにおいて複数のインスタンスが稼働しているものとしているが、各々のバージョンにおいて一つ以上のインスタンスが稼働していればよい。なお、本実施形態では二つのバージョンが混在しているが、三つ以上のバージョンが混在していてもよい。
【００１５】
また、本実施形態では、デプロイされているアプリケーションプログラムがすべて同じ種類のアプリケーションプログラムＡであるが、二種類以上のアプリケーションがデプロイされていてもよい。
【００１６】
デプロイメントプログラム１５００は、アプリケーションプログラムをデプロイするプログラムである。本実施形態では、ＩＴシステム１０００において一つのデプロイメントプログラムが稼働するものとしているが、複数のデプロイメントプログラムが稼働していてもよい。
【００１７】
監視プログラム１６００は、ＩＴシステムの監視を行い、監視結果であるメトリックスの計測値を蓄積するプログラムである。本実施形態では、ＩＴシステム１０００において一つの監視プログラムが稼働するものとしているが、複数の監視プログラムが稼働していてもよい。この場合、複数の監視プログラムが互いに異なるメトリックスを計測してもよいし、複数の監視プログラムが互いに異なるアプリケーションについてメトリックスを計測する構成でもよいし、複数の監視プログラムが互いに異なるロケーションのメトリックスを計測する構成でもよい。
【００１８】
分析プログラム１７００は、監視プログラム１６００が収集したメトリックスの計測値を分析して、アプリケーションのバージョンの違いに起因して計測値に差が生じているメトリックスの種別を抽出するプログラムである。本実施形態では一つの分析プログラムが稼働するものとしているが、複数の分析プログラムが稼働していても構わない。この場合、複数の分析プログラムが互いに異なるアプリケーションの分析を行うようにしても良い。
【００１９】
図２は、本発明の実施形態におけるＩＴシステム１０００の物理構成図２０００である。
【００２０】
実施形態におけるＩＴシステム１０００は、一台以上の計算機システム２２００、２２１０と、一台以上の管理計算機システム２１００、２１０１と、データネットワーク２３００と、管理ネットワーク２４００とを有する。計算機システム２２００、２２１０および管理計算機システム２１００、２１０１は一台以上であれば何台であっても構わない。また計算機システム２２００、２２１０および管理計算機システム２１００、２１０１は、別種の計算機システムとしているが、同種の計算機システムとしても構わない。
【００２１】
計算機システム２２００は、ネットワークＩ／Ｆ２２１０、プロセッサ２２２０、入出力デバイス２２３０、メモリ２２４０、ストレージメディア２２５０、管理Ｉ／Ｆ２２６０および内部ネットワーク２２７０を有する。ネットワークＩ／Ｆ２２１０は、データネットワーク２３００とのＩ／Ｆである。入出力デバイス２２３０は、キーボード、マウスまたはディスプレイなどのユーザに対する入出力を受け付けるデバイスでよい。管理Ｉ／Ｆ２２６０は、管理ネットワーク２４００とのＩ／Ｆである。内部ネットワーク２２７０は、計算機システム２２００内の構成要素間を相互に接続するネットワークである。
【００２２】
本実施形態では、アプリケーションプログラムがデプロイメントプログラム１５００によりストレージメディア２２５０に格納され、実行時にプロセッサ２２２０によってメモリ２２４０にロードされ実行されることを想定しているが、それに限定されず、アプリケーションの一部またはすべてが、ストレージメディア２２５０上で実行されても構わない。また、ストレージメディア２２５０は、例えば、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）またはＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）などの不揮発性のメディアでよいし、メモリ２２４０は、例えば、ＤＲＡＭ（Ｄｙｎａｍｉｃ  ＲＡＭ）などの揮発性のメディアでよい。しかし、計算機システム２２００がメモリ２２４０を有しないときは、ストレージメディア２２５０上ですべてのプログラムが実行され、管理テーブルが読み書きされる形態であっても構わない。また、アプリケーションプログラムが実行されるのは、物理計算機２２００、２２０１上に構築されたハイパーバイザ型の仮想化環境であってもよいし、コンテナ型の仮想化環境であってもよい。
【００２３】
管理計算機システム２１００は、プロセッサ２１２０、入出力デバイス２１３０、メモリ２１４０、ストレージメディア２１５０、管理Ｉ／Ｆ２１６０および内部ネットワーク２１７０を備える。入出力デバイス２１３０は、キーボード、マウスまたはディスプレイなどの、ユーザの入出力を受け付けるデバイスでよい。管理Ｉ／Ｆ２１６０は、管理ネットワーク２４００とのＩ／Ｆである。内部ネットワーク２１７０は、計算機システム２１００内の構成要素間を相互に接続するネットワークである。
【００２４】
データネットワーク２３００は、複数台の計算機システム２２００、２２０１を接続し、それらの間でデータを送受信するためのネットワークである。管理ネットワーク２４００は、複数台の計算機システム２２００、２２０１と管理計算機２１００、２１０１とを接続し、それらの間で管理データを送受信するためのネットワークである。本実施形態では、データネットワーク２３００と管理ネットワーク２４００とは別々のネットワークであるが、同一のネットワークであっても構わない。またこれらのネットワークは、例えば、Ｅｔｈｅｒｎｅｔでよいが、それに限定されず他の形態であっても構わない。
【００２５】
図３、図４、図５は、それぞれ、デプロイメントプログラム１５００が稼働する管理計算機２１００Ａ、監視プログラム１６００が稼働する管理計算機２１００Ｂ、及び分析プログラム１７００が稼働する管理計算機２１００Ｃの構成図である。
【００２６】
管理計算機２１００Ａ〜Ｃは、いずれもプロセッサ２１２０、入出力デバイス２１３０、メモリ２１４０、ストレージメディア２１５０、管理Ｉ／Ｆ２１６０および内部ネットワーク２１７０を備える。管理計算機２１００Ａ、２１００Ｂ、２１００Ｃは物理計算機そのものでも構わない。あるいは、物理計算機に構築されたハイパーバイザ型の仮想化環境であっても、コンテナ型の仮想化環境であっても本発明を実施することが出来る。
【００２７】
図３は、本発明の実施形態においてデプロイメントプログラム１５００が稼働する管理計算機２１００Ａの構成図である。
【００２８】
管理計算機２１００Ａはストレージメディア２１５０を有する。ストレージメディア２１５０には、デプロイメントプログラム１５００、アプリケーションリポジトリ１５１０およびデプロイメント管理テーブル６０００が格納される。
【００２９】
本実施形態では、ストレージメディア２１５０に格納されたデプロイメントプログラム１５００が、実行時にプロセッサ２１２０によってメモリ２１４０にロードされ実行されることを想定しているが、それに限定されず、それらのうちの一部またはすべてが、ストレージメディア２１５０上で実行されても構わない。また、本実施形態では、ストレージメディア２１５０はＨＤＤまたはＳＳＤなどの不揮発性のメディアでよいし、メモリ２１４０はＤＲＡＭなどの揮発性のメディアでよい。しかし、管理計算機２１００Ａがメモリ２１４０をしないときは、ストレージメディア２１５０上ですべてのプログラムが実行され、管理テーブルが読み書きされる形態であっても構わない。
【００３０】
なお、アプリケーションリポジトリ１５１０やデプロイメント管理テーブル６０００は別の管理計算機に格納されていても構わない。また、デプロイメントプログラム１５００は、後述する監視プログラム１６００または分析プログラム１７００と同一の管理計算機上で稼働する形態であってもよい。
【００３１】
図４は、本発明の実施形態において監視プログラム１６００が稼働する管理計算機２１００Ｂの構成図である。
【００３２】
ストレージメディア２１５０には監視プログラム１６００、メトリックステーブル７０００が格納される。
【００３３】
本実施形態では、ストレージメディア２１５０に格納された監視プログラム１６００が、実行時にプロセッサ２１２０によってメモリ２１４０にロードされ実行されることを想定している。しかしながら、このような態様に限定されず、監視プログラム１６００の一部またはすべてが、ストレージメディア２１５０上で実行されても構わない。また、本実施形態では、ストレージメディア２１５０はＨＤＤまたはＳＳＤなどの不揮発性のメディアでよいし、メモリ２１４０はＤＲＡＭなどの揮発性のメディアでよい。しかし、管理計算機２１００Ｂがメモリ２１４０を有しないときは、ストレージメディア２１５０上ですべてのプログラムが実行され、管理テーブルが読み書きされる形態であっても構わない。
【００３４】
図５は、本発明の実施形態において分析プログラム１７００が稼働する管理計算機２１００Ｃの構成図である。
【００３５】
管理計算機２１００Ｃはストレージメディア２１５０を有する。ストレージメディア２１５０には分析プログラム１７００、アプリケーション管理テーブル８０００およびメトリックス集約テーブル９０００が格納される。
【００３６】
本実施形態では、ストレージメディア２１５０に格納された分析プログラム１７００が、実行時にプロセッサ２１２０によってメモリ２１４０にロードされ実行されることを想定している。しかしながら、このような態様には限定されず、分析プログラム１７００の一部またはすべてが、ストレージメディア２１５０上で実行されても構わない。また、本実施形態では、ストレージメディア２１５０はＨＤＤまたはＳＳＤなどの不揮発性のメディアでよいし、メモリ２１４０はＤＲＡＭなどの揮発性のメディアでよい。しかし、管理計算機２１００Ｃがメモリ２１４０を有しないときは、ストレージメディア２１５０上ですべてのプログラムが実行され、管理テーブルが読み書きされる形態であっても構わない。
【００３７】
図６は、本発明の実施形態の計算機システム２２００Ａのストレージメディア２２５０に格納されるデプロイメント管理テーブル６０００の構成図の一例である。デプロイメント管理テーブル６０００は、アプリケーションのバージョンと、各バージョンのアプリケーションがデプロイされている計算機を対応付ける。デプロイメント管理テーブル６０００は、デプロイメントプログラム１５００によって更新される。例えば、デプロイメントプログラム１５００がデプロイを行うと、そのデプロイの内容がデプロイメント管理テーブル６０００に反映される。
【００３８】
デプロイメント管理テーブル６０００は、同図に示すように、アプリケーションカラム６１１０と、バージョンカラム６１２０と、デプロイ先カラム６１３０とを備える。
【００３９】
アプリケーションカラム６１１０には、デプロイされたアプリケーションの種別が格納される。
【００４０】
バージョンカラム６１２０には、デプロイされたアプリケーションのバージョンが格納される。バージョンとして、ハッシュ値のような新旧が比較できない値が格納されるケースもある。例えば３５ｄｆ９である。この場合、アプリケーション管理テーブル８０００にてアプリケーションがアプリケーションリポジトリ１５１０に格納されたコミット日時を管理し、コミット日時が新しいものを新しいバージョンとみなしてもよい。
【００４１】
デプロイ先カラム６１３０には、アプリケーションがデプロイされた計算機を識別する識別子が格納される。識別子は、例えば、ＩＰアドレスまたはホスト名でよいし、それ以外の識別子でも構わない。また、デプロイ先計算機は物理計算機であっても論理計算機であっても構わない。
【００４２】
行６０１０から行６０５０のそれぞれは、デプロイされたアプリケーションの情報を表す。例えば、行６０１０は、ＡｐｐｌｉｃａｔｉｏｎＡという名称でバージョン番号Ｖｅｒ．１のアプリケーションが、４つのデプロイ先の計算機にデプロイされていることを示す。
【００４３】
なお図６の例では、デプロイ先が二つもしくは四つとなっているが、デプロイ先の数はこれに限定されず、一つ以上であればいくつでも構わない。
【００４４】
図７は、本発明の実施形態の計算機システム２２００Ｂのストレージメディア２２５０に格納されるメトリックステーブル７０００の構成図の一例である。メトリックステーブル７０００は、監視プログラム１６００が取得したメトリックスの計測値を格納したものである。
【００４５】
メトリックステーブル７０００は、取得元カラム７２１０と、種別カラム７２２０と、メトリックスカラム７２３０とを有する。
【００４６】
取得元カラム７２１０には、メトリックスの計測値を取得した計算機の識別子が格納される。
【００４７】
種別カラム７２２０には、メトリックス種別が格納される。
【００４８】
メトリックスカラム７２３０には、監視プログラム１６００が取得したメトリックスの計測値が格納される。メトリックスカラム７２３０の最上位行には、各計測値を取得した時刻が格納されてよい。なお、メトリックステーブル７０００はメトリックスカラム７２３０を一つ以上有している。各メトリックスカラム７２３０には異なる時刻に観測されたメトリックスの観測値が格納されて良い。
【００４９】
行７０１０から行７１１０のそれぞれは、メトリックスのデータである。例えば、行７０１０は、取得元１９２．１６８．１．１から、種類がＣＰＵＵｓａｇｅであるメトリックスの値を計測し、その計測値が２／１０  ９：３０には６０、２／１０  ９：４２には５３であったことを示している。
【００５０】
なお本実施形態では、すべてのメトリックスは同一時刻にまとめて取得することを前提としている。しかしながら、メトリックスの取得方法はそれに限定されない。例えば、それぞれのメトリックスを個別に取得し、取得した時刻とともにメトリックスカラムに取得した値を格納してもよい。
【００５１】
図８は、本発明の実施形態の計算機システム２２００Ｃのストレージメディア２２５０に格納されるアプリケーション管理テーブル８０００の構成図の一例である。アプリケーション管理テーブル８０００は、アプリケーションのバージョンと、各バージョンのアプリケーションが稼働している計算機とを対応付ける。アプリケーション管理テーブル８０００はデプロイメント管理テーブル６０００と類似しているため、その差分を中心に説明する。
【００５２】
アプリケーション管理テーブル８０００は、同図に示すように、アプリケーションカラム８１１０と、バージョンカラム８１２０と、デプロイ先カラム８１３０とを備える。各カラム８１１０−８１３０には、デプロイメント管理テーブル６０００が有している情報がコピーされてもよい。
【００５３】
バージョンカラム８１２０の行８０３０および行８０３５には、デプロイメント管理テーブル６０００との差分がある。すなわち、バージョンカラム８１２０は、フィーチャーフラグに関する情報をさらに有してもよい。フィーチャーフラグ（フィーチャートグルと呼称されることもある）とは、アプリケーションプログラムの特定の機能が有効であるか否かを示すフラグである。例えば、アプリケーションプログラムに対して付加された新機能について、ＡＰＩやＣＬＩが外部からその機能を稼働（ＯＮ）させたり、停止（ＯＦＦ）させたりするときに、フィーチャーフラグがその新機能の現在の状態（ＯＮ／ＯＦ）を示す。
【００５４】
したがって、あるアプリケーションにフィーチャーフラグがセットされている場合、そのアプリケーションの新機能が有効になっているかどうかはデプロイ時には決まらない。行８０３０および行８０３５は、いずれもＶｅｒ．２５のアプリケーションＢに関する情報であるが、行８０３０はＦｅａｔｕｒｅＡと呼ばれる新機能が無効になっており、行８０３５はＦｅａｔｕｒｅＡと呼ばれる新機能が有効になっているという違いがある。
【００５５】
図９は、本発明の実施形態の計算機システム２２００Ｃにおける分析プログラム１７００の処理手順を示すフローチャートである。分析プログラム１７００は、二つのバージョンのアプリケーションが動作する環境から取得した複数のメトリックスの測定値に基づいて二つのバージョンの測定値を比較し、有意差のあるメトリックスを抽出するプログラムである。
【００５６】
本実施形態における分析プログラム１７００は、常駐型プログラムとして実装されてよい。例えば、分析プログラム１７００がイベントの到着を待って、到着したイベントの種別に応じて適切な処理を行う態様でよいし、別の実装形態であっても構わない。例えば、分析プログラム１７００がイベントに応じてオンデマンドで処理を実行するのではなく、定期的に本処理を実行することも可能である。
【００５７】
ステップ９０１０でプログラムが動作を開始する。ステップ９０２０において、分析プログラム１７００がイベントの発生の有無を確認する。ここで、イベントは、例えば、新しいアプリケーションのデプロイでよい。分析プログラム１７００は、デプロイメントプログラム１５００から通知を受けてイベントの発生を検出しても良いし、分析プログラム１７００がデプロイメントプログラム１５００にポーリングをイベントの発生を検出してもよい。また、分析プログラム１７００は、アプリケーション管理テーブル８０００のフィーチャーフラグがＯＮになったことをイベントとして検出しても良い。さらに、アプリケーションの開発者などからの依頼などの外部からの特定の入力をイベントとしても構わない。
【００５８】
ステップ９０２０において、イベントが検出されなかった場合、ステップ９０３０において一定時間ＷＡＩＴし、ステップ９０２０に戻る。
【００５９】
ステップ９０２０において、例えば新しいアプリケーションのデプロイなどのイベントが検出されると、分析プログラム１７００はステップ９０４０においてメトリックスの取得元を決定する。ここでは、比較を行う複数のアプリケーションのバージョンに対応する複数のメトリックスの取得元を決定する。
【００６０】
まずは、ステップ９０２０でデプロイが検出されると、分析プログラム１７００が、そのデプロイに係るアプリケーションの情報をアプリケーション管理テーブル８０００に追加する。例えば、分析プログラム１７００は、新しくデプロイされたアプリケーションのアプリケーション名がアプリケーションカラム８１１０に、バージョンがバージョンカラム８１２０に、デプロイ先がデプロイ先カラム８１３０に、新規の行として追加する。ここでデプロイ先カラム８１３０に格納されたアプリケーションのデプロイ先が、メトリックスの第１の取得元となる。
【００６１】
次に、分析プログラム１７００は、比較対象となるアプリケーションとそのバージョンを決定する。例えば、分析プログラム１７００が、ステップ９０２０でデプロイが検出されたアプリケーションと同じアプリケーションで、ステップ９０２０でデプロイが検出されたバージョンより古いバージョン（例えば一つ前のバージョン）を、アプリケーション管理テーブル８０００を参照して特定しても良い。例えば、ステップ９０２０で検知したアプリケーションとそのバージョンが、ＡｐｐｌｉｃａｔｉｏｎＡ、Ｖｅｒ．２であった場合、これと比較すべき一つ前のアプリケーションのバージョンはアプリケーション管理テーブル８０００を参照することによりＶｅｒ．１と定まる。この比較対象のバージョンのアプリケーションのデプロイ先が、メトリックスの第２の取得元である。
【００６２】
ステップ９０５０において、分析プログラム１７００は、ステップ９０４０において決定されたメトリックスの取得元から複数種類のメトリックスについて、それぞれ一以上の測定値を取得し、メトリックス集約テーブル９０００に格納する。メトリックス集約テーブル９０００の構成は、メトリックステーブル７０００と同一であり、取得元カラム、種別カラム、メトリックスカラムを有しても良い。メトリックスはある一定期間を定めて、その期間のメトリックスを収集してもよいし、一度だけメトリックスを収集してもよい。
【００６３】
なお、ステップ９０５０で取得するメトリックス種別を制限しても良い。例えば、メトリックス種別の数が多くなったり、デプロイの頻度が多くなったりすると、デプロイが検出されるごとに、すべてのメトリックス種別に対して有意差の有無の判定を行うと計算量が多く、計算負荷が課題となるおそれがある。そこで、分析プログラム１７００がステップ９０５０で取得するメトリックス種別に優先順位を付けて、優先順位の高い所定数のメトリックス種別についてだけ計測値を取得するようにしても良い。例えば、過去に有意差があると判定されたメトリックス種別の優先順位を高めても良い。例えば、過去に有意差があると判定された回数が上位のメトリックス種別（例えば、上位Ｎ種別）を対象としても良い。ここで、Ｎは固定値でもよいし、運用管理者が指定しても構わない。あるいは、メトリックス種別の優先順位は、運用管理者が指定してもよい。
【００６４】
このように、有意差の判定の対象となるメトリックス種別を制限することにより計算量を削減することが出来る。
【００６５】
なお、全メトリックス種別について有意差の判定を行うことと、一部のメトリックス種別について有意差の判定を行うことを、時間または条件によって切り替えてもよい。
【００６６】
ステップ９０６０において、分析プログラム１７００は、ステップ９０５０で取得したメトリックスの測定値の中から外れ値を除外する。外れ値か否かの判定は、例えば、バージョン別、及びメトリックス種別別に行っても良い。
【００６７】
例えば、それぞれのメトリックス種別の複数の計測値を一つの母集団として、分析プログラム１７００が、各母集団のデータが各々正規分布に従うか否かの検定(正規性の検定)を実施する。正規性の検定手法にはＡｎｄｅｒｓｏｎ−Ｄａｒｌｉｎｇ検定、Ｄ’Ａｇｏｓｔｉｎｏ−Ｐｅａｒｓｏｎ検定、Ｋｏｌｍｏｇｏｒｏｖ−Ｓｍｉｒｎｏｖ検定、Ｓｈａｐｉｒｏ−Ｗｉｌｋ検定、及びＪａｒｑｕｅ−Ｂｅｒａ検定などいろいろな手法がある。正規性があるときは、９５％信頼区間(ｍｅａｎ±２ＳＤ)を逸脱する値を外れ値とするとしてよい。正規性がないときは、中央値とＩＱＲ（ｉｎｔｅｒｑｕａｒｔｉｌｅ  ｒａｎｇｅ）を用い、小さい方の外れ値は第一四分位点−１．５ＩＱＲ以下、大きい方の外れ値は第三四分位点＋１．５ＩＱＲとしてもよい。しかし、これらの手法に限定されず、他の手法で外れ値を除外しても構わない。
【００６８】
ステップ９０７０において、外れ値が除外された複数メトリックス種別の測定値群について、バージョン間での有意差の有無を判定する。
【００６９】
有意差検定を行う前に、分析プログラム１７００は、各母集団のデータが各々正規分布に従うか否かの検定(正規性の検定)を実施してもよい。ステップ９０６０にて実施した正規性の検定結果をここで利用してもよい。分析プログラム１７００は、正規性があるときは、例えばt-検定を行い、正規性がないときは、例えばノンパラメトリック検定であるＭａｎｎ−ＷｈｉｔｎｅｙのＵ検定もしくは符号検定を行う。しかし、これらの手法に限定されず、他の手法で有意差の判定を行っても構わない。
【００７０】
これらの検定により、有意差があるか否かを検定することが可能である。なお、有意差検定する際に、運用管理者などに有意水準(危険率)を指定させてもよい。有意水準とは、有意差がないものを有意差があると誤判定する可能性である。例えば、ｐ＝０．０５とした場合、５％の確率で有意差がないものを有意差があると誤判定してしまう。そのため、誤判定を減らしたいのであればｐ＝０．０１といった小さい値を指定すればよいし、誤判定があっても有意差のある可能性のあるメトリックスを抽出したいのであれば、ｐ＝０．１といった大きな値を指定すればよい。
【００７１】
ステップ９０８０において、ステップ９０７０において有意差があったと認められたメトリックス種別を、図１０に示す分析結果表示ＧＵＩ１００００に出力する。
【００７２】
分析結果表示ＧＵＩ１００００については後述する。なお、表示の方法は図１０の方式によらず、他の方法でも構わない。
【００７３】
また、有意差の判定結果の利用方法は表示するだけに限定されない。例えば、メールやチャットなどのプログラムで送信してもよいし、対策を実行する他のプログラムなどから利用しても構わない。
【００７４】
ステップ９０９０において、ユーザからの終了指示の有無をチェックする。終了指示がなければ、ステップ９０２０に戻る。終了指示があれば、ステップ９１００にて処理を終了する。
【００７５】
なお、本実施形態では二つのバージョン間で、の有意差があるメトリックス種別を検出する処理について説明したが、三つ以上のバージョンを比較することも可能である。例えば、多重比較検定といった手法を用いることにより、複数のバージョン間のメトリックスの有意差の有無を検出することが可能である。
【００７６】
図１０は本発明の実施形態の計算機システム２２００Ｃにおいて、分析プログラム１７００が表示する分析結果表示画面１００００の一例である。
【００７７】
分析結果表示画面１００００は、分析日時フィールド１００１０と、アプリケーションフィードル１００２０と、旧バージョンフィールド１００３０と、新バージョンフィールド１００４０と、有意水準フィールド１００５０と、有意差が検出されたメトリックスフィールド１００６０とを有する。
【００７８】
分析日時フィールド１００１０は、分析を実施した日時を表示する。
【００７９】
アプリケーションフィードル１００２０は、分析の対象としたアプリケーション名を表示する。
【００８０】
旧バージョンフィールド１００３０は、分析の対象としたアプリケーションのうち、古い方のバージョンのバージョンを識別する識別子を表示する。
【００８１】
新バージョンフィールド１００４０は、分析の対象としたアプリケーションのうち、新しい方のバージョンのバージョンを識別する識別子を表示する。
【００８２】
有意水準フィールド１００５０は、有意差の判定をする際に用いた有意水準を表示する。
【００８３】
有意差が検出されたメトリックスフィールド１００６０は、有意差があると判定したメトリックスの一覧を表示するテーブルである。
【００８４】
有意差が検出されたメトリックスフィールド１００６０は、メトリックスカラム１０１４０と、p値カラム１０１５０と、平均値カラム１０１６０、１０１７０と、分散カラム１０１８０、１０１９０とを有する。
【００８５】
メトリックスカラム１０１４０は、有意差があると判定されたメトリックスを表示する。
【００８６】
p値カラム１０１５０は、p値を表示する。p値とは2群に差がないという帰無仮説が成立する確率である。
【００８７】
平均値カラム１０１６０、１０１７０は各々のバージョンの各メトリックスの平均値を表示する。
【００８８】
分散カラム１０１８０、１０１９０は各々のバージョンの各メトリックスの分散を表示する。
【００８９】
行１０１１０から行１０１３０は有意差があると判定されたメトリックスである。例えば、行１０１１０はＶｅｒ．５．０とＶｅｒ．５．１のＡｐｐｌｉｃａｔｉｏｎＣのＣＰＵ  Ｕｓａｇｅに有意差があったことを示している。p値が０．０２５ということは、二つのバージョン間でＣＰＵ使用率に有意差がないという確率は２．５％であり、したがって、９７．５％の確率で有意差があるということを示している。また、各々のバージョンのＣＰＵ  Ｕｓａｇｅについて、平均と分散を表示している。
【００９０】
ＯＫボタン１０２００を押下すると、この画面は終了する。
【００９１】
なお、本実施形態では有意差のあったメトリックスに関する情報を、平均や分散といった統計情報として結果を表示したが、本発明はこれに限定されない。例えば、判定に用いた期間の各メトリックスのグラフを表示してもよい。
【符号の説明】
【００９２】
１０００  ＩＴシステムの論理構成、１１０１   アプリケーションプログラム、１２００  アプリケーションプログラム、１５００  デプロイメントプログラム、１６００  監視プログラム、１７００  分析プログラム、２０００  ＩＴシステムの物理構成
【図１】
2018037561.tif 000003
【図２】
2018037561.tif 000004
【図３】
2018037561.tif 000005
【図４】
2018037561.tif 000006
【図５】
2018037561.tif 000007
【図６】
2018037561.tif 000008
【図７】
2018037561.tif 000009
【図８】
2018037561.tif 000010
【図９】
2018037561.tif 000011
【図１０】
2018037561.tif 000012
【国際調査報告】
2018037561.tif 000013
2018037561.tif 000014