特許 6706321 サービス呼び出し情報処理の方法及びデバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6706321

(24)【登録日】2020年5月19日

(45)【発行日】2020年6月3日

(54)【発明の名称】サービス呼び出し情報処理の方法及びデバイス

(51)【国際特許分類】

   G06F 11/07 20060101AFI20200525BHJP

   G06F 11/34 20060101ALI20200525BHJP

【ＦＩ】

   G06F11/07 151

   G06F11/07 140A

   G06F11/34 147

【請求項の数】13

【全頁数】28

(21)【出願番号】特願2018-522941(P2018-522941)

(86)(22)【出願日】2016年10月25日

(65)【公表番号】特表2019-502191(P2019-502191A)

(43)【公表日】2019年1月24日

(86)【国際出願番号】CN2016103173

(87)【国際公開番号】WO2017076188

(87)【国際公開日】20170511

【審査請求日】2018年7月4日

(31)【優先権主張番号】201510734236.2

(32)【優先日】2015年11月3日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】505032849

【氏名又は名称】アリババ グループ ホウルディング リミテッド

(74)【代理人】

【識別番号】100097320

【弁理士】

【氏名又は名称】宮川 貞二

(74)【代理人】

【識別番号】100131820

【弁理士】

【氏名又は名称】金井 俊幸

(74)【代理人】

【識別番号】100155192

【弁理士】

【氏名又は名称】金子 美代子

(74)【代理人】

【識別番号】100100398

【弁理士】

【氏名又は名称】柴田 茂夫

(72)【発明者】

【氏名】シャ，ユーツァイ

(72)【発明者】

【氏名】チャン，アルポン

(72)【発明者】

【氏名】ワン，ジエ

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２００５−１９０２７７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１２／０１８８８７９（ＵＳ，Ａ１）

【文献】 尾居 愛子 外３名，「サービスチェイニングにおける故障原因推定方法の一検討」，電子情報通信学会２０１５年総合大会講演論文集 通信２，一般社団法人電子情報通信学会，２０１５年 ２月２４日，ｐ．５２８

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／２８−１１／３６

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ １５／００

Ｇ０６Ｎ ３／００−９９／００

(57)【特許請求の範囲】

【請求項1】

サービス呼び出しチェーンを処理する方法であって：
分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するステップであって、各サービス呼び出しチェーンが、順次に呼び出される１つ以上のサービスノードを含み、各サービス呼び出しチェーン内の前記１つ以上のサービスノードの呼び出し順序は同じであり、且つ前記１つ以上のサービスノードのトポロジは同じである、ステップ（Ｓ１）と；
前記１つ以上のサービス呼び出しチェーンに従って対応するサービス呼び出しモデルを構築するステップ（Ｓ２）であって、前記サービス呼び出しモデルは、前記１つ以上のサービス呼び出しチェーンと同じトポロジ構造及び前記サービスノード呼び出し順序を有する、ステップと；
任意の呼び出しエラーが前記１つ以上のサービスノードに関連付けられているか否かを検出するために、前記サービス呼び出しモデルに従って前記サービス呼び出しチェーンのデータを分析するステップ（Ｓ３）と；を備える、
サービス呼び出しチェーンを処理する方法。

【請求項2】

前記１つ以上のサービス呼び出しチェーンを取得する前記ステップは：
分散型システムからサービス呼び出しログ情報を取得するステップ（Ｓ１１）と；
前記サービス呼び出しログ情報から前記１つ以上のサービス呼び出しチェーンを抽出するステップであって、前記サービス呼び出しチェーンのそれぞれは、順次に呼び出される１つ以上のサービスノードを備える、ステップ（Ｓ１２）と；を備える、
請求項１に記載の方法。

【請求項3】

サービス呼び出しチェーンを処理する方法であって：
分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するステップであって、各サービス呼び出しチェーンが、順次に呼び出される１つ以上のサービスノードを含む、ステップ（Ｓ１）と；
前記１つ以上のサービス呼び出しチェーンにおける１つのサービス呼び出しチェーンに従って対応するサービス呼び出しモデルを構築するステップ（Ｓ２）と；
任意の呼び出しエラーが前記１つ以上のサービスノードに関連付けられているか否かを検出するために、前記サービス呼び出しモデルに従って前記サービス呼び出しチェーンを処理するステップ（Ｓ３）と；を備え、
前記サービス呼び出しモデルを構築する前記ステップは：
前記サービス呼び出しチェーンに集約処理を実行することにより、前記対応するサービス呼び出しモデルを構築するステップであって、前記サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、前記サービス呼び出しトポロジのそれぞれは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される、ステップを備える、
サービス呼び出しチェーンを処理する方法。

【請求項4】

前記サービス呼び出しチェーンを処理する前記ステップは：
前記対応するサービス呼び出しチェーンを前記１つ以上のサービス呼び出しトポロジにおける１つのサービス呼び出しトポロジに従って処理するステップを備える、
請求項３に記載の方法。

【請求項5】

前記サービス呼び出しトポロジにクリーニング操作を実行するステップを更に備える、
請求項４に記載の方法。

【請求項6】

クリーニング済みのサービス呼び出しトポロジに従って、前記対応するサービス呼び出しチェーンを処理するステップを備える、
請求項５に記載の方法。

【請求項7】

前記クリーニング操作は：
前記サービス呼び出しトポロジ内の所定のサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内にあって、呼び出し結果情報を戻さないサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップであって、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内で低頻度で用いられるサービスノードの累積出現回数が所定の低頻度使用の閾値よりも少ない又はこれと等しい、ステップと；
前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップであって、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内で前記低頻度で用いられるサービスノードの累積出現回数は前記所定の低頻度使用の閾値よりも少ない、又はこれと等しく、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内の、前記低頻度で用いられるサービスノード以外の別のサービスノードの累積出現回数は、所定の高頻度使用の閾値よりも多い、又はこれと等しい、ステップと；のうちの少なくとも１つを備える、
請求項５に記載の方法。

【請求項8】

前記サービス呼び出しモデルを構築する前記ステップは：
前記サービス呼び出しチェーン内の前記サービスノードの呼び出しフィードバック情報に関連した前記サービス呼び出しチェーンに集約処理を実行することにより、対応するサービス呼び出しモデルを構築するステップを備え、ここで、前記サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、前記サービス呼び出しトポロジのそれぞれは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される、
請求項３乃至請求項７のいずれか１項に記載の方法。

【請求項9】

前記サービス呼び出しチェーンを処理する前記ステップは：
前記サービス呼び出しチェーンそれぞれのサービスノードの前記呼び出しフィードバック情報に従って、前記サービス呼び出しトポロジに対応する前記１つ以上のサービス呼び出しチェーンについての統計を収集するステップ（Ｓ３１）と；
対応する統計結果に従って、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーンを監視するステップ（Ｓ３２）と；を備える、
請求項８に記載の方法。

【請求項10】

対応する統計結果に従って、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーンを監視する前記ステップは：
所定の継続時間比較規則に基づいて、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内の前記サービスノードそれぞれの対応する統計結果と前記呼び出しフィードバック情報との間の差異を特定するステップ（Ｓ３２１）と；
前記差異が所定の変動閾値を超えると、前記差異に対応する前記サービス呼び出しチェーンについての警告情報を生成するステップであって、前記警告情報は前記差異に対応するサービスノードの所在を特定する、ステップ（Ｓ３２２）と；を備える、
請求項９に記載の方法。

【請求項11】

前記分散型サービスシステムは、当該システムの複数の構成要素に分配されるサービスを提供するように構成されたシステムを備える、
請求項１乃至請求項１０のいずれか１項に記載の方法。

【請求項12】

前記１つ以上のサービスノードは、１つのサービスまたは前記分散サービスシステムにおいて呼び出される１つのサービスに関連する１つの機能を備える、
請求項１乃至請求項１１のいずれか１項に記載の方法。

【請求項13】

請求項１乃至請求項１２のいずれか１項に記載の方法を実行するように構成された複数のモジュールを備える、
サービス呼び出しチェーンを処理する装置。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、２０１５年１１月３日に提出され「サービス呼び出し情報処理の方法及びデバイス」と題された中国特許出願第２０１５１０７３４２３６．２号の優先権を主張し、上記中国特許出願は参照によってその全体が本願に組み込まれる。

【0002】

本願はコンピュータ技術分野に関し、特に、サービス呼び出し情報処理の技術に関する。

【背景技術】

【0003】

インターネットの発展と共に、サービスプラットフォームやオンラインショッピングモールのようなネットワークベースのアプリケーションの規模は徐々に拡大し、分散型サービスシステムが利用されるようになっている。ますます多くのアプリケーションサービスがより緊密に相互接続され、相互依存しているため、分散型システムにおける呼び出し関係は煩雑である。サービスを実行すると、内部要因と外部要因の関係から、同じサービスがいつも呼び出されるとは限らない。そのため、サービス実行工程中にエラーが生じた場合、エラーの所在特定と監視が困難である。既存の技術では、エラーは、その所在が、ログに基づいて又はサービス呼び出しパスを追跡することにより特定され、更に、サービス実行時に失敗したサービス呼び出しを監視することにより監視される。

【0004】

しかし、ログに基づく又はサービス呼び出しパスの追跡による既存のエラー所在特定方法は複雑で、時間がかかり、精度が低い。通常、失敗したサービス呼び出しはエラー発生後に監視されるため、エラーを防止することも、事前にエラー警告を発することもできない。

【発明の概要】

【0005】

本願の目的は、分散型システム内でのサービス実行中に、エラーの所在を特定し、サービスの実行を監視し、警告を発するために、サービス呼び出し情報処理の方法及びデバイスを提供することである。

【0006】

上記目的を達成するために、本願は、分散型システムにおけるサービスの実行中に、エラーを発見し、サービスを実行し、警告を発するサービス呼び出し情報処理方法を提供する。この方法は：
分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するステップであって、各サービス呼び出しチェーンが、順次に呼び出される１つ以上のサービスノードを含む、分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するステップと；
サービス呼び出しチェーンに従って対応するサービス呼び出しモデルを構成（構築）するステップと；
前記サービス呼び出しモデルに従って前記サービス呼び出しチェーンを処理するステップと；を含む。

【0007】

本願の別の態様は、分散型システムにおいて、サービスの実行中にエラーを発見し、サービスを実行し、警告を発するためのサービス呼び出し情報処理デバイスを提供する。このデバイスは：
分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するように構成されたサービス呼び出しチェーン取得装置であって、前記サービス呼び出しチェーンのそれぞれは、順次に呼び出される１つ以上のサービスノードを含む、サービス呼び出しチェーン取得装置と；
サービス呼び出しチェーンに従って、対応するサービス呼び出しモデルを構成するように構成されたサービス呼び出しモデル構成装置と；
前記サービス呼び出しモデルに従って、前記サービス呼び出しチェーンを処理するように構成された処理装置と；を含む。

【0008】

既存の技術との比較において、本願では、分散型サービスシステム内でのサービスノードの呼び出し順序情報を含むサービス呼び出しチェーンを取得する。サービス呼び出しモデルは、同じサービスノード呼び出し順序を有するサービス呼び出しチェーンに基づいて構成されているため、サービスノードの呼び出し情報をサービス呼び出しモデルに基づいて分析し、分析に基づいて定期的にサービス呼び出しを監視して迅速に実行エラーの所在を特定し、サービスノードをビッグデータ情報を使って分析及び監視を行うことができる。これにより、分散型サービスシステム内でのエラーの所在特定の効率が向上し、分散型サービスシステムの信頼度が高まる。

【図面の簡単な説明】

【0009】

本願のその他の特徴、目的、利点を明らかにするために、以後、非制限的な実施の形態を以下の添付の図面を参照しながら詳細に説明する。

【0010】

【図1】図１は、本願の一の態様によるサービス呼び出し情報処理方法を例示するフローチャートである。

【0011】

【図2】図２は、本願の別の好ましい実施の形態によるサービス呼び出し情報処理方法のステップＳ１を例示するフローチャートである。

【0012】

【図3】図３は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理方法のステップＳ３を例示するフローチャートである。

【0013】

【図4】図４は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理方法のステップＳ３２を例示するフローチャートである。

【0014】

【図5】図５は、本願の別の態様によるサービス呼び出し情報処理デバイスを例示する概略図である。

【0015】

【図6】図６は、本願の別の好ましい実施の形態によるサービス呼び出し情報処理デバイス内のサービス呼び出しチェーン取得装置を例示する概略図である。

【0016】

【図7】図７は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理デバイス内の処理装置を例示する概略図である。

【0017】

【図8】図８は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理デバイス内の監視ユニットを例示する概略図である。

【0018】

【図9】図９は、本願の更に別の好ましい実施の形態によるサービス呼び出しを例示する概略図である。

【0019】

添付の図面における同一又は類似の符号は、同一又は類似の構成要素を表す。

【発明を実施するための形態】

【0020】

更に、添付の図面を参照しながら本願を以下詳細に述べる。

【0021】

本願の典型的な構成では、端末、サービスネットワーク内のデバイス、及び信頼できるパーティは、どれもが１つ以上のプロセッサ（ＣＰＵ）、入出力インターフェース、ネットワークインターフェース、及びメモリを含んでいる。

【0022】

このメモリには、例えばリードオンリメモリ（ＲＯＭ）やフラッシュメモリ（フラッシュＲＡＭ）のようなコンピュータ読み出し可能な媒体内の、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、及び／又は不揮発性メモリ等がある。このメモリは、コンピュータ読み出し可能な媒体の一例である。

【0023】

コンピュータ読み出し可能な媒体には、任意の方法又は技術を用いて情報を記憶できる不揮発性媒体、揮発性媒体、リムーバブル媒体、又は非リムーバブル媒体がある。情報は、コンピュータ読み出し可能な命令、データ構造、プログラムモジュール、又はその他のデータであってよい。コンピュータ記憶媒体の例として以下があるが、それらに限定されない。すなわち、パラメータランダムアクセスメモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、その他のタイプのランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的消去が可能なリードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリ又はその他のメモリ記憶デバイス、コンパクトディスク−リードオンリメモリ（ＣＤ−ＲＯＭ）、デジタル多目的ディスク（ＤＶＤ）若しくは他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク若しくは他の磁気記憶デバイス、又は、計算デバイスがアクセスできる情報の記憶に用いられる他の非伝送媒体。本明細書での定義に基づき、コンピュータ読み出し可能な媒体には、変調したデータ信号やキャリアのような、コンピュータ読み出し可能な非一時的な媒体（ｔｒａｎｓｉｔｏｒｙ ｍｅｄｉａ）は含まれない。

【0024】

図１は、本願の一態様によるサービス呼び出し情報処理方法を例示するフローチャートである。この手順はステップＳ１、ステップＳ２、及びステップＳ３を含む。

【0025】

ステップＳ１では、デバイス１が、分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得する。ここで、各サービス呼び出しチェーンは、順次に呼び出される１つ以上のサービスノードを含む。ステップＳ２では、デバイス１がサービス呼び出しチェーンに従って、対応するサービス呼び出しモデルを構成する。ステップＳ３では、デバイス１が、サービス呼び出しモデルに従ってサービス呼び出しチェーンを処理する。

【0026】

具体的には、このステップＳ１で、デバイス１が分散型サービスシステムにおいて１つ以上のサービス呼び出しチェーンを取得する。この場合、各サービス呼び出しチェーンは、順次に呼び出される１つ以上のサービスノードを含んでいる。このように、分散型サービスシステムは、サービスアーキテクチャに適応するソフトウェアシステムを含むがそれに限定されない、すなわち、分散型システムの形式で構成される。サービスノードは、分散型サービスシステムにおいて呼び出されるサービス又は機能を含むがそれに限定されない。例えば、電子商取引プラットフォーム上で製品を購入するためのサービスノードは、ユーザの氏名を呼び出すステップ、ユーザの関連アカウントを呼び出すステップ、決済ページを呼び出すステップ、セキュリティ検証を取得するステップ、預金残高を調べるステップなどを含む。サービス呼び出しチェーンとは、分散型サービスシステムにおいて一度にサービス呼び出しを完了するための、関連するサービスノード及び関連するサービスノードの順序を指すものである。例えば、図９は、以下のサービス呼び出しを例示する概略図である。すなわち、サービス呼び出しチェーンの入口がサービスノードＡであり、丸で囲んだＡ、Ｂ、Ｃ、Ｄはそれぞれサービスノードを表す。図示のサービス呼び出しチェーンの入口はサービスノードＡであり、サービスノードＡを完了するためには、先ずＢを呼び出し、次にＣを呼び出す必要がある。Ｃを完了するためにはＤを呼び出す必要がある。図９に示すサービス呼び出しでは、サービス呼び出しチェーン内のサービス呼び出しノードを順番に呼び出す。つまり、図示のサービス呼び出しチェーンの呼び出し順序はＡ→Ｂ→Ｃ→Ｄである。図９に示すサービス呼び出しチェーンでのサービスノードの呼び出しは、サービスノードの呼び出し順序に従って、コンピュータ言語にて容易に識別される。最初の入口ノードをＡ０とマーキングし、次に呼び出されるＢをＢ０．１とマーキングすることができる。つまり、０はＡを表し、記号“．”の後の１は、ＢがＡの後に呼び出される１番目のサービスノードであることを示す。次に呼び出されるＣはＣ０．２とマーキングされる。つまり、０はＡを表し、記号“．”の後の２は、ＣがＡの後に呼び出される２番目のノードであることを示す。次に、Ｃを完了するためにはＤを呼び出す必要があるため、Ｃを完了するためにＤが呼び出されることがわかる。ＤはＤ０．２．１とマーキングされる。つまり、０はＡを表し、記号“．”の後の２はＣを表し、２つ目の記号“．”の後の１は、ＤがＣの後に最初に呼び出されるノードであることを示す。したがって、図９のトポロジ図に示す呼び出しチェーンは、Ａ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１と表すことができる。順序マーキング方法は一例として用いたに過ぎず、順序及びトポロジ（形態、網構成）を表す数字を、各ノードが呼び出される際にログ内に記録することができる。例えば、ログ中で、この呼び出しを表す記録フィールドはＸであり、フィールドＸの後のいくつかのフィールドには、サービスノードのトポロジ及び呼び出し順序を表す数字並びにドットが記録され、ログに記録されたサービス呼び出しに基づいてサービス呼び出しチェーンを取得できるようにする。呼び出された関連サービスノードとこれらサービスノードの呼び出し順序とを含むサービス呼び出しチェーンが取得されることにより、サービス呼び出しの工程を明瞭に示し、各サービス呼び出しのトポロジ及び特徴を取得できるようになる。

【0027】

当業者は、前述のサービス呼び出しチェーンを取得する方法及びサービス呼び出しチェーンをマーキングする方法は単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、サービス呼び出しチェーンを取得する方法及びサービス呼び出しチェーンをマーキングする方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0028】

次に、ステップＳ２では、デバイス１が、サービス呼び出しチェーンに従って対応するサービス呼び出しモデルを構成する。サービス呼び出しモデルは、サービス呼び出しチェーンのトポロジ構造に基づいて構成されるものであって、このサービス呼び出しチェーンと同じノード呼び出し順序を有する。例えば、取得したサービス呼び出しチェーンのサンプルが十分ある場合には、同じサービス呼び出しチェーンが、同じサービスプロバイダのプラットフォーム又はアプリケーションシステム内に現れる。例えば、１日のうちに、全国のユーザが図９に示すサービスノードに関連したサービス呼び出しを３０，０００回実行する場合には、サービスノードの呼び出し順序は同じで、サービスノードのトポロジは同じであるため、３０，０００回のサービス呼び出しは同じサービス呼び出しモデル、すなわち、前出の実施例でのＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１に対応する。サービスノードの同じトポロジと同じ呼び出し順序を有するいくつかのサービス呼び出しチェーンを集約することによってサービス呼び出しモデルを取得する工程が構成工程である。ビッグデータサンプルに基づいてサービス呼び出しチェーンをより明確に分析できるように、サービス呼び出しチェーンに対応するサービス呼び出しモデルを構成する。加えて、構成されたモデルは、或るタイプのサービス呼び出しを表してもよく、それによりサービス呼び出しモデルに基づいた各モデル内での後続のデータ分析を容易にする。

【0029】

次に、ステップＳ３では、デバイス１が、サービス呼び出しモデルに従ってサービス呼び出しチェーンを処理する。サービス呼び出しモデルと同じトポロジ順序及び同じサービスノード呼び出し順序を有するサービス呼び出しチェーンのデータを、サービス呼び出しモデルに基づいて分析する。各サービスノードの呼び出しデータ、例えば、各ノードの呼び出し完了時間や、呼び出し成功又は失敗は、状況に応じて異なる。しかし、十分な数のデータサンプルがあれば、各サービスノードの呼び出し規則を監視できる。例えば、特定のサービスノードの呼び出し完了時間は通常０．１秒未満であり、別の例では、特定のサービスノードのフィードバック情報中に呼び出し失敗が現れるのは、通常１０回未満である。そのため、同じトポロジ順序と同じサービスノード呼び出し順序とを有するサービス呼び出しチェーンのデータを、サービス呼び出しモデルに基づいて分析することにより取得した呼び出し規則を用いることにより、エラーの所在を特定し、分散型システム内の呼び出しが正常であるかどうかを監視することができる。例えば、特定のサービスノードの呼び出し完了時間が、前述の例と同様に、通常０．１秒未満であり、特定期間内にサービスノードを１００回呼び出す中で、０．１秒の１０倍を超えることが５０回より多い場合には、サービスノードの呼び出しエラーが存在する、と検出できる。

【0030】

当業者は、前述のサービス呼び出しチェーン処理方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のあるサービス呼び出しチェーン処理方法が本願に該当する場合は、この別のサービス呼び出しチェーン処理方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0031】

図２は、本願の別の好ましい実施の形態によるサービス呼び出し情報処理方法におけるステップＳ１を例示するフローチャートである。このステップＳ１は、ステップＳ１１とステップＳ１２を含む。

【0032】

ステップＳ１１では、デバイス１が分散型システムからサービス呼び出しログ情報を取得する。ステップＳ１２では、デバイス１がこのサービス呼び出しログ情報から１つ以上のサービス呼び出しチェーンを抽出する。ここで、各サービス呼び出しチェーンは、順次に呼び出される１つ以上のサービスノードを含んでいる。

【0033】

具体的に、ステップＳ１１では、デバイス１は分散型システムからサービス呼び出しログ情報を取得する。サービス呼び出しログ情報は、各サービスノードが呼び出される度に、各サービスノードのマークと順序情報を記録し、各サービス呼び出しにおける順序及びトポロジの判定に用いることができるその他の情報を記録する。例えば、前述の実施例での図９に示すサービス呼び出しにてノードがＤ０．２．１とマーキングされている呼び出し順序に従ってノードがマーキングされた場合には、１つのノードは特定期間中に２回以上呼び出されるので、１つのスタート点から２つ以上の呼び出し工程が始まり、次いで、第１のサービスノードが呼び出され、そして第２のサービスノードの次のノードが呼び出され、０．２．１とマーキングされることになろう。したがって、各ノードを呼び出す度に、各サービス呼び出しをマーキングして、ログに記録する必要がある。例えば、ログ中、図９に示す呼び出しを表すフィールドはＸとして記録される。つまり、Ｘは、入口ＡからＤの、完了した特定のサービス呼び出しがＸとしてマーキングされたことを表わし、ログ情報の取得時に呼び出しをマーキングしているフィールドの読み出しを可能にする。別の例では、前述の実施例と同様、各ノードが呼び出されると、順序とトポロジとを表す数字がログに記録されることで、ログ情報の取得時にサービス呼び出しチェーンにおけるサービスノードのトポロジと呼び出し順序とをマークするフィールドの読み出しが可能になる。前述のサービス呼び出しログ情報が取得されると、サービス呼び出し内のノードをリンクさせてサービス呼び出しチェーンの取得を可能にする。

【0034】

当業者は、前述のサービス呼び出しログ記録方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のあるサービス呼び出しログ記録方法が本願に該当する場合は、この別のサービス呼び出しログ記録方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0035】

次に、ステップＳ１２で、デバイス１は、順次に呼び出される１つ以上のサービスノードを含む１つ以上のサービス呼び出しチェーンを、サービス呼び出しログ情報から抽出する。つまり、各サービスノードが呼び出される度に、ログ情報は、各サービスノードのマーキング及び順序情報と、各サービス呼び出しにおける順序とトポロジとの判定に用いることができる他の情報とを記録する。そして、マーキング、順序情報、及び他の情報に基づいて、関連の呼び出し順序の情報と関連のトポロジの情報とを１ユニットのサービス呼び出しとして抽出し、ノードどうしをリンクさせることにより、サービス呼び出し毎のサービス呼び出しチェーンを生成する。例えば、取得した呼び出しログ情報は「ａｌｉｐａｙ，ｃｏｍ．ａｌｉｐａｙ．ｃｈａｓｈｉｅｒ．ｘｘｘ，０ｘ０ｂｏｃ１２３，０．２．１，ＡＥ００１…」であり、ログはカンマで分割される。第１のフィールドはシステム名「ａｌｉｐａｙ」であり、第２のフィールドはインターフェース方法を表す。第３のフィールドはサービス呼び出しのマーキングを表し、第４のフィールドは呼び出し中における順序及びトポロジを表し、第５のフィールドは、呼び出しの実行結果を表すリターンコード「ＡＥ００１」である。ログの後部では、記号「…」を用いて多くのフィールドを省略できる。つまり、サービス呼び出しのマーキング記録に従って、全てのログの第３のフィールドが検索され、「０ｘ０ｂｏｃ１２３」を含む全てのサービス呼び出しノードが検索され、識別されたログ記録に対応するノードの呼び出し順序及びトポロジが、前述の実施例のマーキング方法を用いて記録された第４のフィールドに記録されたフィールドに基づいて分類され、最後に、サービス呼び出しチェーンがＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１のような形式で形成される。

【0036】

当業者は、前述のログ情報からサービス呼び出しチェーンを抽出する方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、ログ情報からサービス呼び出しチェーンを抽出する方法が本願に該当する場合は、この別の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0037】

好ましくは、ステップＳ１２で、デバイス１が、サービス呼び出しチェーンに集約処理を実行することで、対応するサービス呼び出しモデルを構成する。ここで、サービス呼び出しモデルは、１つ以上のサービス呼び出しトポロジを含み、各サービス呼び出しトポロジは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される。全てのサービス呼び出しモデルは同じサービス呼び出しトポロジを含んでいる。つまり、サービス呼び出しモデルは、同じサービス呼び出しトポロジを持つサービス呼び出しチェーンに集約を実行することで取得される。例えば、前述の実施例のとおりに取得したサービス呼び出しチェーンにおいて、３０，０００個のサービス呼び出しチェーンはＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１と表され、２０，０００個のサービス呼び出しチェーンはＡ０、Ｂ０．１、Ｃ０．２と表され、１つのサービス呼び出しチェーンはＡ０、Ｂ０．１と表される。サービス呼び出しモデル００１は、３０，０００個のサービス呼び出しチェーンに集約を実行することにより取得でき、サービス呼び出しモデル００２は、２０，０００個のサービス呼び出しチェーンに集約を実行することにより取得でき、単一のサービス呼び出しチェーンはサービス呼び出しモデル００３として用いられる。つまり、サービス呼び出しモデルは、同じサービスノード、同じサービストポロジ及び同じ順序を含んでいる全てのサービス呼び出しチェーンを表し、これにより、サービス呼び出しチェーン内のサービスノードが実行したデータ呼び出しをサービス呼び出しモデルを用いて分析及び監視できるようになる。

【0038】

ステップＳ３で、デバイス１は、サービス呼び出しトポロジに従って、対応するサービス呼び出しチェーンを処理する。つまり、集約によって取得したサービス呼び出しモデル内のサービス呼び出しトポロジに基づいて、サービス呼び出しモデルと同じ呼び出しトポロジを有するサービス呼び出しチェーンのデータを分析する。前述の実施例と同様、サービス呼び出しモデルＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１を用いて、３０，０００個のサービス呼び出しチェーン内の各サービスノードのデータを分析する。例えば、取得した、１つのサービス呼び出しノードの呼び出し表示エラーの確率が１時間につき１／１０，０００回であることが分析により示された場合には、続いてこの分析結果に従って、サービス呼び出しモデルと同じサービス呼び出しトポロジを有する別のサービス呼び出しチェーンを監視して、サービス呼び出しノードの表示エラーの確率が１時間に１／１０，０００を超えるとエラーが報告されるようにする。したがって、サービス呼び出しチェーンはサービス呼び出しトポロジに基づいて処理され、比較的大量のデータサンプルがある場合には、システムを効率的に監視でき、システムの警告のパフォーマンスと安定性が向上する。

【0039】

好ましくは、デバイスは更にステップＳ４（不図示）を実行し、ステップＳ４において、デバイス１はサービス呼び出しトポロジにクリーニング操作を実行する。クリーニング操作は、重要でない呼び出しオブジェクト情報をフィルタリングにより除去する。前述の実施例にあるように、図９に示すサービス呼び出しチェーンと同じ呼び出しノードトポロジを有するサービス呼び出しは２つある。サービスノードＣが呼び出されたときには、いくつかの情報がさらに照会される。例えば、１つ目のサービス呼び出しチェーン内でキャッシュＣ１が問い合わせを受け、何も取得されなかった場合には、データベースＣ２が問い合わせを１回受け、次に、データがキャッシュＣ３に記憶される。しかし、２つ目のサービス呼び出しチェーン内でキャッシュＣ１に直接問い合わせすることでデータが取得される。クリーニング操作を実行する以前には、サービス呼び出しチェーンは２つの異なるチェーンであってよい。つまり、ノードＣはノードＣ１、ノードＣ２、ノードＣ３を更に呼び出す。通常、これらの問い合わせを受けたノードにはシステム内に欠陥があり実行結果を戻さず、ノードの呼び出し結果は通常、ノードＣにフィードバックされるため、ノードＣ１、ノードＣ２、ノードＣ３はクリーンオフ（ゼロクリア）され、無視される。加えて、ルーティングについての問い合わせを受けた中間ノード等はモデルに影響せず、クリーンオフできるため、主要なサービスノードの呼び出し状況が強調され、サービス呼び出しトポロジがより正確になる。

【0040】

当業者は、前述のサービス呼び出しトポロジクリーニング方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のあるサービス呼び出しトポロジクリーニング方法が本願に該当する場合は、この別のサービス呼び出しトポロジクリーニング方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0041】

更に、ステップＳ３で、デバイス１が、クリーニング済みのサービス呼び出しトポロジに従って、対応するサービス呼び出しチェーンを処理する。つまり、サービス呼び出しモデルを構成するために、クリーニング操作の実行後に取得され、同じサービス呼び出しトポロジを有するサービス呼び出しチェーンを、サービス呼び出しチェーンのログ情報に従って集約する。特定の集約及び構成方法は前述の方法と同じである。

【0042】

より好ましくは、クリーニング操作は以下のうちの少なくとも１つのステップを含む：
サービス呼び出しトポロジにおいて所定のサービスノードを削除するステップ。ここで、呼び出された、遠隔サービスに属さないサービスノード、例えば、中間サービスノード又はルーティングについて問い合わされた呼び出しノードは、フィルタリングにより除去される；
サービス呼び出しトポロジ内にある、呼び出し結果情報を戻さないサービスノードを削除するステップ。ここで、システム内で実行された呼び出し操作、例えば、キャッシュへの問い合わせやキャッシュの呼び出し、又はデータベースの呼び出しを含む、実行結果のようなサービス呼び出し結果を戻さないサービスノードは、フィルタリングによって除去される；
サービス呼び出しトポロジ内の低頻度で用いられるサービスノードを削除するステップ。ここで、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の低頻度で用いられるこのサービスノードの累積出現回数の数は、所定の低頻度使用の閾値よりも少ない、又はこれと等しい。ここで、呼び出し回数の特定の閾値を設定し、ログ情報又は他の履歴情報における呼び出し回数を読み出すことにより、非常に少ない状況でしか用いられない、又は、特定のサービス呼び出しチェーン全体が正常に終了した際に低頻度でのみ用いられるサービスノードを削除できるようにする。これにより、システムのデータ分析及び処理の負担が減り、より正確なサービス呼び出しモデルとより正確なデータの取得とが可能になる；及び
サービス呼び出しトポロジ内の低頻度で用いられるサービスノードを削除するステップ。ここで、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内で低頻度で用いられるこのサービスノードの累積出現回数は、所定の低頻度使用の閾値よりも少ない、又はこれと等しい。サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の、低頻度で用いられるこのサービスノード以外の、別のサービスノードの累積出現回数は、所定の高頻度使用の閾値よりも多い、又はこれと等しい。ここで、特定の呼び出し回数閾値を設定し、ログ情報又は他の履歴情報における呼び出し回数を読み出すことにより、主要のサービスノード又は特別に維持されたサービスノードを選択できるようにし、又、高頻度には用いられないサービスノードを削除できるようにする。これにより、データを細かく分析及び監視することが可能となる。

【0043】

ステップＳ２で、対応するサービス呼び出しモデルを構成できるようにするために、デバイス１が、サービス呼び出しチェーン内のサービスノードの呼び出しフィードバック情報を参照して、サービス呼び出しチェーンに集約処理を実行することが好ましい。ここで、サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、各サービス呼び出しトポロジは、１つ以上のサービス呼び出しチェーンに集約処理を実行することで取得される。呼び出しフィードバック情報は、各サービスノードが呼び出された後、各サービスノードの戻りノードを参照し、戻りノードはサービスノードの実行結果を表すために用いられる。呼び出しフィードバック情報は、特定の実行結果と、様々な状況により形成され、特定の所定規則に基づいて識別できる情報、例えば、実行の成功又は失敗や、特定のサービスシナリオを含む。図９に示すサービス呼び出しチェーンで、ノードＢの呼び出しが成功した場合には、ＳＵＣＣがフィードバックされる。ノードＤの呼び出しが成功した場合には、呼び出しフィードバック情報はＡＥ００であり、ノードＣの呼び出しフィードバック情報はＡＥ０１であり、ノードＡの呼び出しフィードバック情報はＡＥ１０である。これは、ノードＡを呼び出すためには、ノードＢの呼び出しが成功した後にノードＣを呼び出す必要があり、ノードＣを呼び出すためには、ノードＤを最初に呼び出す必要があることを示す。呼び出しフィードバック情報はログに記録することができ、これにより、或る特定時にサービスノードを呼び出す呼び出しトポロジ情報に問い合わせする場合に、呼び出しフィードバック情報にも問い合わせできるようになる。各サービスノードはいくつかの呼び出しフィードバック情報に対応しており、サービス呼び出しチェーンの後端の呼び出しフィードバック情報は、通常、サービス呼び出しチェーンの前端の呼び出しフィードバック情報に影響を及ぼすが、サービス呼び出しチェーンの前端にて呼び出しフィードバック情報の両端に集約を実行することができる。例えば、図９に示すサービスノードＡは、システムの異常に関する情報を戻し、これは、サービスノードＣ又はサービスノードＤにネットワークアクセス問題が生じている、又は、データベースに異常があることを示し得る。よって、各サービス呼び出しチェーンは呼び出しフィードバック情報の組み合わせであってよい。したがって、種々のサービス呼び出しチェーンについてエラーの所在を明確に特定するために、同じトポロジを有しサービス呼び出しモデルを構成するサービス呼び出しチェーンに集約を実行する場合、全ての呼び出しフィードバック情報の組み合わせがチェーン内に記録され、サービス呼び出しモデルに基づく後続のデータ分析に用いられる。

【0044】

当業者は、前述の呼び出しフィードバック情報を記録する方法と呼び出しフィードバック情報を提示する方法とが、単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、呼び出しフィードバック情報を記録する方法と呼び出しフィードバック情報を提示する方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0045】

図３は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理方法におけるステップＳ３を例示するフローチャートである。ステップＳ３はステップＳ３１とステップＳ３２を含む。

【0046】

ステップＳ３１で、デバイス１は、各サービス呼び出しチェーン内の１つのサービスノードの呼び出しフィードバック情報に従って、サービス呼び出しトポロジに対応する１つ以上のサービス呼び出しチェーンについての統計を収集する。ステップＳ３２で、デバイス１が、対応する統計結果に従って、サービス呼び出しトポロジに対応するサービス呼び出しチェーンを監視する。

【0047】

具体的には、ステップＳ３１で、デバイス１が、各サービス呼び出しチェーン内の１つのサービスノードの呼び出しフィードバック情報に従って、サービス呼び出しトポロジに対応する１つ以上のサービス呼び出しチェーンについての統計を収集する。つまり、サービス呼び出しモデルに対応するとともに同じサービス呼び出しトポロジを有する全てのサービス呼び出しチェーン内の呼び出しフィードバック情報を分析し、この呼び出しフィードバック情報についての統計を収集する。例えば、生成されたサービス呼び出しモデルとサービス呼び出しチェーンとのトポロジ関係に基づいて、同じサービス呼び出しトポロジを有する全てのサービス呼び出しチェーンを、このサービス呼び出しモデルのマークでマーキングする。つまり、各サービス呼び出しモデルが特定のマークを有するということである。更に、各サービス呼び出しチェーン内のマークと呼び出しフィードバック情報の組み合わせとに関連して、各サービス呼び出しチェーンに一意のマークを割り当てる。サービス呼び出しチェーン内の呼び出しフィードバック情報についての統計を収集し、各サービス呼び出しチェーン内のサービスノードの呼び出しフィードバック情報の状態を、一定時間の間、チェーン比較又は並列比較により集合的に分析する。

【0048】

当業者は、前述の呼び出しフィードバック情報分析に基づくデータ分析方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、呼び出しフィードバック情報分析に基づいたデータ分析方法が本願に該当する場合は、この別の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0049】

次に、ステップＳ３２で、デバイス１が、対応する統計結果に従って、サービス呼び出しトポロジに対応するサービス呼び出しチェーンを監視する。つまり、十分な数のデータサンプルが存在する場合は、サービス呼び出しトポロジ内の同じノードの呼び出しフィードバック情報同士を比較し、一定の時間間隔にてデータを監視する。例えば、統計サンプルの９５％以上のデータは正常状態にある。システム内で５％の異常状況が生じた場合、システムはその異常を監視によって識別する。各サービス呼び出しノードについての呼び出しフィードバック情報が存在するので、監視により異常状態を識別した後に、特定のサービス呼び出しモデルに対応するサービス呼び出しチェーンの所在を特定できる。前述の実施例と同様に、各サービス呼び出しチェーンに対応する一意のマークに従って、特定のサービス呼び出しチェーンと、このサービス呼び出しチェーン内の呼び出されたサービスノードの所在とを特定する。

【0050】

当業者は、前述の分析結果に基づくサービス呼び出し監視方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、分析結果に基づくサービス呼び出し監視方法が本願に該当する場合は、この別の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0051】

図４は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理方法におけるステップＳ３２を例示するフローチャートである。ステップＳ３２はステップＳ３２１とステップＳ３２２を含む。

【0052】

ステップＳ３２１で、デバイス１は、所定の継続時間比較規則に基づいて、対応する統計結果を、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の各サービスノードの呼び出しフィードバック情報と比較する。ステップＳ３２２で、差異が所定の変動閾値を超えると、デバイス１が、この差異に対応するサービス呼び出しチェーンについての警告情報を生成する。警告情報は、この差異に対応するサービスノードの所在を特定するために用いられる。

【0053】

具体的には、ステップＳ３２１で、デバイス１が、所定の継続時間比較規則に基づいて、対応する統計結果を、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の各サービスノードの呼び出しフィードバック情報と比較する。つまり、特定の継続時間比較規則に従い、全てのサービス呼び出しチェーンの呼び出しフィードバック情報を同じサービス呼び出しトポロジに基づいて分析する。例えば、同じサービス呼び出しトポロジを有するサービス呼び出しチェーン内の、午前８時から午前９時までに生成されたデータと、午前９時から午前１０時までに生成された呼び出しフィードバック情報とにチェーン比較分析を実行する。もう一つ例を挙げると、同じサービス呼び出しトポロジを有するサービス呼び出しチェーン内の、３月２日の午前８時から午前９時までに生成されたデータと、３月３日の午前８時から午前９時までに生成された呼び出しフィードバック情報とに並列比較分析を実行する。これにより、種々のシナリオにおいて正常作動中に生成された幅広いデータを取得できる。例えば、一日の決済失敗確率は、完了した決済において残高不足が１００回出現することを示す。次に、これらの分析結果に基づいて、システムにおけるサービス呼び出しステータスを監視できる。

【0054】

当業者は、前述の統計結果を取得及び比較する方法が、単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、統計結果を取得及び比較する方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0055】

次に、ステップＳ３２２で、差異が所定の変動閾値を超えると、デバイス１が、この差異に対応するサービス呼び出しチェーンについての警告情報を生成する。この警告情報は、差異に対応するサービスノードの所在を特定するために用いられる。同じトポロジと同じサービスモデルを有するサービス呼び出しチェーンを、呼び出しフィードバック情報に基づいて分析した後に、日常の作動中に生成された、同じトポロジを有するサービス呼び出しチェーンのデータを、様々なシナリオで正常作動中に生成されたデータの取得された範囲に従って監視し、正常範囲を特定の閾値に設定する。例えば、前述の実施例にあるように、一日の決済失敗確率が、完了した決済にて残高不足が１００回出現することを示す場合には、サービスノードの残高チェックについての失敗フィードバック回数の閾値を１００回又は１２０回よりも少なく、或いはこれと等しく設定する。システムにおいて残高チェックについてのサービスノードの一日の失敗フィードバック回数が設定された閾値を超えると警告が発せられ、その失敗ノードが、サービス呼び出しチェーン情報と呼び出しフィードバック情報とで形成されたグローバルな一意のマークに基づいて追跡される。

【0056】

当業者は、前述の監視方法と警告方法とが単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある監視方法と警告方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0057】

図５は、本願の別の態様によるサービス呼び出し情報処理デバイスを例示する概略図である。デバイス１は、サービス呼び出しチェーン取得装置１１、サービス呼び出しモデル構成装置１２、及び処理装置１３を含む。

【0058】

デバイス１において、サービス呼び出しチェーン取得装置１１は分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得し、ここで、各サービス呼び出しチェーンは、順次に呼び出される１つ以上のサービスノードを含む。サービス呼び出しモデル構成装置１２は、サービス呼び出しチェーンに従って、対応するサービス呼び出しモデルを構成する。更に処理装置１３は、サービス呼び出しモデルに従って、サービス呼び出しチェーンを処理する。

【0059】

具体的に、サービス呼び出しチェーン取得装置１１は、分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得する。ここで、各サービス呼び出しチェーンは、順次に呼び出される1つ以上のサービスノードを含む。このように、分散型サービスシステムは、サービスアーキテクチャに適応するソフトウェアシステムを含むがそれに限定されない、すなわち、分散型システムの形式で構成される。サービスノードは、分散型サービスシステムにおいて呼び出されるサービス又は機能を含むがそれに限定されない。例えば、電子商取引プラットフォーム上で商品を購入するためのサービスノードは、ユーザの氏名を呼び出すステップ、ユーザの関連アカウントを呼び出すステップ、決済ページを呼び出すステップ、セキュリティ検証を取得するステップ、預金残高を調べるステップなどを含む。サービス呼び出しチェーンとは、分散型サービスシステムにおいて一度にサービス呼び出しを完了するための、関連するサービスノード及び順序を意味する。例えば、図９は、以下のサービス呼び出しを例示する概略図である。すなわち、サービス呼び出しチェーンの入り口がサービスノードＡである。丸で囲んだＡ、Ｂ、Ｃ、Ｄはサービスノードを表す。図示のサービス呼び出しチェーンの入口はサービスノードＡであり、サービスノードＡを完了するためには、まずＢを呼び出し、次にＣを呼び出す必要がある。Ｃを完了するためにはＤを呼び出す必要がある。図９に示すサービス呼び出しでは、サービス呼び出しチェーン内のサービス呼び出しノードを順番に呼び出す。つまり、図示のサービス呼び出しチェーンの呼び出し順序はＡ→Ｂ→Ｃ→Ｄである。図９に示すサービス呼び出しチェーンでのサービスノードの呼び出しは、サービスノードの呼び出し順序に従って、コンピュータ言語にて容易に識別される。最初の入口ノードをＡ０とマーキングし、次に呼び出されるＢをＢ０．１とマーキングしてよい。つまり、０はＡを表し、記号“．”の後の１は、ＢがＡの後に呼び出される１番目のサービスノードであることを示す。次に呼び出されるＣはＣ０．２とマーキングされる。つまり、０はＡを表し、記号“．”の後の２は、ＣがＡの後に呼び出される２番目のノードであることを示す。次に、Ｃを完了するためにはＤを呼び出す必要があるため、Ｃを完了するためにＤが呼び出されることが分かる。ＤはＤ０．２．１とマーキングされる。つまり、０はＡを表し、記号“．”の後の２はＣを表し、２つ目の記号“．”の後の１は、ＤがＣの後に最初に呼び出されるノードであることを示す。したがって、図９のトポロジ図に示す呼び出しチェーンは、Ａ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１と表すことができる。順序マーキング方法は単に一例として用いたものであり、順序及びトポロジを表す数字は、各ノードが呼び出される際にログ内に記録することができる。例えば、ログ中で、この呼び出しを表す記録フィールドはＸであり、フィールドＸの後のいくつかのフィールドには、サービスノードのトポロジ及び呼び出し順序を表す数字並びにドットが記録され、ログに記録されたサービス呼び出しに基づいてサービス呼び出しチェーンを取得できるようにする。関連する呼び出されたサービスノードとこれらサービスノードの呼び出し順序とを含むサービス呼び出しチェーンが取得されることにより、サービス呼び出しの工程を明瞭に示し、各サービス呼び出しのトポロジ及び特徴を取得できるようになる。

【0060】

当業者は、前述のサービス呼び出しチェーンを取得する方法とサービス呼び出しチェーンをマーキングする方法とは、単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、サービス呼び出しチェーンを取得する方法とサービス呼び出しチェーンをマーキングする方法とが本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0061】

次に、サービス呼び出しモデル構成装置１２が、サービス呼び出しチェーンに従って、対応するサービス呼び出しモデルを構成する。サービス呼び出しモデルは、サービス呼び出しチェーンのトポロジ構造に基づいて構成されるものであって、このサービス呼び出しチェーンと同じノード呼び出し順序を有する。例えば、取得したサービス呼び出しチェーンのサンプルが十分ある場合には、同じサービス呼び出しチェーンが同じサービスプロバイダのプラットフォーム又はアプリケーションシステムに現れる。例えば、１日のうちに、全国のユーザが図９に示すサービスノードに関連したサービス呼び出しを３０，０００回実行する場合には、サービスノードの呼び出し順序は同じで、サービスノードのトポロジは同じであるため、３０，０００回のサービス呼び出しは同じサービス呼び出しモデル、すなわち、前出の実施例でのＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１に対応する。サービスノードの同じトポロジ及び同じ呼び出し順序を有するいくつかのサービス呼び出しチェーンを集約することによりサービス呼び出しモデルを取得する工程が構成工程である。ビッグデータサンプルに基づいてサービス呼び出しチェーンをより明確に分析できるように、サービス呼び出しチェーンに対応するサービス呼び出しモデルを構成する。加えて、構成されたモデルは、或るタイプのサービス呼び出しを表してもよく、それによりサービス呼び出しモデルに基づいた各モデル内での後続のデータ分析を容易にする。

【0062】

次に、処理装置１３が、サービス呼び出しモデルに従って、サービス呼び出しチェーンを処理する。サービス呼び出しモデルと同じトポロジ順序及び同じサービスノード呼び出し順序を有するサービス呼び出しチェーンのデータを、サービス呼び出しモデルに基づいて分析する。各サービスノードの呼び出しデータ、例えば、各ノードの呼び出し完了時間や、呼び出し成功又は失敗は、状況に応じて異なる。しかし、十分な数のデータサンプルがあれば、各サービスノードの呼び出し規則を監視できる。例えば、特定のサービスノードの呼び出し完了時間は通常０．１秒未満であり、別の例では、特定のサービスノードのフィードバック情報中に呼び出し失敗が現れるのは、通常１０回未満である。そのため、同じトポロジ順序と同じサービスノード呼び出し順序とを有するサービス呼び出しチェーンのデータを、サービス呼び出しモデルに基づいて分析することにより取得した呼び出し規則を用いることにより、エラーの所在を特定し、分散型システム内の呼び出しが正常であるかどうかを監視することができる。例えば、特定のサービスノードの呼び出し完了時間が、前述の例と同様に、通常０．１秒未満であり、特定期間内にサービスノードを１００回呼び出す中で、０．１秒の１０倍を超えることが５０回より多い場合には、サービスノードの呼び出しエラーが存在する、と検出できる。

【0063】

当業者は、前述のサービス呼び出しチェーン処理方法が単なる実施例であることを理解すべきである。別の既存の又は将来登場する可能性のある、サービス呼び出しチェーン処理方法が本願に該当する場合は、この別のサービス呼び出しチェーン処理方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0064】

図６は、本願の別の好ましい実施の形態によるサービス呼び出し情報処理装置内のサービス呼び出しチェーン取得装置を例示する概略図である。サービス呼び出しチェーン取得装置１１は、呼び出し情報取得ユニット１１１とサービス呼び出しチェーン生成ユニット１１２とを含む。

【0065】

呼び出し情報取得ユニット１１１は、分散型システムからサービス呼び出しログ情報を取得する。サービス呼び出しチェーン生成ユニット１１２は、サービス呼び出しログ情報から１つ以上のサービス呼び出しチェーンを抽出する。ここで、各サービス呼び出しチェーンは、順次に呼び出される１つ以上のサービスノードを含んでいる。

【0066】

具体的に、呼び出し情報取得ユニット１１１は、分散型システムからサービス呼び出しログ情報を取得する。サービス呼び出しログ情報は、各サービスノードが呼び出される度に、各サービスノードのマークと順序情報とを記録し、各サービス呼び出しにおける順序及びトポロジの判定に用いることができる他の情報を記録する。例えば、前述の実施例での図９に示すサービス呼び出しにてノードがＤ０．２．１とマーキングされている呼び出し順序に従ってノードがマーキングされた場合には、１つのノードは特定期間中に２回以上呼び出されるので、１つのスタート点から２つ以上の呼び出し処理が開始する可能性がある。次いで、第１のサービスノードが呼び出され、又、第２のサービスノードの次のノードが呼び出され、０．２．１とマーキングされる。したがって、各ノードを呼び出す度に、各サービス呼び出しをマーキングして、ログに記録する必要がある。例えば、ログ中で、図９に示す呼び出しを表すフィールドはＸとして記録される。つまり、Ｘは、入口ＡからＤへの特定の完了したサービス呼び出しがＸとしてマーキングされたことを表わし、ログ情報の取得時に呼び出しをマーキングしているフィールドの読み出しを可能にする。別の例では、前述の実施例と同様、各ノードが呼び出されると、順序とトポロジを表す数字がログに記録されることで、ログ情報の取得時にサービス呼び出しチェーンにおけるサービスノードのトポロジと呼び出し順序をマークするフィールドの読み出しが可能になる。前述のサービス呼び出しログ情報が取得されると、サービス呼び出し内のノードをリンクさせてサービス呼び出しチェーンの取得を可能にする。

【0067】

当業者は、前述のサービス呼び出しログ記録方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、サービス呼び出しログ記録方法が本願に該当する場合は、この別のサービス呼び出しログ記録方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0068】

次に、サービス呼び出しチェーン生成ユニット１１２は、順次に呼び出される１つ以上のサービスノードを含む１つ以上のサービス呼び出しチェーンを、サービス呼び出しログ記録から抽出する。つまり、各サービスノードが呼び出される度に、ログ情報が、各サービスノードのマーキング及び順序情報と、各サービス呼び出しにおける順序及びトポロジの判定に用いることができるその他の情報とを記録する。更に、マーキング、順序情報、及びその他の情報に基づいて、関連の呼び出し順序の情報と関連のトポロジの情報とをサービス呼び出しの１ユニットとして抽出し、ノード同士をリンクさせる。これにより、サービス呼び出し毎のサービス呼び出しチェーンを生成する。例えば、取得した呼び出しログ情報は「ａｌｉｐａｙ，ｃｏｍ．ａｌｉｐａｙ．ｃｈａｓｈｉｅｒ．ｘｘｘ，０ｘ０ｂｏｃ１２３，０．２．１，ＡＥ００１…」であり、ログはコンマで分割されている。第１のフィールドはシステム名「ａｌｉｐａｙ」であり、第２のフィールドはインターフェース方法を表す。第３のフィールドはサービス呼び出しのマーキングを表し、第４のフィールドは呼び出し中における順序及びトポロジを表し、第５のフィールドは、呼び出しの実行結果を表すリターンコード「ＡＥ００１」である。ログの後部では、記号「…」を用いてより多くのフィールドを省略できる。つまり、サービス呼び出しのマーキング記録に従って、全てのログの第３のフィールドが検索され、「０ｘ０ｂｏｃ１２３」を含む全てのサービス呼び出しノードが検索され、識別されたログ記録に対応するノードの呼び出し順序及びトポロジが、前述の実施例のマーキング方法を用いて記録された第４のフィールドに記録されたフィールドに基づいて分類され、最後に、サービス呼び出しチェーンがＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１のような形式で形成される。

【0069】

当業者は、前述のログ情報からサービス呼び出しチェーンを抽出する方法が、単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、ログ情報からサービス呼び出しチェーンを抽出する方法が本願に該当する場合は、この別の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0070】

好ましくは、サービス呼び出しモデル構成装置１２は、サービス呼び出しチェーンに集約処理を実行することにより、対応するサービス呼び出しモデルを構成する。ここで、サービス呼び出しモデルは、１つ以上のサービス呼び出しトポロジを含み、各サービス呼び出しトポロジは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される。全てのサービス呼び出しモデルは同じサービス呼び出しトポロジを含んでいる。つまり、サービス呼び出しモデルは、同じサービス呼び出しトポロジを持つサービス呼び出しチェーンに集約を実行することで取得される。例えば、前述の実施例のとおりに取得したサービス呼び出しチェーンにおいて、３０，０００個のサービス呼び出しチェーンはＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１と表され、２０，０００個のサービス呼び出しチェーンはＡ０、Ｂ０．１、Ｃ０．２と表され、１つのサービス呼び出しチェーンはＡ０、Ｂ０．１と表される。サービス呼び出しモデル００１は、３０，０００個のサービス呼び出しチェーンに集約を実行することにより取得でき、サービス呼び出しモデル００２は、２０，０００個のサービス呼び出しチェーンに集約を実行することにより取得でき、単一のサービス呼び出しチェーンはサービス呼び出しモデル００３として用いられる。つまり、サービス呼び出しモデルは、同じサービスノード、同じサービストポロジ及び同じ順序を含んでいる全てのサービス呼び出しチェーンを表し、これにより、サービス呼び出しチェーン内のサービスノードが実行したデータ呼び出しをサービス呼び出しモデルを用いて分析及び監視できるようになる。

【0071】

処理装置１３は、サービス呼び出しトポロジに従って、対応するサービス呼び出しチェーンを処理する。つまり、集約によって取得したサービス呼び出しモデル内のサービス呼び出しトポロジに基づいて、サービス呼び出しモデルと同じ呼び出しトポロジを有するサービス呼び出しチェーンのデータを分析する。前述の実施例と同様、サービス呼び出しモデルＡ０、Ｂ０．１、Ｃ０．２、Ｄ０．２．１を用いて、３０，０００個のサービス呼び出しチェーン内の各サービスノードのデータを分析する。例えば、取得した、１つのサービス呼び出しノードの呼び出し表示エラーの確率が１時間につき１／１０，０００回であることが分析により示された場合には、続いてこの分析結果に従って、サービス呼び出しモデルと同じサービス呼び出しトポロジを持つ別のサービス呼び出しチェーンを監視して、サービス呼び出しノードの表示エラーの確率が１時間に１／１０，０００を超えるとエラーが報告されるようにする。したがって、サービス呼び出しチェーンはサービス呼び出しトポロジに基づいて処理され、比較的大量のデータサンプルがある場合には、システムを効率的に監視でき、システムの警告のパフォーマンスと安定性が向上する。

【0072】

好ましくは、デバイスはクリーニング装置１４（不図示）を更に含み、クリーニング装置１４は、サービス呼び出しトポロジにクリーニング操作を実行する。クリーニング操作は、重要でない呼び出しオブジェクト情報をフィルタリングにより除去する。前述の実施例にあるように、図９に示すサービス呼び出しチェーンと同じ呼び出しノードトポロジを有するサービス呼び出しは２つある。サービスノードＣが呼び出されたときには、いくつかの情報がさらに照会される。例えば、１つ目のサービス呼び出しチェーン内でキャッシュＣ１が問い合わせを受け、何も取得されなかった場合には、データベースＣ２が問い合わせを１回受け、次に、データがキャッシュＣ３に記憶される。しかし、２つ目のサービス呼び出しチェーン内でキャッシュＣ１に直接問い合わせすることでデータが取得される。クリーニング操作を実行する以前には、サービス呼び出しチェーンは２つの異なるチェーンであってよい。つまり、ノードＣはノードＣ１、ノードＣ２、ノードＣ３を更に呼び出す。通常、これらの問い合わせを受けたノードにはシステム内に欠陥があり実行結果を戻さず、ノードの呼び出し結果は通常、ノードＣにフィードバックされるため、ノードＣ１、ノードＣ２、ノードＣ３はクリーンオフ（ゼロクリア）され、無視される。加えて、ルーティングについての問い合わせを受けた中間ノード等はモデルに影響せず、クリーンオフできるため、主要なサービスノードの呼び出し状況が強調され、サービス呼び出しトポロジがより正確になる。

【0073】

当業者は、前述のサービス呼び出しトポロジのクリーニング方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、サービス呼び出しトポロジのクリーニング方法が本願に該当する場合は、この別のサービス呼び出しトポロジのクリーニング方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0074】

更に、処理装置１３は、クリーニング済みのサービス呼び出しトポロジに従って、対応するサービス呼び出しチェーンを処理する。つまり、サービス呼び出しモデルを構成するために、クリーニング操作の実行後に取得され、同じサービス呼び出しトポロジを有するサービス呼び出しチェーンを、サービス呼び出しチェーンのログ情報に従って集約する。特定の集約及び構成方法は前述の方法と同じである。

【0075】

より好ましくは、クリーニング操作は以下のうちの少なくとも１つのステップを含む：
サービス呼び出しトポロジにおいて所定のサービスノードを削除するステップ。ここで、呼び出された、遠隔サービスに属さないサービスノード、例えば、中間サービスノード、又はルーティングについて問い合わされた呼び出しノードはフィルタリングにより除去される；
サービス呼び出しトポロジ内にある、呼び出し結果情報を戻さないサービスノードを削除する。ここで、システム内で実行された呼び出し操作、例えば、キャッシュへの問い合わせやキャッシュの呼び出し、又はデータベースの呼び出しを含む、実行結果のようなサービス呼び出し結果を戻さないサービスノードはフィルタリングによって除去される；
サービス呼び出しトポロジ内の低頻度で用いられるサービスノードを削除するステップ。ここで、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の低頻度で用いられるこのサービスノードの累積出現回数の数は、所定の低頻度使用の閾値よりも少ない、又はこれと等しい。ここで、呼び出し回数の特定の閾値を設定し、ログ情報又は他の履歴情報における呼び出し回数を読み出すことにより、非常に少ない状況でしか用いられない、又は特定のサービス呼び出しチェーン全体が正常に終了した際に低頻度でのみ用いられるサービスノードを削除できるようにする。これにより、システムのデータ分析及び処理の負担が減り、より正確なサービス呼び出しモデルとより正確なデータの取得とが可能になる；及び
サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップ。ここで、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内で低頻度で用いられるこのサービスノードの累積出現回数は、所定の低頻度使用の閾値よりも少ない、又はこれと等しい。サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の、低頻度で用いられるこのサービスノード以外の、別のサービスノードの累積出現回数は、所定の高頻度使用の閾値よりも多い、又はこれと等しい。ここで、特定の呼び出し回数閾値を設定し、ログ情報又は他の履歴情報における呼び出し回数を読み出すことにより、主要のサービスノード又は特別に維持されたサービスノードを選択できるようにし、又、高頻度には用いられないサービスノードを削除できるようにする。これにより、データを細かく分析及び監視することが可能となる。

【0076】

好ましくは、サービス呼び出しモデル構成装置１２は、対応するサービス呼び出しモデルを構成できるようにするために、サービス呼び出しチェーン内のサービスノードの呼び出しフィードバック情報を参照してサービス呼び出しチェーンに集約処理を実行する。ここで、サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、各サービス呼び出しトポロジは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される。呼び出しフィードバック情報は、各サービスノードが呼び出された後の各サービスノードの戻りノードを参照し、戻りノードはサービスノードの実行結果を表すために用いられる。呼び出しフィードバック情報は、特定の実行結果と、様々な状況により形成され、特定の所定規則に基づいて識別できる情報、例えば、実行の成功又は失敗や特定のサービスシナリオとを含む。図９に示すサービス呼び出しチェーンでは、ノードＢの呼び出しが成功した場合には、ＳＵＣＣがフィードバックされる。ノードＤの呼び出しが成功した場合には、呼び出しフィードバック情報はＡＥ００であり、ノードＣの呼び出しフィードバック情報はＡＥ０１であり、ノードＡの呼び出しフィードバック情報はＡＥ１０である。これは、ノードＡを呼び出すためには、ノードＢの呼び出しが成功した後にノードＣを呼び出す必要があり、ノードＣを呼び出すためには、ノードＤを最初に呼び出す必要があることを示す。呼び出しフィードバック情報はログに記録することができ、これにより、或る特定時にサービスノードを呼び出す呼び出しトポロジ情報に問い合わせする場合に、呼び出しフィードバック情報にも問い合わせできるようになる。各サービスノードはいくつかの呼び出しフィードバック情報に対応しており、サービス呼び出しチェーンの後端の呼び出しフィードバック情報は、通常、サービス呼び出しチェーンの前端の呼び出しフィードバック情報に影響を及ぼすが、サービス呼び出しチェーンの前端にて呼び出しフィードバック情報の両端に集約を実行することができる。例えば、図９に示すサービスノードＡは、システムの異常に関する情報を戻し、これは、サービスノードＣ若しくはサービスノードＤにネットワークアクセス問題が生じている、又は、データベースに異常があることを示し得る。よって、各サービス呼び出しチェーンは呼び出しフィードバック情報の組み合わせであってよい。したがって、種々のサービス呼び出しチェーンについてエラーの所在を明確に特定するために、同じトポロジを有しサービス呼び出しモデルを構成するサービス呼び出しチェーンに集約を実行する場合、全ての呼び出しフィードバック情報の組み合わせがチェーン内に記録され、サービス呼び出しモデルに基づいた後続のデータ分析に用いられる。

【0077】

当業者は、前述の呼び出しフィードバック情報を記録する方法と呼び出しフィードバック情報を提示する方法とが、単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、呼び出しフィードバック情報を記録する方法と呼び出しフィードバック情報を提示する方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0078】

図７は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理デバイス内の処理装置を例示する概略図である。処理装置１３は、情報分析ユニット１３１と監視ユニット１３２を含む。

【0079】

情報分析ユニット１３１は、各サービス呼び出しチェーン内のサービスノードの呼び出しフィードバック情報に従って、サービス呼び出しトポロジに対応する１つ以上のサービス呼び出しチェーンについての統計を収集する。監視ユニット１３２は、対応する統計結果に従って、サービス呼び出しトポロジに対応するサービス呼び出しチェーンを監視する。

【0080】

具体的に、情報分析ユニット１３１は、各サービス呼び出しチェーン内のサービスノードの呼び出しフィードバック情報に従って、サービス呼び出しトポロジに対応する１つ以上のサービス呼び出しチェーンについての統計を収集する。つまり、サービス呼び出しモデルに対応するとともに同じサービス呼び出しトポロジを有する全てのサービス呼び出しチェーン内の呼び出しフィードバック情報を分析し、この呼び出しフィードバック情報についての統計を収集する。例えば、生成されたサービス呼び出しモデルとサービス呼び出しチェーンとのトポロジ関係に基づいて、同じサービス呼び出しトポロジを有する全てのサービス呼び出しチェーンを、サービス呼び出しモデルのマークでマーキングする。つまり、各サービス呼び出しモデルが特定のマークを有する。更に、各サービス呼び出しチェーン内のマークと呼び出しフィードバック情報の組み合わせとに関連して、各サービス呼び出しチェーンに一意のマークを割り当てる。サービス呼び出しチェーン内の呼び出しフィードバック情報についての統計を収集し、各サービス呼び出しチェーン内のサービスノードの呼び出しフィードバック情報の状態を、一定時間の間、チェーン比較又は並列比較により集合的に分析する。

【0081】

当業者は、前述の呼び出しフィードバック情報分析に基づくデータ分析方法が、単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、呼び出しフィードバック情報分析に基づくデータ分析方法が本願に該当する場合は、この別の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0082】

次に、監視ユニット１３２が、対応する統計結果に従って、サービス呼び出しトポロジに対応するサービス呼び出しチェーンを監視する。つまり、十分な数のデータサンプルが存在する場合は、サービス呼び出しトポロジ内の同じノードの呼び出しフィードバック情報どうしを比較し、一定の時間間隔にてデータを監視する。例えば、統計サンプルの９５％以上のデータは正常状態にある。システム内で５％の異常状況が生じた場合、システムはその異常を監視によって識別する。各サービス呼び出しノードについての呼び出しフィードバック情報が存在するので、監視により異常状態を識別した後に、特定のサービス呼び出しモデルに対応するサービス呼び出しチェーンの所在を特定できる。前述の実施例と同様に、各サービス呼び出しチェーンに対応する一意のマークに従って、特定のサービス呼び出しチェーンと、このサービス呼び出しチェーン内の呼び出されたサービスノードの所在とを特定する。

【0083】

当業者は、前述の分析結果に基づくサービス呼び出し監視方法が単なる実施例として用いられていることを理解すべきである。別の既存の又は将来登場する可能性のある、分析結果に基づくサービス呼び出し監視方法が本願に該当する場合は、この別の方法は本願の保護範囲に含まれ、参照によって本願に援用される。

【0084】

図８は、本願の更に別の好ましい実施の形態によるサービス呼び出し情報処理デバイス内の監視ユニットを例示する概略図である。監視ユニット１３２は比較サブユニット１３２１と警告サブユニット１３２２を含む。

【0085】

比較サブユニット１３２１は、所定の継続時間比較規則に基づいて、対応する統計結果を、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の各サービスノードの呼び出しフィードバック情報と比較する。差異が所定の変動閾値を超えると、警告サブユニット１３２２が、この差異に対応するサービス呼び出しチェーンについての警告情報を生成する。ここで、警告情報は、この差異に対応するサービスノードの所在を特定するために用いられる。

【0086】

具体的に、比較サブユニット１３２１が、所定の継続時間比較規則に基づいて、対応する統計結果を、サービス呼び出しトポロジに対応するサービス呼び出しチェーン内の各サービスノードの呼び出しフィードバック情報と比較する。つまり、特定の継続時間比較規則に従い、全てのサービス呼び出しチェーンの呼び出しフィードバック情報を同じサービス呼び出しトポロジに基づいて分析する。例えば、同じサービス呼び出しトポロジを有する全てのサービス呼び出しチェーン内の、午前８時から午前９時までに生成されたデータと、午前９時から午前１０時までに生成された呼び出しフィードバック情報とにチェーン比較分析を実行する。もう一つ例を挙げると、同じサービス呼び出しトポロジを有するサービス呼び出しチェーン内の、３月２日の午前８時から午前９時までに生成されたデータと、３月３日の午前８時から午前９時までに生成された呼び出しフィードバック情報とに並列比較分析を実行する。これにより、種々のシナリオにおいて正常作動中に生成された幅広いデータを取得できる。例えば、一日の決済失敗確率は、完了した決済において残高不足が１００回出現することを示す。次に、これらの分析結果に基づいて、システムにおけるサービス呼び出しステータスを監視できる。

【0087】

当業者は、前述の統計結果を取得及び比較する方法が、単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、統計結果を取得及び比較する方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0088】

次に、差異が所定の変動閾値を超えると、警告サブユニットが、この差異に対応するサービス呼び出しチェーンについての警告情報を生成する。ここで、この警告情報は、差異に対応するサービスノードの所在を特定するために用いられる。同じトポロジと同じサービスモデルとを有するサービス呼び出しチェーンを、呼び出しフィードバック情報に基づいて分析した後に、日常の作動中に生成された、同じトポロジを有するサービス呼び出しチェーンのデータを、様々なシナリオで正常作動中に生成されたデータの取得された範囲に従って監視し、特定の閾値に正常範囲を設定する。例えば、前述の実施例にあるように、一日の決済失敗確率が、完了した決済にて残高不足が１００回出現することを示す場合には、サービスノードの残高チェックについての失敗フィードバック回数の閾値を１００回又は１２０回よりも少なく、或いはこれと等しく設定する。システムにおいて残高チェックについてのサービスノードの一日の失敗フィードバック回数が設定された閾値を超えると警告が発せられ、その失敗ノードが、サービス呼び出しチェーン情報と呼び出しフィードバック情報とで形成されたグローバルな一意のマークに基づいて追跡される。

【0089】

当業者は、前述の監視する方法と警告する方法が単なる実施例として用いられていることを理解すべきである。その他の既存の又は将来登場する可能性のある、監視する方法と警告する方法が本願に該当する場合は、これらその他の方法は本願の保護範囲に含まれ、参照によって本願に援用されるものとする。

【0090】

当業者は、本願の精神と範囲から逸脱せずに、本願に様々な修正及び変更を加えられることは明らかである。本願は、本願に対するこれらの修正及び変更が、以下の特許請求の範囲及びそれらと均等な技術によって定義された保護範囲に収まる場合には、これらの修正及び変更を包含することが意図されている。

【0091】

本願はソフトウェア、及び／又はソフトウェアとハードウェアの組み合わせにて実施できることに留意すべきである。例えば、本願は、特定用途向け集積回路（ＡＳＩＣ）、汎用コンピュータ、又はあらゆるその他の類似のハードウェアデバイスを用いて実施することができる。実施の形態では、前述のステップ及び機能を実施するために、本願のソフトウェアプログラムをプロセッサによって実行することができる。同様に、本願におけるソフトウェアプログラム（関連のデータ構造を含む）は、コンピュータ読み出し可能な記憶媒体に記憶することができる。コンピュータ読み出し可能な記憶媒体には、例えばＲＡＭメモリ、ハードディスクドライブ又はＤＶＤ−ＲＯＭ／ＣＤ−ＲＯＭドライブ、又はフロッピーディスク及び類似のデバイスがある。加えて、本願のいくつかのステップ又は機能はハードウェアを用いて実施でき、このハードウェアには、例えばプロセッサと協働してこれらのステップ又は機能を実行する回路がある。

【0092】

加えて、本願の一部は、コンピュータプログラム命令のようなコンピュータプログラム製品として実施することができる。コンピュータプログラム命令がコンピュータによって実行されると、本願による方法及び／又は技術的解決方法を、コンピュータの操作によって呼び出す又は提供することができる。加えて、本願における方法を呼び出すプログラム命令は、固定記憶装置又はリムーバブル記憶装置に記憶することができ、及び／又は、他の信号搬送媒体における配信若しくはデータフローの手段によって伝送され、及び／又は、プログラム命令に従って作動するコンピュータデバイスのオペレーティングメモリに記憶される。このように、本願による実施の形態は装置を含み、この装置は、コンピュータプログラム命令を記憶するように構成されたメモリと、プログラム命令を実行するように構成されたプロセッサとを含む。コンピュータプログラム命令がプロセッサによって実行されると、コンピュータプログラム命令は、本願の複数の実施形態における前出の方法及び／又は技術的解決策に基づいて装置を作動させる。

【0093】

本願は前述の例示の実施の形態における詳細に限定されないことは明らかであり、本願は、本願の精神と基本的な特徴から逸脱せずに、別の特定の形式にて実施できることを当業者は理解すべきである。そのため、これらの実施の形態は例示的且つ非制限的とみなすべきであり、又、本願の範囲は前述の明細書本文に加えて添付の特許請求の範囲によって制限され、特許請求の範囲と均等な特許請求の範囲の意味及び範囲内に収まる全ての変更は本願に含まれるとみなす。特許請求の範囲におけるいかなる符号も、関連する特許請求の範囲の限定としてみなされるべきでない。加えて、用語「含む」はその他のユニット又はその他のステップを除外せず、単数形は複数形を除外しないことが明白である。装置の請求項にて記述されている複数のユニット及び装置は、ソフトウェア又はハードウェアを用いてユニット又は装置として実施することができる。「第１の」及び「第２の」のような用語は名称を表すために用いられており、何らの特定の順序を表すものではない。
［第１の局面］
サービス呼び出し情報処理方法であって：
ａ．分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するステップであって、各サービス呼び出しチェーンが、順次に呼び出される１つ以上のサービスノードを含む、分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するステップと；
ｂ．サービス呼び出しチェーンに従って対応するサービス呼び出しモデルを構成するステップと；
ｃ．前記サービス呼び出しモデルに従って前記サービス呼び出しチェーンを処理するステップと；を備える、
サービス呼び出し情報処理方法。
［第２の局面］
ステップａは：
分散型システムからサービス呼び出しログ情報を取得するステップと；
前記サービス呼び出しログ情報から１つ以上のサービス呼び出しチェーンを抽出するステップであって、前記サービス呼び出しチェーンのそれぞれは、順次に呼び出される１つ以上のサービスノードを備える、前記サービス呼び出しログ情報から１つ以上のサービス呼び出しチェーンを抽出するステップと；を備える、
第１の局面に記載の方法。
［第３の局面］
ステップｂは：
前記サービス呼び出しチェーンに集約処理を実行することにより、前記対応するサービス呼び出しモデルを構成するステップであって、前記サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、前記サービス呼び出しトポロジのそれぞれは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される、前記サービス呼び出しチェーンに集約処理を実行することにより、前記対応するサービス呼び出しモデルを構成するステップを備え；
ステップｃは：
前記対応するサービス呼び出しチェーンをサービス呼び出しトポロジに従って処理するステップを備える；
第１又は２の局面に記載の方法。
［第４の局面］
前記サービス呼び出しトポロジにクリーニング操作を実行するステップを更に備え；
ステップｃは：
クリーニング済みのサービス呼び出しトポロジに従って、前記対応するサービス呼び出しチェーンを処理するステップを備える、
第３の局面に記載の方法。
［第５の局面］
前記クリーニング操作は、以下のステップ：
前記サービス呼び出しトポロジ内の所定のサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内にあって、呼び出し結果情報を戻さないサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップであって、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内で低頻度で用いられるサービスノードの累積出現回数が所定の低頻度使用の閾値よりも少ない又はこれと等しい、前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップであって、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内で前記低頻度で用いられるサービスノードの累積出現回数は所定の低頻度使用の閾値よりも少ない、又はこれと等しく、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内の、前記低頻度で用いられるサービスノード以外の別のサービスノードの累積出現回数は、所定の高頻度使用の閾値よりも多い、又はこれと等しい、前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップと；のうちの少なくとも１つを備える、
第４の局面に記載の方法。
［第６の局面］
ステップｂは：
前記サービス呼び出しチェーン内の前記サービスノードの呼び出しフィードバック情報に関連した前記サービス呼び出しチェーンに集約処理を実行することにより、対応するサービス呼び出しモデルを構成するステップを備え、ここで、前記サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、前記サービス呼び出しトポロジのそれぞれは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される、
第３乃至５の局面のいずれかに記載の方法。
［第７の局面］
ステップｃは：
ｃ１．前記サービス呼び出しチェーンそれぞれのサービスノードの呼び出しフィードバック情報に従って、前記サービス呼び出しトポロジに対応する前記１つ以上のサービス呼び出しチェーンについての統計を収集するステップと；
ｃ２．対応する統計結果に従って、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーンを監視するステップと；を備える、
第６の局面に記載の方法。
［第８の局面］
ステップｃ２は：
所定の継続期間比較規則に基づいて、前記対応する統計結果を、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内の前記サービスノードそれぞれの呼び出しフィードバック情報と比較するステップと；
差異が所定の変動閾値を超えると、前記差異に対応するサービス呼び出しチェーンについての警告情報を生成するステップであって、前記警告情報は前記差異に対応するサービスノードの所在を特定する、差異が所定の変動閾値を超えると、前記差異に対応するサービス呼び出しチェーンについての警告情報を生成するステップと；を備える、
第７の局面に記載の方法。
［第９の局面］
サービス呼び出し情報処理デバイスであって：
分散型サービスシステム内の１つ以上のサービス呼び出しチェーンを取得するように構成されたサービス呼び出しチェーン取得装置であって、前記サービス呼び出しチェーンのそれぞれは、順次に呼び出される１つ以上のサービスノードを含む、サービス呼び出しチェーン取得装置と；
サービス呼び出しチェーンに従って、対応するサービス呼び出しモデルを構成するように構成されたサービス呼び出しモデル構成装置と；
前記サービス呼び出しモデルに従って、前記サービス呼び出しチェーンを処理するように構成された処理装置と；を備える、
サービス呼び出し情報処理デバイス。
［第１０の局面］
前記サービス呼び出しチェーン取得装置は：
分散型システムからサービス呼び出しログ情報を取得するように構成された呼び出し情報取得ユニットと；
前記サービス呼び出しログ情報から１つ以上のサービス呼び出しチェーンを抽出するように構成されたサービス呼び出しチェーン生成ユニットであって、前記サービス呼び出しチェーンのそれぞれは、順次に呼び出される１つ以上のサービスノードを含む、サービス呼び出しチェーン生成ユニットと；を備える、
第９の局面に記載のデバイス。
［第１１の局面］
前記サービス呼び出しモデル構成装置は：
前記サービス呼び出しチェーンに集約処理を実行することにより、前記サービス呼び出しモデルを構成するように構成され、前記サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを備え、前記サービス呼び出しトポロジのそれぞれは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得され；
前記処理装置は：
サービス呼び出しトポロジに従って、前記対応するサービス呼び出しチェーンを処理するように構成された、
第９又は１０の局面に記載のデバイス。
［第１２の局面］
前記サービス呼び出しトポロジにクリーニング操作を実行するように構成されたクリーニング装置を更に備え；
前記処理装置は：
クリーニング済みのサービス呼び出しトポロジに従って、前記対応するサービス呼び出しチェーンを処理するように構成された、
第１１の局面に記載のデバイス。
［第１３の局面］
前記クリーニング操作は、以下の：
前記サービス呼び出しトポロジ内の所定のサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内にあって、呼び出し結果情報を戻さないサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップであって、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内で低頻度で用いられるサービスノードの累積出現回数が所定の低頻度使用の閾値よりも少ない又はこれと等しい、前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップと；
前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップであって、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内で前記低頻度で用いられるサービスノードの累積出現回数は所定の低頻度使用の閾値よりも少ない又はこれと等しく、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内の、前記低頻度で用いられるサービスノード以外の別のサービスノードの累積出現回数は、所定の高頻度使用の閾値よりも多い又はこれと等しい、前記サービス呼び出しトポロジ内で低頻度で用いられるサービスノードを削除するステップと；のうちの少なくとも１つを備える、
第１２の局面に記載のデバイス。
［第１４の局面］
前記サービス呼び出しモデル構成装置は：
前記サービス呼び出しチェーン内の前記サービスノードの呼び出しフィードバック情報に関連した前記サービス呼び出しチェーンに集約処理を実行することにより、対応するサービス呼び出しモデルを構成し、ここで、前記サービス呼び出しモデルは１つ以上のサービス呼び出しトポロジを含み、前記サービス呼び出しトポロジのそれぞれは、１つ以上のサービス呼び出しチェーンに集約処理を実行することにより取得される、
第１１乃至１３の局面のいずれかに記載のデバイス。
［第１５の局面］
前記処理装置は：
前記サービス呼び出しチェーンのそれぞれの中のサービスノードの呼び出しフィードバック情報に従って、前記サービス呼び出しトポロジに対応する前記１つ以上のサービス呼び出しチェーンについての統計を収集するように構成された情報分析ユニットと；
対応する統計結果に従って、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーンを監視するように構成された監視ユニットと；を備える、
第１４の局面に記載のデバイス。
［第１６の局面］
前記監視ユニットは：
所定の継続時間比較規則に基づいて、前記対応する統計結果を、前記サービス呼び出しトポロジに対応する前記サービス呼び出しチェーン内の前記サービスノードのそれぞれの呼び出しフィードバック情報と比較するように構成された比較サブユニットと；
差異が所定の変動閾値を超えた場合に、前記差異に対応するサービス呼び出しチェーンについての警告情報を生成するように構成された警告サブユニットであって、前記警告情報は、前記差異に対応するサービスノードの所在を特定するために用いられる、警告サブユニットと；を備える、
第１５の局面に記載のデバイス。

【符号の説明】

【0094】

１ デバイス
１１ サービス呼び出しチェーン取得装置
１２ サービス呼び出しモデル構成装置
１３ 処理装置
１１１ 呼び出し情報取得ユニット
１１２ サービス呼び出しチェーン生成ユニット
１３１ 情報分析ユニット
１３２ 監視ユニット
１３２１ 比較サブユニット
１３２２ 警告サブユニット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】