「PlayFab」の記事 - Crieit

📔 PlayFab の API 制限に引っかかった

2021-03-16T01:03:30+09:00

はじめに

PlayFab で CloudFunction を利用しているときに API 制限に引っかかってしまいました。負荷テストをした際に初めて気づいたのですが、公式ページにも言及が無かったため発覚が遅れてしまいました。そのため、PlayFab に依存していた機能を部分的に外す必要が出てきてしまい苦労しました。

本記事では、上記のような事態に陥る方を減らすため、API 制限に気づくまでの軌跡を辿りながら、PlayFab の CloudFunction を利用する際の注意点について、記事として残しておきたいと思います。

PlayFab の API 制限に引っかかった要因

PlayFab の CloudFunction を利用すると、PlayFab 経由で独自 Web API を実行することが可能になります。また、CloudFunction 経由で独自 Web API を実行すると、PlayFab ユーザ情報が含まれたパラメタが含まれた状態でリクエストが飛んでくるため、その情報を利用することでサーバーサイドで PlayFab の操作を行うことが出来るようになり大変便利です。

そのため、あるプロジェクトでは PlayFab CloudFunction を Azure Function や AWS Lambda のような FaaS を使っている感じで利用しておりました。そして、その利用の仕方は誤りであったことに後々気づきます...

負荷テストを実装するフェーズで CloudFunction を大量に叩いてみる

PlayFab の CloudFunction を実行するにあたり利用した PlayFab の API は Server-Side Cloud Script - Execute Function というものになります。

同接 2000 人想定で負荷テストのシナリオを実装することが求められていたため、その通りシンプルに 2000 件同時に Server-Side Cloud Script - Execute Function を実行するシナリオを Gatling で組んでみました。すると、何回やっても数十件以上は必ずエラーが発生していることが分かりました。

# Gatling で負荷テストを実行した際に 50件失敗している様子
================================================================================
---- Global Information --------------------------------------------------------
> request count                                       2000 (OK=1950   KO=50    )
> min response time                                    320 (OK=320    KO=354   )
> max response time                                  14459 (OK=9723   KO=14459 )
> mean response time                                   998 (OK=934    KO=3485  )
> std deviation                                       1510 (OK=1304   KO=4310  )
> response time 50th percentile                        545 (OK=543    KO=656   )
> response time 75th percentile                       1085 (OK=1077   KO=7209  )
> response time 95th percentile                       2243 (OK=2029   KO=10210 )
> response time 99th percentile                       7947 (OK=7775   KO=14353 )
> mean requests/sec                                    100 (OK=97.5   KO=2.5   )
---- Response Time Distribution ------------------------------------------------
> t < 800 ms                                          1393 ( 70%)
> 800 ms < t < 1200 ms                                 367 ( 18%)
> t > 1200 ms                                          190 ( 10%)
> failed                                                50 (  3%)
---- Errors --------------------------------------------------------------------
> status.find.is(200), but actually found 400                        50 (100.0%)
================================================================================

正直 2000件程度の API アクセスであれば、何の問題もなく負荷テストが通ると考えていたので、この結果には驚きました。原因は何なのか調べたところ、Azure Function で PlayFab ユーザ認証を行うために利用していた Authentication - Validate Entity Token で 503 エラーが発生していることが分かりました。

少ない API 実行件数で負荷テストを実行する場合は問題ないのですが、件数が一定数超えたタイミングで 503 エラーが返却されるようになってしまいます。しかし、たまに同じ件数を実行しているはずなのにスムーズに全件 API 実行に成功することもありました。これは何らかのレートリミット等に引っかかっているのかも知れないということで調査したところ、次の事実が判明しました。

CloudFunction は FaaS の用途には適さない

どうやら PlayFab 公式フォーラムのある投稿によると、PlayFab の Server API を呼び出す際は 10秒間に 1000回という制限があるようでした。 そして、この制限を突破するには商用のための契約をした後にインスタンス割当に関する交渉をすることで可能になるかも知れないとのことでした。

Servers are rate limited to 1,000 calls per 10 seconds. What jital is highlighting that the per-player rate should be no more than a few times a minute. A server can call at a higher rate, as it is calling for a lot of users, potentially. If you need a higher limit than 1,000 per 10 seconds, you'll want to talk to our sales team about getting on an Enterprise contract so that we can work with you on custom limits. There's an option on the Contact Us form on the main site to message them, if you want to go that route.

つまり、普通に PlayFab を利用している限りはプランをアップグレードしようと制限に引っかかるということが分かりました。 また、今年 1月に投稿された内容を見るに 10秒以内に 5000以上のユーザーがログイン/登録できたとあり、もう API の 10秒間に 1000回呼び出し制限は撤廃されたのかを聞いているユーザがいたのですが、まだ撤廃されていないと返信されていたので偶然だったようでした。

ちなみに私も上記が気になったので、セッションごとにレートリミットのかかり方が変わるのか検証するために異なるユーザ情報を用いてリクエスト 2000件を並列に実行してみましたが、503 エラーは変わらず返却され続けていたので、少なくとも私の手元の環境では効果はなさそうでした。

No, the rate limits on the Client and Server API calls has not changed. However, the rate limits are currently enforced on a per-server basis. And since the service runs a great many servers for load balancing, it is possible to exceed those limits from time to time.

原因の調査中 PlayFab は EC2 の us-west-2 リージョンでリクエストを受けていそうなことが分かったのですが、そのアクセス先のインスタンスがロードバランサによって分散されているため、レートリミットの制限がインスタンス先により、時と場合によって制限されるかどうかが決まってくるのかもしれないとのことでした。

以上のことから、PlayFab の CloudFunction については Azure Function や AWS Lambda のような FaaS のような用途には使わず、あくまでもアプリケーションで補助的に利用するための独自スクリプトを動かす程度に留めて利用するのが正解なように感じました。

PlayFab のユーザ認証情報である SessionTicket や EntityToken を利用することで、認証周りの実装部分を省くことが出来るかも知れないと思い期待していたのですが、それは別の BaaS を使うか IaaS で自前で作るのが良さそうでした。

おわりに

API の 10秒間に 1000回呼び出し制限については明示的にドキュメントに記載があるわけでもなかったため、気づくことが出来ずプロジェクト終盤で気づくという事故が起きてしまったのですが、私と似たような境遇に陥る人が少しでも減るようにと記事を書いてみました。

とはいえ、少し調べれば出てくるような制限だったので純粋に調査不足だったなあと反省しました。。CloudFunction はとても便利ですが、利用する際は API の呼び出し制限等用法には十分お気をつけてご利用くださいませ。

PlayFab が便利な BaaS であることに疑いの余地は無いので今後も利用すると思いますが、知見を貯めつつ効果的に使えるよう勉強していきたいと考えております。また何か知見を得たら随時ブログ記事に書き溜めていきたいと思います。

参考リンク

【PlayFab入門】UnityでPlayFabサーバーとデータの送受信

2019-05-28T19:37:44+09:00

2019/4/28

おはようございます。

「１日３食、夜は寝る」は誰が決めたんだろうと思っている、大学生ゲーム制作者の村人Uです。

今回は、Azureが運営するPlayFabというサービスを利用して、サーバーでデータ管理をする方法について書きます。

説明はUnityを使用したものになりますが、使い方はUnity以外でもあまり変わりません。

PlayFabについては、別の記事に書きましたので今回は実際の使い方について触れていきます。

無料で使えるmBaaSのPlayFabをプレイヤーデータ管理に使ってみた by 大学生ゲーム制作者 - QUEST LAB

サーバーにログインする

PlayFabでは、ユーザーがサーバーに必ずログインする必要があります。

といっても、ユーザーにIDとパスワードを決めてもらう必要はなく、こちらで勝手に決めたIDでログインができます。

//using PlayFab.ClientModels;をスクリプトの最初に記述して下さい

public static void LoginPlayFab(Action resultCallback = null)
    {
        var request = new LoginWithCustomIDRequest { CustomId = SystemInfo.deviceUniqueIdentifier, CreateAccount = true};
        PlayFabClientAPI.LoginWithCustomID(request, result => OnLoginSuccess(result, resultCallback), OnLoginFailure);
    }

上記の例で、LoginPlayFab関数を使う事でPlayFabにログインする事ができます。

なかなかヘンテコな書き方があって、見慣れないかもしれませんがPlayFabを使う場合は今後もこんな感じで書いていきます。

        var request = new LoginWithCustomIDRequest { CustomId = SystemInfo.deviceUniqueIdentifier, CreateAccount = true};

この部分では、ログインするためのリクエスト文を作成しています。

この中のCustomIdがユーザーを識別するIDで、ユーザー毎にユニークな（唯一の）IDを指定する必要があります。

今回の場合は、SystemInfo.deviceUniqueIdentifier という端末ごとに違うIDを取得して利用しています。

このように、CustomIdやCreateAccountのようなPlayFabさんが事前に決めた変数名に値を代入する事でPlayFabのサーバーにどんな指示を送るか決める事が出来ます。

注）これらは、using PlayFab.ClientModels; がスクリプトの最初に記述されている必要があります。

サーバーにデータを送信する

サーバーへのログインに成功したら、データを送信する事が出来るようになります。

public static void SendUserData(){
   PlayFabClientAPI.UpdateUserData(
            new UpdateUserDataRequest(){
            Data = new Dictionary() {
            {"Coin", "10"}
        }}, result => Debug.Log("Successfully updated user data"),
            error => {
                Debug.Log("Got error setting user data");
                Debug.Log(error.GenerateErrorReport());
            });    
}

これまたヘンテコなのですが、↑ではPlayFabClientAPI.UpdateUserDataという一つの関数しか使っていません。

このように関数を使う事によって、今回の場合サーバーに、「キーが"Coin"、値が"10"」のデータを送信する事が出来ます。

ちなみに、この関数は↓のような引数を取っています。

PlayFabClientAPI.UpdateUserData(UpdateUserDataRequest request , Action resultCallback, Action errorCallback);

今回の場合、この中のrequestの部分が

new UpdateUserDataRequest(){
            Data = new Dictionary() {
            {"Coin", "10"}
        }}

に当たり、resultCallbackが

 result => Debug.Log("Successfully updated user data")

に当たり、errorCallbackが

error => {
                Debug.Log("Got error setting user data");
                Debug.Log(error.GenerateErrorReport());
            }

に当たります。

サーバーからデータを受け取る

サーバーへの送信とほぼ同じ感覚で出来ます。

public static void GetUserData(){
 PlayFabClientAPI.GetUserData(
            new GetUserDataRequest() {
            PlayFabId = PlayerData.Instance.MyPlayFabID,
            Keys = null
        }, OnGetUserData
        }, (error) => {
            Debug.Log("Got error retrieving user data:");
            Debug.Log(error.GenerateErrorReport());
        });
}

public static void OnGetUserData(GetUserDataResult result){
         if (result.Data == null || !result.Data.ContainsKey("Coin")) Debug.Log("No Coin");
        else result => Debug.Log(result.Data["Coin"].Value);
}

↑の例では、PlayFabサーバーからユーザーデータを取得し「Coin」というキーを持つデータの値を取り出しています。

ここでもサーバーにデータを送信する時と似た感じで、次のような関数を使っています。

PlayFabClientAPI.GetUserData(GetUserDataRequest request , Action resultCallback, Action errorCallback

送信時と大きく違うのは、この関数の引数の内resultCallbackに当たる部分がOnGetUserDataになっているという事です。

見てもらえれば分かるように、resultCallbackの型は Action になっています。

この Action という型は、「GetUserDataResultを引数にとる関数」を表します。

なので、今回の場合OnGetUserDataというGetUserDataResultを引数に持つ関数を指定する事が出来ます。

そしてこのresultCallbackという引数ですが、これはPlayFabからデータの取得が成功した時に呼び出される関数になります。

つまり、今回の場合データの取得が完了したらOnGetUserDataという関数が呼び出されることになります。

またその時に引数に渡されるGetUserDataResultに様々な情報が格納されています。

実際には、上記のようにresult.DataにデータがDictionaryの形で格納されているのでそれを利用する事が多いと思います。

もっと知りたい

今回書いたのは、正確にはPlayFabの中のごく一部の機能であるPlayerDataについてです。

PlayFabにはデータの管理の方法だけでも

Player Data
Read Only Data
Internal Data
Group Data
Shared Group Data

など、様々なデータの扱い方があります。

複雑に感じるかもしれませんが、逆に言うとそれだけ機能が充実しているという事でもあると思います。

詳しい説明は↓のPlayFabのドキュメントに載っています。

現時点(2019/4/28)で全て英語ですが、グーグル翻訳を使えば割と読めちゃいます。

最近のグーグル翻訳は凄いですね。

Azure PlayFab のドキュメント - PlayFab | Microsoft Learn

無料で使えるmBaaSのPlayFabをプレイヤーデータ管理に使ってみた by 大学生ゲーム制作者

2019-05-20T17:56:38+09:00

ご存知の方は少ないかもしれませんが、サーバーの知識いらずでサーバーでデータ管理できるサービスがあります。

そのサービスはmBaaSなどと呼ばれています。

特にUnityを使う個人開発者は、Nifty Cloud Mobile Backend (NCMB) を使う人が多いイメージです。

しかしどうやら、同様の機能をもつPlayFabというサービスもあるようです。

さらに最近、どんどん便利になってきているらしい。

2018年1月にMicrosoftに買収されたとか。

今回は、そんなPlayFabを実際に使ってみた感想とまとめを書いてみようと思います。

PlayFabで出来る事

そもそもPlayFabで何が出来るかというと、

サーバーでデータ管理
ログインなどプレイヤー管理
フレンド機能
SNS連携
グループ、ギルド機能
アイテム管理
課金機能
サーバーサイドのスクリプトも実装可能
統計をカスタマイズして見れる

こんな感じの事が出来ます。
これらの機能をいい感じに管理してくれているのが、PlayFabの特徴です。

今回僕が使ったのは、1 ~ 3の機能だけですが十分便利でした。

また、現在はプレ版ですが今後のアップデートでリアルタイム通信関係の機能も追加されるようです。

PlayFabの利用例

https://playfab.com/games/のページに載っていますが、

など、有名なゲームの利用例があるようです。

世界的に有名なゲームの名前があるので、信用できるサービスと言えます。

また、PlayFabを調べていると2015年の記事も見つかるので海外では割と長い事使われていそうです。

PlayFabの利用価格

https://playfab.com/pricing/のページに載っています。

無料枠では、

一部の機能が利用できない
MAU(月のアクセスユーザー数)の制限なし
データ容量、APIリクエスト回数制限に関する記述はなさそう

一部の機能が利用できない事についてですが、有料枠の機能は僕が見ても何に使う機能か分からないレベルの物が多かったです。

この記事で書いてきた機能についてはおそらく全て無料で利用可能です。

正直、無料枠で十分だと思っています。

（まだ実際に運用している訳ではないので、断言はできません）

その他サービスとの比較

その他サービスと言っても、僕はNCMBしか使ったことないのですが...

PlayFabを使うメリットは、

ユーザー管理が楽かつセキュア（既に必要な機能が揃っている）
ゲームに特化している
有名な利用例もあり、信用できる

デメリットは、

ドキュメントが英語しかない
使い方がやや複雑（導入コストが高い）
ゲーム特化な分、自由度が低い

NCMBなどの場合、ログイン機能やフレンド機能だけでも結構大変です。

まして、アイテム交換などの機能を作ろうと思うと骨が折れます。

PlayFabではその辺の事は既に用意されているので、メソッドを使うだけで便利です。

にも関わらず日本でPlayFabはあまり浸透していません。

おそらく一番の原因は、日本語のドキュメントがない事です。

僕も調べていて、導入部分だけの記事くらいしか見つかりませんでした。

しかし、Microsoftがつい最近新しいドキュメントを公開していて、それを見ると日本語に対応してくれそうな雰囲気を出しています。（言語で日本語が選択できる）

今後、期待できるかもしれません。

PlayFabの新しいドキュメントはこちら

またPlayFabは仕組みを理解するまで少し時間がかかります。

機能が設計されている為、NCMBほどユーザーの自由なデータ管理も出来ません。

融通が利かなくて困るケースも出てくるかと思います。

まとめ

現状をまとめると、英語がよめるなら機能が豊富なPlayFabはおすすめ。

厳しければ、シンプルイズベストのNCMBや応用性の高いFirebaseなどを使った方が良いと思います。

また、まだ機能が完全に完成していない部分もあって今後の進展に期待といった感じです。

日本語ドキュメントが公開された辺りから、使い始めてみると良いのではないでしょうか。

もしかしたら僕がPlayFabの記事を書くかもしれませんが。

その時はよしなに。ではでは。