サービスを一から立ち上げる場合も、成功したサービスが更に拡大する場合も、いずれもスケールさせるのは一苦労ですが、今回は、Dropboxの初期の取組みと、Facebookの最近の動きを取り上げてみます。

まずは、DropboxのKevin Modzelewskiが、創業当初のサーバインフラの進化を時系列で紹介している講演から。

Dropboxのデータの特徴

書込みボリューム大: 通常のサービスはコンテンツをつくるより消費するボリュームが圧倒的に多いので、read/write比率が、100:1とか1000:1であるのが典型だが、Dropboxはユーザの全端末がコピーを持つ構造なので、その比率が約1:1になる。つまり、同じサーバに対して、他社よりも100倍、1000倍書込みの役割が大きくなる構造。

ACID特性の要件をしっかり守る必要がある。ユーザの情報を預かるのだから、原子性について、「大きなビデオデータだとファイルの半分しかシェアできない。」というわけにはいかない。整合性も犠牲にできない。利用する全ての端末に同期させる。独立性については、オフライン処理の考慮が必要だし、耐久性についても、ユーザの期待度は当然高い。

1) 2007年中頃

構成図（ビデオ11分53秒時点）

• 創業時。社員２名。
• webサーバ１台で全てを処理

2) 2007年後半

構成図（ビデオ15分10秒時点）

• 社員３名。
• webサーバから、MySQLのインスタンスを別サーバに。データはAmazon S3に移管。
• Dropboxのユースケースに特化したkey/valueストアのカスタマイズサーバをつくるスキルはあったが、まだ社員数も少なく、サービスの成長スピードも読めなかったため、この構成を選択。

3) 2008年前半

構成図（ビデオ19分36秒時点）

• 社員４名。5万ユーザ。
• ダウンロード / アップロード / データ同期確認などの役割を複数のサーバで分担する必要がでてきた。
• webサーバを、自社ホスティングのmetaサーバと、Amazonクラウドに置くblockサーバに分けた。blockサーバはアップロード以外の全てのコンテンツを担当。
• 従来はクライアントが、他のクライアントでの変更を確認するために、webサーバにポーリングする構成だったが、metaサーバと連携したnotificationサーバを新たに追加し、notificationサーバからクライアントにプッシュする仕組みとした。

4) 2008年後半

構成図（ビデオ22分24秒時点）

• 社員９名。10万ユーザ。
• サービスをスケールさせるためには、metaサーバとblockサーバのキャパの問題と、Amazon上のblockサーバから自社ホスティング内のMySQLにリクエストをする構成に起因する遅延に対処する必要がでてきた。
  • metaサーバとblockサーバの増強。
  • blockサーバからのリクエストは、直接MySQLのDBをヒットするのではなく、metaサーバの手前に配置したロードバランサに送る。
  • metaサーバと連携したmemcacheを追加。

5) 2012年前半

構成図（ビデオ23分6秒時点）

• 社員100名。5000万+ユーザ。
• 基本構成は上記4)から変化なし。各ハードウェアを適宜増強。
• memcacheの仕様は、最初のmemcacheがリクエストに対応できないと、次のmemcacheがあてがわれるのが基本。しかしそれでは、1台のサーバが特定のmemcacheが死んでると判断し、一方、別のサーバはそれが生きていると見なすと、データの整合性の問題がでてくる。これに対応するためにライブラリを修正。
• ロードバランサにおいては、まずは、PythonのGlobalInterpreterLockを使って、一度に一つのスレッドだけが実行されるように担保した。その後、複数のロードバランサ間をコーディネートして、同じ仕組みを担保しようとすると、既存のソリューションでは対応できないので大変。また、一つのロードバランサが落ちると全体に影響するダメになるということになりかねない。現在では、ロードバランサ群を二つ一組のペアにして、何かあればバックアップが稼働するようにしている。
• notificationを数千万台のクライアントに送る必要があるので、高スループットを担保するため、二つのレイヤで抽象化している。

また、Facebookのアーキテクチャに関する最近の論文をMurat Demirbasがわかりやすくまとめてくれています。

Tao: ソーシャルグラフ向けの分散データストア

• Facebookはユーザごとにページをカスタマイズしているので、その度に、数百のアイテムをソーシャルグラフからアグリゲートしている。
• Taoができる前は、アグレッシブにmemcacheを使って、MySQLからソーシャルグラフのデータを直接読み書きしていた。
• Taoはソーシャルグラフの抽象化を実現している。オブジェクトとアソシエーションモデルを実装しつつ、引き続き整合性はMySQLで担保しているが、中間レイヤがDBにアクセスし、キャッシュでユーザのリクエストに応えている。（構成図）
• 地域毎にスケールさせるために、memcacheによるスケールに関する論文で発表した、データレコードごとのマスターの考え方を採用している。

F4: warm BLOB（Binary Large Object）ストレージシステム

• Facebookはメディアデータ（その内、写真は4000億枚）をHaystackに保管してきたが、今回の新しいアーキテクチャ（概念図）では、
  • アクセス頻度の高いホットなデータ / 最近追加されたデータはHaystackで保管
  • warm（暖かい、つまり、ほぼアクセスされないというわけではないが、ホットではない）メディアデータは、F4ストレージに保管
• メディアデータへのアクセス頻度は、1週間内で桁が変わり、60日内に1/100になる。
• 6ヶ月〜9ヶ月前のデータで80%、0ヶ月〜3ヶ月前のデータで89%が、warmという区分に入る。
• F4はwarmを専門に扱うことによって、Haystackよりも低い最大スループットを許容でき、かつ削除される可能性も低いデータなので、削除後に物理的にスペースをすぐに必要としない。レプリ効率もよい。

#dropbox #facebook

---

ワザノバTop200アクセスランキング

---