(57)【特許請求の範囲】
【請求項１】
多数の物理ノードが参加する分散環境においてデータを処理するための方法であって、
前記多数の物理ノードが提供するリソースを統合した仮想空間を生成し、
前記物理ノード上で動作する複数の第１アプリケーションが、前記物理ノードに前記仮想空間からのデータの読み取り又は前記仮想空間へのデータの書き込みを実行させること、を含み、
前記データは、前記データの属性によって決定される前記仮想空間上の特定の位置領域にマッピングされ、
前記複数の第１アプリケーションは、前記物理ノードに前記位置領域における前記データに対する読み取り又は書き込みを実行させ、
前記多数の物理ノードのそれぞれは、前記仮想空間の少なくとも一つの仮想ノードに対応し、
前記仮想空間の生成又は前記仮想空間に参加する仮想ノード数の変化に応じて、前記少なくとも一つの仮想ノードのそれぞれに、当該仮想ノードが担当する前記仮想空間のデータ領域が自動的に割り当てられ、
前記複数の第１アプリケーションの１つが、前記処理の作業を分散処理可能な多数の部分作業に分割して、前記データを前記仮想空間に保存し、前記複数の第１アプリケーションの他の少なくとも１つに前記部分作業を分散処理させ、前記物理ノードに前記分散処理されたデータの取得を実行させる前記仮想空間のデータ領域は、前記多数の物理ノードのうち、前記複数の第１アプリケーションの他の少なくとも１つを動作させる物理ノードのリソースが割り当てられた仮想ノードが担当するデータ領域に限定されることを特徴とする方法。
【請求項２】
前記位置領域は、前記データに所定のハッシュ関数を適用することにより決定されることを特徴とする請求項１に記載の方法。
【請求項３】
前記ハッシュ関数は、前記データを前記仮想空間上の特定位置にマッピングさせるためのものであることを特徴とする請求項２に記載の方法。
【請求項４】
前記ハッシュ関数によって処理されるデータは、予めサンプリングされたものであることを特徴とする請求項３に記載の方法。
【請求項５】
前記ハッシュ関数又は前記多数の物理ノードのそれぞれが提供する前記仮想空間の一領域は、前記サンプリングを通じて調節されることを特徴とする請求項４に記載の方法。
【請求項６】
請求項１乃至５のいずれか一項に記載の方法を物理ノードに実行させるためのコンピュータプログラムを記録することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項７】
多数の物理ノードと、
前記物理ノード上で動作する複数の第１アプリケーションと、
を含む分散環境においてデータを処理するためのシステムであって、
前記多数の物理ノードが提供するリソースを統合した仮想空間が生成され、
前記複数の第１アプリケーションは、前記物理ノードに前記仮想空間からのデータの読み取り又は前記仮想空間へのデータの書き込みを実行させ、
前記データは、前記データの属性によって決定される前記仮想空間上の特定の位置領域にマッピングされ、
前記複数の第１アプリケーションは、前記物理ノードに前記位置領域における前記データに対する読み取り作業又は書き込み作業を実行させ、
前記多数の物理ノードのそれぞれは、前記仮想空間の少なくとも一つの仮想ノードに対応し、
前記仮想空間の生成又は前記仮想空間に参加する仮想ノード数の変化に応じて、前記少なくとも一つの仮想ノードのそれぞれに、当該仮想ノードが担当する前記仮想空間のデータ領域が自動的に割り当てられ、
前記複数の第１アプリケーションの１つが、前記処理の作業を分散処理可能な多数の部分作業に分割して、前記データを前記仮想空間に保存し、前記複数の第１アプリケーションの他の少なくとも１つに前記部分作業を分散処理させ、前記物理ノードに前記分散処理されたデータの取得を実行させる前記仮想空間のデータ領域は、前記多数の物理ノードのうち、前記複数の第１アプリケーションの他の少なくとも１つを動作させる物理ノードのリソースが割り当てられた仮想ノードが担当するデータ領域に限定されることを特徴とするシステム。
【請求項８】
前記位置領域は、前記データに所定のハッシュ関数を適用することにより決定されることを特徴とする請求項７に記載のシステム。
【請求項９】
前記ハッシュ関数は、前記データを前記仮想空間上の特定位置にマッピングさせるためのものであることを特徴とする請求項８に記載のシステム。
【請求項１０】
前記ハッシュ関数によって処理されるデータは予めサンプリングされたものであることを特徴とする請求項９に記載のシステム。
【請求項１１】
前記ハッシュ関数、又は前記多数の物理ノードそれぞれが提供する前記仮想空間の一領域は、前記サンプリングを通じて調節されることを特徴とする請求項１０に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散スペース（ｄｉｓｔｒｉｂｕｔｅｄ  ｓｐａｃｅ）を用いて分散プログラミング環境（ｄｉｓｔｒｉｂｕｔｅｄ  ｐｒｏｇｒａｍｍｉｎｇ  ｅｎｖｉｒｏｎｍｅｎｔ）を提供するための方法、システム及びコンピュータ読み取り可能な記録媒体に関する。より詳細には、多数のノード又はプロセス（ｐｒｏｃｅｓｓ）がアクセス可能な分散スペースを生成し、前記分散スペースを介してデータを共有できるようにすることで、分散プログラミングを可能にする方法、システム及びコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
ネットワーク通信技術の発達によってリモートコンピュータ間の大容量データの送受信が容易になり、これによって、多数のコンピュータが連携して一つの作業を処理する分散プログラミング（又はコンピューティング）（ｄｉｓｔｒｉｂｕｔｅｄ  ｐｒｏｇｒａｍｍｉｎｇ  （ｏｒ  ｃｏｍｐｕｔｉｎｇ））技術が徐々に普遍化されている。
【０００３】
このような分散プログラミング環境を構築するための主要技術としてＳＢＡ（Ｓｐａｃｅ−Ｂａｓｅｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）が挙げられる。ＳＢＡは、タプルスペース（ｔｕｐｌｅ  ｓｐａｃｅ）を利用して処理状態を把握する（ｓｔａｔｅｆｕｌ）高性能アプリケーションの線形拡張性（ｌｉｎｅａｒ  ｓｃａｌａｂｉｌｉｔｙ）を実現するためのソフトウェア構造パターンであって、エール大学のデイヴィッド・ガランター（Ｄａｖｉｄ  Ｇｅｌｅｒｎｔｅｒ）が提唱したリンダ（Ｌｉｎｄａ）のタプルスペースの概念に由来している。ＳＢＡによると、全ての分散プロセスは、スペースを基盤にして相互通信とリソースシェアリングを行うため、互いに関する詳細な情報を必要としない。また、時間と空間の制約を受けず、単純なインターフェースのみで多様な方式の分散プログラミングが可能になるという長所を有する。
【０００４】
近年、ＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｈａｓｈ  Ｔａｂｌｅ；分散ハッシュテーブル）という非集中的分散システムが注目されており、ＤＨＴは、ハッシュテーブル（ｈａｓｈ  ｔａｂｌｅ）に類似したルックアップ（ｌｏｏｋ‐ｕｐ）サービスを提供することを特徴としている。ＤＨＴは、リソースの均等な分散と構造化されたトポロジー（ｔｏｐｏｌｏｇｙ）とによってネットワークの拡張性とロバスト性（ｒｏｂｕｓｔｎｅｓｓ）を確保するとともに、迅速なルックアップサービスを提供することができるため、Ｐ２Ｐサービスのような多様な分野で活用されている。
【０００５】
このようにＤＨＴが技術的優位性を有しているにもかかわらず、実際には、分散環境において大規模な計算問題に対するＤＨＴの適用事例を見付けることは容易ではない。そのため、ＳＢＡ及びＤＨＴの長所を両方持ち合わせる新しい分散プログラミング環境の必要性が台頭している。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、上記問題点を全て解決することを目的とする。
【０００７】
また、本発明は、作業を分配して分散処理の効率性を向上させるとともに、分散プログラミング環境の線形拡張性を確保することを他の目的とする。
【０００８】
さらに、本発明は、構造化されたトポロジーを基盤にしてデータに対する迅速なアクセスを可能にすることを他の目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するための本発明の代表的な構成は以下のとおりである。
【００１０】
本発明の一実施例によると、分散環境においてデータを処理するための方法であって、多数のノードが提供するリソースを用いて仮想空間を生成し、第１アプリケーションが仮想空間からデータを読み取り又は仮想空間にデータを書き込むこと、を含み、前記データは、データの属性によって決定される仮想空間上の特定の位置領域にマッピングされ、第１アプリケーションは、前記位置領域において前記データの読み取り作業又は書き込み作業を行う方法が提供される。
【００１１】
本発明の他の実施例によると、分散環境においてデータを処理するためのシステムであって、多数のノードが提供するリソースを用いて生成される仮想空間と、仮想空間からデータを読み取り又は仮想空間にデータを書き込む第１アプリケーションを含み、前記データは、データの属性によって決定される仮想空間上の特定の位置領域にマッピングされ、第１アプリケーションは、前記位置領域において前記データの読み取り作業又は書き込み作業を行うシステムが提供される。
【００１２】
この他にも、本発明を実現するための他の方法、システム及び前記方法を実行するためのコンピュータプログラムを記録するためのコンピュータ読み取り可能な記録媒体がさらに提供される。
【発明の効果】
【００１３】
本発明によると、大規模な計算問題を多数のコンピュータを用いて分散処理することにより、作業の効率性を向上させることができる。
【００１４】
また、本発明によると、分散プログラミング環境の線形拡張性を確保するという効果を奏する。
【００１５】
さらに、本発明によると、分散プログラミング環境下でデータに対する迅速なアクセスが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施例における全体システムの構成を概略的に示す図である。
【図２】本発明の一実施例における仮想空間を例示的に示す図である。
【図３】本発明の一実施例における二つの方式のマスターワーカモデルを示す図である。
【図４】本発明の一実施例によおける二つの方式のマスターワーカモデルを示す図である。
【図５】本発明の一実施例においてフェイルオーバーが行われる例を示す図である。
【図６】本発明の一実施例においてフェイルオーバーが行われる例を示す図である。
【図７】３−ｃｏｐｙレプリケーションポリシー（３−ｃｏｐｙ  ｒｅｐｌｉｃａｔｉｏｎ  ｐｏｌｉｃｙ）の下でノードが追加された場合に行われるデータ交換を例示的に示す図である。
【発明を実施するための形態】
【００１７】
以下の本発明に関する詳細な説明において、本発明を実施することのできる特定の実施例を例として図示する添付の図面を参照する。これらの実施例は当業者が本発明を十分に実施することができるように詳細に説明される。本発明の多様な実施例は相互に異なるが相互に排他的である必要はないと理解されるべきである。例えば、本明細書に記載されている特定の形状、構造及び特性は、一実施例において本発明の思想及び範囲を外れない限り他の実施例において実施されてもよい。また、開示された夫々の実施例のうちの個別の構成要素の位置または配置は、本発明の思想及び範囲を外れない限り変更されてもよいと理解されるべきである。従って、以下の詳細な説明は、本発明の範囲を限定的な意味に制限しようとする意図ではない。本発明の範囲は、適切に説明されれば、その特許請求の範囲に記載されているものと均等な全ての範囲とともに添付の特許請求の範囲によってのみ限定される。図面において類似の参照符号は様々な側面に亘って同一または類似の機能を指称する
【００１８】
以下、本発明の属する技術分野における通常の知識を有する者が本発明を容易に実施することができるように、本発明の実施例について添付図面を参照して詳細に説明する。
【００１９】
実施例
全体システムの構成
図１は、本発明の一実施例における全体システム（ｏｖｅｒａｌｌ  ｓｙｓｔｅｍ）の構成を概略的に示す図である。
【００２０】
図１に示すように、本発明の一実施例における全体システムは、通信網１００、分散プログラミング環境を構成するクラスタ２００、及び分散プログラミング環境を基盤として行われる多数のアプリケーション３００で構成されてもよい。
【００２１】
まず、通信網１００は、有線及び無線のような通信方式を問題とせずに構成されてもよく、ローカルエリアネットワーク（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ；ＬＡＮ）、メトロポリタンエリアネットワーク（Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｌ；ＭＡＮ）、ワイドエリアネットワーク（ＷＩＤＥ  Ａｒｅａ  Ｎｅｔｗｏｒｋ；ＷＡＮ）など多様な通信網で構成されてもよい。
【００２２】
本発明の一実施例によると、クラスタ２００は、多数のコンピュータ（以下、「ノード」という。）で構成され、分散プログラミングを行うことができるように演算装置、メモリなどのようなリソースをアプリケーション３００に提供する機能を行うものでもよい。即ち、本発明の一実施例におけるクラスタ２００は、多数のアプリケーション３００がデータ又はプログラムコードを共有することができるように装置を提供し、アプリケーション３００の要請に応じて特定のデータを提供したり、アプリケーション３００が要請する作業を行った結果をアプリケーション３００に返送するものでもよい。
【００２３】
また、本発明の一実施例によると、多数のノードで構成されたクラスタ２００が提供するリソースが一つの統合スペースを形成することにより、アプリケーション３００は、あたかも一つのコンピュータによって作業を行っているかのように動作するものでもよい。
【００２４】
また、本発明の一実施例によると、統合スペースの各領域は、アプリケーション３００の要請に応じて少なくとも一つの仮想空間（ｖｉｒｔｕａｌ  ｓｐａｃｅ）にマッピングされてもよい。また、仮想空間に特定のアプリケーション３００のみがアクセスできるようにすることで、共通の作業を行おうとする多数のアプリケーション３００間の通信やデータ共有を可能とし、互いに独立したアプリケーション３００間の干渉を排除してもよい。
【００２５】
本発明の一実施例によると、アプリケーション３００は、クラスタ２００を用いて分散プログラミング作業を行おうとするプログラムであってもよい。
【００２６】
本発明の一実施例によると、アプリケーション３００は、仮想空間からデータを読み取る作業を行い、又は仮想空間にデータを書き込む作業を行うことで、他のアプリケーション３００と通信してもよく、これにより分散プログラミングを行ってもよい。
【００２７】
一方、図１では、アプリケーション３００がクラスタ２００を構成するノードから物理的に分離された他のコンピュータ上で実行されているように図示されているが、本発明の他の実施例によると、アプリケーション３００は、クラスタ２００内に含まれるノード上で動作するプログラムであってもよい。また、本発明において、アプリケーション３００は、所定作業を実行したり、所定作業の実行を容易にするために設計されたプログラムの通称であって、応用プログラムだけでなく、プロセス、スレッド（ｔｈｒｅａｄ）などを包括する最も広い意味で理解されるべきである。
【００２８】
データの保存及び利用
本発明の一実施例によると、特定作業を行おうとするアプリケーション３００は、当該アプリケーションに割り当てられた仮想空間にデータを保存したり、保存されたデータを利用したりすることによって作業を行う。より具体的には、アプリケーション３００によって扱われるデータは、キー（ｋｅｙ）と値（ｖａｌｕｅ）のペアからなるものでもよい。ここで、キー（ｋｅｙ）は、データに対するインデックスとして機能するものでもよく、値（ｖａｌｕｅ）は、データの値であってもよい。
【００２９】
本発明の一実施例によると、前記のようなデータは、所定の基準に基づいて仮想空間内に保存されるが、その具体的な実施例を図２を参照して説明すると以下のとおりである。
【００３０】
図２は、本発明の一実施例における仮想空間を例示的に示す図である。
【００３１】
図２を参照すると、仮想空間は少なくとも一つの仮想ノード２１０〜２７０の提供するスペースが統合されたものであって、あたかも一つの巨大メモリであるかのように表現されていることが分かる。従って、仮想ノード２１０〜２７０は、仮想空間の領域を多数のセクションに区分する基準点としての機能を担ってもよい。また、それぞれの仮想ノード２１０〜２７０の提供するスペースはそれぞれの仮想ノード２１０〜２７０が生成されているノード２００ａ〜２００ｆ上に存在する特定のリソース（例えば、メモリ）にマッピングされてもよい。ここで、特定のノード（例えば、２００ａ）が仮想ノードを生成するとは、ノード２００ａのリソース（例えば、メモリの一領域）が当該仮想ノードに割り当てられることを意味する。
【００３２】
本発明の一実施例によると、図２に示されたそれぞれの仮想ノード２１０〜２７０は、少なくとも一つのノード２００ａ〜２００ｆによって生成されてもよい。例えば、仮想ノードＦ２６０と仮想ノードＧ２７０の両方がノード２００ａによって生成されてもよく、仮想ノードＦ２６０は、ノード２００ａによって生成され、仮想ノードＧ２７０はノード２００ｂによって生成されてもよい。
【００３３】
本発明の一実施例によると、仮想空間にデータが保存される場合、保存されたデータは仮想空間内の特定領域にマッピングされてもよい。より具体的には、データのキー（ｋｅｙ）に所定のハッシュ関数を適用して仮想空間内にマッピングさせてもよい。図２を参照すると、特定データのキー（ｋｅｙ）をパラメータとしてハッシュ関数を適用すると、前記データが仮想空間の「３１０７」領域にマッピングされることが記載されている。
【００３４】
本発明の一実施例によると、それぞれの仮想ノード２１０〜２７０にはそれぞれの仮想ノード２１０〜２７０が担当することができる仮想空間のデータ領域に関する情報がＩＤ（以下、「スペースＩＤ」という。）の形で付与されてもよい。図２を参照すると、仮想ノードＦ２６０にはスペースＩＤとして「２９０６」が付与されており、仮想ノードＧ２７０にはスペースＩＤとして「３４８５」が付与されていることが確認できる。このようなスペースＩＤを用いて仮想空間内のデータをそれぞれの仮想ノードに割り当ててもよい。例えば、図２の仮想ノードＦ２６０の場合、そのスペースＩＤである「２９０６」以上、仮想ノードＧ２７０のスペースＩＤである「３４８５」未満のスペースＩＤを有する仮想空間領域内にマッピングされるデータに対する情報処理（例えば、読み出し（ｒｅａｄ）、書き込み（ｗｒｉｔｅ）、取り出し（ｔａｋｅ）など）を担当してもよい。
【００３５】
上記のようなスペースＩＤは様々な方式で付与されてもよい。本発明の一実施例によると、スペースＩＤは分散プログラミング環境を管理するオペレータによって手動で付与されてもよいが、仮想空間の生成や仮想空間に参加する仮想ノード数の変化に応じて自動的に決定されてもよい。
【００３６】
より具体的には、仮想ノードに付与されるスペースＩＤは仮想空間に保存されるデータがマッピングされ得る領域と密接に関係しているため、データを仮想空間内にマッピングさせるために利用されるハッシュ関数と同一のハッシュ関数を用いて決定されてもよい。本発明の一実施例によると、スペースＩＤを決定するためにハッシュ関数に入力されるパラメータには、仮想ノードを生成するノードのＩＰアドレスの情報、ｃｏｍポートの情報、仮想空間の属性情報、仮想空間の名称情報などが含まれてもよい。
【００３７】
前記のように仮想空間にデータを保存する方式が、実際の分散プログラミング環境に適用される一例として、大規模な作業が多数のセグメントに分割されて多数のアプリケーションに割り当てられる場合を想定してもよい。即ち、特定のアプリケーションが大規模な作業を分散処理可能な多数の部分作業に分割してこれを分散スペースに保存することにより、部分作業が多数の他のアプリケーションによって分散処理されてもよい。
【００３８】
本発明の一実施例によると、前記のような方法によって保存されるデータは、当該データに対する読み出し／取り出し（ｒｅａｄ／ｔａｋｅ）作業を行おうとするアプリケーション３００によって同一の方式でルックアップされてもよい。即ち、アプリケーション３００が特定のキー（ｋｅｙ）を有するデータをルックアップしようとする場合、当該キー（ｋｅｙ）にハッシュ関数を適用して仮想空間内における位置を取得し、当該位置領域に対する処理を担当する仮想ノードから前記キー（ｋｅｙ）に対応するデータを取得してもよい。
【００３９】
本発明の他の実施例によると、仮想空間に保存されたデータに対するルックアップは、局所性（ｌｏｃａｌｉｔｙ）を確保する方式で行われてもよい。即ち、アプリケーション３００がルックアップすることのできる仮想空間の領域を仮想空間内の特定領域に制限してもよい。例えば、アプリケーション１には仮想ノードＡ２１０及び仮想ノードＢ２２０が担当する領域に対するルックアップのみを許容し、アプリケーション２には仮想ノードＢ２２０及び仮想ノードＣ２３０が担当する領域に対するルックアップのみを許容し、アプリケーション３には仮想ノードＤ２４０及び仮想ノードＥ２５０が担当する領域に対するルックアップのみを許容してもよい。この際、仮想空間に保存されるデータを予めサンプリングしてデータの特性を把握することによりデータが仮想空間上に均一に分布されるため、分散プログラミングをより効率的に行うことができる。これは、データ処理の局所性が確保されるマスターワーカモデル（ｍａｓｔｅｒ−ｗｏｒｋｅｒ  ｍｏｄｅｌ）やスキャッタギャザーモデル（ｓｃａｔｔｅｒ−ｇａｔｈｅｒ  ｍｏｄｅｌ）においてより重要といえるが、データ処理モデルに関する具体的な内容は後で説明する。
【００４０】
本発明の一実施例によると、仮想空間を利用する多数のアプリケーション３００が、仮想空間に参加するノード２００ａ〜２００ｆ上に存在する場合に前記のような方式を採択すると、データを処理しようとするアプリケーション３００がルックアップすることのできる仮想空間の領域を、アプリケーション３００が存在するノードから生成された仮想ノードが担当する領域に限定してもよい。そのため、データを割り当てるアプリケーション３００によって作業が分散される過程のみにネットワーク通信が要求され、データを処理しようとするアプリケーション３００が分散された作業を処理する過程にはネットワーク通信が不要になるため、分散プログラミング過程においてネットワークにかかる負荷を減らすことができるという長所を有する。
【００４１】
この際、特定のアプリケーション３００が二つ以上の仮想ノードに対してルックアップすることができる場合、どの仮想ノードが優先されるべきかについては多様な基準を適用してもよい。例えば、複数の仮想ノードを順に又は任意にルックアップしてもよく、最も大容量のデータが保存された仮想ノードを優先してルックアップすることを想定してもよい。
【００４２】
また、前記のような局所性の確保は、データのルックアップ過程だけでなく、データの保存過程に用いてもよい。例えば、作業を分散させるアプリケーション３００が自己に許容された特定領域にのみデータを保存し、分散された作業を処理する場合、任意の仮想ノードからデータをルックアップして処理する方式としてもよい。
【００４３】
以下、仮想空間を用いて作成される実際の分散プログラミングコードの例を本発明の一実施例によって説明し、本発明をより具体的に説明する。
【００４４】
１．クライアントサーバモデル
クライアントサーバモデル（ｃｌｉｅｎｔ  ｓｅｒｖｅｒ  ｍｏｄｅｌ）は、分散環境のための代表的なネットワークプログラミングモデルである。本発明の一実施例におけるクライアントサーバモデルは、一つの仮想空間を割り当てられ、互いに異なるキー（ｋｅｙ）に対して書き込み／取り出し（ｗｒｉｔｅ／ｔａｋｅ）関数を用いることにより容易に実現されてもよい。
【００４５】
表１に、本発明の一実施例におけるクライアントサーバモデルの実際のインプリメンテーションコード（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  ｃｏｄｅ）を例示的に示す。
【００４６】
クライアントサーバモデルの分散プログラムコードの例
【００４７】
【表１】
0005646511.tif 000002
【００４８】
表１のプログラムコードを見ると、ネットワーク関連イシュー（ｎｅｔｗｏｒｋ  ｒｅｌａｔｅｄ  ｉｓｓｕｅ）（ｓｏｃｋｅｔ、ｔｈｒｅａｄ、ｐｒｏｃｅｓｓ、ｓｉｇｎａｌ、ｐｉｐｅなど）を、分散スペースクラス（ｄｉｓｔｒｉｂｕｔｅｄ  ｓｐａｃｅ  ｃｌａｓｓ）（前記コードによると「Ｃｏｏｒｄ」クラス）に隠し、ユーザが、書き込みメソッド（ｗｒｉｔｅ  ｍｅｔｈｏｄ）又は取り出しメソッド（ｔａｋｅ  ｍｅｔｈｏｄ）などを用いて分散スペースにアクセスできるようにすることで、ユーザが自己の開発目的と意図のみに集中できるようにトランスペアレント（ｔｒａｎｓｐａｒｅｎｔ）な分散環境を支援する。従って、ユーザはクライアントサーバモデルを開発するために別途のネットワーク関連プログラミングについて熟知する必要がなくなるという長所がある。
【００４９】
２．マスターワーカモデル
マスターワーカモデル（ｍａｓｔｅｒ  ｗｏｒｋｅｒ  ｍｏｄｅｌ）は、分散環境においてロードバランス（ｌｏａｄ  ｂａｌａｎｃｅ）を維持する並行処理（ｐａｒａｌｌｅｌ  ｐｒｏｃｅｓｓｉｎｇ）を支援するために有用に活用されてもよい。従って、分散環境において並行処理を行うためにマスターワーカモデルが有する意味は非常に大きい。
【００５０】
図３及び図４は、本発明の一実施例における二つの方式のマスターワーカモデルを示している。
【００５１】
図３又は図４を参照すると、本発明の一実施例におけるマスターワーカモデルは大きく分けて二つの方式で実行されてもよいことが分かる。一つは、図３に示すように、マスターとワーカとの間で同一のキー（ｋｅｙ）を用いて書き込み／取り出し（ｗｒｉｔｅ／ｔａｋｅ）作業を行うことにより作業を割り当てる方式であり、もう一つは、図４に示すように、マスターが様々なキー（ｋｅｙ）を用いて書き込み（ｗｒｉｔｅ）作業を行い、ワーカは自己に割り当てられた分散スペース領域のキー（ｋｅｙ）に関してのみ取り出し（ｔａｋｅ）作業を行う方式である。前者の場合、ワーカはマスターの作業を競争的に割り当てられて処理し、後者の場合、マスターが作業を均等に分散させ、ワーカは自己に割り当てられた作業のみを局所性を確保しながら処理する。
【００５２】
表２に、本発明の一実施例におけるマスターワーカモデルの実際のインプリメンテーションコードを例示的に示す。
【００５３】
マスターワーカモデルの分散プログラムコードの例
【００５４】
【表２】
0005646511.tif 000003
【００５５】
表２のプログラムコードを見ると、マスターとワーカが“ｊｏｂ”という共通のキー（ｋｅｙ）を用いて書き込み／取り出し（ｗｒｉｔｅ／ｔａｋｅ）作業を行うことにより作業が割り当てられることを確認することができる。前記のようなマスターワーカモデルの長所は、マスターはどのワーカがどこに位置しており、ワーカの個数はいくつかを認識する必要がないということである。マスターはただ自己が解決しようとする作業を分散スペースに入力するだけで十分であり、ワーカは作業が割り当てられるまで待機し、割り当てられた作業を行えばよい。
【００５６】
本発明の一実施例によると、前記のようなマスターワーカモデルにスケジューラの機能を追加してもよい。スケジューラは、作業の待ち時間（ｑｕｅｕｉｎｇ  ｔｉｍｅ）とプロセシングタイム（ｐｒｏｃｅｓｓｉｎｇ  ｔｉｍｅ）をモニタリングしながらワーカの個数を動的に調節してもよい。即ち、処理する作業が増加したり作業を行う時間が長くなったりした場合、使用可能なノード又は仮想ノードにワーカをさらに割り当てることで、全体作業の処理性能を向上させてもよい。
【００５７】
３．スキャッタギャザーモデル
スキャッタギャザーモデル（ｓｃａｔｔｅｒ‐ｇａｔｈｅｒ  ｍｏｄｅｌ）は、大容量データを分散処理する際に有用である。本発明の一実施例におけるスキャッタギャザーモデルは、データを分散してすぐデータを収集処理することができるオンザフライ（ｏｎ  ｔｈｅ  ｆｌｙ）方式を支援するため、多様な長所を有するものでもよい。これは分散環境のためのパイプライン（ｐｉｐｅｌｉｎｅ）のようなものであって、リアルタイムで大量のリクエスト（ｒｅｑｕｅｓｔ）を効率的に分散処理しなければならない場合に卓越した効果を奏する。
【００５８】
本発明の一実施例によると、スキャッタギャザーモデルは、多数のスキャッタが処理される作業を仮想空間に入力すると、多数のギャザーに仮想空間に入力されたデータが割り当てられ処理される方式であってもよい。この際、マスターワーカモデルで説明したように、ギャザーは同一のキー（ｋｅｙ）を用いて競争的に作業を割り当てられてもよく、自己の仮想空間領域に割り当てられた作業のみを処理することで局所性を確保してもよい。
【００５９】
表３に、本発明の一実施例におけるスキャッタギャザーモデルの実際のインプリメンテーションコードを例示的に示す。
【００６０】
スキャッタギャザーモデルの分散プログラムコードの例
【００６１】
【表３】
0005646511.tif 000004
【００６２】
表３のプログラムコードを見ると、スキャッタがｇｅｔ＿ｋｖ（）メソッドを用いて任意のキー（ｋｅｙ）を生成し、データを仮想空間に入力すると、ギャザーは入力されたデータのキー（ｋｅｙ）を区別せずに、自己に割り当てられた領域に入力されたデータに対して作業を行うことを確認することができる。前記のようなスキャッタギャザーモデルの長所は、スキャッタで単純に（ｋｅｙ、ｖａｌｕｅ）のペアでデータを入力すると、仮想空間にデータが均一に分散され、ギャザーは自己に割り当てられたデータのみを処理する方式により局所性が確保されるため、性能向上に役に立つという点である。それだけでなく、オンザフライ（ｏｎ  ｔｈｅ  ｆｌｙ）方式でデータを分散、収集して処理するため、分散処理の効率性が向上するという長所もある。
【００６３】
フェイルオーバー（Ｆａｉｌｕｒｅ  Ｃｏｕｎｔｅｒｍｅａｓｕｒｅ）
本発明の一実施例における分散プログラミング環境は、データレプリケーション（ｄａｔａ  ｒｅｐｌｉｃａｔｉｏｎ）方式により障害に対応するものでもよい。これは、一つのノード（ここで、「ノード」は物理ノードと仮想ノードの通称として用いられる）に保存されるデータを他のノードに重複して保存することにより、特定のノードに障害が発生した場合にも障害が発生したノードのデータを復元できるようにする方式である。
【００６４】
図５及び図６は、本発明の一実施例においてフェイルオーバー（ｆａｉｌｕｒｅ  ｃｏｕｎｔｅｒｍｅａｓｕｒｅ）が行われる場合を例示的に示す図である。前記図面では、一つのノードに存在するデータが他の二つのノードにコピーされ、合計３つのコピー（３−ｃｏｐｙ）が維持される状況を仮定した。
【００６５】
図５を参照すると、特定のアプリケーション３００から入力されたデータａがノードＤにマッピングされ保存される場合、ノードＤに保存されるデータａはノードＤの後続ノードであるノードＥ及びノードＦにコピーされ保存されてもよい。
【００６６】
一方、図６は、ノードＤに障害が発生した場合、データａにアクセスしようとするアプリケーション３００の動作を図示しているが、より具体的には、アプリケーション３００がノードＤでデータａに対するルックアップに失敗した場合、ノードＤの後続ノードであるノードＥ及びノードＦに対して順次ルックアップを行うことでデータａを取得してもよい。ノードＥでデータａに対するルックアップが成功した場合、ノードＦにおけるルックアップは省略されてもよい。
【００６７】
前記のようなｎ−ｃｏｐｙレプリケーションポリシーが仮想空間にノードが追加されたり除外されたりする場合にも維持されるようにするためには、仮想空間にノードが追加されたり削除されたりする時点でデータ交換が行われなければならない。
【００６８】
図７は、３−ｃｏｐｙレプリケーションポリシーの下でノードが追加された場合に行われるデータ交換を例示的に示す図である。図７に、ノードＡ、Ｂ、Ｃ、Ｄ、Ｅ及びＧから構成された仮想空間でノードＥとノードＧとの間にノードＦが追加された状況を仮定して示す。
【００６９】
図７に示す状況で、３−ｃｏｐｙレプリケーションポリシーを維持するためには、ノードＤ及びノードＥのデータが新たに追加されたノードＦにコピーされなければならず、既にノードＧが担当していたデータもまたノードＦにコピーされなければならない。即ち、新たに追加されたノードをスペースｉｄ（ｓｐａｃｅｉｄ）と仮定して、任意のノードｘの先行ノード及び後続ノードをそれぞれ先行オペレーション（ｘ）（ｐｒｅｄｅｃｅｓｓｏｒ（ｘ））及び後続オペレーション（ｘ）（ｓｕｃｃｅｓｓｏｒ（ｘ））と仮定すると、次のような三段階のステップが行われてもよい。
【００７０】
１．後続オペレーション（スペースｉｄ）は、スペースｉｄにスペースｉｄが担当するデータを伝達する。
２．先行オペレーション（スペースｉｄ）は、スペースｉｄにスペースｉｄがレプリケーションするデータを伝達する。
３．先行オペレーション（先行オペレーション（スペースｉｄ））はスペースｉｄにスペースｉｄがレプリケーションするデータを伝達する。
【００７１】
前記のようなプロセスは、仮想空間上で特定のノードが除外される場合にも同様に実行されてもよい。
【００７２】
他の実施例
以下では、本発明の理解を容易にするために、本発明にかかる分散プログラミング環境を用いて作業を処理する他の実施例を説明する。
【００７３】
本発明の一実施例における分散プログラミング環境は、大容量のデータをソート（ｓｏｒｔ）するためのマージソート（ｍｅｒｇｅ  ｓｏｒｔ）作業に用いられてもよい。
【００７４】
一般的に分散プログラミング環境で行われる大規模データに対するマージソート作業は、マージソートを行うデータをｎ個のノードに分配し、それぞれのノードでデータ断片（ｄａｔａ  ｆｒａｇｍｅｎｔ）に対する部分的なソートが行われた後、ソートされたｎ個のデータ断片のうち一部をソート基準に合うように併合して新しいデータ断片を生成する過程を、全てのデータ断片が一つのデータに併合されるまで繰り返し行うことにより行われる。この際、併合が繰り返される回数が増加するほど、データ断片のノード間の移動回数が増加するため、ネットワークの負荷が増加し、処理能力が低下する。
【００７５】
しかし、本発明にかかる分散プログラミング環境下では、前記のような問題点を最小化した状態でマージソートを行うことができるが、その具体的な過程は以下のとおりある。
【００７６】
まず、マージソートが行われるデータをｎ個のプロセスに分配し、それぞれのノードがソートされるデータを所定のハッシュ関数を用いて分散スペースに保存する。この際、ハッシュ関数を適切に設定する場合、保存されるデータがソート基準に基づいて分散スペース内の所定領域にマッピングされてもよい。例えば、ソートされるデータが１，０００以下の自然数で構成され、仮想空間が１０個の仮想ノードで構成される場合、ハッシュ関数がモジュラー（ｍｏｄｕｌａｒ）演算を含むようにすることで、１〜１００間のデータは仮想ノード１の領域にマッピングされ、１０１〜２００間のデータは仮想ノード２の領域にマッピングされ、９０１〜１，０００間のデータは仮想ノード１０の領域にマッピングされる。このような場合、それぞれの仮想ノードの領域に保存されたデータをソートした後、仮想ノード１の領域に保存されたデータから仮想ノード１０の領域に保存されたデータまでを順次併合することでマージソート作業を完了してもよい。このような方法による場合、既存のマージソート方式に比べてノード間のデータ送受信量が減少しネットワークの負荷を減らすことができ、繰り返しの併合過程が省略されるため、処理能力が向上する。
【００７７】
この際、注意しなければならない点は、データの特性によってデータが仮想空間に集中してマッピングされ得るという点である。例えば、前記マージソートの例においてソートされるデータがいくつかの数字のみで構成される場合、特定の仮想ノードにデータが集中するため、分散プログラミングの効率が低下する虞がある。
【００７８】
本発明の一実施例によると、仮想空間にデータを保存する前に、保存されるデータの集合体に対するサンプリング作業を通じてデータの特性を把握することにより、前記のような状況を防止してもよい。先に例示したマージソート作業を例に挙げてより詳細に説明すると、マージソートが行われるデータの一部をサンプリングし、サンプリングされたデータにハッシュ関数を適用した結果、１〜３００間の値を有するデータ数が１０パーセント程度を占めることが把握される場合、仮想ノード１の領域に１〜３００間のデータが保存されるようにハッシュ関数を調整するか、仮想ノード１が担当する仮想空間上の領域を増加させることで、一部の仮想ノードにデータが集中する現象を防止してもよい。
【００７９】
一方、本発明の一実施例における分散プログラミング環境は、レガシーコード（ｌｅｇａｃｙ  ｃｏｄｅ）を再使用するためのモデルにも適用されてもよい。より具体的には、ほとんどのソースコードは、部分的にシステムのプラットフォームに従属する特性を有するが、システムのプラットフォームがアップグレードされたり変更されたりする場合には既存のソースコードに対する変更作業が必要となる。しかし、本発明による分散プログラミング環境下では、レガシーコードによって処理されるデータを分散スペースを介して入出力することによりレガシーコードを再使用することができるという効果を奏する。より具体的には、システムのプラットフォームが変更された場合にも、分散スペースに保存されるデータの形式を一定に維持することでレガシーコードによるデータ処理結果が変更されたプラットフォーム下でも適用できるようにしてもよい。
【００８０】
以上で説明した本発明にかかる実施例は、多様なコンピューター構成要素によって実行されるプログラム命令語の形態で実現され、コンピューター読み取り可能な記録媒体に記録されてもよい。前記コンピューター読み取り可能な記録媒体は、プログラム命令語、データファイル、データ構造などを単独に、または組み合わせて含むものでもよい。前記コンピューター読み取り可能な記録媒体に記録されるプログラム命令語は、本発明のために特に設計又は構成されたものであってもよく、コンピューターソフトウェア分野の当業者に公知であり使用可能なものであってもよい。コンピューター読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤなどのような光記録媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ  ｄｉｓｋ）のような磁気−光媒体（ｍａｇｎｅｔｏ−ｏｐｔｉｃａｌ  ｍｅｄｉａ）及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのような、プログラム命令語を保存及び実行するように特に構成されたハードウェア装置が含まれる。プログラム命令語の例としては、コンパイラによって作成されるもののような機械語コードだけでなく、インタープリタなどを用いてコンピュータによって実行することができる高級言語コードも含まれる。前記ハードウェア装置は、本発明にかかる処理を行うために一つ以上のソフトウェアモジュールとして動作するように構成されてもよく、その逆も同様である。
【００８１】
以上、本発明を具体的な構成要素などのような特定の事項と限定された実施例及び図面を参照して説明したが、これは本発明の全体的な理解をより容易にするために提供されたものにすぎず、本発明は前記実施例によって限定されず、本発明が属する分野で通常の知識を有する者であれば、このような記載から多様な修正及び変形が可能である。
【００８２】
従って、本発明の趣旨は前記実施例に限定されてはならず、添付の特許請求の範囲の記載だけでなく、特許請求の範囲の記載と均等または等価的に変形された全てのものは、本発明の範疇に含まれる。
【符号の説明】
【００８３】
１００  通信網
２００  クラスタ
２００ａ〜２００ｆ  ノード
２１０〜２７０  仮想ノード
３００  アプリケーション
【図１】
0005646511.tif 000005
【図２】
0005646511.tif 000006
【図３】
0005646511.tif 000007
【図４】
0005646511.tif 000008
【図５】
0005646511.tif 000009
【図６】
0005646511.tif 000010
【図７】
0005646511.tif 000011