Agile Cat — in the cloud

Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!

Posted in .Selected, Big Data, Facebook by Agile Cat on January 3, 2011

Facebook in 20 Minutes: 2.7M Photos, 10.2M Comments, 4.6M Messages
Friday, December 31, 2010 at 7:37AM
http://highscalability.com/blog/2010/12/31/facebook-in-20-minutes-27m-photos-102m-comments-46m-messages.html 

_highscalability

このポストは、以下のリンクにある 『 A Snapshot of Facebook in 2010 』 のデータを元にしているようです。 そちらを見ると 『 Most Liked Celebrities 』もあり、『 Lady Gaga : 24,712,169 people like 』 というデータなども参照できます。 ーーー A.C.

ーーーーー

To celebrate the new year Facebook has shared the results of a little end of the year introspection. It has been a fecund year for Facebook:

Facebook は新年を祝うために、その内部情報の一部を提供してくれた。 2010 年は、Facebook にとって、実り多き年だったことが分かる:

  • 43,869,800 changed their status to single
  • 3,025,791 changed their status to “it’s complicated”
  • 28,460,516 changed their status to in a relationship
  • 5,974,574 changed their status to engaged
  • 36,774,801 changes their status to married

5038714561_34183a0639_m

If these numbers are simply to large to grasp, it doesn’t get any better when you look at happens in a mere 20 minutes:

上記の数字が、あまりにも大きすぎて把握しにくい場合には、Facebook の 20分間に起こる、以下の事象に注目するほうが良いだろう:

  • Shared links: 1,000,000
  • Tagged photos: 1,323,000
  • Event invites sent out: 1,484,000
  • Wall Posts: 1,587,000
  • Status updates: 1,851,000
  • Friend requests accepted: 1,972,000
  • Photos uploaded: 2,716,000
  • Comments: 10,208,000
  • Message: 4,632,000

If you want to see how Facebook supports these huge numbers take a look at a few posts.

このように膨大なスケールを、どのようにして Facebook が処理しているのか、その方式を知りたい場合には、これまでのポストを参照して欲しい。

One wonders what the new year will bring?

新しい年になり、いったい何が起こるのだろうか?

Related Articles

ーーーーー

ほんとに、今年は何を見せてくれるのでしょうかと、誰もが期待していまう Facebook ですねぇ ~~~ __AC Stamp 2

ーーーーー

Go To Agile_Cat Mobile

ーーーーー

<関連>
2010 年の ビジター数(全米)で、Facebook が Google を追い抜く!
Facebook のスケール感覚に驚愕!
Facebook の HDFS クラスターは 21 PB !!!
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook における 1300万/秒 クエリーの秘密
Facebook の データセンター戦略に関する FAQ

Tagged with: , ,

Facebook 2010 総集編 Agile_Cat 版

Posted in Facebook by Agile Cat on December 29, 2010

怒涛の 1年でした・・・  スゴイ!

image

Facebook の 1年について、何を書くにしても、その最後には 『 スゴイ 』にたどり着いてしまうので、やはり 『 スゴイ 』 のだと思いま :)   とはいえ、そこには いくつかの切り口があるので、それだけでも整理していきたいと思います。

まず、指摘したいのは、そのスケールを達成するために磨き抜いてきた運用術です。 そこには、新旧を取り混ぜたソフトウェアから、最新データセンターにいたるまで、ありとあらゆるノウハウが詰め込まれています。 開発力だけではなく、運用力の重要さを見せつけた Facebook に、まず、『 スゴイ』 を1つ差し上げましょう。

続いて、何時でも、何処でも、素早くという、モバイル性とリアルタイム性をキチッと追求しているところを指摘したいです。 例の、Google との大立ち回りのときですが、新しいメッセージング・システムを説明する際に、ガールフレンドの弟との会話を引用していましたが、若い世代の視点に合わせて真摯に取り組んでいる姿勢にも、『スゴイ』を差し上げましょう。

そして、これだけの企業規模を有しながら、株式の公開をギリギリまで後ろへ引っ張ることで、強力なライバルたちと戦うときに、フリーハンドで臨める領域をシッカリと確保している戦略眼にも、『スゴイ』を差し上げましょう。

・・・という訳で、放っておくと、いつまでたっても前口上が終わりませんので、これくらいにしま~す。 ーーー A.C.

ーーーーー

image January 21, 2010
プライバシーとは? by Nicholas Carr
もちろん、プライバシーについて無頓着なコメントした、最初の Silicon Valley の CEO が Schmidt というわけではない。話は 1999年に遡るが、当時の Schmidt の上司である Sun Microsystems CEO の Scott McNealy は、「とにかく、プライバシーなんてないんだ。 それを乗り越えろ」と宣言している。 そして、まさに今月、その考えは、Web の最も面白い哲学の王様である、Facebook CEO の Mark Zuckerberg により繰り返された。
image3[1]_thumb[1] April 1, 2010
環境保護団体グリーンピースから、クラウド業界へ提言
昨日のことですが、グリーンピースから 「 Make IT Green」 というタイトルのドキュメントが公開されました。 Agile_Cat のお気に入りである、
Data Center Knowledge や、Nicholas Carr の Rough Type などで取り上げられていますが、クラウドを敵視するものではなく、コントリビューションを求めるものと理解してよさそうです。
image6_thumb[1] April 22, 2010
Windows Azure と Facebook の連携が始まった!
2010年4月19日に Washington, D.C. で開催された
Politics Online Conference で、私たちは Windows Azure 上にホストされ、グループ間の意見交換を促進/調整/収束させるための、TownHall という新しいコミュニケーション・プラットフォームをアナウンスした。   今日の Microsoft on the Issues blog で確認できるように、TownHall は、アメリカ国民が重要な関心事についてディスカッションする際に必要とされる、リッチなオンライン・ソーシャル・エクスペリエンスを、政治家や行政当局に提供するための理想的なツールだ。
image9_thumb[1] April 22, 2010
Office 2010 は、Docs.com で Facebook とコラボ?
Facebook の
F8 developer conference で、Office 2010 に関する Microsoft と Facebook の提携が発表されました。 それによると、 Docs.com という新しいサイトがオープンされ、Facebook を介して Office 2010 ドキュメントのオンライン化や、グループによる共有が促進されるとのことです。 このテクノロジーは FUSE (Future Social Experiences) Labs により開発されたものであり、その他にも、Twitter や Bing との連携などが研究されているとのことです。
image12_thumb[1] April 23, 2010
Greenpeace : Oregon のデータセンターをめぐって対峙
環境保護団体である Greenpeace International は、 Facebook が計画している Oregon のデータセンターについて再考するべきだと発言している。そして、化石燃料から大半のパワーを生み出す、公共的な電力会社に換えて、完全に再生可能なエネルギーで稼働する、新しいファシリティが要求するグループに参観するように、Facebook ユーザーに促している。
image15_thumb April 25, 2010
ロシアのハッカー Kirllos が、150万人分のアカウントを売りに出すという
シアのハッカーである Kirllos が入手したという、150万人分のログオン証明が本物だったら、どのようにFacebook は対応するのだろう?  このハッカーは、アンダー・グラウンドなフォーラムで、これらのログオン証明を販売すると申し出たことでマークされている。 イメージは、F-Secure の CRO である Mikko Hyponnen が、Twitter にポストしたものだ(この人をフォローするのは面白いかも?)。
image18_thumb[1] May 8, 2010
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか?
Advertising Age によると、これから出てくる Facebook のロケーション・プラットフォームを、最初に使うマーケッターは McDonald’s になるらしい。 ユーザーは 「This Month 」 に行くような簡単な操作で、Facebook のステータス・アップデートを使ってロケーションにチェックインした後に、そのロケーションにヒモ付けされた、お勧め製品を確認することになると、 AdAge はレポートしている。 伝えられるところ、McDonald’s は、大規模メディアでの買物のに参加する、最初のブランドになるという。
image21_thumb June 15, 2010
Facebook のスケール感覚に驚愕!
Facebook のエンジニアリング部門で Director を務めるAditya Agarwal が、Facebook のアーキテクチャをカバーする、その素晴らしいスケールについて話してくれた。しかし、その内容というと、同社の文化的に優れた部分を維持することで、組織のスケールを調整する方式に多くの時間が割かれた。
image24_thumb[1] June 20, 2010
Facebook で Office ドキュメントを共有する Docs.com
Facebook の
F8 デベロッパカー・ンファレンス(4月21日)で発表された Docs.comですが、すでにベータが使えるようになっています。このアプリケーションは、Microsoft の FUSE Labs が開発したものであり、Microsoft Officeのドキュメントの共有を実現していきます。 これらのドキュメントは、Web とデスクトップの間を行き来できて、Docs.com を Facebook のフレンドと共有することも可能とのことです。
image27_thumb[1] June 25, 2010
Facebook の HDFS クラスターは 21 PB !!!
The Datawarehouse Hadoop cluster at Facebook has become the largest known Hadoop storage cluster in the world. Here are some of the details about this single HDFS cluster:

  • 21 PB of storage in a single HDFS cluster
  • 2000 machines
  • 12 TB per machine (a few machines have 24 TB each)
  • 1200 machines with 8 cores each + 800 machines with 16 cores each
  • 32 GB of RAM per machine
  • 15 map-reduce tasks per machine
image30_thumb[1] June 30, 2010
わずか四半期の間に、サーバー数が倍増した Facebook の事情
これは、先週に開催された Velocity 2010 カンファレンスで、Facebook の Tom Cook がプレゼンテーションで用いたものであり、同社のサーバー・フットプリントの成長を描いている。 このグラフは、4億人のユーザーをサポートする Facebook の、貪欲なニーズを例証するようデザインされてはいるが、実際のサーバー数を明示するような情報は含んでいない。
image45_thumb July 3, 2010
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook の運用スケールにおいて、 Web コンテントをサービスするための、数多くの伝統的なアプローチは失敗し、また、現実的ではなくなっている。 Facebook のエンジニアによるチャレンジは、5億人に近いアクティブ・ユーザーをハンドリングしながら、このサイトを維持して、順調に走らせることにある。 この記事では、その目標を達成するために、Facebook が要しているソフトウェアとテクニックを見ていく。
image39_thumb[1] July 9, 2010
Facebook、Twitter、Digg などでの Cassandra の状況について
おそらく、すべての人々が認識しているように、Cassandra は Facebook において Inbox サーチのために作り出され、その後に ASF と Apache ライセンスのもとでオープンソース化されている。 そして、
Twitter や、Digg、Reddit などの、いくつかの企業が利用を開始しているが、Facebook からの情報は聞こえてこない。
image42_thumb[1] July 17, 2010
リコール騒動の iPhone 4 から エラそう Zuckerberg まで – LTW
その一方では、Facebbok の Zuckerberg さんが、イギリスのキャメロン首相との電話会議で 『ユーガイズ 』を連発したとの、これまた 発言に関するトピックが注目を集めているようです。 ちなみに、わが 英辞郎 によると、You Guys の意味は以下のようになります。
image45_thumb August 23, 2010
Facebook を 1.8 倍速に、WordPress を 2.7 倍速にする、HipHop とは ?
私たちが
HipHop をリリースしてから 6ヶ月が経過したが、その進歩におけるアップデートを共有したいと思う。 この 2月には 693,613 行のソースコードをリリースしたが、それにより、Facebook における CPU の使用量が、平均で 50% ほど低減した。 その後、このチームは、HipHop を 1.8 倍ほど高速化することに成功し、また、それらのコードは、すべてオープンソース化されている。
image48_thumb August 24, 2010
ARM サーバー DC の 一番手が Facebook になるというウワサ
メジャーなプライヤーたちが、そのデータセンターを x86 ベース PC から、 ARM アーキテクチャに移行していくというウワサが、長いこと囁かれていた。 そのマーケットに最初に飛び込んでいくのは、ほかでもない Facebook になるのかもしれない。
image51_thumb August 26, 2010
Facebook の幹部が、ARM サーバーのウワサを否定
5 億人以上のユーザーを有する Facebook の爆発的な成長は、少なくとも
60,000 台のサーバー群をデータセンターに配置し、このソーシャル・ネットワーク企業を、サーバー・ハードウェアの大口顧客にしてしまった。Facebook の Technical Operations VP である Jonathan Heiliger は、Facebook のような巨大インフラにおけるニーズに対して、製品を適合させていくサーバー・ベンダーの能力に対して批判的である
image54_thumb[1] September 2, 2010
Facebook クレジット・カードが、あなたのフトコロに忍び寄る
今日、このチェーンが発表したように、ソーシャル・ネットワーク・バーチャル通貨の最初のターゲットは、Facebook Credits を取り扱う、現実世界の小売り業者になるのだろう。 このバーチャル通貨は 9月 5日に、Facebook Credit のギフト・カードという形態で、現実の世界にデビューする。そして、$15、$25、$50 という単位で、1,750 店の小売業者で利用できる。その中でも $15 バージョンは、小売り業者を対象に作られている。
image57_thumb September 11, 2010
Facebook は簡単には株式公開しない、、、Zuckerberg の回答
Facebook には、Facebook Question というベータ・サービスがあるらしく、そこで Mark Zuckerberg が株式公開について、その考え方を披露しているようです。その全文と対訳は以下のとおりですが、ソーシャル・ネットワークという領域で勝ち抜いていくためには、資金力ではない何もものかが、一番に重視されているのでしょうね。 それと、企業としての成功は、大きな売上と高い利益率を上げること、、、という、これまでの前提とは違うところに注目しているのだろうと、 Zuckerberg の言葉から感じられるものがあります。
image60_thumb[1] September 27, 2010
Facebook は、絶対にモバイル・フォンを開発しているはずだ
アメリカでは先週末に、Facebook と INQ による新しいモバイル・フォンに関するニュースが流れたようですが、その数日前に GIGAOM に掲載されたポストを抄訳してみました。 一言でいえば、Facebook アドレス・ブックが、そのまま携帯アドレス・ブックになってしまうという、きわめて斬新で合理的なアイデアが実現されるようです。
image63_thumb[1] September 28, 2010
Facebook Phone について、知っておくべき全てを GIGAOM が解説
最近の、すべてのテクノロジー・ニュースにおいて、私が最も興味を持ったのは、Facebook フォンの存在である。 その理由は、ずいぶんと前から、Facebook をベースにした電話を開発するというプロジェクトを知っていたが、それを複数の情報源から確認できなかったところにある。 それが、今朝になって、同社が INQ Mobile と共同で、電話を開発しているというニュースとなって流れてきた。
image66_thumb[1] September 30, 2010
Facebook と Skype のアライアンスが、Google の支配に風穴をあける
Facebook と Skype の提携を報じるレポートによると、Skype の Voice/Video チャット機能が、Facebook のソーシャル・ネットワーク・プラットフォームに統合されることになる。 このアライアンスは、Google に対するチャレンジであり、また、ビジネス・ユーザーにメリットを与え、Facebook と Skype の両社に利益をもたらすものになる。
image69_thumb[1] October 1, 2010
Facebook の データセンター戦略に関する FAQ
今週は、さながら Facebook Week になってしまった Agile_Cat ですが、さらに もう1つということで、同社のデータセンター戦略を追ってみました。 その Oregon での計画が発表されて以来、Greepeace とのイザコザがあり、また。ARM が実装されるのではないかというウワサまで流れ、さすがにビックネームと関心しましたが、このお騒がせ巨大データセンターも、そろそろ完成のようです。
image72_thumb[1] October 1, 2010
Google から Facebook へと、すでに覇権は移行しているのか?
このところ、Facebbok の攻勢に対して防戦一方という感じの Google ですが、すでにトラフィック数で Facebook が Google に優っているという説があり、ちょっとその辺りを調べてみました。
この種の調査結果を公表しているサイトとして、いつも Agile_Cat が利用するのは、comScore と Hitwise なのですが、このクラフは、その Hitwise からのものです。
image75_thumb[1] October 6, 2010
Facebook fan page を作ってみました
一言でいうと、Facebook ユーザーであれば、誰もがコメントできる掲示板のようなものかと思っています。 とりあえず、ブログ・ポストのまとめページみないなカタチにしましたので、皆さんへ お知らせしたいと思います。もし、よろしければ、[いいね] もしくは [Like]  ボタンをクリックしてみて下さい。さらに、よろしければ、コメントなどを、お願い致します。
image78_thumb[1] October 15, 2010
Facebook データセンターにおける冷却の見直しと その効果
Facebook が取り組んでいる、さらにエネルギー効率に優れたデータセンターの構築は、Oregon の新しい設備に限定されるわけではない。 最近のことだが、このソーシャル ・ネットワーク企業は、Santa Clara, Calif の既存データセンターの 1つで、そこに設置されている冷却システムを再編成した。そして、年間で $229,000 の電気使用料を節約し、Silicon Valley Power から $294,761 を払戻させた。
image81_thumb[1] October 23, 2010
Facebook のトラフィックが急増 – 4ヶ月で 14% の伸び
おなじみの comScore ですが、Media Metrix Ranks Top 50 U.S. Web Properties for September 2010 というタイトルのレポートが出ていたので、同じく May 2010 のレポートと比較してみました。 注目の Top-5 ですが、その順位には変動のないものの、4位の Facebook の急伸ぶりが目を引きます。 Yahoo! も約 6% という伸びを示していますが、Facebook の場合は約 14% という成長率になっています。
image84_thumb[1] October 24, 2010
Facebook 映画 『 The Social Network 』 の感想ブログ
とても面白い、映画『 The Social Network 』の感想が、吉平健治さんのブログ 『 珪素の唇 』に掲載されているので、ご紹介したいと思います。 吉平さんはアメリカ在住の Twitter 仲間でして、お会いしたことはないのですが、この映画に関するポストを教えていただくことになりました。 まず拝見して、Mark Zuckerberg が学生時代を過ごした東海岸にお住まいで、しかも
難しそうな本を何冊も出されている方なのだと知りました。
image87_thumb[1] November 7, 2010
ここまで来たか! 女王陛下の Facebook
LONDON – これこそ、究極のソーシャル・ネットワークであろう。イギリスの Queen Elizabeth II は、自身の勤めとして Facebook オフィシャル・ ページを公開し、それを日々更新していくと、この日曜日にイギリス皇室は発言した。
84歳になるイギリスの君主は、このサイトにおいて月曜日から、そのビデオ、写真、ニュースを提供しく。もしろん、William、Harry 両王子を含む、イギリス王室も一緒である。
image90_thumb[1] November 10, 2010
Heroku は、Facebook のオフィシャル・アプリケーションになれるのか?
クラウド・コンピューティングとソーシャル・ネットワーキングを正式に統合するチャンスを見出すために、Ruby にフォーカスする PaaS スタートアップである Heroku は、顧客による Facebook アプリケーションの開発と立ち上げを、自身のHeroku プラットフォーム上で支援するためのプログラムを作成した。 この、目的に見合った名前の Facebook App Package にはハウツーガイドと、急成長する Heroku のアドオン・マーケットから取り込む必要のある標準的な機能のセットが含まれる。
image93_thumb[1] November 12, 2010
私たちはオープンだと Facebook は言い、Google の措置に反撃するが
誰がユーザー・コンタクト情報をコントロールすべきかという
、Facebook と Google に発生した報復合戦は、別のレベルへとエスカレートしてしまった。Facebook のプラットフォーム・チームのエンジニアが、この騒ぎに関するコメントをブログにポストしたところによると、Facebook がもたらした競合上の脅威により、Google はデータの可搬性に関するポリシーを変更したと非難されている
image96_thumb[1] November 12, 2010
いずれにせよ、Facebook は Gmail データをインポートする
All Facebook
によれば、ソーシャル・ネットワーキング・サイトが、検索サイトのデータを取り込むめないようにしようとする Google の試みを、Facebook は無視することに決めたようだ。 Palo Alto(FB)は Mountain View(G)の制約に対して、何らかの方策を見いだし、また、Google ユーザーが使用する、データのダウンロード機能を、別のかたちで利用しようとしている。 Facebook は、自身の新規ユーザーに対して、ダイレクトなダウンロード・リンクを提供し、その Google ファイルを Facebook にアップロードするように導く。
image99_thumb[1] November 13, 2010
Facebook は Google キラーを発表するのか?
Facebook は 11月15日の月曜日に、限定された招待客のためのイベントを開催する。 そのイベントと、そこでの発表に関する憶測とウワサが、すでに流れ始めている。Google は、Facebook キラーである 『 Google Me 』が、近い将来に提供されるというウワサを否定したが、今回のイベントで Facebook は、その対抗策である Gmail キラーを発表するかもしれないと示唆している。
image102_thumb November 14, 2010
サウジアラビアが、道徳的な理由から Facebook をブロック
RIYADH, Saudi Arabia – Saudi Arabia の通信委員会は、Facebook が同王国の保守的な価値観に合致しないという観点から、この人気のソーシャル・ネットワーキング Web サイトをブロックしたと発言した。
image105_thumb[1] November 15, 2010
これが Facabook の Mail Server、Project Titan なのか?
今週 、15 日に、Facebook は PROJECT TITAN イベントを開催する。 このプロジェクトに関して、何も明らかにされていないが、Facebook 側の動きが見えはじめてきた。
これは、つい先程に確認できた、Facebook の Mail Server である。
image108_thumb[1] November 15, 2010
Facebook の Social Inbox は、単なる Email ではない!
今朝の発表において、新しい電子メール・サービスの開始を期待されていた Facebook だが、
それよりはずっと幅広い構想を持っていることが分かった。同社の CEO である Mark Zuckerberg が、“social inbox”  として発表したものは、人々がモバイル・フォンで利用する全てのコミュニケーションに対応したものであり、電子メール/SMS/インスタント・メッセージ/Facebook チャット・メッセージを取り込んだものとなる。
image111_thumb[1] November 16, 2010
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
今日の Tech 系 Web サイトは、電子メール/メッセージ/チャット/SMS をシームレスに統合する、
新しくデザインされた Facebook のメッセージ・システムの発表で沸き返っている。  ころから分かることは、この新しいメッセージ・プロダクトが、新しいバックエンドをも必要としていることだ。そのための、メッセージ・インフラストラクチャのデザインを、ゼロから再構成する機会を、Facebook エンジニアリング・チームは得たことになる。
image November 18, 2010
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook が導入する新しい Social Inbox が、電子メールおよび、IM、SMS、テキスト・メッセージ、Facebook オン・サイト・メッセージを統合するという記事を、どこかのメディアで読んでいると思う。 全般的に見て、Facebook は 1カ月に、1350億以上のメッセージをストアする必要がある。それら全てを、何処にストアするのであろうか?
image117_thumb[1] November 21, 2010
Facebook は オープン性を重視する – Zuckerberg
今日の Web 2.0 Summit で CEO の Mark Zuckerberg は、ユーザーが Facebook に求めるのは、彼らのデータを更にコントロールすることだと発言したが、同社は更なるオープン化へと心を傾けている。 そして、「こうした緊張を調整することはチャレンジングなことだ」とも、発言している。
image November 28, 2010
Facebook における 1300万/秒 クエリーの秘密
Facebook は
MySQL Tech Talk において、同社におけるMySQL への取り組みを詳述したが、その中でも微妙で興味深いポイントは、リクエスト・レスポンス・タイムのバラつきを制御することへの注力であり、毎秒のクエリー数を最大にすることが関心事ではないことだった。
image123_thumb[1] December 2, 2010
北米 ⇒ 欧州 ⇒ アジア へと飛び火している Facebook 人気
昨日の 2010 Web 2.0 Summit 情報に続いて、またもや Practical Quant から、今日は Facebook 人気に関するデータをお届けします。 以下のグラフを見てのとおりですが、2008年5月~2010年11月という約2年半の期間における、アクティブ Facebook User 数の推移が分かります。 意外にも、北米と欧州では低落傾向にあり、その分をアジアが支えているという内訳のようですね。
image126_thumb[1] December 20, 2010
Facebook は、敗者である Microsoft と手を組むと言うが
それは、思いつきで Microsoft のポジションを位置づける、マーケティングの策略なのだろうか? そして、好戦的な Bing サーチ・エンジンを利用して、Google をジリジリと追い上げるつもりなのだろうか?  Bill Gates が創設した、このソフトウェア会社を 『 敗者 』と呼ぶのは、彼が初めてではないのだが ・・・
image129_thumb[1] December 21, 2010
Facebook vs. Twitter インフォグラフを比較する
Twitter は Facebook に対して、人口統計とオンライン・アクティビティという切り口では匹敵するのか? オンライン・マーケティング・エージェンシーである Digital Surgeons が、Facebook と Twitter にユーザー分布を比較するための
インフォグラフを組み立てた
image132_thumb[1] December 22, 2010
Facebook のようなエンタープライズ・ソフトウェアを作りたい
Facebook というツールは、使いやすいだけではなく。堅牢でもある。 老人であって、数分もあれば孫たちの写真を取り出すことが可能であり、また、ティーンエージャーたちは、サイト内でソーシャル・ライフを満喫できる。そして、 Facebook は無料である。 そこで考えるのが、Facebook のようなエンタープライズ・ソフトウェアが存在しない理由である。 不思議だと思わないか?
image135_thumb[1] December 25, 2010
2010 年をチャートで見る – これも Facebook 活用術?
最初は、単なるアルバムを作ろうと思って始めた作業ですが、、、その途中で、、、よくよく考えると、それそれのチャートにコメント書くよりも、WordPress 側の URL を貼ったほうが簡単なのだと気づきました。 まぁ、アルバムというと、一般には情報のエンドポイントなのですが、コメントに URL を抱えることで、あたり前のことですが、次のエンドポイントを指定できます。つまり、WordPress 側を指し返してあげれば、、、、 :) これは、とても素晴らしい :) というわけで、こうしてタナボタ・ポストまで思いついてしまった次第です。
image138_thumb[1] December 26, 2010
Facebook が世界第 3位に – トラフィック数で Yahoo を逆転
それは、単に時間の問題に過ぎず、また、現実のものとなった。 最近の Comscore のデータによると、Facebook はトラフィック数で Yahoo を抜き。世界中で 3番目に大きな Web サイトになった。2010年11月だが、 Yahoo の 6億3000万人に対して、Facebook は 6億4800万人のビジターを得ることで、その位置関係が逆転したが、印象的なのは、その全体的な傾向である。
image1_thumb[1] December 27, 2010
ビデオ・トラフィックでも、Facebook が Yahoo を抜いて 2位に
オンライン・ビデオの話になると、Google という支配的なプレーヤーが登場してくる。 この検索の巨人は、Facebook/Yahoo/Bing/Twitter を合計した以上のビデオ・トラフィックを配信している。 しかし、もう 1人のプレーヤーが、そのトラフィックを急速に伸ばしている。 それは、Facebook だ。

ーーーーー

<追加情報>
2010 年の ビジター数(全米)で、Facebook が Google を追い抜く!

ーーーーー

SnapShots 2010 by Agile_Cat

ーーーーー

いつの頃からでしょうか、コンピューティングに無限の可能性を見いだせなくなったのは。 しかし、ソーシャル・ネットワークの台頭が、そんな閉塞的な状況を一変させました。 なぜなら、無限の可能性を持つ人々を結びつけていく、無限のコンピューティングとネットワーキングが、そこに有るからです。

Facebook に限ったことではなく、Twitter や Mixi や、、、さまざまなソーシャル・ネットワークが、これからの IT をドライブしていく原動力になるのでしょう。 そんな現実が明らかになったのが、2010年という年だったのかと思えてきます。 ーーー A.C.

Facebook のスケール感覚に驚愕! _2

Posted in Businesses, Facebook, NoSQL by Agile Cat on June 16, 2010

The Four Meta Secrets of Scaling at Facebook
DateThursday, June 10, 2010 at 10:42PM

http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+HighScalability+%28High+Scalability%29&utm_content=Google+Feedfetcher

image

image

The Four Scaling Meta Secrets

1. Scaling takes Iteration. Solutions of often work in the beginning, but you’ll have to modify them as you go on. What works in year one may not work later. PHP, for example, is simple to use at first, but is not a good choice when you have 10s of thousands of web servers.

1. Scaling takes Iteration. 初期において機能するソリューションであても、先へ進むにつれて修正が必要になる。 最初の 1年間は機能しても、その後には機能しなくなるかもしれない。 たとえば、 PHP を使い始めることは簡単でも、1 万台ものWeb サーバーを使用するのでれば、適した選択とはいえない。

Another example is photos. They currently serve 1.2 million photos a second. The first generation was build it the easy way. Don’t worry about scaling that much. Focus on getting the functionality right. Uploader stored the file in NFS and the meta-data was stored in MySQL. It worked for the first 3 months and caused a lot of sleepless nights. He would still do it the same way today. Time to market was the biggest competitive advantage they had. Having the feature was more important than making sure it was a fully thought out scalable solution.

もう1つの例として写真が挙げられる。 現時点において、1秒あたり 120万枚の写真が提供される。 第 1世代の Facebook では、そのための機能を安易な方式で構築していた。 スケーリングについて、頭を悩まさなくてもよい。 その機能が正確に機能することにフォーカスする。 アップローダーによりファイルは NFS にストアされ、メタデータは MySQL にストアされる。 この方式は、最初 の3カ月間は機能したが、その後は眠れぬ夜をもたらした。 いまもなお、同じ方式で、同じことを行っているだろう。 サービスを提供するまでに費やす時間は、彼らが共同していく上で最大のアドバンテージだった。 機能を持つことが、熟考されたスケーラブル・ソリューションを確認するよりも、いっそう重要な事柄だった。

The second phase was optimization. Are there different access patterns that can be optimized for? It turns out smaller images are access more frequently so those became cached. They also started using a CDN. NFS was not designed to store 80 billion small files, so all meta-data wouldn’t fit in memory, so lookups would take 2 or 3 disk IOs which was slow.

2番目のフェーズは、最適化だった。 そのために最適化できる、別のアクセス・パターンはあるのだろうか? 比較的に小さなイメージが頻繁にアクセスされりことが分かり、それらがキャッシュされるようになった。 さらに、CDN も使い始めた。 NFS は、800億もの小さなファイルをストアするようはデザインされていない。 したがって、すべてのメタデータは、イン・メモリという考え方にはフィットせず、また、2~3 のディスク IO が参照され、結果として遅くなる。

The third generation is an overlay system that creates a file that is a blob stored in the file system. Images are stored in the blob and you know the offset of the photo in the blob. One IO per photo.

第 3世代では、対象となるファイル・システムにストアされる、ブロブであるファイルを作成するための、オーバーレイ・システムが採用された。 イメージはブロブにストアされ、そのブロブ内で写真のオフセットが行われる。 つまり、1枚の写真ごとの IO という考え方だ。

2. Don’t Over Design. Just use what you need to use as you scale your system out. Figure out where you need to iterate on a solution, optimize something, or completely build a part of the stack yourself. They spent a lot of time trying to optimize PHP, they ended up writing HipHop, a code transformer to convert PHP into C++. It generated a massive amount of memory and CPU savings. You don’t have to do this on day one, but you may have to. Focus on the product first before you write an entire new language.

2. Don’t Over Design. システムをスケールアウトするに、使用する必要のものを、的確に使用すべきだ。 ソリューションにおいて反復すべき場所や、何らかの最適化を明確にし、開発者自身が意識すべきパートを完全に構築する。 ある開発者のグループは、PHP の最適化に多くの時間を費やし、別のグループは HipHop の記述を受け持ち、コードは PHP から C++ に変換されていく。 それにより、大量のメモリと CPU パワーが温存される。 このような方式を初日から実施する必要はなくても、いずれは行わなければならないだろう。 すべてのパートを新しい言語で記述する前に、つまり最初に行うべきことは、プロダクトに焦点を合わせることだ。

3. Choose the right tool for the job, but realize that your choice comes with overhead. If you really need to use Python then go ahead and do so, we’ll try to help you succeed. Realize with that choice there is overhead, usually across deployment, monitoring, ops, and so on.

3. Choose the right tool for the job, but realize that your choice comes with overhead. ほんとに Python を使う必要があるなら、そうすべきであり、また。成功へと導くように支援する。一般的にみて、ディプロイメント/モニタリング/オペレーションの至るところで、その選択からオーバーヘッドが生じることを自覚すべきだ。

If you choose to use a services architecture you’ll have to build most of the backend yourself and that often takes quite a bit of time. With the LAMP stack you get a lot for free. Once you move away for the LAMP stack how do things like service  configuration and monitoring is up to you. As you go deeper into the services approach you have to reinvent the wheel.

なんらかのサービス・アーキテクチャを使う場合には、その大半を自身で構築する必要性が生じ、また、一般的には、そのために大量の時間が消費される。 しかし、LAMP スタックを用いることで、多くのものを自由に手にすることができる。ただし、LAMP スタックから離れた途端に、サービスのコンフィグレーションやモニタリングといった処理は、独自のものとなる。 そして、そのサービスへのアプローチが深くなるに連れて、分かり切ったことをやり直す必要性が出てくる。

4. Get the culture right. Move Fast – break things. Huge Impact – small teams. Be bold – innovate. Build an environment internally which promotes building the right thing first and then fixing as needed, not worrying about innovating, not worrying about breaking things,  thinking big, thinking what is the next thing you need to build after the building the first thing. You can get the code right, you can get the products right, but you need to get the culture right first. If you don’t get the culture right then your company won’t scale.

4. Get the culture right. Move Fast – break things. Huge Impact – small teams. Be bold – innovate.適正な事柄の構築を促す、内部的な環境を作成し、必要に応じてそれらを修正していく。そこでは、革新について気にする必要はなく、詳細を気にすることもない。 ただし、規模について考察し、最初の構築の後に検討すべき、次の事柄について考えるべきである。 たしかに、コードを得ることも、プロダクトを得ることもできるが、最初に得るべきは文化だ。 それを的確に行えないなら、Facebook 自身がスケールできなくなる。 それを的確に行えないなら、Facebook 自身がスケールできなくなる。

Move fast. Get to market first. It’s OK if you break things. For example, they now run their entire web tier on HipHop which was developed by three people. Very risky, it brings the site down regularly (out of memory, infinite loops), but there’s a big payoff as they figure out how to make it work. The alternative would be to have 3 month testing process for every change, it slows down everything. This is a particular instance, but the most important thing is the culture, getting people to believe that the most important thing is how quickly they can move.

Move fast. 最初に必要とされるのは、マーケットへのリーチである。 そこで用いた手法を分析できるなら、何の問題も生じない。 たとえば、3人の人員により開発された HipHop の上で、全体的な Web ティアを実行するとする。 一般的に、このような環境はサイトのダウン(メモリ不足や無限のループ)を伴うため、きわめてリスキーであるが、それらの開発者たちに、サービスがダウンする原因を理解させるという、大きな見返りがある。すべての更新に対して、3カ月間のテストを実施するような選択肢は、すべての速度を低下させる。 それは特定の事例を示すが、最も重要なことは、それらの開発者たちに、迅速に行動できるのだと信じさせる文化である。

Huge Impact. Small teams can do great things. Search, photos, chat, HipHop were all small teams doing major features. Get the right set of people, empower them, and let them work. 

Huge Impact. 小さなチームでも、素晴らしい結果を残せる。 サーチ/写真/チャット/HipHop などの全てが、小さなチームによる偉大な成果である。 適切なチームを構成し、彼らに権限を与え、上手く機能させる。

Be bold. Don’t be afraid of failure. It’s OK to try things and fail. It’s crazy to say let’s make a new JVM, but the payoff is amazing when it works.

Be bold. 失敗を恐れてはならない。 トライして、失敗することに、何の問題もない。 新しい JVM を作ろうとすることは、正気の沙汰とは思えないが、それが機能するなら、大きな成果を残すことになる。

There are no product owners at Facebook. Everyone owns the product. Give people ownership of what they work on. If you give ownership to one person then the chances are nobody else will contribute to pushing it to the next level. Ideas come from users and people internally. If you can’t push responsibility down and you isolate the number of people who feel they are real owners, then the only people you’ll be able to motivate are the people who think they are the real owners. So instead why not distribute that entire responsibility?

Facebook には、特定のプロダクト・オーナーがいない。 言い換えれば、全員がプロダクト・オーナーである。 それらの人々が働きやすくなるような、オーナーシップを与えるべきである。 誰かにオーナーシップを与えれば、他の誰もが持ち得ないチャンスが生まれ、プロダクトを次のレベルへ押し上げるコントリビューションが生じる。 アイデアは、ユーザーと内部スタッフから提供される。 責任の移譲が不可能なために、オーナーとしての感覚を持つ多くの人々を孤立させていまう場合もある。 そうなると、あなた自身がモチベーションを持たせられる、明確な自覚を持つ人だけに、オーナーは限定されてしまう。 つまり、何ゆえに、すべての責任を分散しないのかという疑問が残る。

Isolate the part of the culture that you value and want to preserve. It doesn’t happen automatically. Facebook organizes hackathons, the point of which is to show new engineers that if they come in at 8AM they can get a new feature up on the site in 12 hours. Move fast isn’t just a platitude, a company has to come up with ways to make people feel it’s a reality.

重要だと認識し、維持したいと望む、文化の部分を分離すべきである。 それは、自動的には引き起こされない。 Facebook では、いくつかの Hackathon を運営している。それにより、エンジニアが午前 8時に出社した後に、12時間以内にサイトに反映できる、新しい機能などが説明される。 迅速な動きとは、単に陳腐な決まり文句ではない。 それは、企業が知恵を絞るべきものであり、開発者に対して現実感を提供するものである。

Related Articles

Should Startups Worry about Their Company Culture? by Audrey Watters.
Facebook Related Articles

ーーーーー

スケーラブルなプロダクトやサービスを提供するためには、こうした目的に適した組織を作り、開発者のモチベーションを高めていくための、マネージメントが必要という事なのでしょうね。先週の Twiter の話といい、今回の Facebook の話といい、スケールに対する感覚が、IT の在り方を変えていく様が、実感できますね。 ーーー A.C.

ーーーーー

<関連>
Facebook のスケール感覚に驚愕! _1
ーーーーー
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか?
ロシアのハッカー Kirllos が、150万人分の Facebook アカウントを売りに出すという
Facebook と Greenpeace : Oregon のデータセンターをめぐって対峙
Office 2010 は、Docs.com で Facebook とコラボ?
ーーーーー
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _1
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _2
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _3
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _4

Facebook のスケール感覚に驚愕! _1

Posted in Big Data, Facebook, NoSQL by Agile Cat on June 15, 2010

The Four Meta Secrets of Scaling at Facebook
DateThursday, June 10, 2010 at 10:42PM
http://highscalability.com/blog/2010/6/10/the-four-meta-secrets-of-scaling-at-facebook.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+HighScalability+%28High+Scalability%29&utm_content=Google+Feedfetcher

image

facebook_logo

Aditya Agarwal, Director of Engineering at Facebook, gave an excellent Scale at Facebook talk that covers their architecture, but the talk is really more about how to scale an organization by preserving the best parts of its culture. The key take home of the talk is:

Facebook のエンジニアリング部門で Director を務めるAditya Agarwal が、Facebook のアーキテクチャをカバーする、その素晴らしいスケールについて話してくれた。しかし、その内容というと、同社の文化的に優れた部分を維持することで、組織のスケールを調整する方式に多くの時間が割かれた。 そこでの重要な考え方は、以下のとおりである:

You can get the code right, you can get the products right, but you need to get the culture right first. If you don’t get the culture right then your company won’t scale.

たしかに、コードを得ることも、プロダクトを得ることもできるが、最初に得るべきは文化だ。 それを的確に行えないなら、Facebook 自身がスケールできなくなる。

This leads into the four meta secrets of scaling at Facebook:

この言葉により、Facebook をスケールするための、4つのメタ・シークレットが導かれる:

  1. Scaling takes Iteration
  2. Don’t Over Design
  3. Choose the right tool for the job, but realize that your choice comes with overhead.
  4. Get the culture right. Move Fast – break things. Huge Impact – small teams. Be bold – innovate.

Some Background

  • Facebook is big: 400 million active users; users spend an average of 20 minutes a day; 5 billion pieces of content (status updates, comments, likes, photo uploads, video uploads, chat messages, inbox messages, group events, fan pages, friend connections) are shared on Facebook every week; 3 billion photos uploaded each month; 250 applications that have more than 1 million users a month; 80,000 connect applications, 500,000 applications; 2 million developers; 150 million memcache operations per second; thousands of memcache servers with 10s of terabytes of memory; 300 developers.

  • Facebook is big: 4億人のアクティブ・ユーザー。ユーザーあたり 1日平均で20分の滞在。1 週間ごとに50億個のコンテントを共有(status updates, comments, likes, photo uploads, video uploads, chat messages, inbox messages, group events, fan pages, friend connections)。 1ヶ月に30億枚の写真をアップロード。1カ月に100万ユーザーが利用する 250種類のアプリケーション。8 万のアプリケーション接続と、50万のアプリケーション、200万のデベロッパー。毎秒 1億5000万回の memcache 処理。数10テラバイトのメモリて構成される、数千の memcache サーバー。 300人のデベロッパー。

  • Facebook is difficult to scale. Each type of content has its own access pattern which makes scaling difficult. Everyone uses Facebook in a different way. Every experience is unique. Most websites have a scaling story of adding more servers because the data can be partitioned. Scale horizontally. In Facebook users can’t be partitioned because users can join any network. It’s a global network that tries to capture everyone in the world, it allows anyone to friend anyone, and can represent any relationship between users. Every new user can access any other user’s data which means there’s no way to partition users by geography, or any other metric. Every user on Facebook has 130 friends, but there’s no cut that allows you to partition the data so that access is only in that cluster.

  • Facebook is difficult to scale. それぞれのコンテント・タイプが、スケーリングを困難にするアクセス・パターンを持っている。ユーザーごとに異なる Facebook の使い方。すべてのエクスペリエンスがユニーク。データのパーティショニングを実現するために、大半の Web サイトに適用される、サーバー追加に関する個々のスケーリング・ストーリー。水平方向へのスケーリング。あらゆるネットワークに参加する Facebook ユーザーを、パーティショニングすることは不可能。 すべての人々を引きつけるグローバルなネットワークであり、すべての人々が友人になる機会を作り、あらゆるユーザー同士の関係を表現。 地理的な制約などによる制限により、ユーザーを分離することなく、新規ユーザーが他者のデータにアクセスできる環境を実現。130人の友人を持つ Facebook の全ユーザーからのアクセスを、対象となるクラスタだけに限定するような、データ分割を許すような処理を排除。

  • Overall architecture has 4 main components: Load Balancer, Web Servers (written in PHP), Services (fast, complicated, search, ad, scribe), Memcached (fast, simple), Databases (slow, persistent).

  • Overall architecture has 4 main components: Load Balancer/Web Server(PHP で記述)/Service(高速性と安定性を備えた検索・広告・記述)/Memcache 化(高速でシンプル)/Databases(低速であっても永続性を達成)。

<続く>

これは序の口、次回が白眉(?) ーーー A.C.

<関連>
Facebook のスケール感覚に驚愕! _2
ーーーーー
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか?
ロシアのハッカー Kirllos が、150万人分の Facebook アカウントを売りに出すという
Facebook と Greenpeace : Oregon のデータセンターをめぐって対峙
Office 2010 は、Docs.com で Facebook とコラボ?
ーーーーー
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _1
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _2
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _3
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _4

 

Twitter が Cassandra を選んだ理由 — MyNoSQL

Posted in NoSQL, Twitter by Agile Cat on March 1, 2010

Cassandra @ Twitter: An Interview with Ryan King

http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king

 Cassandra Twiitter

There have been confirmed rumors [1] about Twitter planning to use Cassandra for a long time. But except the mentioned post, I couldn’t find any other references. Twitter is fun by itself and we all know that NoSQL projects love Twitter. So, imagine how excited I was when after posting about Cassandra 0.5.0 release, I received a short email from Ryan King, the lead of Cassandra efforts at Twitter simply saying that he would be glad to talk about these efforts. So without further ado, here is the conversation I had with Ryan King (@rk) about Cassandra usage at Twitter:

ずっと以前から、Twitter が Cassandra の利用を計画しているというウワサ [1] があった。 しかし、このポストを除いて、他の情報を得ることは無かった。 Twitter は楽しいし、すべて人々が NoSQL プロジェクトに適していることを知っている。 それだけに、Cassandra 0.5.0 のリリースの後に、Ryan King から短いメールをもらった時の感激を想像してほしい。なぜなら、Cassandra で Twitter を推進する彼が、その内容を説明しても構わないと言ってくれたからだ。 難しい話は抜きにして、Twitter における Cassandra の用法について、私と Ryan King が交わした会話を紹介する:

ーーーーー

MyNoSQL: Can you please start by stating the problem that lead you to look into NoSQL?

MyNoSQL: まず、NoSQL を検討する際の問題点から説明してもらえるか?

Ryan King: We have a lot of data, the growth factor in that data is huge and the rate of growth is accelerating.

Ryan King: 私たちは大量のデータを有している。それらのデータの成長は、途方も無いものであり、また、急加速してい る。

We have a system in place based on shared mysql + memcache but its quickly becoming prohibitively costly (in terms of manpower) to operate. We need a system that can grow in a more automated fashion and be highly available.

私たちは共有された mysql + memcache をベースにしてシステムを運用しているが、そのコストは(マンパワーの点で)きわめて大きなものとなる。 私たちは、さらに自動化された方式で拡張され、いつでも利用できる、システムを必要として いる。

MyNoSQL: I imagine you’ve investigated many possible approaches, so what are the major solutions that you have considered?

MyNoSQL: あらゆるアプローチを調査してきたと思うが、あなたが考えている重要なソリューションとは?

Ryan King:

◦A more automated sharded mysql setup
◦Various databases: HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra,  HyperTable and probably some others I’m forgetting.

◦ いま以上に自動化された、共有 MySQL の設定。
◦ HBase/Voldemort/MongoDB/MemcacheDB/Redis/Cassandra/HyperTable といった、各種のデータベースの 検討。

MyNoSQL: What kind of tests have you run to evaluate these systems?

MyNoSQL: そこれらのシステムを評価するために、行ったテストは?

Ryan King: We first evaluated them on their architectures by asking many questions along the lines of:

Ryan King: 最初に、以下のような項目で、それらのアーキテクチャを評価した:

◦How will we add new machines?
◦Are their any single points of failure?
◦Do the writes scale as well?
◦How much administration will the system require?
◦If its open source, is there a healthy community?
◦How much time and effort would we have to expend to deploy and integrate it?
◦Does it use technology which we know we can work with? *… and so on.

Asking these questions narrowed down our choices dramatically. Everything but Cassandra was ruled out by those questions. Given that it seemed to be our best choice, we went about testing its functionality (“can we reasonably model our data in this system?”) and load testing.

それらの確認により、私たちの選択枝は大幅に狭まった。 そして、Cassandra 以外のすべてが、この質問により除外された。 そ れが、ベスト・チョイスであるという前提のもとで、私たちは機能と負荷についてテストした。それは、私たちのデータを、このシステムでモデル化できるかという確認であった。

The load testing mostly focused on the write-path. In the medium/long term we’d like to be able to run without a cache in front of Cassandra, but for now we have plenty of memcache capacity and experience with scaling traffic that way.

大半の負荷テストは、書き込みに焦点を合わせたものだった。 Cassandra のフロントにキャッシュを置かずに、中長期の運用か可能なのか、その点を調べたかった。 しかし、現在では、大量の memcache を持ち、その方式でトラフィックをスケールする方式を有している。

MyNoSQL: If you draw a line, what were the top reasons for going with Cassandra?

MyNoSQL: どこかに線を引くとしたら、Cassandra を採用する最大の理由は何になる?

Ryan King:

◦No single points of failure
◦Highly scalable writes (we have highly variable write traffic)
◦A healthy and productive open source community

MyNoSQL: Will Cassandra completely replace the current solution?

MyNoSQL: Cassandra は、現在のソリューションを完全に置き換えられるか?

Ryan King: Over time, yes. We’re currently moving our largest (and most painful to maintain) table — the statuses table, which contains all tweets and retweets. After this we’ll start putting some new projects on Cassandra and migrating other tables.

Ryan King: Yes。 ただし、時間がかかる。 現時点では、その維持が最も困難なテーブル、つまり、すべての tweets と retweets 取り込んだテーブルを移行している。 この処理が終われば、新しいプロジェクトに Cassandra で対応できるし、その他のテーブルも移行できる。

MyNoSQL: How do you plan to migrate existing data?

MyNoSQL: 既存データの移行については、どのように計画している?

Ryan King: We have a nice system for dynamically controlling features on our site. We commonly use this to roll out new features incrementally across our user base. We use the same system for rolling out new infrastructure.

Ryan King: 私たちは、ダイナミックな制御が可能な、素晴らしいシステムを手元に有している。 私たちは、それを用いて、ユーザーのための新しい機能を、漸進的に拡張していく。 また、インフラストラクチャに対しても、同じシステムを使用していく。

So to roll out the new data store we do this:

したがって、新しいデータ・ストアを達成するために、以下の項目を実施する:

1.Write code that can write to Cassandra in parallel to Mysql, but keep it disabled by the tool I mentioned above
2.Slowly turn up the writes to Cassandra (we can do this by user groups “turn this feature on for employees only” or by percentages “turn this feature on for 1.2% of users”)
3.Find a bug :)
4.Turn the feature off
5.Fix the bug and deploy
6.GOTO #2

1. Cassandra にはパラレルで書き込み、また、MySQL にも書き込みを行うコードを書く。 ただし、それらを停止すための手段を、前述の方式で確保しておく。
2. Cassandra への書き込みを、段階的にチューンアップしていく。たとえば、“turn this feature on for employees only” や、“turn this feature on for 1.2% of users” というような感じで。
3. バグの調査。
4. この機能を停止する。
5. バグ・フィックスとディプロイ。
6. GOTO #2

Eventually we get to a point where we’re doing 100% doubling of our writes and comfortable that we’re going to stay there. Then we:

最終的に、書き込み能力を倍増するために、上記の手順を完璧に(100%)に行う。そこが、私たちが目標とするポイントだ。 続いて、以下を行う:

1.Take a backup from the mysql databases

1. MySQL データベースのバックアップを作成する。

2.Run an importer that imports the data to cassandra

2. Cassandra にデータをインポートするためのプログラムを実行する。

Some side notes here about importing. We were originally trying to use the BinaryMemtable[2] interface, but we actually found it to be too fast — it would saturate the backplane of our network. We’ve switched back to using the Thrift interface for bulk loading (and we still have to throttle it). The whole process takes about a week now. With infinite network bandwidth we could do it in about 7 hours on our current cluster.

ここで、インポートについて付け加えておく。 私たちは最初に、BinaryMemtable [2]インターフェイスを使おうとしたが、それで速すぎることに気づいた。 つまり、私たちのネットワーク・バックプレーンを飽和させてしまう。そのため、バルク・ロードのために、Thrift インターフェイスを使うように戻した(それでも調整が必要になる)。 すべてのプロセスには、1週間が必要になる。 無限のネットワーク帯域幅があれば、現時点のクラスタ上で、約 7時間で処理できるだろう。

3.Once the data is imported we start turning on real read traffic to Cassandra (in parallel to the mysql traffic), again by user groups and percentages.

3. データがインポートされたら、Cassandra における現実の読み込みトラフィックを、user groups や percentages に応じて再びチューンアップしていく。

4.Once we’re satisfied with the new system (we’re using the real production traffic with instrumentation in our application to QA the new datastore) we can start turning down traffic to the mysql databases.A philosophical note here — our process for rolling out new major infrastructure can be summed up as “integrate first, then iterate”. We try to get new systems integrated into the application code base as early in their development as possible (but likely only activated for a small number of people). This allows us to iterate on many fronts in parallel: design, engineering, operations, etc.

4. この新しいシステム(新しいデータストアに関する QA を実現するために、アプリケーションにおける実際のトラフィックを利用している)に満足できるようになったら、MySQL へのデータベース・トラフィックを停止し始める。新しいインフラストラクチャを達成するためのプロセスは、 “integrate first, then iterate” という発想に要約することができる。 私たちは、以前に開発されたアプリケーション・コードをベースにして、新しいシステムを統合しようと試みる(それを出来る人は限られている)。 しかし、そうすることで、デザイン/エンジニアリング/オペレーションなどのプロセスを、並列的に繰り返せるようになる。

MyNoSQL: Please include anything I’ve missed.

MyNoSQL: なにか足りないことがあったら、補足してほしい。

Ryan King: I can’t really think of anything else.

Ryan King: あまり、他のことは考えていない。

MyNoSQL: Thank you very much!

MyNoSQL: どうも有難う!

References

◦[1] The ☞ Up and running with Cassandra is probably one of the most detailed posts on the internet about Cassandra. MyNoSQL has also a post listing the best resources available for Cassandra documentation. It contains a fair amount of details about using Cassandra for storing Twitter data. (↩)

◦[2] If you remember our post Cassandra in Production @ Digg, Digg is using Hadoop and Cassandra’s BinaryMemtable to load preserialized data. (↩)

 

< Cassandra 関連 >
Cassandra ライブ情報がテンコ盛り – Jonathan Ellis @ Rackspace
Digg が Cassandra を採用する理由 by John Quinn 
High Scalability のホット・リンク集 : Cassandra@Twitter インタビューもあるよ!
Cassandra 分散データベースでの削除とは?
Cassandra プロジェクトと Rackspace
NoSQL Ecosystem とは? _1
イベンチュアル・コンシステンシーはお好き? by James Hamilton

%d bloggers like this: