GS2-Deploy を使用したセットアップ

GS2-Deploy を使用してマイクロサービスにリソースを作成する

マネージメントコンソールを使用したセットアップは手軽に実行できるのは魅力です。

しかし「同じ環境をもう一つ作って欲しい」というオーダーを受けた時にあなたは絶望するに違いありません。ゲーム開発では一般的に「開発環境」「検証環境」「本番環境」のように複数のサーバー環境を必要とします。

それぞれで、マネージメントコンソール上で同じ操作を繰り返して 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」というようなセットアップ手順のコマンドを羅列させ、それを実行することで自動化しようという考えに基づいています。これは人間が行なっていたセットアップ手順を自動化しようとした場合、素直なアイデアです。

宣言型は「Webサーバーが必要である」ということを明記します。この時、Webサーバーを作るために必要な手順は考えません。さて、あなたはこの2つの手法はどちらが優れているとおもいますか？

この2つのアプローチに優劣をつけるには、実務に基づいた例を述べるのがわかりやすいでしょう。あなたは100台のサーバーがあるサービスを任されています。しかし、サービスは利用者が減ってきておりサーバーの台数を半減することを要求されました。 50台を残して、残りの50台は電源を切りました。

その半年後、サービスは好調になり、電源を切った50台のサーバーを再び使用して100台のサーバーを用意することを要求されます。さて、半年ぶりに電源を入れたサーバーを最新の状態にする必要がありますが、この時命令型と宣言型の違いが明確になります。

命令型は前回どこまで命令を実行したのかがわかりません。一方で、宣言型は現在の状態と、新しく宣言された状態の差分がわかれば差分を埋めるための更新をすればいいことになります。

このような過去の事例を参考にして GS2-Deploy は宣言型の IaC を実現しています。

テンプレート

GS2-Deploy はテンプレートファイルに GS2 の各マイクロサービスに求める状態を宣言して、適用することで環境構築を行えるようにしています。マネージメントコンソールを通して GS2-Inventory にリソースを作成した手順をそのままテンプレートにしてみましょう。

GS2TemplateFormatVersion: "2019-05-01"
Resources:
  InventoryNamespace:
    Type: GS2::Inventory::Namespace
    Properties:
      Name: test

  InventoryMasterData:
    Type: GS2::Inventory::CurrentItemModelMaster
    Properties:
      NamespaceName: test
      Settings: {
        "version": "2019-02-05",
        "inventoryModels": [
          {
            "name": "inventory",
            "initialCapacity": 5,
            "maxCapacity": 10,
            "itemModels": [
              {
                "name": "Potion",
                "stackingLimit": 99,
                "allowMultipleStacks": true,
                "sortValue": 1
              }
            ]
          }
        ]
      }

これで、test という名前のネームスペースを作成し、マスターデータを登録するテンプレートの完成です。このファイルを GS2-Deploy にアップロードすることで環境構築ができるので、環境を新しく作るのももう怖くありませんね。

更新

GS2-Deploy は更新処理でも賢く振る舞います。前回アップロードしたテンプレートと、新しくアップロードしたテンプレートの差分を検知しします。

増えているものがあれば作成
減っているものがあれば削除
変わっているものがあれば更新

この挙動により、1つのテンプレートファイルを多数の開発者で編集しても問題になりません。