GS2 Blog

Game Server Services(https://gs2.io/) の最新情報をお届けします

【新サービス】ゲーム内通貨の管理機能を追加

みなさんこんにちは。GS2の丹羽です。

本日は新サービスの提供開始を告知いたします。

新サービスは GS2-Gold というゲーム内通貨の管理機能です。
GS2では既に GS2-Money という課金通貨の管理機能を提供していますが、GS2-Gold は資金決済法に該当しないゲーム内通貨を管理出来る機能となっています。

GS2-Gold ではゲーム向け固有の機能として、一定期間内での取得量制限を設けることが出来るようになっています。
例えば、コンテンツをクリアすることで、ポイントが貯まる仕様があり、そのポイントでキャラクターの強化に必要な素材と交換出来るようにしたとします。
通常、このような仕様を追加した場合、コアユーザは1日でそのコンテンツを大量にプレイすることで、あっという間にその素材を集めてしまい、コンテンツの消化速度の観点からは望ましくありません。

このような問題に対して、既存の多くのゲームはそのポイントを得られるコンテンツ自体の挑戦回数に制限を設けることで、対処しているケースが見られます。
しかし、ゲーム自体は遊べるが、報酬は得られない。というアプローチの方が望ましいこともあるでしょうし、
ポイントが複数のコンテンツから取得出来る場合は、全てのコンテンツを遊んだ前提での取得量をベースに考えざるを得ず、ライトユーザが報酬を得づらいものになってしまいがちです。

GS2-Gold のポイントを採用することで、複数のコンテンツからポイントが得られたとしても、一定期間の取得量自体を制限することで、コンテンツをまたいで取得量の制限を設けることが出来ます。
このような仕組みを採用することで、さまざまなコンテンツからポイントを取得出来るようにも出来ますし、取得量の制限があることで、1日であっという間に素材を集めることもできず、リテンション率を上げる効果が期待出来ます。

取得量の制限は1日だけではなく、1週間や1ヶ月といった期間を設定出来ます。
これにより、1週間の間であればユーザの自由なタイミングでプレイして貰うことが出来ます。

GS2-Gold を Unity で使用する方法を例示します。

yield return Gs2.Gold.Get(
      result =>
      {
          if(result.Error != null) {
              // 例外が発生したとき
          }
          // 取得に成功するとウォレットの状態を取得できます
          var wallet = result.Result;
          Debug.Log("Balance:    " + wallet.Balance);
          Debug.Log("LatestGain: " + wallet.LatestGain);
      },
      session,            // GS2 のログインセッション
      GOLD_NAME);         // GS2-Gold に作成したゴールド名

これでウォレットの残高を取得出来ます。
Balance には現在の残高が
取得量制限を設定している場合は LatestGain には現在の期間での取得量が返ります。

yield return Gs2.Gold.GetSettings(
      result =>
      {
          if(result.Error != null) {
              // 例外が発生したとき
          }
          // 取得に成功するとゴールドごとのウォレットの設定を取得できます
          var walletSettings = result.Result;
          Debug.Log("BalanceMax:       " + walletSettings.BalanceMax);
          Debug.Log("LatestGainMax:    " + walletSettings.LatestGainMax);
          Debug.Log("ResetType:     " + walletSettings.ResetType);
      },
      session,            // GS2 のログインセッション
      GOLD_NAME);         // GS2-Gold に作成したゴールド名

こちらを使用すればゲーム内通貨を所持出来る最大値や、期間内での取得制限量。リセットタイミングといった情報を取得出来ます。
アセットに含めてもいい情報ですが、サーバサイドで変更する可能性がある場合はこちらのAPIを使用してしようすることでアプリやアセットの更新無しで動的に変更が出来ます。

yield return Gs2.Gold.Withdraw(
      r => {
          if(result.Error != null) {
              // 例外が発生したとき
          }
      },
      session,            // GS2 のログインセッション
      GOLD_NAME,   // GS2-Gold に作成したゴールド名
      100,                  // 消費する残高の量
      Context            // 消費に関するコンテキスト
);

こちらを使用すればウォレットの残高を減らすことが出来ます。
ウォレットの消費時に GS2-Script を実行出来るようになっています。またそのスクリプトには消費量だけでなく Context で渡したテキストが渡りますので、
それらの情報をもとに、スクリプト内でアイテムの付与やスタミナの回復と言ったアクションを起こすことが出来ます。

gold_client = client('gold')  –- GS2-Gold のクライアントを初期化
result = gold_client.deposit_into_wallet({
    goldName="gold-0001", -- ゴールド名 
    value=200, -- 加算する残高の量
    context="context" -- コンテキスト
})
result = {permit=not result.isError} -- 加算に失敗した場合失敗とする

ウォレットへの加算は Unity からは行えません。これはウォレットの残高を不正に増やされることを防ぐ目的があります。
ここでは、GS2-Script での加算例を例示していますが、JavaSDK や PythonSDK といったSDKを通してサーバから実行することで既存のサーバシステムから残高を加算することも可能です。

それでは、また。

GameBusiness.jp さんにインタビューしていただきました。

みなさんこんにちは。GS2 CEOの丹羽です。

先日 GameBusiness.jp さんにインタビューをしていただいた記事が公開されました。

www.gamebusiness.jp

  • 独立のきっかけ
  • どういう方々の手助けになりたいと思っているか
  • GS2のビジョン
  • 日本が今後も競争力のある開発力を維持するために

というあたりの話をさせていただきました。
ご興味があれば一読ください。

それでは、また。

シードラウンドとして第三者割当増資による8,000万円の資金調達を実施

f:id:kazutomo:20180330095304p:plain

Game Server Services 株式会社(愛知県北名古屋市 代表取締役社長CEO 丹羽一智 以下当社)は、大和企業投資株式会社(東京都千代田区 代表取締役社長 栁原藤雄)、株式会社GameWith(東京都港区  代表取締役社長 今泉卓也)、KLab Venture Partners株式会社(東京都港区 代表取締役 長野泰和)、株式会社ディー・エヌ・エー(東京都渋谷区 代表取締役社長兼CEO 守安功) の4社を対象としたシードラウンドでの第三者割当増資により、8,000万円の資金調達を実施しました。
今回調達した資金を使用して開発体制を強化し、サーバの開発・運用をせずとも、様々なタイプのゲーム開発が出来るようサービスの拡充を行います。

Game Server Servicesのご紹介

当社は、ゲームサーバの開発・運用をせずともゲーム開発が行えるよう、サーバレスと呼ばれるパラダイムを誰でも扱える形でゲーム分野に持ち込み、2016年12月に「Game Server Services(GS2)」のサービスを開始しました。
GS2自身もサーバレスコンピューティング(FaaS)を活用した設計・実装が行われています。
FaaS によってGS2は大量のアクセスを捌けるスケーラビリティと、サーバダウンが発生しない高可用性、低価格でのサービス提供を実現しました。

Game Server Servicesが解決する課題

モバイルゲームにおいて、サーバ障害が発生すると配信開始やイベント実施に影響が出てしまいます。サーバ障害の大半は「設計ミス」「実装ミス」「キャパシティ予測ミス」のいずれかによって引き起こされています。設計・実装のミスに関しては、ゲーム開発の都度、サーバシステムを再開発している現状のスタイルに原因があり、GS2のような汎用ゲームサーバを使用することで、リスクの大幅な軽減が期待できます。
さらに、GS2はFaaSによる設計・実装が行われているため、キャパシティ不足が理由でサーバ増設に多くの時間を要し、サーバ障害が長期化する、という事態を避けることが出来ます。

Game Server Servicesが開発された経緯

当社代表の丹羽は株式会社セガ任天堂株式会社に在籍した経歴を持ちます。
任天堂株式会社においては、任天堂プラットフォームのサーバシステム開発・運用を中心とした業務に従事しておりました。

任天堂プラットフォームにおいては、ゲームサーバの開発・運用をせずともネットワーク対応ゲーム開発が出来るような環境を提供していました。
しかし、モバイルゲームにおいて、AppleGoogleのようなプラットフォーマーはゲームサーバを提供していません。
結果、ゲーム開発者は自らゲームサーバを開発・運用するほかなく、前述したようなサーバ障害の発生に繫がっています。
また、個人や小規模スタジオにとって、ゲームサーバを利用したゲーム開発の敷居が高くなっています。

ゲームサーバ提供の事業化に可能性は感じていましたが、あらゆる規模のゲームで安心して利用してもらえるサービスにするためには、大量のサーバを用意して待機させておく必要があり、スタートアップには難題でした。
ところが2015年、サーバレスコンピューティング(FaaS)の登場によって状況は変わりました。
従来のアーキテクチャではサーバの起動時間に対して課金されていたため、たとえアクセスが少なくてもサーバを起動しているだけで費用がかかりました。
一方で、FaaSはプログラムの実行時間に対して課金され、アクセスが無ければストレージの維持費用などが発生するのみで、大量のアクセスを捌くことができるアーキテクチャでした。
FaaS技術の登場が、GS2という事業を始めるきっかけとなりました。

Game Server Servicesの見据える未来

近年のモバイルゲームは、開発規模の拡大と長期化から、効率の向上が求められています。
かつて家庭用ゲーム機市場でも似たような潮流があり、汎用ゲームエンジンを活用した開発の効率化が進み、現在では当然の開発スタイルとして浸透しました。

モバイルゲームは、家庭用ゲームよりネットワークを重視したゲームタイトルがスタンダードですが、汎用ゲームサーバが活用されている状態とはいえません。
当社は汎用ゲームサーバを使用して、開発効率の向上を実現する環境を提供します。
そして、今までサーバ開発と運用がネックとなっていたゲーム開発者の皆様の、新たな発想による新しい遊びの体験が世の中にリリースされることを期待しています。

gs2.hatenablog.com
gs2.hatenablog.com

Game Server Services のご案内

GS2 は初期費用が一切かからず、マイクロサービス毎に1時間あたり数円〜数十円(規模に応じて変動)、またはゲームサーバへのAPIリクエスト1,000回~10,000回あたり数円というお手頃な価格でサービスを提供しており、豊富な無料枠も存在します。
さらに、アカウント登録時から3ヶ月間有効な3万円分の体験クーポンをプレゼントしており、体験期間中はクレジットカードの登録無しでサービスをお試しいただけます。

関連ページのご案内

Game Server Services株式会社
https://gs2.io/

大和企業投資株式会社
https://www.daiwa-inv.co.jp/

株式会社GameWith
https://gamewith.co.jp/

KLab Venture Partners株式会社
http://www.kvp.co.jp/

株式会社ディー・エヌ・エー
http://dena.com/jp/

本プレスリリースに関する報道関係者からのお問い合わせ先

Game Server Services 株式会社 広報担当
mail: contact@gs2.io
form: https://gs2.io/contact.html

【新機能】GS2-Lock/GS2-JobQueue の提供を開始しました。

みなさんこんにちは。GS2の丹羽です。

先日こちらのエントリで告知していた新サービスの提供を開始しました。

gs2.hatenablog.com

また、今回のリリースにあわせてドメインの変更も行われています。

gs2.hatenablog.com

さて、サービスの内容に関しては告知時におおむねお伝えしていますので、ここでは Unity SDK からの使い方と料金についてご説明しようと思います。

GS2-Lock

GS2-Lock の使い方は非常に簡単です。

yield return Gs2.Lock.Lock(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
    },
    Session, // ゲームセッション
    LockPoolName,       // ロックプール名
    "resource-0001",    // ロックを取得するリソース名
    "transaction-0001", // トランザクションID
    5 // ロックの有効期限(秒)
    );

// この間に resource-0001 に関する処理を行う。
// たとえば、残高を確認し、残高が必要量以上あれば消費するというような具合
// ロックを取った中で処理を実行することで、残高を確認してから消費するまでの間に割り込まれる心配が無くなる

yield return Gs2.Lock.Unlock(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
    },
    Session, // ゲームセッション
    LockPoolName, // ロックプール名
    "resource-0001", // ロックを取得するリソース名
    "transaction-0001", // トランザクションID
);

GS2-Lock の利用料金はサービスクラス+APIリクエスト回数に対する課金となっていますが、
最少クラスである lock1.nano(1秒間に1回 ロックまたはアンロック可能) は無料でご利用いただけます。
その次のクラスである lock1.micro(1秒間に5回 ロックまたはアンロック可能) は1時間あたり10円でご利用いただけます。
そのほかの利用料金として、APIリクエスト1,000回あたり3円の利用料金が必要です。
APIリクエストには毎月10,000回までの無料枠があります。

GS2-JobQueue

GS2-JobQueue はジョブの登録は Unity SDK からは行えません。
ここでは GS2-Script からジョブを登録する例を示します。

job_queue_client = client('job_queue')        –- GS2-JobQueue のクライアントを初期化
result = job_queue_client.push({
    queueName="queue-0001", -- ジョブキュー名 
    userId="user-0001", -- ジョブを登録するユーザID
    jobs={
        {
            scriptName="script-0001", -- ジョブで実行するGS2-Script名
            args="{\"param1\": \"test\", \"param2\": 2}", -- GS2-Script に渡す引数
            maxRetry=5 -- 最大リトライ回数
        },
        {
            scriptName="script-0002", -- ジョブで実行するGS2-Script名
            args="{\"param\": \"aaa\"}", -- GS2-Script に渡す引数
            maxRetry=3 -- 最大リトライ回数
        }
    }
})
result = {permit=not result.isError} -- ジョブの登録に失敗した場合失敗とする

ジョブの実行は Unity SDK で行えて

yield return Gs2.JobQueue.Run(
    r =>
    {
        if (r.Error != null)
        {
            // 例外が発生
        }
        Debug.Log("statusCode: " + r.Result.StatusCode); // ステータスコード(200が成功 - httpステータスコードに準拠)
        Debug.Log("result: " + r.Result.Result); // ジョブが実行したスクリプトの戻り値
        Debug.Log("endOfJob: " + r.Result.EndOfJob);     // キューの終端までジョブを実行したか
    },
    Session, // ゲームセッション
    QueueName // ジョブキュー名
);

このようになります。ジョブの実行リクエストを定期的に実行することでジョブキューを通した非同期処理を実現出来ます。

ジョブキューにジョブが追加されたときにサーバからプッシュ通知でクライアントに知らせたい場合は
GS2-InGamePushNotification と連携することで、ポーリングしなくてもジョブキューを処理することが出来ます。

Gs2.JobQueue.SetInGamePushNotificationSession(session);

GS2-JobQueue のクライアントに GS2-InGamePushNotification のセッション情報を渡して

Gs2.JobQueue.OnEntryJob += (notification) =>
{
    Debug.Log("queueName: " + notification.QueueName);
};

イベントハンドラを登録するだけです。イベントハンドラにはジョブが登録されたジョブキュー名が渡ってきますので、
それを使ってジョブキューの終端までジョブを実行すれば実装は完了です。

GS2-JobQueue の利用料金は完全リクエスト課金で

ジョブの登録 3円/1,000件
ジョブの実行 5円/1,000回
ジョブ/デッドジョブ/ジョブ実行結果取得 5円/~10件/1,000回
ジョブ/デッドジョブ取得 1円/1,000回

となっており、毎月

ジョブの登録 10,000件
ジョブの実行 10,000回
ジョブ/デッドジョブ/ジョブ実行結果取得 10,000ユニット(取得件数10件あたり 1ユニット)
ジョブ/デッドジョブ取得 10,000回

の無料枠が付属します。

そのほかの利用料金として、APIリクエスト1,000回あたり3円の利用料金が必要です。
APIリクエストには毎月10,000回までの無料枠があります。

それでは、また。

CNCF Serverless Whitepaper v1.0 の重要部分の抜粋と雑感

みなさんこんにちは。GS2 CEO の丹羽です。

先日 Cloud Native Computing Foundation(CNCF) が サーバレスコンピューティングに関するホワイトペーパーを発行しました。
今日はサーバレスアーキテクチャを活用したプラットフォーマーとしての立場としてこのホワイトペーパーを読んでの雑感をお伝えしたいと思います。

github.com

まずは、ホワイトペーパーの中から重要だと感じた部分を抜粋します。

What is serverless computing?

最初にサーバレスコンピューティングの定義から始まります。
どうやらここでは FaaS と BaaS こそがサーバレスコンピューティングという定義がされているようですが、後々の文書を見る限り PaaS もサーバレスコンピューティングとして捕らえている節もあり
CNCF の中でも PaaS をどう扱うか決めあぐねている様子がうかがえますが、文書構成的に本ホワイトペーパーにおける サーバレスコンピューティング とは FaaS を指していると言えそうです。

しかし、そのようなことは些末な問題であり、サーバレスコンピューティングの達成する事項は以下である。と定義しています。

  • サーバのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティプランニングに時間とリソースを費やす必要がなくなる
  • サーバレスプラットフォームには「事前計画された容量」という概念がなく、「自動スケーリング」トリガやルールを設定する必要がない
  • アイドルキャパシティに起因するコストがない

ただし

  • これにはステートフルなストレージコストや追加された高レベルな機能などの他のコストは含まれていない

つまり、サーバレスコンピューティングとは

  • イベントに対してオンデマンドで実行され、実行された時間に応じて費用が発生すること
    • ただし、永続化するためのストレージに関する必要などはそれに値しない
  • キャパシティ管理が不要であること

こそが肝と捕らえられているといえます。

Serverless use cases

このセクションでは実際の応用例を用いて サーバレスコンピューティング の有用性を解説しています。
サーバレスコンピューティングが有用な箇所として以下の特徴があるワークロードに適しているとしています。

  • 非同期、並行、独立した作業単位への並列化が容易
  • 処理が頻繁に発生せず散発的な需要があるもの。予測できない大きな利用変動が起こりえる
  • ステートフル、短いレイテンシを必要としない
  • 開発速度を加速し、ビジネス要件が頻繁に変化する

Serverless vs. Other Cloud Native Technologies

ここでは FaaS とPaaS/CaaS といった既存のテクノロジーとの比較が語られます。

Continer(CaaS)

利点
  • 開発者は、展開されているものに対して、最も支配力があり、その力に伴う責任があります。コンテナオーケストラを使用すると、展開する正確なイメージのバージョンと、実行時を制御するポリシーとともに、どのような構成で運用するかを定義できる
  • ランタイム環境(ランタイム、バージョン、最小OS、ネットワーク構成など)を制御できる
  • システム外のコンテナイメージの再利用性と可搬性の向上
  • コンテナ化されたアプリやシステムをクラウドにもたらすために最適
欠点
  • セキュリティパッチと配布の最適化を含む、ファイルシステムのイメージと実行環境に対する責任が開発者/運用者による
  • ロードバランシングとスケーリングの動作を管理する責任がある
  • キャパシティ管理の責任がある
  • デプロイ/プロビジョンに長い時間を要する
  • ビルドとデプロイメントのメカニズムに対する責任がある
  • 監視、ログ、およびその他の共通サービスの統合に対する責任がある

PaaS

利点
  • 開発者の焦点はアプリケーションコードとそれが接続するデータサービスにあります。実際のランタイムはほとんど制御できませんが、開発者はビルドステップを避け、スケーリングオプションとデプロイメントオプションを選択することもできる
  • 基礎となるOSを管理する必要がない
  • 安定したプログラミングモデルを備えた多くの既存のWebアプリケーションに最適
欠点
  • OSの制御が自由に行えない
  • プラットフォームロックイン

FaaS

利点
  • 開発者の視点が、高可用性を実現するという運用上の懸念から、機能ロジック自体にシフト
  • 開発者は、デマンド/ワークロードに基づいた自動的なスケーリングを獲得
  • コードが実際に稼働している場合にのみ課金する新しいコストモデル
  • OS、ランタイム、およびコンテナのライフサイクルまでが完全に抽象化
  • IoT、データ、メッセージを含む新興のイベント駆動型および予測不可能なワークロードに適している
  • 通常、ステートレスで不変で一時的な展開。各機能は、指定された役割と、リソースへの明確に定義された/限定されたアクセスで実行
  • ミドルウェア層はチューニング/最適化され、時間の経過とともにアプリケーションのパフォーマンスが向上
  • ほとんどのサーバレスランタイムは個々の機能のサイズや実行時間に制限を設けているため、マイクロサービスモデルを強力に推進
欠点
  • 新しいコンピューティングモデル、より包括的で安定したドキュメント、サンプル、ツール、およびベストプラクティスによる迅速なイノベーション
  • ランタイムのよりダイナミックな性質のため、IaaSおよびPaaSと比較してデバッグするのは難しい
  • オンデマンド構造により、ランタイムがアイドル時に関数のすべてのインスタンスを削除する場合、サーバーレスランタイムの「コールドスタート」がパフォーマンスの問題になる
  • 複雑なユースケースにおいて、同じ量のロジックに対してより多くの実装を求められる可能性がある
  • 歴史が浅く標準化と生態系成熟の欠如
  • プラットフォームのプログラミングモデル、イベント/メッセージインターフェイス、およびBaaS製品によるプラットフォームロックイン

雑感

このホワイトペーパーから感じ取れることは、FaaS を使うべきかどうかを判断するための指針を伝えたかった。ということです。
細かいレベルでインフラストラクチャーを制御したい場合は Container を使うのが最良だと言えるでしょうし、そんなものどうでもいいから、可用性とか考えたくないからいい感じにして欲しい。という場合は PaaS か FaaS ということになります。
PaaS と FaaS のどちらを選ぶべきか。という点においては、既に成熟したアプリケーションフレームワークを使いたい場合は PaaS。ごくまれにトラフィックが発生し、普段はトラフィックがほぼ無いケースや、突発的なアクセスの増加が予想される場合は FaaS が望ましいといえそうです。

IaaS の欠点のうち、コールドスタートやロックインといった部分に関しては PaaS と共通する箇所でしょうから、
逆に言えば、成熟したアプリケーションフレームワークが使えない以外のデメリットは PaaS と比較する分には FaaS にはない。といえます。
FaaS のためのアプリケーションフレームワークが整ってくれば次世代のサーバレスコンピューティングとして芽吹いてくる可能性が高そうです。

ところで、BaaS はサーバレスコンピューティング である。と言った割に BaaS について全然触れられてないのはなんとかして欲しいですね。
BaaS も オンプレミス/IaaS/PaaS/FaaS のいずれかで動いているアプリケーションだということを正しく伝えておかないと、BaaS を使えば 『FaaS のような柔軟性が得られる』という絶望的な勘違いが生まれかねません。
GS2 のような FaaS で設計/開発された BaaS というのは世界的に見ても現時点では殆ど存在しないでしょうから、ここはしっかり押さえておくべきではないか。と感じました。

GS2 ってなんやねーん。という方がもしここまで読んでくださっていた場合に備えて紹介を。
GS2 とは Game Server Services というスマートデバイス向けゲームの BaaS です。FaaS で設計/実装 されており、スケーラブルかつ高可用性なサーバシステムを提供しています。
gs2.io

それでは、また。

サービスAPIのドメイン変更(.io -> .com)について

みなさん、こんにちは。GS2 CEOの丹羽です。

本日は GS2 のゲーム内から直接利用するサービスAPIドメイン変更のお知らせをいたします。

現在GS2のサービスは gs2.io というドメインを使用してサービスを提供しておりますが、
io トップレベルドメインが安定しておらず、まれに通信に失敗することがあるため
サービスAPIドメインを gs2io.com に段階的に変更していきます。

Webページやマネージメントコンソールに関しては現時点では変更の予定はありません。

本施策は mackerel.io でも同様の施策をとっておりますので、詳細は以下をご確認ください。
mackerel.io

提供中のサービスは io ドメインでもアクセス出来る状態で維持しますので、
既に提供中・または開発中の開発者の皆さんがSDKを変更することは必須ではありません。

※ ただし、ドメイン変更対応のSDKをご利用いただくことでTLDが不安定になることは少なくなり、安定性は向上すると見込まれます。

ドメイン変更のプロセス

新規サービス

近日公開予定の GS2-Lock / GS2-JobQueue 以降のサービスは gs2io.com でのアクセスのみ利用出来るようになります。

既存サービス

GS2-Lock / GS2-JobQueue のSDKリリースと同時に、gs2io.com でのアクセスに切り替えたSDKをリリースいたします。
古いバージョンのSDKを利用いただいている場合でも、gs2.io 経由でのアクセスが利用出来なくなるわけではありませんので、無理に追従していただく必要はありません。

それでは、また。

【新機能】マイクロサービス間の連携を補助するためのサービスを追加します

みなさんこんにちは。GS2 CEO の丹羽です。

近日公開予定の新機能のお知らせをしたいと思います。
今回お知らせするサービスは2つで、どちらもGS2のマイクロサービス間を協調動作させるために重要な役割を果たす事になる機能です。

GS2-Lock

これは名前の通り、排他処理を実現するための機能となっています。
機能としては非常に単純で、『特定のリソースに対してロックを取得する』という宣言と『特定のリソースのロックを解除する』という宣言の2つが主な機能です。

用途例

たとえば、GS2-Stamina でスタミナを回復するために GS2-Money で 課金通貨を消費する。というプロセスを例に考えてみましょう。
GS2-Lock が無い状態でこれを実現すると、『GS2-Stamina でスタミナを回復する』『GS2-Money で 課金通貨を消費する』という2つの操作はそれぞれ独立した操作になります。
そのため、『GS2-Stamina でスタミナを回復する』と『GS2-Money で 課金通貨を消費する』のわずかな間に他の処理で GS2-Money の消費が割り込んでくる可能性があります。
その結果、スタミナは回復したにも関わらず、GS2-Money の残高が不足していて減らせない。ということが起こりえます。

このような問題を避けるためには GS2-Lock で GS2-Money の残高を増減する前後に、GS2-Money のウォレットのロックの取得/解除を行うようにします。
そうすることで、『GS2-Stamina でスタミナを回復する』と『GS2-Money で 課金通貨を消費する』のわずかな間に他の処理で GS2-Money の消費が割り込んできたとしても
割り込んできた側の処理がロックが取れずに失敗することになり、このような問題を避けることが出来るようになります。

そのほかの特徴

GS2-Lock ではロックを取得する際に『トランザクションID』というものを指定します。
そして、同一トランザクションからのロック取得リクエストだった場合はロック参照カウンターを増加させ、ロック解除リクエストはロック参照カウンターを減算し、実際のロック解除は参照カウンターが0になるまで行わないようになっています。
こうすることで、一つの処理系の中で同じリソースのロックを取ろうとしてデッドロックする。というような問題を避けることが出来るようになっています。

また、GS2-Lock のリリースにあわせて『リクエストID』という機能が導入されます。
リクエストIDとは、APIリクエスト毎にユニークなIDで、さらに APIリクエストによって発火した GS2-Script の中で GS2-SDK を使用して通信をした場合は同じリクエストIDが使用される。という特徴があります。
つまり、GS2-Lock のトランザクションIDにこのリクエストIDを指定することによってピタゴラ装置的に起動するGS2-Script全てで共通のトランザクションIDを使用することが出来ます。

f:id:kazutomo:20180210013805p:plain

ちなみに、ロックの解放を忘れてしまってどうにもならなくなってしまうことを避けるために、ロック取得時にTTLを秒単位で指定することが出来ます。
TTLの長さはロック取得時に指定出来ますので、この後の処理にかかりそうな時間に対して十分な時間でTTLを指定してロックを取得することで何らかの事故によってロックを解除出来なかったとしてもデッドロックすることは無くなります。

GS2-JobQueue

GS2-Lock は複数のマイクロサービスを超えて一貫性のある排他処理を実現するための機能でしたが、GS2-JobQueue は複数のマイクロサービスを超えて結果整合の処理を実現するための機能です。

名前の通り、このサービスはユーザ毎にジョブキューを提供します。
ジョブには GS2-Script のスクリプト名と引数、最大リトライ回数 を指定出来ます。

ジョブキューはFIFO先入れ先出し)を保証しており、1回のAPIリクエストで最大10件のジョブを一気に登録出来ます。
一気にジョブを登録する際には、リクエスト時に指定した順番に優先度が付いて登録が行われます。
ジョブキューの実行は明示的にAPIを通して実行リクエストを出す必要があり、API実行は排他処理が行われているため同時に複数のジョブを走らせることは出来ません。
ジョブには最大リトライ回数を指定したことから推測出来るように、GS2-Script が 200 以外のステータスコードを返した場合は、次回ジョブ実行リクエストの際にリトライを行います。
ジョブキューの実行リクエストのレスポンスにはジョブとして動いた GS2-Script の実行結果が返るほか、ジョブキューの終端まで処理を終えたかも取得出来ます。

用途例

現在のGS2の機能としては提供していませんが、クエストをクリアした際に、あたらしいユニットを入手し、新しいユニットを入手したことでユニット図鑑を解放する。という処理を実現するとしましょう。
エストをクリアした報酬としてユニットを入手する箇所に関しては、UX的に同期的に処理した方がよさそうですが、図鑑の解放はプレイヤーがすぐに目にすることは無いでしょうから、結果整合でよさそうです。

ユニットを入手した際に GS2-Script を発火するように設定し、そのスクリプトでは GS2-JobQueue に対して『ユニット入手というスクリプトを呼び出すジョブ』を登録します。
『ユニット入手というスクリプト』では、入手したユニットが図鑑で解放されているかを確認し、解放されていなければ解放するというスクリプトにします。
あとはゲーム内で余裕があるときに GS2-JobQueue のジョブを実行すれば結果整合で図鑑の解放が実現出来ます。
図鑑の解放済み確認や解放処理をユニットを入手した際に発火するスクリプトで記述する方が楽じゃない?と感じられるかもしれませんが、そのようにしてしまうと、処理エラーやクオーターリミットによるエラーでユニットの入手処理まで巻き添えになってしまいますが、GS2-JobQueue を通すことで非同期処理でリトライ付で実行出来ることによってリスクを最小限に抑えることが出来ます。

そのほかの特徴

最大リトライ回数を超えてエラーが発生した場合はデッドレターキューに追加されます。
デッドレターキューには GS2-Script の実行時エラーの内容も一緒に保存されますので、問題の解決や復旧にも役立つでしょう。

定期的に GS2-JobQueue のジョブを実行すればいい。って言われても常にポーリングするのはちょっと…。と思われた方には GS2-InGamePushNotification との連携機能をご紹介します。
この連携機能を使うことで、ジョブキューに新しいジョブが登録されたときにプッシュ通知を受けることが出来ます。
これを使えば、ジョブキューが空になるまで実行したら、GS2-InGamePushNotification からの通知が来るまではジョブキューは触らず、通知を受けたらもう一度ジョブキューが空になるまで実行する。という風にすることで無駄なポーリングを回避出来ます。


利用料金や実装例については実際に機能をご利用いただけるようになった際にこのブログで告知します。
GS2 ではマイクロサービスの数も増えてきて、これからは1回の操作で複数のマイクロサービスのデータを読み書きすることが増えてくることになります。
今回は、そのようなケースで活用出来る機能のご紹介でした。

それでは、また。

(C) Game Server Services, Inc.