(http://tinymsg.appspot.com)をリリースしてまだ20時間経っていないが、設計の過程でいろいろと学べたことがある。Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデータモデルから設計する必要もあるし、プログラムも丁寧に書く必要がある。場合によっては、アプリの仕様から見直さなければならないケースもある。いったいくつかの約束事さえきちんと守って作れば、いくらユーザーが増えようとデータベース上のEntity数が増えようとアクセス数に応じてCPUの使用時間と通信量が直線的に増えるだけの「リニアなスケーラビリティ」を持ったアプリケーションを作ることができる、ということは脅威的である。mixiにしろ、Twitterにしろ、リレーショナル・データベース上に作られたウェブサービスは、ユーザーが増えるにつれてデータベースの構成を変更しながらスケーラビリティを確保しなければならない、という宿命を背負っている。ユーザーの数が100万人から1000万人に増えた時には、単にマシンの台数を10倍にすれば良いという話ではなく、それに応じてデータベースを新たにクラスタリングさせたり、スケーラビリティの確保のために新たなデータキャッシュの仕組みを導入したり、ということがどうしても必要になる。その結果、マシンの数が10倍ではなく20倍必要になったり、スケーラビリティのことだけを専任で担当するエンジニアが何人も必要になったりする。EngineのDatastoreの特性を活かしたアプリを作れば、その手のことを一切心配せずに、100万ユーザーにでも1000万ユーザーにでも自動的にスケールすることができるようにサービスを作ることが可能だ、ということ。それも、私のように片手間でサービスを立ち上げて、ほとんど手間もお金もかけずに運営して行くことが可能だということ。Groupを(オンデマンドで)作ってそれぞれにカウンターを持たせて個別にトランザクションさせる、という設計にしてある。Groupを使ってユニークなURLを生成しようとする可能性は限りなくゼロに近い。すべてのコードパスがユーザー数やエントリー数には関係なく固定時間で終わるように設計してあるので、トラフィックが10倍に増えれば単にCPUの使用量が10倍に増えるだけ、というリニアなスケーラビリティが確保できているのだ。そんな設計のため、わずか20時間走らせただけで、今後トラフィックが増えて来た時にどうスケールするかが、おおよそ予測できる。現在、一番時間がかかっているのがデータベースへの書込みが必要なメッセージの投稿で、平均して400メガサイクル強のCPUを使っている。そこから予想するに、1日あたり1〜2万メッセージの投稿までは「無料Quota」の範囲でやっていける、と予想できるのだ。その予想は「GoogleのDatastoreがリニアにスケールする」という前提のもとのものなので100%確実な話ではないが、少なくとも「確実にどこかで限界が来る」ことが見えているリレーショナル・データベースの上で作るのとは大きな違いがある。|Comments「コンフリクトを最小限にされている」とのことなのでEntityGroupでも大丈夫な気がしますが、リクエストが増えたときにボトルネックにならないか、ちょっと心配ですね。カウンタを持たないでシーケンス番号をつける方法http://blog.virtual-tech.net/2009/11/google-app-engine.htmlも考えてみましたので、ご参考まで。TypepadTop。