こちらのチャプターでは、AWSからGCPに移行した背景と利用サービスについて説明します。

前チャプターでも説明しましたが、Envaderには大きく3つの機構が必要でした。

  1. Webアプリケーション機構
  2. Dokcerコンテナを起動・停止するAPI
  3. Dockerコンテナが起動・停止するサーバー群

はじめは、AWSにおいて、それぞれ

  1. Webアプリケーション機構 = EC2
  2. Dokcerコンテナを起動・停止するAPI = EC2
  3. Dockerコンテナが起動・停止するサーバー群 = EC2

という全てEC2で構成する機構を採用しておりました。(比較的短時間処理であるAPIをEC2で構成するのは、現代ではアンチパターンでしょう。サーバーレス化することにしました)

しかし、色々考えた結果GCPに移行することを決めました。

GCPに移行することを決断した理由は、先ほどあげた項目の3つ目 Dockerコンテナが起動・停止するサーバー群 の取り扱いがGCPの方が適していたと判断したからです。

Envaderでは、多くのユーザーが集まると、多くのDockerコンテナが起動します。
その際には、もちろん、コンテナサーバーは、スケーリングする必要が出てきます。
ここに問題が生じたのです。

EC2のオートスケーリング機能を利用すればいいではないかと思うかもしれませんが、そうではありませんでした。オートスケーリング機能を自作する必要がありました。ここについて、詳しく解説します。

EC2におけるオートスケーリング機能は、メモリやCPUの使用率を見てスケールアウト、スケールインします。カスタムメトリクスによる柔軟なスケーリングも可能です。スケールインしたとしても他のサーバーにアクセスすれば問題なく動作するというやつです。

よくある構成としては、RedisやDynamoDBを利用してSession情報のみ切り出すあれです。

しかし、Enavderにおいては、そうなってしまうと困るのです。
コンテナサーバーでは、Dockerコンテナが多数起動しています。とあるコンテナサーバーへのアクセスが減ったからと言って、そのサーバーをスケールインさせてしまうとその中にあるコンテナが消えてしまい、ユーザーはシナリオを解くことができなくなります。

つまり、アクセスが増え、1つのコンテナサーバーに起動するコンテナの数が増えたときには、新しくスケールアウトすることにより新たなサーバーを増設する。コンテナサーバーへのアクセスが減り、1つのコンテナサーバーに起動するコンテナの数が減った時には、できるだけ1つのサーバーにDockerコンテナが起動するようにする。完全にとあるサーバーに起動しているDockerコンテナが無くなった場合のみスケールインする。という自前のスケーリングを組む必要があったのです。

そこで、我々を悩ませたのは、コンテナが起動する早さです。ここに時間がかかってしまうとサービス全体のUXが悪くなってしまいます。

どうにかコンテナを早く起動できないか調査していたところ、GCPのContainer Optimized OS (COS)にたどり着きました。これがGCPに移行する決め手でした。

このような経緯により、EnvaderはGCPに移行する形となりました。

Envaderに必要な以下の機能は

  1. Webアプリケーション機構 = GAE, Redis, Cloud SQL
  2. Dokcerコンテナを起動・停止するAPI = Cloud Functions, Google Cloud Pub/Sub
  3. Dockerコンテナが起動・停止するサーバー群 = GCE (COS)

として、サービス全体を疎結合にする方針で再設計されました。

サービス全体のアーキテクチャー図はこちらです。
後に、このアーキテクチャー図はもう少し変更が入ります。