• オートスケール構成
  Google Cloud 上で提供される VM であり、他のパブリッククラウドの IaaS と同様に Linux / Windows をサポートします。今回のパターンでは、インスタンス テンプレートからインスタンス グループを作成の上、要件に応じたスケーリング設定、ヘルスチェック設定等を行います。

• インスタンス テンプレート
  後述のインスタンス グループで起動するインスタンスの定義情報です。用途に応じたマシンタイプ、ストレージ タイプを指定し、合わせてインスタンス起動時に行う各種ソフトウェアのインストール / 起動設定を定義します。
  ※インスタンス起動時の設定方法には、起動スクリプトを利用する方法以外にも、カスタム イメージを利用する起動設定方法もあります。それぞれの特徴については、こちらをご参照ください。

• インスタンスグ ループ
  マネージド インスタンス グループ （ MIG ）を利用してインスタンスのオートスケーリング、リージョン（マルチゾーン）デプロイメント、自動更新などを可能とします。要件に応じたスケーリング ポリシーを設定し、需要予測、負荷試験を通して、オートスケールのインスタンス最小数 / 最大数やクールダウン期間などを設計します。

• ヘルスチェック
  インスタンス グループ内インスタンスの自動修復を行うためのヘルスチェックと、後述のロードバランサで利用する負荷分散のためのヘルスチェックを定義します。それぞれ目的が異なるため、ヘルスチェックは別に定義します。

• Cloud Load Balancing
  暖機運転なしで毎秒ゼロから大規模リクエストまでスケールするロードバランサです。Cloud Load Balancing の配下に、先述の Compute Engine インスタンスグループを配置して、リクエストを分散させて利用します。今回のパターンでは、セッション アフィニティ機能を利用して負荷分散制御を行い、また、コネクション ドレインを設定することで安定性を高めます。

• セッション アフィニティ
  ステートフル アプリケーションの負荷分散を行う場合、そのままの状態ではMIG を用いて冗長化したサーバ間でセッション情報を共有できず、この状態でロードバランシングを行うと、例えば最初にアクセスした VM と別 VM に Cloud Load Balancing によってディスパッチされた場合、セッション情報が失われてしまいます。この課題の対応方法としてセッション アフィニティ機能を利用します。

• コネクション ドレイン
  コネクション ドレインを有効化して、 VM がインスタンス グループから除外されたときに、既存で進行中のリクエストを完了するための時間を確保します。

• Cloud SQL
  Google Cloud 上で提供されるマネージド リレーショナル データベース であり、MySQL 、PostgreSQL 、Microsoft SQL Server をサポートしています。 今回のパターンでは、HA 構成や、自動バックアップ、ポイントインタイム リカバリ機能を利用することで可用性を強化します。また、ストレージの自動増量機能を有効化し拡張性を高めます。その他、必要に応じてリードレプリカを利用することで、読み取りパフォーマンスの向上を図ることもできます

• HA 構成
  インスタンスを別のゾーンに複製し HA 構成を実現することができます。HA 構成を組むことでプライマリ インスタンスが応答しなくなった場合、自動的にスタンバイ インスタンスからデータを提供するようフェイルオーバーされます。

• バックアップ
  Cloud SQL は、オンデマンド バックアップ、自動バックアップの 2 種類のバックアップが可能です。各バックアップ種別によりバックアップ保存期間が異なるため、要件に応じて適切なバックアップ機能を選択します。

• ポイント インタイム リカバリ
  要件に応じて、ポイント インタイム リカバリ （ PITR ） 機能を利用します。 なお、PITR ではバイナリログが使用されますが、これらのログは定期的に更新され、Cloud SQL の保存容量を使用するため注意が必要です。（バイナリログのサイズが原因で問題が生じた場合、インスタンスのストレージ サイズを大きくすることはできますが、ディスク使用量のバイナリログサイズが大きくなるのはあくまで一時的です。予期しないストレージの問題を回避するには、PITR の使用時にストレージの自動増量を有効にすることを推奨します）

• ストレージの自動増量
  Cloud SQL では、ストレージ容量が上限に近づいたときに自動的に容量をスケールアップすることが可能です。

• リードレプリカ
  リードレプリカは、Cloud SQL プライマリ インスタンスから複製された Cloud SQL インスタンスです。リードレプリカは読み取り専用であり、レプリカを使用して、プライマリ インスタンスから読み取りリクエストやアナリティクス トラフィックをオフロードすることが可能となります。（上記アーキテクチャ図にはリードレプリカ構成を表現していませんが、読み取りパフォーマンスの向上を図りたい場合などは、導入を検討してください）

利点

本アーキテクチャを採用することで、既存システム構成を極力変更せず、同一リージョン内で、可用性を高め、かつスケーラビリティの高いアーキテクチャを実現できます。可用性については、複数ゾーンに跨がるインスタンス グループへの負荷分散を Cloud Load Balancing で行うこと、また Cloud SQL の提供する HA 構成で実現し、性能 / 拡張性については、インスタンス グループのオートスケール機能および、 Cloud SQL のもつリードレプリカ機能、ストレージの自動増量機能で対処します。

注意事項

MIG を利用したオートスケール構成を実現する場合、最小 / 最大インスタンス数は需要予測や性能試験を基に決めるようにしましょう。MIG を利用することで柔軟性の高いアーキテクチャを実現できますが、スケーラビリティ性能に限界もあるため、十分な検証が必要です。また、「 マルチゾーン ウォーム スタンバイ 」パターンでも述べていますが、Cloud SQL を使うときには、メンテナンス ウィンドウを設定し、メンテナンスの時間を事前に設定します。また、バックアップなども業務要件に応じて設定すると良いです。

Sample config や Code

• Compute Engine

  • インスタンス テンプレート

    • マシンの構成：汎用 / シリーズ N2 （要件に合わせて、 CPU コア数 / メモリサイズレベルで指定することも可能）

    • ディスク： SSD 永続ディスク

    • 起動スクリプト：インスタンス起動時に必要な設定を指定

  • インスタンスグループ

    • ロケーション：複数のゾーン （ゾーンの停止などの極端なケースでもアプリケーションの可用性を確保するため、 Compute Engine のアプリケーションを複数のゾーンに分散することをおすすめします）

    • クールダウン期間：インスタンス起動後-安定するまでの時間よりも長い時間

    • 自動スケーリングの指標 / 指標タイプ： HTTP 負荷分散の使用率

    • インスタンスの最小数 / インスタンスの最大数：需要予測や性能試験を基に設計した値

  • ヘルスチェック

    • 異常しきい値： 3 以上 （3 以上に設定するのが理想的です。これにより、発生頻度の低いネットワークパケットの損失などの障害による影響を回避できます）

    • 正常しきい値： 2 （多くの場合、値 2 で十分です）

    • チェック間隔： 1 秒からタイムアウトの 2 倍までの値 （値が長すぎると、失敗したインスタンスがすぐに捕捉されません。値が短すぎると、毎秒かなりの数のヘルスチェック プローブが送信されるため、インスタンスとネットワークがビジー状態になる可能性があります）

• Cloud Load Balancing

  • フロントエンドの構成

    • プロトコル： HTTPS （ HTTP / 2 を含む）

    • 証明書：Google 管理の証明書

  • バックエンドの構成

    • ヘルスチェック：インスタンス グループで指定した「自動修復」のヘルスチェックとは別のヘルスチェックを指定

    • セッションアフィニティ：作成した Cookie

    • コネクションのドレインタイムアウト：300

  • Cloud SQL （ MySQL ）

    • ストレージの種類 : SSD

    • ストレージの自動増量を有効化：オン

    • バックアップを自動化する : 有効

    • ポイントインタイムリカバリを有効にする : オン

    • 可用性 ：高可用性 （リージョン）

    • 優先ウィンドウ : インスタンスの定期メンテナンスを行うのに最適な曜日を設定

    • 更新の順序 : 格納されるデータに応じた優先度を設定

このパターンで作成された事例

• 株式会社リベル・エンタテインメントの導入事例：500 万ユーザーが遊ぶ大人気ゲームアプリを Google Cloud Platform で安定運用

• ポノス株式会社の導入事例： e スポーツ対応の対戦型ゲームを Compute Engine ベースで構築、レイテンシーの比較で最大 2 倍の差が採用の決め手

• 株式会社ディー・エヌ・エー：世界的大型タイトルを Compute Engine で運用。従来環境からのスムーズな移行と安定性を両立

関係するデザインパターン

• キャッシュを活用したウェブホスティング

• マルチゾーン ウォーム スタンバイ

参照ドキュメント

• 高可用性アプリでの自動修復の使用 | Compute Engine ドキュメント

• 可用性の高いアプリケーションでの負荷分散の使用 | Compute Engine ドキュメント

• スケーラビリティの高いアプリケーションでの自動スケーリングの使用 | Compute Engine ドキュメント

• Compute Engine でのウェブサービスのグローバルな自動スケーリング | Compute Engine ドキュメント

• スケーラブルで復元性の高いアプリのためのパターン | ソリューション

利点

1. CDN によってウェブ アプリケーションサーバの負荷を軽減することができます。 

2. インメモリ キャッシュの適切な活用によりデータベースが処理するクエリの量を減らすことができるため、データベースの負荷軽減を図ることができるほか、データベースのクエリ応答より一般的に高速な応答が見込まれるインメモリ キャッシュから応答することにより、アプリケーション全体のスループットの向上が見込めます。

Sample config や Code（提供可能な場合）

• Cloud CDN を導入する場合 (上図 (1))

  • 紐付けるHTTP(S) 負荷分散を指定します。該当する HTTP(S) 負荷分散が未作成の場合、ここで新しく作成することも出来ます。

  • HTTP(S) 負荷分散と Cloud CDN を紐付ける方法は複数あり、Cloud CDN のメニューから HTTP(S) 負荷分散を選択して紐付ける方法、HTTP(S) 負荷分散のバックエンド サービスやバックエンド バケットを作成する際に Cloud CDN を有効化することも可能です。

  • TCP 負荷分散 や UDP 負荷分散 では Cloud CDN を有効化することが出来ません。

• Memorystore for Redis を導入する場合 (上図 (2))

  • Memorystore のネットワーク スループットはメモリ容量に応じて増減するため、必要な容量だけではなくボトルネックの影響を受けずに応答することが出来るネットワーク スループットを確保するよう、適切に容量を設定する必要があります。

  • Memorystore インスタンスを配置するプロジェクトとリージョンは必ずアクセス元である Compute Engine のインスタンスと合わせる必要があります。また、この Compute Engine インスタンスが所属する VPC からの接続を許可する必要があります。