JP2006099308A - コンポーネントベース・アプリケーション構築方法 - Google Patents

Abstract

【課題】コンポーネントベース・アプリケーションの構築時に信頼性の評価を行い、要求される信頼性を実現するアプリケーションを効率的に構築することを可能とする。
【解決手段】ソフトウェア・コンポーネント毎にエラーの発生頻度・エラー発生時に復旧に要する時間・予防保守実行時の処理能力などの実行時履歴をアプリケーションＩＤ・組み合わせたコンポーネントＩＤ・実行したハードウェアＩＤなどの実行環境毎に記録された実行時履歴表を付加し、これらの情報からシステム構築時に個々のソフトウェア・コンポーネント毎に推奨される予防保守実行の間隔を算出し、またソフトウェア・コンポーネント毎の信頼性をシステムに要求される信頼性と比較して適否の判定・適合度の評価を行う。さらに、システム全体での信頼性・処理能力の算出をしてシステム全体として要求される信頼性・処理性能と比較して適否の判定・適合度の評価を行う。
【選択図】図１

Description

本発明は、コンポーネント化されたソフトウェア部品（ソフトウェア・コンポーネント）を組み合わせてアプリケーションを構築する方法で、ソフトウェア・コンポーネント毎の信頼性に関する実行履歴の取得・蓄積方法と、それを利用した高信頼システムの構築方法に関する。

インターネット・イントラネット上での電子商取引や社内情報処理システムなどのＷｅｂサービスに代表されるオンラインアプリケーションの利用が急速に広まっており、顧客拡大・運用効率化・コスト削減などの要求に応じて迅速かつ柔軟なシステム開発が求められている。そのため、ＥＪＢに代表されるソフトウェア・コンポーネントを組み合わせてアプリケーションを構築する技術が注目をあびている。このような方法で構築されたアプリケーションをコンポーネントベース・アプリケーションと呼ぶ。

コンポーネントベース・アプリケーションは、よく利用される処理を行うソフトウェア・コンポーネントをあらかじめ用意し、それらを組み合わせることで構築できるので、開発時間を短縮することが可能である。また、動的に変化する顧客要求に応じてアプリケーションを改良する場合には、変更箇所のソフトウェア・コンポーネントを交換することで対応できるので、迅速かつ柔軟な改良が可能である。
コンポーネントベース・アプリケーションの開発はこのような特長をもっており、さらにＪ２ＥＥ（Ｊａｖａ２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）（Ｊａｖａは登録商標）のような標準フレームワークの登場により、広く利用されるようになってきている。その結果として、今後様々なソフトウェア・コンポーネントが開発され、蓄積されていくと考えられる。

システム構築においては、これらのソフトウェア・コンポーネントから必要とされる機能を持つソフトウェア・コンポーネントを検索する必要があるが、ソフトウェア・コンポーネントの充実に伴って、機能的には同等なソフトウェア・コンポーネントが複数見つかる可能性が出てくる。そのため、これら複数の候補ソフトウェア・コンポーネントから最適なものを迅速かつ的確に選択する技術が重要になってくる。
ソフトウェア・コンポーネントの１つの選択指標としては、システム性能が挙げられる。しかしシステム構築時にソフトウェア・コンポーネントを組み合わせた際のシステム性能を予測することは難しい。

特許文献１では、コンポーネントベース・アプリケーションにおいて、個々のソフトウェア・コンポーネントで処理を行った場合のＣＰＵ時間を基本動作性能として測定し、その測定値を基に想定される処理における処理性能（ＣＰＵ時間）を予測する方法について述べている。この方法によれば、通常の処理におけるシステムの処理性能がシステム全体を組み上げる前に予測可能であるとしている。

ソフトウェア・コンポーネントの別の選択指標としては、システムの信頼性が挙げられる。特に業務システムにおいては、システムの信頼性は重要な指標であり、システム性能がハードウェアの追加などの対策で改善可能な場合が多いのに対して、システムの信頼性は同様の対策が困難である場合が多い。特にコンポーネントベース・アプリケーションでは、ソフトウェア・コンポーネントの組み合わせによって信頼性が低下する場合もあり、システムの信頼性を予測することは難しい。

特許文献２では、コンポーネントベース・アプリケーションにおいて、ソフトウェア・コンポーネント毎に処理の開始・終了時刻を計測することで処理時間を測定し、一定の処理時間を超過した場合に異常状態と判定するなどして、対処手続きを行うとしている。対処手続きとしては、コンポーネントの停止やサーバプロセスの再起動などであり、システムの運用時にシステムの信頼性を監視し、異常時の対処をする方法が示されている。あわせて特許文献２ではシステム運用時におけるシステム性能を監視する方法についても示されている。

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

特開２００２−８２９２６号公報 Ａ Ｍｉｃｒｏｒｅｂｏｏｔａｂｌｅ Ｓｙｓｔｅｍ − Ｄｅｓｉｇｎ， Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ， ａｎｄ Ｅｖａｌｕａｔｉｏｎ． Ｇｅｏｒｇｅ Ｃａｎｄｅａ ｅｔ ａｌ．， Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ２００４

以上に示したように、コンポーネントベース・アプリケーションの構築時におけるシステム性能予測方法、運用時におけるシステムの信頼性・性能の監視方法については公知であるが、コンポーネントベース・アプリケーションの構築時にシステムの信頼性を考慮してシステム構築を行う手法については効果的な方法がなかった。これは個々のソフトウェア・コンポーネントの信頼性をそのソフトウェア・コンポーネントを構築する際に評価することはできても、コンポーネントベース・アプリケーションにおいてシステム全体を組み上げる前にシステム全体の信頼性を評価する効果的な方法の開発が困難であったためであるが、コンポーネントベース・アプリケーションにおける信頼性の向上については最近新しいアプローチが検討されており、このアプローチの利用などを含めてシステムの構築時にシステムに要求される信頼性を考慮したシステム構築を行う効果的な手法を示すのが本発明の課題である。

前期の新しいアプローチは非特許文献１に示されている。非特許文献１では、コンポーネントベース・アプリケーションにおいて、コンポーネント単位でのリブート（マイクロリブート）によって、アプリケーション全体のリブート（フルリブート）に対して障害発生時により小さいコストでシステムを復旧させることが可能であることが示されており、特に完全なシステムダウンを回避できる可能性が高い点がシステムの信頼性向上の点で大きな意味を持つ。さらに、システムが正常に動作している間にも、マイクロリブートによりコンポーネント単位でのリブートを行うことで予防保守としてシステムの信頼性を向上させる方法が示されている。非特許文献１では予防保守としてマイクロリブートを行うコンポーネントは、コンポーネントのメモリ使用量の推移によって選択されている。

本願において開示される発明のうち、代表的なものの概要を説明すれば、次のとおりである。
アプリケーションをソフトウェア部品であるソフトウェア・コンポーネントの組み合わせで構築する際に、システムに要求される信頼性を確保しつつ効率的にアプリケーションを構築する方法を提供するために、ソフトウェア・コンポーネント毎にエラーの発生頻度・エラー発生時に復旧に要する時間・予防保守実行時の処理能力などの実行時履歴をアプリケーションＩＤ・組み合わせたコンポーネントＩＤ・実行したハードウェアＩＤなどの実行環境毎に記録された実行時履歴表を付加し、これらの情報からシステム構築時に個々のソフトウェア・コンポーネント毎に推奨される予防保守実行の間隔を算出し、またソフトウェア・コンポーネント毎の信頼性をシステムに要求される信頼性と比較して適否の判定・適合度の評価を行う。さらに、ソフトウェア・コンポーネントを組み合わせて作られたコンポーネントベース・アプリケーション全体での予防保守の実行スケジュールの算出と処理能力の算出を行い、またシステム全体での信頼性・処理能力の算出をしてシステム全体として要求される信頼性・処理性能と比較して適否の判定・適合度の評価を行う。

以上の判定・評価を行うために、ソフトウェア・コンポーネント毎に実行時履歴表を付加する手段、ソフトウェア・コンポーネント毎のエラー発生頻度・エラー発生時に復旧に要する時間・予防保守実行時の処理能力をコンポーネントベース・アプリケーション実行時に計測する手段もしくは試験的にコンポーネントベース・アプリケーションを実行して計測する手段、ソフトウェア・コンポーネント毎の実行時履歴表からソフトウェア・コンポーネント毎およびシステム全体での信頼性・処理能力の算出・評価を行う手段、システムに要求される信頼性・処理能力とソフトウェア・コンポーネント毎およびシステム全体での信頼性・処理能力とを比較して、各ソフトウェア・コンポーネントの適否の判定・適合度の評価を行う手段、コンポーネントベース・アプリケーションにおいてシステムに要求される信頼性・処理能力を満たす各ソフトウェア・コンポーネントの予防保守方法をシステム構築時に示す手段を提供する。

上記代表的な発明の効果は、次のとおりに説明できる。コンポーネントベース・アプリケーションで作られるシステムの構築時に、システムに要求される信頼性を考慮した効率的なシステム構築手法の提供を可能が可能となる。
さらに、予防保守を使ったシステム全体の信頼性の確保と処理性能の確保を両立させる効率的な予防保守スケジュールの提供を可能とする。
また、コンポーネントベース・アプリケーションで作られるシステムの構築時に、最適なソフトウェア・コンポーネントの選択を可能とするために、システムへの要求に対するソフトウェア・コンポーネントの適合度の提供が可能となる。
これらにより、結果的にコンポーネントベース・アプリケーションの構築コストが軽減される。

コンポーネントベース・アプリケーションは、ソフトウェア・コンポーネントをあらかじめ用意し、それを組み合わせることでアプリケーションを構築するので、開発時間の短縮、柔軟な改良が可能である点で優れているが、構築時に適切なソフトウェア・コンポーネントを多数のソフトウェア・コンポーネントから選択することが難しく、特にシステムに要求される信頼性を考慮して最適なソフトウェア・コンポーネントを選択可能とする本発明は、特にコンポーネントベース・アプリケーションの構築コスト削減に有効である。
またコンポーネントベース・アプリケーションにおける新しい信頼性向上手法であるマイクロリブートの考え方を使ったシステム運用時の高信頼化、予防保守によるシステムの高信頼化を考慮した、コンポーネントベース・アプリケーション構築を本発明は可能とする。

本発明で示すコンポーネントベース・アプリケーションにおける高信頼システム構築方法の概略を図１に示す。システム構築時には、まずシステム設計者もしくはシステム設計用のソフトウェアツールなどを利用して、業務定義書もしくは運用ポリシ（１）からシステム要件３を抽出する。
ここで、システム要件３に少なくとも含まれる仕様として、機能/環境仕様・信頼性仕様・性能仕様が挙げられる。

機能/環境仕様には、構築するシステムで実現すべき機能と、用意すべき動作環境が記述される。機能には、業務プロセスフローなどの業務定義書とコンポーネントベース・アプリケーションの構成を結びつけるための詳細仕様が含まれる。動作環境には実行に必要なハードウェアリソースやOSや実行基盤ミドルウェアなどの基盤ソフトウェアとその設定、外部I/Oやストレージなどを含むシステム構成情報などの詳細仕様もしくは条件が含まれる。

信頼性仕様には、アプリケーション実行時に要求される信頼性に関する要求が記述される。要求には、システム停止頻度に対する許容頻度や、障害発生時の復旧方法および復旧時における処理性能低下許容範囲や、性能変動に対する許容範囲などの信頼性を評価するのに必要な基準が含まれる。また、信頼性に関しては、可能な限り守られるべき希望基準や、絶対に守られなければならない絶対基準などのレベルの異なる複数の基準が含まれる場合も含まれる。

性能仕様には、アプリケーション実行時に要求される性能に関する要求が記述される。要求には、レイテンシやスループットなどの基準が含まれる。性能に関しても、可能な限り守られるべき希望基準や、絶対に守られなければならない絶対基準などのレベルの異なる複数の基準が含まれる場合も含まれる。
システム要件３は、業務定義書や運用ポリシ（１）からだけではなく、顧客などのシステム設計依頼者へのヒアリングや、システム設計者の判断、前システムや現システムの構成により決定されることも含まれる。

ソフトウェア・コンポーネント・データベース（以下、ソフトウェア・コンポーネントＤＢ）５は、ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎｓ）コンポーネントに代表されるソフトウェア・コンポーネント８を登録したデータベースであり、システム要件３に応じてソフトウェア・コンポーネントＤＢ５を検索し（４）、適切なソフトウェア・コンポーネント８を選択する。本発明によるソフトウェア・コンポーネント８には、実行履歴表７が付属しており、この実行履歴表７を使ってシステム要件３に記載の要求仕様への適合度を評価し最適コンポーネント・次点コンポーネント・次々点コンポーネントなどの順位をつけてコンポーネントの検索結果９が出力される。この選択はシステム要件３の機能仕様で示される業務プロセスフローなどの個々の業務プロセス毎に行われ、個々の業務プロセスは1つ以上のコンポーネントを選択する。そのため１つのシステム要件３に対して、通常は複数のコンポーネントの選択結果９が出力される。

コンポーネント評価結果１１はコンポーネントの選択結果９に出力された個々のコンポーネント８について、システム要件３に記載の仕様に対しての適合度を評価した結果を出力したものである。機能評価は、前記の業務プロセスで要求される機能を満たすかどうかを示す指標であり、通常は完全に機能を満たす必要がある。機能が不足する場合には、その機能を補うために別のコンポーネントを選択するか、新たに作成する必要がある。環境評価は構築するシステムで想定される環境と、ソフトウェア・コンポーネントＤＢ５を検索した際に利用したコンポーネント毎に記録された実行履歴表に記載の環境との類似度を示す指標である、完全に一致することが理想ではあるが、類似の環境も認められる。信頼性評価は、システム要件３に信頼性に関する要求に対する適合度を評価した結果を出力したものである。同様に、性能評価は性能に関する要求に対する適合度を評価した結果の出力である。

コンポーネント評価結果１１を用いて、システム構築者が適切なソフトウェア・コンポーネント８を選択・組み合わせてコンポーネントベース・アプリケーション１３を構築する。このプロセスは、ソフトウェアツールによる自動化もしくは半自動化も含まれる。コンポーネント評価結果１１はコンポーネント毎のシステム要件（３）への適合度を評価した結果であるので、構築されたコンポーネントベース・アプリケーション１３全体でシステム要件３への適合度を再度評価する必要がある（１４）。その結果がアプリケーション評価結果（１５）であり、その結果から必要に応じてアプリケーションの再構築を行う（１６）。

図２は図１に示したシステム要件３でソフトウェア・コンポーネントＤＢ５を検索し、コンポーネント評価結果１１を出力するまでのプロセスについて実装の一例を示した図である。システム要件３は個々の業務プロセス毎に機能仕様・環境仕様１７、信頼性仕様１８、性能仕様１９をもつ。個々の仕様は１つもしくは複数のソフトウェア・コンポーネント８に対する条件もしくは要求である。

まず機能仕様および環境仕様１７によってソフトウェア・コンポーネントＤＢ５を検索する。機能仕様はアプリケーションで実現すべき機能が記述されているので、この機能を持つソフトウェア・コンポーネント８を検索する。また、環境仕様により、実行環境に適合したソフトウェア・コンポーネント８を検索する。この検索結果２２はアプリケーションを構築する上で最低限の仕様を満たすソフトウェア・コンポーネント群である。この検索においては、環境仕様１７の要求に幅をもたせて検索することによって、実行環境に適合する可能性のある類似のソフトウェア・コンポーネント検索することも含まれる。このようにして検索されたソフトウェア・コンポーネント８は、若干の改良・修正によって利用可能となる可能性があるので有用である。また、ソフトウェア・コンポーネントＤＢ５に完全に適合するソフトウェア・コンポーネントが含まれない場合にも、改良・修正によって利用可能となる可能性のあるソフトウェア・コンポーネントを提示することで、アプリケーションの構築を進めることを可能とする。なお、類似のソフトウェア・コンポーネントとして検索されたソフトウェア・コンポーネントについては、完全に適合したソフトウェア・コンポーネントと区別するマークを付しておくのがよい。

次に検索信頼性仕様（８により検索結果２２に含まれるソフトウェア・コンポーネントを評価し、最適コンポーネント・次点コンポーネント・次々点コンポーネントなどを選択する。評価の際に、各ソフトウェア・コンポーネント８に付属の実行履歴表７に含まれる信頼性仕様に記載の要求への適合度を評価する。次に性能仕様１９との適合度を信頼性仕様への適合度の評価と同様に行い、コンポーネント評価結果（２８）を最終的に出力する。信頼性仕様１８と性能仕様１９の評価は、図２に記載の順序の他に、順序を入れ替えた評価、同時に評価し双方の評価結果をまとめて評価した結果により最適コンポーネント・次点コンポーネント・次々点コンポーネントなどを出力する方法もある。

コンポーネントベース・アプリケーションの実行時における障害発生時の復旧方法の実装例を図３に示す。コンポーネントベース・アプリケーション１３を構成するコンポーネントのうちの１つのコンポーネント２９で障害が発生した場合、このアプリケーション全体をリブートすることで障害復旧をする方法をフルリブートと呼ぶ。フルリブートでは、リブート実行中はアプリケーション全体が停止し、その停止時間もアプリケーションや環境によるが、数秒から数分にわたることもある。一方、障害を起したもしくは起したと推測されるコンポーネントを検出し、そのコンポーネントのみをリブートすることで障害復旧する方法をマイクロリブートと呼ぶ。マイクロリブートでは、障害復旧中もリブートを行っていない他のコンポーネントは継続して実行されるので、アプリケーションは一部のみもしくは一時的に停止するのみで、一般的にはフルリブートに比べて停止時間や停止規模が縮小され、信頼性が向上される。しかし、マイクロリブートはすべての場合に行えるとは限らず、障害を起したもしくは起したと推測されるコンポーネントがＳｔａｔｅｆｕｌｌなコンポーネントであった場合などでリブートによって元の状態に戻らないことがあり、この場合にはフルリブートが必要になる可能性がある。

コンポーネントベース・アプリケーションの実行時における信頼性向上の方法である予防保守の実装例を図４に示す。コンポーネントベース・アプリケーション１３で１つのコンポーネント３３の障害発生可能性が増加したと判断された場合に、そのコンポーネント３３に対して予防的にリブートを実行することで、障害発生可能性を減少させ、アプリケーションを継続的に稼動する方法である。図３に示した障害発生時のマイクロリブートは障害発生後に障害を発生したコンポーネントの検出とリブートを行うのではなく、アプリケーションを監視しアプリケーション実行中に障害発生可能性の増加したコンポーネントを検出し、適当なタイミングでリブートを実行する。予防保守なしの場合には、障害が発生し、その後にフルリブートもしくはマイクロリブートによる障害復旧を行うことになるため、アプリケーション全体が停止もしくは一部・一時のみ停止するため、予防保守を行った場合よりも信頼性が低下する可能性がある。

図５は本実施例におけるコンポーネントに付属する実行履歴表７の内容の例を示す。
実行履歴表７のインデックス部３６には、コンポーネントが使われた環境として、ビジネス・業務種やアプリケーション名、実行したハードウェアに関する情報、実行時のシステム負荷状態、実行した日時、接続元や接続先のコンポーネントなどが記録される。リソース要求３７部３７は、このコンポーネント８が動作時に使用したＣＰＵ使用量、メモリ使用量、入出力データ量などが記録される。

機能仕様などで検索される機能部３８については、コンポーネント（８）が行う処理内容や入出力インタフェースなどが記録される。この他に、コンポーネント８の機能については、例えばＥＪＢなどのＪａｖａＢｅａｎでは、イントロスペクションなどの外部にコンポーネントの機能を通知するメカニズムが備わっているのが普通である。

信頼性部３９は、コンポーネント８の信頼性に関する事項を評価する際に利用される項目である。これには、実行時のエラー頻度、リブート所要時間、マイクロリブートを実行した際に起こった性能劣化度、実行した予防保守頻度の他に、このコンポーネントがマイクロリブート可能かどうかに関する情報などが含まれる。

性能部４０には、このコンポーネント８の実行時の１つの処理に要するレイテンシや処理のスループットが含まれる。これらの性能値については、最大値や平均値などの形態で記録される場合も含まれる。
以上の実行履歴表７はコンポーネント８に１つだけとは限らず、例えば別のシステムで実行された場合や、別の機能として使われた場合など毎に用意する場合も含まれる。

次に実行履歴表７を記録する方法について述べる。図６はコンポーネントベース・アプリケーションの通常実行時の測定結果を実行履歴表に記録する手段を持つ実行管理システムの例である。アプリケーションは、コンポーネントベース・アプリケーション実行部４１で実行される。コンポーネントベース・アプリケーション実行部４１はコンポーネントベース・アプリケーション運用管理部４５から制御指示４２を受けて、アプリケーションの起動や停止などを行う他、ソフトウェア・コンポーネントＤＢ５との間でコンポーネントの投入・退避を行う（４４）。また、コンポーネントベース・アプリケーション実行部４１からコンポーネントベース・アプリケーション運用管理部４５に対して、アプリケーションやコンポーネントの状態報告が行われる（４３）。この状態報告（４３）には、主に信頼性や性能に関する報告が含まれる。ＯＳ、アプリケーション実行基盤４８およびハードウェア５０などとコンポーネントベース・アプリケーション運用管理部４５の間では、状態モニタや構成情報に関する指示や確認が行われる（４７、４９）。リソース要求（図５のリソース要求部３７を参照）はこれらの状態モニタから測定される。また、信頼性や性能に関しても、状態モニタ（４７、４９）から測定されることも含まれる。さらに、状態モニタや構成情報に関する指示や確認は、インデックス（図５のインデックス部３６を参照）を作成するのにも使われることがある。

実行履歴表７を記録する別の方法について述べる。図７はコンポーネントベース・アプリケーションで実行履歴表７の作成・更新のための試験運用を行う方法の例である。
図７（ａ）は、コンポーネントベース・アプリケーションの一部に試験コンポーネント５３を追加して実行することで、試験コンポーネント（５３）の実行履歴表（７）を作成・更新する。試験コンポーネント５３の入力線５２は、試験コンポーネント５３を実行するのに必要な情報を通信するが、この入力線５２が他の通常のコンポーネントの実行や実行履歴表への記録に影響を与えてはならない。また、試験コンポーネント５３の出力線（５４）では、試験コンポーネント５３から出力先のコンポーネントへの実際の通信は行わないが、実行履歴の測定に必要である。この出力線５4も、入力線５２と同様に他の通常のコンポーネントの実行や実行履歴表への記録に影響を与えてはならない。

図７（ｂ）は別の試験運用の方法の例である。実行管理システム５１とほぼ同等の試験実行管理システム５５を設け、試験実行管理システム上で、実行履歴表７の作成・更新をしたいコンポーネントの実行を行う。この実行による実行履歴表７への記録は、試験運用管理部５７を通して、実行管理システム上のソフトウェア・コンポーネントＤＢ５に記録される。これによって、実際の実行部４１には影響を与えずに実行履歴表７の作成・更新が可能となる。なお、ＯＳ、実行基盤４８やハードウェア５）などは、実行管理システム５１と試験実行管理システム５５で２重に用意するだけでなく、一部もしくは全部を共用する方法も考えられる。
その他、図７（ａ）（ｂ）のいずれの場合においても、試験的な実行を空いているリソースを活用しておこなうことも含まれる。

次に、図２に示した信頼性仕様（１８）によるコンポーネントの評価について図８に例を示す。仕様/環境を満たすコンポーネント群２２に含まれるコンポーネントＡ、Ｂ、Ｃの実行履歴表７は、それぞれ図８に示す状態になっている。図８では信頼性仕様の例を３つ挙げて、それぞれの評価結果を示した。

まず、信頼性仕様（１）（符号５８）では、無停止であることが最優先要求であり、若干の性能変動を許容し、マイクロリブートの使用も可能である場合で、無停止の実現のために予防保守を行う。そのため、マイクロリブートが使用できず、予防保守が難しく、停止する可能性のあるコンポーネントＢがまず最下位となる。またエラー頻度とマイクロリブート時の性能劣化度から、性能低下量が少ないコンポーネントＣが最適コンポーネントとなる。コンポーネントＡとＣの評価方法の一例は、エラー頻度にマイクロリブート時の性能劣化度を掛け合わせた値の大小で比較する方法が挙げられる。

信頼性仕様（２）（符号６０）では、性能変動不可が最優先要求であり、障害時にはある程度の停止が許容されるが、停止回数は少ない方がよい場合で、性能変動を起すマイクロリブートは利用できない。また、停止回数を減少させるために、エラー頻度を比較して、エラー頻度の低い順に優先度が高くなり、コンポーネントＡ、Ｂ、Ｃの順序と評価できる。

信頼性仕様（３）（符号６２）では、停止時間の最小化が最優先要求であるが、マイクロリブートの使用が不可の場合である。この場合、エラー頻度とリブート時間から、例えば、エラー頻度にリブート所要時間を掛け合わせた値の大小で比較する方法で停止時間を評価し、コンポーネントＢ、Ｃ、Ａの順序と評価できる。

ここまで、コンポーネント毎に実行履歴表をもち、コンポーネント８単位でアプリケーションの構築や管理を行う場合について述べたが、本発明の方法は、複数のコンポーネントの組み合わせを1つのコンポーネントと同等として扱う場合も含まれる。図９は複数のコンポーネントの組み合わせを1つのコンポーネント群６６として、このコンポーネント群毎に実行履歴表６５を付属させアプリケーション構築時に最適なコンポーネント群選択を行う方法について示した図である。

予防保守を行う場合には、本発明によるアプリケーション構築方法により、予防保守のスケジュールを作成することが可能である。図１０は、予防保守スケジュールの作成例である。各コンポーネント８に付属する実行履歴表７から、信頼性に関する情報を得て、予防保守の実行頻度や予防保守実行時の性能劣化度などから、例えば性能変動の最も小さい予防保守スケジュールを作ることが可能である。例えば、コンポーネントＡとＣでは、エラー頻度に１０倍の差があるため、コンポーネントＣはコンポーネントＡに比べて１０倍の頻度で予防保守を実行する。コンポーネントＣの予防保守実行頻度は、エラー頻度が１０％であるので、例えば１０回の処理に1度の割合で予防保守を実行する。予防保守に要する時間はリブート時間とし、その間だけ実行履歴表７に示されたマイクロリブート時の性能劣化度分だけ処理性能が低下すると考えると、できるだけ各コンポーネントの予防保守スケジュールが重ならないように配置することが重要である。以上のような考え方で、図１０上部に記載のコンポーネントベース・アプリケーション２２に対して作成した予防保守スケジュール７０が図１０下部のグラフである。この予防保守スケジュール７０では、横軸が時間であり、縦軸は各コンポーネントを示している。棒グラフ中の黒い部分でそのコンポーネントに対して予防保守を実行しており、ここでは、同時に１つのコンポーネントのみが予防保守をしている状態を示した。

ここまで、コンポーネントベース・アプリケーションの構築方法について示したが、以上で示したソフトウェア・コンポーネントの評価方法を利用して、環境に応じたソフトウェア・コンポーネントの価格付けも可能である。例えば、実行リソースを低減することが重要な場合には、信頼性の指標が優れているがリソース要求の高いソフトウェア・コンポーネントは、信頼性の指標が劣っていてかつリソース要求も高いソフトウェア・コンポーネントよりも価格付けを高くすることができ、さらに、信頼性の指標が劣っているがリソース要求の低いソフトウェア・コンポーネントはさらに高い価格付けができる。

本発明で示したコンポーネントベース・アプリケーションの高信頼システム構築方法は、コンポーネントベース・アプリケーションで作られるシステムの構築時に、システムに要求される信頼性を考慮した効率的なシステム構築手法の提供を可能とすることで、コンポーネントベース・アプリケーションの適用範囲を広げる可能性がある。また、コンポーネントベース・アプリケーションの高信頼化を実現するために、システムの構築時に行う信頼性の評価においても、本発明で示した方法により、容易かつ精度よく評価することが可能となり、更に予防保守スケジュールなどの運用時も含めた高信頼化方法を示すなど、高信頼なコンポーネントベース・アプリケーションの構築に要するコストを低減することが可能である。さらに、本発明で示したコンポーネントの評価方法により、実行環境などに応じたコンポーネントの価格付けが可能となり、より柔軟なコンポーネント流通ビジネスが実現できる。

本発明によるコンポーネントベース・アプリケーション構築方法の概略を示した概念図である。 本発明によるコンポーネントベース・アプリケーション構築方法において、コンポーネントの選択方法について示した概念図である。 本発明で利用するコンポーネントベース・アプリケーションの実行時の障害復旧において信頼性を向上させる方法を示した概念図である。 本発明で利用するコンポーネントベース・アプリケーションの実行時に予防保守をして信頼性を向上させる方法を示した概念図である。 本発明によるコンポーネントベース・アプリケーション構築方法でコンポーネント毎に付属する実行履歴表の内容の例を示したデータ構成図である。 本発明によるコンポーネント毎に付属する実行履歴表を、アプリケーション実行時に作成・更新する実行管理システムの例を示した概念図である。 本発明によるコンポーネント毎に付属する実行履歴表を、アプリケーションを試験的に実行することで作成・更新する方法の例を示した概念図である。 本発明によるコンポーネントベース・アプリケーション構築方法において、信頼性仕様によりコンポーネントの評価を行う例を示した概念図である。 本発明によるコンポーネントベース・アプリケーション構築方法で、複数のコンポーネントの組み合わせを単位として構築する方法の概略を示した概念図である。 本発明によるコンポーネントベース・アプリケーション構築方法において、コンポーネント毎に付属する実行履歴表を利用した予防保守のスケジュールの作成例を示した概念図である。

符号の説明

１：業務定義書・運用ポリシ
３：システム要件
５：ソフトウェア・コンポーネント・データベース
７：実行履歴表
８：ソフトウェア・コンポーネント
９：ソフトウェア・コンポーネント検索結果
１０：ソフトウェア・コンポーネント評価結果
１３：コンポーネントベース・アプリケーション
１５：コンポーネントベース・アプリケーション評価結果
１７：機能仕様/環境仕様
１８：信頼性仕様
１９：性能仕様
２２：機能/環境を満たすコンポーネント群
２５：信頼性仕様評価結果
２８：ソフトウェア・コンポーネント評価結果
２９：障害発生したソフトウェア・コンポーネント
３０：アプリケーション停止時間
３３：障害発生可能性が増加したソフトウェア・コンポーネント
３４：障害復旧時間
３５：予防保守時間
３６：インデックス部
３７：リソース要求部
３８：機能部
３９：信頼性部
４０：性能部
４１：コンポーネントベース・アプリケーション実行部
４２：コンポーネントベース・アプリケーション制御指示
４３：コンポーネントベース・アプリケーション状態報告
４４：コンポーネントベース・アプリケーション投入・退避
４５：コンポーネントベース・アプリケーション運用管理部
４６：実行履歴表入出力
４７，４９：状態モニタ、構成情報入出力
４８：ＯＳ，アプリケーション実行基盤
５０：ハードウェア
５１：コンポーネントベース・アプリケーション実行管理システム
５２：試験コンポーネント入力線
５３：試験コンポーネント
５４：試験コンポーネント出力線
５５：試験実行管理システム
５６：試験実行部
５７：試験運用管理部
５８，６０，６２：信頼性仕様例
５９，６１，６３：信頼性仕様によるソフトウェア・コンポーネント評価結果例
６４：ソフトウェア・コンポーネント群・データベース
６５：実行履歴表
６６：ソフトウェア・コンポーネント群
６７：ソフトウェア・コンポーネント群検索結果
６８，６９：ソフトウェア・コンポーネント群評価結果
７０：予防保守スケジュール例。

Claims (9)

1. ソフトウェア部品であるソフトウェア・コンポーネントの組み合わせでアプリケーションを構築するコンポーネントベース・アプリケーション構築方法であって、蓄積するソフトウェア・コンポーネントの実行時の信頼性指標の履歴を該ソフトウェア・コンポーネントの実行履歴として記録し、ソフトウェア・コンポーネントを組み合わせてアプリケーションを構築する際に、前記記録された実行履歴を参照してアプリケーションの実行時の信頼性を評価し、前記アプリケーションの構築に採用するコンポーネントの選択に反映させることを特徴とするコンポーネントベース・アプリケーション構築方法。
2. 前記実行履歴として、ソフトウェア・コンポーネント毎の実行時の信頼性指標の履歴を実行時に測定することが可能なコンポーネントベース・アプリケーション実行環境により記録された実行履歴を用いることを特徴とする請求項１に記載のコンポーネントベース・アプリケーション構築方法。
3. 前記実行履歴として、前記ソフトウェア・コンポーネント毎の実行時の信頼性指標の履歴を測定するために試験的に実行することができる実行環境とその実行履歴とを記録することを特徴とするコンポーネントベース・アプリケーション実行環境を用いて記録された実行履歴を用いることを特徴とする請求項１に記載のコンポーネントベース・アプリケーション構築方法。
4. 前記実行履歴に該ソフトウェア・コンポーネントの実行環境を記録し、構築するアプリケーションの実行環境と同一の実行履歴を持つコンポーネントを検索して前記アプリケーションの構築に採用するコンポーネントの選択に反映決定することを特徴とする請求項１に記載のコンポーネントベース・アプリケーション構築方法。
5. 構築するアプリケーションの実行環境と類似の実行環境も同一の実行履歴をもつコンポーネントとして検索することを特徴とする請求項４に記載のコンポーネントベース・アプリケーション構築方法。
6. 前記実行履歴は蓄積するソフトウェア・コンポーネントの群毎に記録し、前記アプリケーションの構築は該ソフトウェア・コンポーネントの群を単位に行うことを特徴とする請求項１の
7. 前記信頼性指標として、エラーもしくは障害の発生時に復旧に要した時間、復旧実行中の性能劣化度、リブートに要する時間、リブートを実行中の性能劣化度の１つ以上を含むことを特徴とする請求項１に記載のコンポーネントベース・アプリケーション構築方法。
8. アプリケーションの実行時に、エラーもしくは障害の発生を予防するためにソフトウェア・コンポーネント単位もしくはソフトウェア・コンポーネントの組み合わせ単位にリブートを行うことが可能なアプリケーション実行環境を持ち、前記予防的にリブートを実行した際の、予防的なリブートの実行頻度、予防的なリブートの実行に要する時間、予防的なリブート実行中の性能劣化度の１つ以上を信頼性指標に含むことを特徴とする請求項１に記載のコンポーネントベース・アプリケーション構築方法。
9. 前記実行履歴を利用してコンポーネントベース・アプリケーション実行環境に応じてソフトウェア・コンポーネントもしくはそれらのソフトウェア・コンポーネントを組み合わせて作られたコンポーネントベース・アプリケーションの価格付けを決定するステップを更に有する請求項１に記載のコンポーネントベース・アプリケーション構築方法。

Images