Agile Cat — in the cloud

Big Data と 音楽:Google Play の Music Timeline が スゴイ!

Posted in Big Data, Entertainment, Google by Agile Cat on March 27, 2014

Google analyzed our MP3 libraries to visualize the evolution of music
http://wp.me/pwo1E-7m1
By Derrick Harris – JAN. 16, 2014
http://gigaom.com/2014/01/16/google-analyzed-our-mp3-libraries-to-visualize-the-evolution-of-music/

_ Giga Om
Summary: Google knows a lot about what people listen to because its Play Music service knows what’s in users’ MP3 libraries. A new tool lets people investigate which albums, artists and genres are most popular over time.

Summary: Google は、人々が聴いている音楽について、たくさんのことを知っている。なぜなら、その Play Music サービスを介して、ユーザーの MP3 ライブラリの内容を調べられるからだ。新しいツールが提供されたことで、最も好まれてきたアルバム/アーティスト/ジャンルなどを、一定の時間軸の中で調べられるようになった。

ーーーーー

Google Play knows a lot about what its users listen to, and on Thursday Google shared some of those insights via a new tool called Music Timeline. It’s an interactive feature that shows the popularity of genres over time, as well as the popularity of subgenres and artists within them. It’s also a great way to show off Google Play as a worthy competitor to more widely used streaming services such as Spotify or Pandora, or more popular MP3 stores such as iTunes.

Google Play は、人々が聴いている音楽について、たくさんのことを知っている。 そして、この木曜日(1/16)には、Music Timeline と呼ばれる新しいツールを用いて解析した、一部の情報を Google は開示している。それは、インタラクティブな機能を持ち、経過する時間の中で、人々に好まれているジャンルを示し、さらには、人気のサブ・ジャンルやアーティストなども示してくれる。それは、Spotify や Pandora などの著名なストリーミング・サービスに対して、さらに言えば、iTunes などの一般的な MP3 ストアに対して、Google Play を強力なライバルとして誇示する、素晴らしい方法でもある。

This type of knowledge is a big deal. As I explained earlier this month, the battle to become the world’s dominant streaming service is heating up as more listening goes digital. Google is a late-comer, but one with some serious potential.

この種のナレッジは、きわめて価値のあるものとなる。 今月の初めに説明したように、音楽のデジタル化が進むにつれて、この世界を支配しようとするストリーミング・サービス間での戦いが激化していく。 その意味で、Google は後発であるが、いくつかの、強力なポテンシャルを秘めたチャレンジャーである。

I don’t know how Google Play’s recommendation algorithms work, but it seems like Google could make a pretty good first hack at classifying someone’s taste just by comparing his or her MP3 library against the aggregate data it has gathered as a part of Timeline. If the Metal line on my graph is disproportionately thick, it probably says something about what I like to hear. Add to that information about what I stream, and the picture becomes clearer.

Google Play のリコメンデーション・アルゴリズムが、どのように動作しているのか、理解しているわけではない。しかし、Timeline の一部として収集されたデータと、自分の MP3 ライブラリを比較することで、好まれているものを分類するという点で、Google は最初から、かなり良い仕事をしているように思える。私のグラフにおいて、Metal の項目が不釣り合いに分厚いなら、おそらく、私が知りたいことについて、何かを言っていることになる。そして、私がストリーミングしている楽曲を追加するにつれて、それを示すチャートが鮮明になっていく。

Across all industries, companies are figuring out how to turn the data they’re collecting into better products. In fact, that’s one of the driving themes of our Structure Data conference in March.

あらゆる産業において、それぞれの企業は、収集してきたデータを、より良い形でプロダクトに転化する方式を考え出そうとしている。実際のところ、昨年の 3月に開催した Structure Data カンファレンスにおいても、それは重要なテーマであった。

Anyhow, here are some screenshots of Music Timeline to highlight the types of things it will let you dig into. Overall, rock and pop music are very popular.

以下に並べていくのは、各種の情報をハイライトで表示する、Music Timeline のスクリーン・ショットであり、そこから深堀りしていくことが可能になる。 全体的に見ると、Rock と Pop に、人気が集まっている。

_  space

_  space

In thrash metal, one of my favorite genres, Metallica dominates.

私の、お気に入りジャンルである、Thrash Metal では Metallica が支配的である。

_  space

_  space

Here’s the career arc of one of my favorite bands, Corrosion of Conformity. I must be the only one who bought its last album.

以下は、私の好きなバンドである、Corrosion of Conformity の勢力を示す曲線である。その最後のアルバムを買った1人として、私がいるはずだ。

_  space

_  space

Of course, this is what a long, successful career looks like. I only wish Music Timeline featured relative comparisons, so we could compare the Rolling Stone to less-popular artists like, well, Corrosion of Conformity to see how they stack up. I suspect even Voodoo Lounge is much more popular overall than COC’s most-popular album. Guess there’s no accounting for taste.

もちろん、このチャートは、長期間における成功のキャリアを示すものである。私が Music Timeline に望むのは、相対的な比較のための機能である。したがって、メジャーな Rolling Stone と、マイナーな Corrosion of Conformity を、並べて比較してみた。私の疑念は、Voodoo Lounge の方が、COC で最も人気のアルバムよりも、売れているだろうというものだ。推測するに、好みに関する正確さというものは、存在しないのだ。

_  space

_  space

Related research

How the consumer space battled licensing issues in the fourth-quarter 2013
How to compete with Facebook in 2013

ーーーーー

TAG indexこの、MP3 の再生回数に関するチャートは、すでに いくつかのメディアで取り上げられていますが、やはり Google の Big Data は強いなぁ、、、と感じさせられますね。 そして、音楽ですが、最近の Youtube の充実ぶりは素晴らしく、それと、このような分析が加わると、iTunes もウカウカしてはいられなくなりそうです。 なんというか、この領域だけは、Google 先生には攻め込んでほしくないという気持ちもありますが、逆に iTnunes が更に充実という展開になるかもしれません。 いろいろな局面で起こっている AG 対決ですが、ここも注目ですね!image

ーーーーー

<関連>

YouTube が 30分もダウンした : しかし、世界は いつも通りだった
Google の 音楽ナレッジ・グラフが、YouTube や Google Now と連動し始めた!
iTunes の収益構造を解析する
Final Fantasy VI が、この秋には iOS に登場する!

Hadoop と Big Data の調査:企業ユーザーが指摘する問題点は、信頼性/使い易さ/ソリューションの欠落

Posted in Big Data, Hadoop, Research by Agile Cat on February 24, 2014

Hadoop and Big Data: Businesses Frustrated by Lack of Reliable, User-Friendly and Secure Solutions
http://wp.me/pwo1E-7eV

By Dick Weisinger – February 17th, 2014
http://formtek.com/blog/hadoop-and-big-data-businesses-frustrated-by-lack-of-reliable-user-friendly-and-secure-solutions/

_ formtek

While Big Data technologies made big headlines in the tech press in 2013, by the end of the year, the adoption of Big Data technologies across many businesses was only relatively modest. A survey by the SandHill group of a cross-section of global businesses found that:

Big Data テクノロジーは、2013年のハイテク・プレスで大きな話題をさらい、その年末までヘッドラインを賑わしていたが、大多数の企業における Big Data の採用となると、比較的に控えめであった。グローバル・ビジネスを横断的に見ている、SandHill Group の調査では、以下のような論点が見出されている:

  • 44 percent said that they are still in the exploration and education phase of Big Data technologies
  • 16.3 percent are conducting proof of concept trials
  • 11.1 percent are developing their first Hadoop-based applications
  • 回答者の 44% は、Big Data テクノロジーについて、依然として探求と教育の段階にあると述べている
  • 16.3% は、POC(proof of concept)トライアルを実施していると言っている
  • 11.1% は、自身にとって初めての、Hadoop ベース・アプリケーションを開発していると述べている

Not only has adoption been relatively slow, the types of solutions created to date have tended to be relatively mundane — Matt Assay comments that “by far the biggest use of Hadoop to date has been as a poor person’s ETL”.

その採用が、相対的に見て遅れているだけではなく、これまでに開発されたソリューションのタイプも、ありきたりのものあった。 それについて、Matt Assay は、「 これまでの Hadoop の用途において、群を抜いて多いのは、貧しい人々のための ETL(Extract, Transform, Load)である」と述べている

While there is a strong interest in the potential of Big Data from the business side of organizations, many are frustrated by usability issues of the technology.  A survey of business executives taken by 1010data, for example,  found that a majority feel that they are locked out of Big Data technologies like Hadoop.  53 percent said that Big Data solutions aren’t addressing the needs of business users.  49 percent said that current Hadoop-based solutions are too complex and that they’d like to see solutions for Big Data that have “fewer moving parts”, and 62 percent said that in order for them to more effectively use Big Data technologies like Hadoop to solve business problems that they need to be better educated about how the technology works.

ビジネス・サイドの組織からは、Big Data の可能性に強い関心が示されているが、その中の多くが、このテクノロジーのユーザビリティに対して不満を感じている。 1010data が実施した 企業エクゼクティブに対する調査では、その大多数が、Hadoop のような Big Data テクノロジーを、閉鎖的なものだと捉えられていることが分かった。 また、53% は、ビジネス・ユーザーのニーズに取り組んでいる、Big Data ソリューションが存在していないと述べている。 49% は、現在の Hadoop ベース・ソリューションについて、あまりにも複雑すぎると考え、また、Fewer Moving Parts を有する Big Data ソリューションを探したいと言っている。 そして、62% は、ビジネス上の問題を解決するために、Hadoop のような Big Data テクノロジーを用いるには、このテクノロジーが機能する方式について、より適切な教育が必要だと述べている。

Specifically, the 1010data survey considered how the latest Hadoop 2.0 release can improve business solutions.  Hadoop 2.0 includes YARN which allows Hadoop resources to be managed for multiple jobs running across an array of servers.  But business executives aren’t yet convinced that the technology is ready for prime time.  45 percent of them are worried about reliability.  42 percent say that they have major concerns about costs, and 35 percent say that there is still too much low-level coding required to apply the technology to business solutions.  41 percent say that Hadoop is still too new and not yet as stable as other existing technologies.

具体的にいうと、1010data の調査は、Hadoop 2.0 という最新リリースにより、ビジネス·ソリューションを改善する方式を検討するために実施されている。Hadoop 2.0 には YARN が取り込まれているが、それにより、なんらかのサーバー・アレイを横断するかたちで実行される複数のジョブのために、Haddop リソースを管理できるようになる。 しかし、企業エクゼクティブたちは依然として、このテクノロジーが最盛期を迎えるための、準備を整えているとはと確信していない。 そのうちの、45% は信頼性について心配し、42% はコストを最大の懸念としている。 そして、35%は、このテクノロジーをビジネス・ソリューションに適用するには、依然として低レベルのコーディングが必要だと述べている。 さらに 41% は、Hadoop は新し過ぎて、その他の既存テクノロジーのように、安定していないと言っている。

But software developers and integrators are well aware of the problems.  It’s likely that 2014 will see a surge in Big Data product offerings and add-ons that specifically try to create an improved experience for users.

しかし、ソフトウェアのデベトッパーやインテグレーターは、この問題を、よく理解している。そして、2014年には、Big Data のプロダクトとアドオンが急増し、とりわけ、その利用者に対して、改良されたエクスペリエンスが提供されると思われる。

ーーーーー

TAG index2009年10月に開催された、最初の Hadoop World NYC から、すでに 4年半の歳月が流れているのですね。 その頃は、もっと早く、Hadoop の事例が増えてくると思っていましたが、エンタープライズ・ユーザーにまで広がるには、まだまだ取り除かれるべき障壁が多いのだと、この記事を訳していて感じました。 いろいろな意味で、ちょっとガッカリする数字が並んではいますが、もう一息で、そのカベも乗り越えられるでしょう。 ガンバレ Hadoop & Big Data です! image

ーーーーー

<関連>

IoT の調査:ビジネスに革命をもたらすテクノロジーではあるが、まだまだ課題が山積みだ
Mobile の調査: 2014年の中小企業は、PC を捨て始めるかもしれない
Enterprise の調査:ここでもソーシャル・ネットワークが 急成長している
Cloud の調査:これからの2年間で、Top-100 プロバイダーの 25% が買収される
Open Data の調査:年間で 500兆円の 経済効果が 見いだせる?

Google Maps の底力:膨大なデータを用いて、目的地までの時間を予測する!

Posted in Big Data, Google, Mobile, Post-PC, Research by Agile Cat on January 8, 2014

Ex-Google Engineer Reveals How Google Maps Figures Out Destination Times
http://wp.me/pwo1E-75C
Paul Szoldra  Dec. 28, 2013
http://www.businessinsider.com/google-maps-times-2013-12

_ Business Insider

When you search for directions using Google Maps, there are a variety of factors at play in determining when you’ll actually arrive, according to a former Google engineer.

元 Google エンジニアの話によると、Google Maps を用いて行き先を検索するとき、実際に到着する時刻を判断するための、さまざまな機能が動き出すらしい。

In a post on Quora recently spotted by 9to5Mac, ex-Google engineer Richard Russell reveals more of what that is:

先日に、9to5Mac が見つけ出した Quora のポストにおいて、元 Google エンジニアの Richard Russell が、その詳細を明らかにしている:

"Like in similar products, Google maps ETAs are based on a variety of things, depending on the data available in a particular area. These things range from official speed limits and recommended speeds, likely speeds derived from road types, historical average speed data over certain time periods (sometimes just averages, sometimes at particular times of day), actual travel times from previous users, and real-time traffic information. They mix data from whichever sources they have, and come up with the best prediction they can make.

その他のプロダクトと同様に、Google がマッピングする ETA( Estimated Time of Arrival)は、特定のエリアで利用可能なデータに応じて、さまざまな機能を成り立たせる。それらの範囲は、法的な速度制限/推奨される速度/道路の種別に応じた速度/一定期間における平均速度データ(平均速度や、朝晩の速度など)/先を走るユーザーから得られる実際の移動時間、リアルタイムな交通情報などになる。そして、それらの情報源からのデータを混ぜ合わせることで、最も適切と思われる、予測値を導き出す。

Most companies who do live traffic compare their predictions against actual time in traffic to tune their algorithms and data sources. The likely result of this is that the companies who have access to the best usage data (ie those who are best able to compare their predictions against reality, which means those who have the most usage) are likely to end up with the best predictions in the medium to long term.”

ライブ・トラフィックに取り組む大半の企業は、自身のアルゴリズムとデータソースをチューニングするために、実際のトラフィック・データと予測値を比較する。その結果として起こり得ることは、最も利用価値の高いデータへのアクセス権を持つ企業が、中長期的にみて、最も適切な予測をもたらす可能性が高いということである(言い換えれば、最も多くの人々に利用されるデータを持つ企業が、最も適切に予測と現実を比較できる)。

In short, there’s a ton of data Google is calculating just to tell you that your destination may happen to be 10 minutes away. The company also revealed more on how crowdsourced traffic data helps make Maps even more accurate in 2009.

簡潔に言うと、目的地まで 10分の距離に、あなたが居ることを伝えるために、Google は膨大な量のデータを計算できるということだ。また、同社は、クラウドに集められたトラフィック・データが、より正確な Maps を作り出すことを、2009年の時点で明らかにしている。

"When we combine your speed with the speed of other phones on the road, across thousands of phones moving around a city at any given time, we can get a pretty good picture of live traffic conditions," wrote Dave Barth, product manager for Google Maps.

「 あなたの車速と、道路上を移動する他者スマホの速度を組み合わせると、その街の中を移動する数千のスマホに横串を指すかたちで、リアルタイムの交通状況の、きわめて正確な全体図が得られる」と、Google Maps の Product Manager である Dave Barth は述べている。

Of course, no matter how much data is involved, the time you get will likely never be perfect. As Russell writes, calculating ETAs "is a future-prediction problem, and traffic, while it follows certain patterns, is inherently unpredictable.”

もちろん、どれだけのデータ量があろうとも、予測される時間が完璧になることはあり得ないだろう。Russell が述べているように、「 将来予測の問題であり、トラフィックが特定パターンに従うとしても、本質的に予測が不可能 」なものが、ETA の計算なのである。

ーーーーー

image月曜日の Engadget に、「Google、自動車のAndroid化を目指す団体 Open Automotive Alliance を結成。Audi・GM・ホンダ・現代・NVIDIA参加」という記事が出ていて、Agile_Cat の周辺には、それに注目する人が多かったように感じていました。この OAA の目的は、「 モバイル業界での Android の成功を自動車に持ち込み、オープンでカスタマイズでき、スケーラブルかつ安全なプラットフォームを通じて自動車のイノベーションを加速すること 」とされています。 しかし、Android はオープンでも、Google Maps はクローズドです。 そして、Google のビジネスは、スマホの時と同様に、ここにあるのです。__AC Stamp 2

ーーーーー

<関連>

Google Maps は Big Data を使いこなすが、Apple Maps には それが出来ない
速報: 新しい Google Maps が、Web と iPad で動き始めた!
新しい Google Maps が絶好調 : Android に続いて iOS にも提供!
Google Maps の広告が、Twitter に掲載される事情とは?
Google Maps が Apple アップ・ストアに登場した : 前より Good だ!

Hadoop 2 がリリースされた : MapReduce から YARN へ移行

Posted in .Selected, Apache, Big Data, Google, Hadoop, MapReduce by Agile Cat on October 17, 2013

Apache Software Foundation unveils Hadoop 2, replacing MapReduce with YARN
http://wp.me/pwo1E-6MQ

Loek Essers, IDG News Service @loekessers – Oct 16, 2013
http://www.pcworld.com/article/2055140/apache-software-foundation-unveils-hadoop-2-replacing-mapreduce-with-yarn.html

image

The Apache Software Foundation unveiled its latest release of its open source data processing program, Hadoop 2. It runs multiple applications simultaneously to enable users to quickly and efficiently leverage data in multiple ways at supercomputing speed, Apache said Wednesday.

Apache Software Foundation が、そのオープンソース・データ処理プログラムである、Hadoop 2 の最新リリースを発表した。水曜日の Apache の説明によると、マルチ・アプリケーションの同時実行が達成されることで、ユーザーは各種の方式を用いて、しかもスーパー・コンピューターの速度で、そのデータを迅速かつ効率よく活用できるようになる。

Apache Hadoop is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It enables organizations to more efficiently and cost-effectively store, process, manage and analyze the growing volumes of data being created and collected every day.

Apache Hadoop は、シンプルなプログラミング·モデルを用いて、しかもコンピュータやクラスタを横断するかたちで、大規模データの分散処理を実現するフレームワークである。それにより、毎日のようにデータを収集/作成していく組織は、増え続ける情報の保存/処理/管理/分析を、効率よく低コストで達成していける。

Hadoop is deployed at enterprise organizations around the globe, including Amazon Web Services, AOL, Apple, eBay, Facebook, Netflix and Hewlett-Packard.

現時点において Hadoop は、Amazon Web Services/AOL/Apple/eBay/Facebook/Netflix/Hewlett-Packard といった、世界中のエンタープライズに展開されている。

The latest version of the platform, released Wednesday, has been more than four years in the making and has a number of new components. Most notable is the addition of YARN, (Yet Another Resource Negotiator), which is a successor to Hadoop’s MapReduce. The new version splits major functions into two separate daemons, with resource management in one, and job scheduling and monitoring in the other.

水曜日にリリースされた、このプラットフォームの最新バージョンは、その製作に 4年以上の歳月をかけ、また、いくつかの新しいコンポーネントを取り込むものとなる。その中でも、最も注目すべきは、Hadoop における MapReduce の後継者となる YARN(Yet Another Resource Negotiator)である。この新バージョンでは、主要な機能を、2つの Deamon に分割している。その 1つは、Resource Management であり、もう 1つは Job Scheduling and Monitoring となる。

Apache Software Foundation

YARN sits on top of the HDFS (Hadoop Distributed File System) and serves as a large-scale, distributed operating system for big data applications, enabling multiple applications to run simultaneously for more efficient support of data throughout its entire lifecycle, Apache said in a news release. Hadoop 2 and YARN gives users the ability to mix batch, interactive and real-time workloads within a stable foundational part of the Hadoop ecosystem, it said.

YARN は HDFS(Hadoop Distributed File System)の上に配置され、Big Data アプリケーションのための、大規模/分散オペレーティング・システムとして機能する。 それにより、ライフサイクル全体を通して、データを効率よくサポートとしていく、マルチ・アプリケーションの同時実行が可能となると、Apache はニュース・リリースで述べている。 そして、Hadoop 2 と YARN がユーザーに提供するものとして、バッチ/インタラクティブ/リアルタイムのワークロードなどを混在させる能力を、Hadoop エコシステムの安定した基盤を用いて実現することを挙げている。

Apache also refers to YARN as MapReduce Version 2. It retains API compatibility with the previous version, and applications written for MapReduce will run on YARN if recompiled, the foundation said.

また、Apache は YARN について、MapReduce の Version 2 だとしている。 つまり、これまでのバージョンとの API 互換を保持し、再コンパイルさえすれば、MapReduce 用のアプリケーションを YARN 上で実行できると、同ファンデーションは述べている。

More than a dozen Apache projects integrate with Hadoop, and ten more are about to follow, Apache said.

1ダース以上の Apache プロジェクトが Hadoop と統合されているが、その大半が、新たなプラットフォームに移行すると、Apache は述べている。

The General Availability (GA) release of Hadoop 2 follows a preview distribution that was released in June, that also included YARN. Apache Hadoop 2 will be released under the Apache License v2.0.

Hadoop 2 の General Availability (GA) リリースは、6月にリリースされたプレビューに、つまり YARN が含まれていたディストリビューションに従うものとなる。なお、Apache Hadoop 2 は、Apache License v2.0 の下でリリースされる。

ーーーーー

image Hadoop に関するポストというと、かなり久々のことなのですが、当然のものとして、広く浸透していることの、証明なのかもしれません。 昨年の、Apple Maps 騒動のときに、Wired が 面白い記事をポストしていました。 そこには ーーー このバトルの背景は、たった 2つの言葉で説明できる。 つまり、Google は Big Data を使いこなし、その一方で Apple は、Big Data を急いで準備している段階にある。ーーー という、とても分かりやすい一文が記されていました。そして、Hadoop も、ついに新世代なのですね。 ほんと、期待大です!image

ーーーーー

<関連>

IDC:データ分析市場は、2016年までに $51 B ビジネスに成長する
Facebook と Hadoop : どのように 100 Peta Byte ハンドリングするのか?
Facebook にストアされた 100 PB イメージ・データは、写真にすると 6,660 億枚になる!
ついに、Hadoop for Windows がデビューするらしい
Hadoop 王国は、戦国時代へと 突入する?

 

クラウドから特許を追放するって、ステキ すぎます Google 先生

Posted in .Selected, Big Data, Data Center Trends, Google, Patent by Agile Cat on October 2, 2013

Google donates 79 more patents to shield the cloud from lawsuits
http://wp.me/pwo1E-6J7
By Jeff John Roberts – AUG. 8, 2013
http://gigaom.com/2013/08/08/google-donates-79-more-patents-to-shield-cloud-from-lawsuits/

_ Gigaom

Summary: Google has taken an important new step in its effort to carve out a space where cloud computing innovators can work without fear of being sued.

Summary: Google は、クラウドにおけるイノベーションが訴訟により妨げられないよう、その空間を切り開くという試みへ向けて、きわめて重要な一歩を踏み出した。

ーーーーー

Google is ramping up its campaign to protect the cloud from the sort of nuisance patent lawsuits that have engulfed the smartphone and app-developer industries.

Google は、ある種の厄介な特許の問題から、つまりスマホとアプリの開発者や産業を巻こむ訴訟から、クラウドを保護するためのキャンペーンの手はずを整えている。

photo: alphaspirit

On Thursday, the company designated 79 more patents to be part of its “Open Patent Non-Assertion Pledge,” which amounts to a non-aggression pact under which anyone can use the technology described in the patents — anyone, that is, who doesn’t use patents to attack Google first.

木曜日(8/8)に同社は、Open Patent Non-Assertion Pledge(オープン特許非係争条項)一環として 79 種類以上の特許を指定し、それぞれの特許に記載されたテクノロジーを、誰もが利用できるという非訴訟協定のもとに置くとした。 ただし、Google を最初から攻撃しようとする者は、それらの特許を使用しないだろう。

The news, announced in a blog post, is significant because the patents relate to essential elements of “big data,” which is one the most important fields in technology right now. Google hopes the newly added patents, which it acquired from IBM and CA Technologies, expand the areas of cloud software in which developers can innovate without fear of being sued.

このブログ・ポストで発表されたニュースが重要なのは、それらの特許には Big Data が、つまり、現在のテクノロジーにおける最重要分野に関連する、本質的な要素も含まれるからだ。さらに Google は、IBM と CA Technologies から取得した特許も、ここに加えたいとしている。それによりデベロッパーは、訴訟を恐れることなく、クラウド·ソフトウェア領域におけるイノベーションを拡大できる。

When the company announced the non-aggression pact in March, the pledge applied to just 10 patents related to MapReduce and Hadoop programming models. The new patents, according to a source at Google, cover different areas related to data-center technologies. In particular, they cover methods for operating data centers efficiently and for so-called “alarm monitoring.”

今年の 3月に、同社が非訴訟協定を発表したときは、MapReduce と Hadoop のプログラミング・モデルに関連する、わずか 10 特許に対して、その誓約が適用されていた。Google 内の情報源によると、新たに追加された特許は、データセンター・テクノロジーに関連する、さまざまな分野をカバーするようだ。そして、効率よくデータセンターを運用するための方式や、いわゆる Alarm Monitoring などをカバーする点が、注目を集める。

As we’ve noted before, Google’s non-aggression pact is no magic bullet to stop nuisance cloud-based lawsuits, in part because it provides little deterrent to so-called trolls — shell companies, often backed by lawyers and private investors, that do nothing but acquire old patents in order to file lawsuits.

ただし、以前に指摘したように、Google の非訴訟協定は、厄介なクラウド訴訟を排除できるという特効薬ではなく、トロールと呼ばれる小さな荒らしをもたらす者は止められないだろう。それらのペーパー・カンパニーは、古い特許を取得する以外に何もしないが、弁護士や民間投資家に支えられながら、随所で訴訟を繰り返していく。

But overall, the expanded pact is good news because it promotes the idea of a technological open space in which anyone can use the basic building blocks of cloud computing. A similar open model, in the case of copyright, has already proved essential for developing a wide variety of common software; under the open GNU license model, developers contribute a common pool of code that anyone can use.

しかし、全体を見れば、誰もがクラウド·コンピューティングの基本的なビルディング·ブロックを使用できる、テクノロジー・オープンスペースのアイデアを促進するため、この拡張された協定は朗報である。類似のオープンモデルは(Copyright の範囲において)は、一般的なソフトウェアを幅広く開発するために、不可欠な存在であると、すでに証明されている。つまり、オープン な GNU ライセンス・モデルにしたがい、誰もが利用できるコードが、共有のための枠組みの中にコントリビュートされているのだ。

The Google initiative also coincides with a growing push by tech companies to push back against people who abuse the patent system. These abusers include lawyer Erich Spangenberg, who makes $25 million a year from patent trolling, and boasted to the New York Times about how he “goes thug” on companies that resist his demands.

この、Google の構想は、特許制度を乱用する人々を押し返そうという、ハイテク企業の成長を支える勢力とも一致している。これらの、特許を乱用すると言われる弁護士には、トローリングで $25 million/年を稼ぎ出す Erich Spangenberg も含まれる。なにせ、自身の要求に抵抗する企業を、どうやって脅すのかと、彼は New York Times に自慢しているのだ

In response to the trolling problem, cloud-computing provider Rackspace is putting its money on the line to fight a troll that claims to own basic mobile technology. And social media firm Twitter has created the “Innovator’s Patent Agreement” to assure its engineers that it won’t use their work for future patent trolling.

トローリングの問題に対応するため、クラウド・プロバイダーである Rackspace は、基本的なモバイル・テクノロジーを所有すると主張する、あるトロールと戦うために、すぐにでも使える現金を用意している。また、ソーシャル・メディアの Twitter は、自身のエンジニアたちに対して、彼らの作品を将来的にトローリングなどに使用しないと約束する、Innovator’s Patent Agreement を作成している。

Google says it hopes other companies will also contribute to the pool of patents that form the Open Patent Non-Assertion Pledge.

Google は、他の企業に対しても、Open Patent Non-Assertion Pledge に特許を提供するよう呼びかけている。

Related research

ーーーーー

google-55a

もう、2年前の話になりますが、Google が Motorola の買収へと至るプロセスの中で、Nortel の知的財産権を購入した企業グループは、このようなオープン化の動きを一番恐がっていたのだと思います。 ここで説明する必要もないですが、知的財産の保護は重要であり、また、イノベーションを停滞させるという副作用も持ちます。昨年の Java をめぐる係争で、Oracle の訴えをはねつけた米司法当局も、イノベーションを優先した、ということなのでしょうかね? __AC Stamp 2

ーーーーー

<関連>

Java と Android をめぐる Oracle と Google の争い : API の適正な用法とは?
Google が IBM からの特許取得を拡大 – Oracle への反撃は?
Google は IBM から、1030 個の特許を取得する!
Google Drive をめぐる特許問題と、その背景を考察する
Microsoft のパテント・トローリング戦略とは
Android 特急は、パテント攻撃により脱線してしまうのか?
アメリカ独占禁止法当局が、Nortel の特許売却を調査?
Apple と Google に妥協点はあるのか : Tim と Larry が水面下で協議を継続?
Microsoft と Oracle の提携 : その骨子が明らかになった!
モバイル特許の相関図は 込み入っていて、まるで地下鉄マップのようだ!

 

Facebook の News Feed は、どう 変わったのか? なぜ 変わったのか?

Posted in .Selected, Big Data, Facebook, Open Graph by Agile Cat on August 13, 2013

Facebook Just Made A Major Change To What Users See On The Site
http://wp.me/pwo1E-6uh

Nicholas Carlson – Aug. 6, 2013
http://www.businessinsider.com/facebook-just-changed-the-kinds-of-stories-youll-see-when-you-re-load-your-news-feed-2013-8

_ Business Insider

Facebook just changed the most important feature on the site – the "News Feed." The News Feed is the first thing you see every time you go to Facebook.com or open your Facebook app.

Facebook は、同サイトにおける最も重要な機能である、"News Feed" を変更した。この News Feed は、Facebook アプリを介して、あなたの Facebook.com がオープンされるたびに、最初に表示されるものでもある。

This is what the Facebook algorithm looks like. (Not really)

It’s a column of what Facebook calls "stories" photos, status updates, links, and whatever else your friends are sharing or doing. The process Facebook goes through to decide what to show you in that feed is pretty complicated. For the average Facebook user, there are about 1,500 "stories" could go in the column every time they open Facebook.

それは、Facebook が Stories と呼ぶものであり、あなたのトモダチが共有する、フォト/ステータス/リンクといった、あらゆるものをカラムとして構成している。つまり、そこで Facebook が実施するプロセスは、フィードとして何を見せるのかを決定するものであり、また、かなり複雑になり得るものでもある。そして、平均的なユーザーの場合、Facebook を開くたびに 約 1500 の Stories が、カラムの中に取り込まれることになる。

Until today, Facebook sorted those stories for you using the following process.

これまでの Facebook は、以下のようなプロセスを用いて、あなたの Stories をストアしてきた。

  1. It takes all the stories created since your last visit.
  2. It scores these stories based on factors. If the person who posted the story is close to you, it gets a higher score. If it has a lot of comments and likes, it gets a higher score. It’s a photo, which people love to look at, it gets a higher score.
  3. Then Facebook would sort those stories by their score.
  1. 前回の訪問時に作成された、すべての Stories を取り込む。
  2. 続いて、それぞれの Stories は、その要因に基づいてスコアを割り振られる。Stories の投稿者が、あなたと親しい場合には、そのスコアは高くなる。 また、イイネやコメントが、たくさん付いた Stories も、そのスコアが高くなる。 さらに、人々が見たがるフォトは、最も高いスコアを取得する。
  3. つまり、Facebook は、こうしたスコアをベースにして、Stories をソートしているのだ。

If you come back an hour later, Facebook would go through the same process again crucially, starting once more with all the new stories created since your last visit.

あなたが、1時間後に Facebook に戻ってくる場合、このプロセスを再現することが重要だと考えられており、前回の訪問時に作成された全ての Stories から、もう一度 スタートするようになっていた。

The big change Facebook announced today is that now, when you come back, Facebook’s story scoring and ranking algorithm will look at all of the stories you have never seen, not just the stories created since you last visited.

今日、Facebook が発表した、大きな変更が行われると、あなたが Facebook に戻ってくる時に、Facebook Stories におけるスコアとランキングのアルゴリズムが、まだ参照されていない、すべての Stories を探し出すようになる。また、それは、あなたが最後に訪問した以降に作成された、Stories に限定されるというものでもない。

In practice, that means if there was a story in your News Feed before, but you missed it because you didn’t scroll down to see it, Facebook will put it up top the next time you visit the site if Facebook believes that story is more relevant to you than all the new ones created since you last checked the site.

実際のところ、以前にスクロール・ダウンしなかったので、まだ見ていない News Feed が残されている、という場合に、この新しい方式に意味が生じてくる。つまり、あなたが最後にチェックした後に作成された、すべての新しい Stories よりも、あなたにとって重要だと Facebook が判断した Stories が、News Feed のトップに表示されることになる。

Facebook calls this tweak to its algorithm "story bumping."

Facebook は、この新しいアルゴリズムのことを、"Story Bumping" と呼んでいる。

Another change to the News Feed that Facebook announced today is that it will now examine your 50 most recent actions on the site, and promote stories that seem to be your most current interest. If you "like" a specific person’s status updates one morning, you’re more likely to see a bunch more of them the rest of that day. The company calls this tweak "Last Actor."

今日、Facebook が発表した、News Feed に関するもう 1つの変更点は、あなたがサイト上で実行した、最新 50個のアクションが検証されるというものだ。つまり、あなたの最新の関心事と思われる Stories が、それをベースに抜き出されることになる。たとえば午前中に、特定のトモダチのステータスにイイネを付けているなら、その日の午後に、追加されたイイネの固まりを、目にする可能性が高くなる。同社では、この取り組みを、"Last Actor" と呼んでいる。

ーーーーー

TAG index先月は、Facebook の新しいストレージ戦略である TAO について、『Facebook が発表した TAO : これで MySQL と Memcached を接続する』と『Facebook の超高速ストレージ : TAO の詳細を説明しよう』という抄訳でご紹介しました。そこでも説明されていましたが、Facebook では Hot Data と Cold Data を使い分け、この巨大なサービスで取り扱うデータの、整合性を図っているとのことです。 そして、そのベースとなるのが、以下のリンクにある Open Graph であり、そのインフラとしての Open Compute ということになります。 10億人以上のユーザーを抱えながら、News Feed という複雑なインターフェイスを、いとも簡単に切り替えてしまう (簡単ではないですが :) )、Facebook の底力を感じてしまいますね。image97

ーーーーー

<関連>

Facebook の Open Graph とは? その歴史から説明しよう
Facebook は Open Graph へと ユーザーを誘う
Intel の Open Compute にかける意気込みがスゴイ : 100G Photonics だ!
やったぜ! Facebook の Open Compute Project がオープン・スイッチに挑戦だ!
Facebook の 超絶 Web パフォーマンス : その秘密を解析する

 

CIA の Prism と Big Data : 作り方を 見積つきで 教えましょう

Posted in .Selected, Big Data, Government, Strategy by Agile Cat on August 6, 2013

PRISM: The Amazingly Low Cost of ­Using BigData to Know More About You in Under a Minute
http://wp.me/pwo1E-6sD
Monday, July 1, 2013
http://highscalability.com/blog/2013/7/1/prism-the-amazingly-low-cost-of-using-bigdata-to-know-more-a.html

_ highscalability

This is a guest post by BugSense Founder/CTO Jon Vlachogiannis and Head of Infrastructure at BugSense Panagiotis Papadomitsos.

これは、BugSense の Founder/CTO である Jon Vlachogiannis と、Head of Infrastructure である Panagiotis Papadomitsos からの、ゲスト・ポストである。

ーーーーー

There has been a lot of speculation and assumptions around whether PRISM exists and if it is cost effective. I don’t know whether it exists or not, but I can tell you if it could be built. Short answer: It can.

PRISM の存在について、さまざまな憶測や仮定があり、コスト的に見合うものなのかという声もあった。私には、その存在について知る由がないが、それを構築できるのか、できないのか、については言及できる。 端的に言えば、その構築は可能である。

If you believe it would be impossible for someone with access to a social "datapool" to find out more about you (if they really want to track you down) in the tsunami of data, you need to think again.

誰かがソーシャルの "データプール" へアクセスし、その津波のようなデータの中から、アナタについて調べたいと思っても(彼らは真剣になってアナタを追跡する)、そんなことは不可能だと思うなら、もう一度考える必要がある。

Devices, apps and websites are transmitting data. Lots of data. The questions are could the data compiled and searched and how costly would it be to search for your targeted data. (hint: It is not $4.56 trillion).

デバイスおよび、アプリケーション、Web サイトから送信されるデータは、大量のデータとなる。

ここでの問は、データの変換/検索が可能かどうかと、ターゲットとなるデータの検索に、どのくらいのコストが必要かという点である(ヒント:$4.56 trillion ということはない)。

Let’s experiment and try to build PRISM by ourselves with a few assumptions:

さぁ、以下に並べた、いくつかの過程を用いて、私たちの PRISM を構築してみよう:

  • Assumption 1: We have all the appropriate "data connectors" that will provide us with data.
  • Assumption 2: These connectors provide direct access to social networks, emails, mobile traffic etc.
  • Assumption 3: Even though there are commercially available solutions that might perform better for data analysis, we are going to rely mostly on open source tools.
  • Assumption 1:  私たちは、すべての適切な "データ・コネクター" を入手しており、そこからデータが提供される。
  • Assumption 2:  それらのコネクターにより、Social Network/Email/Mobile Traffic にダイレクト・アクセスできる。
  • Assumption 3:  より適切なデータ分析を提供する市販ソリューションがあるが、私たちは、主として OSS のツールを活用するつもりだ。

With those assumptions, how much would it cost us to have PRISM up and running and to find information about a person in less than a minute?

これらの仮定に基づいて、PRISM を所有/稼働させ、特定の人物に関する情報を、1分以内に探しだすときに、どの程度のコストが必要になるのだろう?

Let’s begin with what data is generated every month that might contain information about you.

まず、その人物の情報を含む1ヶ月間のデータが、どれほどの量で生成されているのかを試算しよう。

DATA

Facebook: 500 TB/day * 30 = 1.5 PT/month (source)
Twitter: 8 TB/day * 30 = 240 TB/month 8 TB/day (
source)
Email/Other info: 193PT/month Google says 24 PB per day (2008). Five years later lets assume this is 8 times bigger = 192 PB. Now, real user information is 1/3 = 64 PT/day (
source)
Mobile traffic/machine­to­machine exchanges/vehicles etc: 4000 TB per day = 117 PB/month (
source)

Total Data =~312PB month

Facebook: 500 TB/日 * 30 = 1.5 PT/月 (source)
Twitter: 8 TB/日 * 30 = 240 TB/月 (
source)
Email/Other 情報: 192 PT/月。 2008年の時点で、Google 24 PB/日と発言している。したがって、そこから5年を経過した現時点では、192 PB/日と推定する。そこに含まれる、ユーザーに関連する情報を 1/3 とすると、64 PT/日 (
source)
Mobile traffic/machine ­to ­machine exchanges/vehicles etc: 4000 TB/日 = 117 PB/月 (
source)

Total Data = ~312PB/月(どうも、計算が合いませんが、大まかということで ^^;)

Hardware Costs

The prices below correspond to renting off­the­shelf servers from commercial high­end datacenters (considering the data will be stored in a distributed filesystem architecture such as HDFS). This is a worst case scenario that does not include potential discounts due to renting such a high volume of hardware and traffic or acquiring the aforementioned hardware (which incurs a higher initial investment but lower recurring costs) . The hardware configuration used for calculating costs in this case study is comprised of a 2U chassis, dual Intel Hexa­core processors, 16 GB of RAM, 30 TB of usable space combined with hardware­level redundancy (RAID5).

We’ll be needing about 20K servers, put into 320 46U racks. Cost for the server hardware is calculated to be about €7.5M / month (including servers for auxiliary services). Cost for the racks, electricity and traffic is calculated to be about €0.5M / month (including auxiliary devices and networking equipment).

Total hardware cost per year for 3.75 EB of data storage: €168M

以下の価格は、商用のハイエンド・データセンター(データは HDFS などの分散ファイルシステム・アーキテクチャを用いてストアされる)から、ただちに運用できるサーバーをレンタルするときのものである。ただし、この見積は、大量のハードウェアとトラフィックという条件において、ディスカウントの可能性を含まず、また、前述のハードウェアを購入しないという(初期投資が少なくてもランニング・コストが肥大する)、最悪のシナリオをベースにしている。このケース・スタディにおいて、コストを試算するたハードウェア構成は、2U シャーシおよび、Dual Intel Hexacore プロセッサ、16 GB の RAM、ハードウェア・レベルでの冗長性(RAID5)を前提とした 30 TBのスペースで構成されている。

そして、320 台の 46U ラックに詰め込む、20000 台のサーバーが必要になるだろう。それらのサーバー・ハードウェアのコストは、€7.5M/月(補助サービス用のサーバーも含む)程度と試算できる。また、ラックおよび、電力、トラフィックのコストは、€0.5M/月程度(補助機器とネットワーク機器を含む)と試算できる。

3.75 EB のデータ・ストレージを運用するための、全ハードウェア・コスト : €168M/年

Development Costs

  • 3 (top notch) developers ­> 1.5M per year
  • 5 administrators ­> 1.5M per year
  • 8 more supporting developers ­ > 2M per year
  • Developer costs ­> $1M­5M per year (assumes avg developer pay of $500k per year) = 3.74M euro

Total personnel costs: €4Μ

  • 3人の、トップレベル・デベロッパー ­= 1.5M/年
  • 5人の、アドミニストレーター = 1.5M/年
  • 8人の、サポート・デベロッパー = 2M/年
  • 開発コスト = $5M/年 (平均的なデベロッパー賃金を $500k/年とする) = 3.74M euro

トータルの人件費/年 : €4Μ

  • Total Hardware & Personnel Costs: €12M per month (€144M per year) = $187M per year
  • トータルのハードウェア・コストと人件費の総額 : €12M/月 (€144M/年) = $187M/年

Software

On the software side, the two main components necessary are:

  • A Stream (in­memory) Database to alert about specific events or patterns taking place in real­time and to make aggregations and correlations.
  • A MapReduce system (like Hadoop) to further analyze the data.

ソフトウェアの側面においては、2つのメイン・コンポ-ネントが必要になる:

  • A Stream (in­memory) Database to alert about specific events or patterns taking place in real­time and to make aggregations and correlations.
  • A MapReduce system (like Hadoop) to further analyze the data.
  • Stream  Database (in­memory):リアルタイムにおいて、特定のイベントやパターンについて警告し、集計し、相関関係を作成する。
  • MapReduce system (like Hadoop) : さらに詳細な、データ分析を行うため。

Now that we know the cost of finding anything about you, how would it be done?

The data is "streamed" to the Stream Database from the data connectors (social networks, emails etc), aggregated, and saved to HDFS in order for a MapReduce system to analyze them offline

(Bugsense is doing exactly the same thing with crashes coming from 520M devices around the globe with less than 10 servers using LDB, so we know this is both feasible and cost efficient. Yup, 10 servers for 520M. In real­time).

特定の人物を見つけ出すためのコストと、そのための処理は、そのようになっているのか?

対象となるデータは、データ・コネクターから Stream Database へ向けてストリーミングされ、アグリゲーションされた後に、HDFS にストアされる。 そして、MapReduce システムにより、オフラインで分析される。

( Bugsense では、LDB を使用する10台未満のサーバーにより、まったく同じ事を行おうとして、グローバルにおけるデバイス数を 5億2000万台に引き上げたところでクラッシュしている。つまり、リアルタイムでは、10台のサーバーで、5億 2000万台のデバイス数が、ある種の目安になる)

Next, we’d run a new search query on the 312PT dataset. How long will that take?

We could use Hive in order to run a more SQLish query on our dataset, but this might take a lot of time because data "jobs" need to be mapped, need to be read & processed, and results need to be send back and “reduced”/aggregated to the main machine

To speed this up, we can create a small program that saves data in columnar format in a radix tree (like KDB and Dremel does) so searching is done much faster. How much faster? Probably less than 10 seconds for 400TB for simple queries. That translates (very naively) to less than 10 seconds to find information about you.

続いて、312PT のデータセットに対して、新しいクエリーをかけてみた。どれくらいの時間を要したと思う?

このデータセット上で、SQL 的なクエリーを実行するために、Hive を使用できる。 ただし、データ "jobs" をマップする必要があり、 read & processed が必要であり、その結果をメイン・マシンに向けて転送し、“reduced”/aggregated を行う必要がある。

それをスピードアップするために、私たちは小さなプログラムを作成し、 radix tree 上の columnar format に、データを保存することにした ( KDB や Dremel が行うように)。 それにより、サーチが速くなったが、どれ程だと思うだろう? 400TB のデータに対して、シンプルなクエリーをかけるだけなら、おそらく 10秒以内で完了するだろう。 この、変更により、特定人物に関する情報の検索も、10秒未満のレンジへと、その性能を引き上げている。

Do you think that PRISM can be built using a different tech stack?

ここで取り上げていない、他のテクノロジー・スタックを用いて、PRISM を構築できるだろうか?

Related Articles

ーーーーー

TAG indexなるほど、という記事ですね。 先週の TechCrunch に、『 NSAが極秘のスパイ事業XKeyscoreについて釈明 』という記事が掲載されていましたが、この Prism の構造が徐々に解明されているようです。このところ、日本でも Suica の Big Data 問題が、ニュースを賑わしていますが、ユーザーが気をつけても抗しきれない状況になってきているようです。 まずは、さまざまな情報が共有され、実態の把握を進めることなのでしょうね。 その意味で、素晴らしい記事だと思います。image

ーーーーー

<関連>

Facebook の 超絶 Web パフォーマンス : その秘密を解析する
Facebook の超高速ストレージ : TAO の詳細を説明しよう
DynamoDB および、ホット SSD + コールド S3 というパターン
Google Maps は Big Data を使いこなすが、Apple Maps には それが出来ない
みんなの先生 James Hamilton 特集

 

Facebook の 超絶 Web パフォーマンス : その秘密を解析する

Posted in .Selected, Big Data, Facebook, Strategy by Agile Cat on August 2, 2013

Facebook Secrets of Web Performance
http://wp.me/pwo1E-6rT

April 23, 2013
http://highscalability.com/blog/2013/4/23/facebook-secrets-of-web-performance.html

_ highscalability

This is a repost of part 1 of an interview I did for the Boundary blog.

Boundary: What is Facebook’s secret for managing what’s got to be the biggest Big Data project, if you will, on the Web?

Boundary: Web 上で最大の Big Data プロジェクトになるために、Facebook が用いている、マネージメントのための秘密のソースは何なのだろう?

Hoff: From several presentations we’ve learned what Facebook insiders like Aditya Agarwal and Robert Johnson, both former Directors of Engineering, consider their secret sauce:

Hoff: いくつかのプレゼンテーションから、私たちが学んだものがある。 それらは、 Aditya AgarwalRobert Johnson などの Directors of Engineering 経験者が指標とする、いくつかの秘密のソースのことである:

  • Scaling Takes Iteration. Solutions often work in the beginning, but you’ll have to modify them as you go. PHP, for example, is simple to use at first, but is not a good choice when you have tens of thousands of web servers.
  • Scaling Takes Iteration. ソリューションとは、多くの場合において、未成熟な状況にある。 したがって、プロジェクトが進むにつれて、それらを修正する必要性が生じてくる。 たとえば PHP は、容易に導入できるが、何万という Web サーバーを用いるときには、良い選択肢にはならない。
  • Scaling Takes Iteration. You can say that again.
  • Scaling Takes Iteration. スケーリングにはイテレーションが必要だと、もう一度、心に刻み込んでほしい。
  • Don’t Over-Design. Just use what you need 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.
  • Don’t Over-Design.  あなたのシステムをスケール・アウトするために、必要なものだけを用いるべきだ。ソリューションにおける反復および、何かの最適化、そして、スタック内における完璧な構築に、必要とされるものを理解すべきだ。
  • Choose the Right Tool for the Job. Realize that any choice comes with overhead. If you really need to use Python then go ahead and, we’ll try to help you succeed. Yet with that choice there is overhead, usually across deployment, monitoring, ops, and so on.
  • Choose the Right Tool for the Job.  あらゆる選択枝には、オーバーヘッドが含まれると理解しよう。あなたが本当に、Python を用いる必要があり、さらに先へ進みたいと言うなら、それが成功するよう支援するだろう。 しかし、考えて欲しいのは、デプロイメント/モニタリング/オペレーションにまたがるオーバーヘッドが、その選択に含まれていないのかという点である。
  • Get the Culture Right. Build an environment internally which promotes building the right thing first and fixing as needed. Stop worrying about innovating, about breaking things, thinking big and thinking about what is the next thing you need to build after the building the first thing. Isolate the part of the culture that you value and want to preserve. It doesn’t happen automatically.
  • Get the Culture Right. チーム内で構築すべき環境は、最初に適切なものを構築し、必要に応じて、それを修正していける環境となる。大発見や野心的な発想、そして、将来における構築といった、イノベーションについて考え過ぎないようにすべきだ。 大切な事柄と保持すべき事柄で構成されるカルチャーを、明確に分離すべきだ。それは、自動的には行われない。
  • Move Fast. Get to market first. It’s OK if you break things. For example, Facebook runs their entire Web tier on HipHop which was developed by three people. This is a risky strategy. It brings the site down regularly (out of memory, infinite loops), but there’s a big potential payoff as they figure out how to make it work.
  • Move Fast.  製品化を急ぐべきだ。 あなたに発見があるなら、それで OK だ。Facebook を走らせる全体的な Web 階層は、HipHop の上に展開されるが、それ自身は 3人のエンジニアが開発したものである。 それは、リスキーなストラテジーである。それにより、一定の期間でサイトが停止するが(out of memory, infinite loops)、その動作を理解するにつれて、きわめて大きなポテンシャルがもたらされている。
  • Empower Small Teams. Small teams can do great things. Facebook Search, photos, chat and HipHop were all the result of small teams. Get the right set of people, empower them and let them work.
  • Empower Small Teams.  小規模なチームが、偉大な結果を達成する。 Facebook における、Search/Photo/Chat/HipHop の全てが、小さなチームの成果としてもたらされている。適切な人々でチームを構成し、権限を与え、作業を進めさせるべきだ。
  • People Matter Most. It’s people who build and run systems. The best tools for scaling are an engineering and operations teams that can handle anything.
  • People Matter Most.  システムの構築と運用に、人々は携わるべきである。スケーリングのための最適は手段は、1つのエンジニアリング・チームと、複数のイペレーション・チームが、あらゆるものに対処することである。
  • Scale Horizontally. Handling exponentially growing traffic requires spreading load arbitrarily across many machines.
  • Scale Horizontally.  指数関数的に成長するトラフィックの処理では、大量のマシンをまたいで、負荷を適宜分散していくことが要求される。
  • Measure Everything. Production is where the really useful data comes from. Measure both system and application level statistics to know what’s happening.
  • Measure Everything.  プロダクション環境とは、ほんとうに有益なデータで構成される環境である。システムとアプリケーションのレベルを、統計的に把握することで、そこで起っていることが理解される。
  • Gives Teams Control and Responsibility. Responsibility requires control. If a team is responsible for something they must also control it.
  • Gives Teams Control and Responsibility.  責任を持たせるためには、権限を与えなければならない。なんらかのチームが、なんらかの責任を持つなら、それに相応しい権限も持つべきだ。

All these principles work together to make a self-reinforcing virtuous circle. You can’t move fast unless you have small teams who have control and responsibility. You can’t know how your changes are working unless you get those changes into production and measure results. You can’t move code into production unless people feel responsible for moving out working code. You can’t handle the scale unless you figure out how to scale horizontally, move fast and measure everything– that all comes down to good people.

これらすべての原則は、協調しながら、好循環を自ら強化することで達成される。あなたが、権限と責任を有する小さなチームを持たない限り、迅速な行動は取れないだろう。また、プロダクション環境を変更し、そこで測定された結果を取得しない限り、その作用と影響について把握することが出来ないだろう。人々の作業の結果であるコードを、プロダクション環境へ移動するには、それがもたらす変化について、必ず責任を持たなければならない。そして、スケールを取り扱うためには、水平方向への拡散と、迅速な対応、そして、すべての測定について、あなたは理解しなければならない。さらに言えば、すべての事柄はが、適切な人々に受け継がれるという、必要性も生じる。

But the above is not the whole of the story. Not so obvious is the role of opportunity. A pattern we often see is that companies on the leading edge see problems before everyone else, so they solve those problems before everyone else. We see a blast wave of innovation coming from technological hotspots like Google, Netflix, Twitter and Facebook.

しかし、ここまでに述べたものが、すべてのストーリーを語るわけではない。頻繁に見受けられるパターンは、それらの先進的な企業が誰よりも早く、一連の問題に直面することであり、また、それらの問題を、誰よりも早く解決しているという事実である。私たちは、Google/Netflix/Twitter/Facebook といった、テクノロジー・ホットスポットから到来する、イノベーションの爆風を確認すべきだ。

Boundary: What other major websites do you think are doing a great job of scaling with demand, keeping users happy and response times high?

Boundary: その他の要求に応じたスケーリングと、顧客に提示する満足度、そして、高度な応答時間という観点で、どのような主要 Web サイトが上手く機能しているだろうか?

Hoff: We have a great industry. People are constantly willing to share their experiences, share their code and talk about what works. My wife is a tax accountant and they definitely don’t have the same vibe which is a little sad. There are a lot of unbelievably smart and passionate people in this field and total quality only rises the more people talk about how to build great stuff.

Hoff: 私たちは、偉大な産業に属している。人々は、自身の経験を共有し、また、そのコードを共有し、その作業について話し合うよう、常に心がけている。私の妻は税理士であるが、悲しいかな、そのような雰囲気が存在する世界ではない。このフィールドには、数多くの信じられないほどスマートで情熱的な人々が存在し、また、どのようにして素晴らしいものが構築されるのかという議論が促進されることで、全体的な品質が常に向上している。

It’s also pretty obvious to me that having a quality site and willingness to share are linked. There are many companies I could list that fall into this category, but these stand out: Twitter, Etsy, Facebook, Google, Netflix, Amazon and StackExchange. Some other important contributors include: Airbnb, Tumblr, Instagram, TripAdvisor, Heroku, Prismatic, 37signals, Pinterest and Yahoo.

つまり、私から見ると、高品質のサイトと共有への意欲が、明らかに共鳴しているように思える。相当数の企業が、このカテゴリに分類されると思うが、その中でも突出しているのは、Twitter/Etsy/Facebook/Google/Netflix/Amazon/StackExchange である。そして、重要なコントリビュータとしては、 Airbnb/Tumblr/Instagram/TripAdvisor/ Heroku/Prismatic/37signals/Pinterest/Yahoo などが含まれる。

There are literally hundreds of others that could be mentioned, but these companies have continually and enthusiastically contributed to advancing the state of the art in Web performance. I feel bad already, however, because I know I’m missing some.

他にも、文字通り、何百もの企業が挙げられるべきであり、それらの企業は継続的に、Webパフォーマンスの最先端で、情熱的なコントリビューションを継続している。 そのすべてを思い出せずにいることを、申し訳なく思う。

ーーーーー

TAG index久々の、 Todd Hoff さんです。 このインタビューは、Boundary blog での Hoff さんのインタビューを、High Scalability に転載したものとのことです。いろいろなブロガーがいますが、Facebook のスケール感覚に、いち早く注目し、その考え方を伝えてくれたのが、この Hoff さんであり、Agile_Cat も大ファンなのです :)  たくさん並べてしまいましたが、よろしければ、以下の(3年前くらいからの)リンク集も ご覧くださ~い! image

ーーーーー

<関連>

Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2
Facebook の HBase は、毎月 1350億 メッセージを処理する!
Facebook における 1300万/秒 クエリーの秘密
Facebook を 1.8 倍速に、WordPress を 2.7 倍速にする、HipHop とは ?
Facebook は 20分間で、2.7M Photo/10.2M Comment/4.6M Messageを処理!
Google Megastore – 1日で 30億 Write/200億 Read のトランザクションを実現
MySpace を殺したのは Microsoft ソフトウェア・スタックなのか?
Facebook は正攻法で、Billion 単位のメッセージを処理していく
Google の 3つの世代を振り返る – Batch, Warehouse, Instant
Facebook Timeline は、データの非正規化という破壊力で誘う

 

%d bloggers like this: