Life is beautiful

　Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。

　その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。

　もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。

　リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデータモデルから設計する必要もあるし、プログラムも丁寧に書く必要がある。場合によっては、アプリの仕様から見直さなければならないケースもある。しかし、そういったいくつかの約束事さえきちんと守って作れば、いくらユーザーが増えようとデータベース上のEntity数が増えようとアクセス数に応じてCPUの使用時間と通信量が直線的に増えるだけの「リニアなスケーラビリティ」を持ったアプリケーションを作ることができる、ということは脅威的である。

　mixiにしろ、Twitterにしろ、リレーショナル・データベース上に作られたウェブサービスは、ユーザーが増えるにつれてデータベースの構成を変更しながらスケーラビリティを確保しなければならない、という宿命を背負っている。ユーザーの数が１００万人から１０００万人に増えた時には、単にマシンの台数を１０倍にすれば良いという話ではなく、それに応じてデータベースを新たにクラスタリングさせたり、スケーラビリティの確保のために新たなデータキャッシュの仕組みを導入したり、ということがどうしても必要になる。その結果、マシンの数が１０倍ではなく２０倍必要になったり、スケーラビリティのことだけを専任で担当するエンジニアが何人も必要になったりする。

　今回 Tiny Message を作ることによってはっきり分かったのは、App EngineのDatastoreの特性を活かしたアプリを作れば、その手のことを一切心配せずに、１００万ユーザーにでも１０００万ユーザーにでも自動的にスケールすることができるようにサービスを作ることが可能だ、ということ。それも、私のように片手間でサービスを立ち上げて、ほとんど手間もお金もかけずに運営して行くことが可能だということ。

　Tiny Messageは、まだリリースしたばかりのとても小さなアプリだが、万が一ユーザー数が大爆発したときに備えて、ユニークなURLを生成する際に必要なトランザクションによるスレッド間のコンフリクトを最小限にするように２４万個のEntity Groupを（オンデマンドで）作ってそれぞれにカウンターを持たせて個別にトランザクションさせる、という設計にしてある。Entity Groupが２４万個あれば、相当な同時接続数になったとしても二つのHTTPリクエストが同時に同じEntity Groupを使ってユニークなURLを生成しようとする可能性は限りなくゼロに近い。

　そこも含めて （というかそこが一番難しかったのだが）、Tiny Message はすべてのコードパスがユーザー数やエントリー数には関係なく固定時間で終わるように設計してあるので、トラフィックが１０倍に増えれば単にCPUの使用量が１０倍に増えるだけ、というリニアなスケーラビリティが確保できているのだ。

　そんな設計のため、わずか２０時間走らせただけで、今後トラフィックが増えて来た時にどうスケールするかが、おおよそ予測できる。現在、一番時間がかかっているのがデータベースへの書込みが必要なメッセージの投稿で、平均して400メガサイクル強のCPUを使っている。そこから予想するに、１日あたり１〜２万メッセージの投稿までは「無料Quota」の範囲でやっていける、と予想できるのだ。

　もちろん、その予想は「GoogleのDatastoreがリニアにスケールする」という前提のもとのものなので１００％確実な話ではないが、少なくとも「確実にどこかで限界が来る」ことが見えているリレーショナル・データベースの上で作るのとは大きな違いがある。