mixi.jp ミクシィアーキテクチャ

日本を代表するSNSサイト、ミクシィ(Mixi)のアーキテクチャについて。

mixi.jpArchitecture

Mixiは、日本で成長の早いソーシャルネットワーキングサイトです。
Mixiは、次のようなサービスを提供します:
日記、コミュニティ、メッセージ、レビュー、フォトアルバム。LiveJournalと同じアプローチの多くを開発しました。彼らが簡単に彼らのシステムをどのようにスケールさせていったかについて書きます。

サイト: http://mixi.jp

情報源

オープンソースとスケール
http://mysqluc.com/presentations/mysql06/mixi_update.pdf

プラットフォーム

Linux
Apache
MySQL
Perl
Memcached
Squid
Shard - http://highscalability.com/tags/shard

どうなっているか？

2年で約400万ユーザに成長し、1日15000人の新規ユーザが参加しました。
Alexaで35位、日本で3位です。
100台以上のMySQLサーバがあります。
月に10台以上追加しています。
非永続的なコネクションを使っています。
日記のトラフィックは、リード(読み込み)が85％、ライト(書き込み)が15％です。
メッセージのトラフィックは、リード(読み込み)が75％、ライト(書き込み)が25％です。
レプリケーションのパフォーマンスの問題に直面したとき、彼らはデータベースを分割しました。
彼らがデータベースを分割しなければならなかったように、レプリケーションのパフォーマンスの問題にぶつかりました。
ユーザにより垂直に割るか、テーブルタイプによって水平に割ることを考えました。
結局、テーブルタイプとユーザによってパーティショニングしました。
ユーザグループのメッセージのすべては、特別のデータベースに割り当てられます。
パーティションキーは、データが格納されるべきデータベースを決定するのに使われます。
キャッシュのために、30台 x 2GBメモリをmemcachedに使います。
8TB以上の画像を保存し、1日に23GBぐらい追加されます。
MySQLはイメージのメタデータを保存するためにだけに使われます、画像自体のためではありません。
たびたび、アクセスされる画像は、複数のマシンのSquidを使用してキャッシュされます。
めったにアクセスされない画像は、ファイルシステムから配信されます。
それらをキャッシュするメリットがありません。

学んだこと

動的パーティショニングを使うとき、データを格納するためのキーとアルゴリズムを選ぶことは難しいです。
一度データを分割すると、もはや、joinすることができません。そして、データをマージするために異なったデータベースへのたくさんのコネクションをオープンしなければなりません。
データベースを分割しているとき、新しいホストを加え、データを再配置することが難しいです。
たとえば、パーティショニングアルゴリズムは、ユーザ 1-Nをホスト1にすべてのメッセージを格納するとしましょう。
すぐに、ホスト1がデータを抱えすぎるようになり、そして、あなたがは多くのホストに渡ってユーザを再配置したいと言います。
これをするのは、とても難しいです。
分散メモリキャッシュにより、DBへのアクセスはほとんどありません。平均的なページロードの時間は、0.02秒です。
あなたは、たびたびコンテンツのタイプによる戦略を開発しなければなりません。例えば、画像は、短いテキストの配信とは異なって扱われるでしょう。
ソーシャルネットワーキングサイトは、とても時間が重視されるため、ユーザタイプと同様に時間による分割が役に立つかもしれません。

元ネタ
http://highscalability.com/mixi-jp-architecture

参照しているページ (サイト内): [2008-08-21-2]

mixi.jp ミクシィアーキテクチャ

関連記事

最近の記事

はてなの人気のブックマーク

過去ログ

mixi.jp ミクシィ アーキテクチャ

関連記事

最近の記事

はてなの人気のブックマーク

過去ログ

mixi.jp ミクシィアーキテクチャ