ブロガーの実験室スポンサー広告
> Google App Engineの料金体系が面白い > ブロガーの実験室パソコンな日々
> Google App Engineの料金体系が面白い
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


--.--.--|スポンサー広告||TOP↑

refer http://hibituredure.blogspot.com/2009/04/google-app-engine.html


メモ
http://code.google.com/intl/ja/

http://www.atmarkit.co.jp/fjava/index/index_gaej.html


社内で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)]と表記する。また、参考のために、無料かつ支払い可能でない状態での日ごとの上限値を並記する。

■ リクエスト系

  • リクエスト数(HTTPSを含む): 1,300,000 requests
  • 出力帯域総数[B](HTTPSを含む): 10 gigabytes
  • 入力帯域総数[B](HTTPSを含む): 10 gigabytes
  • CPU時間[B] : 46 CPU-hours
CPU時間はデータストアで使った時間も含む。外部サービス呼び出し等による待機時間は含まない。また、CPU消費時間の目安として、以下のようなものがあげられている。
  • データストアへの書き込みは、読み込みに比べておよそ5倍のCPU時間を使う
  • インデックス更新が必要な書き込みは、そうでないものよりCPU時間を使う
  • Entityのプロパティが多いほど、読み込みでも書き込みでもCPU時間を使う
  • Queryは常にIndexを使うため、Queryはほとんどの場合に同じくらいのCPUしか使わない
  • ただし、フェッチが必要な場合は追加のCPU時間が必要になる
リクエスト系のリソースの特筆すべき点は、これらのリソースが不足した場合にはリクエストのハンドリングを開始すらできないため、ユーザーにはHTTP Status403が返されてしまう、という点だ。

■ データストア系
  • データストア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フェッチ系
  • URLフェッチAPI呼び出し回数 : 657,000 calls
  • URLフェッチデータ送信サイズ総数 : 4 gigabytes
  • URLフェッチデータ受信サイズ総数 : 4 gigabytes
■ Image操作系
  • Image操作API呼び出し回数 : 864,000 calls
  • APIへのデータ送信サイズ総数 : 1 gigabytes
  • APIからのデータ受信サイズ総数 : 5 gigabytes
  • 変換実行回数 : 2,5000,000 transforms
■ Memcache系
  • MemcacheAPI呼び出し回数 : 8,600,000 calls
  • APIへのデータ送信サイズ総数 : 10 gigabytes
  • APIからのデータ受信サイズ総数 : 50 gigabytes
■ デプロイ
  • デプロイ回数 : 未定義
リソース[B]の単位あたりコスト
  • 出力帯域総数:1 gigabytes あたり 約12円
  • 入力帯域総数:1 gigabytes あたり 約10円
  • CPU時間:1 CPU時間 あたり 約10円
  • 格納データサイズ:1ヶ月あたり1 gigabytesで約15円
  • メール送信先アドレスの総数:1アドレスあたり約0.01円
安…!いよね?

アプリケーション開発への影響
こんな感じで、明確に上限回数やリソース追加のコストが明示されたら、アプリケーション開発にはどんな影響があるだろう?まず、テストが変わるんじゃないだろうか。従来も行われてきたであろう、リソースの上限を突破しないか、という観点での試験に加えて、費用対効果を考慮した試験がより厳密に行われるようになる可能性がある。なにせ、無駄にCPUリソースを消費した処理を作ると、明確に費用として跳ね返ってくるようになるのだ。そうなると、富豪プログラミングにかわり、効率の良いアルゴリズムが再び脚光を浴びるようになるかもしれない。つまり、(今後の料金変動や景気、規模にもよりそうだが)今よりも省エネな設計が求められるようになる可能性があるんじゃなかろーか。

その他雑感
こうして、使用リソースに応じた料金表を見ていると、携帯電話料金表や電気料金表を見ながら最安のプランを考えているときと同じ感覚をおぼえて「あぁ、本当にユーティリティコンピューティングの時代が来たんだなぁ」と思いがけず実感してしまう。
と同時に、CPU消費時間で費用が変わるような世界は、よくよく考えると、本や口伝えでしか見聞きしたことがないような、コンピューターリソースが貴重だった時代に似ているような気もしてくる。マシン使用時間に応じて料金がかかっていたらしい、自分の知らない時代。
トレンドは螺旋を描いて戻ってくるとはよく言ったものだ。


2010.06.15|パソコンな日々コメント(0)TOP↑
名前:
コメントタイトル:
メールアドレス:
URL:
コメント:

パスワード:
管理人だけに表示:
管理者にだけ表示を許可
カテゴリー
最近の記事
最近のコメント
最近のトラックバック
ブログ検索
管理人のブログ一覧
管理人へメール

名前:
メール:
件名:
本文:

月別アーカイブ
プロフィール

やまもも実験室

Author:やまもも実験室
FC2ブログへようこそ!

RSSフィード
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。