巨大サービスに共通するアーキテクチャの考え方
昔書いたhttp://mtl.recruit.co.jp/blog/2010/11/qconsf_1.htmlがデッドリンクになりそうだったので転載します。
Qcon SFに参加した目的は、Twitter, Facebook, eBay, LinkedIn, Amazon, NetFlix, Quantcastといった名だたる巨大サービスの中の人が各々のアーキテクチャに関して語るというかなりレアなTrackを聴くためでした。
実際、残念ながらZyngaはキャンセルとなってしまいましたが、上記のような多くのサイトのアーキテクチャーについて知ることが出来ました。
それぞれのアーキテクチャについては別の機会に譲るとして、多くのサービスの話を聞いた中で共通していたマインド、方針がありそうという発見をしましたので、それを紹介します。
キーワード
simple
シンプルな2,3tierな構成が基本で、ボトルネックが出てくるとそれを解消するようなスタンスに感じました。
例としてAmazon S3から引用してみます。
基本はこれ。2Tier。
ストレージがボトルネックになったら…
ストレージを増やす。今度はWEBサーバが高負荷になるので…
WEBサーバを増やす。
LBがヤバくなったら…
LBを増設。
ストレージを増やすだけじゃなく、パーティショニング。
遅くなるのでキャッシュを挟む。
Partition, replicate, index
どのサービスも、高速化、大量データ問題、高負荷への対処は基本はこれ。
"Partition, replicate, index. Many efficiency and scalability problems are solved the same way" by Nick Kallen/Twitter
Memcache
どのサービスでもキャッシュする＝memcacheという感じでした。キャッシュのしどころとしては、
- 揮発性データ
- 遅いread
- 遅いwrite
と、いうところでしょうか？
日本ではmemcacheの話題になるとデータ永続化の話になりTTなどのNoSQL(KVSという単語は聞きませんでした)にいきがちですが、こちらではキャッシュとNoSQLとは分けて考えられているようです。
上記の理由でのキャッシングの際も、データ保持はDBだったりします。
<h4サービスをし続けるための手段という意識
印象的だったのが、テクノロジーはサービスをし続ける、成長のための手段という意識を常にもってらしたこと。なので、打ち手が凄く手堅い。当たり前のことを、当たり前にやる、しかも泥臭くしっかりと。そんな印象です。
最後に余談ですが、QconSFの話の中でPerlは誰も話題にしてませんでした。MTLではPerl多いのですが…。JavaやRubyが多いコミュニティのようですね。Pythonもたまに出てくる。PHPはFacebookで使ってますが「なぜPHP使ってるの？」なんて質問が出る始末…。地域によって流行があるものですね。
