×この技術を簡単クリック査定この機能をご利用いただくには、会員登録(無料)が必要です。出願した特許の牽制数、引用された数などを知る事ができます。気になる技術や特許をブックマークしておけば、いつでも後から読むことができます。後で印刷するために、公報をPDFでダウンロードできます。会員登録してastamuseを使えば、もっと簡単に便利にお使いいただけます。会員登録(無料)「astamuse」は世界中の挑戦したい社会課題に挑戦し、未来を創る人のプラットフォームです。関連する未来課題-重要な関連分野マルチプログラミング※この項目の情報は公開日時点(2016年2月8日)のものです。分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することを課題とする。4への通知、および、リソースの追加、の少なくともいずれかを実行するリソース監視機能部16とを備える。概要この情報を共有FacebookTwitterGoogle+LinkedIn背景ユーザ端末からのリクエストを担当する処理サーバを決定する分散処理を行うための技術として、例えば、コンシステントハッシュ法を用いて処理の分散化を行う分散データ管理方法がある(特許文献1)。この分散データ管理方法では、コンシステントハッシュ法が用いられ、仮想ハッシュ空間上に処理サーバが割り当てられており、分散データ管理装置は、ユーザ端末からリクエスト(サービス要求信号)を受信すると、リクエストを識別するキーを元に仮想ハッシュ空間上の値を算出し、算出した仮想ハッシュ空間上の値から、そのリクエストへの応答(サービス処理)を担当する処理サーバ(サービス処理サーバ)を決定し、決定された処理サーバにそのリクエストを転送することで、分散処理を実現している。この分散処理(D(Dispatch)信号処理)とサービス処理(PS(Processing)信号処理)は、1つのマシン(処理サーバ)に重畳させて実行することも可能である。1つのマシンに重畳させて実行することで、D信号処理の結果、サービス処理サーバが自分自身の処理サーバであった場合に、マシン間通信の必要がなく、その通信分のコストを削減することができるという利点がある。分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することを課題とする。4への通知、および、リソースの追加、の少なくともいずれかを実行するリソース監視機能部16とを備える。通知、および、リソースの追加、の少なくともいずれかを実行するリソース監視機能部と、を備えることを特徴とする処理サーバ。Unit)またはメモリの使用率の情報であることを特徴とする請求項4に記載の処理サーバ。請求項6前記リソース使用状況情報は、単位時間当たりの前記分散処理の数の情報であることを特徴とする請求項4に記載の処理サーバ。0001本発明は、ユーザ端末からのリクエストを複数の処理サーバで分担して処理する技術に関する。背景技術0002ユーザ端末からのリクエストを担当する処理サーバを決定する分散処理を行うための技術として、例えば、コンシステントハッシュ法を用いて処理の分散化を行う分散データ管理方法がある(特許文献1)。この分散データ管理方法では、コンシステントハッシュ法が用いられ、仮想ハッシュ空間上に処理サーバが割り当てられており、分散データ管理装置は、ユーザ端末からリクエスト(サービス要求信号)を受信すると、リクエストを識別するキーを元に仮想ハッシュ空間上の値を算出し、算出した仮想ハッシュ空間上の値から、そのリクエストへの応答(サービス処理)を担当する処理サーバ(サービス処理サーバ)を決定し、決定された処理サーバにそのリクエストを転送することで、分散処理を実現している。0003この分散処理(D(Dispatch)信号処理)とサービス処理(PS(Processing)信号処理)は、1つのマシン(処理サーバ)に重畳させて実行することも可能である。1つのマシンに重畳させて実行することで、D信号処理の結果、サービス処理サーバが自分自身の処理サーバであった場合に、マシン間通信の必要がなく、その通信分のコストを削減することができるという利点がある。Unit)、メモリなど)でサービス処理用のリソースを圧迫することは回避するべきである。D信号処理によって分散が実施できても、肝心のサービス処理が遅延しては、処理サーバ側に留保されるリクエストが増加し、リソース使用率の増加を招く、あるいは、処理サーバの応答時間が増加し、ユーザ端末側への影響が発生する、といったことが考えられるためである。0006また、一般に、通信サーバにおいては、信号の受信処理よりも送信処理を優先するという、いわゆる出側優先の思想でソフトウェアの設計がなされている。したがって、分散処理を行う処理サーバについても、出側優先のソフトウェア設計が望ましい。0007そこで、本発明は、分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することを課題とする。通知、および、リソースの追加、の少なくともいずれかを実行することを特徴とする。通知、および、リソースの追加、の少なくともいずれかを実行することで、分散処理の増大によるサービス処理の遅延を回避することができる。Unit)またはメモリの使用率の情報であることを特徴とする。0011これによれば、リソース使用状況情報として、増大すればサービス処理の遅延に直接つながってしまう、分散処理に関するCPUまたはメモリの使用率の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。0012また、本発明は、リソース使用状況情報が、単位時間当たりの分散処理の数の情報であることを特徴とする。0013これによれば、リソース使用状況情報として、増大すればサービス処理の遅延に直接つながってしまう、単位時間当たりの分散処理の数の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。0014また、本発明は、コンピュータを、前記処理サーバとして機能させるためのプログラムとして実現できる。これにより、コンピュータを、前記処理サーバとして機能させることができる。発明の効果0015本発明によれば、分散処理とサービス処理を並行して行う処理サーバにおいて、分散処理の増大によるサービス処理の遅延を回避することができる。図面の簡単な説明0016本実施形態の処理サーバを含む全体構成図である。(a)は、リソース使用状況情報の例を示す図である。(b)は、閾値情報の例を示す図である。本実施形態における処理サーバなどの処理の流れを示したシーケンス図である。(a)は、リソース使用状況情報の他の例を示す図である。(b)は、閾値情報の他の例を示す図である。実施例0017本発明を実施するための形態(実施形態)について、図面を参照しながら説明する。図1に示すように、処理システム100は、処理サーバ1と、複数の他の処理サーバ3とを備えている。処理サーバ1と複数の他の処理サーバ3は同等であるが、ここでは、処理サーバ1に着目するものとする。処理サーバ1と複数の他の処理サーバ3をまとめて表現する場合は、「処理サーバ1,3」と記載する。「処理サーバ1,3」のうちの1つを指す場合、符号無しで「処理サーバ」と記載する場合もある。図10018処理システム100において、ユーザ端末2からのリクエストを処理サーバ1,3のいずれかが受信すると、受信した処理サーバは、処理サーバ1,3のうち前記リクエストを担当する処理サーバを決定する分散処理を行い、前記決定された処理サーバが前記リクエストに応答するサービス処理を行う。処理サーバ1,3それぞれは、分散処理とサービス処理とを並行して行う。Drive)、フラッシュメモリなどによって実現される記憶部17を備えて構成される。0020記憶部17は、リソース使用状況情報18および閾値情報19(所定の閾値)を記憶する。記憶部17は、コンピュータを処理サーバ1として機能させるためのプログラムを記憶している。このプログラムにより、コンピュータを処理サーバ1として機能させることができる。0021D信号受信機能部11は、ユーザ端末2からのリクエストの信号(D信号)を受信キューから取り出す。D信号処理機能部12(分散処理部)は、D信号を解析して、例えばコンシステントハッシュ法によって、担当する処理サーバを決定する分散処理を行う。0022PS信号受信機能部13は、他の処理サーバ3からの信号(PS信号)を受信キューから取り出す。PS信号処理機能部14(サービス処理部)は、PS信号を解析してサービス処理を行う。0023送信機能部15は、D信号処理機能部12によって決定された処理サーバや、ユーザ端末2へ、信号を送信する。4への通知、および、リソースの追加、の少なくともいずれかを実行する(詳細は後記)。0024記憶部17には、図2(a)に示すように、リソース使用状況情報18として、スレッドID(IDentifier)ごとに、用途、CPU使用率(%)、メモリ使用率(%)の各情報が格納される。リソース使用状況情報18は、D信号処理機能部12、PS信号処理機能部14によって逐次更新される。図20025記憶部17には、図2(b)に示すように、閾値情報19として、例えば、全体CPU使用率閾値、D信号処理スレッド用のCPU使用率閾値、全体メモリ使用率閾値、D信号処理スレッド用のメモリ使用率閾値の各情報が予め設定されている。図20026次に、本実施形態における処理サーバ1などの処理の流れについて説明する。図3に示すように(図1も参照)、ユーザ端末2が要求信号(D信号。リクエスト)を送信し(S1)、その要求信号を処理サーバ1が受信するものとする。図1図30027処理サーバ1において、D信号受信機能部11は、ユーザ端末2からの要求信号を受信し、その要求信号をD信号処理機能部12に受け渡す(S2)。D信号処理機能部12は、要求信号を受け取ると、スレッドを生成し(S3)、スレッドIDをリソース監視機能部16に通知する(S4)。D信号処理機能部12は、記憶部17のリソース使用状況情報18を更新する。0028次に、D信号処理機能部12は、その要求信号を担当する処理サーバを決定する分散処理を行い(S5)、決定された処理サーバに対して、送信機能部15を経由してその要求信号(PS信号)を送信する(S6、S7)その要求信号(PS信号)受け取った処理サーバ(他の処理サーバ3)は、その要求信号に応答するサービス処理を行う。0029また、処理サーバ1のPS信号受信機能部13は、ユーザ端末2からの他の要求信号(D信号)を受信して分散処理を終えた他の処理サーバ3から要求信号(PS信号)を受け取ると(S8)、その要求信号をPS信号処理機能部14に受け渡す(S9)。0030PS信号処理機能部14は、要求信号を受け取ると、スレッドを生成し(S10)、スレッドIDをリソース監視機能部16に通知する(S11)。PS信号処理機能部14は、記憶部17のリソース使用状況情報18を更新する。0031次に、PS信号処理機能部14は、その要求信号(PS信号)に関するサービス処理を行い(S12)、その要求信号を発したユーザ端末2に対して、送信機能部15を経由して応答信号を送信する(S13、S14)。0032また、リソース監視機能部16は、定期的に起動し、S4とS11で受け取ったスレッドIDを用いて、記憶部17からリソース使用状況情報18を収集する(S15)。次に、リソース監視機能部16は、収集したリソース使用状況情報18に基づいて、全体CPU使用率、D信号処理スレッド用のCPU使用率、全体メモリ使用率、D信号処理スレッド用のメモリ使用率を算出し、それぞれの値が、閾値情報19に記憶された全体CPU使用率閾値、D信号処理スレッド用のCPU使用率閾値、全体メモリ使用率閾値、D信号処理スレッド用のメモリ使用率閾値を超えているか否かを判定し(S16)、Yesの場合はS17に進み、Noの場合はS17をスキップする。4への通知、および、リソースの追加(例えば処理サーバの追加)、の少なくともいずれかを実行する。0034分散処理を一時停止すれば、分散処理用のリソースがサービス処理用のリソースを圧迫する事態を直接的に回避できる。保守者端末4へ通知すれば、保守者が有効な対策を講じることができる。リソースを追加すれば、分散処理用のリソースの使用率を当然に下がるので、分散処理用のリソースがサービス処理用のリソースを圧迫する事態を回避できる。0035なお、分散処理を一時停止する場合は、その後、所定時間が経過したこと、あるいは、閾値を超えていた値が閾値以下になったこと、などの条件を満たしたときに、分散処理を再開すればよい。0036通知を受けた保守者端末4は、表示部31に閾値を超えた値に関する情報を表示する。保守者は、この表示を見ることで、対策を講じることができる。4への通知、および、リソースの追加、の少なくともいずれかを実行することで、分散処理の増大によるサービス処理の遅延を回避することができる。0038また、リソース使用状況情報18として、増大すればサービス処理の遅延に直接つながってしまう、分散処理に関するCPUまたはメモリの使用率の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。0039次に、リソース使用状況情報と閾値情報の他の例について説明する。図4(a)に示すように、リソース使用状況情報18aとして、分散処理を伴う信号(D信号)の単位時間当たりの処理数を用いることもできる。その場合、図4(b)に示すように、閾値情報19aとして、分散処理を伴う信号(D信号)の単位時間当たりの処理数の閾値を予め設定しておく。4への通知、および、リソースの追加、の少なくともいずれかを実行すればよい。0041これによれば、リソース使用状況情報として、増大すればサービス処理の遅延に直接つながってしまう、分散処理を伴う信号の単位時間当たりの処理数の情報を用いることで、分散処理の増大によるサービス処理の遅延をより確実に回避することができる。分散処理を一時停止する場合は、例えば、その後、単位時間が経過したときに、分散処理を再開すればよい。0042以上で本実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。図2(b)に示した「50.0%」などの数字は一例であり、他の数字を採用してもよい。図20043また、図3のS15〜S17の処理を行うタイミングは、「定期的」に限定されず、例えば、リソース監視機能部16がスレッドIDの通知を所定回数受信する度など、他のタイミングであってもよい。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。