JP5128944B2 - コンピュータアプリケーションにおけるデータ損失を最小限にする方法およびシステム - Google Patents

Description

関連出願との相互参照
本出願は、２００４年７月２０日出願の米国仮特許出願第６０／５８９，２６２号に基づき優先権主張するものであり、その内容は引用により本明細書に含まれるものである。

本発明は、一般的には、コンピュータソフトウェアアプリケーションのフォルトトレランスに関し、さらに、個々のアプリケーションがプログラミングの対象となっていなかったか、あるいは意図していなかった障害発生のシナリオにおいてその操作を可能にする方法とシステムに関する。

コンピュータシステムおよびソフトウェアアプリケーションはますます複雑化し、分散化されている。これらの要因のどちらも、データ損失という共通問題を引き起こす原因になっている。エンドユーザがソフトウェアアプリケーションを操作するとき、その操作の結果を１または２以上のデータファイル内やデータベースに、あるいは他の場所に保存しておくのが普通である。これらの操作をコミットするアクションを行なうと、実効的にチェックポイント（ｃｈｅｃｋｐｏｉｎｔ）として働くステート変化（ｓｔａｔｅ ｃｈａｎｇｅｓ）がシステム内に引き起こされる。アプリケーションプログラマは、自分のソフトウェアプログラムがこれらのチェックポイントで意図した通りに実行されることを保証し、その変化をコミットまたは拒絶するのに大量の時間を費やしている。

しかし、ステート変化がこれらのチェックポイントとチェックポイントの間に累積していくことも普通になっている。大部分のソフトウェアアプリケーションでは、コミットとコミットの間に大量の時間が経過するか、あるいは操作が行なわれることがある。このインターバル期間にアプリケーションに障害が起こったとき、ユーザによってとられたアクションが失われて、最後のチェックポイントに戻されることがある。この場合、ユーザはアプリケーションを再オープンし、表示可能なステートを調べてなにが失われたかを把握し、とられたアクションを再現する必要がある。

アプリケーション障害は、ネットワーク障害、ハードウェア障害、サーバまたはシステムの障害、あるいは他の操作上の瞬間的異常（ｏｐｅｒａｔｉｎｇ ｇｌｉｔｃｈｅｓ）といった、いくつかの理由で発生する可能性がある。新しいソフトウェアモードでは、ユーザがラップトップや他のモバイルデバイスをネットワークから切り離したり、あるいはアプリケーションがストリーム化されるか、クライアントコンピュータにばらばらに（ｉｎ ｐｉｅｃｅｓ）配信されたりするので、障害が発生する可能性が増加している。多くのアプリケーションは、ネットワークから切り離されている間も操作される設計にも、プログラムとその資産（ａｓｓｅｔｓ）全体がランタイム（ａｔ ｒｕｎｔｉｍｅ）に存在しなくても操作される設計にもなっていない。

アプリケーションを書き直したり、あるいはすべての形体の障害を考慮に入れたりすると、コスト的にも時間的にも高くつくので、そのようにしなくても、上記障害や他の形体の障害を受容または解消することによって、チェックポイント個所の作業損失だけでなくチェックポイントとチェックポイントの間の作業損失もなくす手段が望まれている。

どのソフトウェアアプリケーションに修正を加えなくても、あるいはソフトウェアアプリケーションのコードや設計にアクセスしなくても、望みの障害許容力（ｒｅｓｉｌｉｅｎｃｙ−フォルトトレランス）が得られるようにする、単純で汎用目的のメソッド群が提案されている。

特定のアプリケーションまたは目的のために設計時に、この問題の解決を行なうためのメソッドが提案されている。そのようなメソッドとしては、特許文献１に開示されているものがある。特許文献２には、アプリケーション開発者が使用するために作成されたフォルトトレラントルーチンのライブラリが開示されている。特許文献２の方法によれば、アプリケーションをフォルトトレラントになるように設計し、構築する必要のある制約は、上記ライブラリの使用によって解消されている。また、この発明によれば、過去、現在および将来のソフトウェアシステムの多くの要求条件を処理するための拡張可能なソリューションフレームワークが提供されている。

米国特許第６，０１４，６８１号（Ｗａｌｋｅｒ他）、発明の名称「バックグラウンド保存スレッドを使用してドキュメントを保存する方法（Ｍｅｔｈｏｄ ｆｏｒ Ｓａｖｉｎｇ ａ Ｄｏｃｕｍｅｎｔ Ｕｓｉｎｇ ａ Ｂａｃｋｇｒｏｕｎｄ Ｓａｖｅ Ｔｈｒｅａｄ）」 米国特許第５，７４８，８８２号（Ｈｕａｎｇ）、発明の名称「フォルトトレラントコンピューティングのための装置と方法（Ａｐｐａｒａｔｕｓ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆａｕｌｔ−Ｔｏｌｅｒａｎｔ Ｃｏｍｐｕｔｉｎｇ）」

本発明は、障害または潜在的障害がコンピュータアプリケーションで発生したときのデータ損失を防止または最小限にする方法とシステムを提供することを課題にしている。本発明の方法とシステムによれば、使用中のアプリケーションのコードに修正を加えなくても、あるいはコードにアクセスしなくても、データ損失を最小限にし、あるいは防止することを可能にしている。

本発明では、ターゲットコンピュータ上で実行中のプライマリアプリケーション（ｐｒｉｍａｒｙ ａｐｐｌｉｃａｔｉｏｎ）をモニタして、プライマリアプリケーションにおける障害または潜在的障害の存在を検出するためのヘルパ（ｈｅｌｐｅｒ）アプリケーションが用意されている。障害が検出されると、ヘルパアプリケーションは、その障害を処理するためのメソッドを選択し、そのあと選択したメソッドを実行する。

ヘルパアプリケーションは、プライマリアプリケーションへのコールをインターセプト（ｉｎｔｅｒｃｅｐｔ）し、そのコールの結果を調べることによってプライマリアプリケーションをモニタしている。ヘルパアプリケーションは、アプリケーションの内部オペレーション（ロジック障害など）および／または外部オペレーション（ネットワーク接続性（ｎｅｔｗｏｒｋ ｃｏｎｎｅｃｔｉｖｉｔｙ）の損失、アプリケーションによって要求された外部サービスの障害、接続デバイスの障害、およびピアまたはサーバネットワークの障害など）をモニタしている。

障害が特定されると、ヘルパアプリケーションはどの障害ハンドラ（ｆａｕｌｔ ｈａｎｄｌｅｒ）が最も適しているかを判断する。本発明の好適実施形態では、障害ハンドラとしてリダイレクションハンドラ（ｒｅｄｉｒｅｃｔｉｏｎ ｈａｎｄｌｅｒ）、一時中止ハンドラ（ｓｕｓｐｅｎｄｉｎｇ ｈａｎｄｌｅｒ）およびスナップショットハンドラ（ｓｎａｐｓｈｏｔ ｈａｎｄｌｅｒ）が用意されている。システムは、異なる目的別に異なるハンドラがいくつでも利用できるように拡張可能になっている。その他のハンドラの例としては、自動リスタートハンドラ（ａｕｔｏｍａｔｉｃ ｒｅｓｔａｒｔ ｈａｎｄｌｅｒ）または巻き戻しハンドラ（ｒｅｗｉｎｄｉｎｇ ｈａｎｄｌｅｒ）がある。

リダイレクションハンドラが選択された場合は、リダイレクションハンドラは、プライマリアプリケーションの保存ロジックを起動（ｉｎｖｏｋｅ）する。保存ロジックは、（ａ）プライマリアプリケーションの保存エントリポイントを直接にコールするか、（ｂ）プログラムカウンタを保存エントリポイントにリセットするか、あるいは（ｃ）保存のコールを強行するためにジャンプ命令を挿入することにより起動することができる。

一時中止ハンドラが選択された場合は、一時中止ハンドラはアプリケーションを一時中止し、再開が可能であるとの通知を待つ。この通知を受けると、一時中止ハンドラは、（ａ）プライマリアプリケーションを再開するか、（ｂ）プライマリアプリケーションのプログラムカウンタをリセットするか、あるいは（ｃ）障害を起こした元のＡＰＩを再起動する。一時中止ハンドラは、あらかじめ決めた手段を通してのみプライマリアプリケーションを制御可能にすることにより、プライマリアプリケーションが一時中止されている間にプライマリアプリケーションが偶発的に再開されるのを防止する。プライマリアプリケーションは障害が持続している間一時中止させることができるが、障害ステートを予想してユーザインタフェースによって一時中止させることも可能である。

スナップショットハンドラが選択された場合は、スナップショットハンドラは、プライマリアプリケーションに障害または潜在的障害が存在することに応答してプライマリアプリケーションのプロセスとスレッドを一時中止する。そのあと、スナップショットハンドラはプライマリアプリケーションのメモリスナップショットをとり、そのメモリを不揮発性ストレージ（ｎｏｎ−ｖｏｌａｔｉｌｅ ｓｔｏｒａｇｅ）にストアし、起動時にプライマリアプリケーションをリストアする。スナップショットハンドラは、障害がクリアされるか、あるいはユーザによって明示的に確認されるまでプライマリアプリケーションが再起動されるのを防止する。

上述した実施形態では、ヘルパアプリケーションは処理する障害別に分類すると共に、起動できるハンドラ別に分類している。このことは、種々の手法を通してオフラインまたはオンラインでシステムに知らせることができる。最も基本的なシステムでは、ハンドラはすべての障害を検出するように単に登録されるだけである。

本発明の別の側面によれば、追加のステップとして、プライマリアプリケーションコードについてスタティック分析（ｓｔａｔｉｃ ａｎａｌｙｓｉｓ）が行なわれ、その構成だけでなく障害を引き起こす潜在性も判断されると共に、「保存」または「終了（ｅｘｉｔ）」といった共通プログラムエントリポイントが判断される。分析が完了したあと、アナライザは、回復可能な障害と回復可能でない障害および推奨処理方法のリストを提示することができる。どちらの障害群の場合も、障害ハンドラを構成するためのアクションを禁止することができる。回復可能でない障害の場合は、リダイレクションハンドラが使用されるのが普通である。「保存」コードが存在しないか、あるいは特定できない場合は、データが必ずしも保存されないことがあっても、安全に終了するだけで済むようにシステムをセットアップすることができる。

プログラムエントリポイントを分析するために、ヘルパアプリケーションは、ソースを見つけるためにプラットフォーム知識を使用することができる。代替実施形態では、障害とエントリポイントは、ダイナミック分析（ｄｙｎａｍｉｃ ａｎａｌｙｓｉｓ）を使用して特定することができる。従って、これらのシグネーチャ（ｓｉｇｎａｔｕｒｅ）を特定するためにその実行中にプログラムをトレースすることができる。

ソフトウェアアプリケーション１００は、図１に示すようにターゲットコンピュータ１０１上で実行されている。ヘルパアプリケーション１０２は同じコンピュータ上で同時並行に実行されているが、その全体または一部を代替コンピュータ１０３上にサービスプログラムとして置いておくことも可能である。このヘルパアプリケーション１０２はスタンドアロンプロセスとしても、プライマリアプリケーションのメモリ空間に入れておくことも、あるいはコンピュータのオペレーティングシステムの一部としても、デバイスドライバとしても、その他としても置いておくことができる。プライマリアプリケーション１００はコンパイルし直す必要もなければ、修正する必要もない。プライマリアプリケーション１００はスタンドアロンプログラムとして置いておくことも、ナットワーク内の１または２以上のピア（ｐｅｅｒ）またはサーバコンピュータと通信するように置いておくこともできる。

図２を参照して説明すると、ヘルパアプリケーション１０２は障害ディテクタ（ｆａｕｌｔ ｄｅｔｅｃｔｏｒ）２０１、障害ハンドラ（ｆａｕｌｔ ｈａｎｄｌｅｒ）２０２、および知識ベース（ｋｎｏｗｌｅｄｇｅ ｂａｓｅ）２０３を含んでいる。プライマリアプリケーション１００が実行されると、傷害ディテクタ２０１はプライマリアプリケーション１００をモニタして、障害の存在を検出することを試みている。障害検出はプライマリアプリケーション１００の内部オペレーションに対する応答としても、ネットワーク接続性（ｎｅｔｗｏｒｋ ｃｏｎｎｅｃｔｉｖｉｔｙ）の損失、アプリケーションによって要求された外部サービスの障害、プリンタやモデムなどの接続デバイスの障害、ネットワーク内のピアまたはサーバコンピュータの障害といった、他の外部要因に対する応答としても行なわれる。内部エラーを受け入れるために、障害ディテクタは種々のメッセージおよびプライマリアプリケーション１００によってとられたアクションをインターセプトする。一例のメソッド（図２に図示）では、ヘルパアプリケーション１０２は、標準Ｃランタイムライブラリ内のｍａｌｌｏｃ（）とｆｒｅｅ（）の使用といったように、メモリ割り振りルーチン（ｍｅｍｏｒｙ ａｌｌｏｃａｔｉｏｎ ｒｏｕｔｉｎｅ）へのプライマリアプリケーションのコールをモニタしている。ｍａｌｌｏｃ（）ルーチンが要求されたメモリを割り振ることができないときは、メモリ障害が発生している。

この例では、ｍａｌｌｏｃ（）ルーチンへのプライマリアプリケーションのコールは障害ディテクタによってインターセプトされる。なお、本発明の代替実施形態では、障害ディテクタは、実際にはルーチンコールをインターセプトすることなく、その出力から例外、正しくないリターンコードや他の正しくない振る舞い（ｂｅｈａｖｉｏｒ）といった障害をモニタするように動作させることが可能になっている。インターセプトされたコールはｍａｌｌｏｃ（）ルーチンに転送される。このルーチンから戻ると、障害ディテクタはコールの結果を調べる。この時点で、障害ディテクタはブランチして、コントロール（制御権）をプライマリアプリケーション１００に戻すか、あるいは障害ハンドラ２０２を起動する。障害ハンドラ２０２はスタティックにコーディングされた判定（ｓｔａｔｉｃａｌｌｙ ｃｏｄｅｄ ｄｅｃｉｓｉｏｎ）および／または構成可能な知識ベース（２０３）（図２に図示）のようなシステムで構成し、もっと大きなセットの振る舞いやヒューリスティックに基づいて障害処理ルーチンを起動することができる。

一実施形態では、知識ベース２０３は、種々の障害シナリオに対応するように構成可能なルールと振る舞いのセット（ｓｅｔ ｏｆ ｒｕｌｅｓ ａｎｄ ｂｅｈａｖｉｏｒｓ）で構成されている。ルールベース（ｒｕｌｅ ｂａｓｅ）である知識ベースは、時間の経過と共に拡張可能にもなっている。ルールを追加するだけで、新しい障害を処理し、新しい振る舞いを採用し、あるいは利用可能な情報に基づいて異なる判断を行なうようにシステムの能力を拡張することができる。障害ハンドラは、現在の障害に関して利用可能な情報を使用して知識ベースをクエリ（照会）する。この例では、障害ハンドラは、現行プログラム内でｍａｌｌｏｃ＿ｆａｉｌｅｄイベントが起こったことを知識ベースに通知する。そのあと、知識ベースはそのルールベースを起動し、アプリケーションとマシンの現ステート、発生した障害のタイプ、その障害と共に利用可能な重大度（ｓｅｖｅｒｉｔｙ）または拡張エラー情報、またはアプリケーション固有の障害処理ルールに関して、ルールベースのルールに基づいて判断を行なう。知識ベースは、判定ツリー（ｄｅｃｉｓｉｏｎ ｔｒｅｅｓ）、ケース方式の推論（ｃａｓｅｄ−ｂａｓｅｄ ｒｅａｓｏｎｅｒｓ）、または手法の組み合わせといった、種々の方法で実現することができる。知識ベースの処理結果は、障害に対する応答としてとられるアクションが選択されたか、あるいはどのアクションも選択されなかったか、である。このリターン命令は、現行障害をどのように処理すべきかを障害ハンドラに指示する。

障害ディテクタ２０１は、ターゲットコンピュータ１０１上またはターゲットコンピュータが属しているネットワーク内の外部イベントにも応答する。例えば、ターゲットコンピュータ１０１は、モバイルデバイスがバッテリで稼動しているときのように、そのパワーが低下したことを知らせることができる。障害検出システム（ｆａｕｌｔ ｄｅｔｅｃｔｉｏｎ ｓｙｓｔｅｍ）２０１はこのイベントを観察し、知識ベースを通して該当回復アクションを選択するために障害ハンドラを起動することができる。その他の実施形態では、障害ディテクタ２０１は、ネットワーク接続性の損失、アプリケーションによって要求された外部サービスの障害、プリンタやモデムなどの接続デバイスの障害、ネットワーク内のピアまたはサーバコンピュータの障害、その他の重要イベントに応答するように構成することができる。この場合、障害ディテクタは２つの異なるモジュール、すなわち、アプリケーション固有の障害を観察するモジュールとシステム全体の障害または環境上の問題を観察するモジュールを含んでいるものと見ることができる。

障害ディテクタ２０１は、ネットワークから切り離すことができるモバイルデバイスと関連付けて使用することができる。このタイプのデバイスでは、ネットワーク割り込み （ｎｅｔｗｏｒｋ ｉｎｔｅｒｒｕｐｔｉｏｎ）が頻繁に起こる可能性があり、プライマリアプリケーション１００のコードは、モバイル用に設計されていないことがある。さらに、モバイルデバイスでは、プライマリアプリケーション１００のコードは配信モード用にストリーム化することが可能であり、このモードでは、プライマリアプリケーション１００はプライマリアプリケーション１００のある種の関数を操作するために必要なコードセグメントに分割されている。これらのコードセグメントは、ジャストインタイム（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）でモバイルデバイスに配信されるので、プライマリアプリケーション１００はフットプリント（ｆｏｏｔｐｒｉｎｔ：実装面積）を最小にして迅速に配置することができる。このモードでは、モバイルデバイスのオペレータは、利用可能でないプライマリアプリケーションの関数を、オフラインで使用中のときに要求することがよくある。この関数が要求された時点では、コードセグメントは存在していないので、ネットワークからアクセス可能になっていない。

本発明の一実施形態では、プライマリアプリケーションのシステムコードページにアクセスできないことを示すページ不在（ｐａｇｅ ｆａｕｌｔ）がモバイルデバイスのオペレーティングシステムから出されると、障害ディテクタ２０１はこの障害をトラップ（ｔｒａｐ）し、障害ハンドラ２０２を起動する。別の実施形態では、障害ディテクタ２０１は、アプリケーションをストリーム化するためのシステムの一部として、モバイルデバイスのオペレーティングシステム内に埋め込まれている。このシステムでは、データパケットのネットワーク要求が失敗したとき、および障害を起こした振る舞いが直接に検出されたときに、ページ不在が起こる前に傷害を検出することができる。

モバイルデバイスはネットワークから切り離されることがあるので、ネットワークリソースとの連絡を失ったり、連絡不能になったりすることがある。プライマリアプリケーション１００がネットワークとの接続を試みて、失敗すると、別のクラスの障害が起こる可能性がある。このクラスの障害では、障害ディテクタ２０１はネットワークに対する要求をインターセプトし、失敗すると、適切な、障害を起こした振る舞いを実行することができる。

上述したように、障害が検出されると、障害ハンドラ２０２は、どの障害ハンドラが最も適しているかを判断する。あるケースでは、障害ハンドラはヘルパアプリケーション１０２を起動して、ユーザがとるべきアクションを判断できるようにするか、あるいはヘルパアプリケーションによって構成されているアクションを起動する。ヘルパアプリケーションは障害の存在をユーザに通知することも、その障害を内部ログに記録することも、障害通知をＳＮＭＰ、ＷＭＩまたはＷｉｎｄｏｗｓ（登録商標）イベントログ（Ｅｖｅｎｔ Ｌｏｇ）などの、種々のモニタリングシステムに転送することもできる。ヘルパアプリケーションは、障害を処理することを選択するか、あるいは障害の発生を許容するかをユーザに質問することもでき、さらに、多数のアクションが可能な場合には、該当するアクションを選択するようにユーザに求めることができる。

プライマリ障害ハンドラとしては、リダイレクションハンドラ、一時中止ハンドラ、およびスナップショットハンドラがある。以下では、これらの障害ハンドラの各々について詳しく説明する。

リダイレクションハンドラ
リダイレクションハンドラが起動されたときは、リダイレクションハンドラはプライマリアプリケーションをプライマリアプリケーションの「保存と終了」ロジックにリダイレクトし、そのあと終了する。リダイレクションハンドラを使用する本発明の実施形態は図３に示されている。障害が発生した時点では、プライマリアプリケーション１００は、障害ディテクタ２０１のインターセプトルーチン（ｉｎｔｅｒｃｅｐｔ ｒｏｕｔｉｎｅ）の内側で実行されている。オペレーティングシステムのプログラムカウンタは、現在このインターセプトルーチンをポイントしているので、障害を起こしたＡＰＩへのコールの後の次の命令を実行することを続けるのが通常である。リダイレクションハンドラは、順に、アプリケーションの保存ロジック３０２を起動してから、プライマリアプリケーション１００から出ることになる。この保存ロジックの起動は、（ａ）プライマリアプリケーション１００の保存エントリポイントを直接にコールするか、（ｂ）プログラムカウンタを保存エントリポイントにリセットするか、あるいは（ｃ）保存と終了ロジックを強制するためにコール側プログラムにジャンプ命令を挿入するか、によって実現されている。

図３に示す例では、プライマリアプリケーションは、ＡＰＩのｃａｌｌ＿ｔｈｅｓａｕｒｕｓ（）をコールすることを試みる。このルーチンのコードセグメントはオペレーティングシステム３０３によってページインされていない。従って、オペレーティングシステム３０３はコールをインターセプトし、コードページをリトリーブするためにそのバーチャルメモリマネージャ３０４にクエリする。これが失敗したときは、オペレーティングシステム３０３はページ不在を引き起こし、通常はプライマリアプリケーションを中止する。そのあと、ページ不在はリダイレクションハンドラ３０６によってインターセプトされる。別の方法として、リダイレクションハンドラ３０６は、「コードをリトリーブするのに失敗した」ページをルーチンから直接に受け取ることもできる。

ケースによっては、プライマリアプリケーションには、保存と終了にはいくつかの変形がある場合がある。そのようなものとして、「別名保管（ｓａｖｅ ａｓ）」、「切り離し（ｄｉｓｃｏｎｎｅｃｔ）」または「終了（ｅｘｉｔ）」があり、これは保存関数をカプセル化している。障害ハンドラ３０６は、ユーザが完了した作業を安全な方法で保存し、アプリケーションから出られるようにして、アプリケーションの障害および／またはクラッシュを回避することを保証する。ユーザはアプリケーションから出たあと、アプリケーションをリスタートすることができるが、ユーザには、障害が発生したことおよび再発のおそれのあることが知らされる。

障害ハンドラの一実施形態では、プライマリアプリケーションはその「保存」ロジックを起動するが、そのデータファイルはローカルデータソースまたはプロキシストア（ｐｒｏｘｙ ｓｔｏｒｅ）にリダイレクトされるので、プライマリアプリケーションは、データファイルが壊されているため書き込みに失敗した場合や、データファイルがネットワークファイルであって、ネットワークが利用できない場合に、その保存オペレーションを完了することができる。プログラムは、ネットワークファイルサーバと通信できなかったか、あるいはそのファイルを効果的に保存できなかったものとして、別のエラーを引き起こすのが通常である。再接続されたとき、データファイルまたはプロキシストアは、ソースデータファイルと同期させることも、ソースデータファイルを置き換えることもできる。

一時中止ハンドラ
一時中止ハンドラが起動されたときは、一時中止ハンドラは、プライマリアプリケーション１００を構成するすべてのプロセス、子プロセスおよびスレッドを一時中止する。プライマリアプリケーション１００が一時中止されたあと、一時中止ハンドラは再開が可能であるとの通知を待っている（例えば、ネットワークが再確立された、あるいはユーザが継続を望んでいることを示すコントロールを選択した、といったイベント）。継続の要求を受けたときは、一時中止ハンドラは、（ａ）プライマリアプリケーションを直接に再開すること、（ｂ）プログラムカウンタをリセットすること、あるいは（ｃ）障害を起こした元のＡＰＩを再起動することができる。

一時中止している間、プライマリアプリケーション１００はその全体形式が存在したままになっており、ターゲットコンピュータ１０１上のアプリケーションとして見られている。一実施形態では、一時中止ハンドラは、Ｗｉｎｄｏｗｓ（登録商標） Ｔａｓｋ Ｍａｎａｇｅｒなどの簡易システムツールを通してプライマリアプリケーションが偶発的に再開するのを防止している。一時中止ハンドラは、明示的手段を通してあるいは内部ヘルパアプリケーション１０２を通してのみ制御可能になるようにプライマリアプリケーションを一時中止する。

一時中止ハンドラは、明示的「保存」関数がないアプリケーション用に使用されることが多い。アプリケーションは一連の副次作用（ｓｉｄｅ ｅｆｆｅｃｔ）として、あるいは外部サーバ、データベースまたは他のシステムとの通信を通してそのステートを保存している。１つの例において、アプリケーションがハイパテキストアプリケーションであり、ＨＴＴＰサーバとのコネクションが失われたとする。この例では、ハイパテキストアプリケーションのユーザ側のステートをストアすることも、ハイパテキストブラウザアプリケーション全体をストアすることもできる。サーバがオンラインに戻ったとき、アプリケーションは保存したステートを使用して継続することができる。

スナップショットハンドラ
障害が長期的な問題であることを示し、ターゲットコンピュータがパワーサイクル（ｐｏｗｅｒ ｃｙｃｌｅｄ）しているか、あるいは別の障害を受けている可能性があるために、一時中止が問題の持続より長く存続しない場合、スナップショットハンドラが起動される。この事態が起こった場合には、後日のリストアに備えてプライマリアプリケーションの稼動状態をバックアップにとっておくことが望ましい。

スナップショットハンドラが起動されると、スナップショットハンドラは、プライマリアプリケーションのプロセスとスレッドを一時中止し、プライマリアプリケーションのメモリスナップショットをとるが、この中には、アプリケーションの一部ではなく、アプリケーションをプロセスとしてリストアするために使用されるカーネルデータ構造が含まれている。このメモリスナップショットは、後日の回復に備えてディスクに書き出しておくことができる。別の方法では、スナップショットハンドラは、よりきめ細かい回復が行なえるように定期的に、先を見越してプライマリアプリケーションのスナップショットをとることができる。極度のオーバヘッドを回避するために、メモリスナップショットを迅速にとり、バックグラウンドでメモリをディスクまたは他の不揮発性ストレージにストアすることができる。スナップショットが完了すると、スナップショットハンドラは、スナップショットがとられたのが長期的な問題のためであれば、プライマリアプリケーションを中止することができる。

プライマリアプリケーションが中止されると、ヘルパアプリケーション１０２は、障害がクリアされるか、あるいはユーザがアプリケーションを再起動することを望んでいることを明示的に確認するまでは、アプリケーションが再起動されるのを防止する働きをする。起動されたとき、ヘルパアプリケーションはプライマリアプリケーションをリストアすることができるが、プライマリアプリケーションの別のインスタンスを作成させるだけで済ますこともできる。別の方法として、ヘルパアプリケーションは、スナップショットイメージをネットワーク内のピアまたはサーバコンピュータに転送し、そこで再開させることもできる。

リストアされると、障害ハンドラは、プロセスのメモリを逆マッピング（ｍａｐ ｂａｃｋ）し、プログラムが中止されたときと同じように正確に継続できるように内部オペレーティングシステムのカーネルデータ構造をリセットする。１つの例として、アプリケーション１００が障害発生時にいくつかのファイルをオープンしている場合には、スナップショットハンドラは、これらのファイルを再オープンし、プライマリアプリケーションが旧ファイルハンドルの使用を試みてエラーを引き起こさないように、知らされたファイルハンドルを再割り当てする必要がある。また、ファイルハンドルは、ストリームアクセスのためにセットされている場合は、ファイル内の該当オフセットをポイントしていなければならない。

図５は、本発明のヘルパアプリケーションの一実施形態のフローチャートを示す図である。潜在的に障害のあるＡＰＩがステップ５０１、５０２でコールされ、ヘルパアプリケーション１０２は、コールが正しく行なわれたかどうか、あるいは障害が発生したかどうかをステップ５０４で質問する。障害が発生していなければ、ステップ５０５でアプリケーションからＡＰＩの結果が戻される。障害が発生していれば、ヘルパアプリケーション１０２は障害ハンドラを特定し、リダイレクションハンドラと一時中止ハンドラのどちらかを選択する。一時中止ハンドラがステップ５０８で選択された場合は、ヘルパプログラムはプライマリアプリケーションが再開可能であるかどうかを質問する。プログラムが再開される場合は、ステップ５０５でプログラムからＡＰＩ結果が戻される。プライマリアプリケーションが再開されない場合は、ヘルパアプリケーションはＡＰＩを再起動するかどうかをステップ５１０で質問する。ＡＰＩが再起動されない場合は、ヘルパアプリケーションはスナップショットが利用可能であるかどうかを質問する。ステップ５１１においてスナップショットが利用可能であれば、ヘルパアプリケーションはステップ５１３でＰＣをスナップショットに戻す。スナップショットが利用可能でなければ、ステップ５１２でプログラムカウンタをリセットする。

本発明のさらに別の実施形態では、ヘルパアプリケーション１０２は、データベース、ＴＣＰ／ＩＰソケットまたは他のＩＰＣメカニズムなどとの外部コネクションもリストアする。それを行なうために、ヘルパアプリケーション１０２は、ＨＴＴＰサーバによるデータベースログインや認証といった援助をユーザに求めることがある。上述したように、システムは、いくつかのプライマリアプリケーション内部をリセットしたり、ソケット記述子（ｓｏｃｋｅｔ ｄｅｓｃｒｉｐｔｏｒ）のように、変化したエンティティにハンドルをリダイレクトしたりする必要が起こることがある。代替実施形態では、障害の有無に関係なく、ユーザがこの振る舞いを明示的に起動するのを可能にするユーザインタフェースを設けることができる。

ヘルパアプリケーションは、ヘルパアプリケーションが処理する障害別に分類すると共に、ヘルパアプリケーションが起動できるハンドル別に分類する。ヘルパアプリケーションは、種々の手法を通してこのことをオフラインまたはオンラインで知ることができる。一例では、障害ハンドラは、すべての障害を検出するように登録される。

本発明の別の実施形態では、プライマリアプリケーションコードについてスタティック分析を行なうために追加ステップがとられて、その構成と障害の潜在性が判断されると共に、「保存」や「終了」などの共通プログラムエントリポイントが判断される。潜在的障害を調べるとき、分析ルーチンは、ファイルへのアクセスまたはＯＤＢＣによるデータベースへのアクセスといった共通ＡＰＩのセットの使用、あるいは上述したように、ｍａｌｌｏｃ（）とｆｒｅｅ（）などのメモリルーチンまたはｓｏｃｋｅｔ（）またはＷｉｎｄｏｗｓ（登録商標） ＧｅｔＮａｍｅｄＰｉｐｅ（）などのＩＰＣルーチンの使用を探し出す。

分析が完了したあと、アナライザ４０３は、システムの利用可能障害ハンドラを通して回復可能であると分かっている障害および回復可能でない障害と障害処理のための推奨方法のリストを提示することができる（図４参照）。どちらの障害の場合も、障害ハンドラを構成するためのアクションを禁止することができる。回復可能でない障害の場合は、リダイレクションハンドラが使用されるのが普通である。「保存」コードが存在しないか、特定できない場合は、システムは単純に安全に終了するようにセットアップすることができる。

プログラムエントリポイントを分析するために、システムはプラットフォームの知識を使用してソースを見つけることができる。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）プラットフォームでは、ＷＭ＿ＥＸＩＴメッセージに応答できるメッセージハンドラは、プログラムの「終了」ルーチンに対応付けることができる。従って、ＷＭ＿ＥＸＩＴをサーチすると、この関数ポイント（ｆｕｎｃｔｉｏｎ ｐｏｉｎｔ）が示される。別の方法として、リソースファイルには、Ｆｉｌｅ：Ｅｘｉｔメニューコマンドと起動時に生成されるＷｉｎｄｏｗｓ（登録商標）メッセージを記述することができる。これらのインジケータが存在しないときは、アナライザはさらに進んで、Ｗｉｎｄｏｗｓ（登録商標） ＥｘｉｔＰｒｏｃｅｓｓ（）またはｅｘｉｔ（）ルーチンなどの、ＡＰＩの使用を探し出す。「保存」ルーチンを探し出すとき、アナライザはファイルまたは外部データソースの使用を探し出すことができる。

代替実施形態では、障害とエントリポイントはダイナミック分析を使用して特定することができる。プログラムは、これらのシグネーチャ（ｓｉｇｎａｔｕｒｅ）を特定するためにその実行中にトレースすることができる。一実施形態では、ダイナミック分析は、マクロ記録（ｍａｃｒｏ ｒｅｃｏｒｄｉｎｇ）と同じようにエントリポイントを記録するエントリポイント識別子ＵＩ４０４を使用して行なわれる。「保存」関数を特定していることをユーザが示していると、この識別子にはすべてのＵＩとプログラムアクティビティが記録される。これらのシグネーチャから、エントリポイントと関連コードを特定することができる。アプリケーションがオフラインで使用されるストリーム化アプリケーション（ｓｔｒｅａｍｅｄ ａｐｐｌｉｃａｔｉｏｎ）では、「保存」と「終了」関数で特定されたコードには、この振る舞いが起動可能であることを保証するためにコードが常にストリーム化され、オフラインモードで存在していなければならないことを示すタグが特別に付けられる。

本発明によれば、アプリケーションの使用中の破壊や障害を、作業を失うことなく受け入れることを可能にする手段も提供されている。アプリケーションの使用中に障害が起こると、そのプログラムで行なわれた一部の作業量が、完了しているか否かに関係なく、放棄されるのが通常である。本発明のシステムと方法によれば、プログラムを単純に回復するのではなく、それ以上にデータ損失が起こらないことを保証する手段が使用可能になっている。さらに、これは、ソフトウェアを修正したり、コンパイルし直したり、設計し直したりしなくても行なわれ、このパラダイム（ｐａｒａｄｉｇｍ）を念頭に入れて新プログラムを構築することを可能にしている。

以上、若干の好適実施形態と関連付けて本発明を説明してきたが、当然に理解されるように、本発明はこれらの特定実施形態に限定されるものではなく、むしろ、本発明は、代替実施形態、変更および等価技術も包含することを意図している。いくつかの特定コンポーネント、図およびマテリアルのタイプが言及されているが、当然に理解されるように、かかるコンポーネントの値、寸法およびマテリアルのタイプは単なる例示であり、本発明の範囲をいかなる態様においても限定するものではない。

本発明のシステムと方法の一実施形態を示す概略図である。 図１に図示の本発明のシステムと方法で利用される障害検出プロセスを示す概略図である。 図１に図示の本発明のシステムと方法におけるプログラムカウンタのオペレーションを示す概略図である。 図１に図示の本発明のシステムと方法によって使用されるプログラムアナライザを示す概略図である。 障害を検出し、処理するために図１に図示の本発明の方法によって実行されるステップを示すフローチャートである。

Claims (9)

1. コンピュータアプリケーションを実行中のデータ損失を最小限にする方法であって、
   前記コンピュータアプリケーションのコールをインターセプトするステップと、
   障害又は潜在的障害の存在を検出するためにインターセプトされた前記コールの結果を調べるステップと、
   障害又は潜在的障害の前記存在が検出された場合に、
   前記障害または潜在的障害を処理するためのメソッドを選択するステップと、
   前記障害または潜在的障害を処理するための選択された前記メソッドを実行するステップとを備え、
   前記インターセプトするステップ、調べるステップ、選択するステップおよび実行するステップは、前記コンピュータアプリケーションのコードにアクセスすることなく、あるいは前記コンピュータアプリケーションのコードを修正することなく実行され、
   障害又は潜在的障害の前記存在が検出されない場合には、前記コンピュータアプリケーションへコントロールを戻し、
   前記障害または潜在的障害を処理するためのメソッドは、以下のメソッド、すなわち、前記コンピュータアプリケーションの前記コードの実行をリダイレクトするメソッド、前記コンピュータアプリケーションを一時中止するメソッド、および前記コンピュータアプリケーションのメモリスナップショットをとるメソッドの中から選択されることを特徴とする方法。
2. 前記障害または潜在的障害を処理するための選択されたメソッドを実行するステップは、データを保存するために前記コンピュータアプリケーションの保存ロジックを起動することを含むことを特徴とする請求項１に記載の方法。
3. 前記障害または潜在的障害を処理するための選択されたメソッドを実行するステップは、
   前記コンピュータアプリケーションを一時中止することと、
   再開の実行が可能であるとの指示を求めて前記コンピュータアプリケーションをモニタすることと、
   前記コンピュータアプリケーションを再開するか、前記コンピュータアプリケーションのプログラムカウンタをリセットするか、あるいは、障害を起こした元のＡＰＩを再起動するかのいずれかを選択することとを含むことを特徴とする請求項１に記載の方法。
4. 前記障害または潜在的障害を処理するための選択されたメソッドを実行するステップは、
   前記コンピュータアプリケーションを一時中止することと、
   前記コンピュータアプリケーションのメモリスナップショットをとることと、
   前記メモリスナップショットを不揮発性ストレージ手段にストアすることとをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記コンピュータアプリケーションの内部オペレーションをモニタするステップをさらに備えることを特徴とする請求項１に記載の方法。
6. 外部イベントをモニタするステップをさらに備えることを特徴とする請求項１に記載の方法。
7. 前記障害または潜在的障害に関して前記コンピュータアプリケーションのユーザと通信するステップをさらに備えることを特徴とする請求項１に記載の方法。
8. 共通エントリポイントを特定するために前記コンピュータアプリケーションのコードを分析するステップをさらに備えることを特徴とする請求項１に記載の方法。
9. 共通エントリポイントを特定するためにコードを分析するステップは、その実行中に前記アプリケーションをトレースすることを含むことを特徴とする請求項８に記載の方法。

Images