GS2 Blog

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

AWSのAZ障害で影響を受けた・受けなかったの設計の違い。サーバレス最高!

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

今日は大事件が起こりました。Twittetなどでも話題になったので皆さん知っているのではないかと思います。

japanese.engadget.com

こんなブログを見に来てる人ならみんな知ってると思いますが、AWSの東京リージョンには3カ所のデータセンターがあります。
そのうち1カ所のデータセンターが完全に利用できない状態になりました。

その影響で様々なゲームも影響を受けたようです。

gamebiz.jp

なぜAZ障害が様々なサービスの障害につながったのか

さて、なぜ今回のようにAZがダウンするとこのような大規模な障害が発生するのでしょうか。

1. シングルAZ

サーバはどこかのデータセンターで動いていてるわけです。EC2を使ってサーバを起動するときにもどのAZに配置するかを選びます。
この時に、一つのAZに固めてサーバを配置していた。あるいは1台しかなかった。みたいなときはサーバは全滅してしまいますので、障害となります。

2. フェイルオーバー設計ミス

次に、複数のAZに配置していたけれども、フェイルオーバーがうまくいかなかった場合です。
たとえば、データベースに接続するアプリケーションがあったとして、接続しているデータベースが突然いなくなったときに、再接続する処理がちゃんと動かなかった場合などがこれにあたります。

3. キャパシティ不足

最後に、ちゃんとフェイルオーバーもできたのに、キャパシティー管理が正しく行えていなかった場合です。
たとえば、2か所のAZにサーバを配置しているにもかかわらず、50%以上の余剰キャパシティを確保しておかなかった場合です。
当然ですが、AZレベルの障害が発生してフェイルオーバーした場合、正常なAZにアクセスが偏ることになります。
この時にキャパシティオーバーしてしまうような場合も障害となります。

これらをすべて満たしたサービスは”影響が表に出なかった”ということになります。
しかし、表に出なかっただけで、裏では慌てふためいた人たちが動いていたことでしょう。

AZの見えない未来

ここからが本題です。
私は Game Server Services というゲームの BaaS を開発しています。
GS2 は フルサーバレスアーキテクチャ で設計・実装されています。
つまり、API GatewayAWS Lambda、DynamoDB といったフルマネージドサービスを組み合わせてサービスを作っているわけです。

aws.amazon.com

そして、そのおかげで私は今日の障害が発生しても1通もアラートを受け取っていません。
障害が発生した時も、客先で打ち合わせをしていましたが、打ち合わせが終わってLINEに障害の話が届いていて問題に気が付いたくらいです。
なぜ、フルサーバレスアーキテクチャだと障害の影響を受けなかったのでしょうか。

いや、実際はAZ影響は受けます。
API Gateway はマルチAZでフェイルオーバーをしていたでしょうし、AWS Lambda もコンテナを起動するAZから障害の発生していたAZを外していたでしょう。DynamoDB もこのような障害に備えて必ず複数のAZに3個以上の複製を保持することを保証しています。

AWS がしっかりフェイルオーバーしてくれていたおかげで、私からすれば”あたかも障害がなかった”ように感じられたわけです。

オープンソースの Function as a Service を独自の仮想サーバで動かしてサーバレスだ。みたいな記事を時々見ますが、まったく的外れだということが理解いただけるのではないかと思います。

そして、今日改めて私は インフラの未来はサーバレスにある。という思いを強くしたのでした。
それでは、また。

gs2.io

追記

まず、この記事の趣旨は今回の障害のニュースや解説ではありません。
一般論としてAZ障害とは何かの話をしています。
そして、AWSSLAではAZ障害は起こるものとして定義されており返金の対象ではありません。
なので、AZ障害に対する責任は利用者にあるにも関わらず、フェイルオーバーできず影響がでたのはリテラシーの問題です。

ブコメでEC2しか影響出てなかったじゃない。みたいなコメントが多いです。
それはEC2にはAZダウンは仮想サーバの強制シャットダウンに繋がるため、状況の説明責任がありますが、フルマネージドサービスは正しくフェイルオーバーしていれば説明責任はありません。
つまり、本当は影響を受けてたかもしれないし、それはわかりません。
しかし、それがフルマネージドサービスのいいところ。という記事です。

次にフェイルオーバーを正しく設計していたのに障害に繋がったという話です。
今回はALBやELBが正しくフェイルオーバーしなかったという話を聞きます。
これらはフルマネージドサービスである ALB/ELB の問題でありAWSの問題です。SLAの保障の対象でしょう。
問題が起こったことは悲劇ですが、同じ問題は二度と起きません。各自がフェイルオーバーするより確実にいい未来がフルマネージドにはあるはずです。

無料プラン、月額1,000円プラン を追加しました

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

要望に応えて、正式サービス開始後の料金プランについて 変更を加えることにしました。

無料プラン

まずは無料プラン(Free)の追加です。
これまで 従量課金プランに2万円分の豊富な無料枠がある。という料金モデルで訴求していましたが
個人開発者を中心に、クラウド破産が怖い。というフィードバックを頂戴しました。

そこで、一定の利用状況に達した段階でサービスの利用が停止する無料プランを用意しました。
無料プランでは…

  • APIリクエスト 1万回/月
  • リアルタイム対戦 1万分/月
  • 課金通貨 流通額 10万円/月

のいずれかを超過した段階でサービスの利用が一時停止されます。個人開発者でも安心してご利用いただけるプランとなっております。

月額プラン

次に月額プラン(Fixed)です。
無料でなくても良いんだけど、月額固定費がいい。という開発者向けのプランで、月額1,000円でご利用いただけます。
こちらも無料プランと基本的には同じで、利用できる枠が無料プランの10倍あります。

  • APIリクエスト 10万回/月
  • リアルタイム対戦 10万分/月
  • 課金通貨 流通額 100万円/月

のいずれかを超過した段階でサービスの利用が一時停止されます。

従量プラン

最後に、これまでご提案してきた料金プラン(Unlimited)です。
Unlimited に関しては2万円分(100万APIリクエスト相当)の無料枠という点は変わっていません。

gs2.io

それでは、また。

【アップデート】GitHub との連携機能を追加 / GS2-Inbox のエンハンス

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

先週は Google Cloud Next Tokyo 2019 に参加していました。
ミニセッションもやらせていただき、GS2が提供している機能は GS2-Inventory で割引クーポンの所持管理や有効期限設定。GS2-Inbox でサイト内の通知機能など、ゲーム以外の用途でも活用できますよ。というお話をしてきました。

キャンペーンサイトなどで、開発費やリリース後の保守リソースを抑えたい場合などにGS2を使用いただくことで様々なメリットが得られますので、そのような案件がありそうな場合はぜひご検討ください。
今週のアップデート

GS2-Script - GitHub連携機能を追加

GS2-Script は GS2 内のイベントで駆動させられる Function as a Service 機能です。
これまで GS2-Script のコードを更新するにはマネージメントコンソールによる更新、または GS2-SDK によるコードのアップロードが必要でした。
これまでの仕組みでは、コードのバージョン管理が難しく、開発者間で同一のコードを用いた開発ができている保証がしにくい状態となっていました。

今回のアップデートで、GitHubリポジトリのコードから直接 GS2-Script へアップロードすることができるようになり、その際にはコミットハッシュを用いた更新ができるようになりました。

GitHubAPIキーの管理機能は GS2-Key に拡張され、GS2-Script などでコードの更新を実行する際には GS2-Key に保持したどのAPIキーを使用して実行するかを指定して使用します。
GitHubAPIキーは GS2-Key の暗号鍵を用いて暗号化して保存されます。安心してご利用ください。

各種サービスのマスターデータ - GitHub連携機能を追加

各種サービスのJSON形式のマスターデータ更新にも GitHubリポジトリを用いた更新ができるようになりました。
これによって、マスターデータのバージョン管理も容易となります。

GS2-Deploy - GitHub連携機能を追加

GS2-Deploy のテンプレートに GitHubリポジトリを指定できるようになりました。スクリプトのコードや、マスターデータのバージョン管理と組み合わせて使用することで、より安全な継続的デリバリーを実現できるようになります。

GS2-Inbox - プレゼントの付与処理を強化

GS2-Inbox のメッセージ開封時にプレゼントを付与する機能が拡張されました。これまではスクリプトの実行しかできませんでしたが、スタンプシートに対応し様々なリソースの付与も行えるようになりました。
これまでのようにスクリプトでプレゼント付与処理を実行したい場合も、スタンプシートの報酬にスクリプトの実行を設定していただくことで対応できます。

GS2-SDK for Java

GS2-SDKJava 版を公開しました。
現時点では REST API にのみ対応しています。後日 WebSocket への対応を行います。
https://github.com/gs2io/gs2-java-sdk

GS2-Document - カテゴリごとにページを分割

ドキュメントページで1ページにすべての情報を格納していましたが、読み込みに時間がかかる問題がありましたので、カテゴリごとにページを分割することで読み込み速度の改善を行いました。

お気軽にご相談ください

サイト内の右下に設置されたチャットで話しかければ、GS2のスタッフがすぐに対応いたします。
GS2 についての質問や、GS2 をどのように活用するべきかのご相談などでご活用ください。

また、ゲームの仕様を共有いただき どの部分で GS2 を活用いただけるか GS2 がアーキテクトをしてご提案もしています。機密保持契約を結んでの対応も可能です。
みなさんがゲームのコアバリューを磨くことに注力できる環境づくりを進めていますので、ぜひご活用ください。

【アップデート】PhotonCloud より安価に便利に利用できるリアルタイム対戦サーバを公開

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

先週に引き続き、今週も重要なアップデートが行われましたので、お知らせします。

今週のアップデート

GS2-Realtime - リアルタイム対戦サーバを追加

対戦や協力プレイで使用できるリアルタイム対戦サーバが追加されました。
このサーバでは最大100人(今後さらに引き上げる計画あり)が同じゲームサーバに接続し、リアルタイムにデータ交換を行えるようにします。

今回のリリース時点では、簡易的なプレイヤー間でデータ同期をする仕組みと、プレイヤー間でデータ送受信を行う仕組みを提供します。
今後のアップデートで任意のサーバプログラムを配置できるようにして、MMORPGのようにサーバサイドで一定間隔でエネミーをポップさせたり、レイドバトルでボスの体力の状態をサーバ側で管理できるようにします。

CCU管理不要

一般的なリアルタイム対戦サーバはCCU(同時接続数)のキャパシティ管理が必要でした。
しかし、GS2 はゲームルームの起動時間1分あたりの料金で計算され、CCUを管理する必要はありません。
1分あたりの料金はサーバの性能によって変動し、サーバの性能は同時接続数やデータの送信間隔によって適切な性能の設定が変わってきます。目安として『8人対戦で毎秒2回256バイトのデータをルーム内の全プレイヤーに送信する』ユースケースで、最も安価な realtime1.nano(0.04円/分) で提供可能です。

Photon Cloud より安価に利用可能

Photon Cloud は 20CCU & 60GB の通信が無料枠として設定されています。
GS2 の無料枠は realtime1.nano であれば 50万分のルーム起動時間に相当します。これは11のゲームルームを常時起動できる時間に相当します。単純計算で2人対戦であれば22CCU。4人対戦ゲームであれば44CCUとなりますが、実際は常時起動しておくわけではなく対戦を開始してから対戦を終了するまでのルーム起動時間に対してしか費用が発生しませんので、実際は例示したCCUよりもっと多くの同時対戦をホストできます。

さらに、日本リージョンにおける 1GBあたりの通信料金は Photon Cloud では 18.25円 ですが、GS2-Realtime は 15円 で利用できます。

GS2-Realtime を Unity から利用するチュートリアル

GS2-Matchmaking に GS2-Realtime 連携機能を追加

GS2-Matchmaking の機能が拡張され、マッチメイキング開始時やマッチメイキング完了時に GS2-Realtime のルームを作成できるようになりました。
マッチメイキングをしながらチャットをできるようにしたい場合や、マッチメイキングが完了したあとシームレスに対戦・協力プレイに繋ぎたいときに使用できます。

来月のマイルストーンを公開

8月のアップデート予定を公開しました。
ざっくりとタスクをご紹介します。

  • GS2-Script のコードや、GS2-Deploy のテンプレート、各サービスのマスターデータを GitHub リポジトリから取得して反映できるように
  • GS2-Exchange 陳列棚を伴わないリソース交換(★1素材x10で★2素材1に交換できる。アイテムAを売却すると500Gで売れる)
  • GS2-Inventory の機能拡張。所持数量上限を超えたときに別スロットにアイテムを追加で所持できるように
  • GS2-Inbox の機能拡張。プレゼント開封時の処理が現在は GS2-Script の実行のみだが、スクリプトを介さずGS2の各種リソースの付与を行えるように
  • Unreal Engine 4 向け SDK の提供開始

※ あくまで予定ですので、変更がある可能性があることをご了承ください。

お気軽にご相談ください

サイト内の右下に設置されたチャットで話しかければ、GS2のスタッフがすぐに対応いたします。
GS2 についての質問や、GS2 をどのように活用するべきかのご相談などでご活用ください。

また、ゲームの仕様を共有いただき どの部分で GS2 を活用いただけるか GS2 がアーキテクトをしてご提案もしています。機密保持契約を結んでの対応も可能です。
みなさんがゲームのコアバリューを磨くことに注力できる環境づくりを進めていますので、ぜひご活用ください。

gs2.io

【アップデート】WebSocket による常時接続通信に対応・プッシュ通知に対応

みなさんこんにちは。GS2の丹羽です。
ベータテストを開始して1週間が経過しました。既に多くのユーザに評価いただき、感謝しております。
これから、定期的にサービスのアップデート情報を皆さんにお届けすることにしました。
ぜひ今後のご参考にしていただければと思います。

今週のアップデート

WebSocket による常時接続通信に対応

ベータテスト開始時点ではすべての通信は HTTP ベースの通信のみ対応としていました。このアップデートにより、新たに常時接続ベースの通信が利用できるようになりました。

WebSocket は HTTP と比較して通信のたびに再接続を行わないことから通信の応答速度の向上が期待できます。

あわせて公開した GS2-SDK for Unity 2019.7.2 ではデフォルトの通信プロトコルが WebSocket に変更されています。

サーバイベント通知に対応

WebSocket による常時接続ができるようになり、サーバからクライアントに対してメッセージを送信できるようになります。
GS2-Matchmaking では【対戦相手が見つかった場合】【マッチメイキング中に対戦相手が離脱した場合】【マッチメイキングが成立した場合】の3種類のイベントがプッシュ通知で受け取れるようになります。
GS2-Mission では クエストクリア回数などのカウンターを操作し【ミッションのタスクを達成した場合】に通知を受け取れるようになります。
GS2-JobQueue では【ジョブキューに新しいジョブが追加された時】にプッシュ通知を受け取れるようになります。

この通知機能は Firebase を利用したモバイルプッシュ通知への転送機能があります。
これを利用すれば、【マッチメイキングが成立した時】にアプリを終了した場合、モバイルプッシュ通知で知らせる ということが実現できます。
通知の種類ごとに転送を利用するかを設定できますので、重要度の高い通知のみ有効にすることをおすすめします。

マネージメントコンソールの強化

GS2-Quest のクエスト報酬や、GS2-Showcase の管理UIのうち、商品の対価と報酬の設定を強化しました。
ベータリリース時点では、対価の消費・報酬の付与 は対応するAPIのリクエスト内容をJSON形式で指定するUIになっていましたが、入力フォームで直感的に入力できるようになりました。

f:id:kazutomo:20190724110826p:plain
Before
f:id:kazutomo:20190724110852p:plain
After

GS2 の採用に迷ったら?

ゲームの仕様をお聞かせ願えれば、どのようにGS2のサービスを活用すればいいかご提案します。
その際、機密保持契約が必要な場合も都度対応可能です。
検証レベルの評価、リリース時期未定のタイトルであっても問題ございません。まずは contact@gs2.io までお気軽にご相談ください。

GS2 に関するブログエントリー募集

Qiita や ブログ などで 『GS2 を触ってみた』といったエントリーを書いていただけませんでしょうか。ベータリリース後それらしい記事が出てきておらず少しさみしいです…。ぜひご支援いただけますと助かります!

Vue + TS に触れて2週間でシングルページアプリケーションを作ってリリースした話

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

本日 Game Server Services は次世代版のベータテストを開始しました。
これまで提供していた GS2 を GS2 Classic と呼び、次世代版 GS2 を単に GS2 と呼びます。

gs2.io

GS2 のリリースにあたっては非常に多くの新しいチャレンジを行いました。
それについては少しずつブログや登壇を通じて皆さんにお伝えしていきたいと思います。

今回は、GS2 のマネージメントコンソールをシングルページアプリケーションとして作りました。
しかも、Vue + TypeScript に触れて2週間で。というトピックで振り返ってみようと思います。

なぜ Vue + TypeScript にいたったか

GS2 Classic のマネージメントコンソールは Google App Engine を使用していました。
弊社はフルサーバレスアーキテクチャでサービスを作ることに並々ならぬ努力を重ねてきました。
そのため、マネージメントコンソールを作るにあたっても採用できる技術は非常に限られています。

GS2 Classic を GAE で運用してみて感じた一番のツラミはコールドスタート時の スピンアップ速度 でした。
GS2 も GS2 Classic も Function as a Service(いわゆる AWS Lambda) を計算基盤として開発しています。
こちらもスピンアップ速度は課題にはなるのですが、弊社では AWS SDKOSS で提供されているものではなくよりフットプリントが小さく、高速に動作するものを用意して使用するなど、サービスのレスポンスタイムを短くする努力をしてきました。

一方で、そこまで大量にアクセスが来るわけではないマネージメントコンソールは開発リソースをあまり割けていないのと、アクセス数がサービスのエンドポイントより圧倒的に少ない。というダブルパンチでコールドスタート時の応答速度がストレスを感じるレベルになっていました。
やはり、開発効率重視で Web Application Framework(WAF) を使ったアプリケーションを GAE に乗せてしまったのは大きな過ちだったのだと思います。
コンテナの起動速度だけでなく、ランタイムに使用しているJava仮想マシン(GS2 Classic はサービスでは Python を使用していますが、マネージメントコンソールは Java(Kotlin) で作っています)。そして、WAFの起動とレスポンスタイムを遅くする要素が満載です。

FaaS でも WAF を使った開発をしようというアプローチもありますが、スピンアップ速度が遅くなるので私はおすすめしません。
GS2 Classic も GS2 も非常に薄いレイヤーで設計されており、スピンアップ速度も最小になるよう心がけています。

というわけで、GS2 のマネージメントコンソールを開発するにあたっては割と早期に
『HTML + JS でサービスと同じ REST API エンドポイントを使って提供する』ということを決めていました。

なぜ Vue なのか

React や Angular といった WAF もあります。その中で Vue を選んだ最大の理由は、学習コストが低そうだったことです。
そう、タイトルにもあるように開発にかけられる時間が非常に限られていたのです。

なぜ TypeScript なのか

単に型が厳密な言語が好みだからです。

開発期間は2週間なのはわかったけど、人数は?

基本的に1人。
しかも大量に他の仕事も兼務してる。実質5営業日くらいしかかけられない。

で、できたものは?

f:id:kazutomo:20190716232113p:plain
Bootstrap 臭いUIなのは気にしないで

f:id:kazutomo:20190716232131p:plain
Vue コンポーネントを活用して複雑なUIもパズルのように組み合わせて実現してます

f:id:kazutomo:20190716232142p:plain
いたって普通の入力フォームはこんな感じ

f:id:kazutomo:20190716232154p:plain
ビューによってはこんなとんでもない入れ子構造のデータもあるけど、Vueコンポーネントならなんとかなった

f:id:kazutomo:20190716232210p:plain
当然、入れ子構造は入力側でも…

ページ数・コンポーネント数は?

正確に数えてないけど、1マイクロサービスあたりページ数で10。
ビュー用のパネルや入力用のパネルのコンポーネント数で50〜80くらいあると思う。
そのマイクロサービスが30個くらいあります。ひいふうみい…。おう…。

物理的に無理じゃない?

感のいいひとは気づいてしまったでしょう。2週間で 1500〜2000 のコンポーネントを実装するとか無理ゲーだということに。

GS2 はマイクロサービスを DDL で定義していて、そこから色々なものを自動生成しています。
FaaS で動くサービスの雛形とか、サービスにアクセスするための各プログラミング言語向けのSDKとか。
TypeScript でアクセスするための SDK もそうやって作ってます。

@data_structure(
    parent=Namespace.Namespace,
    data_owner=DataOwner(
        owner_holder=DataOwner.OwnerHolderSelf,
        owner_type=GamePlayer(),
    ),
    primary_key=String('accountId'),
    alternate_keys=[
        AlternateKey(
            field_name='userId',
        ),
    ],
    description='''
    ゲームプレイヤーアカウント
    
    Account はゲームプレイヤーを特定するためのユーザIDとパスワードを記録します。
    ''',
)
class Account(BaseModel):

    accountId = GenericGrn(
        primary_key=True,
        require=True,
        updatable=False,
    )
    userId = UUID(
        description='アカウントID',
        require=True,
        primary_key=True,
    )
    password = String(
        description='パスワード',
        require=True,
        updatable=True,
        default=Default.Value(),
    )
    createdAt = CreateTimestamp()

モデルの定義はこんな感じ。

@result(
    items=Array(Account),
    nextPageToken=String(
        description='リストの続きを取得するためのページトークン',
    ),
)
class Describe(BaseDescribeAction):

    namespaceId = Namespace.Namespace.namespaceId
    pageToken = PageToken()
    limit = database.AccountDefaultLimit()

    @path(GET, '/{namespaceName}/account')
    @policy('DescribeAccounts')
    @description(
        '''
            {model_name}の一覧を取得
        '''
    )
    @request(
        (namespaceId, [Request.Default()]),
        (pageToken, [Request.Default()]),
        (limit, [Request.Default()]),
    )
    def describeAccounts(self):
        pass

メソッドの定義はこんな感じ。

で、マネージメントコンソールようにこんな DDL を作った。

@description('{model_name}の新規作成')
@path(GET, '/namespace/:namespaceName/account/:userId/take_over/create')
class CreatePage(BaseConsolePage):

    def __init__(self):
        super().__init__(
            parent=Account.Console.DetailPage,
            name='create_take_over',
            panels=[
                Console.Panel.CreatePanel,
            ],
        )

class CreateInputPanel(BaseGeneralInputPanel):
    def __init__(self):
        super().__init__(
            properties=TakeOver.Create.createTakeOver.request,
        )

class CreatePanel(BaseCreatePanel):
    def __init__(self):
        super().__init__(
            method=TakeOver.Create.createTakeOver,
            input_panel=Console.Panel.CreateInputPanel,
        )

CreatePage はどういうページを作るかを定義してあって、
CreateInputPanel はどういうフィールドの入力フォームを用意するかが定義してあって、
CreatePanel は入力パネルとその送信先メソッドを定義している。

CreateInputPanel と CreatePanel が分離しているのは CreateInputPanel を入れ子構造の入力フォームで再利用できるように Submit ボタンの挙動を分離している。

というわけで、すべてのモデルデータに対応するDDL宣言を追加していって ジェネレータで一気に Vue コンポーネント を生成するようにした。

つらかったこと

これだけページやパネルがあるとビルド時に node のメモリが不足してなかなか動かなかった。
結局、最終的に32GB割り当ててビルドすることになった。
GS2 ではメモリ 64GB のマシンをみんなに割り当ててるのでよかったけど、みんなどうしてるんだろう。

gs2.hatenablog.com

最後に

めっちゃ厳しいスケジュールの中、なんとかリリースできました。
サービスの内容は 先日の Game Tool & Middleware Forum で発表した資料をみてね。

speakerdeck.com

まだまだ突貫工事感あるので、少しずつ改善していきます。

あと、ベータテストのフィードバックを GitHub Issue で受け付けて対応予定とかも載せてるので、興味があれば見てみてください。

github.com

それでは、また。

【登壇資料】Cloud2.0時代のゲーム開発を支えるGS2 / 協業のお知らせ #gc_cloud

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

本日開催された Google Cloud INSIDE 7 の登壇資料を公開しましたので、お知らせします。

speakerdeck.com

本登壇の中で 第二世代GS2 の発表をさせていただきました。
第二世代のGS2 は現行世代の GS2 では利用料金が時間あたりの利用料金とAPIリクエストあたりの料金の二軸でしたが、完全リクエスト単価制に変更します。
この変更によって、あらゆる規模のゲームにフェアプライシングでサービスを提供できるようになると確信しています。

さらに、Googleの協力の下第二世代GS2の負荷テストを実施したことも報告させていただきました。
第二世代のGS2は現行世代よりも多くのマイクロサービスを実装した状態でこの夏にβテストを開始し、年内にグローバルで正式サービスを開始します。
マイクロサービスを組み合わせることで、パズドラ・モンストのようなゲームをサーバ開発・運用をすることなく提供できるようになります。
本日よりエントリーを受け付けていますので、GS2のサイトより申し込みください。

第二世代のGS2は現時点で秒間10万リクエストをさばけることを確認しており、
この数値はローンチ時にSNSで話題となり、AppStoreやGooglePlayでセールスランク1位となったスクウェア・エニックスさんのシノアリスの秒間アクセス数5.5万を遥かに上回る数値です。
正式サービス開始までにより高い数値を出せるようチューニングを続けてまいります。

あわせて、本日 クラウドエース株式会社 との協業についても報告できることとなりました。
クラウドエースは GCP のプレミアムパートナー で確かな技術を持った会社です。
GS2 は クラウドエース と戦略的業務提携をおこない、公式のGS2リセラーに認定いたしました。
クラウドエースを経由してGS2を利用する場合、GS2を直接契約して利用するよりも細やかなサポートが受けられます。

ぜひともこのパートナーシップを活用して、面白いゲームを夜に送り出していただければと思います。

それでは、また。

(C) Game Server Services, Inc.