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を超過しなければ)無料で運用することも可能です。
インスタンスクラス | メモリ | CPU | 料金 |
---|---|---|---|
F1 | 128MB | 600MHz | $0.05 |
F2 | 256MB | 1.2GHz | $0.10 |
F4 | 512MB | 2.4GHz | $0.20 |
F4_1G | 1024MB | 2.4GHz | $0.30 |
表1. automatic scalingで設定可能なインスタンスクラス
※3 automatic scalingのインスタンスクラスにB1(~B8)を設定した場合、デプロイ時に以下のエラーメッセージが表示されデプロイが失敗します。
Error 400: --- begin server output ---
Instance class B1 is only allowed with the 'manual' or 'basic' scaling value.
--- end server output ---
Basic Scalingで選択できるインスタンス
basic scalingで利用可能なクラスは以下の通リです。automatic scalingと比べ選択できるインスタンスの種類が1つ多いことがわかります。automatic scalingと同様に、B1,B2,…と数値が上がる度にサーバのスペックと料金(時間単位)が高くなります。また、basic scalingの場合は8 instances-hourが一日のFree Quota(無料枠)として提供されています。
インスタンスクラス | メモリ | CPU | 料金 |
---|---|---|---|
B1 | 128MB | 600MHz | $0.05 |
B2 | 256MB | 1.2GHz | $0.10 |
B4 | 512MB | 2.4GHz | $0.20 |
B4_1G | 1024MB | 2.4GHz | $0.30 |
B8 | 1024MB | 4.8GHz | $0.40 |
表3. automatic scalingで利用可能なインスタンスクラス一覧
各スケーリング方式で設定可能な項目
automatic scalingとbasic scalingの設定項目について説明します。後述する通リ各方式で設定項目が異なります。ただし、automatic scalingは全5項目、basic scalingは全2項目しかないので、全て丸暗記しても良い項目だと思います。もし、ソーシャルゲームのような瞬間的な大量トラフィックが予想されるシステムをGAEで開発する場合、特にautomatic scalingの項目について理解が必要です。それは、各項目のチューニングによって、スケーリングのパフォーマンスや運用コストが変わってくるからです。それでは各項目について説明します。
Automatic Scalingの設定項目
automatic scalingで設定可能な項目は以下の通リです。全5つの項目があり、必要な場合は以下の設定をおこないます。
設定項目 | 説明 | 設定値 |
---|---|---|
min_idle_instances | idle状態で待機させるインスタンスの最小数を指定します。数値を高くすれば突然のトラフィック増加に対応しやすくなりますが、インスタンスが多く起動することになり運用コストは高くなります。 | 0-1000の範囲で数値を指定します。”automatic”を指定して、自動設定にすることも可能です。 |
max_idle_instances | idle状態で待機させるインスタンスの最大数を指定します。スパイクが定期発生する場合等に高い数値を設定しておくことでパフォーマンスが向上します。 | 1-1000の範囲で数値を指定します。デフォルト値は自動設定を表す”automatic”です。 |
min_pending_latency | リクエストがPending Request Queueで待機する最小時間を指定します。数値を小さくすると、インスタンスのスピンアップが起きやすくなります。 | 0.010000s~15.000000sの範囲で時間を指定します。デフォルト値は”automatic”です。 |
max_pending_latency | リクエストがPending Request Queueで待機する最大時間を指定します。数値を大きくすると、既存インスタンスが空くのを待つようになり、インスタンスのスピンアップが起きにくくなります。 | 0.010000s~15.000000sの範囲で時間を指定します。デフォルト値は30msです。”automatic”を指定して、自動設定にすることも可能です。 |
max_concurrent_requests | インスタンスが同時処理するリクエスト数を指定します。ただし、本項目を最大値に近づければ近づける程、1インスタンスの負荷が高まります。 | 1~80の範囲の数値を指定します。ただし、”automatic”は指定することができません。本項目を設定しない場合のデフォルト値は8で最大値は80となります。 |
表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つです。
設定項目 | 説明 | 設定値 |
---|---|---|
max_instances | スケール時の最大インスタンス数を指定します。 | 1~25の範囲で数値を設定します。 |
idle_timeout | idle状態になってからタイムアウトされるまでの時間を指定します。 | 10~3600sの範囲で時間を指定します。デフォルト値は5分です。 |
表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
各スケーリング方式のデッドライン
リクエストのデッドラインは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!")
}
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!") // ログ出力
}
上記画像の通リ、1時間の待機処理後「Hello, world!」とログが出力されていることがわかります。前述した通リ、automatic scalingではTaskQueueを利用しても10分以内のバッチ処理しか対応することができませんが、basic scalingの場合は数時間(最大24時間)というデータ処理も対応することができます。
GAEのオートスケールまとめ
これまでの内容をまとめると以下表のようになります。表の通リ、2つのスケーリング方式は要件によって使い分けが必要であることがわかると思います。
比較項目 | automatic scaling | basic scaling |
---|---|---|
DeadLine | 60秒以内に処理を完了する必要があります。TaskQueueを利用する場合は10分。 | 24時間以内に処理を完了する必要があります。 |
Instance class | F1、F2、F4、F4_1Gから選択可能です。 | B1、B2、B4、B4_1G、B8から選択可能です。 |
Scaling | リクエストのトラフィック量によってスケールアウトします。 | 指定したインスタンス数の範囲でスケールアウトします。 |
Free Quota | 28 instance-hours | 8 instance-hours |
表5. Automatic/Basic Scalingの比較
例えば、大量の短時間リクエストを処理したいという場合はautomatic scalingを利用するのが適切でしょうし、大量データを処理するようなバッチ処理をおこないたい場合はbasic scalingを利用するのが最適だと思います。
このようにGAEは2008年のサービス開始当時のような大量のリクエストを処理するだけのPaaSサービスを超え、あらゆる用途に利用できるサービスにバージョンアップしていることがわかります(※6)。
※6 さらに柔軟なGAEを利用したい場合はFlexible Environmentを利用してください。Standardにはないファイルシステムの利用も可能です。
以上でスケーリング方式の比較説明は終了です。apps-gcpでは今後もGAE関連の記事を定期的にリリースする予定です。ぜひ今後もapps-gcpをチェックしてください。
また、クラウドエースではGAEによる開発のご相談も受け付けております!お気軽にお問い合わせください。