JP6830695B2 - マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法および装置 - Google Patents

Description

本発明はマルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法および装置に関する。より詳細には、クラウド基盤でゲームＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーをワンクリックで生成／管理するＢａａＳ（Ｂａｃｋｅｎｄ ａｓ ａ Ｓｅｒｖｉｃｅ）のための方法および装置に関する。

韓国コンテンツ振興院が発刊した「２０１５ゲーム白書」によると、２０１４年基準モバイルゲームの平均開発期間は１０ヶ月であり、製作人員は７．６名という。平均労銀を代入して計算すると、１個のゲームの製作に略２億４千万ウォンが入る。ところが、このようにして制作したゲームの平均利用期間は４ヶ月（１４．７週）しかならない。すなわち、モバイルゲームは製作期間の半分もならない短い寿命を有しているのである。したがって、製作期間を低減するとゲーム開発会社の収益率を高めることができる。しかし、製作期間を低減するためには人員をさらに投入しなければならず、結果として費用が増加するため開発会社には代案がなかった。すなわち、ゲーム開発のための資源は多く入るのに反し、ゲームの流行周期が短いためゲーム開発会社が経営上の問題点を有することになる。

現在のモバイルゲームサーバーの開発過程は、以前の項目で口述した「機能の類似性」を理由に、以前のコードを再使用するコピーアンドペースト（Ｃｏｐｙ ＋ Ｐａｓｔｅ）方式で進行されている。新しいゲームが追加されると、以前に作成したサーバーコードを保存所からコピーして一部のみを修正、再使用するのである。

このため、類似するサーバーコードをプロジェクト別に管理しなければならないリポジトリ（ｒｅｐｏｓｉｔｏｒｙ）管理問題、同一の配布環境をプロジェクトが追加されるたびに設定しなければならないインフラ管理の問題、サーバーコードをそれぞれのサーバーに個別伝送しなければならないコード配布の問題が持続的に発生している。

本発明は前述した問題点をすべて解決することをその目的とする。

また、本発明は、ゲーム開発者のより便利なゲーム開発のためのＢａａＳ（Ｂａｃｋｅｎｄ ａｓ ａ Ｓｅｒｖｉｃｅ）を提供することを他の目的とする。

また、本発明は、ゲーム開発のためのあらかじめ生成されたＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーを提供することによって、ゲーム開発者がより便利に少ない人的／物的資源でゲームを開発できるようにすることを他の目的とする。

また、本発明は、テナント別にオートスケーリング呼び出し規則をシステムが自動で設定して、テナント別に最小限の運営データだけでテナント別オートスケーリング呼び出し規則を生成し、また、テナント別オートスケーリング呼び出し規則を自動で遂行することを他の目的とする。

前記目的を達成するための本発明の代表的な構成は次の通りである。

本発明の一態様によると、マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法は、クラウド基盤のマルチテナンシー環境で動作するＢａａＳ（ｂａｃｋｅｎｄ ａｓ ａ ｓｅｒｖｉｃｅ）管理サーバーが複数のテナントからゲームＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーに対する要請を受信する段階と前記ＢａａＳ管理サーバーが前記要請により前記ゲームＡＰＩサーバーを提供する段階を含むものの、前記複数のテナントは前記ゲームＡＰＩサーバーに基づいてゲームの開発および駆動に必要な機能が提供され、前記ＢａａＳ管理サーバーは、前記複数のテナントのそれぞれの曜日別トラフィック情報、時間帯別トラフィック情報およびイベント別トラフィック情報を含む運営データを分析してトラフィックパターンを定義し、前記トラフィックパターンを用いて前記テナントごとにオートスケーリング呼び出し規則を動的に生成し、前記オートスケーリング呼び出し規則に基づいて前記ゲームＡＰＩサーバーに対するオートスケーリングを遂行し得る。

本発明の他の態様によると、マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則を自動生成するＢａａＳ（ｂａｃｋｅｎｄ ａｓ ａ ｓｅｒｖｉｃｅ）管理サーバーは、複数のテナントとの通信のために具現される通信部と前記通信部と動作可能に（ｏｐｅｒａｔｉｖｅｌｙ）連結されたプロセッサを含むものの、前記プロセッサはクラウド基盤のマルチテナンシー環境で前記複数のテナントからゲームＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーに対する要請を受信し、前記要請により前記ゲームＡＰＩサーバーを提供するように具現され得るものの、前記複数のテナントは前記ゲームＡＰＩサーバーに基づいてゲームの開発および駆動に必要な機能が提供され、前記プロセッサは、前記複数のテナントのそれぞれの曜日別トラフィック情報、時間帯別トラフィック情報およびイベント別トラフィック情報を含む運営データを分析してトラフィックパターンを定義し、前記トラフィックパターンを用いて前記テナントごとにオートスケーリング呼び出し規則を動的に生成し、前記オートスケーリング呼び出し規則に基づいて前記ゲームＡＰＩサーバーに対するオートスケーリングを遂行し得る。

本発明によると、ゲーム開発者のより便利なゲーム開発のためのＢａａＳが提供され得る。

また、ゲーム開発のためのあらかじめ生成されたＡＰＩを提供することによって、ゲーム開発者がより便利に少ない人的／物的資源でゲームを開発できるようにすることができる。

また、テナント別にオートスケーリング呼び出し規則をシステムが自動で設定して、テナント別に最小限の運営データだけでテナント別オートスケーリング呼び出し規則を生成し、テナント別オートスケーリング呼び出し規則を自動で遂行することを他の目的とする。

既存のバックエンドサーバーについての開発方式を示した概念図。 本発明の実施例に係るゲームＢａａＳを示した概念図。 本発明の実施例に係るクラウド基盤でゲームＡＰＩサーバーを提供する方法を示した概念図。 本発明の実施例に係るゲームＡＰＩサーバーを通じてのサービス提供方法を示した概念図。 本発明の実施例に係るモバイルゲームサーバーに特化したトラフィック需要予測方法を示した概念図。 本発明の実施例に係るゲームＡＰＩサーバー運営方法を示した概念図。 本発明の実施例に係るＢａａＳ管理サーバーの構造を示した概念図。 本発明の実施例に係るＢａａＳの動作を示した概念図。 本発明の実施例に係るＢａａＳ管理サーバーの動作を示した概念図。 本発明の実施例に係るＢａａＳ管理サーバーの動作を示した概念図。 本発明の実施例に係るマルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法を示した概念図。 本発明の実施例に係るテナント別オートスケーリング呼び出し規則を自動で設定する方法を示した概念図。

後述する本発明についての詳細な説明は、本発明が実施され得る特定の実施例を例示として図示する添付図面を参照する。このような実施例は当業者が本発明を実施できるほど充分かつ詳細に説明される。本発明の多様な実施例は互いに異なるが相互排他的である必要はないことが理解されるべきである。例えば、本明細書に記載されている特定の形状、構造および特性は本発明の精神と範囲を逸脱することなく一実施例から他の実施例に変更されて具現され得る。また、それぞれの実施例内の個別の構成要素の位置または配置も本発明の精神と範囲を逸脱することなく変更され得ることが理解されるべきである。したがって、後述する詳細な説明は限定的な意味として行われるものではなく、本発明の範囲は特許請求の範囲の請求項が請求する範囲およびそれと均等なすべての範囲を包括するものと受け入れられるべきである。図面で類似する参照符号は多様な側面に亘って同一または類似する構成要素を示す。

以下では、本発明が属する技術分野で通常の知識を有する者が本発明を容易に実施できるようにするために、本発明の多様な好ましい実施例に関して添付された図面を参照して詳細に説明する。

モバイルゲームは、デバイスに設置されるアプリケーション（ＡＰＰ、ａｐｐｌｉｃａｔｉｏｎ）と目に見えない機能を担当するバックエンドＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーに基づいて駆動され得る。モバイルゲームのためのバックエンドＡＰＩサーバーには、ゲームのジャンル、規模にかかわらず、会員加入／ログイン／アイテム／チャート／ランキング／キャラクター／ランキング／レベルなどの類似する機能が存在する。このような特性のため、モバイルゲームサーバーの製作過程は標準化／自動化が可能である。

ＢａａＳ（Ｂａｃｋｅｎｄ ａｓ ａ Ｓｅｒｖｉｃｅ）は、よく使われるサーバー機能をクラウドＡＰＩの形態で提供することによって、毎回別途に開発することなく容易に利用可能なように助けるサービスである。ゲームサーバーＢａａＳを利用してゲームを製作すると、製作期間と費用を大幅に節減できる。ゲームサーバーＢａａＳを導入すれば、製作人員の縮小を通じての費用節減と開発期間の短縮の両方を捕らえることができる。また、このように節約したリソースをゲーム製作に追加に投入することによって、さらにレベルの高いゲームを作ることができる。

本発明の実施例に係るゲームサーバーＢａａＳは、（１）ゲームＡＰＩサーバー自動製作機能、（２）サーバー自動拡張（Ａｕｔｏ Ｓｃａｌｉｎｇ）、（３）ゲーム管理機能などを提供することができる。本発明の実施例に係るゲームサーバーＢａａＳは、ワンクリックだけで一定時間以内にゲーム開発者のためのゲームＡＰＩサーバーを生成および提供することができる。これを通じて、国内のゲーム開発会社はゲームの製作期間と費用を低減することができ、低減した製作期間と費用を他の開発に投資して良質のゲームを生成することができる。

図１は、既存のバックエンドサーバーについての開発方式を示した概念図である。

図１を参照すると、既存のゲーム開発者は、ゲームに使われるチャット機能、データベース機能、ランキング機能などのために、別途のバックエンドＡＰＩサーバーを自体で開発していた。このようなバックエンドＡＰＩサーバーについての自体開発はゲームの開発期間を長期化させる。また、別途の自体バックエンドＡＰＩサーバーに対する管理によって管理負担が増加している。

図２は、本発明の実施例に係るゲームＢａａＳを示した概念図である。

図２を参照すると、本発明の実施例に係るゲームＢａａＳは、ゲームで使われるゲームＡＰＩを提供するバックエンドサーバーをクラウドサーバー上でワンクリックでゲーム開発者に提供することができる。

モバイルゲームはデバイスに設置されるアプリケーション（Ａｐｐ）および会員加入、ログイン、アイテム購買機能などを担当するゲームＡＰＩサーバーに基づいて動作することができる。

モバイルゲームを具現するために共通して要求される機能として、会員加入／ログイン／アイテム／チャート／ランキング／キャラクター／アイテムなどの標準化された機能が存在し得る。このような機能のためのゲームＡＰＩサーバーはゲームのジャンル、規模にかかわらず、標準化された機能で構成されて自動化が可能である。本発明の実施例に係るゲームＢａａＳは、ゲームジャンル／連動ＳＮＳ／アイテムの形態／キャラクターの類型／ランキングの類型などにより統合されたＤＢ（ｄａｔａｂａｓｅ）とゲームＡＰＩサーバーを自動生成／提供することができる。

本発明の実施例によると、複数のゲームサーバーにサービスを提供するマルチテナンシー（ｍｕｌｔｉ−ｔｅｎａｎｃｙ）環境のクラウドサービスであり得、テナント別にサービスを提供することができる。

既存の場合、ゲーム開発者が別途のゲームＡＰＩサーバーを製作する段階を経なければならなかったのに対し、本発明の実施例に係るゲームＢａａＳは別途のゲームＡＰＩサーバーの製作段階を経ることなくゲームアプリケーションを開発することができる。

図３は、本発明の実施例に係るクラウド基盤でゲームＡＰＩサーバーを提供する方法を示した概念図である。

図３ではゲームＢａａＳのためのネットワークが開示される。

図３を参照すると、ＢａａＳ管理サーバーは、クラウド基盤マルチテナンシー（ｍｕｌｔｉ−ｔｅｎａｎｃｙ）環境でそれぞれのテナント（例えば、ゲームサーバー）と連動してゲームＡＰＩサーバーを提供することができる。

ゲームＡＰＩサーバーにはゲーム開発者が活用可能なＡＰＩが具現されている。ゲーム開発者はゲームＡＰＩサーバーに具現された提供可能なＡＰＩのうち、ゲームに必要なＡＰＩを選択的に活用してゲームを具現することができる。

ＢａａＳ管理サーバーは、あらかじめ提供可能なすべてのＡＰＩが具現されたゲームＡＰＩサーバーをゲーム開発者に提供してもよく、ゲーム開発者が必要とするＡＰＩのみが具現されたゲームＡＰＩサーバーをゲーム開発者に提供してもよい。

また、ＢａａＳ管理サーバーは、ゲームを遂行するために提供されたＡＰＩサーバーにかかる負荷をチェックして、ゲームＡＰＩサーバーに対するスケールアップ（ｓｃａｌｅ ｕｐ）／スケールアウト（ｓｃａｌｅ ｏｕｔ）を遂行することができる。本発明の実施例に係るＢａａＳ管理サーバーは、別途の予測部または予測サーバーを通じてゲームＡＰＩサーバーの負荷（例えば、ＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）負荷、メモリー負荷など）を予測することができる。ＢａａＳ管理サーバーの予測部（または別途の予測サーバー）はゲームＡＰＩサーバーの負荷を予測するために、実際のゲーム開発者に提供されるゲームＡＰＩサーバーではない別途のゲームＡＰＩサーバーに基づいて負荷予測を遂行することができる。

本発明のように複数のクライアント（ゲームサーバー）にサービスを提供するマルチテナンシー（ｍｕｌｔｉ−ｔｅｎａｎｃｙ）環境のクラウドサービスは、テナント別にトラフィック調節が必要である。トラフィック調節はオートスケーリングである程度対処ができるのであるが、オートスケーリングの呼び出し規則は運営データを蓄積した後でのみ生成が可能な問題がある。テナントは本発明の実施例に係るＢａａＳ管理サーバーによってサービスされるゲームサーバーであり得る。本発明の実施例に係るＢａａＳ管理サーバーは、複数のテナントにサービスを提供するマルチテナンシー環境のクラウドサービスを提供することができる。

また、ゲームＢａａＳはより簡単にアプリケーションとゲームＡＰＩサーバーの連結のためのＳＤＫ（ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）が提供されて、既存のアプリケーションとゲームＡＰＩサーバーとの連結のための複雑なコード（例えば、１００行）の代わりに簡単なコード（例えば、２行）を通じてアプリケーションとゲームＡＰＩサーバー間の連結が遂行され得る。

本発明の実施例に係るＢａａＳ基盤のマルチテナンシーサービスはＩａＣ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ Ｃｏｄｅ）で構成されたサーバーインフラとＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）ＡＰＩ、クライアント用ＳＤＫで構成され、ＲＥＳＴ ＡＰＩはバックエンドとクライアント間のインターフェースを担当し、ＳＤＫからＲＥＳＴ ＡＰＩに接近する時点と回数などの指標を収集することができる。

図４は、本発明の実施例に係るゲームＡＰＩサーバーを通じてのサービス提供方法を示した概念図である。

図４ではゲーム開発者装置でＢａａＳ管理サーバーによって提供されたゲームＡＰＩサーバーに基づいてゲーム上で必要な機能を具現する方法が開示される。

図４を参照すると、ゲーム開発者装置（またはゲームサーバー）は開発しようとするゲームのプロジェクトの名前を設定し、ゲームのプロジェクト類型を選択することができる。例えば、ゲーム開発者がスポーツゲームを開発しようとする場合、プロジェクト類型でスポーツゲームが選択され得る。

また、ゲーム開発者装置はＢａａＳ管理サーバーによって提供されるゲームＡＰＩサーバーのうち、キャラクターＡＰＩサーバー、スキルＡＰＩサーバー、アイテムＡＰＩサーバーなどを選択することができる。既存のゲーム開発者の場合、ゲームの開発時にゲームで使われるキャラクター、スキル、アイテムなどの開発／具現のための別途のバックエンドＡＰＩサーバーを設定し、別途にキャラクター、スキル、アイテムのための機能を開発した。

しかし、本発明の実施例に係るゲームＡＰＩサーバーは、スポーツゲームのキャラクター、スキル、アイテムなどの開発／設定のためのキャラクターＡＰＩサーバー、スキルＡＰＩサーバー、アイテムＡＰＩサーバーを含み、ゲーム開発者は必要なＡＰＩサーバーを選択的に活用することができる。ゲーム開発者はゲーム上で使われるキャラクター、スキル、アイテムなどの機能のための別途のバックエンドＡＰＩサーバーの設定およびキャラクター、スキル、アイテムのための機能を開発する必要なく、ゲームＡＰＩサーバーに含まれるキャラクターＡＰＩサーバー、スキルＡＰＩサーバー、アイテムＡＰＩサーバーを通じてゲームに使われるキャラクター、スキル、アイテムの特性を設定することによって、簡単にゲームのためのキャラクター、スキル、アイテムを開発することができる。このようなゲームＡＰＩサーバーは、ゲームＡＰＩサーバーグループにグルーピングして提供されてもよい。

また、ゲーム開発者装置を通じてサーバーの状態、サーバーの自動拡張の有無などがさらに設定され得る。

左側を参照すると、ゲームＢａａＳはイベント管理機能、ゲーム情報管理機能、維持管理機能、プッシュ発送機能、エラー報告書機能、ゲームログ機能、ランキング管理機能、サーバー設定機能などを提供することができる。

例えば、ゲーム情報管理機能を通じて、ゲームに関連したキャラクター、スキル、アイテムなどの開発のためのゲームＡＰＩサーバーが提供され得る。プッシュ発送機能を通じてゲームユーザーにプッシュ発送のためのゲームＡＰＩサーバーが提供され得る。また、ゲームログ機能を通じてソーシャルログインのためのゲームＡＰＩサーバーが提供され得る。これだけでなく、公知管理機能、会員管理機能などのためのゲームＡＰＩサーバーがＢａａＳを通じて提供され得る。

図５は、本発明の実施例に係るモバイルゲームサーバーに特化したトラフィック需要予測方法を示した概念図である。

図５を参照すると、ゲームＢａａＳは曜日別トラフィックを分類した後、パターンについての検索を遂行することができる。Ｉｎｔｅｌｌｉｇｅｎｃｅ Ｌｏａｄ Ｂａｌａｎｃｅｒ（以下、ＩＬＢ）が適用されたモバイルゲームサーバーは、別途の測定、分析過程を進行せずとも自動サーバー拡張機能（Ｓｃａｌｅ Ｏｕｔ）を適用することができる。

モバイルゲームはトラフィックが分散せず、特定期間に集中する特徴を示す。ＩＬＢはあらかじめ定義されたイベントカレンダーを活用して、異常なトラフィックの発生に先制して対応することができる。ＩＬＢを活用するモバイルゲームサーバーはトラフィック急増の状況においても自動サーバー拡張によって、中断することなく運営が可能である。ＩＬＢはゲームＡＰＩサーバーに対する自動スケールアップ（Ａｕｔｏ Ｓｃａｌｅ Ｕｐ）と自動スケールアウト（Ａｕｔｏ Ｓｃａｌｅ Ｏｕｔ）を自動で遂行することができる。

図６は、本発明の実施例に係るゲームＡＰＩサーバー運営方法を示した概念図である。

既存の場合、物理的サーバー拡張（Ｓｃａｌｅ Ｏｕｔ）を支援するモバイルゲームサーバーを構築するためには、単一サーバー、スケールアップ（Ｓｃａｌｅ Ｕｐ）、スケールアウト（Ｓｃａｌｅ Ｏｕｔ）環境をすべて経験した高級なサーバー人材が要求される。しかし、スケールアウトサーバー構築経験を保有した高級な技術人材は全体のサーバー開発人材のうち極少数であり、このため、中規模以下のゲーム開発社はスケールアウト（Ｓｃａｌｅ Ｏｕｔ）を構成することができず、サーバーの障害に積極的に対応することができずにいる。このため、ゲームの成功時点から（同時接続１０，０００人以上／単一サーバー対応不可）サーバー障害が発生してサービスが失敗する矛盾的な状況が発生している。

本発明の実施例に係るゲームＢａａＳはゲームジャンル／定形化されたトラフィックパターンでＳｃａｌｅ Ｏｕｔルールを設定するため、高級な技術人材がないＳｃａｌｅ Ｏｕｔ使用を支援することができる。

以下、本発明の実施例では具体的なＢａａＳ構造とＢａａＳの動作が開示される。

図７は、本発明の実施例に係るＢａａＳ管理サーバーの構造を示した概念図である。

図７を参照すると、ＢａａＳ管理サーバーは複数の階層構造を有することができる。複数の階層構造は、ビジネスレイヤ（ｂｕｓｉｎｅｓｓ ｌａｙｅｒ）７００、キャッシュレイヤ（ｃａｃｈｅ ｌａｙｅｒ）７１０、パーシステンスレイヤ（ｐｅｒｓｉｓｔｅｎｃｅ ｌａｙｅｒ）７２０、分析レイヤ（ａｎａｌｙｓｉｓ ｌａｙｅｒ）７３０を含むことができる。

ビジネスレイヤ７００は、複数のゲームＡＰＩサーバーを含むことができる。複数のゲームＡＰＩサーバーはゲーム開発者が使う機能を提供するためのサーバーであり得る。例えば、複数のゲームＡＰＩサーバーは、会員加入ＡＰＩサーバー、ログインＡＰＩサーバー、アイテムＡＰＩサーバー、キャラクターＡＰＩサーバーなどを含むことができる。ＢａａＳを利用するゲーム開発者装置および／またはゲームサーバー（以下、ゲームサーバー）は、複数のＡＰＩサーバーのうち少なくとも一つのＡＰＩサーバーと連動してゲームで必要な機能を使用者装置に提供することができる。ＢａａＳ管理サーバーからゲームサーバーに提供されるＳＤＫ（ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）に基づいて、ゲーム開発者はＢａａＳ管理サーバーで提供される複数のゲームＡＰＩサーバーを活用することができる。

ＢａａＳ管理サーバーは、会員加入、ログイン、アイテム、チャート、ランキング、決済などと標準化された機能をドッカ―イメージ（ｄｏｃｋｅｒ ｉｍａｇｅ）に作ってテンプレートで活用することがである。新規ゲームサーバー生成時に保存されたドッカ―イメージは呼び出しされたサーバーに配布され、ゲームサーバーの生成とともにゲームＡＰＩサーバーが活性化され得る。

ゲームサーバーから複数のゲームＡＰＩサーバーのそれぞれを通じて伝送される情報は、キャッシュレイヤ７１０および／またはパーシステンスレイヤ７２０のようなデータ保存階層に保存され得る。例えば、ゲームサーバーがＢａａＳ管理サーバーに含まれるログインＡＰＩサーバーを通じて使用者ログイン機能が提供される場合、使用者ログイン情報がゲームＡＰＩサーバーを通じてキャッシュレイヤ７１０および／またはパーシステンスレイヤ７２０に保存され得る。ゲームＡＰＩサーバーは必要に応じてキャッシュレイヤ７１０および／またはパーシステンスレイヤ７２０に保存されたデータを呼び出すことができ、キャッシュレイヤ７１０および／またはパーシステンスレイヤ７２０は呼び出しされたデータをゲームＡＰＩサーバーに提供することができる。

キャッシュレイヤ７１０はメモリマップ（ｍｅｍｏｒｙ ｍａｐ）基盤の高速ＡＰＩ照会機能を提供することができる。キャッシュレイヤ７１０は複数のＡＰＩサーバーを通じて頻繁に呼び出されるデータを保存するために具現され得る。キャッシュレイヤ７１０はパーシステンスレイヤ７２０で保存／管理されるデータのうち、迅速な処理が必要であるか頻繁に呼び出されるデータを保存することができる。

パーシステンスレイヤ７２０はデータ処理（データの生成／修正／削除／選択（検索））を担当する階層である。パーシステンスレイヤ７２０は複数のＡＰＩサーバーの動作のためのデータ保存／管理のために具現され得る。

下記の表１はパーシステンスレイヤ７２０とキャッシュレイヤ７１０のそれぞれのストレージソリューションとタイプを例示的に示した表である。

分析レイヤ７３０はＢａａＳ管理サーバーの状態分析を通じてビジネスレイヤ７００、キャッシュレイヤ７１０、パーシステンスレイヤ７２０の動作に対する管理のために具現され得る。

分析レイヤ７３０は複数のゲームＡＰＩサーバーの負荷バランシングのためのＩＬＢ（Ｉｎｔｅｌｌｉｇｅｎｃｅ Ｌｏａｄ Ｂａｌａｎｃｅｒ）としての役割を遂行することができる。分析レイヤ７３０は、一定期間（例えば、曜日／時間）別トラフィックを収集してオートスケール（Ａｕｔｏ Ｓｃａｌｅ）呼び出し規則を動的に生成する。ゲームサーバー運営者は、高級なサーバー管理人材がなくてもオートスケール（Ａｕｔｏ Ｓｃａｌｅ）環境を利用することができ、ＩＬＢが適用されたモバイルゲームサーバーはトラフィック急増状況においても中断することなく運営され得る。

また、分析レイヤ７３０はキャッシュレイヤ７１０で保存／管理されるデータ、パーシステンスレイヤ７２０で保存／管理されるデータを決定し、キャッシュレイヤ７１０および／またはパーシステンスレイヤ７２０上でデータに対する保存／管理を遂行することがである。

図８は、本発明の実施例に係るＢａａＳの動作を示した概念図である。

図８ではゲームサーバーと連動する複数のゲームＡＰＩサーバーに対する管理方法が開示される。

図８を参照すると、ゲームサーバー８１０、８２０、８３０がＢａａＳを要請する場合、複数のゲームＡＰＩサーバーがゲームサーバー８１０、８２０、８３０と連動して動作することができる。ＢａａＳは複数のゲームのそれぞれのための複数のゲームサーバー８１０、８２０、８３０と連動して動作することができ、ＢａａＳによって提供される複数のゲームＡＰＩサーバーはゲームサーバー８１０、８２０、８３０とマッチングされ得る。

複数のゲームＡＰＩサーバーは多様な方式でゲームサーバーと対応することができる。

例えば、複数のゲームＡＰＩサーバーがゲームＡＰＩサーバーグループのそれぞれ８５０、８６０にグルーピングされ、ゲームＡＰＩサーバーグループ８５０、８６０は少なくとも一つのゲームサーバー８１０、８２０、８３０とマッチングされ得る。一つのゲームＡＰＩサーバーグループ８５０、８６０はＢａａＳで提供されるすべてのＡＰＩの集合であり得る。例えば一つのゲームＡＰＩサーバーグループ８５０、８６０は、会員加入ＡＰＩ、ログインＡＰＩ、アイテムＡＰＩ、チャートＡＰＩ、ランキングＡＰＩ、決済ＡＰＩなどを含むことができる。

例えば、ゲームサーバー１ ８１０により要求される処理量が一つのゲームＡＰＩサーバーグループ１ ８５０を通じて処理可能な臨界処理量を超過する場合、他の複数のゲームＡＰＩサーバーグループ２ ８６０がゲームサーバー１ ８１０と追加的にマッチングされてゲームサーバー１ ８１０により要求される処理量を満足させることができる。

その反対に、ゲームサーバー１ ８１０により要求される処理量が一つのゲームＡＰＩサーバーグループ１ ８５０を通じて処理可能な臨界処理量より小さい場合、ＢａａＳ管理サーバーに基づいてサービスが提供される他のゲームサーバー８２０がゲームサーバー１ ８１０と同じゲームＡＰＩサーバーグループ１ ８５０を使ってサービスが提供され得る。すなわち、一つのゲームＡＰＩサーバーグループ１ ８５０が複数の互いに異なるゲームサーバー８１０、８２０にサービスを提供することができる。

前記のような方式で、複数のゲームＡＰＩサーバーグループの処理量を考慮してサーバー拡張／サーバー縮小のようなスケーリングが遂行され得る。分析レイヤはゲームサーバーによって要求される処理量に対する分析を通じてゲームＡＰＩサーバーグループとゲームサーバー間のマッチング関係を設定して、サーバー拡張、サーバー維持またはサーバー縮小のようなサーバーに対するスケーリングの有無を決定し、サーバースケーリングを遂行することができる。

図９は、本発明の実施例に係るＢａａＳ管理サーバーの動作を示した概念図である。

図９ではゲームサーバーと連動する複数のゲームＡＰＩサーバーに対する管理方法が開示される。

図９を参照すると、ＢａａＳとして提供される複数のゲームＡＰＩサーバーのうち少なくとも一つのゲームＡＰＩサーバーが分離され、分離された少なくとも一つのゲームＡＰＩサーバーに基づいてＢａａＳがゲームサーバーに提供され得る。

分析レイヤの分析結果、ビジネスレイヤに含まれる複数のゲームＡＰＩサーバーのうち処理量が多いゲームＡＰＩサーバーに対する分離が進行され得、分離されたゲームＡＰＩサーバーに別途のサーバー資源に対する割当およびサーバー資源に対する管理が遂行されてＢａａＳが提供され得る。

例えば、分析レイヤの分析結果、ゲームＡＰＩサーバーグループ９００に含まれる会員加入ＡＰＩ、ログインＡＰＩ、アイテムＡＰＩ、チャートＡＰＩ、ランキングＡＰＩ、決済ＡＰＩのうち、ログインＡＰＩ処理量が臨界処理量以上であり得る。このような場合、ログインＡＰＩ９２０はゲームＡＰＩサーバーグループ９００から分離されて分離ゲームＡＰＩサーバーグループ９５０として管理され得る。

分析レイヤは、分離ゲームＡＰＩサーバーグループ９５０に対して別途のサーバースケーリングを適用してゲームサーバーにサービスを提供することができる。例えば、ゲームサーバー１およびゲームサーバー２は、ゲームＡＰＩサーバーグループ１を通じて会員加入ＡＰＩ、ログインＡＰＩ、アイテムＡＰＩ、チャートＡＰＩ、ランキングＡＰＩ、決済ＡＰＩ機能が提供され得、ゲームサーバー１およびゲームサーバー２で要求される処理量によりゲームＡＰＩサーバーグループ１に割り当てられるサーバーが拡張または減少し得る。

ゲームサーバー１は分離ＡＰＩサーバーグループ１を通じてログインＡＰＩ機能が提供され得、ゲームサーバー２は別途の分離ＡＰＩサーバーグループ２を通じてログインＡＰＩ機能が提供され得る。ゲームサーバー１で要求されるログイン関連処理量により分離ＡＰＩサーバーグループ１に含まれるサーバーのスケーリングが遂行され得る。ゲームサーバー２で要求されるログイン関連処理量により分離ＡＰＩサーバーグループ２に含まれるサーバーの拡張／縮小が遂行され得る。

すなわち、分離レイヤの決定により、ゲームＡＰＩサーバーグループに含まれる複数のゲームＡＰＩサーバーのうち少なくとも一つのゲームＡＰＩサーバーに対する別途分離が進行され得る。ゲームＡＰＩサーバーグループと分離ゲームＡＰＩサーバーグループは別途のサーバースケーリングが適用され得る。

図１０は、本発明の実施例に係るＢａａＳ管理サーバーの動作を示した概念図である。

図１０ではゲームサーバーと連動する複数のゲームＡＰＩサーバーに対する管理方法が開示される。特に、時間による複数のゲームＡＰＩサーバー管理方法が開示される。

図１０を参照すると、ＢａａＳ管理サーバーは時間による複数のゲームＡＰＩサーバーのそれぞれの処理量を収集し、時間による複数のゲームＡＰＩサーバーのそれぞれの処理量を予測して複数のゲームＡＰＩサーバーをグルーピングすることができる。

ＢａａＳ管理サーバーは、複数のゲームサーバーとマッチングされる複数のゲームＡＰＩサーバーグループと複数のゲームＡＰＩサーバーグループに含まれる複数のゲームＡＰＩサーバーのそれぞれに対する時間帯別処理量分析を遂行することができる。以下、ＡＰＩサーバーはゲームＡＰＩサーバーを意味し得る。

第１ゲームＡＰＩサーバーグループ１０１０は、第１ＡＰＩサーバー１ １０１３、第１ＡＰＩサーバー２ １０１６、第１ＡＰＩサーバー３ １０１９を含むことができる。

第２ゲームＡＰＩサーバーグループ１０２０は、第２ＡＰＩサーバー１ １０２３、第２ＡＰＩサーバー２ １０２６、第２ＡＰＩサーバー３ １０２９を含むことができる。

第３ゲームＡＰＩサーバーグループ１０３０は第３ＡＰＩサーバー１ １０３３、第３ＡＰＩサーバー２ １０３６、第３ＡＰＩサーバー３ １０３９を含むことができる。

例えば、ＡＰＩサーバー１ １０１３、１０２３、１０３３はログインサーバー、ＡＰＩサーバー２ １０１６、１０２６、１０３６は会員加入サーバー、ＡＰＩサーバー３ １０１９、１０２９、１０３９はアイテムサーバーであり得る。

時間による処理量を考慮して（第１ＡＰＩサーバー１ １０１３、第１ＡＰＩサーバー２ １０１６、第１ＡＰＩサーバー３ １０１９）、（第２ＡＰＩサーバー１ １０２３、第２ＡＰＩサーバー２ １０２６、第２ＡＰＩサーバー３ １０２９）、（第３ＡＰＩサーバー１ １０３３、第３ＡＰＩサーバー２ １０３６、第３ＡＰＩサーバー３ １０３９）、それぞれが適応的にグルーピングされ得る。

全体時間は複数の時間区間に分割され得、複数の時間区間によりゲームＡＰＩサーバーグループが変化され得る。

第１時間に（第１ＡＰＩサーバー１（１０）１０１３、第１ＡＰＩサーバー２（２０）１０１６、第１ＡＰＩサーバー３（３０）１０１９）、（第２ＡＰＩサーバー１（３０）１０２３、第２ＡＰＩサーバー２（１０）１０２６、第２ＡＰＩサーバー３（２０）１０２９）、（第３ＡＰＩサーバー１（５０）１０３３、第３ＡＰＩサーバー２（１０）１０３６、第３ＡＰＩサーバー３（１０）１０３９）の処理量が必要な場合が仮定され得る。サーバーのそばの括弧は処理量を数値で任意的に表現したものである。

前記のっような場合、第１ＡＰＩサーバー１（１０）１０１３、第２ＡＰＩサーバー１（３０）１０２３、第２ＡＰＩサーバー２（１０）１０２６、第３ＡＰＩサーバー１（５０）１０３３が第１′ゲームＡＰＩサーバーグループ１０５０に設定され、第１ＡＰＩサーバー２（２０）１０１６、第１ＡＰＩサーバー３（３０）１０１９、第２ＡＰＩサーバー３（２０）１０２９、第３ＡＰＩサーバー２（１０）１０３６、第３ＡＰＩサーバー３（１０）１０３９が第２′ゲームＡＰＩグループ１０５０に設定されてゲームサーバーの要請を処理することができる。

前記のように、時間によるゲームＡＰＩサーバー別の必要処理量を考慮して、適応的にゲームＡＰＩグループを再グルーピングすることができ、それにより必要なサーバー資源の量を減少させつつ、効率的にサーバースケーリングが遂行され得る。

図１１は、本発明の実施例に係るマルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法を示した概念図である。

図１１を参照すると、本発明のように複数のクライアント（ゲームサーバー）にサービスを提供するマルチテナンシー環境のクラウドサービス１１００は、複数のテナント１１１０、１１２０、１１５０のそれぞれに対する適応的なトラフィック調節が必要である。テナント１１１０、１１２０、１１５０は本発明の実施例に係るＢａａＳ管理サーバーによってサービスされるゲームサーバーであり得る。トラフィック調節は既存のオートスケーリングである程度対処が可能であるが、現在のオートスケーリングの呼び出し規則は運営データの蓄積後に人によって設定されて生成されている。すなわち、マルチテナンシー環境のクラウドサービス１１００では、運営データが十分に蓄積される時までオートスケーリングが正常に動作しない可能性があり、人の判断によるオートスケーリング呼び出し規則の設定は結果として、それぞれのテナント１１１０、１１２０、１１５０のサービスの初期にトラフィック拡張に正常に対応することができない。

テナント１１１０、１１２０、１１５０のサービスの性格により曜日、時間などのトラフィック運営データは互いに異なるため、すでに作られたオートスケーリング呼び出し規則をリサイクルすることも難しい。また、オートスケーリング呼び出し規則は人間の経験に基づくため、人が直接設定しなければならない問題がある。このような理由によって、マルチテナンシークラウドサーバーを使うテナント１１１０、１１２０、１１５０は、サービスの初期に発生するトラフィック障害に積極的に対応することができない。

本発明の実施例に係るマルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法では、最小限の運営データだけでテナント別オートスケーリング呼び出し規則を生成し、また、オートスケーリング呼び出し規則を自動で遂行することを目標とする。

マルチテナンシー環境で、各テナント１１１０、１１２０、１１５０はマルチテナンシー事業者（ＢａａＳ提供者）が提供するアーキテクチャーとインターフェースで自分のサービスを運営する。これはテナント１１１０、１１２０、１１５０間のサービスが異なっても使うバックエンドインフラとインターフェースが同じであることを意味し得る。

したがって、個別テナント１１１０、１１２０、１１５０が使うインタフェース別呼び出し時点、呼び出し回数などを収集すればパターン化することが可能である。テナント１１１０、１１２０、１１５０別によく呼び出すインターフェースでトラフィックが集中される曜日と時間情報などの運営データを収集して規則を探すのである。前述した通り、ＢａａＳ基盤のマルチテナンシーサービスは、ＩａＣ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ Ｃｏｄｅ）で構成されたサーバーインフラとＲＥＳＴ ＡＰＩ、クライアント用ＳＤＫで構成され得る。このうちＲＥＳＴ ＡＰＩがバックエンドとクライアント間のインターフェースを担当し、ＳＤＫからＲＥＳＴ ＡＰＩに接近する時点と回数などの指標を収集することができる。ＲＥＳＴ ＡＰＩはビジネスレイヤに含まれ得る。

分析レイヤはテナント１１１０、１１２０、１１５０別に運営データを収集して規則を生成することができる。分析レイヤは柔軟に拡張可能なデータ保存所、運営データを収集するログ収集器、収集した運営データを分析して規則として出力するデータ視角化道具を含むことができる。分析レイヤ上でまずテナント１１１０、１１２０、１１５０別運営データをデータ保存所に収集することができる。運営データの収集は分析レイヤのログ収集器が担当し、マルチテナントのためのＩａＣインフラにログ収集器をあらかじめ内蔵して収集を進行することができる。ログ収集器によって収集されるデータは、インタフェース呼び出し時間（ＹＹＭＭＤＤＨＨＭＭ）と呼び出したインタフェース、インターフェースに伝達されるパラメーターである。

このうち最も重要なものは呼び出し時間データである。呼び出し時間は分単位で収集され得る。オートスケールが遂行される時間が数分単位であるため、秒またはマイクロ秒単位の運営データを収集することは、オートスケーリング規則生成の目的に符合せず、コンピューティングパワーの浪費要因となり得る。

運営データは個別テナント別データと多重テナント別データに区分することができる。個別テナント別データは個別テナントと関連した運営データであり、多重テナント別データは多重テナントと関連した運営データであり得る。

個別テナントの主な運営データは曜日別トラフィック情報、時間別トラフィック情報、イベント別トラフィック情報を含むことができる。

曜日別トラフィック情報は曜日別トラフィックに対する情報を含むことができる。すべてのサービスはサービスの特性により曜日別トラフィックが異なる。サービス別曜日別トラフィック情報検索、登録要請を通じて曜日別トラフィック推移に対する情報が収集され得る。

時間帯別トラフィック情報は時間帯別トラフィックに対する情報を含むことができる。サービスの特性により時間帯別トラフィック推移は異なり、特定の時間帯に９０％以上のトラフィックが集中されるサービスも存在する。このような類型のサービスを提供するテナント１１１０、１１２０、１１５０は、マルチテナンシー環境でトラフィック管理をすることが非常に難しい。したがって、時間帯別トラフィック推移情報検索、登録要請を通じて時間帯別トラフィック推移に対する情報が収集され得る。

イベント別トラフィック情報はイベント別トラフィックに対する情報を含むことができる。ゲームサービスを例にすると、休みシーズンにトラフィックが急増するパターンを示し、ウェブ漫画サービスは子供の日、クリスマスなど公休日にトラフィックが増加するパターンを示し得る。サービスを提供する地域の公休日、休みなど、時間に影響を与える特徴を「イベント」と通称して呼び、イベント情報は国家別に異なり得る。このようなイベント情報をデータ視角化道具に登録すればイベント別トラフィックを分析することができる。

分析レイヤは曜日別トラフィック情報、時間別トラフィック情報、イベント別トラフィック情報を分析してトラフィックパターンを定義し、オートスケーリング呼び出し規則を設定することができる。定義されたトラフィックパターン情報により設定されたオートスケーリング呼び出し規則は、オートスケーリング呼び出し規則システムが接近して使用できるパーシステンスレイヤの関係データベースなどに保存することができる。

本発明の実施例によると、曜日別トラフィック情報および時間別情報に基づいて下記のようにトラフィックパターンが定義され、オートスケーリング呼び出し規則が設定され得る。

まずゲームＡＰＩサーバーグループに含まれる複数のゲームＡＰＩサーバーのそれぞれに対するゲームＡＰＩサーバー呼び出し記録が収集され得る。ゲームＡＰＩサーバー呼び出し記録は、時間（年／月／日／時間／分、ＹＹＭＭＤＤ ＨＨ：ＭＭ）、呼び出したＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）、伝達されたパラメーターに対する情報を含むことができる。

１日単位集計の終了後にゲームＡＰＩ呼び出し記録に基づいて分単位で呼び出し数が集計され得る。例えば、ログインＡＰＩサーバーに対して一日が分単位に分割されて分単位呼び出し数が集計され得る。すなわち、複数のゲームＡＰＩサーバーのそれぞれに対するＡＰＩ呼び出し記録に基づいて複数のゲームＡＰＩサーバーのそれぞれに対する分単位呼び出し数が集計され得る。

週単位で前記のような過程が繰り返され、一日単位で集計された複数のゲームＡＰＩサーバーのそれぞれに対する分単位呼び出し数に基づいて、複数のゲームＡＰＩサーバーのそれぞれに対する曜日別分単位占有率が算出され得る。曜日別分単位占有率は週単位でグルーピングされて複数のゲームＡＰＩサーバーのそれぞれに対して週単位曜日別分単位占有率が算出され得る。例えば、現在の時点を基準として、１週間前（月曜日分単位占有率１、火曜日分単位占有率１、水曜日分単位占有率１、木曜日分単位占有率１、金曜日分単位占有率１、土曜日分単位占有率１、日曜日分単位占有率１）、２週間前（月曜日分単位占有率２、火曜日分単位占有率２、水曜日分単位占有率２、木曜日分単位占有率２、金曜日分単位占有率２、土曜日分単位占有率２、日曜日分単位占有率２）、３週間前（月曜日分単位占有率３、火曜日分単位占有率３、水曜日分単位占有率３、木曜日分単位占有率３、金曜日分単位占有率３、土曜日分単位占有率３、日曜日分単位占有率３）等のように、複数のゲームＡＰＩサーバーのそれぞれに対して週単位曜日別分単位占有率が算出され得る。

週単位曜日別分単位占有率に基づいて該当曜日別に複数のゲームＡＰＩサーバーのそれぞれに対する日別分単位占有率の平均値が算出され得る。例えば、ゲームＡＰＩサーバーのうち、アイテムＡＰＩサーバーの月曜日分単位占有率平均値、火曜日分単位占有率平均値等が決定され得る。

本発明の実施例によると、複数のゲームＡＰＩサーバーのそれぞれに対する日別分単位占有率平均値を算出時に、現在の時点を基準として隣接した値であるほど高い加重値を設定して加重平均値が算出されてもよい。現在の時点を基準として１週間前の日別分単位占有率は２週間前の日別分単位占有率より高い加重値が割り当てられ、加重値を適用した加重平均値が日別分単位占有率の平均値が算出され得る。

複数のゲームＡＰＩサーバーのそれぞれに対する日別分単位占有率平均値を考慮して、サーバースケーリングが必要な区間（または時点）に対する情報（または変曲点情報）を保存部（例えば、ＲＤＢＭＳ（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ））に登録することができる。ＲＤＢＭＳはパーシステンスレイヤに含まれたデータ保存構造である。

ＲＤＢＭＳに登録されたサーバースケーリングが必要な区間（または時点）に対する情報に基づいて、スケーリングスケジューラーサーバーにオートスケーリングのためのスケジュールが登録され、このようなオートスケーリングのためのスケジュールに基づいて複数のゲームＡＰＩサーバーのそれぞれに割り当てられるサーバー資源をスケーリングすることができる。

また、本発明の実施例によると、イベント別トラフィック情報に基づいて下記のようにトラフィックパターンが定義され、オートスケーリング呼び出し規則が設定され得る。

モバイルゲームの寿命が短い可能性があるため、年単位イベントに対する記録に基づいてオートスケーリング呼び出し規則を設定することは無意味な場合があり得る。例えば、特定ゲームに対して２０１７年子供の日にゲーム関連イベントを提供した場合、該当データを２０１８年子供の日に使ってトラフィックを予測するのは無意味であり得る。また、一つの地域内で提供されたイベントは平均的な効果を有し得る。

前述した方法に基づいて複数のゲームＡＰＩサーバーのそれぞれに対する日別分単位占有率に対する情報を知っている場合、分析レイヤにイベント日が登録され、イベント登録日が終了すると、複数のゲームＡＰＩサーバーのそれぞれに対してイベント登録日の分単位占有率と最近の該当曜日の分単位占有率を比較して占有率の増減幅が決定され得る。占有率の増減幅は複数のゲームＡＰＩサーバーのそれぞれに対して決定され得る。

複数のイベントに対してイベント時のゲーム別占有率の増減幅が決定され、複数のイベントに対するイベント時のゲーム別占有率の増減幅の平均値が決定され得る。

本発明の実施例によると、イベントの種類別にイベント時のゲーム別占有率の増減幅の平均値が決定されてもよい。例えば、イベントカテゴリー（例えば、会員加入イベント、アイテム贈呈イベントなど）を分類してイベントカテゴリー別ゲーム別占有率の増減幅の平均値が決定されてもよく、遂行されるイベントのカテゴリーによりイベントカテゴリー別ゲーム別占有率の増減幅の平均値を基盤とした複数のゲームＡＰＩサーバーのそれぞれに対するオートスケーリングが遂行され得る。

イベント時のゲーム別占有率の増減幅の平均値（またはイベントカテゴリー別ゲーム別占有率の増減幅の平均値）に対する情報が保存部（例えば、ＲＤＢＭＳ）に登録され得る。保存部に保存されたイベント時のゲーム別占有率の増減幅の平均値（またはイベントカテゴリー別ゲーム別占有率の増減幅の平均値）に対する情報と日別分単位占有率の平均値に対する情報に基づいてイベント時のオートスケーリングのためのスケジュールが登録され得、このようなオートスケーリングのためのスケジュールに基づいて複数のゲームＡＰＩサーバーのそれぞれに割り当てられるサーバー資源がスケーリングされ得る。例えば、水曜日にアイテム贈呈イベントが遂行される場合、複数のゲームＡＰＩサーバーのそれぞれに対する、１）アイテム贈呈イベント時のゲーム別占有率の増減幅の平均値と水曜日分単位占有率の平均値に基づいて複数のゲームＡＰＩサーバーのそれぞれに割り当てられるサーバー資源に対するオートスケーリングが遂行され得る。

図１２は、本発明の実施例に係るテナント別オートスケーリング呼び出し規則を自動で設定する方法を示した概念図である。

図１２を参照すると、テナント別トラフィック運営データを収集して分析する方法を通じてテナントのトラフィックパターン情報が定義されると、オートスケーリング呼び出し規則を設定することが可能である。

オートスケーリングが適用されなければならない部分は、ＲＥＳＴ ＡＰＩを担当するサーバーインスタンス（またはビジネスレイヤ）、データが保存されるパーシステンスレイヤである。したがって、サーバーインスタンスとパーシステンスレイヤはともにスケーリングが可能な環境であり得る。

本発明の実施例によると、オートスケーリング呼び出し規則を生成するために、１）呼び出し規則生成用サーバーコンピューティング資源、２）オートスケーリング呼び出し規則変更用サーバーコンピューティング資源、３）呼び出し規則変更用スケジューラーが必要である。１）、２）ともにＡＷＳ（Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ）Ｌａｍｂｄａ、Ａｚｕｒｅ Ｆｕｎｃｔｉｏｎなどのクラウドサービスの関数型マイクロサーバーで構成することができる。

以下では、呼び出し規則生成用サーバーコンピューティング資源は呼び出し規則生成器１２００、オートスケーリング呼び出し規則変更用サーバーコンピューティング資源は呼び出し規則変更器１２２０、呼び出し規則変更用スケジューラーはスケジューラー１２４０という用語で定義され得る。

呼び出し規則生成器１２００はスケジューラーにより定義されたパターンを登録することができる。スケジューラー１２４０には、オートスケーリングが遂行されなければならない曜日、時間、イベントと準備されなければならないサーバーコンピューティング資源、オートスケーリングが終了する時間が登録され得る。スケジューラー１２４０は定められた時間に呼び出し規則変更器を実行し、呼び出し規則変更器１２２０はスケジューラー１２４０に登録された曜日／時間／イベント／サーバーコンピューティング資源などをテナントのサーバーインフラに適用することができる。オートスケーリングパターンが終了する時間には基本的なオートスケーリング規則を復元適用してサーバーコンピューティングの浪費を防止することができる。

以上で説明された本発明に係る実施例は、多様なコンピュータ構成要素を通じて遂行され得るプログラム命令語の形態で具現されて、コンピュータ読み取り可能な記録媒体に記録され得る。前記コンピュータ読み取り可能な記録媒体は、プログラム命令語、データファイル、データ構造などを単独でまたは組み合わせて含むことができる。前記コンピュータ読み取り可能な記録媒体に記録されるプログラム命令語は、本発明のために特別に設計されて構成されたものであるかコンピュータソフトウェア分野の当業者に公知とされている使用可能なものであり得る。コンピュータ読み取り可能な記録媒体の例には、ハードディスク、フロッピーディスクおよび磁気テープのような磁気媒体、ＣＤ−ＲＯＭおよびＤＶＤのような光気録媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような磁気−光媒体（ｍａｇｎｅｔｏ−ｏｐｔｉｃａｌ ｍｅｄｉｕｍ）、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのような、プログラム命令語を保存して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令語の例には、コンパイラによって作られるような機械語コードだけでなく、インタープリタなどを使ってコンピュータによって実行され得る高級な言語コードも含まれる。ハードウェア装置は、本発明に係る処理を遂行するために一つ以上のソフトウェアモジュールに変更され得、その逆も同じである。

以上、本発明が具体的な構成要素などのような特定の事項と限定された実施例および図面によって説明されたが、これは本発明のより全般的な理解を助けるために提供されたものに過ぎず、本発明は前記実施例に限定されるものではなく、本発明が属する技術分野で通常の知識を有する者であれば、このような記載から多様な修正と変更を試みることができる。

したがって、本発明の思想は前記説明された実施例に限定されてさだめられてはならず、後述する特許請求の範囲だけでなくこの特許請求の範囲と均等なまたはこれから等価的に変更されたすべての範囲は本発明の思想の範疇に属するものと言える。

Claims (10)

1. マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則自動生成方法は、
   クラウド基盤のマルチテナンシー環境で動作するＢａａＳ（ｂａｃｋｅｎｄ ａｓ ａ ｓｅｒｖｉｃｅ）管理サーバーが複数のテナントからゲームＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーに対する要請を受信する段階；および
   前記ＢａａＳ管理サーバーが前記要請により前記ゲームＡＰＩサーバーを提供する段階を含むものの、
   前記複数のテナントは前記ゲームＡＰＩサーバーに基づいてゲームの開発および駆動に必要な機能が提供され、
   前記ＢａａＳ管理サーバーは、前記複数のテナントのそれぞれの曜日別トラフィック情報、時間帯別トラフィック情報およびイベント別トラフィック情報を含む運営データを分析してトラフィックパターンを定義し、前記トラフィックパターンを用いて前記テナントごとにオートスケーリング呼び出し規則を動的に生成し、
   前記オートスケーリング呼び出し規則に基づいて前記ゲームＡＰＩサーバーに対するオートスケーリングを遂行することを特徴とする、方法。
2. 前記ＢａａＳ管理サーバーは、呼び出し規則生成器を有し、
   前記呼び出し規則生成器は、前記運営データを分析して得られる前記トラフィックパターンを用いて、予め定められた時間に前記オートスケーリング呼び出し規則を変更することを特徴とする、請求項１に記載の方法。
3. 前記ゲームＡＰＩサーバーは前記複数のテナントによって提供されるゲームの駆動のための機能を提供し、
   前記ゲームＡＰＩサーバーは、会員加入ＡＰＩサーバー、ログインＡＰＩサーバー、アイテムＡＰＩサーバー、キャラクターＡＰＩサーバーのうち少なくとも一つを含むことを特徴とする、請求項２に記載の方法。
4. 前記ＢａａＳ管理サーバーが前記複数のテナントのそれぞれと前記ゲームＡＰＩサーバーの連結のためのＳＤＫ（ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）を提供する段階をさらに含み、
   前記ＳＤＫに基づいて前記ＢａａＳ管理サーバーと前記ゲームＡＰＩサーバーが連結され、
   前記ＢａａＳ管理サーバーは前記複数のテナントのそれぞれでＳＤＫに基づいて、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）ＡＰＩに接近する時点および回数に対する指標を収集して前記運営データを決定し、
   前記ＲＥＳＴ ＡＰＩは前記ＢａａＳ管理サーバーと複数のテナントのそれぞれ間のインターフェースを担当することを特徴とする、請求項３に記載の方法。
5. 前記ＢａａＳ管理サーバーはビジネスレイヤ、キャッシュレイヤ、パーシステンスレイヤおよび分析レイヤを含み、
   前記ビジネスレイヤは前記ゲームＡＰＩサーバーを含む複数のゲームＡＰＩサーバーを含み、
   前記キャッシュレイヤおよび前記パーシステンスレイヤはデータに対する保存および／または管理のために具現され、
   前記分析レイヤは前記複数のゲームＡＰＩサーバーに対するスケーリング、前記キャッシュレイヤと前記パーシステンスレイヤに保存されるデータを管理するために具現されることを特徴とする、請求項４に記載の方法。
6. マルチテナンシー環境での個別テナント別オートスケーリング呼び出し規則を自動生成するＢａａＳ（ｂａｃｋｅｎｄ ａｓ ａ ｓｅｒｖｉｃｅ）管理サーバーは、
   複数のテナントとの通信のために具現される通信部；および
   前記通信部と動作可能に（ｏｐｅｒａｔｉｖｅｌｙ）連結されたプロセッサを含むものの、
   前記プロセッサはクラウド基盤のマルチテナンシー環境で前記複数のテナントからゲームＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｉｎｇ ｉｎｔｅｒｆａｃｅ）サーバーに対する要請を受信し、
   前記要請により前記ゲームＡＰＩサーバーを提供するように具現されるものの、
   前記複数のテナントは前記ゲームＡＰＩサーバーに基づいてゲームの開発および駆動に必要な機能が提供され、
   前記プロセッサは、前記複数のテナントのそれぞれの曜日別トラフィック情報、時間帯別トラフィック情報およびイベント別トラフィック情報を含む運営データを分析してトラフィックパターンを定義し、前記トラフィックパターンを用いて前記テナントごとにオートスケーリング呼び出し規則を動的に生成し、
   前記オートスケーリング呼び出し規則に基づいて前記ゲームＡＰＩサーバーに対するオートスケーリングを遂行することを特徴とする、ＢａａＳ管理サーバー。
7. 前記運営データは、前記複数のテナントのそれぞれに対する曜日別トラフィック情報、時間帯別トラフィック情報およびイベント別トラフィック情報を含み、
   前記プロセッサは、呼び出し規則生成部を有し、
   前記呼び出し規則生成部は、前記運営データを分析して得られる前記トラフィックパターンを用いて、予め定められた時間に前記オートスケーリング呼び出し規則を変更することを特徴とする、請求項６に記載のＢａａＳ管理サーバー。
8. 前記ゲームＡＰＩサーバーは前記複数のテナントによって提供されるゲームの駆動のための機能を提供し、
   前記ゲームＡＰＩサーバーは、会員加入ＡＰＩサーバー、ログインＡＰＩサーバー、アイテムＡＰＩサーバー、キャラクターＡＰＩサーバーのうち少なくとも一つを含むことを特徴とする、請求項７に記載のＢａａＳ管理サーバー。
9. 前記プロセッサは、前記複数のテナントのそれぞれと前記ゲームＡＰＩサーバーの連結のためのＳＤＫ（ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｋｉｔ）を提供するように具現され、
   前記ＳＤＫに基づいて前記ＢａａＳ管理サーバーと前記ゲームＡＰＩサーバーが連結され、
   前記プロセッサは、前記複数のテナントのそれぞれでＳＤＫに基づいてＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）ＡＰＩに接近する時点および回数に対する指標を収集して前記運営データを決定し、
   前記ＲＥＳＴ ＡＰＩは前記ＢａａＳ管理サーバーと複数のテナントのそれぞれ間のインターフェースを担当することを特徴とする、請求項８に記載のＢａａＳ管理サーバー。
10. 前記プロセッサは、ビジネスレイヤ、キャッシュレイヤ、パーシステンスレイヤおよび分析レイヤを含み、
    前記ビジネスレイヤは前記ゲームＡＰＩサーバーを含む複数のゲームＡＰＩサーバーを含み、
    前記キャッシュレイヤおよび前記パーシステンスレイヤは、データに対する保存および／または管理のために具現され、
    前記分析レイヤは、前記複数のゲームＡＰＩサーバーに対するスケーリング、前記キャッシュレイヤと前記パーシステンスレイヤに保存されるデータを管理するために具現されることを特徴とする、請求項９に記載のＢａａＳ管理サーバー。

Images