Christopher Smith氏は先月，Scale 11x で行なった "スケールの５段階 (The Five Stages of Scale)" と題するプレゼンテーションで，Webアプリケーションのスケーリング問題解決に関する自身の考察を披露した。プレゼンテーションの中で氏が論証したのは，明確に定義されたコンポーネントを追加，あるいは最適化する段階的なスケーリングによって，Webアプリケーション全体の規模を拡大するアプローチだ。ロードバランシングからUDPプロトコルの最適化利用にまで及ぶ幅広い話題で，氏は参加者を 有益な情報に満ちた快適な旅 へと招待した。
スケーリングアーキテクチャの基本としてもっとも重要なのは，ロードバランサの背後にあるWebアプリケーションサーバの増設が可能であることだ。ロードバランサが要求やセッションをアプリケーションサーバ間に振り分けることで，Webアプリケーションのリニアなスケーリングが現実のものになる。このテクニックが使えれば，アプリケーションサーバの増設によってリニアにスケールを拡大することができるが，しかし C10K(クライアント１万台)問題 を避けることはできず，単に先延ばしされるだけだ。サーバを増やしても個々の要求に対する応答性が向上するわけではない，というのがその理由だ。
次に氏は，キャッシュシステムを使用したスケーリングについて説明した。Webアプリケーションの前段に設置したキャッシュ上で参照要求を処理する，という方法である。複数のキャッシュシステムを組み合わせて使用することで，最大限のスケール効果が得られる。また，Memcacheなどのサーバを導入して データをメモリ内に格納しておけば，アプリケーションサーバによる検索の高速化が可能になる。ロードバランサの前段にリバースプロキシを配置してキャッシュされたリソースを提供する，という方法も有効だ。さらにCDN (Content Delivery Network) を使って，キャッシュされたリソースをよりエンドユーザの近くに配置することも考えられる。ただしデータ更新に関して言えば，キャッシュによる効果は限定的なものだ。
更新処理のスケール性を新たな段階まで引き上げるためには，永続化フレームワークを最適化して使用する方法が有効である。氏の説明によれば，このフェーズでの成功と先程説明した内容を組み合わせれば，ほとんどの人にとって十分なものになるはずだ。アプリケーションのデータ構造に適した SQLデータベースあるいはNoSQLデータベースを選択 することで，スケール性はさらに大きく向上する。さらに参照／更新の並列性を確保できれば，更新操作のスループットと応答性の向上に寄与するだろう。その上で "ACID (特にCとD) をうまくごまかす" ことができるならば，更新処理のさらなる高速化も不可能ではない。
このようなスケーリング技術の土台となるのが，Webアプリケーションによるデータ参照／更新のレイテンシの最小化だ。ここまで説明して氏は，コンピュータにおける さまざまな処理のレイテンシ を披露した。
- L1 キャッシュ参照 – 0.5 ns
- 分岐予測ミス – 5 ns
- L2 キャッシュ参照 – 7 ns
- ミューテックスのロック／アンロック – 25 ns
- メインメモリ参照 – 100 ns
- 1KバイトのZip圧縮 – 3,000 ns
- 1Gbpsネットワーク上の1Kバイト送信 – 10,000 ns (0.01 ms)
- SSDから 4K のランダム読み込み – 150,000 ns (0.15 ms)
- メモリから 1MB の順次読み込み – 250,000 ns (0.25 ms)
- 同一データセンタ内のラウンドトリップ時間 – 500,000 ns (0.5 ms)
- SSDから 1MB の順次読み込み – 1,000,000 ns (1 ms)
- ディスクシーク時間 – 10,000,000 ns (10 ms)
- データではなく，コモディティサーバを使用してコードを受け渡す方法: Map/Recude (Hadoop)，DHT，(Cassandra，HBase，Riak)
- データパーティションを経由してデータをルーティングする方法: ESP/CEP，Eigen，Storm，Esper，StreamBase，0mqなど
- TCPに代えてUDPを使用する方法
このような高度なテクニックのほとんどは，ハイパースケールなWebアプリケーションを管理する企業で導入されているものだ。例えば Facebookでは，Memcached で毎秒数十万のリクエストを処理するためにUDPを使用している。