JP5576836B2 - 呼処理データ保存方法、呼処理データ振り分け装置およびプログラム - Google Patents

呼処理データ保存方法、呼処理データ振り分け装置およびプログラム Download PDF

Info

Publication number
JP5576836B2
JP5576836B2 JP2011166232A JP2011166232A JP5576836B2 JP 5576836 B2 JP5576836 B2 JP 5576836B2 JP 2011166232 A JP2011166232 A JP 2011166232A JP 2011166232 A JP2011166232 A JP 2011166232A JP 5576836 B2 JP5576836 B2 JP 5576836B2
Authority
JP
Japan
Prior art keywords
request
call processing
processing data
processor
data
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.)
Expired - Fee Related
Application number
JP2011166232A
Other languages
English (en)
Other versions
JP2013030035A (ja
Inventor
安敏 宮城
悟 近藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2011166232A priority Critical patent/JP5576836B2/ja
Publication of JP2013030035A publication Critical patent/JP2013030035A/ja
Application granted granted Critical
Publication of JP5576836B2 publication Critical patent/JP5576836B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、セッション制御サーバが扱う加入者データ等の呼処理データを保存するデータベースを、複数マシンのクラスタ構成で実現するための、呼処理データ保存方法、呼処理データ振り分け装置およびプログラムに関する。
2つ以上のクライアントの間でセッションを確立するプロトコルとしてSIP(Session Initiation Protocol)が知られている(非特許文献1参照)。また、このSIPを利用した技術として、マルチメディアサービスを実現するIMS(IP Multimedia Subsystem)(非特許文献2参照)や、NGN(Next Generation Network)(非特許文献3参照)がある。
また、あるデータについてのハッシュ値を生成するアルゴリズムであるハッシュアルゴリズムの1つとして、コンシステントハッシュ(Consistent Hashing)(非特許文献4参照)が知られている。
近年、クラウドコンピューティングの隆盛に伴い、分散並列処理技術が発展、普及している。また、設備維持コストの低減を目的として通信網のIP(Internet Protocol)化が進んでおり、従来の交換機のような専用ハードウェアではなく、汎用サーバを用いて通信ネットワークを構築し、通信サービスを実現することが一般化している。
J.Rosenberg, et.al, "SIP: Session Initiation Protocol," RFC3261, IETF, 2002.6 Miikka Poikselka, Georg Mayer ,"The IMS: IP Multimedia Concepts and Services," Wiley, 2009.3 ITU-T Recommendation Y.2012, "Functional requirements and architecture of the NGN," 2006 David Karger, "Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web,"[online]、[平成23年7月14日検索]、インターネット<http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
一般的にデータベースを、複数台の汎用サーバを用いてクラスタ構成として実現する場合、データの複製を保持することで、サーバが故障しても他のサーバで処理を継続し、データの冗長化を実現している。しかし、呼制御サーバで扱うデータ、主に加入者情報等を保存するデータベースには、データの一貫性、応答時間等の要件が数多く存在し、汎用サーバのクラスタ構成を採った際、様々な要因により、要件を満たさない可能性がある。
従来の呼制御において用いられるデータベースはRDB(Relational DataBase)を使用し、冗長化を図る際には、Active-Standbyの構成を採用している。そのため、常に必要なデータベースサーバの倍以上のサーバ筐体を用意しなければならない。一方、データベース分散技術として、Cassandra(非特許文献5:Avinash Lakshman, Prashant Malik, “Cassandra - A Decentralized Structured Storage System, ”ACM SIGOPS Operating Systems Review archive Volume 44 Issue 2, April 2010)を初めとする複数台の汎用サーバを用いてデータベースをクラスタ構成で実現する技術が知られている。このデータベースクラスタでは、データを分散配置することで冗長性、可用性を高めているが、複数の複製データ間の一貫性を完全に担保しようとすると可用性が低下し、一貫性を維持しつつ可用性をある程度確保しようとすると冗長性を下げる必要がある等、トレードオフの関係にあるため、一貫性、可用性、冗長性のいずれかを犠牲にしている場合が多い。
また、既存の呼処理における問題点として、アクセス頻度が偏在することが挙げられる。例えば、イベント予約向け特別電話番号等に対するバースト的な着呼処理時に、特定のデータに対して参照処理が集中するような場合がある。加入者データベースを既存のデータベースクラスタにおいて実現した場合、加入者データを複数サーバに分散保存しているが、複数サーバに対する複製の分散は、ハッシュ関数に基づいてまず1つのサーバに対してマスタデータとしてのデータを送信し、さらに複製となるデータを他サーバに対して割り振って送信している。そして、集中呼による参照時には、マスタデータに対してのみ参照処理を行うため、そのマスタデータを保存する1つのサーバに対して負荷が集中し、処理オーバヘッドが発生してしまう。
このような背景を鑑みて本発明がなされたのであり、本発明は、呼制御サーバが扱う呼処理データを保存するクラスタ構成のデータベースにおいて、複数の複製データ間の一貫性を保ちつつ、可用性や冗長性を低下させず、スケーラブルにデータを書き込むことができる、呼処理データ保存方法、呼処理データ振り分け装置およびプログラムを提供することを課題とする。
前記した課題を解決するため、請求項1に記載の発明は、リクエスタから送信されたリクエストを、プロセッサに振り分ける複数の呼処理データ振り分け装置と、前記呼処理データ振り分け装置から受信したリクエストに基づき、呼処理データをデータストアに保存させる複数の前記プロセッサと、前記プロセッサの指示により前記呼処理データを保存する複数の前記データストアとを備えるデータベースクラスタの呼処理データ保存方法であって、前記呼処理データ振り分け装置が、前記リクエスタから前記リクエストを受信し、前記受信したリクエストの内容を構文解析するステップと、前記構文解析した結果、前記リクエストが前記呼処理データの書き込み要求であると解析した場合に、前記複数のプロセッサのうちから2以上のプロセッサを、前記書き込み要求を示すリクエストの送信先に決定するステップと、前記決定した2以上のプロセッサそれぞれに、前記書き込み要求を示すリクエストを送信するステップと、を実行し、前記2以上のプロセッサそれぞれが、前記書き込み要求を示すリクエストを受信し、自身と接続する前記データストアそれぞれに前記呼処理データを保存させるステップを実行し、前記呼処理データ振り分け装置が、前記書き込み要求を示すリクエストの送信先を決定するステップにおいて、コンシステントハッシュに基づき、前記複数のプロセッサの担当領域をハッシュ空間上に設定するステップと、前記書き込み要求を示すリクエストに含まれるユニークな識別情報をキーとして抽出するステップと、前記抽出したキーを、2以上のハッシュ関数それぞれに導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記書き込み要求を示すリクエストの送信先となる前記2以上のプロセッサを決定するステップと、を含んで実行し、前記呼処理データ振り分け装置が、前記リクエスタから第2の前記リクエストを受信し、前記受信した第2のリクエストの内容を構文解析するステップにおいて、前記構文解析した結果、前記第2のリクエストが前記データストアそれぞれに保存した呼処理データの読み込み要求であると解析した場合に、前記読み込み要求を示す第2のリクエストに含まれるユニークな識別情報をキーとして抽出するステップと、前記抽出したキーを、前記2以上のハッシュ関数のうちの1つを選択して導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記読み込み要求を示す第2のリクエストの送信先となる前記プロセッサを決定するステップと、前記決定したプロセッサに、前記読み込み要求を示す第2のリクエストを送信するステップと、を実行し、前記読み込み要求を示す第2のリクエストを受信したプロセッサが、自身と接続する前記データストアから前記呼処理データを取得して、前記呼処理データ振り分け装置に返信するステップを実行し、前記呼処理データ振り分け装置が、前記返信された前記呼処理データを、前記リクエスタに送信するステップを実行することを特徴とする呼処理データ保存方法とした。
また、請求項に記載の発明は、リクエスタから送信されたリクエストを、複数のプロセッサに振り分けることにより、呼処理データをデータストアに保存させる呼処理データ振り分け装置であって、前記リクエスタから前記リクエストを受信し、前記受信したリクエストの内容を構文解析する構文解析部と、前記構文解析部が構文解析した結果、前記リクエストが前記呼処理データの書き込み要求であると解析した場合に、コンシステントハッシュに基づき、前記複数のプロセッサの担当領域をハッシュ空間上に設定し、前記書き込み要求を示すリクエストに含まれるユニークな識別情報をキーとして抽出し、前記抽出したキーを、2以上のハッシュ関数それぞれに導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記複数のプロセッサのうち、前記書き込み要求を示すリクエストの送信先となる2以上のプロセッサを決定し、前記決定した2以上のプロセッサそれぞれに、前記書き込み要求を示すリクエストを送信する振り分け処理部と、を備え、前記構文解析部が、前記リクエスタから第2の前記リクエストを受信し構文解析した結果、前記第2のリクエストが前記データストアそれぞれに保存した呼処理データの読み込み要求であると解析した場合に、前記振り分け処理部が、前記読み込み要求を示す第2のリクエストに含まれるユニークな識別情報をキーとして抽出し、前記抽出したキーを、前記2以上のハッシュ関数のうちの1つを選択して導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記読み込み要求を示す第2のリクエストの送信先となる前記プロセッサを決定し、前記決定したプロセッサに、前記読み込み要求を示す第2のリクエストを送信することを特徴とする呼処理データ振り分け装置とした。
このようにすることで、本発明によれば、呼処理データ振り分け装置が、書き込み要求を示すリクエストを受信した際に、複数のプロセッサのうちから2以上のプロセッサをリクエストの送信先に決定することにより、複数の複製データ間の一貫性を保ちつつ、可用性や冗長性を低下させず、スケーラブルにデータの書き込みを行うことができる。
また、呼処理データ振り分け装置は、コンシステントハッシュに基づいて、書き込み要求を示すリクエストに含まれるユニークな識別情報をキーとして、2以上のハッシュ関数それぞれに導入することにより、書き込み要求を示すリクエストの送信先となる2以上のプロセッサを決定する。よって、本発明によれば、複数の複製データ間の一貫性を保ちつつ、可用性や冗長性を低下させず、スケーラブルにデータの書き込みを行うことができる。
さらに、呼処理データ振り分け装置は、コンシステントハッシュに基づいて、読み込み要求を示す第2のリクエストに含まれるユニークな識別情報をキーとして、2以上のハッシュ関数のうちの1つを選択して導入することにより、呼処理データをデータストアに保存させた2以上のプロセッサのうちから1つのプロセッサを選択して、読み込み要求を示す第2のリクエストを送信し、データを送信することができる。よって、本発明によれば、アクセス頻度が高い場合でも、呼処理データへの対等な振り分けが可能となり、オーバヘッドを防ぐことができる。
請求項に記載の発明は、コンピュータを、請求項に記載の呼処理データ振り分け装置として機能させるためのプログラムとした。
このようなプログラムによれば、請求項に記載の呼処理データ振り分け装置としての機能を、一般的なコンピュータで実現させることができる。
本発明によれば、呼制御サーバが扱う呼処理データを保存するクラスタ構成のデータベースにおいて、複数の複製データ間の一貫性を保ちつつ、可用性や冗長性を低下させず、スケーラブルにデータを書き込むことができる、呼処理データ保存方法、呼処理データ振り分け装置およびプログラムを提供することができる。
比較例である従来のデータベースクラスタの全体構成を示す概念図である。 比較例のデータベースクラスタにおけるディスパッチャの振り分け処理を説明するための図である。 比較例であるデータベースクラスタにおける冗長化処理を説明するための図である。 本実施形態に係るディスパッチャ(呼処理データ振り分け装置)を含むデータベースクラスタの全体構成を示す概念図である。 本実施形態に係るディスパッチャ(呼処理データ振り分け装置)の構成例を示すブロック図である。
次に、本発明を実施するための形態(以下、「本実施形態」という)におけるクラスタ構成のデータベース(以下、「データベースクラスタ」という)の比較例となる従来技術について説明し、その後に、本実施形態について、適宜図面を参照しながら詳細に説明する。
(比較例)
図1は、比較例である従来のデータベースクラスタの全体構成を示す概念図である。
比較例である従来のデータベースクラスタは、図1に示すように、ロードバランサ(Balancer:各図において「B」と表記)と、複数のディスパッチャ(Dispatcher:各図において「D」と表記)と、複数のプロセッサ(Processor:各図において「P」と表記)と、複数のデータストア(Storage:各図において「S」と表記)とを含んで構成される。
図1に示すこのデータベースクラスタに対するリクエストは、SQL(Structured Query Language)のクエリ文書やXCAP(XML Configuration Access Protocol)のような、データベースからデータを取得するための要求のことであり、データベースに記憶されたデータの更新時には、XMLファイル等が入力として渡されてもよい。ここで、リクエストを行う不図示のリクエスタは、データベースにデータの書き込みや読み出しを要求する他のシステムであり、例えば、呼制御データの投入や参照を行うオペレータシステムや、呼制御サーバである。
図1に示すように、データベースクラスタに対してのリクエストは、まずロードバランサBに到着する。ロードバランサBは、機械的にリクエストの振り分けを行う既存の負荷分散装置である。このロードバランサBは、クラスタ構成の隠蔽や負荷の分散を目的とした、単純(TCP(Transmission Control Protocol)/UDP(User Datagram Protocol)レベル)かつ高速な振り分け処理を行う。そして、ロードバランサBは、リクエストを受信すると、より高度なリクエストの振り分けを行う高レイヤのロードバランサであるディスパッチャDにリクエストを振り分ける。具体的には、ロードバランサBは、リクエストの宛先IPアドレスを元に、ラウンドロビンでそのリクエストをディスパッチャDに振り分けることで、複数のディスパッチャD(図1ではディスパッチャD,D,D)に対して均等にリクエストを割り振ることができる。
ロードバランサBからリクエストを受信したディスパッチャDは、プロセッサPにリクエストを更に振り分ける。ディスパッチャDでは、例えばコンシステントハッシュ(前記した非特許文献4)のアルゴリズムを用いて、各プロセッサP(図1ではプロセッサP,P,P)にリクエストを分散させる。このとき、ディスパッチャDは、受信したリクエストから、例えばリクエストに含まれるURL(Uniform Resource Locator)の一部を用いてキー情報を作成し、ハッシュ関数により導出されたハッシュ値を担当するプロセッサPに対し、リクエストを割り振る。ここで、ハッシュ値の空間(以下、「ハッシュ空間」という)はすべてのディスパッチャDで共有するようにし、各ディスパッチャD(D,D,D)は、プロセッサPの追加や削除に伴い、ハッシュ空間情報を同期する。また、新たなディスパッチャDが追加された場合でも、例えば、他のディスパッチャDからこのハッシュ空間情報を取得する等して、最新のハッシュ空間情報を各ディスパッチャDで同期する。
次に、ディスパッチャDからリクエストを受信したプロセッサPは、受信したリクエストのプロトコル解析や、ファイル形式の確認を行い、データストアSにそのリクエストを送信する。そして、データストアSが、リクエストに基づき、データの書き込みや読み込み等の処理を行う。
<振り分け処理>
図2は、比較例のデータベースクラスタにおけるディスパッチャDの振り分け処理を説明するための図である。図2(a)は、データを書き込むリクエストをデータベースクラスタが受信した場合の振り分け処理を示し、図2(b)は、データを読み込むリクエストをデータベースクラスタが受信した場合の処理を示している。なお、扱うデータは、XML形式でデータストアSが保存するものとする。
図2(a)に示すように、ロードバランサBの振り分け処理により、データを書き込むリクエストを受信したディスパッチャD(ここでは、ディスパッチャD)は、コンシステントハッシュによる振り分けを行う。具体的には、ディスパッチャDが、httpのPUTに含まれるURLの一部(例えば、auid/users/0990@example/a.xml)から、コンフィグ(Config)で指定した部分(0990@example/a.xml等、ファイルをユニークに識別可能な箇所)をキーにハッシュ関数にかけることでハッシュ値を求め、割り振り先となるプロセッサPに振り分ける。図2においては、プロセッサPに振り分けている。
プロセッサPは、ディスパッチャDから受信したリクエストに含まれるXMLファイル等について、スキーマ定義が記述されたXSD(XML Schema Definition)ファイルと照合することで、ファイル形式が正しいか等の判定を行った上で、データストアS(ここではデータストアS)に、そのXMLファイル等を書き込む処理を指示する。データストアS(データストアS)では、プロセッサP(ここではプロセッサP)から受信したXMLファイル等を保存する(書き込む)。
また、図2(b)を参照して、データ読み込み時のデータベースクラスタの処理について説明する。ロードバランサBの振り分け処理により、データを読み込むリクエストを受信したディスパッチャDは、書き込み時と同様にコンシステントハッシュによる振り分けを行う。具体的には、ディスパッチャDが、httpのGETに含まれるURLの一部(auid/users/0990@example/a.xml)から、コンフィグで指定した部分(0990@example/a.xml等)をキーにハッシュ関数にかけることでハッシュ値を求め、振り分け先となるプロセッサPにリクエストを振り分ける。プロセッサPは、XSDファイルとの照合等を行った上で、データストアSからリクエストで指定されたXMLデータを取得し、ディスパッチャD、ロードバランサBを経由して、そのXMLデータをリクエスタに送信する。
なお、ここでのデータストアSは、メモリで実現しても、SAS(Serial Attached SCSI)のようなハードディスクで実現してもよい。また、ディスパッチャD、プロセッサP、データストアSは、それぞれ論理的な構成要素であり、本例では、別々のサーバ筐体に実装しているものとして説明するが、同一のサーバ筐体においてプロセスとして分離されている形で実装してもよい。
<冗長化処理>
次に、比較例であるデータベースクラスタにおける冗長化処理について説明する。既存のデータベースクラスタでは、プロセッサPがデータストアSに対してデータを書き込む際に、データの冗長化、可用性を高めるために複製を作成する。
図3は、比較例である既存のデータベースクラスタにおける冗長化処理を説明するための図である。図3(a)は、データの書き込み時の複製処理を示し、図3(b)は、データの読み込み時の処理を示している。
既存のデータベースクラスタでは、図3(a)に示すように、書き込み時に、ディスパッチャD(ここでは、ディスパッチャD)が、ハッシュ関数により特定のプロセッサP(ここでは、プロセッサP)にリクエストの振り分けを行う。そして、振り分けられたプロセッサPは、特定のデータストアS(ここではデータストアS)をマスタデータの保存先としてデータを書き込み、他のデータストアSのうち予め設定された1つ以上のデータストアS(ここでは、データストアS,S)に対して順次複製を作成する。一方、正常時の読み込み処理では、図3(b)に示すように、各ディスパッチャD(ここでは、ディスパッチャD)は、ハッシュ関数によりプロセッサPにリクエストを振り分け、複製データに対しては読み込みを行わず、マスタデータに対してのみ読み込み処理を行う。
既存のデータベースクラスタでは、書き込み時に、プロセッサPがすべての複製に対して同期をとったことを確認してから処理を完了としているものではなく、マスタデータの書き込みが正常完了すると、処理が正常完了としている。そして、その後に(非同期で)、複製データを他のデータストアSに作成する。
このような既存のデータベースクラスタの処理には、前記したように次に示す問題がある。マスタデータへの書き込み完了後、即座に複製データの作成を行うものではないため、マスタデータと複製データとの間でデータが異なる状況が発生する。例えば、複製を行う前にマスタデータを保存するノード(データストアS)が故障してしまった場合、古い複製データをマスタデータとして復元してしまうため、データの一貫性がとれない。既存の処理は、可用性を高めるための方式であるが、すべての複製データについて一貫性が担保できないというトレードオフが存在する。また、データの読み込み時には、マスタデータに対してのみ参照しているため、特定の呼番号に対して集中リクエストがあった場合に、処理オーバヘッドが発生し、スループットが低下してしまうという問題がある。本発明は、これらの問題を解決するものである。
(本実施形態)
次に、本実施形態に係る呼処理データ保存方法について説明する。
図4は、本実施形態に係るディスパッチャD(呼処理データ振り分け装置)を含むデータベースクラスタの全体構成を示す概念図である。図4(a)は、書き込み時における処理を示し、図4(b)は、読み込み時における処理を示している。
図4に示すデータベースクラスタの全体構成は、図1〜図3に示した従来のデータベースクラスタの構成と同じであるが、本実施形態に係る呼処理データ保存方法においては、次の点が従来のデータベースクラスタの処理とは異なる。従来は、ロードバランサBからリクエストを受信したディスパッチャDが、複数のプロセッサPの中から、ハッシュ関数によりプロセッサPを1つ選択してそのリクエストを振り分けていた。これに対し、本実施形態に係る呼処理データ保存方法では、ディスパッチャD(図4(a)のディスパッチャD)が複数のハッシュ関数(h1,h2,h3)を備えており、データ書き込み時に、複数のハッシュ関数(h1,h2,h3)に同一キーを入力することで、複数のプロセッサP(P,P,P)を選択してリクエストを送信し、各データストアS(S,S,S)にデータを書き込む処理をする際に、すべての複製に対して同期をとったことを確認してから処理を完了とする。
このように、複数のプロセッサP(P,P,P)に対してリクエストを振り分けて複製を作成することにより冗長化させ、データを均等配分し、可用性を高めるとともに、各複製データにおいて一貫性を保つことができる。
また、データ読み込み時には、ディスパッチャD(図4(b)のディスパッチャD)が、複数のハッシュ関数(h1,h2,h3)のうちの1つを選択し、そのハッシュ関数にキー情報を入力することで、1つのプロセッサP(ここでは、プロセッサP)を決定し、そのプロセッサP(P)がデータストアS(ここでは、データストアS)からデータを取得する。このようにすることで、アクセス頻度が偏在している参照時であっても、複製データへの対等な振り分けが可能になるため、オーバヘッドを防ぐことができる。
<ディスパッチャ>
次に、本実施形態に係るディスパッチャD(呼処理データ振り分け装置)について詳細に説明する。
図5は、本実施形態に係るディスパッチャD(呼処理データ振り分け装置)の構成例を示すブロック図である。
ディスパッチャDは、ロードバランサBおよび複数のプロセッサPと通信可能に接続され(適宜図4参照)、ロードバランサBから取得したリクエストを、プロセッサPに振り分ける装置であり、図5に示すように、制御部10と、入出力部20と、メモリ部30と、記憶部40とを含んで構成される。
入出力部20は、ロードバランサBや、各プロセッサPとの間の情報の入出力を行う。例えば、入出力部20は、ロードバランサBが送信したリクエストを受信し、各プロセッサPに対し、そのリクエストの送信を行う。また、データストアSに保存されていたデータをプロセッサPから受信し、ロードバランサBに対して送信する等の処理を行う。
また、この入出力部20は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力装置やモニタ等の出力装置等との間で入出力を行う入出力インタフェースとから構成される。
制御部10は、ディスパッチャD全体の制御を司り、情報受信部11と、構文解析部12と、振り分け処理部13と、情報送信部14とを含んで構成される。なお、この制御部10は、例えば、ディスパッチャDの記憶部40に格納されたプログラムをCPU(Central Processing Unit)がメモリ部30であるRAM(Random Access Memory)に展開し実行することで実現される。
情報受信部11は、入出力部20を介して、ロードバランサBからのリクエストや、プロセッサP等からのデータを取得する。
構文解析部12は、情報受信部11からリクエストを受け取り、そのリクエストの内容を構文解析する。例えば、構文解析部12は、そのリクエストがデータストアSに対する「PUT(書き込み)」を要求するリクエストであるか、「GET(読み込み)」を要求するリクエスト(第2のリクエスト)であるか等を解析し、その解析情報とともに、リクエストを振り分け処理部13に引き渡す。
振り分け処理部13は、リクエストの振り分け先となるプロセッサPを決定する処理を行う。この振り分け処理部13は、関数選択部131と複数のハッシュ値計算部132(132a,132b,132c)とを備える。
関数選択部131は、構文解析部12の解析情報に基づき、振り分け先となるプロセッサPをハッシュ関数を用いて決定するハッシュ値計算部132を選択する。
具体的には、関数選択部131は、構文解析部12が、リクエストの内容を、「PUT(書き込み)」であると解析した場合には、設定されている各ハッシュ値計算部132(132a,132b,132c)を選択し、その選択したハッシュ値計算部132に対して、リクエストを引き渡す。
また、関数選択部131は、構文解析部12が、リクエストの内容を、「GET(読み込み)」であると解析した場合には、ランダム若しくはラウンドロビンで、設定されているハッシュ値計算部132(132a,132b,132c)のうちの1つを選択し、その選択したハッシュ値計算部132に対して、リクエストを引き渡す。
ハッシュ値計算部132は、コンシステントハッシュを用いて、例えば、記憶部40に記憶された、各プロセッサP(P,P,P,…)のID(IPアドレス等)のハッシュ値を計算し、閉じたハッシュ空間上に配置しておく。なお、このハッシュ値計算部132は、プロセッサPが故障等で減設された場合や、システム設計者等によりプロセッサPが増設された場合ごとに、ハッシュ空間上での各プロセッサPの担当領域の再設定を行う。
そして、ハッシュ値計算部132は、取得したリクエストに含まれるURLの一部から、コンフィグで指定した部分であるユニークな識別箇所(識別情報)をキーとしてハッシュ関数(h)にかけることでハッシュ値を計算し、ハッシュ空間上に配置する。
続いて、ハッシュ値計算部132は、ハッシュ空間上での配置から、その領域を担当するプロセッサPを、リクエストの振り分け先として決定する。
このハッシュ値計算部132は、システム設計者等により、データの冗長化が必要な数として複数設定される。つまり、2以上のハッシュ関数が設定される。図5に示すように、例えば、データを3重化する場合には、3つのハッシュ値計算部132(132a,132b,132c)が設けられ、3つのハッシュ関数(h1,h2,h3)が設定される。そして、ハッシュ値計算部132aは、ハッシュ関数(h1)によりハッシュ値を計算し、ハッシュ値計算部132bは、ハッシュ関数(h2)によりハッシュ値を計算し、ハッシュ値計算部132cは、ハッシュ関数(h3)によりハッシュ値を計算する。このハッシュ関数(h1,h2,h3)は、リクエストに含まれるURIの一部をキー(同一キー)として計算されるハッシュ値を、異なるプロセッサPの担当領域に配置するように演算する。このようにすることで、2以上のプロセッサPがリクエストの振り分け先として決定される。従って、ハッシュ値計算部132を設けた数だけ、冗長化することができる。
また、関数選択部131により、複数のハッシュ値計算部132(132a,132b,132c)のうちの1つのハッシュ値計算部132が、ランダム若しくはラウンドロビンで選択されることで、アクセス頻度が偏在している読み込み時であっても、複製データへの対等な振り分けが可能になる。
なお、ディスパッチャD,D,Dは、それぞれ同じ複数のハッシュ関数(h1,h2,h3)を備えたハッシュ値計算部132(132a,132b,132c)を備える。
情報送信部14は、振り分け処理部13が決定した振り分け先となるプロセッサPに対し、リクエスト等を送信する。また、プロセッサPから受信したデータをロードバランサBへ送信する等の制御を行う。
次に、記憶部40は、ハードディスクやフラッシュメモリ等の記憶装置からなり、制御部10や入出力部20を制御するためのプログラム等を記憶している。
メモリ部30は、RAM等の一次記憶装置からなり、制御部10によるデータ処理に必要な情報、例えば、各プロセッサPのID(IPアドレス)等を一時的に記憶している。
<呼処理データ保存方法>
次に、本実施形態に係る呼処理データ保存方法について、図4を参照して詳細に説明する(適宜図5参照)。
≪書き込み時≫
まず、図4(a)を参照して、書き込み時の処理について説明する。
リクエスタ(不図示)からの書き込み要求としてのリクエストを取得したロードバランサBは、ラウンドロビンで振り分け先のディスパッチャDを決定し、そのリクエストを送信する。ここでは、振り分け先としてディスパッチャDが選択される。
ディスパッチャDは、リクエストを受信すると、構文解析部12が、そのリクエストの内容を構文解析する。そして、ここでは、構文解析部12が、そのリクエストがデータストアSに対する「PUT(書き込み)」を要求するものであると解析し、この解析情報とともに、リクエストを振り分け処理部13に引き渡す。
振り分け処理部13は、解析情報とリクエストとを受け取ると、まず、関数選択部131が、受け取った解析情報に基づき、ハッシュ値計算部132を選択する。ここで、関数選択部131は、解析情報により、リクエストの内容が「PUT(書き込み)」であるので、振り分け処理部13内に設定された複数のハッシュ値計算部132(132a,132b,132c)を振り分け先として選択する。そして、関数選択部131は、リクエストをハッシュ値計算部132(132a,132b,132c)それぞれに引き渡す。
ハッシュ値計算部132(132a,132b,132c)それぞれは、取得したリクエストに含まれるURLの一部から、コンフィグで指定した部分であるユニークな識別箇所(識別情報)をキーとして、それぞれに設定されているハッシュ関数(h1,h2,h3)にかけることでハッシュ値を計算し、ハッシュ空間上に配置する。
続いて、ハッシュ値計算部132(132a,132b,132c)それぞれは、ハッシュ空間上での配置から、その領域を担当するプロセッサPを、リクエストの振り分け先として決定する。
例えば、ハッシュ値計算部132aは、URLの一部をキーとして、ハッシュ関数(h1)にかけることで、ハッシュ値を計算し、ハッシュ空間上での配置から、振り分け先をプロセッサPに決定する。ハッシュ値計算部132bは、同じURLの一部をキーとして、ハッシュ関数(h2)にかけることで、ハッシュ値を計算し、ハッシュ空間上での配置から、振り分け先をプロセッサPに決定する。また、ハッシュ値計算部132cは、同じURLの一部をキーとして、ハッシュ関数(h3)にかけることで、ハッシュ値を計算し、ハッシュ空間上での配置から、振り分け先をプロセッサPに決定する。
そして、各ハッシュ値計算部132a,132b,132cは、情報送信部14を介して、リクエストをそれぞれが決定したプロセッサP(P,P,P)に送信する。
プロセッサP,P,Pそれぞれは、ディスパッチャDから受信したリクエストを受信すると、そのリクエストに含まれるXMLファイル等について、スキーマ定義が記述されたXSDファイルと照合することで、ファイル形式が正しいか等の判定を行った上で、データストアS(S,S,S)それぞれに、そのXMLファイル等を書き込む処理を行う。その際、すべての複製に対して同期をとったことを確認して、ディスパッチャDは、処理を完了とする。
≪読み込み時≫
次に、図4(b)を参照して、読み込み時の処理について説明する(適宜図5参照)。なお、ここでは、図4(a)の書き込み処理により、同じXMLファイルのデータがデータストアS(S,S,S)に書き込まれているものとする。
リクエスタ(不図示)からの読み込み要求としてのリクエスト(第2のリクエスト)を取得したロードバランサBは、ラウンドロビンで振り分け先のディスパッチャDを決定し、そのリクエストを送信する。ここでは、振り分け先としてディスパッチャDが選択される。
ディスパッチャDは、リクエストを受信すると、構文解析部12が、そのリクエストの内容を構文解析する。そして、ここでは、構文解析部12が、そのリクエストがデータストアSに対する「GET(読み込み)」を要求するものであると解析し、この解析情報とともに、リクエストを振り分け処理部13に引き渡す。
振り分け処理部13は、解析情報とリクエストとを受け取ると、まず、関数選択部131が、受け取った解析情報に基づき、ハッシュ値計算部132を選択する。ここで、関数選択部131は、解析情報により、リクエストの内容が「GET(読み込み)」であるので、ランダム若しくはラウンドロビンで、設定されている複数のハッシュ値計算部132(132a,132b,132c)のうちの1つを選択し、その選択したハッシュ値計算部132に対して、リクエストを引き渡す。ここでは、ハッシュ値計算部132aが選択されたものとする。
ハッシュ値計算部132aは、取得したリクエストに含まれるURLの一部から、コンフィグで指定した部分であるユニークな識別箇所(識別情報)をキーとして、ハッシュ関数(h1)にかけることでハッシュ値を計算し、ハッシュ空間上での配置から、振り分け先をプロセッサPに決定する。
そして、ハッシュ値計算部132aは、情報送信部14を介して、リクエストを決定したプロセッサPに送信する。
プロセッサPは、ディスパッチャDから受信したリクエストを受信すると、そのリクエストに含まれるXMLファイルについて、スキーマ定義が記述されたXSDファイルと照合することで、ファイル形式が正しいか等の判定を行った上で、データストアSからデータを取得する。そして、プロセッサP、ディスパッチャD、ロードバランサBを経由して、リクエスタにそのデータを送信する。
以上のように、本実施形態に係る呼処理データ保存方法、ディスパッチャD(呼処理データ振り分け装置)およびプログラムによれば、ディスパッチャDから複数のプロセッサPにリクエストを分散させて、複数のデータストアSに複製データを記憶するため、複数のデータ間の一貫性を保ちつつ、可用性や冗長性を低下させることなくスケーラブルな構成が可能となる。つまり、ディスパッチャDや、プロセッサP、データストアSが故障等の理由で減設した場合でも、他のデータストアSが複製情報を保持しているため、データベースへのアクセスを中断することなく実行でき、高い可用性が実現できる。また、アクセス頻度が偏在している参照時に、プロセッサPを、複数のプロセッサPからランダム若しくはラウンドロビンで振り分けて実行させることができるため、複製データへの対等な振り分けが可能となりオーバヘッドを防ぐことができる。さらに、それでも処理の応答時間の増加や、保存データ容量が逼迫した場合、動的にディスパッチャD、プロセッサP、データストアSを追加することも可能となる。
なお、本実施形態の構成は、従来技術と同様に、データストアSを、メモリで実現しても、SAS(Serial Attached SCSI)のようなハードディスクで実現してもよい。また、ディスパッチャD、プロセッサP、データストアSそれぞれは、別々のサーバ筐体に実装されていてもよいし、同一のサーバ筐体においてプロセスとして分離されている形で実装してもよい。また、ロードバランサBをなくし、リクエスタから直接各ディスパッチャD(D,D,D)がリクエストを受信するようにしてもよいし、本実施形態のように、ロードバランサBがリクエスタからリクエストを受信し、各ディスパッチャD(D,D,D)に振り分けるようにしてもよい。
10 制御部
11 情報受信部
12 構文解析部
13 振り分け処理部
14 情報送信部
20 入出力部
30 メモリ部
40 記憶部
131 関数選択部
132 ハッシュ値計算部
B ロードバランサ
D ディスパッチャ(呼処理データ振り分け装置)
P プロセッサ
S データストア

Claims (3)

  1. リクエスタから送信されたリクエストを、プロセッサに振り分ける複数の呼処理データ振り分け装置と、前記呼処理データ振り分け装置から受信したリクエストに基づき、呼処理データをデータストアに保存させる複数の前記プロセッサと、前記プロセッサの指示により前記呼処理データを保存する複数の前記データストアとを備えるデータベースクラスタの呼処理データ保存方法であって、
    前記呼処理データ振り分け装置は、
    前記リクエスタから前記リクエストを受信し、前記受信したリクエストの内容を構文解析するステップと、
    前記構文解析した結果、前記リクエストが前記呼処理データの書き込み要求であると解析した場合に、
    前記複数のプロセッサのうちから2以上のプロセッサを、前記書き込み要求を示すリクエストの送信先に決定するステップと、
    前記決定した2以上のプロセッサそれぞれに、前記書き込み要求を示すリクエストを送信するステップと、を実行し、
    前記2以上のプロセッサそれぞれは、
    前記書き込み要求を示すリクエストを受信し、自身と接続する前記データストアそれぞれに前記呼処理データを保存させるステップを実行し、
    前記呼処理データ振り分け装置は、
    前記書き込み要求を示すリクエストの送信先を決定するステップにおいて、
    コンシステントハッシュに基づき、前記複数のプロセッサの担当領域をハッシュ空間上に設定するステップと、
    前記書き込み要求を示すリクエストに含まれるユニークな識別情報をキーとして抽出するステップと、
    前記抽出したキーを、2以上のハッシュ関数それぞれに導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記書き込み要求を示すリクエストの送信先となる前記2以上のプロセッサを決定するステップと、を含んで実行し、
    前記呼処理データ振り分け装置は、
    前記リクエスタから第2の前記リクエストを受信し、前記受信した第2のリクエストの内容を構文解析するステップにおいて、前記構文解析した結果、前記第2のリクエストが前記データストアそれぞれに保存した呼処理データの読み込み要求であると解析した場合に、
    前記読み込み要求を示す第2のリクエストに含まれるユニークな識別情報をキーとして抽出するステップと、
    前記抽出したキーを、前記2以上のハッシュ関数のうちの1つを選択して導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記読み込み要求を示す第2のリクエストの送信先となる前記プロセッサを決定するステップと、
    前記決定したプロセッサに、前記読み込み要求を示す第2のリクエストを送信するステップと、を実行し、
    前記読み込み要求を示す第2のリクエストを受信したプロセッサは、
    自身と接続する前記データストアから前記呼処理データを取得して、前記呼処理データ振り分け装置に返信するステップを実行し、
    前記呼処理データ振り分け装置は、
    前記返信された前記呼処理データを、前記リクエスタに送信するステップを実行すること
    を特徴とする呼処理データ保存方法。
  2. リクエスタから送信されたリクエストを、複数のプロセッサに振り分けることにより、呼処理データをデータストアに保存させる呼処理データ振り分け装置であって、
    前記リクエスタから前記リクエストを受信し、前記受信したリクエストの内容を構文解析する構文解析部と、
    前記構文解析部が構文解析した結果、前記リクエストが前記呼処理データの書き込み要求であると解析した場合に、
    コンシステントハッシュに基づき、前記複数のプロセッサの担当領域をハッシュ空間上に設定し、
    前記書き込み要求を示すリクエストに含まれるユニークな識別情報をキーとして抽出し、
    前記抽出したキーを、2以上のハッシュ関数それぞれに導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記複数のプロセッサのうち、前記書き込み要求を示すリクエストの送信先となる2以上のプロセッサを決定し、前記決定した2以上のプロセッサそれぞれに、前記書き込み要求を示すリクエストを送信する振り分け処理部と、を備え
    前記構文解析部が、前記リクエスタから第2の前記リクエストを受信し構文解析した結果、前記第2のリクエストが前記データストアそれぞれに保存した呼処理データの読み込み要求であると解析した場合に、
    前記振り分け処理部が、
    前記読み込み要求を示す第2のリクエストに含まれるユニークな識別情報をキーとして抽出し、
    前記抽出したキーを、前記2以上のハッシュ関数のうちの1つを選択して導入することにより、ハッシュ値を計算し、前記ハッシュ空間上の前記プロセッサの担当領域に基づき、前記読み込み要求を示す第2のリクエストの送信先となる前記プロセッサを決定し、前記決定したプロセッサに、前記読み込み要求を示す第2のリクエストを送信すること
    を特徴とする呼処理データ振り分け装置。
  3. コンピュータを、請求項に記載の呼処理データ振り分け装置として機能させるためのプログラム。
JP2011166232A 2011-07-29 2011-07-29 呼処理データ保存方法、呼処理データ振り分け装置およびプログラム Expired - Fee Related JP5576836B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011166232A JP5576836B2 (ja) 2011-07-29 2011-07-29 呼処理データ保存方法、呼処理データ振り分け装置およびプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011166232A JP5576836B2 (ja) 2011-07-29 2011-07-29 呼処理データ保存方法、呼処理データ振り分け装置およびプログラム

Publications (2)

Publication Number Publication Date
JP2013030035A JP2013030035A (ja) 2013-02-07
JP5576836B2 true JP5576836B2 (ja) 2014-08-20

Family

ID=47787011

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011166232A Expired - Fee Related JP5576836B2 (ja) 2011-07-29 2011-07-29 呼処理データ保存方法、呼処理データ振り分け装置およびプログラム

Country Status (1)

Country Link
JP (1) JP5576836B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015033451A1 (ja) * 2013-09-06 2015-03-12 株式会社日立製作所 分散ストレージシステム及びそのデータアクセス方法
JP6305078B2 (ja) * 2014-01-29 2018-04-04 キヤノン株式会社 システムおよび制御方法
JP6571614B2 (ja) * 2016-09-02 2019-09-04 日本電信電話株式会社 振分装置、通信システム及びデータ振分方法
JP6674871B2 (ja) * 2016-09-08 2020-04-01 日本電信電話株式会社 異種データベース管理装置、方法及びプログラム
CN116703651B (zh) * 2023-08-08 2023-11-14 成都秦川物联网科技股份有限公司 一种智慧燃气数据中心运行管理方法、物联网系统和介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5396848B2 (ja) * 2008-12-16 2014-01-22 富士通株式会社 データ処理プログラム、サーバ装置およびデータ処理方法

Also Published As

Publication number Publication date
JP2013030035A (ja) 2013-02-07

Similar Documents

Publication Publication Date Title
CN111480154B (zh) 批量数据摄取的方法、系统和介质
Wang et al. HydraDB: a resilient RDMA-driven key-value middleware for in-memory cluster computing
EP1330907B1 (en) Method and apparatus for real-time parallel delivery of segments of a large payload file
US10803015B2 (en) Caching system and method
CA2512312C (en) Metadata based file switch and switched file system
US8805984B2 (en) Multi-operational transactional access of in-memory data grids in a client-server environment
JP5576836B2 (ja) 呼処理データ保存方法、呼処理データ振り分け装置およびプログラム
US20120166403A1 (en) Distributed storage system having content-based deduplication function and object storing method
JP6408433B2 (ja) 負荷分散プログラムおよびサーバ
US20070220302A1 (en) Session failover management in a high-availability server cluster environment
CN104834722A (zh) 基于cdn的内容管理系统
KR20120072907A (ko) 오브젝트를 복수 개의 데이터 노드들의 위치에 기반하여 분산 저장하는 분산 저장 시스템 및 그 위치 기반 분산 저장 방법 및 컴퓨터에 의하여 독출 가능한 저장 매체
KR20120072908A (ko) 복수 개의 프락시 서버를 포함하는 분산 저장 시스템 및 그 오브젝트 관리 방법 및 컴퓨터에 의하여 독출가능한 저장 매체
EP2791819A1 (en) Content delivery network
CN110300188B (zh) 数据传输系统、方法和设备
Zhao et al. Sdpaxos: Building efficient semi-decentralized geo-replicated state machines
WO2015021178A1 (en) System and method for processing web service transactions using timestamp data
WO2015021172A1 (en) System and method for storing and processing web service requests
US11025688B1 (en) Automated streaming data platform
WO2018072450A1 (en) Method for elastic geographical database replication
JP2014041550A (ja) データ移行処理システムおよびデータ移行処理方法
CN109067898A (zh) 一种通过文件散列分布降低内容分发网络边缘节点回源率的方法
EP2523423A1 (en) Method and system for providing a distributed scalable hosting environment for web services
CN110928911A (zh) 审校请求处理系统、方法、装置、计算机可读存储介质
US10992748B1 (en) Verification of event-based synchronization

Legal Events

Date Code Title Description
RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20130201

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130819

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140225

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140311

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20140502

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140508

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20140528

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: 20140701

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140704

R150 Certificate of patent or registration of utility model

Ref document number: 5576836

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees