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)」方式によって、複数台のマスターを用意し、大量のデータと書き込み要求を分散させる。多くの大規模環境では、これらを組み合わせた形を取っている。

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