JP2012068800A - 非同期処理サービス管理システム - Google Patents

Abstract

【課題】非同期処理での各サーバ・各業務アプリケーションの連携を追跡し、処理構成を可視化する非同期処理サービス管理システムを提供する。
【解決手段】業務サーバ１０は、業務ＡＰＬ１５が非同期処理により他の業務ＡＰＬ１５を呼び出す際にＡＴｘＩＤを発行するＡＴｘＩＤ発行部１２とログ出力部１３とを有し、第１の業務ＡＰＬ１５は、非同期処理により第２の業務ＡＰＬ１５から呼び出されたものである場合に、さらに非同期処理により第３の業務ＡＰＬ１５を呼び出した際に新たに発行した第１のＡＴｘＩＤを呼び出し元の第２のＡＴｘＩＤと関連付けてログ１４に出力し、管理サーバ２０は、各業務サーバ１０のログ１４に記録されたログを収集して収集ログ２３に記録するログ収集部２２と、ログを解析してＡＴｘＩＤの関連付けの情報に基づいて非同期処理における各業務ＡＰＬ１５間の連携を追跡し、処理構成に係る情報を取得する構成解析部２５とを有する。
【選択図】図１

Description

本発明は、複数のサーバにより提供される各機能の連携によりユーザに各種サービスを提供する情報処理システムにおける運用管理の技術に関し、特に、複数のサーバの各業務アプリケーションが非同期処理により連携して全体としてサービスを提供する情報処理システムにおける運用管理を行う非同期処理サービス管理システムに適用して有効な技術に関するものである。

近年では多くの業務（サービス）がコンピュータシステムでの情報処理により提供され、その際、多数のサーバ機器が利用されることも多い。これらのサーバ機器は、主にデータセンターなどの施設で運用管理される。このとき、これらのサーバ機器や設備をサービスの提供主体が所有して運用管理するのではなく、アウトソーシングにより外部のベンダー等に運用管理を委託する場合も多い。また、近年ではクラウドコンピューティング環境を利用して構築され運用される場合もある。

このようなシステム形態では、サーバ機器等およびその上で稼働する業務アプリケーションからなる情報システムの運用管理を担当する主体と、業務アプリケーションによって実現されるサービスの提供主体とが、契約によりＳＬＡ（Service Level Agreement）を締結し、運用管理側が一定のサービスレベルをサービスの提供主体に保証するということが行われる。

従って、運用管理側では、システムの稼働状況を監視して現状のサービスレベルを把握し、システムがＳＬＡを遵守しているか否かを判定するとともに、ＳＬＡを遵守できていない（もしくは遵守できなくなりそうな）場合には警告を発したり、ＳＬＡを遵守するために要求されるシステムの増強ポイントや構成変更ポイントなどを抽出したりすることが行われる。

これらに関する技術として、例えば、特開２００６−２５２１８９号公報（特許文献１）には、ビジネス環境の変化やＳＬＡの充足状況に応じて柔軟に機能・性能・信頼性といったサービスレベルを制御するアプリケーション運用管理方法に係る技術が記載されている。

特許文献１では、業務アプリケーション全体またはその一部は、部品であるソフトウェア・コンポーネントの組み合わせで構成され、個々のコンポーネントは、コンポーネントＤＢに格納されており、必要に応じて稼動環境にローディングされる。また、アプリケーションによるサービスは、システム運用ポリシー管理部によりそのポリシーが管理されて実施され、アプリケーションの稼動状況は、コンポーネント毎にランタイム・アプリケーション運用管理部により監視され、結果が監視履歴として蓄積される。この監視履歴とシステム運用ポリシーとを照らし合わせて業務アプリケーションの状態を診断し、この診断結果に基づいてアプリケーションを構成するコンポーネントの制御を行う。

特開２００６−２５２１８９号公報

現在の情報システム環境では、複数のサーバ上で稼働する業務アプリケーションプログラムおよびこれにより実現される機能の連携により全体として一つのサービスが実現されてユーザに提供される場合も多い。例えば、インターネットを介した株式取引のシステムにおいて、保有する株式を売却し、これにより得た資金で別の株式を購入する、という一連のサービスを想定した場合、株式売却、約定、口座入出金、株式購入等、複数の独立した汎用的な機能を実装する部品化された業務アプリケーションが連携して一連の処理が行われ、サービスとして実現される。

このとき、例えば、ＳＬＡ遵守の観点や、顧客からのサービスレベルに関する問い合わせに対する回答などの観点からは、当該サービスにおけるサービスレベルとしては、個別の業務アプリケーション単位ではなく、一連の処理全体もしくはその一部についてのＴＡＴ（Turn Around Time）や処理時間などを指標として把握することが必要となる。例えば、上記のサービスの例で、次の株式を購入するために、顧客から「売却した株式の金額が口座に入金されるのはいつか？」というような問い合わせを受けることが想定される。また、このような処理に要する処理時間の保証値をサービスレベルとしてＳＬＡに規定することも想定される。

ここで、サービスに係る一連の処理における各サーバ（機能）の連携が同期処理で行われる場合であれば、複数のサーバ間での一連の処理の制御は最終的に処理の開始元のサーバに戻ってくる。従って、一連の同期処理の終了時点を把握することは容易であり、ＴＡＴを算出することは容易である。

しかし、各サーバ（機能）の連携が非同期処理で行われる場合は、あるサーバは、連携のために他のサーバを呼び出した後は、その後どのように処理が行われているかについて関知しないため、処理の流れを追跡することは困難であり、一連の処理からなるサービスの終了タイミングや、全体に要した処理時間を把握することは困難である。従って、基本的には一連の非同期処理からなるサービスにおけるサービスレベルを保証することはできないが、顧客から上述したようなサービスレベルに関する問い合わせがあった場合などにはある程度の確度で処理時間等を回答できるようにしたいという要望がある。

また、非同期処理の場合、同期処理とは異なって処理経路が一直線であるとは限らず、処理内容に応じて複数のサーバ間での処理経路が分岐して、異なるサーバで同時並行的に処理が行われる場合も生じる。

しかし、これらの処理を行うサーバ機器の運用管理等を行う担当者は業務アプリケーションの開発者とは基本的に異なるため、サーバ（機能）間の連携関係、処理経路などの詳細を把握することができず、ブラックボックス化された状態で運用せざるを得ない場合も生じる。このような状況では、例えば、サーバから出力されたログ等を見ても、どのサーバのどの業務アプリケーションから出力されたものかは把握できても、この処理がどのサーバのどの機能から呼び出されて、次にどの機能が呼び出されるのかといった非同期処理の処理構成を運用管理者が把握するのは困難である。

なお、上記のような課題については、特許文献１などを含むシステムの運用監視における従来の技術では特に考慮されていないのが現状である。

そこで本発明の目的は、複数のサーバ上で稼働する業務アプリケーションによる非同期処理によってサービスを提供するシステムにおいて、非同期処理での各サーバもしくは各業務アプリケーションの連携を追跡可能とし、これによって非同期処理の処理構成を可視化する非同期処理サービス管理システムを提供することにある。また、本発明の別の目的は、サービスに係る一連の非同期処理全体もしくはその一部における処理時間の情報を取得する非同期処理サービス管理システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による非同期処理サービス管理システムは、複数の業務サーバ上でそれぞれ稼働する各業務アプリケーションでの非同期処理による連携によって提供されるサービスを管理する非同期処理サービス管理システムであって、以下の特徴を有するものである。

すなわち、非同期処理サービス管理システムは、前記各業務サーバとネットワークを介して接続可能であり、前記各業務サーバ上でそれぞれ稼働する前記各業務アプリケーションの稼働状況を把握し管理する管理サーバを有し、前記業務サーバは、当該業務サーバ上で稼働する業務アプリケーションが、非同期処理により他の業務サーバ上の業務アプリケーションを呼び出す際に、当該業務サーバ上で稼働する業務アプリケーションからの要求により、非同期処理毎に識別可能な非同期処理トランザクションＩＤを発行する非同期処理トランザクションＩＤ発行部と、当該業務サーバ上で稼働する業務アプリケーションからの要求により、ログ情報をログ記録装置に記録可能であるログ出力部とを有する。

第１の業務サーバ上で稼働する第１の業務アプリケーションは、非同期処理により第２の業務サーバ上で稼働する第２の業務アプリケーションから呼び出されたものである場合に、さらに非同期処理により第３の業務サーバ上で稼働する第３の業務アプリケーションを呼び出した際に、前記第１の業務サーバにおいて発行された第１の非同期処理トランザクションＩＤに係る情報を、呼び出し元の前記第２の業務サーバにおいて発行された第２の非同期処理トランザクションＩＤと関連付けて、前記第１の業務サーバ上の第１のログ出力部によって第１のログ記録装置に出力する。

また、前記管理サーバは、前記各業務サーバの前記ログ記録装置に記録されたログ情報を収集して収集ログ記録装置に記録するログ収集部と、前記収集ログ記録装置に記録されたログ情報を解析して、前記非同期処理トランザクションＩＤの関連付けの情報に基づいて、前記サービスを提供するための一連の非同期処理における前記各業務アプリケーション間の連携を追跡し、非同期処理の処理構成に係る情報を取得する構成解析部とを有する。

また、本発明の代表的な実施の形態による非同期処理サービス管理システムは、前記管理サーバが、さらに、前記サービスを提供するための一連の非同期処理の全体もしくは一部における前記各業務アプリケーションについての、前記ログ収集部に記録されたログ情報を解析して、前記非同期処理トランザクションＩＤの関連付けの情報に基づいて、前記各業務アプリケーション間の連携を追跡し、その処理時間の情報を取得する処理時間算出部を有することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、複数のサーバ上で稼働する業務アプリケーションによる非同期処理によってサービスを提供するシステムにおいて、非同期処理での各サーバもしくは各業務アプリケーションの連携を追跡可能とし、これによって非同期処理の処理構成を可視化することが可能となる。また、サービスに係る一連の非同期処理全体もしくはその一部における処理時間の情報を取得することが可能となる。

本発明の一実施の形態である非同期処理サービス管理システムの構成例について概要を示した図である。 本発明の一実施の形態における非同期処理の処理構成の例について概要を示した図である。 同期処理の処理構成の例について概要を示した図である。 非同期処理の処理構成の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
各業務アプリケーションによるサービスの提供を同期処理によって実現する構成の場合、ＳＬＡに規定された項目の一つとして、もしくは、顧客からの問い合わせに対する回答などの観点から、サービスに係る一連の処理についてのＴＡＴを取得するということは容易である。

図３は、同期処理の処理構成の例について概要を示した図である。図３では、４台の業務サーバ１０（業務サーバＡ（１０ａ）〜業務サーバＤ（１０ｄ））が同期処理により連携してサービスの提供に係る処理を行う場合の例を示している。例えば、一連の処理の最初として業務サーバＡ（１０ａ）で稼働する業務アプリケーション（ＡＰＬ） Ａ（１５ａ）が実行され、そこから同期的に業務サーバＢ（１０ｂ）で稼働する業務ＡＰＬ Ｂ（１５ｂ）が呼び出される。さらに、業務ＡＰＬ Ｂ（１５ｂ）の処理中に、同期的に業務サーバＣ（１０ｃ）で稼働する業務ＡＰＬ Ｃ（１５ｃ）が呼び出される。さらに、業務ＡＰＬ Ｃ（１５ｃ）の処理中に、同期的に業務サーバＤ（１０ｄ）で稼働する業務ＡＰＬ Ｄ（１５ｄ）が呼び出される。

業務ＡＰＬ Ｄ（１５ｄ）での処理が終了すると、処理の制御は呼び出し元の業務ＡＰＬ Ｃ（１５ｃ）に戻る。さらに、業務ＡＰＬ Ｃ（１５ｃ）での処理が終了すると、処理の制御は呼び出し元の業務ＡＰＬ Ｂ（１５ｂ）に戻る。同様に、業務ＡＰＬ Ｂ（１５ｂ）での処理が終了すると、処理の制御は呼び出し元の業務ＡＰＬ Ａ（１５ａ）に戻る。業務ＡＰＬ Ａ（１５ａ）での処理が終了すると、サービスの提供に係る一連の処理は終了する。

このとき、各業務サーバ１０は、一般的に、業務ＡＰＬ１５（業務ＡＰＬ Ａ（１５ａ）〜業務ＡＰＬ Ｄ（１５ｄ））での処理に係るログとして、例えば、処理の開始時と終了時にログ１４（ログＡ（１４ａ）〜ログＤ（１４ｄ））にレコードをそれぞれ出力する。従って、上記の一連の処理においては、業務サーバＡ（１０ａ）上のログＡ（１４ａ）に記録された、業務ＡＰＬ Ａ（１５ａ）の処理の開始と終了のログを参照することで、一連の同期処理の処理時間（ＴＡＴ）を取得することができる。また、ログＡ（１４ａ）に蓄積して記録されたログから統計情報を取得することにより、ＳＬＡの遵守状況を確認したり、顧客からの問い合わせに対して処理にかかる想定所用時間を回答したりすることが可能となる。

一方、図４は、非同期処理の処理構成の例について概要を示した図である。図４では、上述した図３と同様に、４台の業務サーバ１０が連携して、業務サーバＡ（１０ａ）から始まって業務サーバＤ（１０ｄ）までの一連の処理によってサービスの提供に係る処理を行う場合の例を示しているが、ここでは、各業務サーバ１０で稼働する業務ＡＰＬ１５が非同期処理により連携を行っている。

業務ＡＰＬ１５が他の業務ＡＰＬ１５を非同期処理により呼び出す際には、例えば、各業務ＡＰＬ１５（もしくは業務サーバＢ）に連携用のキューを設け、このキューに処理要求の電文を追加・挿入する。各業務ＡＰＬ１５は、対応するキューから電文を取り出し、電文に指定されたパラメータ等に基づいて処理を開始する。図４の例では、業務ＡＰＬ Ａ（１５ａ）は、処理要求の電文を業務サーバＢ（１０ｂ）（もしくは業務ＡＰＬ Ｂ（１５ｂ））のキュー１６ｂに追加する。業務ＡＰＬ Ｂ（１５ｂ）は、キュー１６ｂから処理要求の電文を随時取り出して処理を開始する。さらに、業務ＡＰＬ Ｂ（１５ｂ）は、処理要求の電文を業務サーバＣ（１０ｃ）（もしくは業務ＡＰＬ Ｃ（１５ｃ））のキュー１６ｃに追加する。業務ＡＰＬ Ｃ（１５ｃ）は、同様にキュー１６ｃから処理要求の電文を随時取り出して処理を開始する。

図４の例に示すような非同期処理では、同期処理の場合と異なり、一連の処理の終了は、処理を開始した業務ＡＰＬ Ａ（１５ａ）ではなく連携の末尾で呼び出された業務ＡＰＬ１５となる。このため、処理を開始した業務サーバＡ（１０ａ）上のログＡ（１４ａ）を解析しても、一連の処理の終了タイミングを把握することはできない。

また、非同期処理であることから、例えば、業務サーバＢ（１０ｂ）の業務ＡＰＬ Ｂ（１５ｂ）は、業務サーバＣ（１０ｃ）の業務ＡＰＬ Ｃ（１５ｃ）を呼び出すのと並行して（すなわち、業務ＡＰＬ Ｃ（１５ｃ）での処理が終了したか否かに関わらず）、業務サーバＤ（１０ｄ）の業務ＡＰＬ Ｄ（１５ｄ）を呼び出すことも可能である。例えば、このような処理構成が不明の状態で、業務サーバＤ（１０ｄ）のログＤ（１４ｄ）を参照した場合、業務ＡＰＬ Ｄ（１５ｄ）が呼び出されて実行されたことは把握できても、これが業務ＡＰＬ Ｂ（１５ｂ）から業務ＡＰＬ Ｃ（１５ｃ）を呼び出すのと並行して呼び出されたのか、もしくは、業務ＡＰＬ Ｃ（１５ｃ）から呼び出されたのかが把握できない（業務ＡＰＬ Ａ（１５ａ）から呼び出された可能性や、クライアント端末５０から最初に呼び出された可能性もある）。

従って、ある一つの一連の処理を特定して、その処理経路を追跡して把握し、処理に要した時間を算出するということは非常に困難である。例えば、「（業務ＡＰＬ Ａ（１５ａ）によって）売却した株式の金額が（業務ＡＰＬ Ｄ（１５ｄ）によって）口座に入金されるのはいつか？」というような問い合わせに対する回答のように、業務ＡＰＬ Ａ（１５ａ）での処理から業務ＡＰＬ Ｄ（１５ｄ）での処理までに要する処理時間を算出する際に、各業務サーバ１０での業務ＡＰＬ１５の平均処理時間をログ１４から取得してこれを積み上げて算出する、という手法をとることができない。

そこで、本発明の一実施の形態である非同期処理サービス管理システムでは、各業務サーバで非同期処理が発生する度に、これに対して非同期処理トランザクションＩＤ（以下では「ＡＴｘＩＤ」と記載する場合がある）を発行し、これをログ１４やジャーナル等に出力する。このＡＴｘＩＤに基づいて一連の非同期処理における各業務サーバ１０（業務ＡＰＬ１５）での処理を関連付けることで連携を追跡可能とし、これによって非同期処理の処理構成を可視化するとともに、サービスに係る一連の処理全体もしくはその一部における処理時間の情報を取得することを可能とする。

＜システム構成＞
図１は、本発明の一実施の形態である非同期処理サービス管理システムの構成例について概要を示した図である。非同期処理サービス管理システム１は、データセンター等、複数の業務サーバ１０を運用管理するサイトにて構築され、例えば、複数の業務サーバ１０と、管理サーバ２０およびＰＣ（Personal Computer）等からなる運用端末３０が、ＬＡＮ（Local Area Network）等の内部ネットワーク４１に接続された構成を有する。また、業務サーバ１０には、インターネット等のネットワーク４２を経由して、ＰＣ等からなる複数のクライアント端末５０がアクセス可能な構成となっている。

業務サーバ１０は、単独もしくは他の業務サーバ１０と連携して、クライアント端末５０を介してユーザにサービスの提供を行うサーバ機器であり、例えば、基盤部１１、ＡＴｘＩＤ発行部１２、ログ出力部１３、および業務アプリケーション（ＡＰＬ）１５の各ソフトウェア、およびデータベースやファイル等からなるログ１４を有する。

基盤部１１は、ＯＳ（Operating System）やＷｅｂサーバプログラム、データベース管理プログラムなどの各種ミドルウェア等からなり、業務サーバ１０の基盤機能を提供する。ＡＴｘＩＤ発行部１２は、後述する業務ＡＰＬ１５から呼び出され、業務ＡＰＬ１５が非同期処理により他の業務ＡＰＬ１５を呼び出す際にこれに対して割当てるＡＴｘＩＤを発行する。ＡＴｘＩＤのフォーマットは特に何らかのものに限定されるものではないが、少なくとも、どの業務ＡＰＬ１５（もしくは業務サーバ１０）からの要求により発行されたかを識別可能であり、さらに、シーケンス番号等により、同一の業務ＡＰＬ１５からの要求により発行されたものがそれぞれ識別可能となることが必要である。

ログ出力部１３は、業務ＡＰＬ１５から呼び出され、業務ＡＰＬ１５での処理に伴うログの出力要求を受けて、これをログ１４に出力する。ログ出力部１３は、業務ＡＰＬ１５の中に組み込まれて実装されていてもよい。業務ＡＰＬ１５は、例えば他の業務サーバ１０の業務ＡＰＬ１５と連携して、ユーザに対するサービスの提供に係る処理を実行する。他の業務サーバ１０との連携については、同期処理、非同期処理いずれを利用するものであってもよい。なお、業務ＡＰＬ１０は、必ずしも全てがクライアント端末５０からその機能に直接アクセス可能である必要はなく、他の業務ＡＰＬ１０からのみ呼び出されて利用されるものを有していてもよい。

業務ＡＰＬ１５は、上述したように、非同期処理により他の業務ＡＰＬ１５を呼び出す際に、ＡＴｘＩＤ発行部１２によりＡＴｘＩＤの発行を受けて取得する。取得したＡＴｘＩＤの情報は、ログ出力部１３を介してログ１４に出力する。この限りにおいて、各業務ＡＰＬ１５を本実施の形態の非同期処理サービス管理システム１での管理対象とするには、改修により、もしくは初期開発当初からこのような機能を実装しておく必要がある。

一方、管理サーバ２０は、各業務サーバ１０のログ１４を収集して解析・集計することによって、各業務ＡＰＬ１５の稼働状況を把握・管理するサーバ機器であり、例えば、基盤部２１、ログ収集部２２、処理時間算出部２４、構成解析部２５、および表示部２６の各ソフトウェア、およびデータベースやファイル等からなる収集ログ２３を有する。この管理サーバ２０は、各業務ＡＰＬ１５によって提供される非同期処理サービスにおける各業務ＡＰＬ１５間の連携を追跡し、その処理構成を把握して可視化するとともに、サービスに係る一連の処理全体もしくはその一部における処理時間の情報（サービスレベル）を取得する。

基盤部２１は、業務サーバ１０の基盤部１１と同様に、ＯＳやＷｅｂサーバプログラム、データベース管理プログラムなどの各種ミドルウェア等からなり、管理サーバ２０の基盤機能を提供する。ログ収集部２２は、各業務サーバ１０のログ１４からログデータを収集して収集ログ２３に格納する。収集のタイミングや手法は要件に応じて適宜設定可能である。例えば、定期的にログ収集部２２が各業務サーバ１０のログ１４からログ出力部１３を介して該当するログデータを抽出して収集する構成としたり、逆に各業務サーバ１０のログ出力部１３が管理サーバ２０のログ収集部２２にほぼリアルタイムでログを送信する構成としたりなどが考えられる。

処理時間算出部２４は、収集ログ２３に格納されたログデータを解析して、運用端末３０を介した運用担当者等からの指示に従って、指定されたサービスに係る一連の処理全体もしくはその一部における処理時間の情報を取得することを可能とする。ここでは、単独の業務処理（トランザクション）についての処理時間の情報を取得可能であるとともに、複数回実行された業務処理についての各処理時間の情報を集計することで統計情報を算出可能とし、サービス全体でのＳＬＡの遵守状況の確認等に利用できるようにしてもよい。

構成解析部２５は、収集ログ２３に格納されたログデータを解析して、サービスを提供するための一連の非同期処理における各業務ＡＰＬ１５間の連携を追跡し、非同期処理の処理構成を取得する。例えば、任意のサービスに係る一連の非同期処理について、各業務ＡＰＬ１５の呼び出し元と呼び出し先の対応、およびその順序の情報を取得する。この情報により、運用担当者等は、例えば、非同期処理の処理構成がブラックボックス化された状態で開発担当者等から引き渡しを受けて運用を開始することになったような場合であっても、処理構成に係る情報を把握する、すなわち論理的に可視化することができる。

さらに、表示部２６は、構成解析部２５で取得した処理構成の情報に基づいて、これを運用端末３０のグラフィカルインタフェース上に可視化して表示する。これにより、非同期処理の処理構成を物理的にも可視化することができる。なお、表示部２６では、例えば、任意のエンティティ（本実施の形態では業務ＡＰＬ１５もしくは業務サーバ１０）について関連（本実施の形態では業務ＡＰＬ１５の呼び出し）を有するもの同士を線分や矢印等で連結して表示用データとし、運用端末３０上のＷｅｂブラウザ等に表示するような既存の技術を利用することができる。

＜非同期処理の処理構成の把握手法＞
図２は、本実施の形態における非同期処理の処理構成の例について概要を示した図である。本実施の形態では、上述したように、業務ＡＰＬ１５が非同期処理として他の業務ＡＰＬ１５を呼び出す際、ＡＴｘＩＤ発行部１２によりＡＴｘＩＤが発行され、これをログ１４に出力する。例えば、図中の業務サーバＡ（１０ａ）では、業務ＡＰＬ Ａ（１５ａ）が業務サーバＢ（１０ｂ）の業務ＡＰＬ Ｂ（１５ｂ）を非同期処理として呼び出す際に、ＡＴｘＩＤ発行部１２によりＡＴｘＩＤ＝“Ａ００１”が発行され、この情報を追加した処理要求の電文をキュー１６ｂに追加することで、業務ＡＰＬ Ｂ（１５ｂ）を呼び出す。

このとき、業務ＡＰＬ Ａ（１５ａ）は、このＡＴｘＩＤ＝“Ａ００１”により非同期処理を呼び出した（開始した）旨をログＡ（１４ａ）に記録する。なお、本実施の形態では、ＡＴｘＩＤは、例えば、各業務ＡＰＬ１５を識別可能な文字列（“Ａ”、“Ｂ”、…）にシーケンス番号（“００１”、“００２”、…）を付加したフォーマットとしている。

業務サーバＢ（１０ｂ）では、業務ＡＰＬ Ｂ（１５ｂ）がキュー１６ｂから処理要求の電文を随時取り出して処理を開始する。当該処理の中で、業務ＡＰＬ Ｂ（１５ｂ）は、業務サーバＣ（１０ｃ）の業務ＡＰＬ Ｃ（１５ｃ）を非同期処理として呼び出すため、処理要求の電文を業務サーバＣ（１０ｃ）（もしくは業務ＡＰＬ Ｃ（１５ｃ））のキュー１６ｃに追加する。このとき、業務サーバＢ（１０ｂ）のＡＴｘＩＤ発行部１２によりＡＴｘＩＤ＝“Ｂ００１”が発行され、このＡＴｘＩＤにより非同期処理を呼び出した（開始した）旨をログＢ（１４ｂ）に記録する。

さらに、業務サーバＤ（１０ｄ）の業務ＡＰＬ Ｄ（１５ｄ）を非同期処理として呼び出すため、業務サーバＤ（１０ｄ）（もしくは業務ＡＰＬ Ｄ（１５ｄ））のキュー１６ｄにも非同期処理の処理要求の電文を追加する。このとき、業務サーバＢ（１０ｂ）のＡＴｘＩＤ発行部１２によりＡＴｘＩＤ＝“Ｂ００２”が発行され、このＡＴｘＩＤにより非同期処理を呼び出した（開始した）旨をログＢ（１４ｂ）に記録する。

なお、ログＢ（１４ｂ）に非同期処理を呼び出した旨を記録する際、呼び出し元との連携の関係が把握可能となるよう、呼び出し元となった処理のＡＴｘＩＤ（図２の業務サーバＢ（１０ｂ）の例ではいずれも呼元ＡＴｘＩＤ＝“Ａ００１”）の情報を追加して関連付ける。この呼び出し元となった処理のＡＴｘＩＤの情報を参照することにより、対象の業務処理における、各業務ＡＰＬ１５間の処理の連携を追跡することが可能となる。

その後、業務ＡＰＬ Ｂ（１５ｂ）が業務ＡＰＬ Ａ（１５ａ）から呼び出された非同期処理を終了する際、その旨をログ１４ｂに記録する。その際、当該処理のＡＴｘＩＤ＝“Ａ００１”の情報についても記録する。以上の処理は、さらに非同期処理によって呼び出された業務ＡＰＬ Ｃ（１５ｃ）および業務ＡＰＬ Ｄ（１５ｄ）についても同様である。

ここで、例えば、「（業務ＡＰＬ Ａ（１５ａ）によって）売却した株式の金額が（業務ＡＰＬ Ｄ（１５ｄ）によって）口座に入金されるのはいつか？」というようなサービスレベルについての問い合わせに対して回答するような場合、業務ＡＰＬ Ａ（１５ａ）での処理の開始から、非同期処理による連携によって呼び出された業務ＡＰＬ Ｄ（１５ｄ）での処理の終了までの処理時間（の統計情報）を取得する必要がある。

この処理時間を算出する手法としては種々のものが考え得るが、例えば、管理サーバ２０の処理時間算出部２４は、収集ログ２３を参照し、まず、対象のサービスに係る非同期処理の連携における末尾の処理（当該例では業務ＡＰＬ Ｄ（１５ｄ））に対応する開始・終了のログを取得してその処理時間を算出する。また、収集ログ２３から当該処理において出力された非同期処理の終了のログを検索して取得する。図２の例では、業務サーバＤ（１０ｄ）のログ１４ｄに出力されたＡＴｘＩＤ＝“Ｂ００２”の終了ログが取得できる。

次に、対象の処理について遡って、収集ログ２３からＡＴｘＩＤ＝“Ｂ００２”の開始ログを検索して取得する。図２の例では、業務サーバＢ（１０ｂ）のログ１４ｂに出力されたＡＴｘＩＤ＝“Ｂ００２”の開始ログが取得できる。ここで、当該開始ログに対応する業務処理（業務ＡＰＬ Ｂ（１５ｂ）での処理）の処理時間を、当該業務処理の開始・終了のログに基づいて算出する。

図２の例では、当該開始ログにその呼び出し元がＡＴｘＩＤ＝“Ａ００１”の処理である旨の情報が追加されている。従って、当該業務処理は、さらに呼び出し元の処理（ＡＴｘＩＤ＝“Ａ００１”）から非同期処理によって呼び出されたものであることが分かる。

なお、本実施の形態では、当該開始ログに呼び出し元のＡＴｘＩＤの情報を追加することで関連付けるようにしているが、当該開始ログに対応する取引処理がさらに他の業務ＡＰＬ１５から非同期処理により呼び出されたものである場合、当該取引処理の一連のログには、呼び出し元の非同期処理の終了ログ（図２の例ではログ１４ｂにおけるＡＴｘＩＤ＝“Ａ００１”の終了ログ）が出力されているはずである。従って、その有無を検索することによっても、当該取引処理が非同期処理として呼び出されたものであるか否かを判断することができる（すなわち、当該取引処理の一連のログの中に含まれている、ということによって黙示的に関連付けられる）。

次に、対象の処理についてさらに遡って、収集ログ２３からＡＴｘＩＤ＝“Ａ００１”の開始ログを検索して取得する。図２の例では、業務サーバＡ（１０ａ）のログ１４ａに出力されたＡＴｘＩＤ＝“Ａ００１”の開始ログが取得できる。ここで、当該開始ログに対応する業務処理（業務ＡＰＬ Ａ（１５ａ）での処理）の処理時間を、当該業務処理の開始・終了のログに基づいて算出する。ここで、業務ＡＰＬ Ａ（１５ａ）は、処理時間を求める対象である一連の非同期処理における先頭の処理であるため、ここで連携の追跡は終了する。

このとき、上記で算出した、業務ＡＰＬ Ｄ（１５ｄ）、業務ＡＰＬ Ｂ（１５ｂ）、業務ＡＰＬ Ａ（１５ａ）における各処理時間を合算することで、一連の非同期処理での連携における各業務サーバ１０での処理時間の合計を得ることができる。

なお、上記のような処理時間の算出方法では、業務サーバ１０において実際に処理をしている時間の合計を得ることができるが、処理負荷が高いシステム環境などでは、各業務サーバ１０での処理に時間を要し、各キュー１６に処理要求の電文が滞留するという場合も生じ得る。このとき、上記のような処理時間の算出方法では、キュー１６に処理要求の電文が滞留している時間が含まれない。そこで、上記の例では、一連の非同期処理の連携における末尾の業務処理（業務ＡＰＬ Ｄ（１５ｄ）での処理）の終了のログを取得し、非同期処理の連携を追跡して、その先頭の業務処理（業務ＡＰＬ Ａ（１５ａ）での処理）の開始のログを取得して、これらのログのタイムスタンプの差分によって全体での処理時間を算出することができる。

例えば、この全体での処理時間と、各業務サーバ１０（業務ＡＰＬ１５）での処理時間の合計との差分を求めることにより、キュー１６に処理要求が滞留している時間を把握することができる。また、各業務処理でのログのタイムスタンプの差分を解析することにより、非同期処理毎の各キュー１６での滞留時間を把握することも可能である。これらにより、一連の非同期処理におけるボトルネックの有無や、その場所等を解析するということも可能である。

また、管理サーバ２０の構成解析部２５は、各種の業務処理（サービス）について、例えば、対象範囲を限定せずに収集ログ２３から一連の非同期処理の連携を上記と同様の手順によって追跡し、その関係を記録することで、各サービスについての非同期処理の処理構成に係る情報を得ることができる。また、表示部２６は、構成解析部２５によって得られた情報に基づいて、例えば、サービス毎に各業務ＡＰＬ１５（もしくは業務サーバ１０）とその連携の関係をフロー図のような形式で画面表示するなどにより可視化する。

以上に説明したように、本発明の一実施の形態である非同期処理サービス管理システム１によれば、各業務サーバ１０（業務ＡＰＬ１５）で非同期処理が発生する度に、これに対してＡＴｘＩＤを発行し、これをログ１４やジャーナル等に出力する。呼び出された業務サーバ１０（業務ＡＰＬ１５）において、さらに非同期処理が発生する際、新たに発行したＡＴｘＩＤと、呼び出し元の業務サーバ１０（業務ＡＰＬ１５）で発行されたＡＴｘＩＤの情報とを関連付けてログ１４に出力する。

管理サーバ２０においてこれらのログ情報を収集し、解析して集計することで、一連の非同期処理での各業務サーバ１０（業務ＡＰＬ１５）の連携を追跡可能とし、これによって非同期処理の処理構成を可視化するとともに、サービスに係る一連の処理全体もしくはその一部における処理時間の情報を取得することが可能となる。

これにより、運用担当者においてＳＬＡの遵守状況をアプリケーション的な観点からもある程度把握することが可能となり、また、各業務ＡＰＬ１５での処理時間に加えて非同期処理の際のキューでの滞留時間の情報などに基づいて、パフォーマンスやキャパシティ上のチューニングポイント（ボトルネック）等を把握することも可能となる。

また、既存の各業務ＡＰＬ１５は、非同期処理により他の業務ＡＰＬ１５を呼び出す際に、ＡＴｘＩＤ発行部１２にＡＴｘＩＤの発行を依頼して取得し、これを含むログをログ１４に出力するという微少な改修のみで容易に非同期処理サービス管理システム１での管理対象とすることが可能であり、各業務ＡＰＬ１５の既存の処理への影響と、開発担当者・運用担当者の作業負荷を最小限に抑えることが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、複数のサーバの各業務アプリケーションが非同期処理により連携して全体としてサービスを提供する情報処理システムにおける運用管理を行う非同期処理サービス管理システムに利用可能である。

１…非同期処理サービス管理システム、
１０（１０ａ〜ｄ）…業務サーバ（Ａ〜Ｄ）、１１…基盤部、１２…非同期処理トランザクションＩＤ（ＡＴｘＩＤ）発行部、１３…ログ出力部、１４（１４ａ〜ｄ）…ログ（Ａ〜Ｄ）、１５（１５ａ〜ｄ）…業務アプリケーション（ＡＰＬ）（Ａ〜Ｄ）、１６（１６ａ〜ｄ）…キュー、
２０…管理サーバ、２１…基盤部、２２…ログ収集部、２３…収集ログ、２４…処理時間算出部、２５…構成解析部、２６…表示部、
３０…運用端末、
４１…内部ネットワーク、４２…ネットワーク、
５０…クライアント端末。

Claims (4)

1. 複数の業務サーバ上でそれぞれ稼働する各業務アプリケーションでの非同期処理による連携によって提供されるサービスを管理する非同期処理サービス管理システムであって、
   前記各業務サーバとネットワークを介して接続可能であり、前記各業務サーバ上でそれぞれ稼働する前記各業務アプリケーションの稼働状況を把握し管理する管理サーバを有し、
   前記業務サーバは、
   当該業務サーバ上で稼働する業務アプリケーションが、非同期処理により他の業務サーバ上の業務アプリケーションを呼び出す際に、当該業務サーバ上で稼働する業務アプリケーションからの要求により、非同期処理毎に識別可能な非同期処理トランザクションＩＤを発行する非同期処理トランザクションＩＤ発行部と、
   当該業務サーバ上で稼働する業務アプリケーションからの要求により、ログ情報をログ記録装置に記録可能であるログ出力部とを有し、
   第１の業務サーバ上で稼働する第１の業務アプリケーションは、非同期処理により第２の業務サーバ上で稼働する第２の業務アプリケーションから呼び出されたものである場合に、さらに非同期処理により第３の業務サーバ上で稼働する第３の業務アプリケーションを呼び出した際に、前記第１の業務サーバにおいて発行された第１の非同期処理トランザクションＩＤに係る情報を、呼び出し元の前記第２の業務サーバにおいて発行された第２の非同期処理トランザクションＩＤと関連付けて、前記第１の業務サーバ上の第１のログ出力部によって第１のログ記録装置に出力し、
   前記管理サーバは、
   前記各業務サーバの前記ログ記録装置に記録されたログ情報を収集して収集ログ記録装置に記録するログ収集部と、
   前記収集ログ記録装置に記録されたログ情報を解析して、前記非同期処理トランザクションＩＤの関連付けの情報に基づいて、前記サービスを提供するための一連の非同期処理における前記各業務アプリケーション間の連携を追跡し、非同期処理の処理構成に係る情報を取得する構成解析部とを有することを特徴とする非同期処理サービス管理システム。
2. 請求項１に記載の非同期処理サービス管理システムにおいて、
   前記管理サーバは、さらに、前記サービスを提供するための一連の非同期処理の全体もしくは一部における前記各業務アプリケーションについての、前記ログ収集部に記録されたログ情報を解析して、前記非同期処理トランザクションＩＤの関連付けの情報に基づいて、前記各業務アプリケーション間の連携を追跡し、その処理時間の情報を取得する処理時間算出部を有することを特徴とする非同期処理サービス管理システム。
3. 請求項１または２に記載の非同期処理サービス管理システムにおいて、
   前記管理サーバは、さらに、前記構成解析部によって取得された前記サービスを提供するための一連の非同期処理の処理構成に係る情報に基づいて、これを可視化して運用端末上に表示させる表示部を有することを特徴とする非同期処理サービス管理システム。
4. 請求項２に記載の非同期処理サービス管理システムにおいて、
   前記管理サーバの前記処理時間算出部は、前記サービスを提供するための一連の非同期処理の全体もしくは一部における前記各業務アプリケーションについての、前記ログ収集部に記録されたログ情報におけるタイムスタンプの差分を解析することにより、前記各業務アプリケーション間の呼び出しに利用されるキューでの滞留時間を取得することを特徴とする非同期処理サービス管理システム。