Feelin Games ロゴ

Google Cloud Runでのサーバー構築

アプリ、ゲームのソフトウェア開発に注力したいアプリエンジニア、ゲームクリエイターにとって、アプリコードをアップロードさえすれば、サーバーインフラは、全ていい感じにお任せという形が理想的だ。

それを叶えるために、私は、Google Cloud Platform(GCP)のCloud Runを使っている。

サーバー側の初回セットアップ、システム変更、メンテナンス、日々のお守り作業を最小化したい。サクサク本番移行できること。数分ではなく、数十秒が理想的。アプリコードを実装、修正し、デプロイコマンド実行、本番サーバー更新、これを一日に何度も繰り返すことがある。ブルー・グリーン・デプロイメントができること。更新版に徐々に切り替えたり、何かあったら直ぐ戻せること。利用する量に応じて、サーバー能力が自動で調整されること。ログ、異常のモニタリングできること。

Cloud Runは、上記の大部分を満たしてくれる。キーワードを列挙すると、「フルマネージド」サービス側が大部分やってくれていて、基本お任せ。「サーバーレス」クラウドサーバーであることは勿論、各種サーバーセットアップ作業も極限までに削ぎ落とされ、アプリコードをアップロードするだけ。そう、サーバーはレスで良い。「スケーラブル」自動的にサーバー能力を拡張していってくれる。トラフィックに応じてゼロからNまで自動的にスケーリング。「コンテナ」Go言語など使いたい言語で動く実行環境=コンテナイメージが用意されていれば良い。Dockerなどコンテナ自体も最適化されていれば特にケアしたくない。「従量課金」資源を使った分だけ課金される。

システム構成の例

Cloud Runのシステム構成の例 - Google Cloud Platform

VS Codeで、WebサーバーのGoコードを書いて、デプロイコマンドをターミナルで打つだけ。1分ぐらいで、サーバーが更新される。

例) gcloud run deploy servicename --source . 

コード実装、デプロイ、これを、高速に繰り返すわけだ。

なお、「ソースコードでデプロイする」という方法を使っているのでコンテナイメージのビルド作業も、私はローカルPCでは行っていない。サーバー側でお任せで処理されている。

デメリットを挙げてみると、サーバー構成を変えたくなった時に変えられるか?または、乗り換えが発生するかもしれないこと。利用規模が大きくなったとき、Compute Engineなどの専有サーバーの方が、料金が安くなる場合がある。初めてCloud Runを使い始める人は、学習コストと思い通りに操作できるまでの時間はある程度要することだろう。

アプリコードをアップロードさえすればよい、というのは、先に登場していたGoogle App Engine(GAE)のStandard環境だろう。GAEの方が、先行している分、使える機能が多く、充実している。Cloud RunとGAEは、サービス機能はとても似ているので、かなり細かく見て違いを理解する必要があるだろう。AWSで言うと、Lambdaがそれに当たる。Google Cloud Runの利用規模(小から大まで) vs 料金コストが、他の何れの類似サービスと比較しても安くなれば、最高なサーバーレスインフラとなるだろう。

Tweet