Google App Engine(以下GAE)(※1)は、GCPユーザならば言わずと知れたGoogleのPasSサービスですが、設定によってスケーリング方法が異なることはご存知でしょうか。今回は3種類(※2)あるスケーリング方法から「automatic scaling」と「basic scaling」2種類をピックアップして比較をおこなっていきます。本記事で紹介する内容は以下の通リです。

• 選択できるインスタンス種別
• 各スケーリング方式で設定可能な項目
• リクエストのデッドラインの違い

GAEで本格的なシステムを構築する場合これらの違いを知ることは非常に重要です。開発者は各方式のどちらかを理解しているだけでは駄目で、それぞれのメリット・デメリットを知ることで、要件に応じたベストな設計をおこなうことができるようになります。
それではGAEのスケーリング方式を学んでいきましょう。

※1 GAEは現在Standard Environment(従来のGAE)とFlexible Environment(旧MVMs)の2種類に大別されますが、本記事で取り扱うGAEは「Standard Environment」です。Flexibleの場合も、スケーリング方式は選択することができますが、「automatic scaling」と「manual scaling」の2種類しか選択することができません。また、Flexibleのautomatic scalingで設定できる項目はStandardとは若干異なります。詳細については以下のURLをご確認ください。
https://cloud.google.com/appengine/docs/flexible/nodejs/configuring-your-app-with-app-yaml
※2 3種類目のスケーリング方法として「manual scaling」があり、これは指定した数のインスタンスを常時起動するための設定方式です。本記事ではこのスケーリング方法については解説しません。

各スケーリング方式の概要

Automatic Scalingは大量のリクエストを処理したい場合に利用

automatic scalingは、リクエストのトラフィック量に応じてスケールアウトするスケーリング方式です。昔からGAEを利用している開発者にとって、一番馴染みやすいスケーリング方式と言えます。この設定は、急なスパイクが発生する可能性のあるWebサービスに最適な設定と言えます。

Basic Scalingはバッチ処理をおこないたい場合に利用

basic scalingは、インスタンスの最大数を指定するスケーリング方式です。この方式では指定数以上にスケールアウトすることはありません。一定のスケールアウトが必要となるバッチ処理が最適な利用ケースとして挙げられます。

GAEで選択できるインスタンス種別

automatic scalingとbasic scalingでは利用できるインスタンスのクラスと数が異なります(※3)。開発者がGAEを利用した開発をおこなう過程で要件によってはインスタンスのクラスを変更する必要もあると思いますが、インスタンスはクラスの数値が上がる程(F1, F2, …)、料金が高くなるので注意が必要です。

Automatic Scalingで選択できるインスタンス

automatic scalingで設定可能なインスタンスクラスは以下の通リです。F1, F2, …と数値が上がる毎にサーバのスペックと料金(時間単位)が高くなります。インスタンスクラスのスケールアップはGAEのデプロイによって反映されます。また、28 instances-hourが一日のFree Quota(無料枠)として提供されているため、スタートアップのサービスはある程度アクセスが増えてくるまで(28 instance-hourを超過しなければ)無料で運用することも可能です。

表1. automatic scalingで設定可能なインスタンスクラス

※3 automatic scalingのインスタンスクラスにB1(~B8)を設定した場合、デプロイ時に以下のエラーメッセージが表示されデプロイが失敗します。

Basic Scalingで選択できるインスタンス

basic scalingで利用可能なクラスは以下の通リです。automatic scalingと比べ選択できるインスタンスの種類が１つ多いことがわかります。automatic scalingと同様に、B1,B2,…と数値が上がる度にサーバのスペックと料金(時間単位)が高くなります。また、basic scalingの場合は8 instances-hourが一日のFree Quota(無料枠)として提供されています。

表3. automatic scalingで利用可能なインスタンスクラス一覧

各スケーリング方式で設定可能な項目

automatic scalingとbasic scalingの設定項目について説明します。後述する通リ各方式で設定項目が異なります。ただし、automatic scalingは全5項目、basic scalingは全2項目しかないので、全て丸暗記しても良い項目だと思います。もし、ソーシャルゲームのような瞬間的な大量トラフィックが予想されるシステムをGAEで開発する場合、特にautomatic scalingの項目について理解が必要です。それは、各項目のチューニングによって、スケーリングのパフォーマンスや運用コストが変わってくるからです。それでは各項目について説明します。

Automatic Scalingの設定項目

automatic scalingで設定可能な項目は以下の通リです。全5つの項目があり、必要な場合は以下の設定をおこないます。

表2. automatic scalingの設定項目一覧

設定項目はappengineの設定ファイルに記述します。設定ファイルのサンプルは以下の通リです。表2で記した通リ、max_concurrent_requestsには”automatic”を指定できませんので、パラメータを記述する場合は必ず数値を指定してください。

application: simple-sample
version: uno
runtime: go
api_version: go1
instance_class: F2
automatic_scaling:
  min_idle_instances: 5
  max_idle_instances: automatic # default value
  min_pending_latency: 30ms 
  max_pending_latency: automatic
  max_concurrent_requests: 50

例1. automatic scalingのapp.yaml設定

Basic Scalingの設定項目

basic scalingで設定可能な項目は以下の通リです。設定項目はたったの2つです。

表4. basic scalingの設定項目一覧
設定項目はautomatic scalingと同様にappengineの設定ファイル(app.yaml)に記述します。設定ファイルのサンプルは以下の通リです。利用できるInstanceクラスはautomatic scalingとは異なり、B1-B8からの選択になりますので注意してください。F1~F4_1Gを設定してデプロイ処理を実行した場合はエラーメッセージが表示されます。

application: simple-sample
version: uno
runtime: go
api_version: go1
instance_class: B8
basic_scaling:
  max_instances: 11
  idle_timeout: 10m

例2. basic scalingのapp.yaml設定

各スケーリング方式のデッドライン

リクエストのデッドラインはautomatic scalingとbasic scalingを比較する上で一番重要な項目であると言えます。それは、この2つの方式ではデッドラインが全くことなるからです。

Automatic Scalingのリクエストデッドラインは60秒！

automatic scalingのデッドラインは60秒です(※4)。以下は120秒を待機して「Hello, world!」を出力するプログラムですが、automatic scalingのフロントエンドのリクエストのデッドラインは前述した通リ60秒となっているため、以下のプログラムを実行する場合DeadLineExceedExceptionが発生します。ただし、TaskQueue APIを利用する場合は1タスク10分がデッドラインとなります。

※4 フロントエンドのデッドラインは60秒というのがGoogle公式の数値ですが、検証した結果100秒までの待機処理でも正常にレスポンスを返せることがわかりました。これについては別途Googleに確認中です。

package src

import (
  "net/http"
  "fmt"
  "time"
)

func init() {
  // Handler
  http.HandleFunc("/receive", receive)
}

func receive(w http.ResponseWriter, r *http.Request) {
  time.Sleep(120 * time.Second) // 120秒待機
  fmt.Fprint(w, "Hello, world!")
}

サンプルアプリをデプロイ後、Webブラウザでアプリにアクセスすると500エラーが発生します。GCP管理コンソールのログ画面を見ると、指定バージョンのログに以下画像のようなエラーメッセージが表示されます。「request deadline was exceeded」というメッセージがDeadLineエラーのメッセージを表しています。

Basic Scalingのリクエストデッドラインは24時間！

basic scalingのデッドラインは24時間です。以下は1時間待機して「Hello, world!」をログ出力するプログラムです。以下を実行して、1時間のリクエスト処理でも正常に処理が終了することを確認してみます(※5)。
※5 本記事では24時間のリクエスト検証はおこないません。興味がある方は実際に以下プログラムの待機時間を24時間に設定して、検証をおこなってみてください。

package src

import (
  "net/http"
  "appengine"
  "time"
)

func init() {
  http.HandleFunc("/receive", receive)
}

func receive(w http.ResponseWriter, r *http.Request) {
  c := appengine.NewContext(r)
  time.Sleep(3600 * time.Second) // 1時間待機
  c.Infof("Hello, world!") // ログ出力
}

サンプルアプリをデプロイ後、Webブラウザ、curl等でGETリクエストを送信してください。1時間後にGCP管理コンソールのログ画面で以下のようなログが確認できます。

上記画像の通リ、1時間の待機処理後「Hello, world!」とログが出力されていることがわかります。前述した通リ、automatic scalingではTaskQueueを利用しても10分以内のバッチ処理しか対応することができませんが、basic scalingの場合は数時間(最大24時間)というデータ処理も対応することができます。

GAEのオートスケールまとめ

これまでの内容をまとめると以下表のようになります。表の通リ、2つのスケーリング方式は要件によって使い分けが必要であることがわかると思います。

表5. Automatic/Basic Scalingの比較

例えば、大量の短時間リクエストを処理したいという場合はautomatic scalingを利用するのが適切でしょうし、大量データを処理するようなバッチ処理をおこないたい場合はbasic scalingを利用するのが最適だと思います。
このようにGAEは2008年のサービス開始当時のような大量のリクエストを処理するだけのPaaSサービスを超え、あらゆる用途に利用できるサービスにバージョンアップしていることがわかります(※6)。
※6 さらに柔軟なGAEを利用したい場合はFlexible Environmentを利用してください。Standardにはないファイルシステムの利用も可能です。
以上でスケーリング方式の比較説明は終了です。apps-gcpでは今後もGAE関連の記事を定期的にリリースする予定です。ぜひ今後もapps-gcpをチェックしてください。
また、クラウドエースではGAEによる開発のご相談も受け付けております！お気軽にお問い合わせください。