JP5723330B2 - 分散処理システムおよび分散処理方法 - Google Patents
分散処理システムおよび分散処理方法 Download PDFInfo
- Publication number
- JP5723330B2 JP5723330B2 JP2012172616A JP2012172616A JP5723330B2 JP 5723330 B2 JP5723330 B2 JP 5723330B2 JP 2012172616 A JP2012172616 A JP 2012172616A JP 2012172616 A JP2012172616 A JP 2012172616A JP 5723330 B2 JP5723330 B2 JP 5723330B2
- Authority
- JP
- Japan
- Prior art keywords
- processing
- servers
- server
- request
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、ネットワーク上に分散配置されるサーバをクラスタ化してデータを格納する分散データベースの技術分野、および、大規模なデータ集合から、所定の条件で所望のデータを取得する検索技術の分野に属する。
近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。
分散処理を行う際には、処理対象（管理対象）のデータを、クラスタを構成する各サーバ（以下、「クラスタメンバ」または「メンバ」とも称する）に振り分けておく必要がある。このとき、クラスタ全体での処理能力を高めるためには、各クラスタメンバが担当するデータ数（データ量）は平均化されていることが望ましい。
代表的なデータの振り分け手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「ｈａｓｈ（ｋｅｙ）」と称する）をクラスタメンバ数Ｎで割った余り、すなわち「ｈａｓｈ（ｋｅｙ） ｍｏｄ Ｎ」を番号として持つクラスタメンバにデータを振り分ける方法がある。この場合、各クラスタメンバに事前に「０」から「Ｎ−１」までの番号を割り当てていることが前提となる。このような振り分け方法を用いた場合、クラスタメンバを追加すると、Ｎの値が変化して、多くのデータについて、担当するクラスタメンバが変更になるため、担当するデータの再配置が必要になる。
そこで、クラスタメンバの追加に伴い担当するクラスタメンバが変更になるデータ数を約１／Ｎに抑える方法として、コンシステントハッシュ（Consistent Hashing）法（非特許文献１参照）を用いた振り分け手法がある。このコンシステントハッシュ法は、Amazon Dynamo（非特許文献２参照）等で用いられる。
このコンシステントハッシュ法を用いたデータ振り分け手法では、クラスタメンバとデータの双方にＩＤ（IDentifier）を割り当てる（具体的には、ハッシュ関数を用いてハッシュ値を計算する）。そして、データのＩＤ（ハッシュ値）から閉じたＩＤ空間（ハッシュ空間：コンシステントハッシュ環）を時計回りに辿った場合に最初に出合ったクラスタメンバをそのデータの担当とする。
図８に示すように、コンシステントハッシュ法では、クラスタメンバ（メンバ「１」〜「４」）とデータ（データ「Ａ」〜「Ｄ」。黒丸（●）で表示）の双方にＩＤを割り当て、データのＩＤからＩＤ空間を時計回りに辿り最初に出合ったクラスタメンバをそのデータの担当として決定する。例えば、図８においては、データ「Ａ」は、ＩＤ空間上を時計回りに辿り最初に出合ったメンバ「１」が担当となる。
このコンシステントハッシュ法等を用いた従来の分散処理システム１ａは、図９に示すように、ロードバランサＢ（Balancer：各図において「Ｂ」と表記）と、複数のディスパッチャＤ（Dispatcher：各図において「Ｄ」と表記）と、複数のプロセッサＰ（Processor：各図において「Ｐ」と表記）と、複数のストレージＳ(Storage：各図において「Ｓ」と表記）とを含んで構成される。なお、後記するように、プロセッサＰとストレージＳとで１つのサーバ３（クラスタメンバ）を構成する。
そして、ロードバランサＢが、外部装置５から入力データを取得し、ラウンドロビン等により、入力データを複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）のいずれかに振り分ける。ここで、図９においては、ロードバランサＢがディスパッチャＤ１に振り分けている。このディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）は、複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）に接続されており、ロードバランサＢから取得した入力データにコンシステントハッシュ法を適用して、その入力データの担当となるサーバ３（プロセッサＰとストレージＳの組）のうちの１つを決定し、その入力データを送信する。続いて、その入力データを処理したサーバ３から、処理結果としての出力データを、入力データを送信したディスパッチャＤ（Ｄ１）が受信し、そのディスパッチャＤ（Ｄ１）が、ロードバランサＢを経由して外部装置５に出力データを送信する。
David karger et al.,"Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"，［online］，1997，ACM，［平成24年7月17日検索］，インターネット<ＵＲＬ:http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
Giuseppe DeCandia，et al.，"Dynamo: Amazon’s Highly Available Key-value Store," SOSP’07, October 14-17, 2007, Stevenson, Washington, USA，［online］、［平成24年7月17日検索］、インターネット<ＵＲＬ:http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf>
ここで、図９に示すような分散処理システム１ａにおいて、複数のサーバ３すべてに対し一斉に処理を実行させたい場合を考える。この複数のサーバ３すべてに対し一斉に処理を実行させたい場合とは、例えば、各サーバ３内のデータに関する統計や管理情報を取得する際に行うデータクラスタへの全件検索、各サーバ３が正常に動作しているかを確認するためのサーバ正常性確認コマンド、各サーバ３に処理条件等の情報を登録するための登録系保守コマンド、処理中の緊急呼の呼数を確認するための緊急呼呼数確認コマンド等を実行させたい場合である。なお、この複数のサーバ３（クラスタメンバ）すべてに対して一斉に実行させたい処理を、以下「全サーバ処理」と称する。
このような全サーバ処理に対し、従来技術では、外部装置５から処理要求をあるディスパッチャＤが受信すると、そのディスパッチャＤがクラスタを構成するすべてのサーバ３に対し、その処理要求をする。そして、その処理要求を送信したディスパッチャＤが、各サーバ３からの処理結果を受信して集約し、すべてのサーバ３からの受信を確認した上で、外部装置５に対し集約した処理結果を送信する。
しかしながら、このような従来の処理では、処理要求を各サーバ３に配信するディスパッチャＤが、すべてのサーバ３からの処理結果の受信の有無等の状態を保持したり、処理結果が受信できなかったサーバ３がある場合のエラー時処理を行ったりする必要がある。よって、全サーバ処理を実行する際に、ディスパッチャＤの処理負荷が増大する問題がある。
このような背景に鑑みて本発明がなされたのであり、本発明は、分散処理システムを構成する複数のサーバすべてに対し一斉に処理を実行させたい場合において、ディスパッチャの処理負荷の増大を抑えることができる、分散処理システムおよび分散処理方法を提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、外部装置から受信した処理要求を、クラスタメンバを構成するサーバに振り分ける複数のディスパッチャと、前記ディスパッチャから受信した前記処理要求に基づき、自身が保存するデータについて処理を実行する複数の前記サーバと、前記サーバが実行した処理結果を受信する前記外部装置と、を備える分散処理システムであって、前記ディスパッチャが、前記外部装置から受信した前記処理要求に、前記複数のサーバすべてに対する処理の要求を示す全サーバ送信フラグが設定されているか否かを判定する第１の構文解析部と、前記第１の構文解析部が前記処理要求に前記全サーバ送信フラグが設定されていると判定した場合に、前記複数のサーバすべてに当該処理要求を配信する要求配信部と、を備え、前記複数のサーバそれぞれが、前記サーバそれぞれに割り当てられるデータの担当分と、前記サーバそれぞれの当該担当分の総和とを示す管理情報を記憶する記憶部と、前記ディスパッチャから受信した処理要求に、前記全サーバ送信フラグが設定されているか否かを判定する第２の構文解析部と、前記処理要求に示される処理を実行し処理結果を生成する要求処理部と、前記第２の構文解析部が前記処理要求に前記全サーバ送信フラグが設定されていると判定した場合に、前記管理情報を参照し、前記サーバ自身に割り当てられた前記担当分と、前記担当分の総和とを示す処理担当情報を生成する処理担当情報生成部と、前記処理結果および前記処理担当情報を含む応答メッセージを生成し、前記外部装置に送信する応答メッセージ生成部と、を備え、前記外部装置が、前記複数のサーバすべてに対し処理を要求する場合に、前記全サーバ送信フラグを設定した前記処理要求を前記複数のディスパッチャのいずれかに送信する処理要求送信部と、前記複数のサーバそれぞれから受信した前記応答メッセージから前記処理担当情報を抽出し、前記抽出した処理担当情報に含まれる前記担当分を、受信した各応答メッセージのすべてについて集計し、当該集計結果が、前記抽出した処理担当情報に含まれる前記担当分の総和と一致するか否かを判定し、所定の時間内に前記担当分の総和と一致した場合は前記複数のサーバすべてに対する処理が成功したと判定し、一致しない場合は失敗したと判定する応答メッセージ集計部と、を備えることを特徴とする分散処理システムとした。
また、請求項３に記載の発明は、外部装置から受信した処理要求を、クラスタメンバを構成するサーバに振り分ける複数のディスパッチャと、前記ディスパッチャから受信した前記処理要求に基づき、自身が保存するデータについて処理を実行する複数の前記サーバと、前記サーバが実行した処理結果を受信する前記外部装置と、を備える分散処理システムの分散処理方法であって、前記外部装置が、前記複数のサーバすべてに対し処理を要求する場合に、前記複数のサーバすべてに対する処理の要求を示す全サーバ送信フラグを設定した前記処理要求を前記複数のディスパッチャのいずれかに送信するステップを実行し、前記ディスパッチャが、前記外部装置から受信した前記処理要求に、前記全サーバ送信フラグが設定されているか否かを判定するステップと、前記処理要求に前記全サーバ送信フラグが設定されていると判定された場合に、前記複数のサーバすべてに当該処理要求を配信するステップと、を実行し、前記複数のサーバそれぞれが、前記サーバそれぞれに割り当てられるデータの担当分と、前記サーバそれぞれの当該担当分の総和とを示す管理情報を記憶する記憶部を備えており、前記ディスパッチャから受信した処理要求に、前記全サーバ送信フラグが設定されているか否かを判定するステップと、前記処理要求に示される処理を実行して処理結果を生成するステップと、前記処理要求に前記全サーバ送信フラグが設定されていると判定された場合に、前記管理情報を参照し、前記サーバ自身に割り当てられた前記担当分と、前記担当分の総和とを示す処理担当情報を生成するステップと、前記処理結果および前記処理担当情報を含む応答メッセージを生成し、前記外部装置に送信するステップと、を実行し、前記外部装置が、前記複数のサーバそれぞれから受信した前記応答メッセージから前記処理担当情報を抽出し、前記抽出した処理担当情報に含まれる前記担当分を、受信した各応答メッセージのすべてについて集計し、当該集計結果が、前記抽出した処理担当情報に含まれる前記担当分の総和と一致するか否かを判定し、所定の時間内に前記担当分の総和と一致した場合は前記複数のサーバすべてに対する処理が成功したと判定し、一致しない場合は失敗したと判定するステップを実行することを特徴とする分散処理方法とした。
このようにすることで、処理要求を送信した外部装置が、各サーバそれぞれから応答メッセージを受信し、その応答メッセージから処理担当情報を抽出して集計することにより、全サーバ処理が成功した否かを判定することができる。よって、各サーバに処理要求を配信したディスパッチャが、各サーバの処理状態等を保持する必要がないため、ディスパッチャの処理負荷の増大を抑えることができる。
請求項２に記載の発明は、前記複数のサーバそれぞれの前記応答メッセージ生成部が、前記生成した応答メッセージを、前記外部装置に替えて、前記処理要求を配信したディスパッチャに送信し、前記ディスパッチャが、前記複数のサーバそれぞれから受信した応答メッセージを集約することなく、前記外部装置に転送することを特徴とする請求項１に記載の分散処理システムとした。
このようにすることによっても、各サーバに処理要求を配信したディスパッチャが、各サーバの処理状態等を保持する必要がないため、ディスパッチャの処理負荷の増大を抑えることができる。
本発明によれば、分散処理システムを構成する複数のサーバすべてに対し一斉に処理を実行させたい場合において、ディスパッチャの処理負荷の増大を抑える、分散処理システムおよび分散処理方法を提供することができる。
次に、本発明を実施するための形態（以下、「本実施形態」という）における分散処理システム１等について説明する。
＜システム構成＞
図１は、本実施形態に係る分散処理システム１の全体構成を示す図である。
図１に示すように、分散処理システム１は、クラスタシステム２が、ネットワークを介して、外部装置５に接続されて構成される。そして、クラスタシステム２は、外部装置５からの処理要求データを受け取り、クラスタシステム２内でデータの全件検索や、クラスタシステム２を構成するサーバ３（後記する図２参照）の正常性確認等の全サーバ処理を実行し、その処理結果を含む応答データを、外部装置５に送信する。
図１は、本実施形態に係る分散処理システム１の全体構成を示す図である。
図１に示すように、分散処理システム１は、クラスタシステム２が、ネットワークを介して、外部装置５に接続されて構成される。そして、クラスタシステム２は、外部装置５からの処理要求データを受け取り、クラスタシステム２内でデータの全件検索や、クラスタシステム２を構成するサーバ３（後記する図２参照）の正常性確認等の全サーバ処理を実行し、その処理結果を含む応答データを、外部装置５に送信する。
図２は、本実施形態に係る分散処理システム１の内部構成と処理概要を説明するための図である。
図２に示すように、本分散処理システム１は、外部装置５とクラスタシステム２とを備える。そして、クラスタシステム２は、ロードバランサＢと、複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）と、複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）と、複数のストレージＳ（Ｓ１，Ｓ２，Ｓ３）とを含んで構成される。なお、本実施形態においては、このプロセッサＰとストレージＳとの組で、１つのサーバ３を構成するものとして説明する。
図２に示すように、本分散処理システム１は、外部装置５とクラスタシステム２とを備える。そして、クラスタシステム２は、ロードバランサＢと、複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）と、複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）と、複数のストレージＳ（Ｓ１，Ｓ２，Ｓ３）とを含んで構成される。なお、本実施形態においては、このプロセッサＰとストレージＳとの組で、１つのサーバ３を構成するものとして説明する。
外部装置５は、各サーバ３（クラスタメンバ）に対する、データ検索や登録、変更のための入力データを、クラスタシステム２のロードバランサＢに送信する処理を行うとともに、前記したような全サーバ処理の要求を送信する際には、その処理要求に「全サーバ送信フラグ」を設定してクラスタシステム２のロードバランサＢに送信する。
ロードバランサＢは、外部装置５から処理要求を取得し、ラウンドロビン等により、取得した処理要求を複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）のいずれかに振り分ける。
各ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）は、複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）と接続されており、ロードバランサＢから取得した処理要求を、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）のいずれかに振り分ける。このディスパッチャＤは、処理要求を解析し、「全サーバ送信フラグ」が設定されていなければ、コンシステントハッシュを適用してハッシュ関数により、データの格納先であるサーバ３（プロセッサＰとストレージＳとの組）の１つを決定し、その処理要求を送信する。また、処理要求を送信したサーバ３から処理結果を受信した場合には、そのディスパッチャＤは、ロードバランサＢを介して外部装置５にその処理結果を送信する。
なお、本実施形態においては、ＩＤ空間（コンシステントハッシュ環）におけるサーバおよびデータのＩＤ（ハッシュ値）の配置の偏りを解消するため、１つのクラスタメンバから複数のＩＤ（ハッシュ値）を算出し、ＩＤ空間（コンシステントハッシュ環）上に仮想サーバを配置するものとする。これにより、各サーバ３（クラスタメンバ）の担当するデータ数を均等化し、各サーバ３の負荷を均等にすることができる。
なお、本実施形態においては、ＩＤ空間（コンシステントハッシュ環）におけるサーバおよびデータのＩＤ（ハッシュ値）の配置の偏りを解消するため、１つのクラスタメンバから複数のＩＤ（ハッシュ値）を算出し、ＩＤ空間（コンシステントハッシュ環）上に仮想サーバを配置するものとする。これにより、各サーバ３（クラスタメンバ）の担当するデータ数を均等化し、各サーバ３の負荷を均等にすることができる。
また、ディスパッチャＤは、処理要求を解析し、「全サーバ送信フラグ」が設定されている場合には、全サーバ処理を実行するため、クラスタシステム２内のすべてのサーバ３に受信した処理要求を配信する。
なお、ディスパッチャＤの詳細な構成と処理については、後記する。
なお、ディスパッチャＤの詳細な構成と処理については、後記する。
プロセッサＰは、複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）と自身が制御するストレージＳとに接続されており、いずれかのディスパッチャＤから処理要求を受信し、その処理要求を解析し、ストレージＳに新規データを保存したり、既存データを更新したり、データの検索処理をしたり、サーバ正常性確認コマンドや保守コマンド、緊急呼呼数確認コマンド等を実行する。
また、プロセッサＰは、受信した処理要求に「全サーバ送信フラグ」が設定されている場合には、処理結果を、処理要求を送信してきたディスパッチャＤではなく、外部装置５に直接送信する。このときプロセッサＰは、そのサーバ３自身に割り当てられたデータの担当分として、ＩＤ空間上で担当する領域を示す情報（後記する「処理担当情報」）を付した処理結果を、応答メッセージとして外部装置５に送信する。
また、プロセッサＰは、受信した処理要求に「全サーバ送信フラグ」が設定されている場合には、処理結果を、処理要求を送信してきたディスパッチャＤではなく、外部装置５に直接送信する。このときプロセッサＰは、そのサーバ３自身に割り当てられたデータの担当分として、ＩＤ空間上で担当する領域を示す情報（後記する「処理担当情報」）を付した処理結果を、応答メッセージとして外部装置５に送信する。
ストレージＳは、データを保存する記憶手段であり、プロセッサＰにより、ストレージＳに保存されるデータの登録、更新、検索等が制御される。
なお、ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）、ストレージＳ（Ｓ１，Ｓ２，Ｓ３）それぞれは、図２に図示した３つの装置に限定されず、複数の装置であればよい。
＜概要＞
次に、図２を参照して、本実施形態に係る分散処理システム１が行う処理の概要について説明する。
まず、外部装置５は、「全サーバ送信フラグ」を設定した処理要求をロードバランサＢに送信する（ステップＳ１）。
次に、図２を参照して、本実施形態に係る分散処理システム１が行う処理の概要について説明する。
まず、外部装置５は、「全サーバ送信フラグ」を設定した処理要求をロードバランサＢに送信する（ステップＳ１）。
ロードバランサＢは、外部装置５から処理要求を取得すると、ラウンドロビン等によりその処理要求を複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）のいずれかに振り分ける（ステップＳ２）。ここでは、ロードバランサＢにより、ディスパッチャＤ１が振り分け先として決定され、ディスパッチャＤ１に処理要求が送信されたものとする。
次に、ディスパッチャＤ（Ｄ１）は、処理要求を解析し、「全サーバ送信フラグ」が設定されていることから、クラスタシステム２内のすべてのサーバ３、具体的には、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）に対し、その処理要求を送信する（ステップＳ３）。
各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、処理要求を受信すると、その処理要求に示される処理を実行し処理結果を取得する。また、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、その処理要求を受信した際に、「全サーバ送信フラグ」が設定されているか否かを判定する。そして、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、「全サーバ送信フラグ」が設定されている場合には、処理結果にサーバ３自身がＩＤ空間上で担当する領域を示す情報（「処理担当情報」）を付して、応答メッセージを生成する（ステップＳ４）。例えば、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、全ＩＤ空間分をｂｉｔ列として設定し、そのｂｉｔ列の中で、自身の仮想サーバが担当するＩＤ空間（コンシステントハッシュ環）の領域に「１」を設定した処理担当情報を処理結果に付した応答メッセージを生成する。
次に、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、生成した応答メッセージを、ネットワークを介して直接外部装置５に送信する（ステップＳ５）。
外部装置５は、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）それぞれから処理要求に対する応答メッセージを受信する。そして、外部装置５は、受信した応答メッセージに付された処理担当情報を集計し、全ＩＤ空間分のｂｉｔ列がすべて「１」となった場合に、全サーバ処理が成功したと判定し、全ＩＤ空間分のｂｉｔ列のいずれかが「１」とならなかった場合に、全サーバ処理が失敗したと判定する（ステップＳ６）。
このようにすることで、本実施形態に係る分散処理システム１および分散処理方法によれば、外部装置５がクラスタシステム２内のサーバ３（クラスタメンバ）の構成を知らなくても、分散処理システム１を構成する複数のサーバ３すべてに対し処理を実行させることができる。そして、外部装置５は、処理担当情報を集計することにより、全サーバ処理が成功した否かを判定することができる。さらに、本分散処理システム１および分散処理方法によれば、各サーバ３に処理要求を配信したディスパッチャＤが、全サーバ処理の状態等を保持する必要がないため、ディスパッチャＤの処理負荷の増大を抑えることができる。
＜各装置の構成＞
以下、本実施形態に係る分散処理システム１を構成する各装置の構成例について、具体的に説明する。
以下、本実施形態に係る分散処理システム１を構成する各装置の構成例について、具体的に説明する。
≪ロードバランサＢ≫
ロードバランサＢは、ネットワークを介して接続される外部装置５からの処理要求等を受け付け、ラウンドロビン等により、その処理要求等を、クラスタシステム２内の複数のディスパッチャＤのいずれかに振り分ける装置である。そして、このロードバランサＢは、制御部、入出力部、メモリ部および記憶部（いずれも不図示）を含んで構成される。
ロードバランサＢは、ネットワークを介して接続される外部装置５からの処理要求等を受け付け、ラウンドロビン等により、その処理要求等を、クラスタシステム２内の複数のディスパッチャＤのいずれかに振り分ける装置である。そして、このロードバランサＢは、制御部、入出力部、メモリ部および記憶部（いずれも不図示）を含んで構成される。
≪ディスパッチャＤ≫
次に、ディスパッチャＤの構成例について説明する。図３は、本実施形態に係るディスパッチャＤの構成例を示す機能ブロック図である。
ディスパッチャＤは、ロードバランサＢおよび複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）と通信可能に接続され、ロードバランサＢから取得した処理要求を、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）に振り分ける装置であり、図３に示すように、制御部１１０と、入出力部１２０と、メモリ部１３０と、記憶部１４０とを含んで構成される。
次に、ディスパッチャＤの構成例について説明する。図３は、本実施形態に係るディスパッチャＤの構成例を示す機能ブロック図である。
ディスパッチャＤは、ロードバランサＢおよび複数のプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）と通信可能に接続され、ロードバランサＢから取得した処理要求を、プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）に振り分ける装置であり、図３に示すように、制御部１１０と、入出力部１２０と、メモリ部１３０と、記憶部１４０とを含んで構成される。
入出力部１２０は、ロードバランサＢや、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）との間の情報の入出力を行う。例えば、入出力部１２０は、ロードバランサＢが送信した処理要求を受信し、各プロセッサＰに対し、その処理要求の送信を行う。また、入出力部１２０は、ストレージＳに保存されるデータ等の検索結果や、ストレージＳへの登録、変更等の処理結果を出力データとしてプロセッサＰから受信し、ロードバランサＢに対して送信する等の処理を行う。
また、この入出力部１２０は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
また、この入出力部１２０は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
制御部１１０は、ディスパッチャＤ全体の制御を司り、情報受信部１１１と、構文解析部１１２（第１の構文解析部）と、振り分け処理部１１３と、要求配信部１１４と、情報送信部１１５とを含んで構成される。なお、この制御部１１０は、例えば、記憶部１４０に格納されたプログラムをＣＰＵ（Central Processing Unit）がメモリ部１３０であるＲＡＭ（Random Access Memory）に展開し実行することで実現される。
情報受信部１１１は、入出力部１２０を介して、ロードバランサＢからの処理要求や、プロセッサＰからの出力データを取得する。
構文解析部１１２（第１の構文解析部）は、情報受信部１１１から処理要求を受け取り、その処理要求を解析し、「全サーバ送信フラグ」が設定されているか否かを判定する。そして、構文解析部１１２は、「全サーバ送信フラグ」が設定されていないと判定した場合には、その処理要求を振り分け処理部１１３に引き渡す。一方、構文解析部１１２は、「全サーバ送信フラグ」が設定されていると判定した場合には、その処理要求を要求配信部１１４に引き渡す。
振り分け処理部１１３は、構文解析部１１２から、「全サーバ送信フラグ」が設定されていない処理要求を受け取る。振り分け処理部１１３は、予め設定されたハッシュ関数を用いて、処理要求に示される入力データのハッシュ値を計算する。そして、振り分け処理部１１３は、計算したハッシュ値に基づき、記憶部１４０に記憶されたＩＤ空間管理情報１００（後記する図４）を参照し、振り分け先となるＩＤ空間（コンシステントハッシュ環）上の仮想ノードを決定する。続いて、振り分け処理部１１３は、決定した仮想ノードの基となるサーバ３（プロセッサＰとストレージＳとの組）を、振り分け先のサーバ３として選択する。振り分け処理部１１３は、その選択したサーバ３に対して、処理要求を、情報送信部１１５を介して送信する。
また、振り分け処理部１１３は、各サーバ３から処理要求に対する処理結果である出力データを受信すると、ロードバランサＢにその処理結果を送信する。
また、振り分け処理部１１３は、各サーバ３から処理要求に対する処理結果である出力データを受信すると、ロードバランサＢにその処理結果を送信する。
図４は、本実施形態に係るＩＤ空間管理情報１００（管理情報）のデータ構成の一例を示す図である。
図４に示すように、ＩＤ空間管理情報１００は、仮想ノードＩＤ１０１、物理ノードＩＤ１０２、ハッシュ値１０３のデータ項目を含んで構成される。
図４に示すように、ＩＤ空間管理情報１００は、仮想ノードＩＤ１０１、物理ノードＩＤ１０２、ハッシュ値１０３のデータ項目を含んで構成される。
ここで、仮想ノードＩＤ１０１は、本分散処理システム１内において仮想ノードを特定するための固有な番号である。例えば、図４に示す、仮想ノードＩＤ１０１の「２−７」は、仮想ノードの基となる物理ノードのＩＤ（物理ノードＩＤ１０２）と、当該物理ノードにおける仮想ノードの固有な番号のうちの１つ（ここでは、「７」番）との組により構成される。
物理ノードＩＤ１０２は、処理要求に示される入力データの振り分け先となるサーバ３（プロセッサＰとストレージＳとの組）を、本分散処理システム１内において特定するための固有な番号である。例えば、図４に示すように、物理ノードＩＤ１０２として「２」が設定される。
なお、この仮想ノードＩＤ１０１および物理ノードＩＤ１０２は、本分散処理システム１内において、一意に特定されるＩＤであればよく、図４に示した表記方法に限定されるものではない。
なお、この仮想ノードＩＤ１０１および物理ノードＩＤ１０２は、本分散処理システム１内において、一意に特定されるＩＤであればよく、図４に示した表記方法に限定されるものではない。
ハッシュ値１０３は、ＩＤ空間（コンシステントハッシュ環）において、仮想ノードが担当する領域を特定するためのものであり、例えば、「０」から順に「９９９９」までのいずれかの値が格納される。
例えば、図４に示す、第１行目のハッシュ値１０３が「５６」の場合は、仮想ノードＩＤ１０１が「２−７」の仮想ノードのＩＤ空間（コンシステントハッシュ環）における入力データの担当領域が、「０」〜「５６」であることを示す。また、第２行目のハッシュ値１０３が「１７２」の場合は、仮想ノードＩＤ１０１が「５−９６」の仮想ノードのＩＤ空間（コンシステントハッシュ環）における入力データの担当領域が、１つ前の行のハッシュ値１０３の値に「１」をプラスした「５７」〜「１７２」であることを示す。
例えば、図４に示す、第１行目のハッシュ値１０３が「５６」の場合は、仮想ノードＩＤ１０１が「２−７」の仮想ノードのＩＤ空間（コンシステントハッシュ環）における入力データの担当領域が、「０」〜「５６」であることを示す。また、第２行目のハッシュ値１０３が「１７２」の場合は、仮想ノードＩＤ１０１が「５−９６」の仮想ノードのＩＤ空間（コンシステントハッシュ環）における入力データの担当領域が、１つ前の行のハッシュ値１０３の値に「１」をプラスした「５７」〜「１７２」であることを示す。
各ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）および各サーバ３（具体的には、ストレージＳ）は、このＩＤ空間管理情報１００の各データ項目である、仮想ノードＩＤ１０１、物理ノードＩＤ１０２およびハッシュ値１０３について、すべて共通の値が格納されたＩＤ空間管理情報１００を備えている。
図３に戻り、要求配信部１１４は、構文解析部１１２から、「全サーバ送信フラグ」が設定されている処理要求を受け取ると、その処理要求をクラスタシステム２内のすべてのプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）それぞれに配信する。
情報送信部１１５は、振り分け処理部１１３が決定した振り分け先となるプロセッサＰに対して処理要求を送信したり、要求配信部１１４の制御によりすべてのプロセッサＰに対して処理要求を送信したりする。また、情報送信部１１５は、プロセッサＰから受信した処理結果等の出力データを、ロードバランサＢに送信する等の制御を行う。
メモリ部１３０は、ＲＡＭ等の一次記憶装置からなり、制御部１１０によるデータ処理に必要な情報を一時的に記憶している。
記憶部１４０は、ハードディスクやフラッシュメモリ等の記憶装置からなり、前記したＩＤ空間管理情報１００（図４参照：管理情報）を記憶する。また、記憶部１４０は、ロードバランサＢや、自身以外の各ディスパッチャＤ、各プロセッサＰのアドレス（ＩＰアドレス）等を記憶する。
≪サーバ≫
次に、サーバ３の構成例について説明する。図５は、本実施形態に係るサーバ３の構成例を示す機能ブロック図である。
サーバ３は、複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）および外部装置５と通信可能に接続され、制御部３１０と、入出力部３２０と、メモリ部３３０と、記憶部３４０とを含んで構成される。なお、このサーバ３の構成のうち、制御部３１０、入出力部３２０およびメモリ部３３０がプロセッサＰ（図２参照）に相当し、記憶部３４０がストレージＳ（図２参照）に相当する。
次に、サーバ３の構成例について説明する。図５は、本実施形態に係るサーバ３の構成例を示す機能ブロック図である。
サーバ３は、複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）および外部装置５と通信可能に接続され、制御部３１０と、入出力部３２０と、メモリ部３３０と、記憶部３４０とを含んで構成される。なお、このサーバ３の構成のうち、制御部３１０、入出力部３２０およびメモリ部３３０がプロセッサＰ（図２参照）に相当し、記憶部３４０がストレージＳ（図２参照）に相当する。
入出力部３２０は、各ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）や外部装置５との間の情報の入出力を行う。例えば、入出力部３２０は、ディスパッチャＤが送信した処理要求を受信し、その処理要求に基づく処理をした結果（処理結果）を出力データとして、そのディスパッチャＤに送信する。また、入出力部３２０は、その処理要求に、「全サーバ送信フラグ」が付されている場合には、後記する応答メッセージ生成部３１５が生成した応答メッセージを外部装置５に送信する。
また、この入出力部３２０は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
また、この入出力部３２０は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
制御部３１０は、サーバ３全体の制御を司り、情報受信部３１１と、構文解析部３１２（第２の構文解析部）と、要求処理部３１３と、処理担当情報生成部３１４と、応答メッセージ生成部３１５と、情報送信部３１６とを含んで構成される。なお、この制御部３１０は、例えば、記憶部３４０に格納されたプログラムをＣＰＵがメモリ部３３０であるＲＡＭに展開し実行することで実現される。
情報受信部３１１は、入出力部３２０を介して、各ディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）からの処理要求等を取得する。
構文解析部３１２（第２の構文解析部）は、情報受信部３１１から処理要求を受け取り、その処理要求を解析し、「全サーバ送信フラグ」が設定されているか否かを判定する。そして、構文解析部３１２は、「全サーバ送信フラグ」が設定されていないと判定した場合には、その処理要求を要求処理部３１３に引き渡す。一方、構文解析部３１２は、「全サーバ送信フラグ」が設定されていると判定した場合には、その処理要求を要求処理部３１３に引き渡すと共に、処理担当情報生成部３１４を起動させる。
要求処理部３１３は、「全サーバ送信フラグ」が設定されていない処理要求を受け取ると、その処理要求に従い、記憶部３４０（ストレージＳ）に対し、新規データを保存、既存データを更新、データの検索等の処理を実行する。そして、要求処理部３１３は、その処理結果を、情報送信部３１６を介して、処理要求を送信してきたディスパッチャＤに送信する。
また、要求処理部３１３は、「全サーバ送信フラグ」が設定されている処理要求を受け取ると、その処理要求に従い、サーバ３自身の記憶部３４０（ストレージＳ）に記憶したデータへの全件検索、サーバ正常性確認コマンド、処理条件等の情報を登録するための登録系保守コマンド、緊急呼呼数確認コマンド等の処理（全サーバ処理のうちの当該サーバ３の処理）を実行する。そして、要求処理部３１３は、その処理結果を、応答メッセージ生成部３１５に引き渡す。
処理担当情報生成部３１４は、構文解析部３１２が受信した処理要求に「全サーバ送信フラグ」が設定されていると判定したことを契機に起動されると、記憶部３４０（ストレージＳ）に記憶されたＩＤ空間管理情報１００（管理情報）を参照し、そのサーバ３自身に割り当てられたデータの担当分として、ＩＤ空間（コンシステントハッシュ環）において担当する領域を示す処理担当情報を生成する。
この処理担当情報は、例えば、サーバそれぞれの担当分の総和である全ＩＤ空間をｂｉｔ列として設定し、そのｂｉｔ列の中で、そのサーバ３自身が担当するＩＤ（ハッシュ値）に対応するｂｉｔの位置に「１」が設定される。具体的には、ＩＤ空間（コンシステントハッシュ環）において、ハッシュ値が「０」〜「９９９９」まで設定されている場合に、当該処理担当情報生成部３１４は、「０」〜「９９９９」のハッシュ値に１対１で対応するｂｉｔ列を生成し、ＩＤ空間管理情報１００を参照して、サーバ３自身の仮想ノードが担当するＩＤ空間（コンシステントハッシュ環）の領域（すなわち、サーバ３自身の仮想ノードの行の１つ前の行のハッシュ値１０３の値に「１」をプラスした値から、サーバ３自身の仮想ノードのハッシュ値１０３の値までの領域）に対応するｂｉｔ列の位置に「１」を設定して、処理担当情報を生成する。そして、処理担当情報生成部３１４は、生成した処理担当情報を、応答メッセージ生成部３１５に引き渡す。
この処理担当情報は、例えば、サーバそれぞれの担当分の総和である全ＩＤ空間をｂｉｔ列として設定し、そのｂｉｔ列の中で、そのサーバ３自身が担当するＩＤ（ハッシュ値）に対応するｂｉｔの位置に「１」が設定される。具体的には、ＩＤ空間（コンシステントハッシュ環）において、ハッシュ値が「０」〜「９９９９」まで設定されている場合に、当該処理担当情報生成部３１４は、「０」〜「９９９９」のハッシュ値に１対１で対応するｂｉｔ列を生成し、ＩＤ空間管理情報１００を参照して、サーバ３自身の仮想ノードが担当するＩＤ空間（コンシステントハッシュ環）の領域（すなわち、サーバ３自身の仮想ノードの行の１つ前の行のハッシュ値１０３の値に「１」をプラスした値から、サーバ３自身の仮想ノードのハッシュ値１０３の値までの領域）に対応するｂｉｔ列の位置に「１」を設定して、処理担当情報を生成する。そして、処理担当情報生成部３１４は、生成した処理担当情報を、応答メッセージ生成部３１５に引き渡す。
応答メッセージ生成部３１５は、要求処理部３１３から処理結果を受け取り、処理担当情報生成部３１４から処理担当情報を受け取る。応答メッセージ生成部３１５は、受け取った処理結果と処理担当情報とを含む応答メッセージを生成する。そして、応答メッセージ生成部３１５は、受信した処理要求に示される外部装置５のアドレス情報（ＩＰアドレス等）に基づき、その外部装置５に対し応答メッセージを送信する。
情報送信部３１６は、処理要求を送信してきたディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）に対し要求処理部３１３が処理した処理結果を送信したり、応答メッセージ生成部３１５が生成した応答メッセージを外部装置５に送信したりする。
メモリ部３３０は、ＲＡＭ等の一次記憶装置からなり、制御部３１０によるデータ処理に必要な情報を一時的に記憶している。
記憶部３４０（ストレージＳ）は、ハードディスクやフラッシュメモリ等の記憶装置からなり、前記したＩＤ空間管理情報１００（図４参照：管理情報）等を記憶する。
≪外部装置≫
次に、外部装置５の構成例について説明する。図６は、本実施形態に係る外部装置５の構成例を示す機能ブロック図である。なお、図６においては、制御部、入出力部、メモリ部および記憶部の図示を省略し、外部装置５の特徴となる機能を示す制御部内の処理要求送信部５１１と応答メッセージ集計部５１２とを記載している。
次に、外部装置５の構成例について説明する。図６は、本実施形態に係る外部装置５の構成例を示す機能ブロック図である。なお、図６においては、制御部、入出力部、メモリ部および記憶部の図示を省略し、外部装置５の特徴となる機能を示す制御部内の処理要求送信部５１１と応答メッセージ集計部５１２とを記載している。
処理要求送信部５１１は、クラスタシステム２（ロードバランサＢ）に処理要求を送信する。そして、この処理要求送信部５１１は、その処理要求が、クラスタシステム２内のすべてのサーバ３（クラスタメンバ）に対する、全件検索、サーバ正常性確認コマンド、登録系保守コマンド、緊急呼呼数確認コマンド等の処理（全サーバ処理）である場合に、「全サーバ送信フラグ」を設定した処理要求をクラスタシステム２内のロードバランサＢに送信する。
応答メッセージ集計部５１２は、クラスタシステム２内の各サーバ３（プロセッサＰ（Ｐ１，Ｐ２，Ｐ３））それぞれから応答メッセージを受信する。そして、応答メッセージ集計部５１２は、その応答メッセージに含まれる処理担当情報を抽出し、各サーバ３からの処理担当情報（当該サーバの担当分）を集計して、その集計結果が、すべてのサーバ３の担当分の総和と一致するか否かで、すべてのサーバ３から応答メッセージを受信したか否かを判定する。
応答メッセージ集計部５１２によるこの判定は、例えば、処理担当情報としてそのサーバ３の担当分が示されたｂｉｔ列を、各サーバ３から受信した応答メッセージのすべてについてｏｒ演算し、ＩＤ空間（コンシステントハッシュ環）の領域（担当分の総和）に対応するｂｉｔ列がすべて「１」であるときに、すべてのサーバ３からの応答メッセージを受信した、つまり、全サーバ処理が成功したと判定する。一方、応答メッセージ集計部５１２は、所定の時間内に、ｂｉｔ列がすべて「１」とならなかった場合に、全サーバ処理が失敗したと判定する。
なお、この所定の時間内とは、例えば、外部装置５の処理要求送信部５１１が、全サーバ処理の処理要求を送信してから所定の時間内であってもよいし、全サーバ処理の処理要求を送信後、最初または直前の応答メッセージを受信してから所定の時間内であってもよい。
応答メッセージ集計部５１２によるこの判定は、例えば、処理担当情報としてそのサーバ３の担当分が示されたｂｉｔ列を、各サーバ３から受信した応答メッセージのすべてについてｏｒ演算し、ＩＤ空間（コンシステントハッシュ環）の領域（担当分の総和）に対応するｂｉｔ列がすべて「１」であるときに、すべてのサーバ３からの応答メッセージを受信した、つまり、全サーバ処理が成功したと判定する。一方、応答メッセージ集計部５１２は、所定の時間内に、ｂｉｔ列がすべて「１」とならなかった場合に、全サーバ処理が失敗したと判定する。
なお、この所定の時間内とは、例えば、外部装置５の処理要求送信部５１１が、全サーバ処理の処理要求を送信してから所定の時間内であってもよいし、全サーバ処理の処理要求を送信後、最初または直前の応答メッセージを受信してから所定の時間内であってもよい。
＜分散処理システムの処理の流れ＞
次に、本実施形態に係る分散処理システム１において、全サーバ処理を実行する場合の処理の流れについて説明する。
次に、本実施形態に係る分散処理システム１において、全サーバ処理を実行する場合の処理の流れについて説明する。
図７は、本実施形態に係る分散処理システム１において、全サーバ処理を実行する場合の処理の流れを示すシーケンス図である。
まず、外部装置５の処理要求送信部５１１は、全サーバ処理の実行を要求する処理要求に「全サーバ送信フラグ」を設定し、その処理要求をクラスタシステム２のロードバランサＢに送信する（ステップＳ１０）。
ロードバランサＢは、外部装置５から処理要求を取得すると、ラウンドロビン等によりその処理要求を複数のディスパッチャＤ（Ｄ１，Ｄ２，Ｄ３）のいずれかに振り分ける（ステップＳ１１）。ここでは、ロードバランサＢにより、ディスパッチャＤ１が振り分け先として決定され、ディスパッチャＤ１に処理要求が送信されたものとする。
処理要求を受信するとディスパッチャＤ（Ｄ１）の構文解析部１１２は、その処理要求を解析し、「全サーバ送信フラグ」が設定されているか否かを判定する。ここで、ディスパッチャＤ（Ｄ１）の構文解析部１１２は、受信した処理要求に「全サーバ送信フラグ」が設定されていると判定する（ステップＳ１２）。
次に、ディスパッチャＤ（Ｄ１）の要求配信部１１４は、その処理要求を、クラスタシステム２内のすべてのサーバ３（＃１，＃２，＃３）、具体的には、すべてのプロセッサＰ（Ｐ１，Ｐ２，Ｐ３）に送信する（ステップＳ１３）。
処理要求を受信すると各サーバ３（＃１，＃２，＃３）の構文解析部３１２は、その処理要求を解析し、「全サーバ送信フラグ」が設定されているか否かを判定する。ここで、各サーバ３（＃１，＃２，＃３）の構文解析部３１２は、受信した処理要求に「全サーバ送信フラグ」が設定されていると判定する（ステップＳ１４）。また、構文解析部３１２は、処理担当情報生成部３１４を起動させる。
続いて、各サーバ３（＃１，＃２，＃３）の要求処理部３１３が、その処理要求に示される処理を実行し処理結果を取得する（ステップＳ１５）。
そして、各サーバ３（＃１，＃２，＃３）の処理担当情報生成部３１４が、記憶部３４０（ストレージＳ）に記憶されたＩＤ空間管理情報１００（図４）を参照し、そのサーバ３自身がＩＤ空間（コンシステントハッシュ環）において担当する領域を示す担当処理情報を生成する（ステップＳ１６）。ここで、処理担当情報生成部３１４は、例えば、全ＩＤ空間をｂｉｔ列として設定し、そのｂｉｔ列の中で、そのサーバ３自身が担当するＩＤ（ハッシュ値）に対応するｂｉｔの位置に「１」を設定した処理担当情報を生成する。
次に、各サーバ３（＃１，＃２，＃３）の応答メッセージ生成部３１５は、要求処理部３１３から処理結果を受け取り、処理担当情報生成部３１４から処理担当情報を受け取って、その処理結果と処理担当情報とを含む応答メッセージを生成する。そして、応答メッセージ生成部３１５は、生成した応答メッセージを、ネットワークを介して外部装置５に送信する（ステップＳ１７）。
外部装置５は、各サーバ３（＃１，＃２，＃３）から応答メッセージを受信する。そして、外部装置５の応答メッセージ集計部５１２は、受信した応答メッセージから処理担当情報を抽出し、各サーバ３からの処理担当情報を集計して（ステップＳ１８）、クラスタシステム２内の全てのサーバから応答メッセージを受信したか否かを判定する。
具体的には、応答メッセージ集計部５１２は、受信した応答メッセージに処理担当情報として付されたｂｉｔ列をｏｒ演算し、ＩＤ空間（コンシステントハッシュ環）の領域に対応するｂｉｔ列がすべて「１」であるときに、すべてのサーバ３からの応答メッセージを受信した、つまり、全サーバ処理が成功したと判定する。一方、応答メッセージ集計部５１２は、所定の時間内に、ｂｉｔ列がすべて「１」とならなかった場合に、全サーバ処理に失敗したと判定する。
具体的には、応答メッセージ集計部５１２は、受信した応答メッセージに処理担当情報として付されたｂｉｔ列をｏｒ演算し、ＩＤ空間（コンシステントハッシュ環）の領域に対応するｂｉｔ列がすべて「１」であるときに、すべてのサーバ３からの応答メッセージを受信した、つまり、全サーバ処理が成功したと判定する。一方、応答メッセージ集計部５１２は、所定の時間内に、ｂｉｔ列がすべて「１」とならなかった場合に、全サーバ処理に失敗したと判定する。
このようにすることで、本実施形態に係る分散処理システム１および分散処理方法によれば、外部装置５がクラスタシステム２内のサーバ３（クラスタメンバ）の構成を知らなくても、処理要求を送信した外部装置５が、各サーバ３それぞれから処理担当情報を取得し集計することにより、全サーバ処理が成功した否かを判定することができる。そして、本分散処理システム１および分散処理方法によれば、各サーバ３に処理要求を配信したディスパッチャＤが、全サーバ処理の状態等を保持する必要がないため、ディスパッチャＤの処理負荷の増大を抑えることができる。
＜変形例１＞
本実施形態に係る分散処理システム１および分散処理方法においては、ディスパッチャＤから「全サーバ送信フラグ」が設定された処理要求を受信した各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）が、処理結果と処理担当情報とを含む応答メッセージを直接外部装置５に送信するものとして説明した。
これに対し、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、処理結果と処理担当情報とを含む応答メッセージを、処理要求を送信してきたディスパッチャＤに返信し、そのディスパッチャＤがロードバランサＢを介して外部装置５に送信するようにしてもよい。
本実施形態に係る分散処理システム１および分散処理方法においては、ディスパッチャＤから「全サーバ送信フラグ」が設定された処理要求を受信した各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）が、処理結果と処理担当情報とを含む応答メッセージを直接外部装置５に送信するものとして説明した。
これに対し、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）は、処理結果と処理担当情報とを含む応答メッセージを、処理要求を送信してきたディスパッチャＤに返信し、そのディスパッチャＤがロードバランサＢを介して外部装置５に送信するようにしてもよい。
この場合において、ディスパッチャＤは、各プロセッサＰ（Ｐ１，Ｐ２，Ｐ３）からの応答メッセージを集約することなく、受信した応答メッセージをそのままロードバランサＢに転送する。また、ロードバランサＢもディスパッチャＤから応答メッセージを受信すると、集約することなく外部装置５に転送する。
このようにすることで、本実施形態に係る変形例１においても、本実施形態と同様に、ディスパッチャＤが全サーバ処理の状態等を保持する必要がないため、ディスパッチャＤの処理負荷の増大を抑えることができる。
＜変形例２＞
本実施形態に係る分散処理システム１および分散処理方法においては、コンシステントハッシュ法に基づくクラスタシステム２を前提に説明を行った。しかしながら、本発明は、これに限定されず、保存したいデータ（値：value）に対し一意の標識（key）を設定して保存するＫＶＳ（Key Value Store）を採用するクラスタシステムであればよい。
本実施形態に係る分散処理システム１および分散処理方法においては、コンシステントハッシュ法に基づくクラスタシステム２を前提に説明を行った。しかしながら、本発明は、これに限定されず、保存したいデータ（値：value）に対し一意の標識（key）を設定して保存するＫＶＳ（Key Value Store）を採用するクラスタシステムであればよい。
その場合、総数Ｎ個（担当分の総和）のサーバ（プロセッサＰ）に対し、「０」〜「Ｎ−１」の番号を付し、各サーバは、処理結果に、そのサーバ自身に付された番号（「０」〜「Ｎ−１」うちの１つであり、当該サーバの担当分を示す）とサーバ総数Ｎとを付して応答メッセージを生成し、外部装置５に送信すればよい。
外部装置５は、各サーバそれぞれから応答メッセージを受け取り、「０」〜「Ｎ−１」の番号のすべてがそろったか否かで、クラスタシステム内の全てのサーバから応答メッセージを受信したか否か、つまり、全サーバ処理が成功したか否かを判定する。
このようにすることで、分散処理システムを構成する複数のサーバすべてに対し一斉に処理を実行させたい場合において、従来、各サーバに処理要求を配信するディスパッチャＤでなければ、全サーバ処理が成功したか否かを判定できなかったものを、ディスパッチャＤによらず、処理要求を送信した外部装置５において判定できる。よって、ディスパッチャＤが全サーバ処理の状態等を保持する必要がなく、ディスパッチャＤの処理負荷の増大を抑えることができる。
１，１ａ 分散処理システム
２ クラスタシステム
３ サーバ
５ 外部装置
１００ ＩＤ空間管理情報（管理情報）
１１０，３１０ 制御部
１１１，３１１ 情報受信部
１１２，３１２ 構文解析部
１１３ 振り分け処理部
１１４ 要求配信部
１１５，３１６ 情報送信部
１２０，３２０ 入出力部
１３０，３３０ メモリ部
１４０，３４０ 記憶部
３１３ 要求処理部
３１４ 処理担当情報生成部
３１５ 応答メッセージ生成部
５１１ 処理要求送信部
５１２ 応答メッセージ集計部
Ｂ ロードバランサ
Ｄ ディスパッチャ
Ｐ プロセッサ
Ｓ ストレージ
２ クラスタシステム
３ サーバ
５ 外部装置
１００ ＩＤ空間管理情報（管理情報）
１１０，３１０ 制御部
１１１，３１１ 情報受信部
１１２，３１２ 構文解析部
１１３ 振り分け処理部
１１４ 要求配信部
１１５，３１６ 情報送信部
１２０，３２０ 入出力部
１３０，３３０ メモリ部
１４０，３４０ 記憶部
３１３ 要求処理部
３１４ 処理担当情報生成部
３１５ 応答メッセージ生成部
５１１ 処理要求送信部
５１２ 応答メッセージ集計部
Ｂ ロードバランサ
Ｄ ディスパッチャ
Ｐ プロセッサ
Ｓ ストレージ
Claims (3)
- 外部装置から受信した処理要求を、クラスタメンバを構成するサーバに振り分ける複数のディスパッチャと、前記ディスパッチャから受信した前記処理要求に基づき、自身が保存するデータについて処理を実行する複数の前記サーバと、前記サーバが実行した処理結果を受信する前記外部装置と、を備える分散処理システムであって、
前記ディスパッチャは、
前記外部装置から受信した前記処理要求に、前記複数のサーバすべてに対する処理の要求を示す全サーバ送信フラグが設定されているか否かを判定する第１の構文解析部と、
前記第１の構文解析部が前記処理要求に前記全サーバ送信フラグが設定されていると判定した場合に、前記複数のサーバすべてに当該処理要求を配信する要求配信部と、を備え、
前記複数のサーバそれぞれは、
前記サーバそれぞれに割り当てられるデータの担当分と、前記サーバそれぞれの当該担当分の総和とを示す管理情報を記憶する記憶部と、
前記ディスパッチャから受信した処理要求に、前記全サーバ送信フラグが設定されているか否かを判定する第２の構文解析部と、
前記処理要求に示される処理を実行し処理結果を生成する要求処理部と、
前記第２の構文解析部が前記処理要求に前記全サーバ送信フラグが設定されていると判定した場合に、前記管理情報を参照し、前記サーバ自身に割り当てられた前記担当分と、前記担当分の総和とを示す処理担当情報を生成する処理担当情報生成部と、
前記処理結果および前記処理担当情報を含む応答メッセージを生成し、前記外部装置に送信する応答メッセージ生成部と、を備え、
前記外部装置は、
前記複数のサーバすべてに対し処理を要求する場合に、前記全サーバ送信フラグを設定した前記処理要求を前記複数のディスパッチャのいずれかに送信する処理要求送信部と、
前記複数のサーバそれぞれから受信した前記応答メッセージから前記処理担当情報を抽出し、前記抽出した処理担当情報に含まれる前記担当分を、受信した各応答メッセージのすべてについて集計し、当該集計結果が、前記抽出した処理担当情報に含まれる前記担当分の総和と一致するか否かを判定し、所定の時間内に前記担当分の総和と一致した場合は前記複数のサーバすべてに対する処理が成功したと判定し、一致しない場合は失敗したと判定する応答メッセージ集計部と、を備えること
を特徴とする分散処理システム。 - 前記複数のサーバそれぞれの前記応答メッセージ生成部は、
前記生成した応答メッセージを、前記外部装置に替えて、前記処理要求を配信したディスパッチャに送信し、
前記ディスパッチャは、
前記複数のサーバそれぞれから受信した応答メッセージを集約することなく、前記外部装置に転送すること
を特徴とする請求項１に記載の分散処理システム。 - 外部装置から受信した処理要求を、クラスタメンバを構成するサーバに振り分ける複数のディスパッチャと、前記ディスパッチャから受信した前記処理要求に基づき、自身が保存するデータについて処理を実行する複数の前記サーバと、前記サーバが実行した処理結果を受信する前記外部装置と、を備える分散処理システムの分散処理方法であって、
前記外部装置は、
前記複数のサーバすべてに対し処理を要求する場合に、前記複数のサーバすべてに対する処理の要求を示す全サーバ送信フラグを設定した前記処理要求を前記複数のディスパッチャのいずれかに送信するステップを実行し、
前記ディスパッチャは、
前記外部装置から受信した前記処理要求に、前記全サーバ送信フラグが設定されているか否かを判定するステップと、
前記処理要求に前記全サーバ送信フラグが設定されていると判定された場合に、前記複数のサーバすべてに当該処理要求を配信するステップと、を実行し、
前記複数のサーバそれぞれは、
前記サーバそれぞれに割り当てられるデータの担当分と、前記サーバそれぞれの当該担当分の総和とを示す管理情報を記憶する記憶部を備えており、
前記ディスパッチャから受信した処理要求に、前記全サーバ送信フラグが設定されているか否かを判定するステップと、
前記処理要求に示される処理を実行して処理結果を生成するステップと、
前記処理要求に前記全サーバ送信フラグが設定されていると判定された場合に、前記管理情報を参照し、前記サーバ自身に割り当てられた前記担当分と、前記担当分の総和とを示す処理担当情報を生成するステップと、
前記処理結果および前記処理担当情報を含む応答メッセージを生成し、前記外部装置に送信するステップと、を実行し、
前記外部装置は、
前記複数のサーバそれぞれから受信した前記応答メッセージから前記処理担当情報を抽出し、前記抽出した処理担当情報に含まれる前記担当分を、受信した各応答メッセージのすべてについて集計し、当該集計結果が、前記抽出した処理担当情報に含まれる前記担当分の総和と一致するか否かを判定し、所定の時間内に前記担当分の総和と一致した場合は前記複数のサーバすべてに対する処理が成功したと判定し、一致しない場合は失敗したと判定するステップを実行すること
を特徴とする分散処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012172616A JP5723330B2 (ja) | 2012-08-03 | 2012-08-03 | 分散処理システムおよび分散処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012172616A JP5723330B2 (ja) | 2012-08-03 | 2012-08-03 | 分散処理システムおよび分散処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2014032530A JP2014032530A (ja) | 2014-02-20 |
| JP5723330B2 true JP5723330B2 (ja) | 2015-05-27 |
Family
ID=50282310
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012172616A Active JP5723330B2 (ja) | 2012-08-03 | 2012-08-03 | 分散処理システムおよび分散処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5723330B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6374841B2 (ja) * | 2015-08-03 | 2018-08-15 | 日本電信電話株式会社 | 仮想マシン配置装置および仮想マシン配置方法 |
| JP6977621B2 (ja) * | 2018-03-02 | 2021-12-08 | 日本電信電話株式会社 | 制御装置、及び制御方法 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3395208B2 (ja) * | 1991-07-10 | 2003-04-07 | 株式会社日立製作所 | 分散データベースのソート方法およびアクセス方法 |
| JP2002342327A (ja) * | 2001-05-22 | 2002-11-29 | Nec Corp | ディレクトリ検索システム、ディレクトリ検索方法およびディレクトリ検索用プログラム |
| JP4177346B2 (ja) * | 2005-03-30 | 2008-11-05 | 株式会社東芝 | 負荷分散システム、実サーバ及び負荷分散方法 |
| JP2009251756A (ja) * | 2008-04-02 | 2009-10-29 | Nec Corp | クライアント装置、分散ファイルシステム、共有リソース多重化方法およびプログラム |
| WO2011074630A1 (ja) * | 2009-12-17 | 2011-06-23 | 日本電気株式会社 | 負荷分散システム、負荷分散方法、負荷分散システムを構成する装置およびプログラム |
| JP2011180658A (ja) * | 2010-02-26 | 2011-09-15 | Kddi Corp | 分散ファイルシステムにおける冗長化方法 |
| JP2012128698A (ja) * | 2010-12-16 | 2012-07-05 | Hitachi Ltd | 負荷分散ブレードシステム |
-
2012
- 2012-08-03 JP JP2012172616A patent/JP5723330B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2014032530A (ja) | 2014-02-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5719323B2 (ja) | 分散処理システム、ディスパッチャおよび分散処理管理装置 | |
| US20210256016A1 (en) | Blockchain system and method | |
| US9164806B2 (en) | Processing pattern framework for dispatching and executing tasks in a distributed computing grid | |
| WO2019067997A1 (en) | AUTONOMOUS MULTIPLE TENANT DATABASE CLOUD SERVICE FRAME | |
| CA2897338C (en) | Data stream splitting for low-latency data access | |
| US9699085B2 (en) | Periodic advertisements of host capabilities in virtual cloud computing infrastructure | |
| WO2014030235A1 (ja) | 分散型データベースシステム | |
| JP2017129935A (ja) | サーバシステム、サーバシステムを制御する方法およびプログラム。 | |
| JP5969315B2 (ja) | データ移行処理システムおよびデータ移行処理方法 | |
| CN104125294A (zh) | 一种大数据安全管理方法和*** | |
| JP5723330B2 (ja) | 分散処理システムおよび分散処理方法 | |
| US10171570B2 (en) | Information processing apparatus | |
| JPWO2017169471A1 (ja) | 処理システムおよび処理方法 | |
| KR20210097560A (ko) | 블록체인 트랜잭션 처리 방법 | |
| Xia et al. | Distributed web crawling: A framework for crawling of micro-blog data | |
| EP3829139A1 (en) | Distributed storage system for storing context data | |
| JP5956364B2 (ja) | クラスタシステム | |
| JP6324304B2 (ja) | クライアント装置及び通信システム及びデータ処理方法及びプログラム | |
| CN108572993B (zh) | db分库hash方法、电子设备、存储介质和对数据访问的装置 | |
| JP5711772B2 (ja) | クラスタシステム | |
| WO2019218469A1 (zh) | 配置更新方法、配置更新的响应方法及服务器、*** | |
| JP2013182553A (ja) | 管理装置およびプログラム | |
| JP6506156B2 (ja) | ノードおよびグラビテーション抑止方法 | |
| JP2015162216A (ja) | 分散処理システム | |
| JP6326011B2 (ja) | ノード、リバランシングキャンセル方法、および、プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20140325 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20140502 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20140528 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20141107 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20141118 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150113 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20150324 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150327 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5723330 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |