Agile Cat — in the cloud

わずか四半期の間に、サーバー数が倍増した Facebook の事情

Posted in Data Center Trends, Facebook by Agile Cat on June 30, 2010

Facebook Server Count: 60,000 or More
June 28th, 2010 : Rich Miller
http://www.datacenterknowledge.com/archives/2010/06/28/facebook-server-count-60000-or-more/

image

It’s said that a picture is worth a thousand words. Sometimes a PowerPoint slide can tell the story of thousands of servers.

百聞は一見にしかずである。 ときおり、一枚の PowerPoint スライドが、きわめて重要なサーバー・ストーリーを語ることがある。

facebook-server-growth

That was the case with a presentation from Facebook’s Tom Cook at last week’s  Velocity 2010 conference, which depicted the growth of the company’s server footprint. Designed to illustrate Facebook’s insatiable need for more servers to support its 400 million users, the chart didn’t include any numbers, seeking not to reveal the actual server count.

これは、先週に開催された Velocity 2010 カンファレンスで、Facebook の Tom Cook がプレゼンテーションで用いたものであり、同社のサーバー・フットプリントの成長を描いている。 このグラフは、4億人のユーザーをサポートする Facebook の、貪欲なニーズを例証するようデザインされてはいるが、実際のサーバー数を明示するような情報は含んでいない。

Dates Provide A Clue

But the chart included dates, which allows us to do some math to fill in the blanks. In a presentation in November 2009, Facebook vice president of technology Jeff Rothschild disclosed that the company had more than 30,000 servers. Cook’s chart shows a brief plateau in Facebook’s server growth at about that time, followed by a sharp upward spike in the growth line through the first quarter of 2010 that effectively doubles the total number of servers.

けれども、このグラフには日付が含まれており、それにより、空白を埋めるための計算が可能になる。 2009年11月に行われたプレゼンテーションでは、Facebook の Vice President of Technology である Jeff Rothschild が、30,000 台以上のサーバーを保有していることを明らかにしている。 今回の Cook のグラフからは、そのときの短い安定期を読み取ることができる。 そして、その後に、つまり、2010年の第1四半期に急激な成長の跡があり、サーバーの合計数が2倍に伸びている。

That suggests that Facebook now has 60,000 or more servers. The sharp acceleration in Facebook’s server growth in late 2009 also helps explain the company’s move to lease large chunks of data center space in northern Virginia and Silicon Valley in March. The growth spurt occurred after Facebook announced plans to construct its own data center in Prineville, Oregon.

Facebook は、いまでは 60,000 台以上のサーバーを保有していると示唆される。 2009年の広範囲おける、Facebook サーバー数の急激な成長は、この 3月に Virginia 北部と Silicon Valley にいおいて、膨大なデータセンター・スペースをリースしたとする、同社の動きを説明するにも役立つ。 そして、急激な成長は、Facebook が Prineville, Oregon に、自社のデータセンタを建設するという、計画を発表した後に起こっている。

That places Facebook among the largest Internet companies that have publicly discussed their server growth, but still well behind Intel, which has more than 100,000 servers. See Who Has The Most Web Servers for more data on the largest Internet infrastructures.

それにより、Facebook は最大級のインターネット企業の仲間入りを果たすことになり、そのサーバー成長率も公に議論されているが、100,000 台以上とも言われるサーバー群は、Intel の影に隠れてしまっている。 大規模インターネット・インフラストラクチャの詳細については、Who Has The Most Web Servers を参照してほしい。

Why so many servers? Facebook now has more than 400 million active users, including more than 200 million who use the service every day. Here are some other data points from Cook’s presentation and a talk last Thursday at Structure 2010 by Facebook’s Jonathan Heiliger.

何故に、それほどまでのサーバーが必要なのだろうか? 現時点において、Facebook は 4億人以上のアクティブ・ユーザーを持っており、その中には、彼らのサービスを毎日使う、2億人以上の超アクティブ・ユーザーが含まれる。 以下に示すのは、Cook のプレゼンテーションとは別に、Facebook の Jonathan Heiliger が、先週の木曜日に Structure 2010において説明したものである。

Users spend more than 16 billion minutes on Facebook each day
Every week users share more than 6 billion pieces of content, including status updates, photos and notes.
Each month more than 3 billion photos are uploaded to Facebook.
Users view more than 1 million photos every second
Facebook’s servers perform more than 50 million operations per second, primarily between the caching tier and web servers
More than 1 million web sites have implemented features of Facebook Connect

ユーザーが Facebook で費やす合計時間は、160億時間/日となる。
ユーザーが共有するコンテンツは 60億/週であり、そこにはステータス/写真/ノートなどが含まれる。
30 億枚の写真が、毎月のようにアップロードされる。
写真の参照は、100万枚/秒である。
Facebook のサーバーは、5000万件/秒のオペレーションを処理しており、その大半がキャッシュ層とWebサーバーの間で行われる。
100万以上の Web サイトが、Facebook Connect を実装している。

Here’s a look at some of our past coverage of the growth of Facebook’s infrastructure:

Facebook におけるインフラストラクチャの成長については、Data Center Knowledge の、これまでのポストを参照してほしい:

Facebook Amassing Data Center Space: The company has moved to lock down much of the available data center space in two major markets, leasing large chunks of space in Santa Clara, Calif. and Ashburn, Va.
Facebook Building Its Own Data Center in Oregon: Facebook’s first company-built data center will be in Prineville, Oregon, and will be among the most energy efficient in the industry.
Should Servers Come With Batteries? Will the data center of the future have no central UPS units, and be filled with servers with on-board batteries? The data center team at Facebook believes it should
Facebook: Managing Epic Growth in Real-Time: CTO Jonathan Heiliger presents an overview of Facebook’s back-end operations at the Velocity 2009 conference in June.
A Look Inside Facebook’s Data Center: A recruitment video provides a glimpse inside the server-packed racks and aisles of a Facebook data center.
Facebook Pushes Limits on Memcached: Caching is key to massive web scalabilty. Here’s how Facebook is extending a popular caching technology.

facebook-heiliger

Facebook VP of Technical Operations Jonathan Heiliger discusses the infrastructure for the social network at Structure 2010 (Photo by Colleen Miller).

 

___space

ーーーーー

<関連>
Facebook の HDFS クラスターは 21 PB !!!
Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2
Facebook で Office ドキュメントを共有する Docs.com を触ってみた
Microsoft TownHall : Windows Azure と Facebook の連携が始まった!
Facebook は RFID タグで、アメリカ版 お財布ケータイを狙うのか?
ーーーーー
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _1
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _2
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _3
10億人のユーザーを目指す、Twitter の 6つの戦略とは? _4

Infragistics : ユーザーのためのデータ・ビジュアライゼーション Part_2 – 円グラフとピザ効果

Posted in UX by Agile Cat on June 29, 2010

Blog series: User-Centered Data Visualization. Part 2 – The Pizza Effect
http://blogs.infragistics.com/error.htm?aspxerrorpath=/blogs/ux/archive/2010/01/05/blog-series-user-centered-data-visualization-part-2-the-pizza-effect.aspx

image

The underlying data set is pretty simple. It consists of just 8 numbers which are used for four target/actual comparisons: how many swine flu vaccinations 4 organizations have requested and how many they actually received. And still, the way the data was visualized is problematic.

この、基礎となるデータセットは、かなり単純なものである。 それは、4つのターゲットと、現実的な比較のために使われる、8種類の数値だけで構成されている。つまり、4つの組織において、ブタ・インフルエンザ・ワクチンンの接種を求めた人数と、実際に接種できた人数を表現している。 そして、データのがビジュアライズには、依然として問題が残されている。

TimeMagazinScan

Estimating the area of a circle is hard. The area of a circle grows quadratically with the radius. You double a circle’s radius and the area gets four times as large. You may know this from ordering pizza: the diffe

サークルの面積を推測することは困難である。 サークルの面積は、その半径に比例して拡大する。 たとえば、サークルの半径を 2倍にするなら、その面積は 4倍の広さとなる。 ピザを注文するときに、この事実に気づくことになる。 つまり、14インチのピザ(medium)と 16インチのピザ(large)の違いについて、数字だけを並べてみても実感がない。 結局のところ、それは 2インチの違いに過ぎない。 しかし、16インチのピザ(large)を食べることは、14インチのピザ(medium)のときと比べて、まったく別次元の挑戦となる。これが、『半径を 2倍にするなら面積は 4倍』の効果である。

Columbia University requested twice as many vaccines than Goldman Sachs. This is very hard to see in the circle sizes: with both red circles being the same size (showing that they both received the same number of vaccines), Columbia’s large dotted circle does not look twice as large as Goldman’s – but it is. That’s the pizza effect. Were the actual numbers not shown below the circles, the visualization would be not very expressive. Because estimating the area of circles is so difficult, it’s also tough to compare the size of the red circles against the dotted circles for all of the organizations.

Columbia University は Goldman Sachs と比べて、2倍の量のワクチンを求めた。 それを、サークルのサイズで見きわめることは、きわめて困難である。 双方の赤いサークルは同じサイズ(双方が同じ数のワクチンを受け取ったことを示す)であるが、Columbia の点線によりサークルが、Goldman のそれと比べて、2倍の大きさに見えることはない。   実際には 2倍の大きさなのに、そう見えないことがピザ効果の結果である。 もし、サークルの下に実際の数量が示されていなければ、このビジュアライゼーションの効果は半減する。 それほどに、サークルの面積を推測することは難しい。 そのため、点線によるサークルを基準にして、赤いサークルのサイズを判断することも難しくなる。

Here’s one suggestion to visualize the data in an easier to interpret manner:

ここでは、データをビジュアライズするため方式を示唆するが、それは、データの説明を容易にするためのものとなる。

Infragistics_1

Because it’s much easier to estimate the length of a bar than the area of a circle, this graph makes it easy to see that Columbia ordered twice as many vaccines than Goldman – even without data labels next to the bars. It’s still a challenge to estimate the number of received vaccines for Goldman and Columbia. A logarithmic scale could resolve this problem, but people have hard times understanding log scales (see the first blog of this series).

サークルの面積を見積るより、バーの長さを見積もる方が、ずっと容易である。 そのため、Columbia が Goldman に対して、2倍の量のワクチンを発注したことが、このグラフから容易に読み取れる。 数値による説明がなくても、それが判るだろう。 しかし、Goldman と Columbia が受け取ったワクチンの数を見積もることが、まだ解決されていない課題として残される。 対数のスケールを用いれば、この問題を解決することが可能だが、一般的に受け入れられるものではない。 (see the first blog of this series )

People often say that bar charts or column charts are too standard and therefore boring ("not sexy"). These chart types are standard because they are superior to other ways of visualizing data. There are still ways (within limits) to make them attractive, but from a user-centered design perspective I believe that usability has the top priority.

バー・グラフやカラム・チャートは、あまりにも標準的であり面白くないという(not sexy)、数多くの声がある。 しかし、これらのチャート・タイプがスタンダードとして用いられるのは、データのビジュアライズにおいて、他の方法より優れているからという理由がある。これらのグラフを、さらに(適度に)魅力的にする方法はあるが、ユーザーを中心としたデザインの見地からは、有用性が最優先にされすべきだと信じる。

Here’s another interesting fact that neither the original visualization nor the bar chart reveal. It doesn’t seem like it was the intention of Time to focus on this, but since the ratios between requested and received vaccines are shown, it’s straight forward to calculate the actual value which then makes it very easy to see which of the four organizations got better off than the others. Here’s what the result looks like:

オリジナルのサークルでも、追加されたバーでも明らかにされていない、もう1つの面白い事実がある。 ワクチンに対する要求と受け取りの比率を表示できるのだが、そこに焦点を合わせることが、Time 誌の意図になかったように思われる。この比率を、4つの組織において比較することは、実際の数値を計算することで、シンプルかつ容易に行える。 つまり、以下のような結果が導き出せる:

Infragistics_2

Again I didn’t put data labels next to the bars. Not necessary. It’s obvious that the cancer center and Goldman Sachs have approximately the same ratio between requested and received vaccines – roughly 5% and that’s a third of what Citigroup got and twice as much as Columbia. It’s interesting that, unlike pie charts, bar charts require you to think about how to scale the x-axis. I put it to 100% max to show the distance between the optimum relative return (100%) and the best achieved relative return (17%). So the message is that none of the four organizations got a good portion of what they had asked for. If I had put the max on the x-axis to 20% it would’ve shown more clearly the differences between the organizations. So the message had been: Citigroup got a much higher relative return than the others. Which scaling is better? There is no right or wrong answer. It depends on the underlying question at hand and what you want to express. Doesn’t this demonstrate how manipulative data visualization can be? You betcha.

繰り返すが、バーの横にデータ・ラベルは配置していない。 なぜなら、必要とは思えないからである。 ワクチンに関する要求と結果において Cancer Center と Goldman Sachs が、ほぼ同じ比率となっている。 この、約 5% という値が、Citigroup の 1/3 に近く、Columbia の2倍に近いという事実が明らかになる。 サークル・グラフでは不可能であるが、バー・グラフにおける x軸のスケールを考えると面白い。 ここでは、最大値を 100% にして、最良の結果である 17% との対比を示している。 つまり、4つの組織のいずれもが、最良の結果を得られなかったというメッセージが発信される。 もし、x 軸のスケールを 20% にしたなら、今度は組織間の相違が明らかになる。 そして、Citigroup が、他と比較して高いリターンを得ていることも、メッセージとして発信される。 どちらのスケールのが適切なのだろうか? そこには、正解もなければ不正解もない。 それは、取り組んでいる基本的な問題と、明らかにするものに依存する。 つまり、データ・ビジュアライゼーションを、どれだけ巧みに操れるのかということが、証明されているのはないだろうか? そこに賭けるべきだ。

ーーーーー

image 

ーーーーー

<関連>
Infragistics : ユーザーのためのデータ・ビジュアライゼーション Part_1
カラー と ユーザー・エクスペリエンス _1
カラー と ユーザー・エクスペリエンス _2

5月の Web アクセス TOP-50 :1位 Google、2位 Yahoo!、3位 Microsoft、、、

Posted in Research by Agile Cat on June 26, 2010

comScore Media Metrix Ranks Top 50 U.S. Web Properties for May 2010
http://www.comscore.com/content/download/5457/100205/file/comScore%20Media%20Metrix%20Ranks%20Top%2050%20US%20Web%20Properties%20for%20May%202010.pdf

comScore

母の日があったり、NBA の盛り上りがあったりという、2010年 5月の Web アクセスデータに関するレポートが提供されています。 その中から、Table 3 の Top 50 Properties という表をご紹介します。 1位 Google、2位 Yahoo!、3位 Microsoft に続いて、4位には Facebook が付けています。 ずっと下がって、12位から Amazon、New York Times、eBay、Apple という、おなじみのサイトが並んでいます。我らが WordPress は 27位で、Agile_Cat の分も、下二桁くらいには影響するのかと思うと、ちょっと誇らしげな気分になります :)

comescore-50

↑ クリックで拡大します ↑

でも、こうして見ていると、Twitter がいないことに気づきましたが、どうなっているのでしょう? その答えは、ココ 6: Ubiquity – ユビキタスを実現する  にあるようです。

もし、その目的が、この世界に張り巡らされる動脈になることなら、すべてにおいてユビキタスにならなければならない。 その目標へ向けて、Twitter は他者とは異なる戦略を追求している。 それは、自身のフロントページへ向けてトラフィックを集約する、大半の Web サイトとは別の発想である。 Twitter を利用するための選択肢を、ユーザーに提供することで、ほとんど正反対の方向へ向かっている。 その結果として、トラフィックの約 75% が、サードパーティのサービスと Twitter API を介したものとなる。 驚くべきことに、Twitter.com Web サイトでのトラフィックは 25% にしか過ぎない。

それにしても、comScore の TOP-50 に入っていないのは不思議ですよね。 こんな調査は、Twitter にとっては意味が無いのだと、協力していない可能性もありますね。。。

ーーーーー

<関連>
ワールドカップとインターネット・アクセス: キックオフ偏
ワールドカップとインターネット・アクセス
GIGAOM のクラウド調査:1位 AWS、2位 Rackspace、、、
アメリカのスマートフォン・シェアは、iPhone 4 で変化するのか?
アメリカの 新聞/TV 幹部への意識調査:先行きの見えないジャーナリズム
App Store を凌駕する、Touch Screen Web サイトの成長
ISACA のクラウド・セキュリティ 調査結果
ISACA のクラウド・セキュリティ 調査結果

Facebook の HDFS クラスターは 21 PB !!!

Posted in Big Data, Facebook, HDFS by Agile Cat on June 25, 2010

Facebook has the world’s largest Hadoop cluster!
http://hadoopblog.blogspot.com/2010/05/facebook-has-worlds-largest-hadoop.html

facebook_logo

なにげなく Facebook を見ていたら、こんなポストが ・・・ これまでは秘密だったみたいですね。 スゴイ! ーーー A.C.

ーーーーー

It is not a secret anymore!

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

That’s a total of more than 21 PB of configured storage capacity! This is larger than the previously known Yahoo!’s cluster of 14 PB. Here are the cluster statistics from the HDFS cluster at Facebook:

image

ーーーーー

立てこんでまして、英語のままでスミマセン。

ーーーーー

<関連>
HDFS のスケーラビリティを考察する _1
Hadoop DFS _ Introduction

Tagged with: , ,

アメリカ政府が Microsoft と Google の採用を検討

Posted in .Selected, Google, Government, Microsoft by Agile Cat on June 25, 2010

Federal Agencies Shift Into Cloud Adoption
Posted by John Foley on June 14, 2010 11:37 AM
http://www.informationweek.com/blog/main/archives/2010/06/federal_agencie.html

image

Technology leaders with the Department of Energy, the Defense Information Systems Agency, and GSA will outline their next steps in cloud computing on June 15 at InformationWeek’s Government IT Leadership Forum in Washington, D.C. With new implementations of infrastructure as a service and software as a service, including hosted apps from Google and Microsoft, the feds appear to be shifting aggressively into full-scale adoption of the cloud services model.

Department of Energy(DoE)および、Defense Information Systems Agency(DISA)、GSA などのテクノロジー・リーダーは、6月15日に Washington, D.C で開催される InformationWeek Government IT Leadership Forum において、クラウド・コンピューティングに関する次のステップを概説する。Google と Microsoft がホストするアプリケーションを含めて、サービスとしてのインフラストラクチャおよび SaaS(software as a service)を新たに実装することで、連邦政府はクラウド・サービス・モデルの全面的な採用へ向けて、積極的に取り組んでいると思われる。

As we’ve been documenting for the past year, Uncle Sam has been investigating the potential benefits of cloud computing and agencies have been planning their first steps into the cloud. As we approach mid 2010, the mood is shifting from discussion and pilot projects into actual deployment.

私たちが昨年に紹介したように、アメリカ政府(Uncle Sam)はクラウド・コンピューティングの潜在的なメリットを調査しており、また、各種の政府機関はクラウドへの第一歩を記すべく計画してきた。 そして、2010年の半ばに私たちがアプローチしたとき、こうした方向性は、ディスカッションやパイロット・プロジェクトというより、具体的なディプロイメントへと移行していた。

A recent InformationWeek Government survey of IT managers in federal government found that 22% planned to implement cloud computing over the next 12 months and another 22% within two years, so it’s not surprising that evidence of the trend is quickly building up. Following are some of the new developments to be discussed at the Government IT Leadership Forum during a session titled “Cloud Computing Implementers’ Guide,” which is meant to help government IT pros move past the planning phase.

連邦政府の IT マネージャーに対する、最新の InformationWeek Government 調査では、今後の 12カ月間において 22%のクラウド・コンピューティング実装が計画され、また、2年以内に更に 22%の実装が計画されていることが分かった。しかし、こうした方向性が迅速に具体化され、証明されていることに驚きはない。 下記は、Government IT Leadership Forum の “Cloud Computing Implementers’ Guide” というセッションで議論される、つまり、政府機関の IT プロが計画フェーズを速やかに通り抜けるための、いくつかの新しい計画である。

Katie Lewin, director of the General Services Administration’s cloud computing program, will provide an update on GSA’s pending launch of infrastructure as a service (Iaas) on the Apps.gov cloud services portal. The deadline for GSA’s revised RFQ for IaaS services is June 15. Once GSA approves cloud service providers for participation, agencies will be able to access virtualized servers and storage on demand at Apps.gov. Lewin will also discuss GSA’s plans to issue an RFP as a first step in providing hosted e-mail services to government agencies.

General Services Administration のクラウド・コンピューティング・プログラムにおいて、ディレクターを務める Katie Lewin は、まもなく GSA が着手する Apps.gov クラウド・サービス・ポータル上での IaaS について、その情報をアップデートするだろう。 この IaaS サービスに対して、GSA が修正した RFQ(Request for Question) の期限は 6月 15日である。 GSA がクラウド・サービス・プロバイダーの参加を認可した後に、Apps.gov において仮想化されたサーバーとストレージに対して、それぞれの政府機関はオンデマンドでアクセスできるようになる。 さらに Lewin は、行政機関にホストされた電子メール・サービスを提供するための、最初のステップとしての RFP (Request for Proposal)を、GSA が発行する計画についても議論するだろう。

Henry Sienkiewicz, CIO of DISA, will provide an overview of DISA’s expanding portfolio of cloud services. DISA provides cloud services to the Department of Defense via its Rapid Access Computing Environment and its Forge.mil site for software development. The agency is adding new capabilities to its Global Content Delivery Service (GCDS), which it describes as its first cloud service, and offering Microsoft’s SharePoint and Office apps (Word, Excel, PowerPoint, OneNote) as hosted services.

DISA の CIO である Henry Sienkiewicz は、DISA が拡張していくクラウド・サービスのポートフォリオについて、その概要を提供するだろう。 DISA はソフトウェア開発において、Rapid Access Computing Environment と Forge.mil サイトを介して、Department of Defense にクラウド・サービスを提供する。 政府機関における最初のクラウド・サービスと表現される Global Content Delivery Service(GCDS)に新しい機能が加えられ、また、ホスティング・サービスとして、Microsoft の SharePoint と Office(Word/Excel/PowerPoint/OneNote)が提供される。

Lawrence Berkeley National Lab is midway through the deployment of Google Apps to 5,000 lab employees, the first unit within the Department of Energy to adopt Google’s hosted apps in a big way. Rosio Alvarez, CIO of Lawrence Berkeley, will explain the rationale behind the move and give an update on how it’s going. So far, there have been a “few bumps” but otherwise the rollout has been relatively smooth, she tells me. Lawrence Berkeley and Argonne National Lab are also building private clouds for high-performance computing using $32 million in Recovery Act funds.

Lawrence Berkeley National Lab では、5,000人の従業員に対して Google Apps をディプロイメントしている。Google にホストされたアプリケーションを、それは、Department of Energy 内で採用する、最初のユニットとなる。 Lawrence Berkeley の CIO である Rosio Alvarez は、この移行ににおける合理性を説明し、また、その進捗について情報を更新するだろう。 これまでのところ、若干の問題は生じても、その他は比較的に円滑に進んでいると、彼女は語っている。 また、Lawrence Berkeley と Argonne National Lab は、Recovery Act の資金から 3200万ドルを費やすことで、ハイパフォーマンスなプライベート・クラウドも構築している。

These are just some of the latest developments in the U.S. government’s accelerating use of commercial cloud services and deployment of private clouds, both for internal use and as a base from which to offer cloud services to other departments and agencies. InformationWeek will provide continued coverage this week from the Government IT Leadership Forum and through our ongoing editorial series on private clouds in government.

これまでに説明してきたことは、商用クラウド・サービスとプライベート・クラウドのディプロイメントを加速する、アメリカ政府における最新の開発事例に過ぎない。どちらも、内部で使用されるものであり、また、他の機関や部門にクラウド・サービスを提供するための基盤になる。 InformationWeek では、Government IT Leadership Forum の週に特集を提供し、また、政府のプライベート・クラウドを紹介するシリーズを介して、このテーマについて継続的に報道していく。

ーーーーー

以下の、Recovery.gov に続いて、ガンガン 行っちゃうようですね! ーーー A.C.

ーーーーー

<関連>
米政府の Recovry.gov が Amazon EC2 へ移行する!
とても重要な NIST のクラウド定義:対訳
総務省 自治体 クラウド ポータル サイトって、これで良いの?
台湾政府のしたたかなクラウド戦略
総務省と経済産業省は共振している: @ytaniwaki 氏のまとめ
経産省の Twitter に掲載された、とても真摯なメッセージ
総務省 スマート・クラウドに対するパブコメと議論 on Twitter (まとめ)

Tagged with: , , , , ,

ワールドカップとインターネット・アクセス: キックオフ偏

Posted in Network, Research by Agile Cat on June 24, 2010

FIFA.com のトラフィックを comScore が調査
http://blog.comscore.com/2010/06/world_cup_kick_off.html

image

先日に、やはり comScore から提供されていた、5月の FIFA.com トラフィックについてお伝えしましたが、この続編は 6月に入ってからの、開幕戦のキックオフまでの調査結果とのことです。

fifa_com 2_1

5 月の調査では、インターネット全体の 0.1%~0.2% で推移していた FIFA.com のトラフィックスですが、6月に入ってからもジワジワと伸び、開幕戦の時には 1.0% に達したようです。 各試合のサマリーやゴールシーンなど、ビデオ・コンテンツも充実しているサイトに、これだけのトラフィックが集中していること、そしてダウンもせずにサービスを提供していることが、インターネットの未来を証明しているような気がします。

fifa_com 2_2

こちらも前回と同様に、世界の各地域からのアクセス比率です。 依然としてアジアからは少なく、言葉の壁の重さを感じてしまいます。 日本語がサポートされていないということについて、ちょっとしたやり取りが Twitter 上でありましたが、国連の Web サイトでも同じことがあるようです。こちらは、戦勝国と敗戦国という図式を反映したサイトなので、仕方のない部分もあるのかとは思いますが、ドイツは国連における情報を、自前で母国語にしているそうです。

fifa_com 2_3

話はワールドカップに戻って、こちらは UK と USA の比較です。これは、サッカーに対する温度差が、そのま数字に出ているのでしょうね。 総人口で USA を大きく下回る UK ですが、サッカーとなると強烈なパワーが沸き起こってくるのでしょう(笑う) そろそろ予選も終に近づいていますが、決勝トーナメントになると、いったい どれだけのトラフィックが FIFA.com に集中するのでしょうね? それも大きな楽しみになってきました。

___space 

ーーーーー

<関連>
ワールドカップとインターネット・アクセス

Tagged with: , , , , , ,

HDFS のスケーラビリティを考察する _3

Posted in HDFS by Agile Cat on June 24, 2010

Scalability of the Hadoop Distributed File System _3
Yahoo! Developer Network Blog
May 5, 2010
http://developer.yahoo.net/blogs/hadoop/2010/05/scalability_of_the_hadoop_dist.html?

image

image

Reasonable Load Expectations

We have learned by now that the name-node can use 70% of its time to process external client requests. Even with a handful of clients one can saturate the name-node performance by letting the clients send requests to the name-node with very high frequency. The name-node most probably would become unresponsive, potentially sending the whole cluster into a tailspin because internal load requests do not have priority over regular client requests.

これまでに、外部クライアントのリクエストを処理する時間の 70% を、Name-Node が使えるを学んできた。 ただし、ひと握りのクライアントを用いるときでさえ、クライアントから Name-Node へ向けて極端な頻度でリクエストを送信すると、Name-Node は飽和してしまうだろう。 内部に負荷をもたらすリクエストが、クライアントからの一般的なリクエストに対して優先されないと、大半のケースにおいて Name-Node は反応を失い、クラスタ全体を急速に劣化させる可能性を生じる。

In practice, the extreme load bursts are uncommon. Regular Hadoop clusters run MapReduce jobs, and jobs perform conventional file reads or writes. To get or put data from or to HDFS, a client first accesses the name-node and receives block locations, and then directly talks to data-nodes to transfer file data. Thus the frequency of name-node requests is bound by the rate of data transfer from data-nodes.

現実的に見て、極端な負荷によるバーストは一般的ではない。 通常の Hadoop クラスタは MapReduce のジョブを実行し、それらのジョブが標準的なファイルの Read/Write を行う。 HDFS を相手にデータの送受信を行うために、クライアントは最初に Name-Node にアクセスし、ブロックのロケーションを受け取り、続いて、ファイル・データを転送するために、Data-Node とダイレクトに交信する。したがって、Name-Node におけるリクエストの頻度は、Data-Node からのデータ転送のレートにより拘束される。

Typically a map task of a MapReduce jobs reads one block of data. We estimate how much time it takes for a client to retrieve a block replica and, based on that, evaluate the expected read load on the name-node — namely, how many “get block location” requests the name-node should expect per second from 100,000 clients. We apply the same technique to evaluate the write load on the cluster.

典型的な MapReduce ジョブのマップ・タスクは、1つのデータ・ブロックを読み込む。
私たちは、クライアントがブロック・レプリカを取得するために、費やす時間を見積もることができる。そして、それに基づいて、Name-Node 上での読み取りの負荷を評価する。 つまり、Name-Node が想定すべき、1秒あたりの "get block location" リクエスト数を、10,000 クライアントを前提として予測することになる。クラスタにおける書き込みの負荷に対しても、同じテクニックで評価できる。

Performance Limitations

The read and write throughputs have been measured by the DFSIO benchmark and are summarized in Table 3.

この read/write に関するスループットは、Table 3 に示されるように、DFSIO ベンチマークにより測定されている。

image

Another series of throughput results produced by NNThroughputBenchmark (Table 4) measures the number of open (the same as get block location) and create operations processed by the name-node per second:

NNThroughputBenchmark (Table 4)により生成される、もう 1つのスループットは、Name-Node により 1 秒ごとに処理される、ブロックのオープン(get block location と同じ)と作成に関する頻度を測定している。

image

The read throughput in Table 3 indicates that 100,000 readers are expected to produce 68,750 get-block-location requests to the name-node per second. And Table 4 confirms that the name-node is able to process that many requests even if only 70% of its processing capacity is dedicated to this task.

NNThroughputBenchmark (Table 4)により生成される、もう 1つのスループットは、1 秒ごとに Name-Node により処理される、ブロックのオープン(get block location と同じ)と作成に関する頻度を測定している。Table 3 における read スループットによると、100,000 reader が Name-Node に対して、1秒あたり 68,750 回の get-block-location リクエストを発行すると予測される。 そして Table 4 では、このタスクが占有する処理容量の 70% であっても、Name-Node が数多くのリクエストを処理できることが確認される。

A 10,000 node HDFS cluster with the internal load at 30% will be able to handle an expected read-only load produced by 100,000 HDFS clients.

30% の内部負荷を伴なう 10,000ノードの HDFS クラスタは、100,000の HDFS クライアントが生じる read-only の負荷を処理できるだろう。


The write performance is not as optimistic. According to Table 3, 100,000 writers are expected to provide an average load of 41,667 create block requests per second on the name-node. This is way above 3,920 creates per second — 70% of possible processing capacity of the name-node (see Table 4).

書き込みのパフォーマンスに関しては、楽観できない。 Table 3 によると、100,000 writer が Name-Node に対して、1 秒あたり 41,667 回の create-block リクエストを、平均として発行すると予測される。 つまり、Name-Node の処理容量の 70% に相当する、毎秒3,920 回の生成を上回ることになる(参照 Table 4)。

A reasonably expected write-only load produced by 100,000 HDFS clients on a 10,000 node HDFS cluster will exceed the throughput capacity of a single name-node.

10,000のノードの HDFS クラスタにおける、100,000 の HDFS クライアントが生成する write-only の負荷については、単一の Nme-Node のスループット容量を超えると予測すべきだろう。

We have seen that a 10,000-node HDFS cluster with single name-node is expected to handle a workload of 100,000 readers well. However, even 10,000 writers can produce enough workload to saturate the name-node, making it a bottleneck for linear scaling.

私たちが確認してきたことは、単一の Name-Node を持つ 10,000ノードの HDFS クラスタが、100,000 reader のワークロードを適切に処理するだろうというものだ。 しかし、10,000 writer のケースでさえ、単一の Name-Node を充分に飽和させるワークロードを生成するため、リニアなスケールにボトルネックを生じる。

Such a large difference in performance is attributed to get-block-locations (read workload) being a memory-only operation, while creates (write workload) requires journaling, which is bounded by the local hard drive performance.

このような、パフォーマンスにおける大きい相違は、get-block-locations(read workload)が memory-only 操作であるのに対して、create(write workload)がローカルな HDD の性能に拘束される journaling を要求することに起因する。

There are ways to improve the single name-node performance. But any solution intended for single namespace server optimization lacks scalability.

単一の Name-Node におけるパフォーマンスを、改善する方法は存在する。 しかし、単一の名前空間サーバーの最適化を意図する、あらゆるソリューションはスケーラビリティを失う。

Looking into the future — especially taking into account that the ratio of small files tend to grow — the most promising solutions seem to be based on distributing the namespace server itself both for workload balancing and for reducing the single server memory footprint.

前向にいこう。 とりわけ、小さなファイルの比率が、増大していく傾向にあることを考慮に入れよう。 最も有望なソリューションは、ワークロードのバランスを取り、シングル・サーバーのメモリ・フットプリントを低減する、名前空間サーバー自体を分散していくという、方式に基づいて達成されると思われる。

I hope you will benefit from the information provided above. Please refer to the USENIX ;login: article for more details.

ここで提供した情報から、メリットが得られることを希望する。 詳細に関しては、 USENIX ;login: の記事を参照してほしい。

ーーーーー

konstantin_shvachko

Konstantin V. Shvachko
Hadoop Distributed File System (HDFS) Team, Yahoo!

ーーーーー

<関連>
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
ーーーーー
Hadoop DFS _ Introduction
NoSQL Ecosystem とは? _1

Tagged with: , , , ,

GIGAOM のクラウド調査:1位 AWS、2位 Rackspace、、、

Posted in Businesses, Rackspace, Research by Agile Cat on June 23, 2010

とても解り易いグラフでクラウドを分析
http://gigaom.com/2010/06/22/cloud-computing/

Gigaom

現在のクラウド・トレンドを簡潔にビジュアライズした、GIGAOM の素晴らしいレポートです。 それぞれの図をクリックして拡大し、詳細をご覧下さい。これぞ、一目瞭然です!

ーーーーー

① クラウドへ行くのか、デスクトップに留まるのか?

これは、2020年までに、どのような状況になるのかという意識調査なのでしょう。 クラウドへ行ってしまうに同意する人が 71% で、デスクトップに留まるに同意する人が 27% という結果になったようです。

Gigaom Cloud 1

② クラウドの成長率と、メジャー・プロバイダーについて

こちらは市場調査なのでしょう。 2008年の初頭から 2010年までの間に、ものすごい勢いでクラウドが成長している様子が分かります。 また、メジャー・クラウド・プロバイダーのランキングについても触れています。

Gigaom Cloud 2

③ クラウドへ対する投資

こちらも市場調査ですね。『1 案件あたりの平均投資額 x 案件数 = トータルの投資額 』となっています。

Gigaom Cloud 3

 

この他にも、とても興味深い調査結果が提供されていますので、ぜひ、本編を ど~ぞ!
http://gigaom.com/2010/06/22/cloud-computing/

ーーーーー

先日も、Twitter でちょっとした議論になったのですが、日本のメディアには 『 Amazon、Google、Microsoft、Salesforce による 4大クラウド』という図式が定着してしまい、その捉え方と現実が乖離しているように思えます。  まぁ、その他は日本市場に関係ないという見方もあるのでしょうが、もう少し、なんとかならないかなぁ ーーー A.C.

 

 

 

%d bloggers like this: