Facebookの環境

　キーノートにおいて、Facebookの環境は以下のようになっていると発表された。

• アクティブユーザー数…7,000万人
• ユーザー数の増加率…多いときで4日で100万人くらいのペース
• Webサーバ台数…1万台
• memcachedサーバ台数…805台
• MySQLサーバ台数…1,800台(マスター/スレーブ各900台ずつ)
• Webサーバへのリクエスト量…毎秒2,000万回
• memcachedのヒット率…95%
• MySQLサーバへのSQL文発行量…毎秒50万回
• memcachedのメモリ搭載量…15TB
• MySQLサーバのメモリ搭載量…25TB
• MySQLのバージョン…5.0.44 Enterpriseをベースに改変(後述)

ユーザー数や台数、クエリ量、メモリ量などは桁違いに多いのがわかる。memcachedのヒット率95%や、memcachedとMySQLサーバの台数/メモリ搭載量の比率など、参考になる数値も多い。

大規模環境のアーキテクチャ

Facebookのアーキテクチャの話に入る前に、前提知識として、MySQLやキャッシュサーバ(memcached)が、一般的にどのように使われているかを簡単に紹介しよう。この構成は日本でもよく使われている。

アプリケーションの規模が大きくなるに従って、1台のMySQLサーバでは処理が追いつかなくなるケースが出てくる。処理が追いつかなくなる原因としては、大きく分けて以下の2つ(およびその混合)が挙げられる。

• SQL文の実行頻度が多いこと(多くの場合、CPUネックになる)
• データ量が多いこと(多くの場合、ディスクネックになる)

読み込みが多い場合は、「スレーブの追加」や後述の「キャッシュサーバ」の追加によって、本体のMySQLサーバ(マスター)への負荷を軽減できる。一方で書き込みが多い場合やデータ量が多い場合は、マスター1台ではディスクI/Oネックになって、効率的に処理を行なえない。そこで「アプリケーションパーティショニング(Sharding)」方式によって、複数台のマスターを用意し、大量のデータと書き込み要求を分散させる。多くの大規模環境では、これらを組み合わせた形を取っている。

アプリケーションパーティショニングがうまくいく(リニアにスケールする)かどうかは、アプリケーションがどのように作られているかに大きく依存する。多くの場合、機能別に分けたり、ユーザーごとに分けたりするが、大きな副作用としてジョインがやりづらくなるという点がある。ジョインを使えばずっと効率良く書けるクエリも、アプリケーション側で処理しなければならなくなるので非効率になる。そのため、できるだけ効率が良くなるようなテーブル設計なども重要なポイントになってくる。