PlayFab 消費量: ベストプラクティス
PlayFab の消費量ベースの価格モデルでは、タイトルの実際のサービス利用分に対してのみお支払いいただきます。しかし、ここで当然の疑問が生じます。必要な機能をすべて実装しつつ、コストを抑えるためにタイトルをどう最適化するのがベストなのでしょうか。このドキュメントでは、その詳細に踏み込み、事前に計画する上で役立つベストプラクティスを説明します。 タイトルを開発モードから本番運用に移行する前に、Game Manager の Billing Summary タブでメーター情報を確認できます。 消費量メーターは 6 種類あります: Events、Profile、Content and Configuration、CloudScript、Insights、Multiplayer Services です。タイトルの最適化を始めるには、まず使用している各メーターを確認し、時間の経過とともにどのように蓄積されるかを見るのが最善の方法です。これにより、明らかな改善点をすばやく引き出すことができます。メーターの詳細については、価格メーター を参照してください。Events
PlayFab には 2 種類のイベントがあります: PlayStream と Telemetry です。 PlayFab は PlayStream イベントを処理し、定義された PlayStream Actions をトリガーするかどうかを確認したり、User Segmentation を更新したりします。一部の PlayStream イベントは、認証や統計情報の更新などのサービス機能の呼び出しの結果として自動的に生成されます。タイトルは、この機能を拡張するために独自のカスタムイベントを生成できます。 Telemetry イベントは PlayStream では処理されません。これらのイベントは分析用途に使用され、直接データウェアハウスに送られます。Telemetry イベントは PlayFab で自動生成されるものではなく、タイトルによって生成されるカスタムイベントです。 いずれのイベントタイプでも、データのペイロードが大きくなるほどメーターの合計使用量が増加します。必要なデータだけを送信するようにすることで、全体的な使用量を削減できます。おおよその目安として、任意のイベントは、イベント本文内のデータ 1 KB ごとに該当メーターを 1 だけ増分します。 自分の利用目的に最も適したイベント経路を選ぶには、生成する各カスタムイベントをどのように利用するのかについて明確な計画を持つ必要があります。タイトルのオフライン評価のためだけに必要なイベントは Telemetry ルートを利用してください。Telemetry イベントの超過料金は PlayStream の半分以下であるため、これによりコストを大幅に削減できます。 構築済みの SDK のいずれかを使用している場合、ユーザー行動に関する一部の分析データが自動的に生成されることを覚えておくことが重要です。詳細は PlayStream Event Model リファレンス を参照してください。オプションのイベントをオフにするには、PlayFab Game Manager のゲームの Settings/Data Collection タブで分析設定を変更してください。同様に、デバッグ中は CloudScript の実行に対して「generate PlayStream event」オプションをオンにしておくのは良いアイデアですが、本番運用に移行する前には必ず無効にする必要があります。PlayStream Action によってトリガーされる CloudScript の場合、実運用で動作をデバッグする必要が出てきた場合には、後からいつでもオンに戻せます。Profile
プロフィールは事実上「プレイヤーに関するすべて」を表しており、インベントリ、保存データ、統計情報などの一般的な要素が含まれます。また、前述の User Segmentation のように、PlayStream の LiveOps 機能を通じて固有の体験を提供するために使用するメタ情報も含まれます。加えて、Title Data、Catalogs、Stores といったタイトルレベルのレガシー機能の一部も、そのデータ実装が実質的に User Data と同じであるため、このメーターに含まれます。この一連のメーターは、すべてのプレイヤーのアクション、およびプレイヤーに対して行われるアクションによって駆動されるため、圧倒的に最も最適化計画が必要なものとなります。 価格メーターで捕捉される使用量に主に寄与する要因は、読み取り、保存、書き込みされるデータの量、およびメーター対象のデータを生成する API を呼び出す頻度です。 これらのメーターに「回転」を与える具体的な API 呼び出しの詳細については、価格メーター を参照してください。 まず、使用パターンが類似している User Data と Statistics から始め、続いてプレイヤーインベントリ管理について説明します。データと統計
User Data の使用量を評価する際、イベントと同じ近似ロジックが適用されます—各 1 KB がメーターカウントを 1 増加させます—ただし、この計算の目的においては、呼び出しの各「要素」は別個のものと考えるべきである点に注意してください。User Data 更新の呼び出しにおける各キーと値のペアは、それぞれ別にカウントされます。読み取りの場合、この 1 KB の計算はキーと値のペアの数に関係なく、返される合計データに適用されます。つまり、100 バイトのキーを 10 個書き込むことは、キーと値のペアの書き込みが最低でも 1 KB としてカウントされるため、プロフィール書き込みメーターの「10 目盛り」となる一方、それら 10 キーの読み取りは合計 1 KB であるため「1 目盛り」となります。使用量の詳細については、価格メーター を参照してください。 Statistics はやや複雑で、プロフィールを更新し、リーダーボードにも影響を与える可能性があります。一般的な目安として、更新される各統計はプロフィール全体の更新として考えられ、読み取りは各呼び出しで読み取られるデータの合計サイズに基づきます。またストレージは 1 GB あたりで課金され、統計は通常わずか数バイトしか消費しないため、ここでは読み書きに焦点を当てます。 合計データサイズが重要であるため、まずそれを最適化することが第一歩です。幸いにも、この目的にはよく知られたテクニックが数多くあります。たとえば、アイテムに対して綴られたテキストの代わりに enum や ID を使用する、大規模データをバイナリとしてパックする、あるいはビットフィールドを使用してデータをより小さなスペースにパックする、などです。これが完了したら、次のステップとして、これらの読み書き呼び出しをいつ行う必要があるかを慎重に評価します。 もしあなたが PC やコンソール開発、特にシングルプレイヤー ゲームから来ているなら、これは新しいパターンかもしれません。ただし、これらの環境では、クライアントデバイス上のリソースヒットとガベージコレクションに注意する必要があります。重要なタイミングでパフォーマンスの低下を引き起こす可能性があるからです。タイトルがクラウド上のリソースを使用する場合、そのロジックを拡張し、パフォーマンス コストに加えて、各リソースヒットに実際のコストが発生することを考慮する必要があります。 読み書きの最適な頻度をどのように決定しますか?データや統計をより頻繁に更新したいと考える開発者にとって最も一般的な懸念事項の 2 つは、チート対策と、プレイヤー間のやり取りのために、あるいはゲームが予期せず終了した場合のデータ損失を防ぐために、タイムリーな情報をサーバー側に保存することです。チート対策
必要不可欠なセキュリティを確保するためにバックエンドデータを常に更新する必要があるように見えるかもしれませんが、ゲームがセッションを完全にサーバー主導で制御する必要がない限り、頻繁な更新はほとんど必要ありません。まず、根本的な問題は、実際にどれだけのセキュリティが必要かということです。 一部のゲーム、特にゲーム内広告で主に収益化しており、リーダーボードを持たないゲームでは、チートは大きな懸念事項ではありません。この場合、そのデータのセキュリティは実際にはあまり気にならないため、クライアントが送信するデータを信頼するアプローチが有効です。チート行動を特定し、どのように処理するかを決定するために、プレイヤーのイベント、データ、統計を確認するプロセスを実装することをお勧めします。 競争の完全性を維持したり、全体的なプレイヤー体験を保護したりする必要がある他のゲームでは、より強固なセキュリティが重要になります。具体的な要件によっては、特定のアプローチによりデータの読み書きの頻度を減らせる場合があります。 ゲームがリアルタイムでない場合、推奨するアプローチの 1 つは、ある期間、しばしばゲームの「ラウンド」で、数分間にわたってプレイヤーのゲームに関する情報を集約し、そのデータを検証するスクリプトに送信することです。評価すべき主要な要素はゲームによって異なりますが、考慮すべき一般的な概念の例をいくつか挙げます:- 前回のセッションレポートからどれくらい時間が経過し、クライアントは最新のセッションでどれくらいプレイしたと報告しているか?
- プレイヤーが登録したスコアは、そのプレイヤーのレベル、装備などから見て妥当か?
データの時宜性
書き込みレートが高いプロフィールを持つ開発者の間でよく聞かれるテーマの 1 つは、プレイヤーが進捗を失うことへの懸念です。プレイヤーがゲームを保存する前に終了し、次回プレイ時にローカルの状態が使用できない、あるいはその状態をデバイス間で移動する必要がある場合、プレイヤーの PlayFab 保存状態情報を可能な限り最新に保ちたいと考えるでしょう。 多くのゲームでは、サービスへの定期的で頻度の低い更新のハートビート(たとえば 15 分ごと)を行うことで、この問題に対処できます。しかし、その頻度を長くしたり短くしたりする追加のロジックを含めることも役立ちます。たとえば:- プレイヤーが積極的に重要な行動をとった場合に、即時書き込みを引き起こしてタイマーをリセットする「重要な更新」オーバーライドを含め、失われないようにします。
- ゲームがプレイヤーの入力なしで進行し続ける場合、長時間入力がなければハートビート期間を長くすることを検討します。これは、プレイヤーが夜通し実行しっぱなしにすることが多いアイドル ゲームで特に重要です。
- ユーザー メニューのボタンなど、プレイヤーが直接更新を強制する方法を提供します。ただし、この場合、クライアントデバイスから PlayFab に実際に呼び出されるレートを必ず制限してください。そうすれば、プレイヤーがそのボタンを何度も押しても、毎回呼び出しが生成されることはありません。