*

GAEのautomatic scalingとbasic scalingを徹底比較!!

公開日: : 投稿者: GAE

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”を指定できませんので、パラメータを記述する場合は必ず数値を指定してください。

例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を設定してデプロイ処理を実行した場合はエラーメッセージが表示されます。

例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に確認中です。

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

 

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

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

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


上記画像の通リ、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による開発のご相談も受け付けております!お気軽にお問い合わせください。

この記事を書いた人

tomorier
tomorier
普段はGCP専門のエンジニアをやっています。
最近は個人的な活動としてGOとswiftでアプリ作ってます。

関連記事

GAEのスケーリング 後編 <最適化の実践>

この記事では、こちらの公式ドキュメントをもとに、GAEのスケーリングの仕組みと最適化のやり方について

記事を読む

AppEngine Security Scan Tool

AppEngine Security Scan Toolが利用出来るようになりました。ついては、GA

記事を読む

これで怖くない Datastore のトランザクション

”トランザクション” 聞いただけで嫌厭する方も少なくないのでは? Datastore のトランザ

記事を読む

GAEでよくあるエラーの発生原因と対策1

GAE上で動くWebアプリケーションに特有の例外について、弊社での運用の事例からいくつか特徴的なもの

記事を読む

GCEにPuttyから簡単接続する

年末ではありますが、先日ちょっとGCE(Google Compute Engine)を触る機会がまた

記事を読む

1つのエンティティにプロパティをいくつまで作れるか

1つのエンティティにプロパティをいくつまで作れるか 1つのエンティティにプロパティをいくつまで

記事を読む

静的HTMLをGAE上で公開する

みなさんこんにちは。 本日は、静的HTMLをGAEで公開する手順を紹介します。 本サイトを運営し

記事を読む

Search API詳細解説 Part6「Search API 詳細 限界値編」

みなさん、こんにちは。 前回はSearch APIの反映速度について調べてみましたが、いかがだった

記事を読む

GAEのスケーリング 前編 <仕組みについて>

今回は、こちらの公式ドキュメントをもとに、GAEのスケーリングの仕組みと最適化のやり方について紹介し

記事を読む

GAE/JからBigQueryへのStream Insert

今回はGAE/JからBigQueryへのStream Insertを試してみます。 BigQuer

記事を読む

PAGE TOP ↑