2022.04.01

【トップゲート主催】ゲーム業界様向けGCP活用のポイント〜Cloud Run編〜

Cloud
Cloud Run
Cloud Runサービス連携
GGG Study

弊社トップゲートではGoogle Cloudのプレミアパートナーとして、Google Cloudに関する様々なセミナーを開催しています。この記事では、ゲーム業界様向けにGCPの使い方を解説した「GGG Study」の内容についてご紹介します。

GGG Studyは全6回に分けてGCPの各スキルを習得していただくための勉強会です。第5回では、Cloud Runについて解説していきます。

前提知識

まずはCloud Runを理解するためにあらかじめ知っておく必要のある用語について解説します。

コンテナ

コンテナとは、単一のアプリケーションと付随するランタイム環境をパッケージ化したものです。アプリケーションの実行環境を1つのパッケージにすることによりライブラリなどの依存関係を排除することができます。また、仮想マシンとは異なりOSイメージは含まれないため、非常に軽量で動作も高速です。

コンテナイメージ

コンテナイメージ
コンテナイメージは、コンテナの元となるベースイメージです。コンテナイメージからコンテナを起動します。

Container Registry(Artifact Registry)

コンテナイメージを保存・管理するためのGCPのサービスです。また、Artifact Registryは次世代のContainer Registryで、2020年7月現在はベータ版で提供されています。

Google Kubernetes Engine

GKE
Google Kubernetes Engine（GKE）は、GCP上で提供されているKubernetesのマネージドサービスです。マスターノードはGKEが管理を行うため、ユーザー側は管理の必要がありません。また、GKEではコンソールによるGUI経由やCLIで簡単にクラスタを構築することが可能です。

Cloud Runの概要

ここからはCloud Runの概要についてご紹介します。

Cloud Runとは

Cloud Runとは、コンテナ化されたアプリケーションを素早くデプロイできるフルマネージド型のコンピューティングプラットフォームです。コンテナをHTTPSで公開することで、セキュアな環境を構築することが可能です。運用はGoogleのエンジニアチームが行うため、アプリケーションの開発に集中することができます。

また、下記のような機能を持っています。

Container Registryに格納されたコンテナイメージを利用することができる
トラフィックに応じて0〜1000コンテナインスタンスの範囲で自動的にスケールイン/アウトを行う
(事前に申請することで1000以上にスケールすることも可能)
最新版をデプロイすると、無停止で自動的にローリングリリースが実施される
コンテナインスタンスあたりの同時接続数の設定により、効率的な処理が行われる

Cloud Runのリソース

上図は、Cloud Runの各リソースモデルを表しています。プロジェクトの中にサービス、リビジョン、コンテナインスタンスと呼ばれるリソースが存在します。

サービスとはCloud Runにおけるメインリソースです。冗長性を担保するためにリージョン内の複数のゾーンに自動的に複製されます。各サービスは固有のエンドポイントを公開しており、リクエストを処理する役割を持っています。

また、サービスを新しくデプロイするとリビジョンが作成されます。リビジョンは環境設定とコンテナイメージから構成されています。リクエストは最新のリビジョンに自動的にルーティングされます。

各リビジョンは受信したリクエストを処理できるようにコンテナインスタンスを自動的にスケールします。

オートスケールの仕組み

Cloud Runでどのようにリクエストを処理しているのか、簡単に流れをご紹介します。
オートスケール1
コンテナインスタンス数に対して受信したリクエストが多くなると、トラフィック負荷を処理できるインスタンスが不足することがあります。その場合、リクエストはリビジョン内にある仮想的なキューにプールされます。

オートスケール2
キューから順次コンテナインスタンスに対してリクエストを転送します。この時、全てのリクエストを処理できるように、コンテナインスタンスの数を自動的に調整します。

ローリングリリース

ローリングリリース1
また、同じサービスに新しいコンテナイメージをデプロイした場合、リビジョンが作成されます。

ローリングリリース2
新しいリビジョンでリクエストの処理ができる準備が完了すると、古いリビジョンから新しいリビジョンの方に少しずつトラフィックが流れ始めます。

ローリングリリース3
また、別のリビジョンではそれぞれ別のコンテナが独立に起動しています。この動きにより、無停止でのローリングリリースを実現しています。

ローリングリリース4
また、全てのリクエストの処理が新しいリビジョンで行われるようになると古いリビジョンはそのコンテナインスタンスを0にスケールします。この段階で新しいバージョンのデプロイが完了したことになります。

Cloud Run利用上の注意点

ワークロードによっては、Cloud Run上で稼働させるのに適していない場合もあります。下記のような要件がある場合には設計に十分な考慮が必要です。

まず、Cloud RunではHTTPS以外での公開はできません。そのため、メールサーバーのホスティング用途などには向かないことになります。また、1つのリクエストに対しての処理時間は15分以内に収める必要があります。

コンテナイメージについては、Docker Hubなどの外部サービスに格納されたコンテナイメージは利用できないため、GCPのContainer RegistryかArtifact Registryに登録されたイメージから選択する必要があります。

パフォーマンス

ここからはCloud Runのパフォーマンスに関する仕様についてご紹介します。

パフォーマンスに関する仕様

まず前提として、Cloud Runで稼働するサービスに対しては、明確なリクエストレートの上限は設定されていません。そのため、コンテナ上で動かすアプリケーションの速度に依存します。

リビジョンに60秒
Cloud Runへのリクエストは先述の通り1度リビジョン内のキューに保存されます。キュー内では60秒間を上限としてプールされるため、その間にコンテナへリクエストを渡せない場合には429 Too Many Requestsエラーにより処理が失敗します。

コンテナのスケールに関して、スケールアウトは前述の通り1000コンテナインスタンスが上限となりますが、スケールアップさせることも可能で、コンテナへのvCPUやメモリの割り当てを増加することができます。1インスタンスに最大で2 vCPU、2 GBまで割り当てることが可能です。

また、コンテナインスタンスあたりの同時接続数を増加させることでコンテナあたりで処理するリクエスト数が増加し、より効率的にリクエストを処理できるようになります。コンテナインスタンスあたりの同時接続数は80が上限です。

運用管理

ここからは実運用を想定し、運用時の留意点と、運用のフローについて解説します。

運用時の留意点

サーバーレス環境のため、基本的には定常的なメンテナンスは行う必要がありません。逆に、sshでログインしてメンテナンスすることなどはできません。ライブラリやミドルウェアをバージョンアップを実施したい場合は新たにコンテナイメージを作成し、デプロイする必要があります。

また、一般的なコンテナ環境にも言えることですが、運用環境と開発環境は同じコンテナイメージを利用した方が良いと考えられます。環境ごとに変化するような設定は外出しする事を考慮する必要があります。

運用のフロー

運用フロー全体像
開発者と運用者の関係性を考慮しながら、実際の運用のフローについてご紹介します。

Gitリポジトリへの操作
開発者は、ソースコードの改修など、Gitのリポジトリに対する操作を行います。ここではGCPのCloud Source RepositoriesというフルマネージドのプライベートGitリポジトリサービスを利用する例を示しています。コンテナの開発では、CI/CD（Continuous Integration／Continuous Delivery）との親和性を考慮したフローを考慮することが重要となります。例えばPull Requestごとにコンテナイメージを作成するようにしたり、もしくはMasterブランチにマージされたら自動的にイメージを作成してステージング環境にCDするなどといった考え方を適用することが必要です。

CI/CDパイプライン
Gitリポジトリの操作によって、それをトリガーとしてCloud Buildにより自動的にテストが実施されます。テストを通過すると、コンテナイメージが作成され、Container Registryに格納されます。

運用者の操作
運用者は、Container Registryに格納されたコンテナイメージを指定し、Cloud Runの新規リビジョンを作成します。

ログの保存
また、アプリケーションのログはCloud Logging(旧Stackdriver)に格納されます。ログの詳細な分析はBigQueryに転送して実施します。

セキュリティ

Cloud Runを利用するにあたり考慮すべきセキュリティについて解説します。

Cloud Runのセキュリティ機能

Cloud Runで公開されるURLのエンドポイントは、IAMによりアクセス制御を行うことが可能です。これはバッチサーバーなど、ユーザーから非公開の処理を実行するコンテナを、セキュアに作成する場合の利用が想定されます。

Container Registryのセキュリティ機能

Container Registryでは、コンテナイメージに対する脆弱性スキャンが可能です。これにより、格納されているイメージ自体のセキュリティを向上することができます。また、Container Registryサービスは外部に非公開のサービスであり、IAMによる権限設定を行うことが可能です。

他サービスとの連携

Cloud Runは、さまざまなサービスと連携することが可能です。ここではよく連携して利用されるサービスをいくつかご紹介し、その活用方法を簡単に解説します。

Cloud SQL

Cloud SQLはフルマネージドのリレーショナルデータベースです。Cloud Runからでもデータベースとして簡単に接続することができます。

Cloud Firestore

Cloud Firestoreはフルマネージドのドキュメントデータベースです。JSONなどのデータをそのまま格納するのに便利です。

Cloud Storage

Cloud Storageは可用性の高いオブジェクトストレージです。画像ファイルの配信や、アプリケーションの設定ファイルの格納など、活用方法は多岐に渡ります。

Firebase Hosting

Firebase Hostingはきめ細やかな配信設定が可能なコンテンツ配信サービスです。Cloud Runの前段に配置することにより、CDNエッジにキャッシュされ、コンテンツ配信の負荷を軽減することができます。

Secret Manager

Secret Managerは機密情報をセキュアに扱うことのできるストレージシステムです。例えば設定ファイルの中でもAPIキーやDBのパスワードなど、機密性の高い情報はSercret Managerに格納しておくと良いでしょう。

連携できないサービス

2020年7月現在、Cloud Runから次のGCPサービスへの連携はできませんのでご注意ください。

Filestore
Cloud Load Blancing
Google Cloud Armor
Cloud CDN
Identity-Aware Proxy
VPC Service Controls
Cloud Asset Inventory

Cloud Runの料金体系

最後に、Cloud Runにおける料金体系についてご紹介します。

基本料金

Cloud Runでは、リソースの使用量に応じて下記の通り課金が発生します。

リソース	無料枠	料金
CPU	最初の 180,000 vCPU 秒は無料	無料割り当てを超えた場合 vCPU 秒あたり $0.00002400
メモリ	最初の 360,000 GB 秒は無料	無料割り当てを超えた場合 GB 秒あたり $0.00000250
リクエスト	200 万リクエストまで無料	無料割り当てを超えた場合 100万リクエストあたり $0.40
ネットワーキング	北米内の下りは1 GBまで無料	無料割り当てを超えた場合 Google Cloud ネットワークのプレミアムティアの料金が適用

リクエスト処理時間について

コンテナインスタンスのCPUとメモリにおいて、実際にリクエストを処理するために割り当てられたアクティブなリソースのみが課金対象となります。

リクエストの処理時間
また、コンテナインスタンスが同時に多くのリクエストを受信した場合、請求の対象となる時間は最初のリクエストの処理が始まってから最後のリクエストの処理が完了するまでの間になります。

同時接続数の影響

同時接続数の影響
同時接続数を多く設定しておくことにより、Cloud Runに対して同じ程度の負荷がかかった場合でも、コンテナインスタンスがスケールアウトせずに効率的に処理できる場合があります。

リクエスト数が増加した場合でも課金の対象となるコンテナインスタンス数が少ない状態で処理できるため、よりコストを最適化することが可能です。

Cloud Runの想定料金モデル

いくつかのユースケースに基づいて価格を算出してみます。

モデル1

想定ケース1: 新しいサービスを小規模で開始

月間100万リクエスト
1リクエストあたり300msの処理時間
1リクエストあたり1KBのレスポンス
コンテナあたり2 vCPU/2 GB Mem
コンテナあたりの同時接続数 80
東京リージョンで稼働

この時の利用料金は、月あたり$0.00です。これだけ利用しても無料枠の範囲内で収まります。

モデル2

想定ケース2: サービスがユーザーに人気となり、リクエスト数が増加

月間1000万リクエスト
1リクエストあたり300msの処理時間
1リクエストあたり1KBのレスポンス
コンテナあたり2 vCPU/2 GB Mem
コンテナあたりの同時接続数 80
東京リージョンで稼働

この時の利用料金は、月あたり$4.10です。ある程度の規模のリクエストを捌けるようになりましたが、1ヶ月500円程度で利用することができます。

モデル3

想定ケース3: ユーザーが劇的に増加

月間1億リクエスト
1リクエストあたり300msの処理時間
1リクエストあたり1KBのレスポンス
コンテナあたり2 vCPU/2 GB Mem
コンテナあたりの同時接続数 80
東京リージョンで稼働

この時の利用料金は、月あたり$63.76です。IaaSなどを運用する場合と比較して、非常に安価で利用できることがCloud Runのメリットです。

リファレンスアーキテクチャ

実際にCloud Runを利用してアプリケーションを構築する場合の構成をご紹介します。

アーキテクチャ
ユーザーの持っているデバイスにゲームのアプリがインストールされています。Firebase Hostingを設置することで、ユーザーからのリクエストの中から静的コンテンツに対してはCloud Storageのデータを透過的に参照するように設計しています。Cloud Runに対しては通常のREST APIがFirebase Hosting経由で転送されます。

Cloud RunのバックエンドのデータベースとしてはCloud Firestoreを利用します。また、バッチサーバーもCloud Runでデプロイしており、定期的に処理を自動実行するためにCloud Schedulerを活用しています。バッチサーバーではFirestoreやCloud Storage上のデータの削除や画像の破棄などのメンテナンスをすることも想定しています。

アプリケーションのログはCloud Logging(旧Stackdriver)に自動的に払い出すようにして、分析を行う場合にはBigQueryを活用します。

まとめ

この記事では、Cloud Runを活用してコンテナアプリケーションを構築し、運用する方法についてご紹介しました。Cloud Runでは、マネージドサービスとして運用の負荷を最低限に抑えた形でアプリケーションをリリースする様々な仕組みが提供されています。価格も非常に安く、簡単に始められるのでクラウド上でコンテナアプリケーションを作成する際には是非利用を検討してみてください。

弊社トップゲートでは、Google Cloud (GCP）利用料3%OFFや支払代行手数料無料、請求書払い可能などGoogle Cloud (GCP）をお得に便利に利用できます。さらに専門的な知見を活かし、

など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。

Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！

Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。

お問合せはこちら

メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！
Google Cloud（GCP）、Google Workspace（旧G Suite）、TOPGATEの最新情報が満載！

メルマガ登録はこちら