奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。
奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。
ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。
最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖い
1,000万PV/Dayとなると、ピークのリクエスト数が平均の2倍として秒間に230リクエストとなります。
( 10,000,000 pv / 86400 sec/day ) * 2 = 231.481481
奥一穂さんの試算であれば、クアッドコアのサーバで秒間40回の処理が可能なので、6台程度のアプリケーションサーバがあれば、1日1,000万PV、月に3億PVがさばけることになります。冗長性や安全をとるためにサーバを増やしたり、またクアッドコアを2つ搭載するマシンを採用することも考えられますが、この数字は自分の経験と比べても大きなずれはない数字です。
さて、ここからが本題で、1,000万PV/Day（秒間230 req/sec)には何台のデータベースが必要となるのでしょうか。Shardingを行ってデータベースの分散を行い多くのデータベースサーバを運用する必要があるのでしょうか。
1リクエストにつき、SQLを8回発行した場合、秒間のクエリー数の最大は1840query/sec
230 req/sec * 8 = 1840 query/sec
このうち、5%程度が更新系のクエリーだったとしたら、更新系クエリは92 query/secとなり、
1840 query/sec * 0.05 = 92 query/sec
残りが参照クエリとなり、1748
query/secとなります。1リクエストあたりのSQL数や更新回数はアプリケーションにより大きく変動しますが、この程度のクエリー数の場合、MySQLであれば1台で処理することは可能です。冗長性やバックアップのためのSLAVEサーバも追加して1組2台あれば安定稼働できます。
多くのSQLをさばくためには、クアッドコア以上のCPUや十分なメモリー、最適なデータベースサーバの設定や、効率のよいスキーマとSQLの設計が必要です。Blogサービス等でなければデータをあまり蓄積しないのも重要です。MySQLであれば次の書籍が非常に参考になります。
もし、アプリケーションがもっと多くのクエリーを発行していたり、負荷が大きな場合には、安くなったSSDを使ったり、SLAVEサーバを追加して参照クエリーを分散を行ったり、memcachedを利用して参照クエリを減らしたり、また、更新が多いテーブルだけを別のMySQLサーバに移動したり、データが単純なkey-valueであればTokyo TyrantやRedisなどを利用すれば、データベースサーバを最小限にとどめることができます。
2010年代は手軽に購入できるようになった高性能なハードウェアでスケールアップし、OSやミドルウェアのチューニングを行うことで、アプリケーションサーバ、データベースサーバを最小限に食い止め、サービスの収益率を改善してお給料を増やしてもらうのがよいのだろうと思う。
