JP5884595B2

JP5884595B2 - メッセージ通信方法，メッセージ通信プログラムおよびコンピュータ

Info

Publication number: JP5884595B2
Application number: JP2012075661A
Authority: JP
Inventors: 博昭久保田; 良雄岩滝
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2012-03-29
Filing date: 2012-03-29
Publication date: 2016-03-15
Anticipated expiration: 2032-03-29
Also published as: JP2013206233A

Description

本発明は，コンピュータノード間において非同期にメッセージ通信を行うメッセージ通信方法，メッセージ通信プログラムおよびコンピュータノードに関するものである。

複数のコンピュータノード間で非同期に通信を行う技術として，メッセージキューなどのキュー領域を利用したメッセージ通信の技術がある。

この技術では，処理要求のメッセージを送信するアプリケーションプロセスが動作するコンピュータノードは，送信するメッセージをキュー領域に登録する。ここでは，便宜的に，処理要求のメッセージを送信するアプリケーションプロセスを送信アプリと呼び，送信アプリが動作するコンピュータノードを送信ノードと呼ぶ。メッセージの処理要求に応じた処理を実行するアプリケーションプロセスが動作するコンピュータノードは，キュー領域からメッセージを取り出し，メッセージの処理要求に応じた処理を実行する。ここでは，便宜的に，メッセージの処理要求に応じた処理を実行するアプリケーションプロセスを受信アプリと呼び，受信アプリが動作するコンピュータノードを受信ノードと呼ぶ。

送信ノードは，受信ノードが処理を実行可能な状態であるか否かにかかわらず，処理要求のメッセージを発行してキュー領域に登録しておくことができる。受信ノードは，処理が実行可能な状態になってから，キュー領域からメッセージを取得し，処理を実行することができる。この技術によって，コンピュータノード間での非同期のメッセージ通信が可能となる。

なお，複数のプロセス間で授受されるメッセージを，単一のメッセージキューを介して伝播し，該メッセージキューへのメッセージの格納履歴をログに記録する技術が知られている。また，現用プロセスに対するメッセージのみをメッセージキューから取り出して送信し，待機プロセスに対してはメッセージを送信しないメッセージキューイングの技術が知られている。

特開２００５−４３５６号公報特開２０１０−８６１３７号公報

従来，受信ノードの性能はシステム設計時に決定されており，受信ノードの性能に応じた受信アプリの実装が行われていた。この場合，受信ノードは，処理を実行する受信アプリが待機状態であれば，キュー領域からメッセージを取得して，円滑に処理を実行することができた。

近年，クラウドコンピューティングの発展もあって，多くのシステムに仮想化の技術が導入されている。仮想マシンシステムでは，物理マシン上で動作する各仮想マシンに割り当てるリソース量を，動的に変化させることが可能となる。

例えば，非同期のメッセージ通信を行うシステムにおいて，受信ノードが，リソースが動的に変化する仮想マシンで実現されているものとする。このとき，処理を実行する受信アプリが待機状態であっても，同じ物理マシン上で動作する他の仮想マシンの影響によって受信ノードのリソース量が動的に変化し，受信ノードがメッセージに応じた処理を円滑に実行するのに必要なリソース量を得られないというケースも発生する。この状況で受信ノードがメッセージを取得してしまうと，そのメッセージの処理が著しく遅延したり，そのメッセージの処理が不能となってしまうという問題が発生する。

非同期のメッセージ通信を行うシステムでは，メッセージを取得した受信ノードは，速やかに，かつ確実に処理を行うということが前提となっている。そのため，受信したメッセージの処理を速やかに実行できない受信ノードがあると，システム全体の運用が円滑に行われなくなる可能性がある。

一側面では，本発明は，非同期のメッセージ通信が行われるシステムにおいて，メッセージの受信側のコンピュータノードのリソース量が変化する場合でも，円滑なシステムの運用が可能となる技術を提供することを目的とする。

本発明の一態様として開示するメッセージ通信方法では，受け付けたメッセージの内容に応じた処理を実行する受信側アプリケーションプロセスが動作する仮想マシンであるコンピュータノードが，前記コンピュータノードの空きリソース量を，自仮想マシンのゲストＯＳまたは自仮想マシンを管理するホストＯＳから取得し，記憶部に記憶されたアプリケーションプロセスの管理情報から，処理の実行状態が待機状態である受信側アプリケーションプロセスについて，処理を実行する上で必要なリソース量を取得し，空きリソース量が必要なリソース量以上である場合に，待機状態である受信側アプリケーションプロセスに対するメッセージを取得すると判断し，待機状態である受信側アプリケーションプロセスに対するメッセージを，メッセージを記憶する記憶部から取得する処理を実行する。

１態様では，非同期のメッセージ通信が行われるシステムにおいて，メッセージの受信側のコンピュータノードのリソース量が変化する場合でも，円滑なシステムの運用が可能となる。

本実施の形態１によるコンピュータノード間でメッセージ通信を行うシステムの構成例を示す図である。本実施の形態１によるアプリ状況テーブルの例を示す図である。本実施の形態によるプロパティ情報の例を示す図である。本実施の形態によるノードを実現するコンピュータのハードウェア構成例を示す図である。本実施の形態１における送信ノードの送信アプリによる処理のフローチャートである。本実施の形態１における送信ノードのキューマネージャによる処理のフローチャートである。本実施の形態１における受信ノードの受信アプリによる処理のフローチャートである。本実施の形態１における受信ノードの受信制御部による処理のフローチャートである。本実施の形態１における受信ノードのキューマネージャによる処理のフローチャートである。本実施の形態２によるコンピュータノード間でメッセージ通信を行うシステムの構成例を示す図である。本実施の形態２における受信ノードの受信アプリによる処理のフローチャートである。本実施の形態２における受信ノードのアプリ稼働管理部による処理のフローチャートである。本実施の形態３によるコンピュータノード間でメッセージ通信を行うシステムの構成例を示す図である。本実施の形態３における送信ノードの送信アプリによる処理のフローチャートである。本実施例によるメッセージ通信を行うシステムを示す図である。

以下，本実施の形態について，図を用いて説明する。

〔実施の形態１〕
図１は，本実施の形態１によるコンピュータノード間でメッセージ通信を行うシステムの構成例を示す図である。

図１に示すシステムにおいて，送信ノード１００，受信ノード２００は，コンピュータノードである。以下では，コンピュータノードを，単にノードとも呼ぶ。図１に示すシステムの例では，２つのノードのみが示されているが，システムにはさらに多数のノードが存在してもよい。図１に示す送信ノード１００と受信ノード２００との間では，キュー領域３００を介した非同期のメッセージ通信が行われる。各ノードやキュー領域３００は，例えばＩＰ（Internet Protocol ）ネットワークなどのネットワーク（図示省略）に接続されている。

送信ノード１００は，メッセージの送信側となるノードである。受信ノード２００は，メッセージの受信側となるノードである。なお，本実施の形態に示す例において，送信ノード１００と受信ノード２００は，便宜的に表したものであり，常にメッセージを送信する送信ノード１００と，常にメッセージを受信する受信ノード２００が存在していることを表したものではない。すなわち，システムが有する各ノードは，メッセージの送信側となる場合には送信ノード１００となり，メッセージの受信側となる場合には受信ノード２００となる。

本実施の形態では，送信ノード１００と受信ノード２００は，それぞれ，物理的なコンピュータマシンで実現されてもよいし，仮想的なコンピュータマシンで実現されてもよい。以下では，物理的なコンピュータマシンを物理マシン，仮想的なコンピュータマシンを仮想マシンと呼ぶ。なお，本実施の形態の技術は，受信ノード２００がリソース量が動的に変化する仮想マシンで実現される場合に，より高い効果が得られる。ただし，受信ノード２００が物理マシンである場合でも，例えば障害の発生によりリソース量が減少してしまうというケースも考えられるので，限定的ではあるが，本実施の形態の技術による効果は得られる。

図１に示す例では，受信ノード２００は，仮想マシンで実現されている。物理マシン１０は，受信ノード２００を含む仮想マシンを実現する物理的なコンピュータマシンである。図１に示す物理マシン１０上では，受信ノード２００以外にも，複数の仮想マシン３０が動作している。受信ノード２００を含む各仮想マシン３０は，物理マシン１０のリソースを利用して動作する。ホストＯＳ（Operating System）／ハイパーバイザ２０は，物理マシン１０のリソース管理や，受信ノード２００を含む各仮想マシン３０の管理・制御を行う。ゲストＯＳ２０１は，仮想マシンである受信ノード２００のＯＳである。同様に，ゲストＯＳ３１は，仮想マシン３０のＯＳである。

図１に示す例では，ホストＯＳ／ハイパーバイザ２０によって，物理マシン１０上で動作する受信ノード２００を含む各仮想マシン３０へのリソースの割り当てが，受信ノード２００を含む各仮想マシン３０の稼働状況に応じて動的に変更されるものとする。すなわち，受信ノード２００が使用するリソースの量は，時間的に変動する。

なお，クラウドコンピューティングなどの技術では，１つの物理マシンを複数のテナントで利用するマルチテナント環境が導入される場合がある。マルチテナント環境では，例えば，図１に示す物理マシン１０上で動作する受信ノード２００と他の仮想マシン３０とが，それぞれ異なるテナントが利用するマシンとなる場合がある。このような環境では，他のテナントの仮想マシン３０との兼ね合いもあり，受信ノード２００は，望む量のリソースを常時得られるわけではない。

キュー領域３００は，送信ノードと受信ノードとの間での非同期のメッセージ通信を実現するために，メッセージを一時的に記憶するメッセージ記憶部の一例である。本実施の形態の例では，キュー領域３００は，原則としてＦＩＦＯ（First In First Out）でメッセージを出し入れするメッセージキューであるものとする。メッセージごとに優先度を設定して，キュー領域３００への登録順が遅いが優先度が高いメッセージがある場合に，そのメッセージを先にキュー領域３００から取り出すように，システムを設計してもよい。なお，送信ノード１００と受信ノード２００との間での非同期のメッセージ通信を実現するためのメッセージ記憶部が，必ずしもキューである必要はない。

また，キュー領域３００の設計において，宛先となるアプリケーションプロセスごとにメッセージを管理するキューを用意してもよいし，異なる複数のアプリケーションプロセスに対するメッセージを一元的に管理するキューを用意してもよい。本実施の形態の例におけるキュー領域３００では，異なる複数のアプリケーションプロセスに対するメッセージが一元的に管理されているものとする。

本実施の形態のキュー領域３００を実現する方法としては，様々な方法が考えられる。例えば，専用に用意されたノードで，キュー領域３００を実現する方法が考えられる。また，システムが有する各ノードが共通にアクセス可能なストレージで，キュー領域３００を実現することも可能である。

送信ノード１００は，送信アプリ１１０，キューマネージャ１２０を備える。受信ノード２００は，受信アプリ２１０，キューマネージャ２２０，受信制御部２３０，アプリ状況テーブル記憶部２４０を備える。

送信ノード１００の送信アプリ１１０は，受信ノード２００の受信アプリ２１０に対する処理要求のメッセージを送信する側のアプリケーションプロセスである。送信ノード１００が送信するメッセージは，送信アプリ１１０により発行されるメッセージとなる。

これに対して，受信ノード２００の受信アプリ２１０は，送信ノード１００の送信アプリ１１０からのメッセージを受信する側のアプリケーションプロセスである。受信アプリ２１０は，受け付けたメッセージの内容に応じた処理を実行する。受信ノード２００が受信するメッセージは，受信アプリ２１０が受け付けるメッセージとなる。

受信ノード２００では，複数の受信アプリ２１０が動作可能である。図１に示す例では，受信ノード２００で，３つの受信アプリ２１０ａ〜ｃが動作している。なお，受信ノード２００では，動的に必要な受信アプリ２１０が新規に起動され，不要な受信アプリ２１０が削除されることにより，リソース活用の効率化が図られている。

なお，本実施の形態では，複数の受信ノード２００での分散処理が行われているものとする。例えば，図１に示す受信ノード２００で動作する受信アプリ２１０ａと同じアプリケーションのプロセスが，図示省略された他の受信ノード２００でも動作しており，処理を実行可能な受信ノード２００がキュー領域３００からメッセージを取得して，処理を実行するものとする。

キューマネージャ１２０（または２２０）は，各ノードに実装される，キュー領域３００に対するメッセージの送受信を制御する機構である。ノードが送信ノード１００となる場合には，キューマネージャ１２０は，キュー領域３００にメッセージを送信して登録するメッセージ登録部となる。ノードが受信ノード２００となる場合には，キューマネージャ２２０は，キュー領域３００からメッセージを取得して受信するメッセージ取得部となる。キューマネージャ１２０（または２２０）は，例えば，クラスライブラリとして実装される。

受信制御部２３０は，受信ノード２００において，キュー領域３００からメッセージを受信するタイミングを制御する。より具体的には，受信制御部２３０は，受信ノード２００の空きリソース量を取得する。また，受信制御部２３０は，後述のアプリ状況テーブル記憶部２４０から，処理の実行状態が待機状態である受信アプリ２１０について，該受信アプリ２１０が１処理を実行する上で必要なリソース量を取得する。受信制御部２３０は，空きリソース量が必要なリソース量以上である場合に，該待機状態である受信アプリ２１０に対するメッセージを取得すると判断する。逆に，受信制御部２３０は，空きリソース量が必要なリソース量に満たない場合に，該待機状態である受信アプリ２１０に対するメッセージを取得しないと判断する。受信制御部２３０は，キューマネージャ２２０に，取得すると判断した受信アプリ２１０に対するメッセージの取得を依頼する。このとき，キューマネージャ２２０は，メッセージ取得部として動作し，受信制御部２３０から依頼された受信アプリ２１０に対するメッセージを，キュー領域３００から取得する。

なお，受信制御部２３０は，受信ノード２００の空きリソース量を，例えば，該受信ノード２００のＯＳから取得する。図１に示すように，受信ノード２００が仮想マシンである場合には，仮想マシンである該受信ノード２００のゲストＯＳ２０１，または仮想マシンである該受信ノード２００を管理するホストＯＳ／ハイパーバイザ２０から取得する。受信制御部２３０が，受信ノード２００の空きリソース量をゲストＯＳ２０１から取得するのか，ホストＯＳ／ハイパーバイザ２０から取得するのかは，受信ノード２００の環境に応じた任意の設計が可能である。

ゲストＯＳ２０１は，物理マシン１０のリソース状況を把握していないので，受信ノード２００に割り当てられる空きリソース量を，必ずしも正確に判断できるわけではない。例えば，上述のクラウドコンピューティングにおけるマルチテナント環境などでは，他のテナントの仮想マシン３０と競合するため，ゲストＯＳ２０１が要求するだけのリソース量が得られない場合もある。

これに対して，物理マシン１０のリソース管理を行うホストＯＳ／ハイパーバイザ２０は，物理マシン１０のリソース状況を把握しているので，受信ノード２００に割り当てられる空きリソース量を，正確に判断することができる。ホストＯＳ／ハイパーバイザ２０から受信ノード２００の空きリソース量の情報を得ることができる場合には，受信制御部２３０は，正確な受信ノード２００の空きリソース量を取得可能となる。

しかし，上述のクラウドコンピューティングにおけるマルチテナント環境などでは，ホストＯＳ／ハイパーバイザ２０が，必ずしも自テナントのものとはならない。このような環境では，受信制御部２３０は，ホストＯＳ／ハイパーバイザ２０から，受信ノード２００の空きリソース量の情報を得ることができない場合もある。このようなケースでも，受信制御部２３０は，ゲストＯＳ２０１からは，受信ノード２００の空きリソース量の情報を取得できる。

アプリ状況テーブル記憶部２４０は，受信ノード２００で動作する受信アプリ２１０を管理するアプリ状況テーブルを記憶する記憶部である。アプリ状況テーブル記憶部２４０は，アプリケーションプロセスの管理情報を記憶する管理情報記憶部の一例である。

図２は，本実施の形態１によるアプリ状況テーブルの例を示す図である。

図２に示すアプリ状況テーブル２４５は，図１に示す受信ノード２００のアプリ状況テーブル記憶部２４０に記憶されるアプリ状況テーブルの一例である。図２に示すアプリ状況テーブル２４５は，受信ノード２００で動作する受信アプリ２１０のそれぞれに対応するレコードごとに，アプリＩＤ，必要リソース，アプリ状態の情報を持つ。

図２に示すアプリ状況テーブル２４５において，アプリＩＤは，該当レコードの受信アプリ２１０のアプリケーションを識別する識別情報である。図２に示すアプリ状況テーブル２４５において，例えば，“ａｐｐ＃０１”は，受信アプリ２１０ａのアプリケーションの識別情報であり，“ａｐｐ＃０２”は，受信アプリ２１０ｂのアプリケーションの識別情報であり，“ａｐｐ＃０３”は，受信アプリ２１０ｃのアプリケーションの識別情報であるものとする。

本実施の形態では，送信ノード１００の送信アプリ１１０は，処理を依頼する相手先のアプリＩＤを指定して，メッセージを送る。受信ノード２００では，処理を実行可能であると判断した受信アプリ２１０がある場合に，該当受信アプリ２１０に対応するメッセージをアプリＩＤで識別して，キュー領域３００から取得する。例えば，複数の受信ノード２００で分散処理が行われる場合，受信ノード２００が異なっても，同じアプリケーションの受信アプリ２１０には，同じアプリＩＤが与えられるものとする。すなわち，送信ノード１００から送信されてキュー領域３００に格納されたメッセージは，該メッセージの宛先となるアプリＩＤの受信アプリ２１０が動作する受信ノード２００であれば，どの受信ノード２００が受信してもよい。

図２に示すアプリ状況テーブル２４５において，必要リソースは，該当レコードの受信アプリ２１０が１処理を行うのに必要なリソースの情報である。図２に示すアプリ状況テーブル２４５の例では，各受信アプリ２１０に必要なリソースの情報として，ＣＰＵ（Central Processing Unit ）コア数，メモリ量，ネットワーク帯域量，ハードディスク容量の情報が記録されている。

図２に示すアプリ状況テーブル２４５において，アプリ状態は，該当レコードの受信アプリ２１０による処理の実行状態を示す。図２に示すアプリ状況テーブル２４５の例において，アプリ状態の“待機”は，該当受信アプリ２１０が，処理要求のメッセージを待っている待機状態を示す。また，アプリ状態の“稼働”は，該当受信アプリ２１０が，処理要求のメッセージを受け付けて，該メッセージの内容に応じた処理を実行している稼働状態を示す。

本実施の形態１では，各受信アプリ２１０が，アプリ状況テーブル２４５に対して，自身の情報を記録・更新するものとする。例えば，受信アプリ２１０は，起動時に，アプリ状況テーブル２４５に自身の情報を記録するレコードを生成し，該レコードに自身のアプリＩＤと必要リソースとを登録する。このとき，受信アプリ２１０は，アプリ状況テーブル２４５において，自身のアプリ状態を“待機”に設定する。受け付けたメッセージの内容に応じた処理を実行する際には，受信アプリ２１０は，アプリ状況テーブル２４５において，自身のアプリ状態を“稼働”に更新する。受け付けたメッセージの内容に応じた処理を終了する際には，受信アプリ２１０は，アプリ状況テーブル２４５において，自身のアプリ状態を“待機”に更新する。

受信アプリ２１０が起動時にアプリ状況テーブル２４５に登録するアプリＩＤや必要リソースなどの情報は，例えば受信アプリ２１０のアプリケーションプログラムに組み込まれていてもよいし，アプリケーションプログラムとは別に用意されたプロパティ情報に設定されていてもよい。

図３は，本実施の形態によるプロパティ情報の例を示す図である。

図３に示すプロパティ情報２０５は，受信アプリ２１０のアプリＩＤや必要リソースなどの情報が設定されたプロパティ情報の一例である。例えば，図３（Ａ）は，図１に示す受信アプリ２１０ａについてのプロパティ情報２０５ａである。また，図３（Ｂ）は，図１に示す受信アプリ２１０ｂについてのプロパティ情報２０５ｂである。また，図３（Ｃ）は，図１に示す受信アプリ２１０ｃについてのプロパティ情報２０５ｃである。

図３に示すプロパティ情報２０５は，例えばそれぞれが１つのファイルとして，図１では図示省略された記憶部に記憶されている。本実施の形態１において，各受信アプリ２１０は，例えば，起動時に自身のプロパティ情報２０５のファイルにアクセスし，自身のアプリＩＤ，必要リソース等の情報を取得する。

図４は，本実施の形態によるノードを実現するコンピュータのハードウェア構成例を示す図である。

図１に示す本実施の形態の送信ノード１００や受信ノード２００を実現する物理的なコンピュータ１は，例えば，ＣＰＵ２，主記憶となるメモリ３，記憶装置４，通信装置５，媒体読取・書込装置６，入力装置７，出力装置８等を備える。記憶装置４は，例えばＨＤＤ（Hard Disk Drive ）等の外部記憶装置や，補助記憶装置などである。媒体読取・書込装置６は，例えばＣＤ−Ｒ（Compact Disc Recordable ）ドライブやＤＶＤ−Ｒ（Digital Versatile Disc Recordable ）ドライブなどである。入力装置７は，例えばキーボード・マウスなどである。出力装置８は，例えばディスプレイ等の表示装置などである。

図１に示す送信ノード１００や受信ノード２００およびそれらのノードが備える各機能部は，コンピュータ１が備えるＣＰＵ２，メモリ３等のハードウェアと，ソフトウェアプログラムとによって実現することが可能である。コンピュータ１が実行可能なプログラムは，記憶装置４に記憶され，その実行時にメモリ３に読み出され，ＣＰＵ２により実行される。

コンピュータ１は，可搬型記録媒体から直接プログラムを読み取り，そのプログラムに従った処理を実行することもできる。また，コンピュータ１は，サーバコンピュータからプログラムが転送されるごとに，逐次，受け取ったプログラムに従った処理を実行することもできる。さらに，このプログラムは，コンピュータ１で読み取り可能な記録媒体に記録しておくことができる。

以下，図５〜図９に示すフローチャートを用いて，本実施の形態１の送信ノード１００および受信ノード２００によるメッセージ通信に関する処理の流れの例を説明する。

図５は，本実施の形態１における送信ノードの送信アプリによる処理のフローチャートである。

送信ノード１００において，送信アプリ１１０は，受信アプリ２１０に対して処理要求を行うメッセージに，メタ情報を付与する（ステップＳ１０）。ここでメッセージに付与するメタ情報としては，宛先の受信アプリ２１０のアプリＩＤ，優先度，自送信アプリ１１０のＩＤなどの例が挙げられる。本実施の形態１の例では，メッセージに宛先のアプリＩＤを付与するものとする。例えば，図１に示す受信アプリ２１０ａを宛先とする場合，送信アプリ１１０は，宛先のアプリＩＤとして“ａｐｐ＃０１”を付与する。送信アプリ１１０は，キューマネージャ１２０に対して，メッセージの送信を依頼する（ステップＳ１１）。

図６は，本実施の形態１における送信ノードのキューマネージャによる処理のフローチャートである。

送信ノード１００において，キューマネージャ１２０は，送信アプリ１１０からメタ情報が付与されたメッセージの送信依頼を受け付けると（ステップＳ２０），送信アプリ１１０から受け付けたメタ情報が付与されたメッセージに，さらにタイムスタンプを付与する（ステップＳ２１）。キューマネージャ１２０は，タイムスタンプとメタ情報とが付与されたメッセージを，キュー領域３００に登録する（ステップＳ２２）。本実施の形態１の例では，タイムスタンプと宛先のアプリＩＤとが付与されたメッセージが，キュー領域３００に格納される。なお，キュー領域３００へのメッセージの登録は，エンキューとも呼ばれる。

図７は，本実施の形態１における受信ノードの受信アプリによる処理のフローチャートである。

受信ノード２００において，受信アプリ２１０は，起動の際に，アプリ状況テーブル２４５に，自身のレコードを追加する（ステップＳ３０）。受信アプリ２１０は，アプリ状況テーブル２４５における自身のレコードに，自身のアプリＩＤと，自身が１処理を実行するのに必要なリソース量を登録する（ステップＳ３１）。例えば，図１に示す受信アプリ２１０ａが起動する際に，受信アプリ２１０ａは，図３（Ａ）に示すプロパティ情報２０５ａのファイルから自身のアプリＩＤと必要リソースの情報を取得し，その情報をアプリ状況テーブル２４５における自身のレコードに記録する。受信アプリ２１０は，アプリ状況テーブル２４５における自身のレコードのアプリ状態を，待機状態を示す“待機”に設定する（ステップＳ３２）。

受信アプリ２１０は，送信アプリ１１０からのメッセージを受け付けると（ステップＳ３３のＹＥＳ），アプリ状況テーブル２４５における自身のレコードのアプリ状態を，稼働状態を示す“稼働”に更新する（ステップＳ３４）。受信アプリ２１０は，受け付けたメッセージの内容に従って処理を実行する（ステップＳ３５）。

受信アプリ２１０は，メッセージに応じた処理が終了すると，アプリ状況テーブル２４５における自身のレコードのアプリ状態を，待機状態を示す“待機”に更新する（ステップＳ３４）。受信アプリ２１０は，ステップＳ３３の処理に戻って，次のメッセージを待つ。

なお，図７のフローチャートには示されていないが，受信アプリ２１０は，受信ノード２００から削除される際に，アプリ状況テーブル２４５における自身のレコードを削除する。

図８は，本実施の形態１における受信ノードの受信制御部による処理のフローチャートである。

受信ノード２００において，受信制御部２３０は，定期的にアプリ状況テーブル２４５を参照し，アプリ状態が“待機”状態である受信アプリ２１０の存在をチェックする（ステップＳ４０）。

“待機”状態である受信アプリ２１０がある場合には（ステップＳ４０のＹＥＳ），受信制御部２３０は，“待機”状態である受信アプリ２１０を順に１つ選択する（ステップＳ４１）。“待機”状態である受信アプリ２１０が複数存在する場合には，受信制御部２３０は，例えば優先度を用いた特定の優先制御や，ラウンドロビンを用いた制御などにより，順に処理対象の受信アプリ２１０を選択する。“待機”状態である受信アプリ２１０が１つしかない場合には，受信制御部２３０は，その受信アプリ２１０を選択する。

受信制御部２３０は，アプリ状況テーブル２４５から，該当受信アプリ２１０の必要リソースの情報を取得する（ステップＳ４２）。また，受信制御部２３０は，ゲストＯＳ２０１またはホストＯＳ／ハイパーバイザ２０から，自受信ノード２００の空きリソースの情報を取得する（ステップＳ４３）。なお，受信ノード２００の空きリソースの情報をゲストＯＳ２０１から取得するか，ホストＯＳ／ハイパーバイザ２０から取得するかは，設計による。

受信制御部２３０は，該当受信アプリ２１０の必要リソース以上の受信ノード２００の空きリソースがあるかを判定する（ステップＳ４４）。必要リソース以上の空きリソースがなければ（ステップＳ４４のＮＯ），受信制御部２３０は，該当受信アプリ２１０に対するメッセージを取得しないと判断し，ステップＳ４８の処理に進む。例えば，受信制御部２３０は，ＣＰＵコア数，メモリ量，ネットワーク帯域量，ハードディスク容量の各項目について比較を行う場合に，空きリソースの方が必要リソースよりも値が小さい項目が１つでもあれば，必要リソース以上の空きリソースがないと判定する。

必要リソース以上の空きリソースがあれば（ステップＳ４４のＹＥＳ），受信制御部２３０は，該当受信アプリ２１０に対するメッセージを取得すると判断する。例えば，受信制御部２３０は，ＣＰＵコア数，メモリ量，ネットワーク帯域量，ハードディスク容量の各項目について比較を行う場合に，すべての項目で空きリソースの方が必要リソースよりも値が大きければ，必要リソース以上の空きリソースがあると判定する。

このとき，受信制御部２３０は，該当受信アプリ２１０のアプリＩＤを指定して，キューマネージャ２２０に，該当受信アプリ２１０に対するメッセージの受信を依頼する（ステップＳ４５）。受信制御部２３０は，キューマネージャ２２０から該当受信アプリ２１０に対するメッセージを取得すると（ステップＳ４６），取得したメッセージを該当受信アプリ２１０に渡す（ステップＳ４７）。該当受信アプリ２１０では，受信制御部２３０から渡されたメッセージの内容に従った処理が実行される。

受信制御部２３０は，すべての“待機”状態の受信アプリ２１０について処理が終了したかを判定する（ステップＳ４８）。まだすべての“待機”状態の受信アプリ２１０について処理が終了していなければ（ステップＳ４８のＮＯ），受信制御部２３０は，ステップＳ４１の処理に戻って，次の“待機”状態の受信アプリ２１０の処理に移る。すべての“待機”状態の受信アプリ２１０について処理が終了していれば（ステップＳ４８のＹＥＳ），受信制御部２３０は，ステップＳ４０の処理に戻って，次のアプリ状況テーブル２４５のチェックタイミングを待つ。

図９は，本実施の形態１における受信ノードのキューマネージャによる処理のフローチャートである。

受信ノード２００において，キューマネージャ２２０は，受信制御部２３０からメッセージの受信依頼を受け付けると（ステップＳ５０），指定されたアプリＩＤを検索キーに，キュー領域３００のメッセージを検索する（ステップＳ５１）。例えば，キューマネージャ２２０は，キュー領域３００からメッセージをＦＩＦＯで取り出せるように，付与されたタイムスタンプが古い順に，付与された宛先のアプリＩＤが検索キーのアプリＩＤと一致するメッセージを検索する。なお，メッセージに優先度の情報が付されている場合に，優先度が高いメッセージを優先的に検索するなどの設計は，任意である。指定されたアプリＩＤを宛先としたメッセージがキュー領域３００になければ（ステップＳ５２のＮＯ），キューマネージャ２２０は，ステップＳ５１の処理に戻り，次の検索のタイミングを待つ。

指定されたアプリＩＤを宛先としたメッセージがキュー領域３００にあれば（ステップＳ５２のＹＥＳ），キューマネージャ２２０は，他の受信ノード２００とメッセージの取り出し処理が輻輳しないように，対象のメッセージをレコードロックして（ステップＳ５３），排他制御する。キューマネージャ２２０は，キュー領域３００から，対象のメッセージを取り出す（ステップＳ５４）。なお，キュー領域３００からのメッセージの取り出しは，デキューとも呼ばれる。キューマネージャ２２０は，取り出したメッセージを，受信制御部２３０に応答する（ステップＳ５５）。キューマネージャ２２０は，取り出したメッセージを，キュー領域３００から削除する（ステップＳ５６）。

ここまで説明したように，本実施の形態１の受信ノード２００における受信制御部２３０は，待機状態の受信アプリ２１０があっても，自受信ノード２００のリソースに十分な空きがなければ，該当受信アプリ２１０に対するメッセージを取得しないように制御を行う。受信制御部２３０は，その時点で，待機状態の受信アプリ２１０が１処理を実行するのに必要な空きリソースがあると判断できる場合にのみ，メッセージを取得する制御を行う。

すなわち，本実施の形態１による受信ノード２００は，リソース量が動的に変化する場合でも，その時その時で，十分に処理実行可能なメッセージのみをキュー領域３００から取得して処理を行う。そのため，受信ノード２００において，待機状態の受信アプリ２１０があるゆえにキュー領域からメッセージを取得してしまい，リソース量が変化したためにリソース不足によって適切に処理が実行できなくなってしまう，といった状況を回避できる。

これにより，例えば，リソース量が動的に変化する複数の受信ノード２００によって分散処理が行われるようなシステムにおいて，その時点で真に処理実行可能な受信ノード２００のみが，キュー領域３００からメッセージを取得して処理を行うので，円滑なシステムの運用が可能となる。

〔実施の形態２〕
図１０は，本実施の形態２によるコンピュータノード間でメッセージ通信を行うシステムの構成例を示す図である。

図１０に示す本実施の形態２によるシステムの構成では，受信ノード２００’の構成が，図１に示す受信ノード２００の構成に，アプリ稼働管理部２５０が加えられたものとなっている。その他の構成については，図１に示す実施の形態１によるシステムの構成と同様である。以下では，本実施の形態２について，上述の実施の形態１と異なる部分を中心に説明を行い，上述の実施の形態１と同様の部分については説明を省略する。

上述の実施の形態１では，各受信アプリ２１０が，自身のプロパティ情報や自身の処理の実行状態を，アプリ状況テーブル記憶部２４０のアプリ状況テーブル２４５に記録していた。本実施の形態２では，アプリ稼働管理部２５０が，各受信アプリ２１０のプロパティ情報や処理の実行状態を，アプリ状況テーブル記憶部２４０のアプリ状況テーブル２４５に記録する。

なお，本実施の形態２では，受信ノード２００’で動作する各受信アプリ２１０は，自身のプロパティ情報や自身の処理の実行状態をアプリ状況テーブル２４５に記録する処理を行わない。

図１１は，本実施の形態２における受信ノードの受信アプリによる処理のフローチャートである。

受信ノード２００’において，受信アプリ２１０は，起動後，送信アプリ１１０からのメッセージの受け付けを待つ（ステップＳ６０）。受信アプリ２１０は，送信アプリ１１０からのメッセージを受け付けると（ステップＳ６０のＹＥＳ），受信アプリ２１０は，受け付けたメッセージの内容に従って処理を実行する（ステップＳ６１）。受信アプリ２１０は，メッセージに応じた処理が終了すると，ステップＳ６０の処理に戻って，次のメッセージの受け付けを待つ。

このように，本実施の形態２の受信ノード２００’で動作する各受信アプリ２１０は，本実施の形態によるメッセージ通信の技術の導入に関係なく，既存の受信アプリと同様の処理を行う。

受信ノード２００’が備えるアプリ稼働管理部２５０は，受信ノード２００’で動作する各受信アプリ２１０の動作を監視する機能部である。受信ノード２００’の起動時において，アプリ稼働管理部２５０は，各受信アプリ２１０より先に起動される。

図１２は，本実施の形態２における受信ノードのアプリ稼働管理部による処理のフローチャートである。

受信ノード２００’において，アプリ稼働管理部２５０は，受信アプリ２１０の起動を検知すると（ステップＳ７０のＹＥＳ），アプリ状況テーブル２４５に，該受信アプリ２１０の情報を記録するレコードを生成する（ステップＳ７１）。アプリ稼働管理部２５０は，例えば図３に示すプロパティ情報２０５のファイルから，起動された受信アプリ２１０のアプリＩＤと必要リソースとを読み出す（ステップＳ７２）。アプリ稼働管理部２５０は，読み出したアプリＩＤと必要リソースとを，アプリ状況テーブル２４５の該当レコードに登録する（ステップＳ７３）。アプリ稼働管理部２５０は，アプリ状況テーブル２４５において，起動された受信アプリ２１０のアプリ状態を“待機”に設定する（ステップＳ７４）。

アプリ稼働管理部２５０は，受信アプリ２１０の削除を検知すると（ステップＳ７５のＹＥＳ），アプリ状況テーブル２４５から，削除された受信アプリ２１０のレコードを削除する（ステップＳ７６）。

アプリ稼働管理部２５０は，受信アプリ２１０がメッセージを受け付けたことを検知すると（ステップＳ７７のＹＥＳ），アプリ状況テーブル２４５において，該当受信アプリ２１０のアプリ状態を“稼働”に更新する（ステップＳ７８）。

アプリ稼働管理部２５０は，受信アプリ２１０がメッセージに応じた処理を終了したことを検知すると（ステップＳ７９のＹＥＳ），アプリ状況テーブル２４５において，該当受信アプリ２１０のアプリ状態を“待機”に更新する（ステップＳ８０）。

ここまで説明したように，本実施の形態２の受信ノード２００’におけるアプリ稼働管理部２５０は，受信ノード２００’で動作する各受信アプリ２１０の処理の実行状態を，まとめて管理する。これにより，本実施の形態によるメッセージ通信の技術の導入にあたって，既存の受信アプリのプログラムを書き換えずに使用可能となる。

〔実施の形態３〕
図１３は，本実施の形態３によるコンピュータノード間でメッセージ通信を行うシステムの構成例を示す図である。

図１３に示す本実施の形態３によるシステムの構成では，受信ノード２００”の構成が，図１に示す受信ノード２００の構成から，アプリ状況テーブル記憶部２４０が削除されたものとなっている。代わりに，アプリ状況テーブル記憶部４００が，受信ノード２００”の外部に設けられている。その他の構成については，図１に示す実施の形態１によるシステムの構成と同様である。以下では，本実施の形態３について，上述の実施の形態１と異なる部分を中心に説明を行い，上述の実施の形態１と同様の部分については説明を省略する。

アプリ状況テーブル記憶部４００は，複数の受信ノード２００”で動作する受信アプリ２１０を一括で管理するアプリ状況テーブルを記憶する記憶部である。本実施の形態３のアプリ状況テーブル記憶部４００を実現する方法としては，キュー領域３００と同様に，様々な方法が考えられる。例えば，システムが備えるいずれかのノードで，アプリ状況テーブル記憶部４００を実現する方法が考えられる。また，システムが有する各ノードが共通にアクセス可能なストレージで，アプリ状況テーブル記憶部４００を実現することも可能である。

アプリ状況テーブル記憶部４００に記憶されるアプリ状況テーブルの構成としては，例えば，図２に示すアプリ状況テーブル２４５に，受信ノード２００”を識別するノードＩＤを加えたものとなる。アプリ状況テーブル記憶部４００では，例えば，受信ノード２００”ごとに，アプリ状況テーブルが管理される。

受信ノード２００”において，受信アプリ２１０は，自身のプロパティ情報や処理の実行状態をアプリ状況テーブルに記録する際に，自受信ノード２００”のノードＩＤでアプリ状況テーブル記憶部４００にアクセスし，情報の記録・更新を行う。また，受信制御部２３０は，自受信ノード２００”の受信アプリ２１０の情報を取得する際に，自受信ノード２００”のノードＩＤでアプリ状況テーブル記憶部４００にアクセスし，情報の取得を行う。

なお，アプリ状況テーブルの情報を受信ノード２００”内部と，外部のアプリ状況テーブル記憶部４００とに分けて管理する実施も可能である。例えば，アプリ状況テーブルの情報のうち，各受信アプリ２１０の必要リソースの情報を受信ノード２００”内部で管理し，各受信アプリ２１０の処理の実行状態のみを外部のアプリ状況テーブル記憶部４００で管理するようにしてもよい。

本実施の形態３において，送信ノード１００の送信アプリ１１０は，アプリ状況テーブル記憶部４００のアプリ状況テーブルを参照し，システム内に待機状態の受信アプリ２１０が存在するかを確認する。送信アプリ１１０は，システム内に待機状態の受信アプリ２１０が存在する場合に，キューマネージャ１２０にメッセージの送信を依頼する。

図１４は，本実施の形態３における送信ノードの送信アプリによる処理のフローチャートである。

送信ノード１００において，送信アプリ１１０は，受信アプリ２１０に対して処理要求のメッセージを送る際に，該当受信アプリ２１０のアプリＩＤでアプリ状況テーブル記憶部４００のアプリ状況テーブルを参照する（ステップＳ９０）。

送信アプリ１１０は，システム内のいずれかの受信ノード２００”に，該当受信アプリ２１０が存在するかを判定する（ステップＳ９１）。システム内のいずれの受信ノード２００”にも該当受信アプリ２１０が存在しない場合には（ステップＳ９１のＮＯ），送信アプリ１１０は，ステップＳ９０の処理に戻って，次のタイミングを待つ。例えば，アプリ状況テーブル記憶部４００のアプリ状況テーブルに，該当受信アプリ２１０のアプリＩＤのレコードがない場合には，該当受信アプリ２１０は存在しないと判定される。受信ノード２００”において，受信アプリ２１０が動的に起動・削除される環境では，目的とする受信アプリ２１０がシステム内のいずれの受信ノード２００”にも存在しないことがあり得る。

システム内のいずれかの受信ノード２００”に該当受信アプリ２１０が存在する場合には（ステップＳ９１のＹＥＳ），送信アプリ１１０は，待機状態の該当受信アプリ２１０が存在するかを判定する（ステップＳ９２）。待機状態の該当受信アプリ２１０が存在しない場合には（ステップＳ９１のＮＯ），送信アプリ１１０は，ステップＳ９０の処理に戻って，次のタイミングを待つ。

待機状態の該当受信アプリ２１０が存在する場合には（ステップＳ９２のＹＥＳ），送信アプリ１１０は，受信アプリ２１０に対して処理要求を行うメッセージに，メタ情報を付与する（ステップＳ９３）。送信アプリ１１０は，キューマネージャ１２０に対して，メッセージの送信を依頼する（ステップＳ９４）。

ここまで説明したように，本実施の形態３の送信ノード１００における送信アプリ１１０は，アプリ状況テーブル記憶部４００のアプリ状況テーブルで，目的とする待機状態の受信アプリ２１０があるかを確認する。送信アプリ１１０は，目的とする待機状態の受信アプリ２１０がある場合にのみ，キューマネージャ１２０にメッセージの送信を依頼する。

すなわち，送信ノード１００は，受信ノード２００”がすぐには受信できないメッセージを，キュー領域３００に送信しないようになる。これにより，すぐに処理されないメッセージがキュー領域３００に滞留することでキュー領域３００が枯渇することを防止できる。

〔実施例〕
図１５は，本実施例によるメッセージ通信を行うシステムを示す図である。

図１５に示すシステムにおいて，送信ノード５００は，例えば図１に示す送信ノード１００に相当する。受信ノード６００，受信ノード７００は，例えば図１に示す受信ノード２００に相当する。受信ノード６００，受信ノード７００は，動的にリソース量が変化する仮想マシンであるものとする。キュー領域８００は，例えば図１に示すキュー領域３００に相当する。

受信ノード６００で動作する受信アプリ６１０ａと，受信ノード７００で動作する受信アプリ７１０ａは，それぞれが異なる受信ノードで動作する，同じアプリケーション（アプリＩＤ：“ａｐｐ＃ａ”）のプロセスであるものとする。また，受信ノード６００で動作する受信アプリ６１０ｂと，受信ノード７００で動作する受信アプリ７１０ｂは，それぞれが異なる受信ノードで動作する，同じアプリケーション（アプリＩＤ：“ａｐｐ＃ｂ”）のプロセスであるものとする。

ここで，送信ノード５００は，メッセージＭａ₁，メッセージＭａ₂，メッセージＭｂの順でメッセージを発行する。メッセージＭａ₁とメッセージＭａ₂の宛先のアプリＩＤは，“ａｐｐ＃ａ”であり，メッセージＭｂの宛先のアプリＩＤは，“ａｐｐ＃ｂ”であるものとする。図１５に示すように，キュー領域８００には，メッセージＭａ₁，メッセージＭａ₂，メッセージＭｂの順でメッセージが格納される。

この時点で，受信ノード６００の受信アプリ６１０ａ，６１０ｂ，および受信ノード７００の受信アプリ７１０ａ，７１０ｂは，すべて待機状態であるものとする。このタイミングで，受信ノード６００は，定期的な受信チェックを行い，受信アプリ６１０ａが待機状態であることを確認し，また受信アプリ６１０ａが処理を実行するのに十分な空きリソース量があることを確認する。受信ノード６００は，受信アプリ６１０ａのアプリＩＤ“ａｐｐ＃ａ”でキュー領域８００を検索し，メッセージＭａ₁を取得する。受信アプリ６１０ａは，メッセージＭａ₁の内容に応じた処理の実行を開始する。

次のタイミングで，受信ノード７００は，定期的な受信チェックを行い，受信アプリ７１０ａが待機状態であることを確認し，また受信アプリ７１０ａが処理を実行するのに十分な空きリソース量があることを確認する。受信ノード７００は，受信アプリ７１０ａのアプリＩＤ“ａｐｐ＃ａ”でキュー領域８００を検索し，メッセージＭａ₂を取得する。受信アプリ７１０ａは，メッセージＭａ₂の内容に応じた処理の実行を開始する。

次のタイミングで，受信ノード６００は，定期的な受信チェックを行い，受信アプリ６１０ｂが待機状態であることを確認する。ここで，ノードのリソース量が時間変化しないという前提であれば，通常，ノードのリソース量に応じたアプリケーションプロセスの実装が行われるので，アプリケーションプロセスの待機状態が確認できれば，メッセージを受信しても問題はない。従来であれば，この時点で，キュー領域８００から，受信アプリ６１０ｂに対応するメッセージＭｂが取得されていた。

しかし，受信ノード６００は割り当てられるリソース量が時間変化するので，ある時点で空きリソース量が十分であることが確認されて受信アプリ６１０ｂが起動されたとしても，別の時点では受信アプリ６１０ｂが処理を実行するのに十分な空きリソース量がないというケースが発生し得る。このタイミングでは，受信ノード６００に割り当てされるリソース量が減っていて，受信アプリ６１０ｂが処理を実行するのに十分な空きリソース量がないものとする。このとき，受信ノード６００は，受信アプリ６１０ｂに対するメッセージの受信を行わないと判断する。すなわち，受信ノード６００は，キュー領域８００にあるアプリＩＤ“ａｐｐ＃ｂ”のメッセージＭｂの取り出しを行わない。

次のタイミングで，受信ノード７００は，定期的な受信チェックを行い，受信アプリ７１０ｂが待機状態であることを確認する。また，受信ノード７００は，この時点での自身の空きリソース量が，受信アプリ７１０ｂが処理を実行するのに十分な量であることを確認する。受信ノード７００は，受信アプリ７１０ｂのアプリＩＤ“ａｐｐ＃ｂ”でキュー領域８００を検索し，メッセージＭｂを取得する。受信アプリ７１０ｂは，メッセージＭｂの内容に応じた処理の実行を開始する。

本実施例に示すように，ある時点において，十分なリソースがある受信ノード７００が存在するのに，リソース量が足りない受信ノード６００がメッセージＭｂを取得して処理が滞ってしまうといった問題の発生を防ぐことが可能となる。このように，上述の本実施の形態によるメッセージ通信の技術を用いれば，受信ノード６００，７００に割り当てられるリソース量が時間変動していても，その時点で処理を実行可能な受信ノード６００，７００のみがメッセージを取得するので，円滑なシステムの運用が可能となる。

以上，本実施の形態について説明したが，本発明はその主旨の範囲において種々の変形が可能であることは当然である。

１０物理マシン
２０ホストＯＳ／ハイパーバイザ
３０仮想マシン
３１ゲストＯＳ
１００送信ノード
１１０送信アプリ
１２０キューマネージャ
２００受信ノード
２０１ゲストＯＳ
２１０受信アプリ
２２０キューマネージャ
２３０受信制御部
２４０アプリ状況テーブル記憶部
２５０アプリ稼働管理部
３００キュー領域
４００アプリ状況テーブル記憶部

Claims

受け付けたメッセージの内容に応じた処理を実行する受信側アプリケーションプロセスが動作する仮想マシンであるコンピュータノードが，
前記コンピュータノードの空きリソース量を，自仮想マシンのゲストＯＳまたは自仮想マシンを管理するホストＯＳから取得し，
記憶部に記憶されたアプリケーションプロセスの管理情報から，処理の実行状態が待機状態である受信側アプリケーションプロセスについて，処理を実行する上で必要なリソース量を取得し，
前記空きリソース量が前記必要なリソース量以上である場合に，前記待機状態である受信側アプリケーションプロセスに対するメッセージを取得すると判断し，
前記待機状態である受信側アプリケーションプロセスに対するメッセージを，前記メッセージを記憶する記憶部から取得する処理を実行する
ことを特徴とするメッセージ通信方法。
前記コンピュータノードでは，さらに，
前記コンピュータノードで動作する受信側アプリケーションプロセスが，自身の処理の実行状態を，前記管理情報に記録する処理を実行する
ことを特徴とする請求項１に記載のメッセージ通信方法。
前記コンピュータノードでは，さらに，
前記コンピュータノードで動作する受信側アプリケーションプロセスの稼働を監視する機能部が，前記コンピュータノードで動作する受信側アプリケーションプロセスの処理の実行状態を，前記管理情報に記録する処理を実行する
ことを特徴とする請求項１に記載のメッセージ通信方法。
前記受信側アプリケーションプロセスに処理を要求するメッセージを送る送信側アプリケーションプロセスが動作するコンピュータノードが，
前記管理情報を参照し，処理の実行状態が待機状態である受信側アプリケーションプロセスが存在する場合に，該待機状態である受信側アプリケーションプロセスに対するメッセージを，前記メッセージを記憶する記憶部に登録する
ことを特徴とする請求項１から請求項３までのいずれか一項に記載のメッセージ通信方法。
受け付けたメッセージの内容に応じた処理を実行する受信側アプリケーションプロセスが動作する仮想マシンであるコンピュータノードに，
前記コンピュータノードの空きリソース量を，自仮想マシンのゲストＯＳまたは自仮想マシンを管理するコンピュータのホストＯＳから取得し，
記憶部に記憶されたアプリケーションプロセスの管理情報から，処理の実行状態が待機状態である受信側アプリケーションプロセスについて，処理を実行する上で必要なリソース量を取得し，
前記空きリソース量が前記必要なリソース量以上である場合に，前記待機状態である受信側アプリケーションプロセスに対するメッセージを取得すると判断し，
前記待機状態である受信側アプリケーションプロセスに対するメッセージを，前記メッセージを記憶する記憶部から取得する
処理を実行させるためのメッセージ通信プログラム。
受け付けたメッセージの内容に応じた処理を実行する受信側アプリケーションプロセスが動作する仮想マシンであるコンピュータノードを起動するコンピュータであって，
アプリケーションプロセスの管理情報を記憶する管理情報記憶部と，
前記コンピュータノードの空きリソース量を，前記コンピュータノードのゲストＯＳまたは前記コンピュータノードを管理する自コンピュータのホストＯＳから取得し，前記管理情報から，処理の実行状態が待機状態である受信側アプリケーションプロセスについて，処理を実行する上で必要なリソース量を取得し，取得した空きリソース量が取得した必要なリソース量以上である場合に，該待機状態である受信側アプリケーションプロセスに対するメッセージを取得すると判断する受信制御部と，
前記受信制御部がメッセージを取得すると判断した場合に，前記待機状態である受信側アプリケーションプロセスに対するメッセージを，メッセージ記憶部から取得するメッセージ取得部とを備える
ことを特徴とするコンピュータ。