今回のmixiアクセス不能の件、memchachedのデーモンダウンが原因とのこと。

memchachedはDBクエリー負荷を軽減する為のメモリキャッシュ機能で、 大規模サーバのDB負荷軽減においてここ数年流行の機能です。

詳しくは、WEB+DB PRESS vol47を参照

mixiの対応策

今回のmixiの対応策としては

memchachedの設定で最大接続数を絞り、サーバを増やす方向で対処した

あと、繋がりにくいのは単にWebの帯域制限をかけてたものと見られます。

Facebookの規模

mixiの利用者数は2000万やそこら。 しかし5億以上とも言われているFacebook。 利用者が増えれば正比例以上にサーバ負荷となる。 でも、なぜFacebookは平然な顔で動作しているのか？

(1)数万台規模と言われてるサーバの台数 (2)RDBからの脱却

(1)に関しては桁違いとしか言いようがないｗ (2)に関しては、AmazonのDynamoとGoogleのBigTableを元にしたオープンソースの列指向分散データベース「Apache Cassandra」で、Facebook社がNonSQLデータベースで採用されているとの事。

SQLデータベース + memchachedの時代は終わった

いわゆる、NonSQLプログラミングです。 今回のmixiのトラブルで何か説得力のある言葉だと思った。

近年あまりにもデータが肥大化し、RDBのSQLで処理するには限界がきており、 Googleもここ数年KVS(Key Value Store)を推奨し技術提供している。

自分もRDBシステム開発している時に感じる部分があったり。 テーブル間のデータをSQLで複雑な処理させるより、プログラムや設計でカバーする方が圧倒的にパフォーマンスが良い事が多々ある。

また大規模サーバ負荷分散システムもここ数年で格安で構築できるようになっている。 [Apache]負荷分散、システム構成、memchached の勉強

Cassandraへの移行

とは言え、

既存のRDBデータをCassandraに移行するのはかなりの労力がいる

Twitterも現状MySQL + memchachedで運用しており、Cassandraに移行したいがなかなか踏み切れないらしい。

オイラも今後の新規開発に関しては、Cassandra等のKVS(Key Value Store)を視野に入れなきゃな？と思うのであった。

ちなみに、このサイトのシステムはPHP + PostgreSQL + Apacheです。 この規模じゃmemchachedすらいらないのですが（爆）、時間あったらこのサイトでもCassandraで試してみようと思います！