Google App Engine(GAE)を無料枠で収めるための勘所

GAE設定（app.yaml）周りで気をつけたいこと

automatic_scalingの設定を適切にする

GAEは処理負荷に合わせて自動でスケーリングしてくれる素晴らしいサービスなのですが、逆にGAE側で「もっとインスタンスを増やした方がいいな」と判断されてしまうと、どんどん起動インスタンスを増やしていってしまいます。

そうすると、1日28インスタンス時間はあっという間になくなってしまうので、app.yamlで最大インスタンス数を決めておくなど対処しておくと無料枠に抑えることができます。

automatic_scaling:
  min_idle_instances: automatic
  max_idle_instances: 1
  min_pending_latency: 3000ms
  max_pending_latency: automatic
  max_instances: 2

上記は最大稼働インスタンスを2に、最大アイドルインスタンスを1にしています。

フレキシブル環境は絶対使わない

すでにいろんなブログなどで言われていることですが、GAEの無料枠はスタンダード環境のみなので、GAEを無料運用したいのであればフレキシブル環境は絶対に立ち上げてはいけません。

また、アクセスがあって初めて立ち上げるスタンダード環境に対して、フレキシブル環境は最低でも1インスタンスを常時起動します。ですので、フレキシブル環境を使うというapp.yamlを書いたら最後、1時間あたり6円以上のコストが「アプリを停止・削除する」まで永久に発生し続けるのです。

さらに、フレキシブル環境では、「一日の予算」が無視されるので、「予算を設定しているから大丈夫」と思っていたら翌月高額請求がきて青ざめるということになってしまいます。

スタンダード環境を使うクセをつける

GAEは何も指定しない限りスタンダード環境を使うようになっていますが、念のためにapp.yamlでスタンダード環境とインスタンスクラスを指定するクセをつけておくと良いでしょう。

env: standard
instance_class: F1

他人のapp.yamlはGAEの仕組みや料金体系を理解してから使う

GoogleのGAEに関するドキュメントや「GAEを使ってみた」的なブログなどでは、サイト構築の例としてフレキシブル環境をapp.yamlで指定しているケースがまあまああります。

ですので、GAEの料金体系や仕組みを理解せずにそのままコピペして使うとかなり危険ということを頭に入れておきましょう。

他人のapp.yamlで不明な点があったら、必ず調べて意味を理解してからGAEにデプロイするようにしましょう。

GAEの環境の違いについては、下記の記事をどうぞ。

Google App Engine(GAE)のフレキシブル環境とスタンダード環境の違いを把握する

Google App Engine(GAE)のバックエンド環境である、フレキシブル環境とスタンダード環境の違いを見ていきます。

作成するアプリで気をつけたいこと

処理の重いスクリプトは走らせない

GAEのインスタンスは処理をしている間とその前後のみ起動して、処理がない時は休止状態になります。つまり、同じ処理でも、スクリプトを軽くすれば、早くインスタンスを休止状態にさせることができます。

DB接続する場合や、処理が多いスクリプトを実行すると、「処理終了まで時間がかかる=インスタンス起動時間が長くなる」ということになり、インスタンス稼働時間も起動インスタンスも増えていく傾向にあるので、注意が必要です。

同期処理よりも非同期処理

例えば、WordPressで採用されているPHPは、1リクエストの処理が終わってから次の処理をする「同期処理」言語です。この場合、仮に1インスタンスで処理できる同時待ち受けが1だった場合、1スクリプトの処理に1秒かかると、60リクエストあった場合は単純に60秒かかります。処理をしている間はGAEインスタンスが稼働し続け、処理が捌き切れないと判断すると、GAEは稼働インスタンスを自動で増やします。

一方で、Node.jsなどの非同期処理ができるスクリプトの場合は、複数の処理を同時並行で行えるため、同じ60リクエスト処理でも、同期処理言語よりも短くすることが可能（非同期を前提にした書き方が必要ですが）で、その分GAEインスタンスの消費を抑えることができます。

アクセス数が多いWebアプリをGAEの無料枠28インスタンス時間に収めるのであれば、プログラムで選択する言語も重要になりそうです。

適切なエラー処理をする

GAEは処理が続いている間インスタンスを起動させるので、応答のないエラーやスクリプトが走っているとその間ずっとインスタンスが稼働します。

例えば、通常の処理では300msで処理が終わるスクリプトで、エラーが発生すると問い合わせが続いてレスポンスを返すまでに3000msかかる場合、通常の10倍の時間インスタンスが稼働します。

自分も遭遇したケースでは、MySQLを5.6から5.7にバージョンアップしたところ、5.6では問題なかったけど5.7ではエラーになるSQL構文があって、GAE側のスクリプトがエラーを吐いたままで10数秒起動しっぱなしという不具合がありました。

Cloudコンソールで見たら急に消費インスタンス時間が増えていて、何かがおかしいと思って「現在の負荷」やエラー周りを見ていたら通常50msくらいで返答するはずのスクリプトが20秒くらいかかっていたのが原因でした。

もちろん、エラーをなくすことが大事ですが、こういうことにならないように、エラー時にスクリプトを止める処理もしっかり考えておく必要があります。（これはGAEに限ったことではありませんが）

GAEを使うなら普段からやっておきたいこと

ダッシュボードの「課金インスタンス推定」を当てにしない

GAEのダッシュボードでインスタンスのグラフを見ると、

• 作成
• 有効
• 課金インスタンス推定

の3つが表示されます。

文言からすると「課金インスタンス推定だけみておけばOK」というような気がしますが、ここはあくまで「推定」であり、しかもどういうわけかフレキシブル環境のインスタンスは課金インスタンス推定に含まれません。

ですので、課金インスタンス推定だけで判断していると、意味もわからず他人のapp.yamlでデプロイしてフレキシブル環境のインスタンスを立ち上げていたのに、課金に気づかなかったということがあり得るので要注意です。

正確なGAE課金を確認したいなら、「お支払い」ダッシュボードをこまめにチェックしましょう。

お支払いダッシュボードは常にチェック。予算アラートもしっかり設定

これはGAEに限らずクラウドサーバー全般に言えることですが、「使った分だけ課金」と聞こえはいいクラウドサーバーですが、逆に言えば「使えば使うほど青天井に課金する」という意味でもあることを常に覚えておきましょう。

知らない間に高額課金になっていたということを避けるためにも、お支払いは定期的にチェックし、予算アラートも必ず設定しましょう。

以上、簡単にですが、GAEを無料枠で収めるための勘所をまとめてみました。

筆者自身が、6000アクセス/日あるAPIをGAEで稼働していますが、エラー関連のミスで0.6ドルほど無料枠を超えた（それでも、300ドルトライアルで無料）だけで、無料枠内で安定して稼働しています。

使い方を理解すれば、無料枠でも十分に使えると言えそうです。