前編を執筆した寺本に引き続き、QCon San Francisco 2012の参加レポート後編を執筆させていただきます。
3日間で20セッション近く聞いたのですが、特に印象的だったものについて概要をレポートさせていただきます。
1. Architectural patterns for high availability
→ Netflixのアーキテクチャについて。
NetflixはWebでDVDのレンタルを提供するサービスを展開していて、
DVDはストリーミングでも視聴可能。
そのトラフィックは北米でトップ(モバイルのトラフィックは除く)。
下りトラフィックは、北米の下りトラフィックの33%を占める(ちなみにyoutubeは14.8%)。
そのシステムの中核はAWSとCassandraでした。
→ Pinterestのアーキテクチャについて。Pinterestは写真共有のSNSで、
サービス開始から2年でトラフィックが爆発的に伸びました。
スタートアップからのアーキテクチャの変遷についての話が聞けました。
Adrian Cockcroft, Director of architecture for the Cloud Systems team at Netflix
Netflixのアーキテクチャの話。ぶっちゃけNetflixのエンジニアブログの内容が多かったような気もするwあと、昨年度のQConでも似たような内容を発表していますｗ需要があって今年も登壇したのかな？
僕個人としては仕事でCassandraを触っている関係もあり、Cassandraを大規模に扱っているNetflix社のセッションはカンファレンス前から目星をつけていました。Cassandra on AWSの大規模運用の事例として面白かったです。実際の図やアーキは公開されているスライドを見ていただくとして、ここでは印象に残ったトピックについて書きます。
① AWSとCassandra
上でも述べた通り、Netflixのアーキテクチャの肝はCassandraとAWSという印象です。想像以上に大規模な構成でした。
US-west, US-east, EU, (＋おそらくアジア圏にも)、世界各地のAWSリージョンにインスタンスを展開。Cassandraクラスタは1リージョン内に3つのゾーンを跨いでLB(ELB)で負荷分散しており、規模は次の通り。
・500ノード以上のCassandraノード
・50のCassandraクラスタ
・もっとも大きいクラスタは72ノード
・1クラスタあたり250 K write/secを捌いている
数あるデータストアの中からCassandraを採択した理由は、高可用性であることに加え、会社としてJavaが得意だからとのことです。
高可用性を謳っているデータストアは他にもありますが、Javaで書かれているミドルウェアならいつでもハックできるから、ってことなんでしょうね。
② 自社製OSSで運用
これだけの規模のものをご丁寧に手運用しているわけではないですね。やはり。
自社製のOSSで運用管理を行っている模様です。
・Priam
https://github.com/Netflix/Priam
詳細はしっかり見てないのですが、PriamはCassandraのトークンの管理、障害ノードのオートリプレイス、S3へのバックアップ・・・and moreを行うツールのようです。
また、Netflixのgithubには他にも様々なツールやライブラリが公開されています。セッションではPriamの他に自社製のCassandraのJavaクライアント、Astyanaxも紹介していました。
③ SSD
SSDな環境(hi1.4xlargeインスタンス)にCassandraを移行しつつあるようです。SSDの効果は「Awesomeだ！」と言ってました。
実は俺も最近試しにSSDな環境(AWSではなくオンプレ）にCassandraを乗せてみたんですが、俺んトコはあんま効果なかった・・・。チューニングパラメータやHW構成が最適じゃないんだと思う。SSDの効果があるという事例は心強いので、もうちょい深堀してみたいです。
Yashwanth Nelapati, Cloud Balrog @ Pinterest& Marty Weiner, Cloud Ninja @ Pinterest
なぜ最終的にシンプルにしたかをちゃんと理由付けしながら話してくれたのが良かったです。
先程紹介したNetflixがオートシャードなCassandraクラスタをプラットフォームの肝としているのに対して、Pinterestは古典的なMySQLのシャーディングを用いているのが対比として面白い。
ちなみにエンジニアを募集しているようです。腕に覚えのある方は応募してみてはいかがでしょうか。サーバサイドはPython(Django)の模様。
以下、スライドより引用＋メモ。スモールスタート→複雑化→最終的にはシンプルな構成を成しています。
・ rackspace
・1 small web engine
・1 MySQL db
・1 Engineer
→ いわゆるWeb+DB構成のスモールスタート。
2011年
· Amazon EC2 + S3 + CloudFront
· 1 NGinX, 4 Web Engines
· 1 MySQL DB + 1 Read Slave
· 1 Task Queue + 2 Task Processors
· 1 MongoDB
· 2 Engineers
→ AWSへの移行。nginxやMongoDBなど使用しているプロダクトが増える。
· Amazon EC2 + S3 + CloudFront
· 2 NGinX, 16 Web Engines + 2 API Engines
· 5 Functionally Sharded MySQL DB + 9 read slaves
· 4 Cassandra Nodes
· 15 Membase Nodes (3 separate clusters)
· 8 Memcache Nodes
· 10 Redis Nodes
· 3 Task Routers + 4 Task Processors
· 4 Elastic Search Nodes
· 3 Mongo Clusters
· 3 Engineers
→ ノード数の増加につれてミドルウェアの種類も増える。
2012年1月
· Amazon EC2 + S3 + Akamai, ELB
· 90 Web Engines + 50 API Engines
· 66 MySQL DBs (m1.xlarge) + 1 slave each
· 59 Redis Instances
· 51 Memcache Instances
· 1 Redis Task Manager + 25 Task Processors
· Sharded Solr
· 6 Engineers
→ ここでMongoDB、Membase、Cassandra、Elastic searchなどが消える。nginxも消えてる。
この頃からELBを導入しているので、おそらくはnginxはL7プロキシとして使っていたのかな？
2012年10月
· Amazon EC2 + S3 + Edge Cast, Akamai, Level 3
· 180 Web Engines + 240 API Engines
· 80 MySQL DBs (cc2.8xlarge) + 1 slave each
· 110 Redis Instances
· 200 Memcache Instances
· 4 Redis Task Managers + 80 Task Processors
· Sharded Solr
· 40 Engineers
→ そして現在。Web+DB+cacheといったよくありがちな構成に落ち着く。
② なぜこの構成を選んだか
詳細はスライドを見ていただくとして、主に↓の理由のようです。
・AWS：数秒でインスタンスが作れる。ELBやroute53のような便利なマネージド・プロダクト。
・MySQL：枯れている。致命的なデータロストは発生しない。Perconaのツールが良い。
プロダクトの採択に確実性と安定性を重視しているのが見て取れます。
MySQLについて「致命的なデータロストは発生しない」ってことについては、ソレあったらデータストアとして失格だろ！ｗって思いましたがｗ
pinterestはMySQLのシャーディングでデータを管理しています。
その主な理由としては、
・(クラスタリングは)複雑である点(アーキテクチャが？)
・(クラスタリングは)アップグレード時が怖い
などを挙げています。
3. 全体的な感想
全体を通しての感想です。
① とにかく刺激になった
世界最大規模のトラフィックを捌いているWebサービス企業の中の人や、著名なハッカーの話を生で聴けたこともあって、とにかく刺激になった。
かの有名な「ブリュワーのCAP定理」の提唱者であるブリュワー氏本人(GoogleのVP、カリフォルニア大学バークレー校教授)が来てCAPとBASEの話をしてくれたり、SPDYの開発者がSPDYとHTTP2.0の話をしてくれたりね。
僕らはGoogleマップで場所を調べて、iPhoneで写真を撮り、TwitterやFacebookに投稿する、、、といった行動を当たり前のようにしています。少なくとも俺はそう。まさにカンファレンスで登壇した人とその仲間達が世界を作っているんだな、と思いました。
技術的な収穫も多かったです。プライベートの時間も使って日々技術情報をキャッチアップしているハズだったんだけど、やはり知らないことは多く、もっとウマく情報を集めて糧にしていかないとなー・・・って思った。
例えば↓のringmark。こんなのあるんだね。知らなかった。(ツール類については前編で寺本も挙げています。)
・ringmark
http://rng.io/
Facebookが公開しているHTML5の動作チェックツールです。アクセスするだけで、そのブラウザがHTML5にどこまで対応しているか調べることができる。
OSS(https://github.com/facebook/rng.io)なので自分で機能の拡張もできます。
あくまでもブラウザのHTML5への対応状況をチェックするだけです。
② 懇親会
初日の夜に懇親会がありました(といっても毎晩オープンスペースやホテルのレストランでお酒が振る舞われる懇親会っぽいものがありましたが)。
英語力が不安だったのですが、なんとか会話することができて良かったです。場所柄アジア系が珍しくないということもあり、他の参加者も「どんな会社で働いてるんだ？ところでちょっとトイレ行ってくるから俺の酒持っといてくんない？」といった具合でフランクに話しかけてきてくれました。海外の技術者と会話する良い機会だったので、本当はもっとガッツリ技術の話をしてみたかったのですが、英語力ががが・・・。英語ができなくて本当にもったいなかった。
③ メシ
カンファレンス中の3日間は朝から晩までほとんどをホテルで過ごし、朝昼晩メシ、お菓子、コーヒー、夜の酒代などをすべて無料で楽しめました(参加費に含まれている)。
しかしながら一日中カンヅメなのは息が詰まるので、夜はフィッシャーマンズワーフやらユニオンスクエアに繰り出して、いろいろ飲み食いしました。アメリカンサイズのハンバーガー、フィッシャーマンズワーフでカニ、クラブチャウダー(クラムチャウダー)、アメリカンイタリアン(？)やらいろいろ楽しめました。
カニ！↓
アメリカ料理ってあまり美味しい印象なかったんですけど、美味しいものは美味しいですｗクラムチャウダーとカニは本当にウマかったです！あとワインも！
でもまぁメシは総合的に見てやっぱ日本のメシが一番ウマいっす。メシウマ。