GAEでMax Idle Instancesを1にした時の色々の続報ですが。

　結局、一週間くらいFrontend Instance HoursのUsedが24.01にビターッと張り付きっぱなしで、当然Billableは0.00。他は問題外なくらい余裕。
　つまり余裕の無料と予想されるので、別にそれでいいじゃん、という話ではあるのだが。色々見て回ってると、Max Idle Instancesが1だからといっても常に24.01に張り付くという訳じゃなさそうな。行く人はもっと上がるようだ。ふーむ。
　ちなみにMin Pending LatencyはAutomaticのままである。なので、グラフを見る限りでは相当頻繁にインスタンスが二個立ち上がっているのだが、24.01から動かないのがやっぱり謎。

　仮に、IdleなInstancesがMax Idle Instancesより多く立ち上がっている分は計算外にする、という仕様だとすれば、納得は行く。その場合、一日中インスタンスが立ち上がってても24.00+CPU使用時間が理論最大値になるだろうし。うちのアプリなんかはキャッシュと事前計算でかなり削りやすいから、ログ見ても0cpu_msとか普通だしなあ。
　まあ、こんな憶測を積み上げてもあまり意味は無い気もしますが。

　コモンズの悲劇は認識しているけれども、ちょっと気になることもあるので、一週間ちょい前からVPSのcronで一分ごとにwgetしてテスト中。
　んで、丸二日くらい経過した頃から26h/dayくらい、さらにその二日後くらいからは34.5h/dayくらいフロントエンドインスタンスが使われる状態になってきた。よし、この辺でMax Idle Instancesを1に設定してみよう。
　これはかなり即効性があり、24.01h/dayに二日連続で張り付いた。グラフを見る限り、もっと立ち上がってそうだし、昨日と一昨日の状態もかなり違うし、二日ともきっちり24.01hというのは不自然だな。"You will not be charged for instances over the specified maximum."とか"Setting Max Idle Instances to a lower level will help lower your costs as we will only charge for idle instances up to the maximum you set."とかいう文言は、設定した最大値を超えて立ち上がった分の課金は無しよ、と捉えていいのだろうか。それでConcurrent Requests対応なら、無料枠でも困る気は全くしないけど。何しろ俺のアプリはDatastore全く使わないので（笑）。

　で、テスト中のインスタンス立ち上がりっぱなし状態が地味に快適で。スピンアップが問題な訳だし、GAE/Goとか試してみるか？（笑）
　つっても、今更Pythonで書いたのを移植する気もしないな。うむ。やめようか。
　スピンアップ時間を仮に激しく極小化出来ていたら、旧課金モデルで行けたのかもだけどなあ。やれたらやってるんだろうけど。あのモデルはelasticityを細分化の方向にも持ち込んでいた点が好きだったので残念だ。

　Google App Engineで身内向けの小さいWebアプリを幾つか動かしてるんだけど、課金方法が大幅に変わるとか、大抵の人には値上げになるとか、ひどい場合はお値段が一桁変わるとか、無料枠死ぬんじゃねーのとか、色々聞いて不安だったのだが。
　結局のところ、仕組みを理解して正しく設定すれば余裕っぽい感じになってきた。

　つーか、今はGAEのダッシュボードから新料金の予定値が出るようになって、ユーザーが実際どう変わるか理解してきて、そのフィードバックが運営側にも行ってる訳で、それを受けたGAEの公式blogで「ちょっと料金変更するよ」とかも出てたり。
　特に無料ユーザーに興味深いのは、フロントエンドインスタンスの無料枠が24時間/日から28時間/日に拡大されたことか。つっても、Max Idle Instancesを1に設定してたらどうでもいいことなんじゃ、と思わなくも無いんだけども、実際その設定にしたのはついさっきなので何とも。何故今まで設定してなかったかと言うと、灰色表示だから設定不可だと思い込んでいた。単に灰色なだけでした（笑）。

　あと、新体系になるのは11/1、と読めるんだけど、英語あんまり自信無いんで何ともかんとも。
　それと、Python 2.7の導入される12/1まではインスタンス半額だよ、ってなってる（ように読める）けど、もしかしてConcurrent Requestsってアプリ側は何もしなくていいんだろか。これってスレッドで実装されるんかなー。Pythonのスレッドってどんなんだろ。えーと…。
　何だってー。
　まあ、分散してパフォーマンス上げるような用途の言語じゃねー（気がする）し、ノンブロッキングみたいな用途を押さえれば十分なのかも。そもそも低水準を表に出すタイプの言語でもないよなあ。

　という訳で、何だか何もしなくても良さそうな予感です。面白くないです（笑）。
　まあでも、GAE的には十分便利かも。

追記:
　スレッドはさすがに何もしなくても良くはなさそうだった。でも平行リクエスト処理はそもそもどう実装されてるか分からんし、っつーか書く前に調べろ俺。

また追記:
　実装によって変わるようで、とりあえずCPythonだと面白みは無さそうだった。
　あと平行リクエストもGAEの話しかヒットしないし、やっぱGoogle側で実装する部分なんかなあ。テスターやるのは英語だるそうだしなあ…。

　今ちょっとproxy欲しいんだけどなー、とか言ってたら、SSHが繋がるホストならそのままproxyになるのよ、とか言われた。全くproxyに見えないレベルの奴に。マジで？
　試しに、さくらのVPSにSSH Dynamic Forwardingをしてみた。ふむふむ。設定はこうかな。うっは。
　調子に乗って、さくらのレンタルサーバでも実験。ははは。こっちでも出来るんかい。

　という訳で、さらにSSHの便利さが身に沁みるのであった。
　まあ、今書いてるコードが出来上がったら、proxyとか使う機会も当分無くなりそうだけど。