こちらのチャプターでは、AWSからGCPに移行した背景と利用サービスについて説明します。
前チャプターでも説明しましたが、Envaderには大きく3つの機構が必要でした。
- Webアプリケーション機構
- Dokcerコンテナを起動・停止するAPI
- Dockerコンテナが起動・停止するサーバー群
はじめは、AWSにおいて、それぞれ
- Webアプリケーション機構 = EC2
- Dokcerコンテナを起動・停止するAPI = EC2
- 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に必要な以下の機能は
- Webアプリケーション機構 = GAE, Redis, Cloud SQL
- Dokcerコンテナを起動・停止するAPI = Cloud Functions, Google Cloud Pub/Sub
- Dockerコンテナが起動・停止するサーバー群 = GCE (COS)
として、サービス全体を疎結合にする方針で再設計されました。
サービス全体のアーキテクチャー図はこちらです。
後に、このアーキテクチャー図はもう少し変更が入ります。
