数十億人のFacebookユーザーがこのソーシャルネットワーキングサイトにアクセスするたびに、同社のサーバーは世界中の数百、あるいは数千もの異なるサーバーから、ユーザーの投稿、いいね、シェア、画像といったデータを集めなければなりません。ページは数百ミリ秒以内に即座に作成されなければなりません。
決して簡単な作業ではありませんが、Facebookはこれまで、自社のサーバーがどのようにこの困難な処理を実行しているかをほんの少しだけ公開したに過ぎません。しかし今週、同社はカリフォルニア州サンノゼで開催される2013 Usenix Annual Technical Conference において、自社のデータ管理および配信インフラストラクチャのアーキテクチャ概要を発表する予定です。
水曜日にUsenixでプレゼンテーションを行うFacebookのエンジニア、マーク・マルチュコフ氏も、詳細を記したブログ記事を投稿している。
Facebookが提供するデータの構造と量は、商用リレーショナルデータベースが一般的に扱うデータとは大きく異なるため、同社はTAO（The Associations and Objects）と呼ばれる独自のデータストアを開発しました。Facebookは付属のUsenix論文の中で、TAOを「地理的に分散され、結果的に一貫性があり、読み取りに最適化されたグラフストア」と説明しています。
フェイスブック「数年前、FacebookはApache、MySQL、Memcache、PHPといったオープンソースのスタックに完全に依存していました。オープンソースソフトウェアを自社のニーズに合わせてカスタマイズするのは得意でした」と、Facebookのエンジニアリングディレクター、ベンカット・ベンカタラマニ氏はインタビューで語った。「しかしその後、FacebookがFacebookのために構築するデータストアとはどのようなものになるかを考え始めたのです。」
Facebook はまだ TAO のコードをオープンソースとして公開していないが、同社が公開したアーキテクチャの詳細は、Amazon Dynamo や Google BigTable に関するホワイトペーパーが新世代の NoSQL データベースへの道を開いたのと同じように、新しいタイプのデータストアやその他のソフトウェアの開発に影響を及ぼす可能性がある。
この研究は、Facebook が人々とイベントの関連付けに使用しているグラフ データ モデルの有効性と、分散データ管理の威力を示しています。
「ほぼすべての企業はリレーショナルデータモデルを採用していますが、クラウドへの移行に伴い、多くの企業が将来直面するスケーラビリティの課題は、現在の状況とは全く異なるものになるでしょう。私たちは、その点で少しだけ先を進んでいるのかもしれません」とベンカタラマニ氏は述べた。
TAO API（アプリケーション プログラミング インターフェイス）により、「データ ストア全体が 1 つの統合システムのように感じられ、バックエンドでは、多数のマシン、データ センター、さらには地域に分散できるようになります」と Venkataramani 氏は述べています。
TAOは約2年前からFacebookで本格的に導入されており、ピーク時には1秒あたり16億回以上の読み取りと300万回以上の書き込みを処理できます。
2007年に開始されたTAOは、Facebookやサードパーティの開発者がユーザーデータに基づいた新しいサービスを容易に構築できるAPIを構築するプロジェクトとしてスタートしました。このAPIはグラフデータモデルに基づいてデータを提供し、すべての情報をオブジェクトまたは関連付けに分類します。オブジェクトとはユーザーや特定の投稿のことであり、関連付けとは、ユーザーが投稿に「いいね！」するなど、2つのノード間の事前定義された関係を指します。各ノードまたは関連付けは、世界中のどのFacebookサーバーからでも生成できます。
オブジェクトとアソシエーションAPIは、「いいね！」やイベントなど、Facebookの数々の大成功を収めた機能の基盤を築きました。しかし同時に、データリクエストの方法においてサーバーとソフトウェアに大きな負担をかけるという問題もありました。そこで2009年、Facebookのエンジニアたちは、グラフデータ構造での情報提供に適した、オブジェクトとアソシエーションに基づく分散サービスの開発に着手しました。
当初、FacebookのユーザーデータはMySQLに保存され、PHPでクエリされ、Memcacheにキャッシュされて迅速にアクセス可能でした。しかし、時間が経つにつれて、Facebookが収集する膨大なデータ量に対応するため、データベースを数十万の論理シャードに分割し、各シャードに独自のデータ部分を保持する必要が生じました。
Facebookが現在TAOのコンポーネントと見なしているMySQLは、永続的、つまり長期的なデータストレージのみを提供します。ユーザーに表示される情報の大部分は、TAOのグローバルに分散されたインメモリキャッシュから構築されます。このキャッシュには、ユーザーからのリクエストと送信に応じてデータが自動的に追加され、最も最近使用されていない（LRU）データが削除されます。MySQLデータベースに送信されるのは、古くてあまり参照されないデータへのリクエストのみです。
同社はキャッシュ機能に Memcache を使用しなくなりました (ただし Facebook は他のシステムでは引き続きこのソフトウェアを使用しています)。
技術的に言えば、Memcacheはキャッシュ機構というよりはインメモリデータストアに近いとベンカタラマニ氏は説明した。そのため、このソフトウェアは、ソースデータベースとの整合性を自動的に維持したり、ユーザーから要求されたデータベースからデータを自動的に取得したりするといった、典型的なキャッシュ機能を処理できなかった。その結果、Facebookのエンジニアはこれらの機能を有効にするためのコードを部分的に記述する必要があり、全体的なアーキテクチャが複雑化していた。
Memcacheは、Facebookユーザー向け製品を開発する開発者にもかなりの専門知識を必要としたと、ベンカタラマニ氏は指摘した。開発者がMemcacheのニュアンスをすべて理解していなければ、製品にデータの不整合、バグ、パフォーマンスの問題が生じる可能性がある。
TAOキャッシュ層は、主にCおよびC++で記述されたデーモン群によってサーバー上で実行されます。デーモンは書き込みリクエストのルーティング、読み取りリクエストの実行、そして他のキャッシュサーバーとの整合性維持を行います。TAOキャッシュサーバーには、リーダーとフォロワーの2種類があります。各リーダーキャッシュは単一のデータベースシャードに割り当てられ、自身とシャード間のデータの整合性を維持する役割を担います。
リーダーキャッシュは、ユーザーがFacebookにデータをリクエストする際に最初にアクセスするキャッシュであるフォロワーキャッシュに定期的に更新を送信します。Facebookは結果整合性の原則に基づいて動作しており、Facebookに書き込まれたデータはアクセス可能になりますが、すべてのデータベースとキャッシュにデータが書き込まれるまでに数秒かかる場合があります。結果整合性は、分散データベースの使用に伴う動作として長年認識されてきました。
TAOはFacebookに多くのメリットをもたらすと、ベンカタラマニ氏は述べています。まず、トラフィックの急増にも対応でき、フォロワーサーバーを追加するだけで容易に拡張できます。また、キャッシュ層と永続データストレージ層が明確に分離されているため、アップグレードも容易です。これにより、一方を更新したり拡張したりしても、もう一方には影響を与えません。APIもまた、製品ロジックとデータアクセスを明確に分離しています。その結果、「製品開発において、製品エンジニアはデータの保存とアクセスにAPIのみを使用するようになります」とベンカタラマニ氏は述べています。
