ドキュメント

サポート

Cloud Code

モジュールコスト

Understand the pricing model and free tier for Cloud Code modules.
読み終わるまでの所要時間 2 分最終更新 23日前

Cloud Code には無料枠があるため、開発とローンチは無料で開始できます。組織が無料枠または適用されるクレジット許容範囲を超えてスケールした後でのみ支払いが開始します。 UGS 製品価格の概要ページ で詳細および価格設定に関する FAQ を確認できます。

Unity サービスでの Cloud Code の使用

Cloud Code を Unity サービスとともに使用すると、使用したサービスの使用状況に対して課金されます。例えば、Cloud Code から Cloud Save サービスを呼び出すと、Cloud Save の呼び出しと Cloud Code の呼び出しの両方に対して課金されます。 詳細については、Unity サービスの料金 ページを参照してください。

プッシュメッセージの使用

Cloud Code WebSocket 機能を使用してクライアントにメッセージをプッシュする場合は、ネットワークの使用状況と関連するコストを考慮することが重要です。

エグレスコスト

モジュールからクライアントに送信する各メッセージはネットワーク帯域幅を消費し、モジュールからのアウトバウンドデータの合計量に影響します。Cloud Code は、WebSocket 接続上でのメッセージのプッシュに関連するネットワーク使用量を Cloud Code エグレスコストに追加します。 アプリケーションを設計する際にはエグレスコストを考慮し、メッセージを送信するタイミングと頻度を決定することが重要です。過剰または不必要に大きいメッセージは、エグレスコストが高くなる原因となります。 Cloud Code 価格設定の詳細については、コスト のページを参照してください。

メッセージサイズの制限

Cloud Code は、WebSocket 接続に送信されるメッセージのサイズを 10 KB に制限します。これは、より複雑またはデータの多いアプリケーションでは特に、送信するデータのサイズを管理する必要があることを意味します。 以下の方法を使用して、プレイヤーに常に最新情報を伝え、コストとネットワーク使用量を低く保つこともできます。

軽減

使用する状況

実現方法

データの差分を送信する。大量のデータやゲームの状態の大幅な変化を通信する必要があるとき。ペイロード全体ではなく、データの差分を送信します。差分は、既存の状態に適用する変更のセットであり、多くの場合に完全な状態データよりもはるかに小さくなります。
データの HTTP リクエストのプロンプトを表示する。完全なデータセットのサイズが大きく、不定期に発生する更新のみが必要であるか、HTTP を介してデータを取得する方が効率的またはコスト効果が高いとき。WebSocket メッセージをナッジメカニズムとして使用して、新しいデータが使用可能であることをクライアントに通知し、完全なデータセットを取得するには HTTP リクエストを行うよう求めるプロンプトを表示します。

Cloud Code のコスト

コストは、3 つのカテゴリで計算されます。

カテゴリ

説明

呼び出し呼び出しでは、組織内で Cloud Code モジュール関数の実行リクエストが成功した回数がカウントされます。成功した実行は、HTTP 200 ステータスコードでモジュールからレスポンスが返されたリクエストが対象になります。
コンピューティング時間コンピューティング時間は、組織内で Cloud Code モジュール関数の実行に費やした時間です。実行には、追加のウォームアップ時間も含まれます。
エグレスエグレスでは、組織内で成功した Cloud Code モジュール関数の実行からのレスポンスのサイズ (GB 単位) が測定されます。成功した実行は、HTTP 200 ステータスコードでモジュールからレスポンスが返されたリクエストが対象になります。

コスト削減のヒント

Cloud Code を使用するコストを削減するには、以下のヒントに従います。
  • モジュール関数のレスポンスに、使用するデータのみが含まれていることを確認します。モジュール関数のレスポンスに含まれる未使用のデータも、エグレスコストに影響します。
  • Cloud Code モジュール関数が、割り当てられた 15 秒のタイムアウト以内に完了することを確認します。予想外の
    while(true)
    ループにより、予期しないコストが生成される可能性があります。
  • 実行をバッチ化できるかどうかを検討します。例えば、Cloud Code モジュール関数
    FuncExampleB
    は、
    FuncExampleA
    からのレスポンスに依存する場合があります。これらを個別に呼び出すと、両方のロジックを 1 つのモジュール関数リクエストに結合した場合に比べてコストの金額が 2 倍になる可能性があります。

コマンドバッチ処理

コマンドバッチ処理は、各ゲームアクションが、キューに収集し、サーバーにバッチで送信して処理できるコマンドであるという概念です。詳細については、コマンドバッチ処理 のページを参照してください。 例えば、
Cloud Save
を呼び出してプレイヤーに XP を配布し、
Economy
を呼び出してコインを配布することにより、すべてのアクションの後にゲーム内報酬を配布するゲームについて考えます。プレイヤーは、以下の 3 つのアクションを完了します。
  • 最初のアクションの結果、100 XP と 10 コインが発生します。
  • 2 番目のアクションの結果、50 XP と 5 コインが発生します。
  • 3 番目のアクションの結果、200 XP と 30 コインが発生します。
これらを個別に実行した場合、これら 3 つのアクションの結果として、さまざまな Unity サービス (この場合は、Cloud Save と Economy) に対して最小で 6 回の呼び出しが行われます。一方、これらの 3 つのアクションすべてをバッチコマンドとして保存し、単一の Cloud Code モジュール関数リクエストを通じて処理できます。これは、ゲームが行う必要があるのは 2 回の Unity サービス呼び出しのみであることを意味します。XP を 350 増やすために Cloud Save に対して 1 回と、45 コインを追加するために Economy に対して 1 回です。