社内でGoogle App Engineのミニ勉強会をやることになったので、技術者らしくAPIとかBigTableまわりとかやろうかなーと思って色々ドキュメントをあさっていたところ、思いがけず非常に面白いものを見つけてしまった。
それは、料金体系。たいていのGAE紹介サイトには、〜まで無料、以降〜みたいな形でさらっと書いてあるんだけど、思った以上に奥が深い。DoCoMoやソフトバンクモバイルより奥が深い。しかも、この料金体系によってアプリケーションの作り方にまで影響が出てくる可能性がある。こうなってくると、JPAとかJDOとか開発環境とか紹介するのなんて馬鹿馬鹿しくなってしまった。Google App Engine勉強会、って名目で人呼んどきながら、ずーっと料金の話ってありだろうか？なしだろうなぁ。
基本的な概念、リソースとクォータ
さて、Google App Engineには利用可能な資源、リソースが定義されており、リソースにはクォータ（割当）が設定されている。逆に言えば、クォータが設定されているものがリソースであるとも言える。リソースには2種類存在し、固定的に割り当てられていて基本的にはクォータの上限が変更できないもの（Fixed）と、支払いによって上限を増やせるもの（Billable）がある。
ややこしいことに、Fixedのリソースのクォータは、Account保持者が支払い可能状態になると上限が増える（一方Billableなリソースのクォータは、実際に上限を増やすように設定しないと増えない）。
また、クォータにも2種類あり、日ごとの上限値と、分ごとの上限値が設定できる。分ごとの上限値は、日ごとに割り当てられたリソースが急速に消費されつくし、日のうち大部分が稼働不可能になる...といった状況を避けるために設定できるようになっている。
リソースの枯渇と補充
リソースは、クォータの上限値から消費されていき、Pacific Timeの0時にリセットされてクォータの最大値まで補充される。
リソースが枯渇した状態で枯渇したリソースにアクセスしようとした際には、例外が発生する。リソース枯渇に適切に対応しようとする場合、適切にこの例外をハンドリングしなければならない。たとえば、ユーザーにそのサービスが利用不可能であることを通知したり、管理者にメールで通知する等の事後処理が考えられるだろう。これが、アプリケーション設計に影響を与える要素の1つである。
リソースの種類
以下でリソースを紹介するが、支払いによって上限を増やせるものは、オリジナルのドキュメントに従って[B(illable)]と表記する。また、参考のために、無料かつ支払い可能でない状態での日ごとの上限値を並記する。
■ リクエスト系
■ データストア系
アプリケーション開発への影響
こんな感じで、明確に上限回数やリソース追加のコストが明示されたら、アプリケーション開発にはどんな影響があるだろう？まず、テストが変わるんじゃないだろうか。従来も行われてきたであろう、リソースの上限を突破しないか、という観点での試験に加えて、費用対効果を考慮した試験がより厳密に行われるようになる可能性がある。なにせ、無駄にCPUリソースを消費した処理を作ると、明確に費用として跳ね返ってくるようになるのだ。そうなると、富豪プログラミングにかわり、効率の良いアルゴリズムが再び脚光を浴びるようになるかもしれない。つまり、（今後の料金変動や景気、規模にもよりそうだが）今よりも省エネな設計が求められるようになる可能性があるんじゃなかろーか。
その他雑感
こうして、使用リソースに応じた料金表を見ていると、携帯電話料金表や電気料金表を見ながら最安のプランを考えているときと同じ感覚をおぼえて「あぁ、本当にユーティリティコンピューティングの時代が来たんだなぁ」と思いがけず実感してしまう。
と同時に、CPU消費時間で費用が変わるような世界は、よくよく考えると、本や口伝えでしか見聞きしたことがないような、コンピューターリソースが貴重だった時代に似ているような気もしてくる。マシン使用時間に応じて料金がかかっていたらしい、自分の知らない時代。
トレンドは螺旋を描いて戻ってくるとはよく言ったものだ。
それは、料金体系。たいていのGAE紹介サイトには、〜まで無料、以降〜みたいな形でさらっと書いてあるんだけど、思った以上に奥が深い。DoCoMoやソフトバンクモバイルより奥が深い。しかも、この料金体系によってアプリケーションの作り方にまで影響が出てくる可能性がある。こうなってくると、JPAとかJDOとか開発環境とか紹介するのなんて馬鹿馬鹿しくなってしまった。Google App Engine勉強会、って名目で人呼んどきながら、ずーっと料金の話ってありだろうか？なしだろうなぁ。
基本的な概念、リソースとクォータ
さて、Google App Engineには利用可能な資源、リソースが定義されており、リソースにはクォータ（割当）が設定されている。逆に言えば、クォータが設定されているものがリソースであるとも言える。リソースには2種類存在し、固定的に割り当てられていて基本的にはクォータの上限が変更できないもの（Fixed）と、支払いによって上限を増やせるもの（Billable）がある。
ややこしいことに、Fixedのリソースのクォータは、Account保持者が支払い可能状態になると上限が増える（一方Billableなリソースのクォータは、実際に上限を増やすように設定しないと増えない）。
また、クォータにも2種類あり、日ごとの上限値と、分ごとの上限値が設定できる。分ごとの上限値は、日ごとに割り当てられたリソースが急速に消費されつくし、日のうち大部分が稼働不可能になる...といった状況を避けるために設定できるようになっている。
リソースの枯渇と補充
リソースは、クォータの上限値から消費されていき、Pacific Timeの0時にリセットされてクォータの最大値まで補充される。
リソースが枯渇した状態で枯渇したリソースにアクセスしようとした際には、例外が発生する。リソース枯渇に適切に対応しようとする場合、適切にこの例外をハンドリングしなければならない。たとえば、ユーザーにそのサービスが利用不可能であることを通知したり、管理者にメールで通知する等の事後処理が考えられるだろう。これが、アプリケーション設計に影響を与える要素の1つである。
リソースの種類
以下でリソースを紹介するが、支払いによって上限を増やせるものは、オリジナルのドキュメントに従って[B(illable)]と表記する。また、参考のために、無料かつ支払い可能でない状態での日ごとの上限値を並記する。
■ リクエスト系
- リクエスト数（HTTPSを含む）: 1,300,000 requests
- 出力帯域総数[B]（HTTPSを含む）: 10 gigabytes
- 入力帯域総数[B]（HTTPSを含む）: 10 gigabytes
- CPU時間[B] : 46 CPU-hours
- データストアへの書き込みは、読み込みに比べておよそ5倍のCPU時間を使う
- インデックス更新が必要な書き込みは、そうでないものよりCPU時間を使う
- Entityのプロパティが多いほど、読み込みでも書き込みでもCPU時間を使う
- Queryは常にIndexを使うため、Queryはほとんどの場合に同じくらいのCPUしか使わない
- ただし、フェッチが必要な場合は追加のCPU時間が必要になる
■ データストア系
- データストアAPI呼び出し回数 : 10,000,000 calls
- 格納データおよび関連インデックスのサイズ[B] : 1 gigabyte
- APIに送信されたデータのサイズ : 12 gigabytes
- APIから取得したデータのサイズ : 115 gigabytes
- データストアに使ったCPU時間 : 60 CPU-hours
- メールAPI呼び出し回数 : 7,000 calls
- メール送信先アドレスの総数[B] : 2,000 recipients
- 送信メール総数 : 5,000 mails
- メッセージボディのデータサイズ総数 : 60 megabytes
- 送信添付ファイル総数 : 2,000 attachments
- 送信添付ファイルデータサイズ総数 : 100 megabytes
- URLフェッチAPI呼び出し回数 : 657,000 calls
- URLフェッチデータ送信サイズ総数 : 4 gigabytes
- URLフェッチデータ受信サイズ総数 : 4 gigabytes
- Image操作API呼び出し回数 : 864,000 calls
- APIへのデータ送信サイズ総数 : 1 gigabytes
- APIからのデータ受信サイズ総数 : 5 gigabytes
- 変換実行回数 : 2,5000,000 transforms
- MemcacheAPI呼び出し回数 : 8,600,000 calls
- APIへのデータ送信サイズ総数 : 10 gigabytes
- APIからのデータ受信サイズ総数 : 50 gigabytes
- デプロイ回数 : 未定義
- 出力帯域総数：1 gigabytes あたり 約12円
- 入力帯域総数：1 gigabytes あたり 約10円
- CPU時間：1 CPU時間 あたり 約10円
- 格納データサイズ：1ヶ月あたり1 gigabytesで約15円
- メール送信先アドレスの総数：1アドレスあたり約0.01円
アプリケーション開発への影響
こんな感じで、明確に上限回数やリソース追加のコストが明示されたら、アプリケーション開発にはどんな影響があるだろう？まず、テストが変わるんじゃないだろうか。従来も行われてきたであろう、リソースの上限を突破しないか、という観点での試験に加えて、費用対効果を考慮した試験がより厳密に行われるようになる可能性がある。なにせ、無駄にCPUリソースを消費した処理を作ると、明確に費用として跳ね返ってくるようになるのだ。そうなると、富豪プログラミングにかわり、効率の良いアルゴリズムが再び脚光を浴びるようになるかもしれない。つまり、（今後の料金変動や景気、規模にもよりそうだが）今よりも省エネな設計が求められるようになる可能性があるんじゃなかろーか。
その他雑感
こうして、使用リソースに応じた料金表を見ていると、携帯電話料金表や電気料金表を見ながら最安のプランを考えているときと同じ感覚をおぼえて「あぁ、本当にユーティリティコンピューティングの時代が来たんだなぁ」と思いがけず実感してしまう。
と同時に、CPU消費時間で費用が変わるような世界は、よくよく考えると、本や口伝えでしか見聞きしたことがないような、コンピューターリソースが貴重だった時代に似ているような気もしてくる。マシン使用時間に応じて料金がかかっていたらしい、自分の知らない時代。
トレンドは螺旋を描いて戻ってくるとはよく言ったものだ。
コメント