/ja/overview/workflow/setup_gs2_resources/ Recent content in GS2にリソースを作成 on Game Server Services | Docs Hugo ja /ja/overview/workflow/setup_gs2_resources/manual_setup/ Mon, 01 Jan 0001 00:00:00 +0000 /ja/overview/workflow/setup_gs2_resources/manual_setup/ 開発者がまずマネージメントコンソールでやるべきことは、ネームスペースの作成とマスターデータの登録です。 これらはマネージメントコンソール上で作成が可能です。 リージョンの選択 サイドメニューの下方にリージョンメニューがあります。 ここからマイクロサービスを操作するリージョンを選択できます。 ネームスペースの作成 マネージメントコンソールにログインし、マイクロサービスを選択します。 ネームスペースの一覧が表示されたら、ネームスペースを新規作成します。 設定項目に値を入力し、確定すればネームスペースの作成は完了です。 マスターデータの登録 マイクロサービスによっては、機能を利用する前にマスターデータの登録が必要な場合があります。 マスターデータの登録が必要なマイクロサービスには、ネームスペースの詳細ページに「マスターデータ」というタブがあります。 タブを選択すると「Currently available master data could not be found」というようなエラーが表示され、まだマスターデータが登録されていないことがわかります。 マスターデータエディターの利用 マスターデータを作成するには マスターデータエディタ が利用できます。 ネームスペースの詳細ページに「マスターデータエディタ」というタブがありますので、それを選択します。 このスクリーンショットは GS2-Inventory の例です。 マスターデータの作成について説明するために、GS2-Inventory がどのようなマスターデータを必要とするのか説明しましょう。 class InventoryModel { +string 名前 +int 初期サイズ +int 最大サイズ } class ItemModel { +string 名前 +int スタック可能な最大数量 +bool スタック可能な最大数量を超えた時、複数枠にアイテムを保管することを許すか +int 表示順番 } Namespace "1" *-- "many" InventoryModel InventoryModel "1" *-- "many" ItemModel GS2-Inventory には容量制限のある Inventory と、Inventory に格納できる Item の定義が必要です。 Inventory には初期容量と最大容量。Item には1容量で最大いくつのアイテムをスタックできるか、アイテムの所持数量がスタックできる最大数に達した時、2スタック目を作成するかを設定します。 /ja/overview/workflow/setup_gs2_resources/automation_setup/ Mon, 01 Jan 0001 00:00:00 +0000 /ja/overview/workflow/setup_gs2_resources/automation_setup/ マネージメントコンソールを使用したセットアップは手軽に実行できるのは魅力です。 しかし「同じ環境をもう一つ作って欲しい」というオーダーを受けた時にあなたは絶望するに違いありません。 ゲーム開発では一般的に「開発環境」「検証環境」「本番環境」のように複数のサーバー環境を必要とします。 それぞれで、マネージメントコンソール上で同じ操作を繰り返して GS2 への設定をミスをせず行うのは不可能と言えるでしょう。 GS2-Deploy そこで、GS2 には環境構築のためのマイクロサービスである GS2-Deploy が用意されています。 あなたがクラウドに精通したエンジニアであれば、AWS が提供している Cloud Formation の GS2版 と言うだけで、このマイクロサービスの役割を理解できます。 理解できたあなたはこれ以上このページを読み進める必要はありません。GS2 は Cloud Formation のような機能を使って、マイクロサービスをオーケストレーションできます。 そうではないあなたも安心してください。ここから GS2-Deploy について詳しく解説します。 Infrastructure as Code 管理画面を使用して GS2 への設定を反映することの愚かさについて、すでにあなたが理解している信じています。 このような愚かさに対抗するべく、サーバーインフラの世界では様々な改善が行われてきました。 そして、その成果が Infrastructure as Code(IaC) です。 20年前には、サーバーを新しくセットアップすることになったインフラエンジニアは1台1台にコマンドを入力して環境を構築していました。 「HTTPサーバーをインストール」「HTTPサーバーの設定ファイルを更新」「データベースサーバーをインストール」「データベースにスキーマを登録」 その作業は1台であれば問題ありませんが、100台のサーバーに設定するとなるとどうでしょうか？ 1週間かけて100台のサーバーをセットアップしたが、そのうち数台は設定ミスがあって動かない なんてことが起こっていたわけです。 2006年に Amazon が現代のクラウドの基礎と言える Elastic Compute Cloud をローンチしました。 すると、これまで発注してからサーバーが手元に届くまで数ヶ月待つ必要がありましたが、発注してから5分後にはサーバーが手元にある状態になりました。 これはサーバーインフラの世界に激変をもたらしました。 これまでハードウェアのリードタイムが数ヶ月あるのだから、サーバーのセットアップをしてミスがあれば修正する作業を1週間かけてやっていても、非効率をごまかせていました。 しかし、5分でサーバーを調達した後1週間かけてサーバーをセットアップしているのは何かおかしい と気付いた人たちがいます。 そこで、サーバーのセットアップ手順を自動化し、セットアップにかける時間を短縮するモチベーションが高まりました。 その成果物として、出てきたのが サーバーのセットアップ手順をコード化する IaC です。 IaC によって、サーバーのセットアップ時間は高速かつ正確なものになりました。 IaC のアプローチ IaC には2つのアプローチが存在します。 1つ目は命令型、2つ目は宣言型です。 命令型は「apt install httpd」というようなセットアップ手順のコマンドを羅列させ、それを実行することで自動化しようという考えに基づいています。 これは人間が行なっていたセットアップ手順を自動化しようとした場合、素直なアイデアです。 /ja/overview/workflow/setup_gs2_resources/cdk_setup/ Mon, 01 Jan 0001 00:00:00 +0000 /ja/overview/workflow/setup_gs2_resources/cdk_setup/ GS2-Deploy は環境構築のために素晴らしい成果をあげています。 しかし、テンプレートの記述方法にはまだ課題がありました。それは、テンプレートファイルを記述するのに入力支援が得られないことです。 GS2-Deploy を設計するのに AWS の Cloud Formation を参考にしたのはすでに説明した通りですが、 2019年に AWS が発表したのが AWS CDK(Cloud Development Kit)です。 これは、従来のJSONやYAMLでのテンプレートファイルを記述するのに入力支援を得られない という問題の解決策として、各種プログラミング言語でテンプレートを記述できるようにしよう という成果です。 2019年のサービス開始から、GS2 はずっと JSON/YAML によるテンプレートのデプロイ機能を提供してきましたが、2022年11月に GS2 も CDK のサポートを開始しました。 CDK は現在 Go / Java / PHP / Python / TypeScript をサポートしています。 それぞれのプログラミング言語で、GS2-Inventory の GS2-Deploy 用のテンプレートを生成するコードを記述した例が以下です。 Language: Go Java PHP Python TypeScript stack := core.NewStack() inventory.NewNamespace( &stack, "test", inventory.NamespaceOptions{ }, ).MasterData( []inventory.InventoryModel{ inventory.NewInventoryModel( "inventory", 5, 10, []inventory.ItemModel{ inventory.NewItemModel( "Potion", 99, true, 1, inventory.