GAE でうっかり発生していた課金を無くして無料運用に戻した話2016-08-27
ちょっと期間が空きましたが、1つ前のポストこのブログで使ってる WP テーマと追加したプラグインの話の続きの話です。
前回までで一通りブログの新サーバへの移行作業は完了し、想定外のエラーなどが発生していないか数日間様子を見ていたときのことでした。こんな弱小サイトでまさか発生しないだろうと思っていた課金が発生していたのです。といってもクレカを登録した際にもらった $300 が少し目減りした程度の話ですし、追加課金は許可していないので実際の課金が発生したわけではありません。
ただこのままでは $300 の有効期限が切れた後、課金が発生するタイミングで実際に課金が発生する代わりにエラーが発生するようになってしまうので、それは避けなければなりません。そこで課金の発生箇所を確認したところ、唯一フロントエンドのインスタンス時間が無料時間分を超えていました。
GAE はクラウドがベースのサービスなので、もちろん固定のフロントエンドのサーバが存在しているわけではありません。必要に応じて必要な分だけインスタンスを起動する仕組みになっていて、その無料分が一日当たり 28 時間という事になっています。つまり、1インスタンスは起動しっぱなしでも良くて、負荷が増えて 2 個目のインスタンスが立ち上がっている時間が 1 日当たり 4 時間を超えたらダメ、という感じです。
そして、インスタンスの起動・終了にも一定の時間がかかるので、頻繁に On/Off するのでは無く、負荷が増えそうな気配がしたらインスタンスを追加、一定時間以上インスタンスがアイドルしてたらインスタンスを削除、というような挙動をしているようです。
当初想像していたのは、ゆうてもそんな、インスタンスが 24 時間も上がりっぱなしにはならないだろうし、ましてや 2 つめのインスタンスなんて、という感じでした。ところが蓋を開けてみるとご覧のように、28 時間を超えるどころか多い日は 35 時間を超えている日もありました。
当初の狙い通りではあるのですが、ロングテールなこのブログは、絶えず地味に少しだけアクセスがあり続け、また、Googlebot や RSS リーダーなどからの定期的なアクセスもあり、インスタンスが落ちる暇が無いという状況でした。CPU だの帯域だのはクッソほど余ってるのに、インスタンス時間だけ超過するのはややアンバランスで課金の納得感に欠けるので何とかしたいところです。ちなみに 0.16 円 (16銭) とかどうでも良いかなー、と一瞬思いかけたのですが、よくよく計算してみるとこれ、$0.16 の単位だけ ¥ に変えてみたよっていう Google 側のバグでして、実際には 16 円相当です。
というわけでこれを何とかするのですが、設定自体は意外に簡単。app.yaml に下記の記述を追加してデプロイするだけでした。(GAE/php の場合。GAE/py や GAE/j では少し違うらしい。)
そして max_pending_latency です。これが何かというと、1 つのインスタンスで全く同時に対応出来るのは 1 つのアクセスに限られるので、後から来たアクセスがキューで待つ最大の時間はどのくらいか、という値になります。これが実は結構な罠で、デフォルトが 30 ms なので、ちょっと重いページに複数のアクセスが (ほぼ) 同時に発生すると、すぐに 30ms の壁を突破し次のインスタンスを要求してしまいます。この時、インスタンスの数が 1 で制限されていると、当然ながらエラーになってしまうはずです。なのでこれは思い切って 2000ms まで伸ばしてしまいました。まあ、最悪ケースで 2000ms 待たされても、うちみたいな弱小サイトだったら 30ms でエラー表示するよりずっといいかな、という判断です。
これらを設定した結果、無事に課金は 0 になりました。素晴らしい！
以上で、一連のサーバ移行シリーズは完了になります。実際、現在までで本格稼働からほぼ 1 ヶ月になりますが、今のところさしたる問題もなく安定してよく動いています。相変わらずのロングテールっぷりには変わりありませんが…。
前回までで一通りブログの新サーバへの移行作業は完了し、想定外のエラーなどが発生していないか数日間様子を見ていたときのことでした。こんな弱小サイトでまさか発生しないだろうと思っていた課金が発生していたのです。といってもクレカを登録した際にもらった $300 が少し目減りした程度の話ですし、追加課金は許可していないので実際の課金が発生したわけではありません。
ただこのままでは $300 の有効期限が切れた後、課金が発生するタイミングで実際に課金が発生する代わりにエラーが発生するようになってしまうので、それは避けなければなりません。そこで課金の発生箇所を確認したところ、唯一フロントエンドのインスタンス時間が無料時間分を超えていました。
GAE はクラウドがベースのサービスなので、もちろん固定のフロントエンドのサーバが存在しているわけではありません。必要に応じて必要な分だけインスタンスを起動する仕組みになっていて、その無料分が一日当たり 28 時間という事になっています。つまり、1インスタンスは起動しっぱなしでも良くて、負荷が増えて 2 個目のインスタンスが立ち上がっている時間が 1 日当たり 4 時間を超えたらダメ、という感じです。
そして、インスタンスの起動・終了にも一定の時間がかかるので、頻繁に On/Off するのでは無く、負荷が増えそうな気配がしたらインスタンスを追加、一定時間以上インスタンスがアイドルしてたらインスタンスを削除、というような挙動をしているようです。
当初想像していたのは、ゆうてもそんな、インスタンスが 24 時間も上がりっぱなしにはならないだろうし、ましてや 2 つめのインスタンスなんて、という感じでした。ところが蓋を開けてみるとご覧のように、28 時間を超えるどころか多い日は 35 時間を超えている日もありました。
当初の狙い通りではあるのですが、ロングテールなこのブログは、絶えず地味に少しだけアクセスがあり続け、また、Googlebot や RSS リーダーなどからの定期的なアクセスもあり、インスタンスが落ちる暇が無いという状況でした。CPU だの帯域だのはクッソほど余ってるのに、インスタンス時間だけ超過するのはややアンバランスで課金の納得感に欠けるので何とかしたいところです。ちなみに 0.16 円 (16銭) とかどうでも良いかなー、と一瞬思いかけたのですが、よくよく計算してみるとこれ、$0.16 の単位だけ ¥ に変えてみたよっていう Google 側のバグでして、実際には 16 円相当です。
というわけでこれを何とかするのですが、設定自体は意外に簡単。app.yaml に下記の記述を追加してデプロイするだけでした。(GAE/php の場合。GAE/py や GAE/j では少し違うらしい。)
automatic_scaling: min_idle_instances: 1 max_idle_instances: 1 max_pending_latency: 2000msまず automatic_scaling というのがその名の通り、自動的にスケールさせるための設定項目なので、そこで min_idle_instances と max_idle_instances を指定し、アイドルしてるインスタンスの数を 1 で固定します。つまりスケールするのを禁止してしまっているのですが 28 時間越えを避けるためにはしょうが無いですし、本質的にはこれだけで課金は防げるはずです。一方、min を 1 にする事でインスタンスが落ちるのも避けています。現状見る限りあまりなさそうですが、インスタンスが無いときにアクセスされても、インスタンスの起動時間分ユーザを待たせないための配慮ですね。
そして max_pending_latency です。これが何かというと、1 つのインスタンスで全く同時に対応出来るのは 1 つのアクセスに限られるので、後から来たアクセスがキューで待つ最大の時間はどのくらいか、という値になります。これが実は結構な罠で、デフォルトが 30 ms なので、ちょっと重いページに複数のアクセスが (ほぼ) 同時に発生すると、すぐに 30ms の壁を突破し次のインスタンスを要求してしまいます。この時、インスタンスの数が 1 で制限されていると、当然ながらエラーになってしまうはずです。なのでこれは思い切って 2000ms まで伸ばしてしまいました。まあ、最悪ケースで 2000ms 待たされても、うちみたいな弱小サイトだったら 30ms でエラー表示するよりずっといいかな、という判断です。
これらを設定した結果、無事に課金は 0 になりました。素晴らしい！
以上で、一連のサーバ移行シリーズは完了になります。実際、現在までで本格稼働からほぼ 1 ヶ月になりますが、今のところさしたる問題もなく安定してよく動いています。相変わらずのロングテールっぷりには変わりありませんが…。
カテゴリ: Development タグ: gae