JP2017113375A - 情報処理システム、及び情報処理プログラム - Google Patents

Abstract

【課題】柔軟なオートスケーリングを行う情報処理システムを提供する。【解決手段】複数のユーザ端末１５ａ〜１５ｃからのアクセスが可能であり、前記アクセスのあった複数のユーザ端末によるリアルタイムマルチプレイゲームを制御する情報処理システム１１であって、Ｌｏｂｂｙクラスタ２１ａ〜２１ｃ及びＧａｍｅクラスタ２２ａ〜２２ｄを含むリアルタイムクラスタ１１１と、Ｌｏｂｂｙロードバランサ及びＧａｍｅロードバランサを含むロードバランサ／オートスケーリングクラスタ１１２と、ＡＰＩサーバ２３と、Ｃａｃｈｅクラスタ２６とを有し、前記ＡＰＩサーバ及び前記Ｃａｃｈｅクラスタを介したＬｏｂｂｙノード及びｇａｍｅノード割当が実現される。【選択図】図２

Description

本発明は、広くネットワークを介してリアルタイムマルチプレイゲームを進行する情報処理システム及び情報処理プログラムに関し、より具体的には、オートスケーリング機能を有する情報処理システム及び情報処理プログラムに関する。

従来、ネットワークを介していわゆるリアルタイムマルチプレイが可能なゲームが数多く開発されてきた。その際、ネットワークを介して多くのユーザ端末からゲームサーバ（サーバ群）へのアクセスが発生するため、サーバへの負荷の監視及び負荷状況に応じたサーバ（サーバ群）のチューニングに関しても工夫がなされてきた。

また、近年、クラウドコンピューティングにおいては、仮想マシンやネットワークなどのインフラをサービスとして提供するＩａａＳ（Infrastructure as a Service）等のサービスを介し、システムのリソース消費率が一定以上になったときに、自動でスケールアウトを行うサービスも提供されている。ここで、クラウドコンピューティングにおいて、自動でシステムの拡張／縮小を行う技術は、一般にオートスケーリングと呼ばれている。

クラウド環境におけるオートスケーリングの一例として、需要変化に応答してサーバ規模を増減させるオートスケーリング機構を実現する情報処理システム等が提案されている（特許文献１）。

すわなち、特許文献１には、複数の処理サーバを含む処理サーバ群と、前記処理サーバ群に代替して応答するための代替サーバと、前記処理サーバ群の各処理サーバにトラフィックを分散するとともに、前記処理サーバ群が過負荷状態となった際に前記代替サーバにトラフィックを転送するロードバランサと、前記ロードバランサにより前記処理サーバ群へ転送される転送量と前記代替サーバへ転送される転送量とに応じて、前記処理サーバ群の目標規模を演算する目標規模演算部と、前記処理サーバ群の現在の規模から目標規模へ増強するため前記処理サーバ群の処理サーバを準備するサーバ準備部とを含む情報処理システムが開示されている。

特開２０１２−２０８７８１号公報

しかしながら、現時点で広く提供されているＩａａＳ等のサービスを利用しながらロードバランシングやオートスケーリングを効率よく行おうとすると、既存のパッケージやサービスとの相性が悪かったり、機能的な制限や限界等があったりして、システムとしての機能を十分に発揮できない場合があった。例えば、ロードバランサとプロキシとを２重運用するなどの冗長性を排除できずに運用コストが増大したり、どうしても手動による設定に頼らなければならない状況が発生したりするなどの課題があった。

また、情報処理システム及び情報処理プログラムの構成上の観点からは、一般的に、ロードバランサの監視下にプロキシサーバを配し、サーバとクライアントとの間のコネクションを確立した上で、ゲームやチャット等のアプリケーション処理を行うサーバ群（クラスタ）のバランシングが行われることが多い。かかる構成においても、プロキシサーバの下位に配されるサーバ群を自動的に増減させる制御の仕組みが求められるが、運用コストの高さや自動化技術のハードルの高さから、運用が見送られたり、手動管理を余儀なくされたりしており、更なる改善が期待されている。

そこで、本発明の一実施形態にかかる情報処理システムは、複数のユーザ端末からのアクセスが可能であり、前記アクセスのあった複数のユーザ端末によるリアルタイムマルチプレイゲームを制御する情報処理システムであって、
Ｌｏｂｂｙクラスタ及びＧａｍｅクラスタを含むリアルタイムクラスタと、
Ｌｏｂｂｙロードバランサ及びＧａｍｅロードバランサを含むロードバランサ／オートスケーリングクラスタと、
ＡＰＩサーバと、
Ｃａｃｈｅクラスタと
を有し、
（Ａ）前記リアルタイムマルチゲームの進行時には、
前記ロードバランサ／オートスケーリングクラスタから前記リアルタイムクラスタへの負荷監視が行われるとともに、前記負荷監視結果は前記Ｃａｃｈｅクラスタに保管及び更新され、
前記Ｃａｃｈｅクラスタと前記ＡＰＩとの間で前記負荷監視結果に基づいたデータ授受が行われ、
前記ロードバランサ／オートスケーリングクラスタから前記リアルタイムクラスタに対しては、前記負荷監視結果に基づくオートスケーリング処理が行われると共に、
（Ｂ）前記複数のユーザ端末からのアクセス要求時には、
前記アクセス要求を前記ＡＰＩサーバで受け付けると共に、前記ＡＰＩサーバは前記Ｃａｃｈｅクラスタとの間でＬｏｂｂｙノード割当調整を実施し、
前記ＡＰＩサーバは、前記Ｌｏｂｂｙノード割当調整の結果、決定されたＬｏｂｂｙノードを、前記アクセス要求を行ったユーザ端末に返送し、
前記アクセス要求を行ったユーザ端末は、前記決定されたＬｏｂｂｙノードに基づいて前記Ｌｏｂｂｙクラスタにおける所定のサーバにアクセスし、
前記所定のサーバは、マルチプレイのためのマッチング処理を行ってｒｏｏｍ＿ｉｄを決定すると共に当該ｒｏｏｍ＿ｉｄを、前記アクセス要求を行ったユーザ端末に返送し、
前記ＡＰＩサーバは、前記アクセス要求を行ったユーザ端末からの要求に応じて、前記Ｃａｃｈｅクラスタと前記アクセス要求を行ったユーザ端末が利用するためのｇａｍｅノードの割当調整を実施し、
前記ＡＰＩサーバは、前記ｇａｍｅノード割当調整の結果、決定されたｇａｍｅノードを、前記アクセス要求を行ったユーザ端末に返送し、
前記アクセス要求を行ったユーザ端末は、前記決定されたＬｏｂｂｙノード及びｇａｍｅノードに基づいて、前記リアルタイムマルチゲームを進行させる
ことにより、前記ＡＰＩサーバ及び前記Ｃａｃｈｅクラスタを介したＬｏｂｂｙノード及びｇａｍｅノード割当が実現されることを特徴とする。

また、前記負荷監視は、ｓｏｃｋｅｔ．ｉｏプロセスにおけるコネクション数を監視するよう制御されることを特徴とする。

また、前記オートスケーリング処理は、スケールインを行う時間間隔とスケールアウトを行う時間間隔とが異なるように制御されることを特徴とする。

本発明の一実施形態にかかる情報処理システム等によれば、ロードバランサがユーザ端末等からの直接的なコネクションを受けることによる障害等のリスクを低減し、既存の仕組みを利用しながら最小の構成で高度のロードバランシング及びオートスケーリングを実現できるという特段の効果を奏する。

本発明の一実施形態にかかる情報処理システムの全体構成例を説明する説明図である。 本発明の一実施形態にかかる情報処理システムをより詳細に説明する説明図である。 本発明の一実施形態にかかる情報処理システムにおける情報処理装置の外観構成を説明する説明図である。 本発明の一実施形態にかかる情報処理システムにおける情報処理装置の機能ブロックを説明する説明図である。 本発明の一実施形態にかかる情報処理システム等の動作例を説明する説明図である。 本発明の一実施形態にかかる情報処理システム等の動作を説明するフローチャートである。 本発明の一実施形態にかかる情報処理システム等の他の動作を説明するフローチャートである。

本発明の一実施形態にかかる情報処理システム及び情報処理プログラムについて、図面を参照しながら詳細に説明する。

図１に、本発明の一実施形態にかかる情報処理システムの全体構成例を示す。本発明の特徴的な処理動作は、主に情報処理サーバ群において実施されるが、本発明はこれに限定されるものではなく、他の情報処理サーバや情報処理装置等においても実行可能な処理ルーチンのうちの少なくとも一部が実施されることがある。以下、図１を参照して、情報処理システム全体として本発明の一実施形態を実施する場合の態様を説明する。

図１に示されるように、情報処理システム１０は、その最小限の構成として、情報処理サーバ群１１と、プレーヤが使用する各種情報処理装置（図において、例示的に、ＰＣ１２及び１３、携帯電話１４、携帯情報端末ないしタブレット端末１５が示されている。以下、総称して「端末」とも言うこともある）とで構成され、サーバ群及び各種端末間は、図１に示されるように専用回線やインターネット等の公衆回線（有線の回線として、１６〜１８）により相互に通信可能に接続されている。また、回線は有線であっても無線であってもよく、無線の場合、携帯電話１４及び携帯情報端末ないしタブレット端末１５は、無線で図示しない基地局や無線ルータ等を介してインターネット１９に乗り入れ、更に回線１８を介して情報処理サーバ群１１と相互に通信可能に接続される。

なお、本願の出願時点での携帯電話や携帯情報端末ないしタブレットは、パーソナルコンピュータ（ＰＣ）に比肩する処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコンピュータとも言うべきものである。

また、本発明の実施に必要なプログラムないしソフトウェアは、通常、情報処理サーバ群における記憶部、さらには必要に応じてＰＣや携帯情報端末の記憶部におけるＨＤＤないしＳＳＤ等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。

なお、演算実行は必ずＣＰＵ等の中央処理部で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

さらに、情報処理サーバ群１１のハードウェア構成も、基本的にはＰＣを採用することができる。なお、本発明はこれに限定されるものではないが、情報処理サーバ群１１は、必要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十台〜数万台）を並列的に作動させることによって大規模データの処理に適した構成をとることもできる。

図２に、本発明の一実施形態にかかる情報処理サーバ群１１のより詳細なシステム構成を示す。情報処理サーバ群１１の動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。

図２において、ユーザ端末１５ａ〜１５ｃからアクセスされる情報処理サーバ群１１は、大別すると、リアルタイムクラスタ１１１と、ロードバランサ／オートスケーリングクラスタ１１２と、ＡＰＩサーバ２３と、Ｃａｃｈｅクラスタ２６とを有する。更に詳細には、リアルタイムクラスタ１１１は、Ｌｏｂｂｙクラスタ２１ａ〜２１ｃとＧａｍｅクラスタ２２ａ〜２２とを含み、ロードバランサ／オートスケーリングクラスタ１１２は、Ｌｏｂｂｙロードバランサ２４ａ〜２４ｃと、Ｇａｍｅロードバランサ２５ａ〜２５ｃとを含む。
なお、「ユーザ端末１５ａ〜１５ｃ」や「Ｌｏｂｂｙクラスタ２１ａ〜２１ｃ」などとアルファベットを添えて複数の構成としたのは、多数の端末やサーバ群（クラスタ）で構成されていることを意図するものであって、その数（ａ〜ｃまでの３台とか、ａ〜ｄまでの４台など）を制限するものではない。

ここで、Ｌｏｂｂｙクラスタは、リアルタイムマルチプレイゲームを成立させるためのロビーでのユーザマッチング処理を担当するサーバ群であり、Ｇａｍｅクラスタは、リアルタイムゲームを進行させる上での主としてアクション部分におけるリアルタイム通信処理等を担当するサーバ群である。

また、ロードバランサ／オートスケーリングクラスタ１１２においては、Ｌｏｂｂｙクラスタのロードバランシング及びオートスケーリングを担当するＬｏｂｂｙロードバランサ２４とＧａｍｅクラスタのロードバランシング及びオートスケーリングを担当するＧａｍｅロードバランサとが併存し、互いに調整（プロセス監視など）を行いながら作動している。

詳細は図５等を参照して後述するが、図２におけるサーバ群１１とユーザ端末１５とのデータのやり取りや、クラスタ間のデータのやり取りについて、双方向又は単方向の矢印ａ〜ｅ、並びに、矢印Ａ〜Ｄを示しているが、それぞれの概要は下表のとおりである。

図３に、本発明の一実施形態にかかる情報処理システムにおける情報処理装置としてのタブレット端末の外観構成を示す。図３において、情報処理装置（タブレット端末）１５は、筐体部１５１とディスプレイ１５２と筐体１５１の下部中央部に設けられたハードウェアボタン１５３とからなる。ディスプレイ１５２は典型的には液晶ディスプレイ（ＬＣＤ）等で構成され、文字や静止画像や動画など様々な情報を表示することができる。また、ディスプレイ１５２にメニューボタンやソフトウェアキーボードを表示させ、これを指ないしタッチペン（不図示）等で触れることによりタブレット端末１５への指示（コマンド）とすることができる。この点で上記ハードウェアボタン１５３は必須の構成要素ではないが、本発明の説明の便宜上、一定の機能を担うボタンとして実装されている。もちろん、これらハードウェアボタン１５３を、ディスプレイ１５２の一部に表示させたメニューボタンで代替させることも可能である。

また、ディスプレイ１５２には、マルチタッチ入力パネルが含まれており、タッチ入力パネル上でのタッチ入力位置座標が入力デバイスインタフェース（不図示）を介してタブレット端末１５の処理系（ＣＰＵ）へ送信され処理される。そして、このマルチタッチ入力パネルは、パネルに対する複数の接触点を同時に感知することができるよう構成されている。この検出（センサ）については様々な方法で実現することができ、必ずしも接触センサに限られず、例えば、光学式のセンサを利用してパネルに対する指示点を抽出することも可能である。さらに、センサには、接触式のセンサや光学式のセンサのほか、人の肌の接触を感知する静電容量方式のセンサを用いることも可能である。

また、図３には現れていないが、タブレット端末１５は、マイクやスピーカを備えることもできる。この場合にはマイクより拾ったユーザの声などを判別して入力コマンドとすることも可能である。さらに、図３には現れていないが、タブレット端末１５の背面等には、ＣＭＯＳ等のカメラデバイスが実装されている。

図４に、本発明の一実施形態にかかるタブレット端末１５を構成するハードウェアの機能ブロック図を例示する。タブレット端末１５の動作は、以下に説明するハードウェアの個々の動作、及びソフトウェアとこれらハードウェアとの連携動作によって実現されている。

図４において、ハードウェアブロック全体としてのタブレット端末４００は、大別すると、図３におけるハードウェアボタン１５３、ディスプレイ１５２に設けられたマルチタッチ入力パネル、マイク等で構成される入力部４０１と、プログラムやデータ等を記憶するためのハードディスク、ＲＡＭ及び／又はＲＯＭ等で構成される記憶部４０２と、プログラムによって様々な数値計算や論理演算を行うＣＰＵによって構成される中央処理部４０３と、ディスプレイ１５２等で構成される表示部４０４と、チップや電気系統等の制御を行うための制御部４０５と、インターネットにアクセスするためのスロットや光通信を行うためのポート、及び通信インタフェースから構成される通信インタフェース部４０６と、スピーカやバイブレーション等の出力部４０７と、時刻等を計時するための計時部４０８と、ＣＭＯＳ等のイメージセンサからなるセンサ部４０９と、装置内の各モジュールに電源を供給するための電源部４１０とからなり、これらのモジュールは必要に応じて適宜通信バスや給電線（図４においては、便宜上各線が適宜区分された結線４１１としてひとまとめに表す）によって接続されている。

なお、センサ部４０９には、タブレット端末４００（１５）の位置を特定するためのＧＰＳセンサモジュールを含めることとしても良い。また、センサ部４０９を構成するＣＭＯＳ等のイメージセンサによって検知された信号は、入力部４０１において入力情報として処理することができる。

また、本発明の実施に必要なプログラムないしソフトウェアは、通常、記憶部４０２を構成するハードディスクディスク等にインストールないし記憶され、プログラムないしソフトウェアの実行時には、必要に応じて記憶部４０２内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵ４０３において演算実行される。

なお、演算実行は必ずしもＣＰＵ等の中央処理部４０３で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

次に、図５〜図６の動作フローないしフローチャートを用いて、本発明にかかる一実施形態における情報処理システムないし情報処理プログラムの動作を説明する。
既に述べたように、本発明の特徴的な動作は、主として情報処理サーバ群において実施可能であるとともに、少なくともその一部を情報処理装置等に実施させることもできる。

図５に、本発明の一実施形態における情報処理システムの全体動作フローの概略を示す。図５において、「ユーザ端末」は情報処理装置であり、図１におけるタブレット端末１５のほか、同図のＰＣ１２、１３、携帯電話１４などがこれに対応し、図５における「Ｌｏｂｂｙクラスタ」、「Ｇａｍｅクラスタ」、「ＡＰＩサーバ」、「Ｃａｃｈｅクラスタ」は、図１における情報処理サーバ群１１がこれらに対応する。より詳細には、図５における「Ｌｏｂｂｙクラスタ」、「Ｇａｍｅクラスタ」、「ＡＰＩサーバ」、「Ｃａｃｈｅクラスタ」は、図２におけるＬｏｂｂｙクラスタ２１ａ〜２１ｃ、Ｇａｍｅクラスタ２２ａ〜２２ｄ、ＡＰＩサーバ２３、Ｃａｃｈｅクラスタ２６にそれぞれ対応する（ロードバランサ２４ａ〜２４ｃやオートスケールサーバ２５ａ〜２５ｃの動作例については、図６〜図７を参照して後述する）。
また、図５中、ｔ１〜ｔ８は時系列の流れを示し、経時的に後述する動作や処理が行われるものである。

（時刻ｔ１までの処理）
まず、時刻ｔ１までの処理（図５において、不図示）を簡単に説明しておく。時刻ｔ１までに、ユーザ（プレーヤ）は、ユーザ端末を介して情報処理サーバ群のうちのいずれかのサーバから自身のユーザ端末を本発明にかかる情報処理システムにおける情報処理装置として動作させるためのアプリケーションソフトウェアをダウンロードする。このアプリケーションソフトウェアは、本発明にかかるプログラムの少なくとも一部を処理するためのクライアントソフトウェアないしアプリケーションソフトウェアである。そして、ダウンロードしたアプリケーションソフトウェアをユーザ端末にインストールする。

なお、アプリケーションソフトウェアは、情報処理装置に予めインストールされているウェブブラウザの機能で代替することも可能であり、この場合は、アプリケーションソフトウェアのインストールが省略される場合もある。

また、ユーザ端末からは、必要に応じてユーザ登録としてユーザ自身のメールアドレスのほか、一例として、次表のようなプロフィール情報をサーバへアップロードして登録管理させることもできる。

以上のデータ項目は、ユーザデータとして情報処理サーバ群のうちのいずれかのサーバ上で保存される。そして、ユーザ（プレーヤ）が情報処理装置を操作することによりゲームを開始することができる。

ゲーム開始時には、一例として、ユーザ（プレーヤ）は、ログイン動作と、コマンド送信という２つの典型的なユーザ端末操作を行い、情報処理サーバから必要なデータ送信を受け、あるいは、サービス提供を受けることとなる。

より具体的には、ユーザが自身の情報処理装置を介してサーバへのログイン処理を行うと、情報処理サーバでは必要な認証処理が適宜行われ、ユーザがサービス提供を受けられるためのデータを送信する。例えば、端末からのコマンドを受信可能に構成されたトップメニュー画面や、アプリケーションの起動画面等である。
そして、ユーザは情報処理装置を介して何らかのコマンドを送信する。このコマンドは、メニュー画面に表示されたメニューの選択かもしれないし、アプリケーション起動画面であれば、アプリケーションを開始するための開始コマンドの場合もある。サーバ側では、このコマンドを受けて、サービス処理を開始する。そして、サーバから端末の要求に応じたサービスが提供される。

なお、端末からは随時コマンドを送信することができ（例えば、ゲームアプリケーション実行中の操作コマンドなど）、都度、サーバでは端末からのコマンド受信を受けてサービスを提供することができる（例えば、ゲームアプリケーション実行中の操作コマンドを受けて対象となるオブジェクトを移動させたり、その他の演算処理をしたりするなど）。

その他付加的に、ユーザ（プレーヤ）は、一例としてユーザ端末から特定の相手もしくは特定多数の相手に向けてメッセージを送信することもできる。このメッセージは、情報処理サーバにて中継され、特定の相手もしくは特定多数の相手に転送され相手方において受信される。また、送信したメッセージは自身の端末でも確認できる。このようなコミュニケーションツールはいわばオプションであり、必要に応じて実装することができる。
以上が、時刻ｔ１までの動作例である。

（時刻ｔ１以降の処理）
図５の時刻ｔ１において、ユーザ端末からＡＰＩサーバ及びＣａｃｈｅサーバを介して、Ｌｏｂｂｙノードの取得処理が行われる（ステップＳ５０１〜ステップＳ５０３）。つまり、ユーザ端末からのＬｏｂｂｙノード取得要求（ステップＳ５０１）をトリガとして、当該ユーザ端末が使用するＬｏｂｂｙサーバの割り当て処理が行われる。このとき、ＡＰＩサーバは、適宜、Ｃａｃｈｅクラスタとのデータのやり取りを行っており（一例として、ステップＳ５０２）、ＡＰＩサーバとＣａｃｈｅサーバとの調整の結果、時刻ｔ２において、ＡＰＩサーバを介して取得されたＬｏｂｂｙノードがユーザ端末へ返される（ステップＳ５０３）。
なお、Ｌｏｂｂｙノード取得（ないし割当）についてのＡＰＩサーバ／Ｃａｃｈｅクラスタ間のやり取りは、時刻ｔ１〜ｔ２間に限られるものではなく、適宜行うことができる（図５中、破線の矢印で記した）。
また、本実施例では、ステップＳ５０１におけるＬｏｂｂｙノード取得要求を「ゲーム開始要求のためのトリガ」、ないしゲームに対する「アクセス要求」と位置付ける。

次に、時刻ｔ３において、ユーザ端末からＬｏｂｂｙクラスタへＬｏｂｂｙノード接続が行われる（ステップＳ５０４）。接続先は、ステップＳ５０３において返送されたＬｏｂｂｙノードである。

時刻ｔ３〜ｔ４において、Ｌｏｂｂｙクラスタにてユーザ同士の対戦マッチングたのめのｒｏｏｍ＿ｉｄが決定され（ステップＳ５０５）、時刻ｔ４において、Ｌｏｂｂｙクラスタからユーザ端末へ決定さされたｒｏｏｍ＿ｉｄが返送される（ステップＳ５０６）。

次に、図５の時刻ｔ５において、ユーザ端末からＡＰＩサーバ及びＣａｃｈｅサーバを介して、Ｇａｍｅノードの取得処理が行われる（ステップＳ５０７〜ステップＳ５０９）。つまり、ユーザ端末からのＧａｍｅノード取得要求（ステップＳ５０７）をトリガとして、当該ユーザ端末が使用するＧａｍｅサーバの割り当て処理が行われる。このとき、ＡＰＩサーバは、適宜、Ｃａｃｈｅクラスタとのデータのやり取りを行っており（一例として、ステップＳ５０８）、ＡＰＩサーバとＣａｃｈｅサーバとの調整の結果、時刻ｔ６において、ＡＰＩサーバを介して取得されたＧａｍｅノードがユーザ端末へ返される（ステップＳ５０９）。
なお、Ｇａｍｅノード取得（ないし割当）についてのＡＰＩサーバ／Ｃａｃｈｅクラスタ間のやり取りは、時刻ｔ５〜ｔ６間に限られるものではなく、適宜行うことができる（図５中、破線の矢印で記した）。

つまり、Ｌｏｂｂｙノード取得及びＧａｍｅノード取得のためのＡＰＩサーバ／Ｃａｃｈｅクラスタ間のデータやり取りは、時刻ｔ１〜ｔ２間あるいは時刻ｔ５〜ｔ６間に限られず、適宜実施することができる。

次に、時刻ｔ７において、ユーザ端末からＧａｍｅクラスタへＧａｍｅノード接続が行われる（ステップＳ５１０）。接続先は、ステップＳ５０９において返送されたＧａｍｅノードである。
Ｇａｍｅノード接続が成功すると、ユーザはユーザ端末を使って、ゲームを開始することができる（ゲーム開始の様子は、図５において不図示）。典型的には、リアルタイムマルチプレイゲームなどである。

ユーザがゲームを終了するなどして、いったんＡＰＩサーバからのサービス提供を終了させる場合には、ユーザ端末からＡＰＩサーバへ終了要求が送信される（時刻ｔ８におけるステップＳ５１１）。

図６に、本発明の一実施形態にかかる情報処理システムのうち、ロードバランサ／オートスケーリングクラスタ１１２の処理動作を含むシステムの動作フローチャートを示す。
図６には、独立した２つのフローチャート（Ａ）及び（Ｂ）が示されているが、このように分けたのは、それぞれ割込み元が異なるためである。
しかしながら、本発明の一実施形態にかかる情報処理システムとしては、図６に示された２つのフローチャートによってロードバランシング処理が完結するとも言えるため、同図にまとめて示し、それぞれのフローチャートについて説明する。

図６（Ａ）には、ロードバランサ／オートスケーリングクラスタ１１２及びＣａｃｈｅクラスタ２６側のロードバランシング処理フローが示されている。
すなわち、ステップＳ６０１において、本処理が開始されると、ステップＳ６０２では情報更新のための割り込みが定期的に実施される。本発明は、これに限定されるものではないが、割り込みの頻度は、数十ｍ秒〜１秒程度（あるいはそれ以上の間隔でも良い）である。
ステップＳ６０２において、Ｎｏであれば、ステップＳ６０５に進み、システム終了かどうかの判定がなされ、Ｙｅｓであれば処理を終了する（ステップＳ６０６）が、Ｎｏの場合は、ステップＳ６０２に復帰する。

ステップＳ６０２において、Ｙｅｓの場合は、ステップＳ６０３に進み、一例としてＥＣ２（アマゾン・ドット・コムが提供する仮想クラウドサーバ）などで振り分け可能なタグ情報等を基に、各クラスタ（ＬｏｂｂｙクラスタやＧａｍｅクラスタ）におけるノードごとのコネクション数を取得する。この場合の取得間隔は、一例として１秒ごとなどである（上述したステップＳ６０２の割り込み間隔によって適宜調整される）。

このとき、監視されるコネクション数は、ＣＰＵ使用率やＬｏａｄＡｖｅｒａｇｅといった指標で見るのではなく、ｓｏｃｋｅｔ．ｉｏプロセス（アプリケーションレイヤ）でのコネクション数を監視するように制御すると好適である。つまり、このような監視を行うと、サーバ自体は稼働しているがプロセスそのものは動作していなかったような状況における監視上の誤認を回避することができる。

次に、ステップＳ６０４に進み、前ステップで取得された各クラスタにおけるノードごとのコネクション数をＣａｃｈｅクラスタのＳｏｒｔｅｄＳｅｔクラス（ソート済みセット型）のメンバに保管及び更新する。
そして、ステップＳ６０５に進み、その後の処理は上述のとおりである。

一方、図６（Ｂ）には、ユーザ端末１５、ＡＰＩサーバ２３及びＣａｃｈｅクラスタ２６側のロードバランシング処理フローが示されている。
すなわち、ステップＳ６３１において、本処理が開始されると、ステップＳ６３２では、ユーザ端末からのエンドポイント要求があるかどうかが判断される。ステップＳ６３２において、Ｎｏであれば、ステップＳ６３４に進み、システム終了かどうかの判定がなされ、Ｙｅｓであれば処理を終了する（ステップＳ６３５）が、Ｎｏの場合は、ステップＳ６３２に復帰する。

ステップＳ６３２において、Ｙｅｓの場合は、ステップＳ６３３に進み、ＡＰＩサーバから実質的にリアルタイムにて（例えば、数ミリ秒以内で）、最も接続数の少ないノードを読み出し、クライアント（ユーザ端末）へそのエンドポイントを返送する。
そして、ステップＳ６３５に進み、その後の処理は上述のとおりである。

つまり、図６（Ｂ）に示した詳細フローは、図５を参照して既に説明したフローとなり得る。

このように、本発明の一実施形態にかかる情報処理システムにおけるロードバランシング処理は、図６（Ａ）及び（Ｂ）に示される独立した処理フローによって完結するものである。また、ＡＰＩサーバ２３及びＣａｃｈｅクラスタ２６間で適宜データのやり取り（調整）が行われていることは、図５を参照して説明した通りである。

そして、上述した本発明の一実施形態にかかるロードバランシング処理においては、ロードバランサは、ユーザ端末からの直接のコネクションを受けることがないため、システム上の障害リスクを低減させることができるという大きな利点がある。

図７に、本発明の一実施形態にかかる情報処理システム等の他の動作を示す。具体的には、ロードバランサ／オートスケーリングクラスタ１１２の処理動作のうち、オートスケーリング処理動作を中心に説明している。

（オートスケーリング処理の基本概念）
本発明の一実施形態にかかる情報処理システム等のオートスケーリング処理動作の特徴は、設定した閾値に応じて、クラスタを構成するサーバを自動的に追加／削減させることであるが、追加（スケールアウト）及び削減（スケールイン）の条件を異ならせることである。例えば、追加（スケールアウト）は最短で３分に一度の頻度で実施し、削減（スケールイン）は１時間に一度の頻度で実施するなどである。もちろん、時間頻度は任意に設定可能であるが、追加（スケールアウト）の頻度よりも削減（スケールイン）の頻度のほうをより長く取ると好適である。これは、追加よりも削減のほうがシステム全体の運営上リスクを伴うことが多いためである。

あるいは、システム全体の運営上のリスク低減の観点から、システム稼働が活発なとる日中の時間帯の削減は避け、深夜（例えば、深夜１時〜４時など）の時間帯のみトリガを有効とするなどの設定も有効である。
以下、図７に沿って処理動作を詳述する。

ステップＳ７０１において、処理を開始すると、ステップＳ７０２において、スケールアウトフラグ及びスケールインフラグをそれぞれオフにし、スケールアウトタイマ及びスケールインタイマをそれぞれリセットする。

スケールアウトフラグは、所定時間内にスケールアウトを既に実施したかどうかを確認するためのフラグで、通常オン／オフの２値をとる。同様に、スケールインフラグは、所定時間内にスケールインを既に実施したかどうかを確認するためのフラグで、通常オン／オフの２値をとる。

スケールアウトタイマは、システム運営上、一定時間間隔内で１回のスケールアウトを許容するような場合に、その時間間隔を管理するための変数である。また、スケールインタイマは、システム運営上、一定時間間隔内で１回のスケールインを許容するような場合に、その時間間隔を管理するための変数である。

それぞれのタイマは、任意に設定可能であり（同値とすることも異なった値とすることもできる）、タイマカウント開始後は、決められた時間を計時し、タイムアウトするとまたリセットされるというように利用される。

次に、ステップＳ７０３へ進み、スケールアウトタイマ及びスケールインタイマをスタートさせる。つまり、それぞれの設定時間（一例として、スケールアウトに対しては３分、スケールインに対しては１時間など）に対する計時を開始する。

次に、ステップＳ７０４では、管理者による明示的な指示等によりシステムが終了したかどうかが判断され、Ｙｅｓの場合は、システムを終了させる（ステップＳ７９９）が、Ｎｏの場合はステップＳ７０５へ進む。

ステップＳ７０５では、システム内の各クラスタ等の監視が行われる。例えば、各クラスタのノードごとの負荷の監視などである（これによって、各クラスタ単位での負荷も把握することができる）。どのクラスタにどの程度までの負荷が許容範囲なのか、どのクラスタにどの程度の稼働を常時課すように定めるか等については、システムの運営上適宜設定することができる。

ステップＳ７０６では、あるクラスタの負荷が所定の範囲内かどうかが判断される。本ステップでは、便宜上判断ステップはこのステップＳ７０６のみであるが、クラスタごとに本ステップに基づく判断は行われる。また、ステップＳ７０４でＮｏとなる場合の処理ループも一定時間（一例として、数十ミリ秒〜１秒。それ以上の間隔でも良い）ごとに繰り返される。
以下、説明の便宜上、特定のクラスタにフォーカスしてその処理ループの１回分の説明を詳述する。

（スケールアウト／スケールインが全く発生しない場合の運用）
ステップＳ７０６において、Ｙｅｓの場合、ステップＳ７１４に進み、スケールアウトタイマが所定値Ａ以内であり、かつ、スケールインタイマが所定値Ｂ以内であるかどうかが判断される（所定値Ａ及び所定Ｂは同じであっても良い）。

ステップＳ７１４において、Ｙｅｓの場合はステップＳ７０４へ復帰する。一方で、Ｎｏの場合は、スケールアウトタイマ、スケールインタイマの少なくともいずれか一方がタイムアウトした場合なので、ステップＳ７１５へ進み、タイムアウトしたスケールアウトタイマ及び／又はスケールインタイマをリセットし、併せて、対応するフラグをリセット（オフ）して、前ステップでリセットされたタイマをスタートさせる（ステップＳ７１６）。
そして、ステップＳ７０４に復帰する。

（スケールアウト／スケールインが発生する場合の運用）
ステップＳ７０６において、Ｎｏの場合、ステップＳ７０７へ進み、クラスタの負荷は閾値（上限）を越えたかどうかが判断される。ステップＳ７０７において、Ｙｅｓの場合は、ステップＳ７０８へ進み、スケールアウトフラグはオンかどうかが判断される。同ステップにおいて、スケールアウトフラグはオン（Ｙｅｓ）の場合はステップＳ７１４へ進むが、Ｎｏの場合は、ステップＳ７０９へ進み、スケールアウトフラグをオンにして（ステップＳ７０９）、スケールアウトが行われる（ステップＳ７１０）。そして、ステップＳ７１４へ進む。なお、ステップＳ７０９とステップＳ７１０の順序はこれに限定されない。

一方で、ステップＳ７０７において、クラスタの負荷は閾値（上限）を越えていない（Ｎｏ）と判断された場合は、負荷は所定の範囲内ではなく（ステップＳ７０６において、Ｎｏ）、かつ、閾値（上限）を越えていない場合であるので、スケールイン（サーバの削除）をしても良いケースであり、さらなる判断のためステップＳ７１１へ進む。

ステップＳ７１１では、スケールインフラグはオンかどうかが判断される。同ステップにおいて、スケールインフラグはオン（Ｙｅｓ）の場合はステップＳ７１４へ進むが、Ｎｏの場合は、ステップＳ７１２へ進み、スケールインフラグをオンにして（ステップＳ７１２）、スケールインが行われる（ステップＳ７１３）。そして、ステップＳ７１４へ進む。なお、ステップＳ７１２とステップＳ７１３の順序はこれに限定されない。

（オートスケーリング処理の応用例）
オートスケーリング処理の基本概念として、スケールインを深夜の時間帯に実施することを述べたが、かかる判断は、一例として図７のステップＳ７１１の後に、現在時刻に基づき予め設定された深夜帯（例えば、午前１時〜午前４時間までなど）であるかどうかを判断させることができるが、その他の応用例として次のような処理を実施させることも可能である。いずれもゼロダウンタイム（ダウンタイムを限りなく短くすること）を実現するための処理である。

（１）システムにおいて、サーバプロセスが立ち上がり、さらに接続が確認できるまで、ロードバランサ側で有効なノードとして認識させないように制御する。
（２）システムにおいて、スケールインの際は、ノードへの接続な状態でのみトリガを有効とするように制御する。

以上、具体例に基づき、情報処理システム及び情報処理プログラム等の実施形態を説明したが、本発明の実施形態としては、システム又は装置を実施するための方法又はプログラムの他、プログラムが記録された記憶媒体（一例として、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、ハードディスク、メモリカード）等としての実施態様をとることも可能である。

また、プログラムの実装形態としては、コンパイラによってコンパイルされるオブジェクトコード、インタプリタにより実行されるプログラムコード等のアプリケーションプログラムに限定されることはなく、オペレーティングシステムに組み込まれるプログラムモジュール等の形態であっても良い。

さらに、プログラムは、必ずしも制御基板上のＣＰＵにおいてのみ、全ての処理が実施される必要はなく、必要に応じて基板に付加された拡張ボードや拡張ユニットに実装された別の処理ユニット（ＤＳＰ等）によってその一部又は全部が実施される構成とすることもできる。

本明細書（特許請求の範囲、要約、及び図面を含む）に記載された構成要件の全て及び／又は開示された全ての方法又は処理の全てのステップについては、これらの特徴が相互に排他的である組合せを除き、任意の組合せで組み合わせることができる。

また、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された特徴の各々は、明示的に否定されない限り、同一の目的、同等の目的、または類似する目的のために働く代替の特徴に置換することができる。したがって、明示的に否定されない限り、開示された特徴の各々は、包括的な一連の同一又は均等となる特徴の一例にすぎない。

さらに、本発明は、上述した実施形態のいずれの具体的構成にも制限されるものではない。本発明は、本明細書（特許請求の範囲、要約、及び図面を含む）に記載された全ての新規な特徴又はそれらの組合せ、あるいは記載された全ての新規な方法又は処理のステップ、又はそれらの組合せに拡張することができる。

１０ 情報処理システム
１１ 情報処理サーバ群
１１１ リアルタイムクラスタ
１１２ ロードバランサ／オートスケーリングクラスタ
１５ タブレット端末（情報処理装置の一形態）
１２、１３ ＰＣ（情報処理装置の一形態）
１４ 携帯電話（情報処理装置の一形態）
１９ 公衆回線（専用線、インターネット等）
２１ Ｌｏｂｂｙクラスタ
２２ Ｇａｍｅクラスタ
２３ ＡＰＩサーバ
２４ Ｌｏｂｂｙロードバランサ
２５ Ｇａｍｅロードバランサ
２６ Ｃａｃｈｅクラスタ

Claims (6)

1. 複数のユーザ端末からのアクセスが可能であり、前記アクセスのあった複数のユーザ端末によるリアルタイムマルチプレイゲームを制御する情報処理システムであって、
   Ｌｏｂｂｙクラスタ及びＧａｍｅクラスタを含むリアルタイムクラスタと、
   Ｌｏｂｂｙロードバランサ及びＧａｍｅロードバランサを含むロードバランサ／オートスケーリングクラスタと、
   ＡＰＩサーバと、
   Ｃａｃｈｅクラスタと
   を有し、
   （Ａ）前記リアルタイムマルチゲームの進行時には、
   前記ロードバランサ／オートスケーリングクラスタから前記リアルタイムクラスタへの負荷監視が行われるとともに、前記負荷監視結果は前記Ｃａｃｈｅクラスタに保管及び更新され、
   前記Ｃａｃｈｅクラスタと前記ＡＰＩとの間で前記負荷監視結果に基づいたデータ授受が行われ、
   前記ロードバランサ／オートスケーリングクラスタから前記リアルタイムクラスタに対しては、前記負荷監視結果に基づくオートスケーリング処理が行われると共に、
   （Ｂ）前記複数のユーザ端末からのアクセス要求時には、
   前記アクセス要求を前記ＡＰＩサーバで受け付けると共に、前記ＡＰＩサーバは前記Ｃａｃｈｅクラスタとの間でＬｏｂｂｙノード割当調整を実施し、
   前記ＡＰＩサーバは、前記Ｌｏｂｂｙノード割当調整の結果、決定されたＬｏｂｂｙノードを、前記アクセス要求を行ったユーザ端末に返送し、
   前記アクセス要求を行ったユーザ端末は、前記決定されたＬｏｂｂｙノードに基づいて前記Ｌｏｂｂｙクラスタにおける所定のサーバにアクセスし、
   前記所定のサーバは、マルチプレイのためのマッチング処理を行ってｒｏｏｍ＿ｉｄを決定すると共に、当該ｒｏｏｍ＿ｉｄを、前記アクセス要求を行ったユーザ端末に返送し、
   前記ＡＰＩサーバは、前記アクセス要求を行ったユーザ端末からの要求に応じて、前記Ｃａｃｈｅクラスタと前記アクセス要求を行ったユーザ端末が利用するためのｇａｍｅノードの割当調整を実施し、
   前記ＡＰＩサーバは、前記ｇａｍｅノード割当調整の結果、決定されたｇａｍｅノードを、前記アクセス要求を行ったユーザ端末に返送し、
   前記アクセス要求を行ったユーザ端末は、前記決定されたＬｏｂｂｙノード及びｇａｍｅノードに基づいて、前記リアルタイムマルチゲームを進行させる
   ことにより、前記ＡＰＩサーバ及び前記Ｃａｃｈｅクラスタを介したＬｏｂｂｙノード及びｇａｍｅノード割当が実現される
   ことを特徴とする情報処理システム。
2. 前記負荷監視は、ｓｏｃｋｅｔ．ｉｏプロセスにおけるコネクション数を監視するよう制御されることを特徴とする請求項１に記載のシステム。
3. 前記オートスケーリング処理は、スケールインを行う時間間隔とスケールアウトを行う時間間隔とが異なるように制御される請求項１または２に記載のシステム。
4. 複数のユーザ端末からのアクセスが可能であり、Ｌｏｂｂｙクラスタ及びＧａｍｅクラスタを含むリアルタイムクラスタと、Ｌｏｂｂｙロードバランサ及びＧａｍｅロードバランサを含むロードバランサ／オートスケーリングクラスタと、ＡＰＩサーバと、Ｃａｃｈｅクラスタとを有し、前記アクセスのあった複数のユーザ端末によるリアルタイムマルチプレイゲームを制御する情報処理システムで実行されるコンピュータプログラムあって、前記情報処理システム上で実行されたとき、
   （Ａ）前記リアルタイムマルチゲームの進行時には、
   前記ロードバランサ／オートスケーリングクラスタに、前記リアルタイムクラスタへの負荷監視を行わせるとともに、前記負荷監視結果を前記Ｃａｃｈｅクラスタに保管及び更新させるステップと、
   前記Ｃａｃｈｅクラスタと前記ＡＰＩとの間で前記負荷監視結果に基づいたデータ授受を行わせるステップと、
   前記ロードバランサ／オートスケーリングクラスタに、前記リアルタイムクラスタに対する、前記負荷監視結果に基づくオートスケーリング処理を行わせるステップと、
   （Ｂ）前記複数のユーザ端末からのアクセス要求時には、
   前記ＡＰＩサーバに、前記アクセス要求を受け付けさせると共に、前記ＡＰＩサーバと前記Ｃａｃｈｅクラスタとに、Ｌｏｂｂｙノード割当調整を実施させるステップと、
   前記ＡＰＩサーバに、前記Ｌｏｂｂｙノード割当調整の結果、決定されたＬｏｂｂｙノードを、前記アクセス要求を行ったユーザ端末に返送させるステップと、
   前記アクセス要求を行ったユーザ端末に、前記決定されたＬｏｂｂｙノードに基づいて前記Ｌｏｂｂｙクラスタにおける所定のサーバにアクセスさせるステップと、
   前記所定のサーバに、マルチプレイのためのマッチング処理を行わせてｒｏｏｍ＿ｉｄを決定させると共に、当該ｒｏｏｍ＿ｉｄを、前記アクセス要求を行ったユーザ端末に返送させるステップと、
   前記ＡＰＩサーバと前記Ｃａｃｈｅクラスタとに、前記アクセス要求を行ったユーザ端末からの要求に応じて、前記アクセス要求を行ったユーザ端末が利用するためのｇａｍｅノードの割当調整を実施させるステップと、
   前記ＡＰＩサーバに、前記ｇａｍｅノード割当調整の結果、決定されたｇａｍｅノードを、前記アクセス要求を行ったユーザ端末に返送させるステップと、
   前記アクセス要求を行ったユーザ端末に、前記決定されたＬｏｂｂｙノード及びｇａｍｅノードに基づいて、前記リアルタイムマルチゲームを進行させるステップと
   を実行させることにより、前記ＡＰＩサーバ及び前記Ｃａｃｈｅクラスタを介したＬｏｂｂｙノード及びｇａｍｅノード割当が実現される
   ことを特徴とするプログラム。
5. 前記負荷監視は、ｓｏｃｋｅｔ．ｉｏプロセスにおけるコネクション数を監視するよう制御されることを特徴とする請求項４に記載のプログラム。
6. 前記オートスケーリング処理は、スケールインを行う時間間隔とスケールアウトを行う時間間隔とが異なるように制御される請求項４または５に記載のプログラム。