/ja/tags/tech/ Recent content in Tech on Game Server Services | Docs Hugo ja /ja/articles/tech/error/pattern/ Mon, 01 Jan 0001 00:00:00 +0000 /ja/articles/tech/error/pattern/ GS2 を利用したネットワーク機能の実装において、エラーハンドリングはゲームの安定性とユーザー体験（UX）に直結します。 ここでは、単なる例外のキャッチに留まらない、実践的な実装パターンを紹介します。 1. エラーの分類と対応方針 GS2 の例外は、その性質によって大きく 3 つに分類できます。 分類 該当する例外 (例) 対応方針 一時的なエラー InternalServerError, ServiceUnavailable, RequestTimeout 自動リトライ。数回試行してもダメな場合はエラーダイアログを表示。 ロジック/設定エラー BadRequest, NotFound 開発中に解消すべきエラー。リリース後はバグとしてログ収集し、ユーザーには適切なメッセージを表示。 認証・状態エラー Unauthorized, Conflict, QuotaLimitExceeded 特別なリカバリ処理が必要。再ログインや、データの再同期（ドメインの再取得）を行う。 2. リトライ戦略の実装（指数バックオフ） サーバーの過負荷や一時的なネットワークの不安定さによるエラーに対しては、即座にリトライするのではなく、間隔を空けてリトライする「指数バックオフ（Exponential Backoff）」が推奨されます。 Unity / C# での例（自動リトライ） public async Task<T> ExecuteWithAutoRetry<T>(Func<Task<T>> action, int maxRetries = 3) { for (int i = 0; i < maxRetries; i++) { try { return await action(); } catch (Gs2.Core.Exception.Gs2Exception e) when (e.RecommendAutoRetry) // 自動リトライ推奨か判定 { if (i == maxRetries - 1) throw; // 指数バックオフ: 1s, 2s, 4s. /ja/articles/tech/cache/ Mon, 01 Jan 0001 00:00:00 +0000 /ja/articles/tech/cache/ GS2 の Game Engine 向け SDK (GS2 SDK for Unity, GS2 SDK for Unreal Engine など) には、サーバーから取得したデータを SDK 内部にキャッシュする機構が組み込まれています。 このキャッシュ機構を理解することで、API 呼び出し回数を削減し、ゲームのレスポンス性とコストの両方を改善できます。 キャッシュの基本動作 Domain オブジェクト（gs2.Inventory.Namespace(...).Me(...).Inventory(...) のようなアクセス）を介してデータを取得すると、取得したデータは SDK 内部のキャッシュに保持されます。 同一のリソースに対する再取得は、サーバーに問い合わせを行わず、キャッシュから返されます。 そのため、UI の各所で必要となる値を都度サーバーから取得しなくても、Domain オブジェクトを通して何度でも安心して値を参照できます。 キャッシュの自動更新 サーバー側でデータが更新された場合は、SDK 側のキャッシュも自動的に最新の状態に追随します。 具体的には以下のタイミングで反映されます。 API 呼び出しの応答内に含まれるリソース情報を受け取ったとき WebSocket 接続を介してリソースの更新通知を受け取ったとき スタンプシートの実行結果として返却されたリソース情報を受け取ったとき 例えば、Gs2-Showcase で商品を購入すると、その購入処理によって増加した Gs2-Inventory のアイテム所持数も、購入 API の応答に含まれる結果から自動的に SDK 内のキャッシュへ反映されます。 UI 側でわざわざ「アイテム一覧を取り直す」必要はありません。 設計指針 取得 API は躊躇なく呼ぶ Domain オブジェクト経由の ModelAsync / Model / Fetch といった取得処理は、初回はサーバーへリクエストを発行し、以降はキャッシュから値を返します。 そのため、UI を更新するたびに値を読みに行く実装にしても、過剰なリクエスト料金が発生することはありません。 // UI 描画のたびに呼んでも、初回以降は SDK 内のキャッシュから返る var item = await gs2. /ja/articles/tech/cost/ Mon, 01 Jan 0001 00:00:00 +0000 /ja/articles/tech/cost/ GS2 は従量課金制を採用しているため、ゲームの設計次第で利用料金が大きく変わる可能性があります。 このセクションでは、パフォーマンスを維持しつつコストを抑えるための設計のポイントを解説します。 1. API 呼び出し回数の削減 GS2 の料金の大きな割合を占めるのが API のリクエスト数です。 SDK のキャッシュ機構を活用する GS2 SDK にはキャッシュ機構が組み込まれています。 同じデータを短時間に何度も取得する場合、サーバーへリクエストを飛ばさずにキャッシュから返すように設計されています。 SDK の各メソッドの Future や Async 版を使用する際、可能な限り高レベルな API（Domain オブジェクトを介したアクセス）を使用してください。 まとめて取得・更新する 例えば、複数のアイテムの所持数を取得する場合、個別に API を呼ぶのではなく、インベントリ全体を一度に取得する方がリクエスト数を抑えられます。 2. GS2-Deploy によるリソースの適切な管理 不要なネームスペースやリソースが残っていると、わずかですがストレージ料金や管理コストが発生し続ける場合があります。 開発環境や検証環境は、不要になったら GS2-Deploy のスタックを削除することで、関連するリソースを一括でクリーンアップできます。 3. GS2-Script の実行効率 GS2-Script の実行料金は、実行時間に応じて変動します。 効率的なコード: ループ内での不要な API 呼び出しを避けるなど、Lua スクリプト自体の効率を高めて実行時間を短縮してください。 外部通信の最小化: http.get などの外部通信は実行時間を延ばす要因になります。 なお、メモリ使用量は直接料金には影響しませんが、使用可能なメモリ容量には制限がある点に注意してください。 4. ログと分析の活用 各マイクロサービスのネームスペース設定で GS2-Log を関連付けることで、各マイクロサービスのアクセスログ（リクエスト・レスポンスの内容）を収集できます。 これにより、特定の機能が想定以上のリクエストを発生させていないか、どの API がコストの要因になっているかを詳細に分析し、最適化に役立てることが可能です。