Agile Cat — in the cloud

Facebook の超高速ストレージ : TAO の詳細を説明しよう

Posted in .Selected, Big Data, Facebook, Open Graph, Storage by Agile Cat on July 18, 2013

What’s Behind The Door Of Facebook’s ‘Data Store?’
http://wp.me/pwo1E-6nS

David Cohen on June 25、2013
http://allfacebook.com/tao_b120642

_ All Facebook

Facebook offered some behind-the-scenes details about its TAO (The Association and Objects) server, which the social network referred to as its graph data store, in a note on the Facebook Engineering page by Software Engineer Mark Marchukov.

Facebook が提供する、その舞台裏に関する情報には、TAO (The Association and Objects) サーバーの詳細も含まれている。 それは、このソーシャル・ネットワークが、Graph Data のストアとして言及するものだと、Software Engineer である Mark Marchukov の Facebook Engineering ページに記されている

Marchukov described TAO as follows:

Marchukov は、TAO について 以下のように述べている:

Facebook puts an extremely demanding workload on its data back end. Every time any one of more than 1 billion active users visits Facebook through a desktop browser or on a mobile device, they are presented with hundreds of pieces of information from the social graph. Users see News Feed stories; commejnts, likes, and shares for those stories; photos and check-ins from their friends — the list goes on. The high degree of output customization, combined with a high update rate of a typical user’s News Feed, makes it impossible to generate the views presented to users ahead of time. Thus, the data set must be retrieved and rendered on the fly in a few hundred milliseconds.

Facebookはのデータ・バックエンドには、きわめて厳しいワークロードが課される。いつも誰かが、つまり、10億人以上といわれるアクティブ・ユーザーの誰かが、デスクトップの Web ブラウザを介して、また、Mobile Facebook を介して、このソーシャル・グラフから引き出される、数百もの情報を用いて自身を表現している。 そして、ユーザーたちは、News Feed 内で Story/Comment/Like などを参照し、また、トモダチからの Story/Photo/Check-In などを共有し、それらのリストが積み上げられていく。一般的なユーザーの News Feed であっても、その表示は高度にカスタマイズされ、また、高い頻度でアップデートされていく。 つまり、それらのユーザーのためのにビューを事前に生成することは不可能であり、また、それらのデータ・セットを数百ミリ秒のレベルで、空中戦でレンダリングしていく必要性が生じる。

This challenge is made more difficult because the data set is not easily partitionable, and by the tendency of some items, such as photos of celebrities, to have request rates that can spike significantly. Multiply this by the millions of times per second this kind of highly customized data set must be delivered to users, and you have a constantly changing, read-dominated workload that is incredibly challenging to serve efficiently.

この課題をさらに困難にするのは、対象となるデータ・セットのパーティショニングが容易ではなく、また、たとえば有名人の写真などを含むことで、リクエストでピークを生じる傾向があるからだ。高度にカスタマイズされたデータ・セットと、数百万回/秒というリクエストの掛け算の結果を、ユーザーに配信する必要がある。 そして、読み取りに支配されるワークロードを、それぞれのユーザーが頻繁に変更するため、サーバーの効率という側面において、信じられないほどの課題が発生してくる。

Marchukov went on to discuss why the social network implemented the use of memcache in addition to MySQL, as well as the development of the Objects and Associations application-programming interface, and it described a subgraph of objects and associations that is created in TAO after Alice checks in at the Golden Gate Bridge and tags Bob there, while Cathy comments on the check-in and David likes it.

Marchukov は、このソーシャル・ネットワークが、MySQL に加えて memcache を実装している理由と、The Association and Objects の API について説明してくれた。そして、事例として「 Alice が Golden Gate Bridge にチェックインして、それに Bob がタグを付け、それと同時に Cathy がコメントを付け、そこに David がイイネを付けた 」直後の、TAO の内部で生成された、オブジェクトと関連付けのサブ・グラフについても詳述してくれた。

He concluded:

The TAO service runs across a collection of server clusters geographically distributed and organized logically as a tree. Separate clusters are used for storing objects and associations persistently, and for caching them in RAM and flash memory. This separation allows us to scale different types of clusters independently and to make efficient use of the server hardware.

この TAO サービスは、ロケーション的に分散していても、ツリーとして論理的に構成されるサーバー·クラスターのコレクションを、横断するかたちで実行される。それぞれのクラスタは、オブジェクトとの関連付けを永続的にストアするために、また、それらを RAM とフラッシュ・メモリにキャッシュするために使用される。こうしたセパレーションを施すことで、各種のクラスタを個別にスケールすること、そして、サーバー・ハードウェアの効率的な運用が実現される。

We chose eventual consistency as the default consistency model for TAO. Our choice was driven by both performance considerations and the inescapable consequences of CAP theorem for practical distributed systems, where machine failures and network partitioning (even within the data center) are a virtual certainty. For many of our products, TAO losing consistency is a lesser evil than losing availability. TAO tries hard to guarantee with high probability that users always see their own updates. For the few use cases requiring strong consistency, TAO clients may override the default policy at the expense of higher processing cost and potential loss of availability.

私たちは、TAO におけるデフォルトのコンシステンシー・モデルとして、イベンチュアル・コンシステンシーを選んでいる。私たちの選択は、マシンの故障とネットワーク分断が(たとえデータセンター内でも)が確実に起こることを前提とし、その範囲においてパフォーマンスを考慮し、実用的な分散システムで避けることのできない CAP 定理という、2つの側面から推進した結果でもある。Facebook の大半のプロダクトにおいて、TAO により失われるコンシステンシー(一貫性)は、可用性を失うよりも、小さな問題だと解釈されている。ユーザーによるアップデートが常に確認されるという、高度な蓋然性を保証するよう、TAO に対して懸命に取り組んでいるところだ。そして、ストロング・コンシステンシーを必要とするいくつかのユースケースでは、より多くの処理コストと、可用性が失われる可能性を犠牲にして、TAO クライアントはデフォルト・ポリシーを上書きすることになる。

A massive amount of effort has gone into making TAO the easy-to-use and powerful distributed data store that it is today. TAO has become one of the most important data stores at Facebook — the power of graph helps us tame the demanding and dynamic social workload. For more details on the design, implementation, and performance of TAO, I invite you to read our technical paper published in Usenix ATC ‘13 proceedings.

TAO を容易に使いこなし、また、パワフルな分散データストアとするために、いまは修練していく段階にある。TAO は、Facebook における、最も重要なデータ・ストアの1つとなっている。この Graph のパワーは、動的であり暴れまわるソーシャル・ワークロードを飼いならすのに役立つ。TAO に関する設計/実装/性能の詳細については、Usenix ATC ‘13 proceedings で提供されている、私たちのテクニカル・ペーパーを参照して欲しい。

Related Stories

ーーーーー

TAG index先週に、『 Facebook が発表した TAO : これで MySQL と Memcached を接続する 』という抄訳で、この TAO に関する概要をお伝えしました。そこでは、「Facebookは、あなたが参照している情報を、2つの極めて異なるデータ・コレクションから提供している」というふうに説明されていましたが、その2つ目のデータ・コレクションで用いられるのが、この TAO だというわけです。 そして、コンシステンシーよりも可用性を重視すると説明されていますが、このあたりついては、以下の <関連> を参照してください。James Hamilton 先生と、Mike Stonebraker 先生が、たっぷりと語ってくれています。image

ーーーーー

<関連>

イベンチュアル・コンシステンシーはお好き? — by James Hamilton
Stonebraker と CAP Theorem と Databases – by James Hamilton
Database System エラー と Eventual Consistency と CAP Theorem _1
Database System エラー と Eventual Consistency と CAP Theorem _2

Facebook が発表した TAO : これで MySQL と Memcached を接続する

Posted in .Selected, Big Data, Facebook, Open Graph, Storage by Agile Cat on July 9, 2013

The Tao of Facebook: ‘Social Graph’ Takes New Path
http://wp.me/pwo1E-6lI

By
Cade Metz – 06.25.2013
http://www.wired.com/wiredenterprise/2013/06/facebook-tao/

_ WIRED

Ever noticed that certain things on a Facebook page load faster than others? This is often the case with even the simplest of websites, but with a site the size of Facebook’s globe-spanning social network, the divide is in some ways more pronounced. Facebook, you see, serves information from two very different collections of data.

Facebook ページにおける特定のアイテムが、他より素早く読み込まれるようになったことに、気づいるだろうか? それは、多くの点において、Web サイトにおける最もシンプルなケースと同様であるが、この Facebook サイトは世界を横断するソーシャル・ネットワークの規模となり、いくつかの処理系に、分割されているのも明らかである。Facebookは、あなたが参照している情報をを、2つの極めて異なるデータ・コレクションから提供している。

Facebook CEO Mark Zuckerberg.
Photo: Alex Washburn/Wired

Most data is stored inside a good old fashioned database — the open source mainstay MySQL — but the social networking giant also uses a second system to house data that’s accessed with particular frequency. This system is known as Memcached, and it’s a common thing inside the massive data centers that underpin the world’s largest websites. Memcached stores data in the memory subsystems of the servers that drive Facebook, rather than slower hard disks. Facebook engineers call it “hot data.” Basically, this means that the data you’re more likely to visit is more likely to load at speed.

大半のデータは、古き良きデータベースの内部に、つまりオープンソースを主力とする MySQL にストアされている。しかし、このソーシャル・ネットワーキングの巨人は、きわめて頻繁にアクセスするデータのために、2番目のシステムを用いている。このシステムは、Memcached として知られるものであり、世界で最大級の Web サイトを支える、大規模データセンターでは一般的なものである。Memcached は、サーバーのメモリ・サブシステム内にデータをストアし、遅いハード・ディスクに代えて Facebook をドライブしていく。 そして、Facebook のエンジニアたちは、それを Hot Data を呼んでいる。基本的に、これらのデータが、あなたが頻繁に呼び出し、また、高速でロードするものとなる。

The rub is that juggling both MySQL and Memcached isn’t the easiest of tasks for the engineers that build and operate the Facebook machine. But in recent years, the company has built a new system that seeks to ease the use of these two data stores. It’s called TAO, short for “The Associations and Objects,” and it’s been used on the site for “several” years now.

そこでの問題点は、MySQL と Memcached の双方を曲芸のように取り扱い、Facebook のマシンを構築/運用していくエンジニアのタスクが、きわめて難しいということである。しかし、近年では、これらの2つのデータ・ストアの利用を容易にするための、新しいシステムを同社は構築している。それが、TAO という省略形を持つ “The Associations and Objects" であり、すでに、何年かにわたって、そのサイトで利用されている。

“It was important to build something that would help Facebook engineers move fast,” says Facebook software engineer Mark Marchukov. “Before, engineers had to understand the details of how both the cache and the MySQL data stores operated in order to write efficient code, and that slowed down the rate of development. With TAO, we put in an API [application programming interface] that they could use without thinking about the details.”

「 Facebook におけるエンジニアの効率を改善するために、何らかのものを構築する必要があった。以前には、エンジニアたちは効率の良いコードを書くために、Cache と MySQL のデータ·ストアを操作する方式を、詳細まで理解する必要があり、その結果としてし開発スピードが鈍化していた。TAO を用いることで、エンジニアたちが詳細を考えずに利用できる、1つの API の導入が可能になった」と、Facebook のソフトウェア・エンジニアである Mark Marchukov は発言している。

But TAO is more than just a new interface for Memcached and MySQL. According to Marchokov, the company also rebuilt the software that sits behind the API. “We wanted to build something that could do better than a hybrid system consisting of just Memcached and MySQL,” he says. In short, the system is specifically designed for the types of data structures used by Facebook — data structures that define what Facebook calls “the social graph,” the endless tangle of relationships among people and information on the site.

しかし TAO は、Memcached と MySQ Lのための、新しいインタフェースというレベルを超えるものである。Marchokov によると、同社では、この API の背景となるソフトウェアを再構築したとされる。「 私たちは、Memcached と MySQL で構成される、ハイブリッド・システムよりも優れたものを構築したかった」と、彼は言う。 要するに、このシステムは、Facebook で使用されるデータ構造に特化したデザインを持つ。つまり、 Facebook がソーシャル・グラフという名で定義するデータ構造であり、このサイト上で人と情報を、無限に関連付けるものである。

“We wondered what an infrastructure built by Facebook for Facebook would look like,” says Facebook director of engineering Venkat Venkataramani.

「 Facebook が Facebook のために構築するインフラは、どのようになるべきかと、ずっと考えてきた」と、Facebook の Director of Engineering である Venkat Venkataramani は発言する。

The system — which Facebook discussed for the first time this week — is yet another example of the company building entirely new software to streamline and accelerate its ever-growing online empire. Like Google and Amazon and even Microsoft and Twitter, Facebook has reached such an enormous size, it can no longer rely on software originally designed for much simpler sites.

このシステムは、つまり  Facebook が今週に初めて説明したシステムは、その永遠に成長し続けるオンライン帝国を合理化し、加速させていくための、まったく新しいソフトウェア構築の事例である。Google や Amazon のように、さらには Microsoft や Twitter のように、Facebook は巨大な規模に達しており、もはやシンプルなサイトのために設計された、ソフトウェアには頼ることはできないのだ。

Very often, Facebook will “open source” its new software creations, sharing them with the world at large. But the company has yet to share the code behind TAO. Venkataramani says the company is still considering whether it will do so. Though TAO helps drive the live Facebook site, he says, it is still under development.

大半のケースにおいて、Facebook は新たに開発したソフトウェアを "オープンソース" にして、世界規模でその共有を図っていく。 しかし同社は、TAO を支えるるコードについては共有するに至っていない。そのオープンソース化は検討中だと、Venkataramani は発言している。TAO は、Facebook のライブ・サイトを効率よくドライブするが、彼によると、それは開発の途上にあるという。

ーーーーー

TAG indexこの、Facebook インフラに関しては、2011年11月に『 Facebook メッセージを支えるストレージ・インフラを解説 – James Hamilton  』という抄訳で紹介しました。 そして、おそらく、その延長線上にあるものが、今回の TAO(The Associations and Objects)なのだと推測します。 Memory/Flash Memory/HDD といった記憶システムを、適材適所に配置して、それぞのアドバンテージを活かすかたちで構成していく。 さらに言えば、そのためにハードウェア・インフラを再構成していくという、Open Compute Project にまでつながっている話しなのだと思います。image

ーーーーー

<関連>

Facebook の Open Graph とは? その歴史から説明しよう
Facebook の Open Graph により、SEO に大変革が訪れる
Facebook の Open Graph により、マーケティングに質的変化が訪れる
Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2
IBM の Flash Memory アプライアンスは、12T Bytes で 3000万円だ!

BaaS で自由になる? それとも便利になる? そして DoCoMo の i-Concier は?

Posted in .Selected, API, BaaS by Agile Cat on December 11, 2012

Mobile Backend-as-a-Service (MBaaS): Give me Liberty or give me… Convenience?
http://wp.me/pwo1E-5li

Guest Author, November 29th, 2012
http://blog.programmableweb.com/2012/11/29/mobile-backend-as-a-service-mbaas-give-me-liberty-or-give-me-convenience/

_ ProgrammableWeb

This guest post comes from Miko Matsumura, Senior Vice President of Platform Marketing and Developer Relations for Kii Corporation. Miko main role at Kii is evangelizing the Kii Cloud Mobile Backend-as-a-Service (MBaaS).

What’s good about MBaaS?

imageMBaaS provides mobile developers with LIBERTY and CONVENIENCE. LIBERTY in the sense of self-determination, control and an independent destiny–they can communicate with, manage, understand and serve their users without being beholden to external influences. An app developer who doesn’t control their users has no independent future. CONVENIENCE is a simple matter of reducing time-to-market, risk and cost of development.

LIBERTY は、自身による判断と制御、そして独立した運命の意味を持つ。つまり、外部からの影響を受けることなく、ユーザーに対するコミュニケーションとサービスを実現し、その関係を理解し、管理していく。自身のユーザーをコントロールしないアプリ・デベロッパは、独立した未来を持ち得ない。 CONVENIENCE は、ビジネスを立ち上げる時間と、開発におけるリスクとコストを低減するという、シンプルな論点である。

MBaaS is only one of several options for cloud backend:

MBaaS は、クラウド・バックエンドにおける、いくつかの選択肢の 1つに過ぎない:

___space

Why not just roll-your-own backend?

Now I’m sure the web-programming gurus here at ProgrammableWeb are all wondering why its not more convenient for mobile developers to write their own backends?

そして、ProgrammableWeb 上において、Web プログラミング接着剤だと確信できるものが、自身のバックエンドを書こうとするモバイル・デベロッパーにとって、さらに便利なものになるなら、それがなんで悪いのか?

Reasons vary, but in our experience, these factors are pretty common among mobile app developers, particularly independent app store developers who are often just one person (and in some cases someone who has a full time job doing something else).

さまざまな理由があるが、私たちのエクスペリエンスにおいて、以下の要因は、モバイル・アプリ・デベロッパーに共通するものである。そして、大半のケースにおいて、1人で作業を行う、独立したアップ・ストア・デベロッパーにおいて顕著なものとなる(そして、何らかのテーマに、フル・タイムで取り組むデベロッパーにも共通する)。

  • Pace: especially when competing in major app stores, the pace of mobile app development demands at least bi-weekly updates, patches and bug fixes. There’s no time to architect scalable back-end services.
  • Learning Curve: some mobile developers can double as server programmers, some can’t–but more importantly, the pace is fast enough on the client that they can’t afford to context switch.
  • Stack Risk: stacks can be confusing? MongoDB? Couch? Cassandra? MySQL? Postgres? Ruby? Python? PHP? Node? For some this is simple, but not for all. The consequences of picking the wrong combinations can be severe.
  • ペース:特に、メジャーなアップ・ストア内で競争するとき。 モバイル・アップの開発ペースは、少なくとも隔週のアップデート/パッチ/バグ・フィックスを要求する。 そして、スケーラブルなバックエンド・サービスを、デザインする時間がない。
  • 学習曲線:サーバー・プログラマーを兼任できる、モバイル・デベロッパーもいいれば、それが難しいこともある。しかし、それよりも重要なことは、容易なコンテキ・ストスイッチが不能なクライアント上で、十分に速い学習のペースが得られるところにある。
  • スタックは、混乱するだろうか? MongoDB? Couch? Cassandra? MySQL? Postgres? Ruby? Python? PHP? Node?  いくつかはシンプルであるが、すべてではない。 不適切なコンビネーションの選択は、厳しい結果を生じるだろう。

Turns out it’s a full time job to keep users happy and release new versions of apps in the ragingly competitive app stores.

分かったことは、熾烈に競い合うアップ・ストア内で、ユーザーを満足させ、また、新バージョンのアプリをリリースしていくには、フル・タイムの作業が必要ということである。

So MBaaS fills in the sweet spot in this chart by giving mobile app developers liberty over their own users, their own data and other such benefits, but with relative convenience–not requiring them to invest large amounts of time and effort in building and scaling back-end services.

したがって、MBaaS は、モバイル・アプリ・デベロッパーに自由を与え、彼らのユーザー/データ/メリットなどをカバーする点において、上記のチャートで及第点を得ている。しかし、相対的な利便性については、バックエンド・サービスの構築とスケーリングにおいて、彼らに大量の時間と労力を投じるようには要求しない。

Liberty is more important than convenience

To paraphrase Ben Franklin, those who would give up liberty for the sake of a little convenience deserve neither liberty nor convenience.

Ben Franklin の言葉を、ちょっとした便利さのために自由を諦める人々は、自由も便利さも手にすることができない、と言い換えられるだろう。

This is the biggest mistake of mobile developers when selecting a mobile backend strategy. Now another way of looking at it is that many developers marry their MBaaS for “love” (features) rather than “money” (business reasons). Many developers are in such a hurry to ship the next feature or version of their product that they just fall in love with whichever tool comes in handy. Or even more commonly they fall in love with the tools that are the most elegantly designed or have the coolest feature set. One issue can be that once you select, it can be hard to switch.

それが、モバイル・バックエンド戦略を選択するときに、モバイル・デベロッパーが犯しやすい最大の誤りである。 そして、数多くのデベロッパーが、 “money” (business reasons) よりも  “love” (features) のために、MBaaS に依存し続けるという、別の道筋が見えてくる。 数多くのデベロッパーが、そのプロダクトに新機能や次期バージョンを矢継ぎ早に送り込もうとするのは、どんどんと便利になってくるツールとの、恋に堕ちるからである。 それよりも一般的なケースは、最もエレガントにデザインされ、クールな機能のセットを取り込んだ、ツール自体に惚れ込んでしまうことだ。 一度、決めてしまったことが、その後の変更を、とても難しくすることもあり得るのだ。

A longer term and more business-oriented view of this decision may save a lot of trouble down the road. When selecting an MBaaS partner (and there are many) it’s probably worthwhile to consider whether the provider is going to be in business a year from now or even 6 months from now. Startups get acquired (or worse, acqui-hired) or even run out of business. Be sure to understand whether your supplier has sufficient history of operation and a stable financial base.

そのための判断において、よりビジネス的で長期的な視野を持てば、これからの道筋に潜んでいる、数多くのトラブルを回避できるだろう。 MBaaS パートナー(数多く存在する)を選ぶときに、対象となるプロバイダーが 1年後に、あるいは 6カ月後に、ビジネスを展開しているのかどうかを考えることに、おそらく価値が生じる。 スタートアップには、買収される可能性がある(最悪は人材だけを買われてしまうケース)。 さらには、ビジネスから脱落することもある。 あなたにとってのサプライヤが、充分な実績を持ち、財政的にも安定していることを、確認すべきである。

Backend case study: NTT DoCoMo i-Concier

To understand what it takes to provide reliable service, we can take a look at the Kii Cloud MBaaS currently deployed by the largest carrier in Japan to millions of paying subscribers of the i-Concier™ mobile sync service. Historically, this kind of reliability, elasticity and scalability was only available to the largest carriers in the world, however, Kii has opened this service up to the developers of the world.

信頼性の高いサービスを提供する際に、必要となるものを理解するために、Kii Cloud MBaaS に注目してみる。それは、Japan で最大のキャリアにより、i-Concier モバイル同期サービスの何百万という有償サブスクライバーに対して、現時点で提供されているものである。  歴史的にみて、この種の安定性/柔軟性/スケーラビリティは、世界での最大級のキャリアだけが提供できるものであったが、このサービスは Kii により、世界のデベロッパーへ向けて開放されているのだ。

___space

Isn’t MBaaS part of the weird closed mobile bubble-world?

One of the greatest things about the Programmable Web is the glorious freedom of connecting services from anywhere to anything–and the ethos is supported by web standards like REST. It’s all so open and free (as in free beer).

Programmable Web において最も素晴らしいことは、あらゆる場所から、あらゆる事象にいたるまで、サービスの接続に対して輝かしい自由度を提供する点にある。 そして、この理念は、REST などの Web スタンダードによりサポートされる。 さらに言えば、その、すべてが、オープンでフリーなのだ(無料のビールのようなもの)。

This makes mobile development paradigms like HTML5 seem most attractive as these solutions are not fenced behind app stores and paywalls. I think theres plenty of room for this and environments like Node.js provide common language across client and server. Commenting on this is outside the scope of this post, but the short perspective on this is that there should be room for everyone in mobile.

それにより、HTML5 のように、最も魅力的だと思われる、モバイル開発のパラダイムがもたらされる。そして、それらのソリューションは、アップ・ストアや課金のカベに囲まれるものではない。 そこには、たくさんの考え方があると思う。そして、Node.js のような環境が、クライアントとサーバーにまたがる、共通の言語を提供している。 それについて意見を述べることは、このポストのスコープ外のことであるが、モバイルにおいては、それぞれの人々のための考え方があるというのが、私の簡潔な展望となる。

For those who do choose native mobile client programming, they do have to put up with ugly app store approval processes, app store “taxes” and a much more “closed” mindset around their technology stacks. But in exchange for being part of this world, developers gain access to monetization and professionalization and can build sustainable businesses with exponential growth properties. There’s room for everyone.

ネイティブのモバイル・クライアント・プログラミングを選ぶ人々は、面倒なアップ・ストアの承認プロセスと「税」に耐え、自身のテクノロジー・スタックに「閉じ込められた」固定観念を引きずらざるを得ない。しかし、この世界の一部になるこという交換条件により、デベロッパーたちはマネタイズとパーソナライズに取り組み、自身の特質を活用した、持続可能なビジネスを構築できる。 そこには、みんなのための方式がある。

ーーーーー

imageこのところ、すっかりと BaaS にハマっている Agile_Cat ですが、例の Kinvey Subway Map に入っていないため、この Kii を見逃していました。 そして、先日、このところご無沙汰だった ProgrammableWeb に行ってみたところ、このような重要な記事を見つけたというわけです。最近の Agile_Cat の悩みは、この新たに作った BaaS カテゴリに、これまでの API カテゴリを統合すべきなのかというものです。 う~ん、どうしたものでしょうかね?  

ーーーーー

<関連>

AWS イベントでの Parse が スゴそう – BaaS の勢いが加速する?
Ray Ozzie の Talko も、$4M の資金で BaaS に参戦!
Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!
モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう

Google Cloud SQL の価格が発表された!

Posted in .Selected, Businesses, Google, Storage by Agile Cat on May 14, 2012

Google puts a price tag on Cloud SQL services
http://wp.me/pwo1E-4do
By
Barb Darrow May. 10, 2012
http://gigaom.com/cloud/google-puts-a-price-tag-on-sql-cloud-services/

_ Gigaom

Trying to convince naysayers that it’s serious about Google App Engine as a bona fide business, Google on Thursday put a price plan around its MySQL-based Cloud SQL services.

Google App Engine が気合の入ったビジネスであることを、否定論者たちに知らしめるために、この木曜日(5/10)に Google は、MySQL ベースの Cloud SQL サービスに関連するプライス・プランを発表した。

Google Cloud SQL
クリックで拡大 ⇒

There will be two options. One is what Google calls a true per user price model to help get people started and in which they incur query charges only when they are actively using the service although the storage meter keeps running throughout. This model targets users with lightweight applications and/or those with unknown spiky workloads who don’t want to have to predict their usage in advance, said Joe Faith, product manager for Google Cloud SQL.

そこには、2つのオプションが含まれるようだ。1つ目は、Google が True Per User Price Model と呼ぶものであり、このサービスを導入し易くするものである。 つまり、ストレージの課金は継続的に生じるが、クエリーに関する課金は、このサービスを積極的に使用するときにだけ生じるというものだ。 このモデルがターゲットにするのは、ライトウェイトなアプリケーションのユーザーであり、また、その利用量やピークについて、事前に予測する必要のないユーザーであると、 Google Cloud SQL の Product Manager である Joe Faith は発言している。

The second package billing plan allocates a designated amount of RAM and CPU for a monthly fee based on the number of days the database exists. Queries that access RAM but not disk are not charged for I/Os. Package charges start at $1.46 per day for 850K I/Os per day, 1 GB included storage and 0.5G RAM. At the high end, the charge is $11.71 per day for 8M I/Os per day, 10GB storage and 4GB RAM with two tiers in between. Both plans also incur a network charge of $0.12 per GB for outbound traffic. Google published the price list Thursday with billing slated to start in 30 days.

2つ目は、指定された量の RAM と CPU に課金するものであり、データベースを保持する日数に基づいて、1ヶ月あたりの使用料がパッケージされている。 クエリーはディスクにではなく RAM にアクセスするものとなり、また、ディスク I/O については課金されない。 Package の料金が、1日あたり 850K I/Os と $1.46 から始まり、1 GB のストレージと 0.5G の RAM が含まれる。 ハイエンドにおいては、1日あたり 8M I/Os と $11.71 であり、10 GB のストレージと 4G の RAM が含まれる。 そして、さらに、中間的な 2つの価格帯も提供されるという。また、いずれのプランにおいても、アウトバウンド・トラフィックに関しては、1 GB あたり $0.12 の、ネットワーク使用料が生じる。 そして、30日以内に開始される一連のプライス・リストを、 Google は発行している。

Database turfwar in the cloud

imageCloud vendors are competing fiercely on database services. Two days ago, Amazon brought Microsoft SQL Server into its Relational Database Service (RDS), which already offers Oracle and MySQL databases as managed services. The newly available beta of HP’s Cloud Services also offer MySQL database services.

クラウド・ベンダー間における、データベース・サービスの競合は熾烈である。 2日前のことだが、 Amazon が Relational Database Service(RDS)に Microsoft SQL Server を加えたが、そこでは既に Oracle と MySQL が、マネージド・サービスとして提供されている。また、HP も、新たに提供される同社の Cloud Services において、MySQL データベース・サービスに対応する。

“Cloud SQL was one of the most requested additions to App Engine since it launched, poeple wanted a SQL option to go with our NoSQL option,” Faith said in an interview this week. Google made an early version of Cloud SQL. available in October and has since signed up 10,000 users for it, he said.

「 Cloud SQL は、App Engine が立ち上がってから、最もリクエストの多かった付加機能の 1つである。 つまり、人々は NoSQL のオプションに対して、SQL のオプションも望んでいたことになる 」と、今週のインタビューで Faith は答えている。 Google は 昨年の 10月に、この Cloud SQL のアーリー・バージョンを提供開始した。それ以来、10,000 人以上のユーザーが Sign Up していると、彼は付け加えた。

Google is clearly still smarting from criticism, including some in GigaOM, that it’s not serious about Google App Engine as a business. Critics have taken to painting Google as an advertising company not a technology provider and the company is fighting that perception.

明らかに Google は、これまでの批判に対してピリピリしている。 そこには、GigaOMに書かれた、ビジネスとしの Google App Engine に対して、同社は真剣ではないという論評も含まれるだろう。 こうした批判は、同社を技術系の企業としてではなく、広告系の企業として色づけるものであるが、その認識に対して Google は戦いを挑んでいる

Related research and analysis from GigaOM Pro:

 

 

ーーーーー

TAG index今年に入ってっから、クラウド・ストレージにおける価格戦争は、ほんとうに厳しさを増しています。 しかし、「Amazon が安いのか? Hosting が安いのか? コスト分析モデルで比較する!」で Charlie Oppenheimer さんが論じているように、その価格の実態はストレージの使用料ではなく、インターネットへ向けたアウトバウンド・トラフィックの費用にあるようですね。 たとえば、同じストレージであっても、それを Web サイトとして利用する場合と、バックアップ用に使う場合では、まったく異なる実質料金となるわけです。 その意味で、この Google Cloud SQL の価格設定は、とても理にかなっているように思えます。 ーーー ac-stamp-232

ーーーーー

<関連>

Google のたまわく、Amazon だけにクラウド価格破壊はさせない!
Microsoft も価格を引き下げ! バーガー戦争時代に突入するクラウド・ストレージ
結局のところ、いま ストレージに、何が起こっているのか?
Google Drive は、もう1つの Dropbox では無いのだ!

 

Twitter が提供する、MySQL 関連のオープンソースとは

Posted in .Selected, Big Data, Storage, Twitter by Agile Cat on May 6, 2012

Twitter open sources its MySQL secret sauce
http://wp.me/pwo1E-4bb
By
Derrick Harris Apr. 9, 2012
http://gigaom.com/cloud/twitter-open-sources-its-mysql-secret-sauce/

_ Gigaom

Updated: Twitter has shared numerous aspects of its infrastructure over the past few years, and its decision to open source its work on MySQL might be the social media platform’s most useful contribution yet. Sure, open source big data tools are valuable, but they’re not MySQL.

Updated: Twitter は、この数年にわたって、自身のインフラストラクチャを、いくつかの切り口から共有してきた。 そして、MySQL に関する成果をオープンソース化していくという判断は、このソーシャルのメディアのプラットフォームから提供される、最も有用なコントリビューションとなるだろう。たしかに、オープンソースの Big Data ツールは貴重であるが、それらは MySQL ではないのだ。

Used by millions of web developers, MySQL is hugely popular; it’s the “M” in the LAMP stack that still underpins many web applications. But it has its problems, among them scalability and performance under the pressure of high transaction rates. This is part of the reason that NoSQL databases came into existence and continue to flourish. So, for anyone concerned with making MySQL scale, being able to see and build upon what a site like Twitter did with the code should be a big deal.

MySQL は、何百万という Web デベロッパーにより利用され、また、人気者でもある。そして、LAMP スタックの [M] として、数多くの Web アプリケーションを下からサポートしている。 しかし、ハイ・トランザクション・レートというプレッシャーを前提にすると、そのスケーラビリティとパフォーマンスに問題を抱えてしまう。 逆説的に言えば、それが NoSQL データベースの存在する理由であり、また、広く利用されている要因でもある。したがって、MySQL でスケールを実現しようする、あらゆる人々にとって、Twitter のようなサイトがコーディングした成果を参照し、それをもとに何らかを構築できることは、きわめて重要な事柄になるはずだ。

It’s not like Twitter is alone in working on MySQL’s shortcoming or anything — companies such as Tokutek and ScaleBase are centered around this very premise, and Facebook has done some amazing things with the database — but Twitter’s willingness to open source its code is critical. No vendor licenses, no support contracts and no lock-in, just a tried and true MySQL fork from one of the world’ most successful web platforms.

MySQL の欠点などに取り組んでいるのは、なにも Twitter だけではない。 しかし、そのコードを快くオープンにする Twitter の意思は、とても重要な意味を持つ(たとえば、TokutekScaleBaseなどは、こうした仮説を前提にビジネスを考えている。そして Facebook は、データベースに関する驚くべき成果を達成している)。ベンダーのライセンスや、サポート契約、そしてロックインのない世界だ。 そこにあるのは、この世界で最も成功した Web プラットフォームとしての、実証済みの MySQL フォークだけである。

imageAs it turns out, however, Twitter’s move in open sourcing its core MySQL code comes after the company already open sourced various components that sit atop MySQL. In 2010, it open sourced Gizzard, a middleware component for creating distributed databases that can serve tens of thousands of queries per second, and FlockDB shortly thereafter.

しかし、今にしてみると、コアとなる MySQL コードをオープンソースにしようとする Twitter の行動は、MySQL 上の多様なコンポーネントをオープンにしてきた、その後に続くものである。 2010年には、分散データベースを構築するミドルウェア・コンポーネントである、Gizzard をオープンソース化し、その直後に FlockDB もオープンにしている。それらは、秒あたり何万というクエリーを処理するものである。

Update: Someone alerted me that Facebook does have a site for sharing its MySQL patches, although it’s hosted at Launchpad. Earlier on Monday, commenters to a thread on the MySQL at Facebook page strongly urged Facebook to move its efforts to the far more popular Github, which is where Twitter hosts its code.

Update: Facebook には、MySQL パッチを共有するためのサイトがあるが、Launchpad にホストされていると、教えてくれる人がいた。 月曜日の朝のことだが、Facebook ページの MySQL スレッドで、こうした Facebook による成果は、よりポピュラーな Github に移行されるべきだと、強く催促するコメントがあった。 そこは、Twitter が、一連のコードをホストしている場所である。

Related research and analysis from GigaOM Pro:

-----

image文中に指摘されるように、Facebook と並んで Twitter も、ソフトウェアのオープン化について、さまざまな活動を展開してきました。 とくに、Hadoop が注目を浴び始めたころから、この 2つの巨大ソーシャルが LAMP スタックを用いて、その上で Big Data をハンドリングしていることが明らかにされ、大規模 Web サイト構築におけるデファクトが確定してきたのだろうと思います。それは、従来からのソフトウェア・ライセンス・ビジネスに終止符を打つものであり、また、その合理性を Android が証明しているのでしょう。 まだまた問題は山積みですが、特定の企業が権利を主張するより、それが一人一人のデベロッパーのスキル(経済)として分散されることで、エコシステムが確立され、また、イノベーションが促進されているのだと感じます。 --- image

-----

<関連>

誕生日を迎えた Twitter と、Jack Dorsey による6年前の初ツイート
正確に言うと、Twitter はソーシャルじゃないんだ – Jack Dorsey
Twitter サーチを 3倍速にする新アーキテクチャとは?
Twitter が提供する、Hadoop ライクな OSS とは?
Twitter の Trend API は、XML から JSON-Only へと移行する

 

オープンソースは商用ソフトウェアを侵食し始めているのか?

Posted in .Selected, Cloud Stack, Linux, OpenStack, Research by Agile Cat on March 7, 2012

Open Source: Commercial Software Loses Ground
http://wp.me/pwo1E-3Zs
By Dick Weisinger, on February 16th, 2012
http://www.formtek.com/blog/?p=2777

_ formtek

Open Source is now a competitive mainstream alternative for many business applications and the rise of Open Source is becoming a threat to proprietary software.

Open Source は、数多くのビジネス・アプリケーションにとって、競争力のあるメインストリームの選択肢となり、また、Open Sourceの台頭は、プロプライエタリなソフトウェアに対する脅威となっている。

A decade ago, Open Source was not well understood and considered by many organizations to be too risky to even be considered as an option.  Today, success by well-recognized Open Source product brands like RedHat, MySQL and Alfresco have totally changed people’s perspectives about Open Source.  Linux has become a sort of poster-child success story for Open Source.  Key selling points of Open Source have been less vendor lock-in and more flexibility in software customization.

10年前には、Open Source は正しく理解されず、また、選択枝の 1つとして考えるにも、あまりにもリスキーであると、数多くの組織に思われていた。  しかし、いまでは、RedHat/MySQL/Alfresco といった、Open Source プロダクト・ブランドが適切に認識されたことで、人々の Open Source に対する見方が変わってきた。  その意味で、Linux は Open Source におけるサクセス・ストーリーの、ある種のイメージ・キャラクターになった。  Open Source における主要なセールス・ポイントは、ベンダー・ロックインを低減し、また、ソフトウェア・カスタマイズに柔軟性を与える点にある。

Laurie Wurster, research director at Gartner, described the results of a survey on Open Source taken by Gartner in the Harvard Business Journal.  She found that across the total sum of all organizations, Open Source platforms account for 29 percent of software portfolios.  Organizations responded that they are using Open Source in the following way:

Gartner の Research Director である Laurie Wurster は、Gartner による Open Source の調査の結果について、Harvard Business Journal で執筆している。  彼女は、すべての組織における合計において、ソフトウェア・ポートフォリオの 29% を、Open Source プラットフォームが占めていることに気付いた。それらの 組織は、以下のような方式で、Open Source を使用していると回答してきた:

  • 46 percent of organizations use Open Source Software at the departmental or project level
  • 22 percent of organizations consistently use Open Source Software in all departments
  • 21 percent of organizations are in the process of evaluating the advantages of using Open Source Software
  • 46% の組織が、Open Source ソフトウェアを、部門やプロジェクトのレベルで使用している
  • 22% の組織が、Open Source ソフトウェアを、全体的な部門でコンスタントに使用している
  • 21% の組織が、Open Source ソフトウェアの、利用面での利点を評価するプロセスにある

But despite the inroads that Open Source has made across many organizations, the Gartner survey finds that while many people have a better understanding of Open Source, the biggest impediment to Open Source adoption remains confusion because most organizations still don’t have any formal policies around the use of Open Source.

しかし、Open Source が数多くの組織に食い込んだにもかかわらず、その Gartner 調査は、多くの人々が Open Source を適切に理解している間に、Open Source の適用における最大の障害が、混乱を引き起こしたと指摘している。なぜなら、大半の組織が、Open Source の用法に関する、正式のポリシーを持っていないからである。

The flip side to the success of Open Source is the worry that it creates for developers employed in commercial software development.

Open Source が成功した裏面には、商用ソフトウェアの開発のために採用されたデベロッパーに対して、なにかを作成するという心配事がある。

One area where Open Source has had a devastating effect on commercial software is in the area of Java application servers.  Open Source options have resulted in a complete commoditization of this market segment.   A survey by New Relic found that 54 percent of enterprises now use Apache Tomcat.  16 percent are using Jetty, and 9 percent are using JBoss.  IBM WebSphere and Oracle WebLogic each have only about 1 percent each of market share.

Open Source が、商用ソフトウェアに破壊的な影響を与えてきたのは、Java アプリケーション・サーバーのエリアにある。  オープンソースの選択が、このマーケット・セグメントの完全なコモディティ化をもたらした。 New Relic による調査は、エンタープライズの 54% が、いまでは Apache Tomcat を用いていると指摘する。  16% が Jetty を使用し、9% が JBoss を使っている。  IBM WebSphere と Oracle WebLogic における、それぞれのマーケット・シェアは。約 1% というレベルに過ぎない。

ーーーーー

TAG index先日ですが、Amazon AWS と Self-Hosting のコストを比較するというポストを訳しました。 Amazon が提示する価格体系も、それと比較する Self-Hosting のコストも、当たり前のようにオープンソースをベースにしています。言い換えれば、オープンソースにより大半のクラウド・サービスが構成され、そこでの実績が、エンタープライズ・システムの在りかたを変化させているのが、いまの流れなのでしょう。あらためて認識する、オープンソースの経済性です。 ーーー __AC Stamp 2

ーーーーー

<関連>

OSS のスキルは、エンジニアの人生を豊かにする
とっても ラブラブな Linux と Big Data
クラウドは、オープンソースと伴に遍在化していく
この一年で、OSS への支出が 56% に跳ね上がった
OSS に対する企業意識の調査 – 予想以上の期待度にビックリ!

Facebook が Timeline をデザインしていく発想は、いったい何処から湧き上がってくるのか?

Posted in .Selected, Big Data, Facebook by Agile Cat on January 18, 2012

How Facebook built its Timeline feature
http://wp.me/pwo1E-3P0
By
Stacey Higginbotham Jan. 5, 2012, 1:06pm
http://gigaom.com/cloud/how-facebook-built-its-timeline-feature/

_ Gigaom

Facebook’s Timeline feature is beautiful, although some revile it. But love it or hate it, Timeline is the engineering equivalent of building a racing bike customized for a specific track, only without testing either until race day. At least that’s how Ryan Mack, an infrastructure engineer with Facebook, makes it seem on a blog posted Thursday detailing how Facebook engineered its Timeline feature.

Facebook の Timeline は素晴らしいが、悪口を言う人もいる。 好き嫌いもあるが、Timeline のエンジニアリングは、特定のサーキットにカスタマイズされたレーシング・バイクの開発に等しい。ただし、テストは行われず、ぶっつけ本番でレースに臨んでいる。少なくとも、Facebook のインフラ・エンジニア Ryan Mack にとって、それが彼のやり方のようだ。木曜日(1/5)にポストされたブログが、どのように Facebook Timeline 機能がデザインしたのを、詳述しているように思える。  

Making a legacy MySQL database faster.

クリックで拡大 ⇒

The blog post also offers a ton of data on how Facebook dealt with petabytes of user data stored in legacy MySQL systems on slow disks that could make Timeline less responsive. The company implemented a new architecture that separates out older data to slower disk storage and keeps more recent and more accessed data stored in flash drives and cached using memcached. From the blog:

そして、このブログ・ポストでは、Timeline の反応を遅くしてしまう、低速ディスク上のレガシー MySQL システムにストアされていたペタバイト・ユーザー・データを、Facebook が取り扱った方式についても、膨大なデータが提供されている。 Facebook は、その遅いディスク・ストレージと、従来からのデータを切り離す、新しいアーキテクチャを実装した。それは、直近にアクセスされたデータや、頻繁にアクセスされるデータを、フラッシュ・メモリ・ドライブにストアし、また、memcached にキャッシュするという方式である。以下は、そのブログからの参照である:

Before we began Timeline, our existing data was highly normalized, which required many round trips to the databases. Because of this, we relied on caching to keep everything fast. When data wasn’t found in cache, it was unlikely to be clustered together on disk, which led to lots of potentially slow, random disk IO. …A massive denormalization process was required to ensure all the data necessary for ranking was available in a small number of IO-efficient database requests.

Timeline が開始される前には、既存のデータが高度に正規化されており、対象となるデータベースとの間で、数多くのラウンド・トリップが必要とされていた。 そのような理由から、すべてをキャッシングして、高速化を図るというという手法に依存することにした。 そして、データがキャッシュ上で発見されなかったとき、きわめて低速なランダム I/O が、大量に発生する可能性のあるディスク上のデータを、探さないで済むようにした。つまり、ランキングに必要な全データが、効果的な I/O データベース・リクエストを介して、しかも、少ない呼び出し回数で得られるようにするための、大量の非正規プロセスが必要とされた。

Here’s a visual of the system
クリックで拡大 ⇒

Mack spent a lot of time detailing the challenges of denormalizing the data, which entailed getting an intern to define a custom language that would tell a compiler how to convert old data into the new format and the use of three “data archeologists” to write the conversion rules. It also required Facebook to move older activity data to slower network storage while maintaining acceptable performance. To do this Facebook, “hacked a read-only build of MySQL and deployed hundreds of servers to exert maximum IO pressure and copy this data out in weeks instead of months.”

Mack は、それらのデータの非正規化というチャレンジについて、大量の時間を費やしながら詳述してきた。そこでは、カスタム言語をインターンに定義させることまで必要になり、そこから、古いデータを新しいフォーマットにコンバートする方法を、コンパイラに伝えることになった。 さらに、そのコンバージョン規則を記述するために、3人の「データ考古学者」を採用することにもなった。 そして、受容できるパフォーマンスを維持しながら、さらに古いアクティビティ・データを、低速のネットワーク・ストレージに移動させることも必要となった。 それを実現するために Facebook は、「 MySQL のリード・オンリー・ビルドをハックし、最大の I/O プレッシャーを行使する、数百台のサーバーにディプロイした。 続いて、それらのデータのコピーを、数カ月から数週間に頻度を切り替えて、処理するようにした」。

To speed IO even further, engineers consolidated join tables into a tier of flash-only databases. Since PHP can perform database queries on only one server at a time, Mack said Facebook wrote a parallelizing query proxy that allowed it to query the entire join tier in parallel. Finally Facebook attempted to future-proof its data model, but we’ll see how far that takes it.

さらに I/O を高速化するために、エンジニアたちは複数のテーブルを、フラッシュ・メモリのみで構成されるデータベースの、1つのティアにコンソリデートしていった。 PHP によるデータベース・クエリーは、一度に 1つのサーバーのみという制限がかかるため、 Facebook では、ジョインされているティア全体をパラレルでクエリーしていく、並列化されたクエリー・プロキシーを記述したと、Mack は発言している。 Facebook は最終的に、そのデータ・モデルを future-proof にしようと試みているが、それを私たちが確認するのは、はるか未来になるだろう。

In response to a question I sent Mack, said through a spokesman, that it took Facebook two weeks to dump everyone’s old profile data from the existing system into an archive using “some off-the-shelf network attached storage.” That data was then stored on “the new servers that now power Timeline, which, at the time, were fresh and didn’t have anything hitting them from production. We did incremental updates weekly until later, when we had writes going to both systems in real time.” That’s a lot of fresh servers, although Facebook remained mum about the exact data transferred.

私からの質問に対して、Mack がスポークスマンを介して回答してきたのは、「ストレージにアタッチされた、いくつかの既製品ネットワーク」を用いて、既存システム上の古いプロファイル・データをアーカイブにダンプするのに、2週間を要したというものだった。 続いて、それらのデータは、「いまや Timeline にパワーを供給する新しいサーバーにストアされた。 なお、その時点における、それらのサーバーは、フレッシュなものであり、また、プロダクション・システムからのアクセスが皆無なものであった。私たちは、毎晩遅くまで、Weekly のインクリメタル更新を行なっていった。そして、その時には、2つのシステムに、リアル・タイムで書き込んでいった」とも伝えてきた。 たしかに、大量のフレッシュ・サーバーを用いたのだろうが、転送された正確なデータについては、Facebook は口を閉ざしたままである。

Facebook also built the Timeline aggregator to run locally on each database to avoid information traveling over the network unless that information will be displayed on the page. That’s another timesaver. It also used it’s Hip Hop code for speeding up PHP in that aggregator.

さらに Facebook は、ネットワーク上を情報が移動することを回避するために、個々のデータベース上でローカルに実行される Timeline Aggregator を構築した。 ただし、その情報がページ上に表示される場合には、この情報の移動は制約されない。 つまり、ここでも時間の短縮が図られている。 そして更に、Aggregator の PHP を高速化するために、Hip Hop コードが用いられた。

Building in parallel.

The other element of the blog that I found amazing was how Facebook apparently denormalized its data, had a product team visualizing the Timeline UI, and built a scalable back end system for everything to run on all at the same time. I’m going to call that crazy, but Mack notes that’s what kept the development time frame to a mere six months.

見たところ、Facebook がデータの非正規化を行なっているらしいという、驚くべき発見があったブログには、Timeline UI のビジュアライズと、スケーラブルなバックエンド・システムを、プロダクト・チームが常に同時に構築していたとも書かれている。 私はクレージーだと叫びたいが、Mack の方はというと、6ヶ月間の開発タイム・フレームで保持したものに過ぎないと言っている。

I asked Facebook about what it learned during that process, because I imagine a lot of other sites would love to be able to develop their front and back end systems in parallel and save the cost of replicating their entire production environment’s data to test it. The response a spokesman emailed me from Mack was as follows:

私は、このプロセスで Facebook が学習したことについて尋ねた。 なぜなら、Timeline に限らず、彼らの多くのサイトが、フロント・エンドとバック・エンドを、平行して開発できるようになっていると、想像したからである。また、全体的なプロダクション環境のデータを、テストのためにリプリケートするコストも、排除されていると想像した。 スポークスマンが Mack からのメールを転送してきたが、その答えは以下のとおりである:

Layering is a good way of describing the process of building Timeline. To make sure we could work in parallel, we always made sure that there was at least a temporary technology that each part of the team could build on top of. Some of these were pre-existing, but many of them were quick prototypes built in a couple of days as needed. We also had frequent scrums to identify places where people were blocked on each other, and everyone on the team did an excellent job of knowing what others needed or would soon need.

Timeline の構築プロセスを表現する上で、階層化は良い方式である。 私たちの作業を並列で機能させるために、少なくとも、テンポラリなテクノロジーの上に、チームが構築しているものが在ることを、常に確認していった。 いくつかのテクノロジーは、以前から存在するものであったが、その他の大半は、必要に応じて2~3日で構築されるプロトタイプであった。 それぞれの個人が、相互に守るべき境界線を定めるために、私たちは頻繁に議論してきた。そして、このチームの全員が、他者が必要としていること、また、必要になると思われることを理解するという、素晴らしいジョブを実施していった。

When the production solutions were ready, there was always some friction in migrating from the temporary solution, but usually it was just a few days of work. It was a definite win compared with the weeks or months of delay we’d have faced if we had waited for the production solution up front. Given that we wanted to build the entire system in six months, it was critical that we avoided wasting any time.

そして、プロダクション・ソリューションの準備が整ったとき、テンポラリ・ソリューションからの移行において、いくつかの軋轢が常にあったが、だいたいは数日間の作業でフィックスできた。 このプロダクション・ソリューションを、以前から待っていたとするなら、私たちが直面することになった、数週間あるいは数ヶ月の遅れと比較して、たしかな勝利を収めたと言えるだろう。 全システムを 6ヶ月で構築することが望みだったと考えると、あらゆる時間の浪費を避けたことが、とても重要であった。

From nothing to Timeline in six months is pretty impressive, considering we’re talking about creating something to support more than 800 million users. Now you know a bit more how this Timeline sausage was made.

無から始めて、6ヶ月で Timeline を達成するとは、とても素晴らしい結果である。 そして、8億人以上のユーザーをサポートするための、何らかのものについて、ここで話しているという事実を再認識したい。 そして、いまでは、この Timeline ソーセージが作られた方式について、あなたも少し詳しくなっただろう。

Related research and analysis from GigaOM Pro:

ーーーーー

TAG indexいやぁ~~~ 翻訳していて、これほどゾクゾクしてくるのは、ほんとうに久しぶりの経験でした。 昨年の 11月のことですが、「 Big Data の実装へと走る前に、Better Data について考えるべきだ 」という Formatek のブログポストを訳しました。 そのときには、Better Data のイメージが掴めませんでしたが、ここに書かれている非正規化と、Non ストレージ・アクセス(ゼロではありません)も、きっと、その 1つなのだろうと思えてきます。 こうした柔軟な発想には、ほんとうに脱帽です。 ーーー  __AC Stamp 2

ーーーーー

<関連>

Facebook のスケール感覚に驚愕! _1
Facebook のスケール感覚に驚愕! _2
Facebook 探検隊:どのようなソフトウェアでスケールを達成しているのか _1
Facebook 探検隊:どのようなソフトウェアでスケールを達成しているのか _2
Facebook 探検隊:どのようなソフトウェアでスケールを達成しているのか _3

Google Cloud SQL は、MySQL ライクな UI と、DC 間同期をサポートする

Posted in Google by Agile Cat on October 7, 2011

Google Cloud SQL: Your database in the cloud
Thursday, October 6, 2011
http://googleappengine.blogspot.com/2011/10/google-cloud-sql-your-database-in-cloud.html

image
Cross-posted from the Google Code Blog

One of App Engine’s most requested features has been a simple way to develop traditional database-driven applications. In response to your feedback, we’re happy to announce the limited preview of Google Cloud SQL. You can now choose to power your App Engine applications with a familiar relational database in a fully-managed cloud environment. This allows you to focus on developing your applications and services, free from the chores of managing, maintaining and administering relational databases. Google Cloud SQL brings many benefits to the App Engine community:

App Engine に寄せられるリクエストとして最も多かったものは、従来からのデータベース駆動型のアプリケーションを開発するための、シンプルな方式を提供して欲しいというものだった。 そのフィードバックに応えるために、私たちは Google Cloud SQL の限定プレビューを、喜びと伴に発表する。これからは、App Engine のアプリケーションにパワーを提供するために、フル・マネージド・クラウド環境において、慣れ親しんだリレーショナル・データベースを選択できる。それにより、アプリケーションとサービスの開発に専念できるようになり、また、リレーショナル・データベースの管理/維持/運営における煩わしさから解放される。 Google  Cloud SQL は、App Engine コミュニティに、数多くのメリットをもたらす:  

  • No maintenance or administration – we manage the database for you.
  • High reliability and availability – your data is replicated synchronously to multiple data centers. Machine, rack and data center failures are handled automatically to minimize end-user impact.
  • Familiar MySQL database environment with JDBC support (for Java-based App Engine applications) and DB-API support (for Python-based App Engine applications).
  • Comprehensive user interface for administering databases.
  • Simple and powerful integration with Google App Engine.
  • 管理と運営が不要 ー 私たちが、あなたのデータベースを管理する。
  • 高度な信頼性と可用性 ー あなたのデータのプリケートは、マルチ・データセンター間におけ同期により実現される。 マシン/ラック/データセンターにおける障害を、自動的に処理することで、エンドユーザーへの影響は最小限に留められる。
  • MySQL ライクなデータメース環境を、JDBC サポート (for Java-based App Engine applications) と DB-API サポート (for Python-based App Engine applications) により実現する。
  • データベース管理のための、一貫したユーザー・インターフェイスを提供する。
  • Google App Engine との、シンプルでパワフルなインテグレーション。

The service includes database import and export functionality, so you can move your existing MySQL databases to the cloud and use them with App Engine. Cloud SQL is available free of charge for now, and we will publish pricing at least 30 days before charging for it. The service will continue to evolve as we work out the kinks during the preview, but let us know if you’d like to take it for a spin.

このサービスには、データベースの import/export 機能が含まれるため、既存の MySQL データベースをクラウドに移行し、App Engine と組み合わせて利用できる。 しばらくの間は、Cloud SQL の無料での利用が可能である。 そして、少なくとも、課金を開始する 30日前には、その価格体系を発表することになる。 たとえば、プレビュー期間であっても、このサービスは進化し続けるが、使用期間中に気づいたことがあれば、ぜひ、教えて欲しい

Posted by Navneet Joneja, Product Manager for Google Cloud SQL

ーーーーー

TAG indexついにキマシタね! おそらく、MySQL の活用を回避するという決定が、Oracle による SUN の買収に際して下されたのだろうと推測できます。 それにしても、データセンター間のを [ data is replicated synchronously to multiple data centers ]と言い切っているのがスゴイですね。 これは、先日の Todd Hoff さんのブログ[ 3つの世代を振り返る ]にあった、Instant アーキテクチャの活用につながるのでしょうか? そして、弱点とされてきた、スケールに対応できない Google App Engine という烙印が、これで消えることになりそうです。 しかも、革新的なアーキテクチャの投入も、充分に期待できそうです。さらに、もう 1つですが、Google が IBM から、1000項目以上の特許を購入した理由も、この辺りに有りそうですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Google の 3つの世代を振り返る – Batch, Warehouse, Instant
Larry Page さん、あなたのリストから Google Apps が漏れているのですが?
Google が OSS NoSQL として発表した、LevelDB の狙いは Chrome にあるのか?
Google は IBM から、1030 個の特許を取得する!
Google App Engine は エンタープライズ市場で戦えるのか?
Google のソフトウェア・インフラは時代遅れだと、元 Wave エンジニアが語る
もう SLA なんて不要だ – Google が自慢する究極のインフラ
メジャー・クラウドの比較テスト Part_1 : 性能は Amazon S3 と Azure が圧勝

%d bloggers like this: