このサイトについて

ディスク<帯域<CPUの順に制限がキツくなるGoogle App EngineのQuota構成から見るコストパフォーマンスの高いシステム構成

ディスク<帯域<CPUの順に制限がキツくなるGoogle App EngineのQuota構成から見るコストパフォーマンスの高いシステム構成

GoogleのクラウドサービスGoogle App Engineに有償コースが追加されました。去年の6月頃,G社のマーケの仕事でApp Engineを使ってアプリを構築していたころ,Quotaの制限に少々手間取っていたことを懐かしく思い出します。システムのサイズや負荷に合わせてQuotaを買うことができるようになったわけですね。やっとQuota地獄から開放される道が開けました。めでたいことです。なによりPythonチームにおめでとうといいたい:-)。

誰でも使えるApp Engineのフリー版には,CPUの計算量やディスク使用サイズによって,制限が設けられています。この制限を超えるとエラーになってしまい,リクエストが処理できなくなってしまいます。

何種類かあるQuotaのうち,一番制限が厳しいのはCPUの使用率。その次はデータの転送量。一番緩いのがハードディスクの使用率。メールには通信する通数に制限があります。

こんな構成になっているので,たとえばリレーショナルデータベースのお約束に則って,正規化したデータ構造を設計して,JOINっぽい操作をたくさん使おうモノならすぐにCPUのQuotaがパンクする。JOINする必要があるようなデータはディスクに書き込んでおくようにするとこの制限を迂回できます。次に頭を悩ますのはデータの転送量でしょうね。でかい画像をたくさん配信しようものなら,すぐにQuotaの制限に引っかかります。画像とか音声は別サーバに置くとか,HTMLをダイエットするとか,そういう対策を取ることになります。

最初のウチは,なんでこんな構成になっているのか,つまりなんで「ディスク<帯域<CPU」の順に制限がキツくなるのか不思議に思っていたのです。が,よく考えてみると答えが見えてきました。ここ数年を振り返ると,ディスク容量のチープ化が一番進んでいるんですね。帯域はインフラ整備が必要なのでそう簡単にはチープ化しないし,CPUの速度も実は以前ほど急速に向上していず,マルチコア化とか並列化で数字を稼いでいるというのが現状。

つまり,CPUパワーの消費をディスクにデータを書き出すことで代替できるのなら,そっちの方がコスト効率がよい,よりチープ革命の恩恵を受けることができる,ということが言えるわけです。Webアプリを作るときは,ヘンにJOINしすぎるより,データをキャッシュ用のテーブルに書き出しちゃった方がいいってことですね。App Engineのプロマネの方(もちろんマウンテンビューの人)とテレカンしたりして,いろいろとコツを教えてもらいながら,なるほどなあと納得したことを思い出しました。

2010-08-27 04:50