Agile Cat — in the cloud

Google が擁護する、App Engine におけるロックインの定量化とは?

Posted in .Selected, Google, Interoperability, PaaS by Agile Cat on September 12, 2013

Google defends, quantifies App Engine lock-in concerns
http://wp.me/pwo1E-6Cw
By
Derrick Harris – JUL. 9, 2013
http://gigaom.com/2013/07/09/google-defends-quantifies-app-engine-lock-in-concerns/

_ Gigaom

Summary: Google App Engine’s engineering director, Peter Magnusson, took to Google+ on Tuesday to dispute a lingering reputation the company is trying to lock in developers with its PaaS offering.

Summary: 火曜日のことだが、Google App Engine の Engineering Director である Peter Magnusson は、同社が提供する PaaS により開発者をロックするという、いつまでも消えない評判を戦うために、Google+ に登場した。

photo: Shutterstock / Mopic

Google App Engine engineering director Peter Magnusson has some good news and some bad news about his product. The good news: Contrary to its reputation among some people, Google isn’t locking anybody in by design. The bad news: In practice, it is kind of locking in developers, though.

Google App Engine の Engineering Director である Peter Magnusson は、自身のプロダクトに関して、いくつかの Good News と Bad News を持っている。Good News:何人かの人々が言う悪評に反して、Google はデザイン面で誰もロックしていない。 Bad News:しかし、実際のところ、それは開発者をロックする、ある種のものである。

Magnusson laid out his case in a lengthy Google+ post Tuesday morning in which he explains away lock-in as a case of necessary trade-offs. Essentially, he argues, you can either have access to the guts of the infrastructure and the flexibility — and operational effort — that comes along with that, or you can free yourself of those headaches by using someone else’s abstractions. If you’re using App Engine, that means you also get to use rad features such as Datastore and take advantage of Google’s know-how around things such as load balancing and fending off DDoS attacks.

火曜日の朝の長い Google+ ポストで Magnusson は、必要なトレードオフのケースとして、ロックインとは切り離した自身の経験について説明している。彼の基本的な主張は、インフラとフレキシビリティの本質にアクセスし、また、それに伴う運用上の取り組みを達成できるというものである。さもなければ、他の誰かが考えた、抽象化の概念を用いて、それらの悩みから自身を解放できるという。 つまり、あなたが App Engine ユーザーなら、すでに Datastore などの素晴らしい機能を利用し、また、ロード・バランシングや DDoS 対策といった、先進的な機能を利用していることになる。

With the right practices, portability is possible

Additionally, Magnusson writes, there are generic best practices developers can use to create applications that should be relatively easy to port between modern web application platforms. And, he continues:

それに加えて Magnusson は、アプリケーション構築にデベロッパーが用いる、汎用的なベスト・プラクティスが存在しており、最新の Web アプリケーション・プラットフォームを結びつけるために、それほど難しくなく移植できるはずだと述べている。さらに続けて:

“The stacks that these abstractions map to are replaceable by you. The Google Cloud Datastore is “just” anther NoSQL/NearSQL solution and can be replaced by stacks such as MongoDB; memcache is memcache; MySQL can obviously replace Google Cloud SQL; and the language containers are mostly forward compatible with other containers. Significant portions of the client environment, such as NDB, are open sourced by us already. When we add new building blocks like the Go language, we open source the whole language.”

これらの抽象概念がマップするスタックは、あなたによりリプレースが可能である。たとえば Google Cloud Datastoreは、まさに別の NoSQL/ NearSQL ソリューションであり、MongoDB といったスタックによりリプレースできる。 memcache は memcache のままであが、言語コンテナは他のコンテナに対して上位互換性を持つ。たとえば NDB などの、クライアント環境における重要な部分は、すでにオープンソース化されている。 さらに言えば、Go 言語のような新しいビルディング・ブロックを追加するとき、その言語全体が、オープンソース化されていく。

Want more proof? Magnusson points to Google’s partnership with open-source App Engine implementations such as AppScale, as well its work with Red Hat to bring the App Engine APIs to the JBoss and OpenShift platforms. Oh, and the rollout of the Google Compute Engine platform for users who really do want control at the infrastructural level.

これ以上の証明が、必要とされるだろうか? Magnusson は、オープンソース App Engine 実装する、たとえば AppScale と Google のパートナーシップを指摘するだけではなく、JBoss および OpenShift のプラットフォームに、App Engine の API を取り込むための、Red Hat との協業にも触れている。そして、インフラレベルでのコントロールを必要とするユーザーに対しては、Google Compute Engine プラットフォームを展開しているのだ。

The App Engine homepage.

Now here comes the “but …”

All that said, there is the cold, hard truth that running on a platform like Google App Engine (or, one could argue, almost any other cloud platform) inherently involves some degree of lock-in. Google does exit interviews with large-scale customers when they leave, and it has found the average time for them to successully move their application to a new platform is three to four months. “I would posit that this is not materially worse than any other public-cloud-to-public-cloud transition once you have a complex system up and running,” Magnusson wrote.

ここで述べてきた、すべての事柄を、Google App Engine(大半のクラウド・プラットフォームも同じだといえる)のような、いくつかの点でロックインと本質的に絡み合うプラットフォーム上で実現するにしても、ある種の冷たい響きを拭い去れない。 大口の顧客が Google から去るとき、彼らは出口インタビューを行なっている。 そして、それらの顧客が、新しいプラットフォームへアプリケーションを移動するために、平均で 3~4ヶ月を要しているという事実を見つけた。「それは、複雑なシステムを構築/運用し始めた後に、あるパブリック・クラウドから他のパブリック・クラウドへと移行するのと比較して、大きく悪化することはないと、私は仮定していたのだろう 」と、Magnusson は述べている。

All biases considered, Magnusson does make some good points. I’ve argued essentially the same thing before about Amazon Web Services — it’s a matter of expectation lock-in more than technological lock-in — and it probably holds true for just about every Platform-as-a-Service and Infrastructure-as-a-Service offering around. You could technically rewrite an application for any number of similar database or storage services, for example, but it’s the parts you like about a particular provider’s service that are hard to replicate.

すべてのバイアスを考慮した上で、Magnusson は、いくつかの興味深い点を指摘している。以前に、Amazon Web Services について、本質的に同じことだと主張している。 それは、テクニカルなロックインというより、期待どおりのロックインである。そして、おそらく、ほぼすべての Platform-as-a-Service と Infrastructure-as-a-Service について言えることでもある。 たとえば、技術面で類似したデータベースやストレージ・サービスへ向けて、あらゆるアプリケーションを書き換えられるだろうが、特定のプロバイダが提供するサービスを好むなら、その複製も難しくなってしまう。

Even with an open source project like OpenStack, easy portability isn’t guaranteed. Yes, the underlying code and building blocks might be the same, but it’s the differences among OpenStack-based providers that makes a market. If everyone looked and functioned exactly the same, there would be no reason to consider anything other than Rackspace in the public cloud.

OpenStack のようなオープンソース・プロジェクトであっても、容易なポータビリティが保証されるわけではない。Yes! 基本的なコードやビルディング・ブロックは同じかもしれないが、そこには、市場を構成する OpenStack ベース・プロバイダごとの差異がある。誰もが見ても、まったく同じように機能するなら、パブリック・クラウドにおいて、Rackspace の以外の環境を検討する必要もなくなるだろう。

Beside, moving a serious application from one cloud to another will never be enjoyable no matter how architecturally similar they are. Although, management layers such as RightScale, Scalr or Enstratius (now Dell Multi-Cloud Manager) could help mitigate some of that pain, and the Cloud Foundry community is trying to make portability among Cloud Foundry instances, at least, relatively pain-free.

話はそれるが、きわめて重要なアプリケーションを、あるクラウドから他のクラウドに移行することは、どれほどアーキテクチャが似通っていても、決して楽しい作業ではない。しかし、RightScale や、ScalrEnstratius (現 Dell Multi-Cloud Manager)などのマネージメント・レイヤを用いることで、その痛みも、いくぶんは軽減されるかもしれない。また、Cloud Foundry のコミュニティでは、Cloud Foundry インスタンス間でのポータビリティを実現しようとしている。そうなれば、少なくとも、痛みから開放される。

As with so many things in life, the “which cloud to choose?” debate really boils down to picking your poison. You can probably count on loving some aspects and hating others. But you’re also probably stuck with it for a while, so choose carefully.

人生における数多くの物事と同じように、「どのクラウドを選ぶべきか?」という議論は、「毒を食らわば」という発想に至りやすい。 おそらく、いくつかの側面は好ましく、いくつかは好ましくないという、何らかの判断に依存することになるのだろう。しかし、多くの人びとは、まだ、躊躇しているのだろう。 だからこそ、慎重に選択して欲しい。

Feature image courtesy of Shutterstock user Mopic.

Related research

ーーーーー

google-55a昨年の 9月にポストした、『 クラウド・ベンダー・ロックインと闘うための 五箇条の御誓文 』という抄訳には ーーー 数多くの人々が、そうしたように、私も App Engine の学習に、長い時間を費やしてきた。そして、App Engine を使っている多くの人々のように、それは間違いなのかと案じている。なぜなら、あなたの投資と開発の産物である、あらゆるアプリケーションが、App Engine だけで走るのものになってしまうのだから ーーー という、Google Groups フォーラムに書かれたメッセージが引用されていました。抽象度が高まれば、互換性が薄れていく。 だからといって、互換性に固執すれば、イノベーションの速度が落ちていく。とても難しい問題です。__AC Stamp 2

ーーーーー

<関連>

クラウドに潜む、見えないコストについて言及しておこう
この一年で、OSS への支出が 56% に跳ね上がった
NIST の Cloud Architecture 序文
NIST の Cloud Architecture 概要
NIST の Cloud Architecture – プロバイダとユーザーのスコープ

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 では無いのだ!

 

クリエーションラインが展開する、CloudStack/MidoNet/Cloudian 統合戦略とは?

Posted in Businesses, Cloud Stack, OpenFlow, SDN by Agile Cat on January 30, 2012

日本発クラウド・スタートアップの、クリエーションライン、ミドクラ、ジェミナイの三社提携
http://wp.me/pwo1E-3RM

Agile_Cat_Loupe

昨年末のことですが、クリエーションライン、ミドクラ、ジェミナイの三社提携が発表されました。 その後、クリエーションラインの安田さんと会い、この件の概要を教えてもらうという機会を得ました。

この三社の守備範囲は、それぞれ、クリエーションラインが CMS(Cloud Management Systems)で、ミドクラが SDN(Software Defined Networking )、そしてジェミナイが Storage という分担です。 そして、この提携のコアは CloudStack であり、また、クリエーションラインがハブになることで、この3つの要素をつなげていくというものです。

imageつまり、シングル・ポイント・ビューを実現する CMS の管理画面から、クラウド・フレームワークと、ネットワークと、ストレージを透過的に管理できるようになるわけです。 CloudStack については、他にも情報がありますので、ここでは説明を割愛しますが、なぜ、SDN と ストレージがキー・コンポーネントになるのかという点について、クリエーションラインが考えていることを、簡単にまとめていきます。

まず、SDN ですが、最近のクラウドのトレンドとして、データセンター内の管理を容易にするというニーズが高まっているとのことです。 つまり、膨大な数のサーバーを確実に管理するには、物理的な結線を一度行ったら、その後はソフトウェアを介して管理する方が、その運用が容易になるという発想です。ここで管理する要素としては、NAT や、ファイヤーウォール、ロードバランシングといったものを含む、ネットワーク全体が対象になります。

imageクラウド・シフトの理由の 1つとして、性能/信頼性/コストという条件に応じて、適切なプロバイダーをいつでも選び直せるという点があります。 しかし、こうしたデータセンター内のネットワーク管理が、従来からの物理的な結線や各アプライアンスといった、個別の設定変更に依存しているのでは、その効果も半減してしまいます。 それは、クラウドを拡張する際にも言えることであり、単にコストに留まらず、安全な運用をという視点からも考えるべき、重要な問題となります。

SDN の役割としては、前述のとおりデータセンター内の運用というレベルがありますが、クラウドが進化していくにつれて、マルチ・データセンター間での連携というステージが浮上してきます。 そのときに、どのレベルのネットワーク・レイヤーが要求されるのでしょう? 少なくとも、L3 以上が必要になるわけですが、L4 ~ L7 も考慮すべきなのかも知れません。ミドクラの MidoNet は、L3 はもちろんのこと、それより上位のレイヤーも視野に入れています。 つまり、将来のネットワーク・アーキテクチャを、長期的なスパンでカバーできる点に、クリエーションラインは魅力を感じているようです。

clip_image001その一方で、SDN と比べると、ストレージは成熟した市場です。 そして、エクスペリエンスが広く共有され、1つの指標となっているのが Amazon S3 の存在です。 そのような背景から、数多くのストレージ・ベンダーが、Amazon S3 用に開発されたソフトウェア資産をターゲットに、新しいプロダクトやサービスを展開しているという、ワールドワイドなトレンドがあります。 その流れに乗り、SDN のミドクラと同様に、世界のマーケットへ向けて、日本発のテクノロジーを展開しているのがジェミナイです。(Agile_Cat は以前、ジェミナイって海外ベンダーだと勘違いしていました :)

ジェミナイの提供する Cloudian は Cassandra ベースのストレージであり、S3 互換の API を備えているため、ユーザーはもちろんのこと、ツール 類を提供するサードパーティへも訴求していけます。 そして、すでに Nifty などへの導入実績があることも魅力とのことです。Cassandra は、Rackspace からスピンアウトした DataStax(元 riptano)が商用化を目指していた、Apache の NoSQL プロジェクトです。 NoSQL の宿命ともいえる、コンシステンシーとパフォーマンスという相反する要素を、ニーズに合わせてカスタマイズできるプロダクトだと認識していますが、どのようにジェミナイが処理しているのか、とても興味があります。

クリエーションラインとしては、ClousStack/MidoNet/Cloudian を統合する環境を提供していくことになります。つまり、それらのサービスが提供する各種 API に精通し、また、ノウハウを蓄積している点が、同社のエクスペリエンスであり、またセールスポイントだということです。この領域は、ユーザーが個別にソリューションを考えるより、たとえばクリエーションラインの CRM のような、汎用化された統合テクノロジーを利用する方が効率化を図れます。そして、クリエーションラインは、CloudStack だけに特化したソリューションを提供するのではなく、OpenStack などを含むオープンクラウド全般に取り組んでいくとのことです。 そのときにも、MidoNet と Cloudian の API を介して、SDN とストレージを効果的に利用していくソリューションが提供されるはずです。

今後、クリエーションラインでは実証実験などを行なっていくとのことです。そして、時期が来たら、その結果を公表するとのことです。 目指すはワールドワイド・マーケットですが、この三社は日本発のクラウド・スタートアップであり、日本のビジネス・スタイルに最適化したサービスの提供も考えています。これまで、世界の市場と向き合ってきたのは、主として大手のベンダーであり、国内で確立したビジネスをベースに、新たに海外を狙っていくというスタンスでした。 ところが、この三社は、それぞれの設立時から、ビジネスを国内に限定することなく、テクノロジーを磨き上げてきた会社です。 海外のスタートアップを見れば、それが当たり前なのですが、ようやく日本でも、そのような兆しが見えてきたことを嬉しく思います。

ーーーーー

<関連>

Citrix が Cloud.com を買収!
OpenStack における SDN コネクションを探求する _1
OpenStack における SDN コネクションを探求する _2
AT&T が OpenStack に参加した!
さらなる クラウド M&A が押し寄せる

Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚 by James Hamilton

Posted in .Selected, Amazon, James Hamilton, NoSQL by Agile Cat on January 27, 2012

Amazon DynamoDB: NoSQL in the Cloud
http://wp.me/pwo1E-3R0
Wednesday, January 18, 2012
http://perspectives.mvdirona.com/2012/01/18/AmazonDynamoDBNoSQLInTheCloud.aspx

_ perspectives

Finally! I’ve been dying to talk about DynamoDB since work began on this scalable, low-latency, high-performance NoSQL service at AWS. This morning, AWS announced availability of DynamoDB: Amazon Web Services Launches Amazon DynamoDB – A New NoSQL Database Service Designed for the Scale of the Internet.

ついに、この日がやってきた!AWS における、スケーラブル/ロー・レイテンシ/ハイ・パフォーマンスな NoSQL サービスに着手したときから、この DynamoDBについて話したいとを強く望んでいた。 今朝のことだが、DynamoDB の提供が開始されたと AWS が発表した: Amazon Web Services Launches Amazon DynamoDB – A New NoSQL Database Service Designed for the Scale of the Internet.

In a past blog entry, One Size Does Not Fit All, I offered a taxonomy of 4 different types of structured storage system, argued that Relational Database Management Systems are not sufficient, and walked through some of the reasons why NoSQL databases have emerged and continue to grow market share quickly. The four database categories I introduced were: 1) features-first, 2) scale-first, 3) simple structure storage, and 4) purpose-optimized stores. RDBMS own the first category.

私は以前のブログ・エントリーである One Size Does Not Fit All で、構造化されたストレージ・システムに関する、4種類のタクソノミーを提供している。そこでは、Relational Database Management Systems が十分ではないことを論じ、また、NoSQL データベースが出現した理由と、素早くマーケット・シェアを拡大し続ける理由について、簡単に説明している。 私が紹介した 4つのデータベース・カテゴリーは: 1) features-first 機能優先、2) scale-first スケール優先、3) simple structure storage シンプルなストレージ構成、4) purpose-optimized stores 目的に最適化されたストア、であった。そして、RDBMS が持つのは、最初のカテゴリのみである。

DynamoDB targets workloads fitting into the Scale-First and Simple Structured storage categories where NoSQL database systems have been so popular over the last few years. Looking at these two categories in more detail.

DynamoDB は、Scale-First と Simple Structured Storage のカテゴリにフィットした、ワークロードをターゲットにするものであるが、これらの領域は、これまでの数年にわたって、NoSQL データベース・システムで人気を集めているところである。これら 2つのカテゴリについて、さらに詳細を追いかけよう。

Scale-First is: Scale-first applications are those that absolutely must scale without bound and being able to do this without restriction is much more important than more features. These applications are exemplified by very high scale web sites such as Facebook, MySpace, Gmail, Yahoo, and Amazon.com. Some of these sites actually do make use of relational databases but many do not. The common theme across all of these services is that scale is more important than features and none of them could possibly run on a single RDBMS. As soon as a single RDBMS instance won’t handle the workload, there are two broad possibilities: 1) shard the application data over a large number of RDBMS systems, or 2) use a highly scalable key-value store.

Scale-First:Scale-first アプリケーションは、境界に影響されることなく、また、あらゆる制約から開放された方式で、絶対的にスケーラブルであることが、その他の機能よりも優先する。 これらのアプリケーションは、Facebook/MySpace/Gmail/Yahoo/Amazon.com といった、きわめてハイ・スケールな Web サイトにより実証される。 これらのサイトにおいて、いくつかのリレーショナル・データベース利用例があるが、大半は別の方式を採用するという現実がある。それら全てのサービスを横断する普遍的なテーマは、スケーラブルであることが機能よりも重要であり、また、それらをシングル RDBMS 上で実現することは、不可能だろうという点に集約される。 シングル RDBMS インスタンスが、対象となるワークロードを処理しきれない場合に、すぐに適応できる 2つの対応策がある: 1) 大量の RDBMS システム上に、アプリケーション・データを Sharding する。あるいは、2) きわめてスケーラブルな Key-Value ストアを使用する。

And, Simple Structured Storage: There are many applications that have a structured storage requirement but they really don’t need the features, cost, or complexity of an RDBMS. Nor are they focused on the scale required by the scale-first structured storage segment. They just need a simple key value store. A file system or BLOB-store is not sufficiently rich in that simple query and index access is needed but nothing even close to the full set of RDBMS features is needed. Simple, cheap, fast, and low operational burden are the most important requirements of this segment of the market.

Simple Structured Storage: 構造化されたストレージ要件を持つ、数多くのアプリケーションが存在するが、そこでは、RDBMS の機能と、コスト、複雑さが必要とされないのも現実である。 また、それらのアプリケーションは、Scale-first の構造化されたストレージ・セグメントが要求する、スケールに対してフォーカスすることもない。 つまり、そこでは、シンプルな Key-Value ストアだけが必要とされる。 必要とされるシンプル・クエリーとインデックス・アクセスにおいて、何らかのファイル・システムや BLOB ストアが、その要件を十分に充たすことはないが、RDBMS のフル機能に似たようなものは、何も必要とされない。 シンプル/安価/高速で、運用上の負担を低減するソリューションが、このマーケット・セグメントにおいて、最も重要な要件である。

_ AmazonMore detail at: One Size Does Not Fit All.

The DynamoDB service is a unified purpose-built hardware platform and software offering. The hardware is based upon a custom server design using Flash Storage spread over a scalable high speed network joining multiple data centers.

DynamoDB は、目的に合せて構築されたハードウェア・プラットフォームと、ソフトウェアが提供するサービスである。 そのハードウェアは、接続されるマルチ・データセンターに対して、高速でスケーラブルなネットワークを供給するために、Flash  Storage 用いたカスタム・サーバー・デザインをベースにしている。

DynamoDB supports a provisioned throughput model. A DynamoDB application programmer decides the number of database requests per second their application should be capable of supporting and DynamoDB automatically spreads the table over an appropriate number of servers. At the same time, it also reserves the required network, server, and flash memory capacity to ensure that request rate can be reliably delivered day and night, week after week, and year after year. There is no need to worry about a neighboring application getting busy or running wild and taking all the needed resources. They are reserved and there whenever needed.

DynamoDB がサポートするのは、プロビジョニングされたスループット・モデルである。 DynamoDB アプリケーションのプログラマーは、自身のアプリケーションがサポートすべき、毎秒ごとのデータベース・リクエスト数を決定する。 そして DynamoDB は、適切な数のサーバー上に、テーブルを自動的に供給していく。 それと同時に、たとえば日/週/年の単位で、リクエスト・レートが確実に供給されることを保証するために、要求されるネットワーク/サーバー/フラッシュ・メモリの容量を確保する。そして、隣接するアプリケーションがビジーになることや、制御不能な状況に陥ること、そして、必要とするリソースを奪っていってしまうようなことを、心配する必要は無い。それらの確保されたリソースは、必要とされるときに、必ず供給される。

The sharding techniques needed to achieve high requests rates are well understood industry-wide but implementing them does take some work. Reliably reserving capacity so it is always there when you need it, takes yet more work. Supporting the ability to allocate more resources, or even less, while online and without disturbing the current request rate takes still more work. DynamoDB makes all this easy. It supports online scaling between very low transaction rates to applications requiring millions of requests per second. No downtime and no disturbance to the currently configured application request rate while resharding. These changes are done online only by changing the DynamoDB provisioned request rate up and down through an API call.

高度なリクエスト・レートを達成する、Sharding のテクニックが必要とされていることは、この業界において広く認識されている。 しかし、それを実装するには、いくつかの作業が欠かせない。 つまり、キャパシティの確保が、必要とされるときに、常に約束されるようにするには、多くの作業が要求される。オンライン時にリクエスト・レートに影響をあたえることなく、 割り当てられているリソースの増減を達成するには、さらに多くの作業が要求される。 DynamoDB は、それら全ての容易に実現する。 具体的には、きわめて低いトランザクション・レートから、何百万回(秒)のレートを必要とするアプリケーションを、停止すること無くスケーリングしていく。 また、Re-Sharding を行う間も、そこ時点でコンフィグレーションされている、アプリケーション・リクエスト・レートを妨害することはなく、もちろん、ダウンタイムを要求することもない。 これらの変更は、プロビジョニングされている DynamoDB のリクエスト・レートを、API コールを介して変更するだけで、オンラインを維持しながら達成される。

In addition to supporting transparent, on-line scaling of provisioned request rates up and down over 6+ orders of magnitude with resource reservation, DynamoDB is also both consistent and multi-datacenter redundant. Eventual consistency is a fine programming model for some applications but it can yield confusing results under some circumstances. For example, if you set a value to 3 and then later set it to 4, then read it back, 3 can be returned. Worse, the value could be set to 4, verified to be 4 by reading it, and yet 3 could be returned later. It’s a tough programming model for some applications and it tends to be overused in an effort to achieve low-latency and high throughput. DynamoDB avoids forcing this by supporting low-latency and high throughout while offering full consistency. It also offers eventual consistency at lower request cost for those applications that run well with that model. Both consistency models are supported.

API による透過的のサポートに加えて、リソースの確保については、プロビジョニングされるリクエスト・レートの、オンラインにおけるスケールを 6段階で増減できる。 つまり DynamoDB は、コンシステンシーとマルチ・データセンターにおける、2つの冗長性に対応する。 インベンチュアル・コンシステンシーは、いくつかのアプリケーションにとっては素晴らしいプログラミング・モデルであるが、別の状況においては、紛らわしい結果をもたらす場合もある。 たとえば、何らかの値を 3に設定し、続いて 4に変更しても、それを読み返すときに 3が返される可能性があるのだ。 さらに悪いことに、4 に設定された値が、4であると確かめられた後に、依然として 3が返される場合もある。 それは、いくつかのアプリケーションにとっては、利用が困難なプログラミング・モデルであり、また、ロー・レイテンシとハイ・スループットを達成するために、過度に使用されるという傾向を持つ。  DynamoDB は、ロー・レイテンシとハイ・スループットをサポートしながら、フル・コンシステンシーを提供することで、こうした問題の発生を回避している。 さらに、このモデルを適切に実行するアプリケーションの、リクエスト・コストを抑制する場合には、インベンチュアル・コンシステンシーも提供される。つまり、2つのコンシステンシー・モデルがサポートされる。

Amazon-DynamoDBIt is not unusual for a NoSQL store to be able to support high transaction rates. What is somewhat unusual is to be able to scale the provisioned rate up and down while on-line. Achieving that while, at the same time, maintaining synchronous, multi-datacenter redundancy is where I start to get excited.

NoSQL が、高度なトランザクション・レートをサポートできたとしても、べつに異常なことではない。 通常と異なる点があるとすれば、オンラインを維持しながら、プロビジョニングされたレートを、上下にスケールできることである。それを達成すると同時に、マルチ・データセンターの同期をとることで、その冗長性を維持できるところが、私がエキサイトするところである。

Clearly nobody wants to run the risk of losing data but NoSQL systems are scale-first by definition. If the only way to high throughput and scale, is to run risk and not commit the data to persistent storage at commit time, that is exactly what is often done. This is where DynamoDB really shines. When data is sent to DynamoDB, it is committed to persistent and reliable storage before the request is acknowledged. Again this is easy to do but doing it with average low single digit millisecond latencies is both harder and requires better hardware. Hard disk drives can’t do it and in-memory systems are not persistent so flash memory is the most cost effective solution.

データを失うというリスクを、望む人がいないのは明らかであるが、NoSQL システムの定義は Scale-First である。 高度なスループットとスケールを達成するための、唯一の方式がリスクを冒すことであり、また、コミット時にデータをパーシスタント・ストレージに入れると約束できないなら、そのような事態が頻繁に生じるということである。 そして、この点が、DynamoDB が本当に輝くところである。 データが DynamoDB に送られるとき、そのリクエストが承認される前に、信頼できるパーシスタント・ストレージに対してコミットが行われる。 繰り返すが、それを実現することは容易である。 ただし、平均で一桁台のミリセカンド・レイテンシを達成することは困難であり、また、より良いハードウェアを必要とする。 ハードディスク・デバイスを用いて、それを達成することは不可能だ。 そして、イン・メモリのシステムはパーシスタントでないため、フラッシュ・メモリが最も費用効果の高いソリューションとなる。

But what if the server to which the data was committed fails, or the storage fails, or the datacenter is destroyed? On most NoSQL systems you would lose your most recent changes. On the better implementations, the data might be saved but could be offline and unavailable. With dynamoDB, if data is committed just as the entire datacenter burns to the ground, the data is safe, and the application can continue to run without negative impact at exactly the same provisioned throughput rate. The loss of an entire datacenter isn’t even inconvenient (unless you work at Amazon :-)) and has no impact on your running application performance.

しかし、そのデータをコミットするサーバーが失敗したら、あるいは、ストレージが失敗したら、データセンターに障害が発生したら、いったい、どうなるのだろう? 大半の NoSQL システムでは、直近の更新が失われてしまうだろう。  それよりも優れた実装が行われていれば、データは保存されるかもしれないが、オフラインとなり、利用できなくなるケースも生じるだろう。 dynamoDB を用いるなら、データをコミットしたときにデータセンターが火災にあっても、そのデータは安全である。 そして、あなたのアプリケーションは、プロビジョニングされたときと、まったく同じスループットレートで、悪影響を受けることなく走り続けるだろう。1つのデータセンターが、まるごと吹っ飛んでも、たいした問題ではない(あなたが Amazon の従業員でない限り :) )。 そして、実行中のアプリケーションに、パフォーマンスの問題が生じることもない。

Combining rock solid synchronous, multi-datacenter redundancy with average latency in the single digits, and throughput scaling to the millions of requests per second is both an excellent engineering challenge and one often not achieved.

強固で堅実な同期と、平均で一桁台のレイテンシを持つマルチ・データセンターの冗長性、そして、何百万回/秒というリクエストをスケーリングするスループットの組み合わせは、エンジニアリングにおける素晴らしいチャレンジであり、また、達成できるのも稀なものである。

More information on DynamoDB:

· Press Release: http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-newsArticle&ID=1649209&highlight=
· DynamoDB detail Page:
http://aws.amazon.com/dynamodb/
· DynamoDB Developer Guide: http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/
· Blog entries:
· Werner:
http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html
· Jeff Barr: http://aws.typepad.com/aws/2012/01/amazon-dynamodb-internet-scale-data-storage-the-nosql-way.html
· DynamoDB Frequently Asked Questions:http://aws.amazon.com/dynamodb/faqs/
· DynamoDB Pricing: http://aws.amazon.com/dynamodb/pricing/
· GigaOM: http://gigaom.com/cloud/amazons-dynamodb-shows-hardware-as-mean-to-an-end/
· eWeek: http://www.eweek.com/c/a/Database/Amazon-Web-Services-Launches-DynamoDB-
a-New-NoSQL-Database-Service-874019/

· Seattle Times: http://seattletimes.nwsource.com/html/technologybrierdudleysblog/
2017268136_amazon_unveils_dynamodb_databa.html

Relational systems remain an excellent solution for applications requiring Feature-First structured storage. AWS Relational Database Service supports both the MySQL and Oracle and relational database management systems: http://aws.amazon.com/rds/.

Feature-First の構造化されたストレージを必要とするアプリケーションにとって、リレーショナル・システムは優れたソリューションであり続ける。 そして、AWS Relational Database Service は、MySQL と Oracle 、そして、リレーショナル・データベース・マネージメント・システムをサポートする:http://aws.amazon.com/rds/.

Just as I was blown away when I saw it possible to create the world’s 42nd most powerful super computer with a few API calls to AWS (42: the Answer to the Ultimate Question of Life, the Universe and Everything), it is truly cool to see a couple of API calls to DynamoDB be all that it takes to get a scalable, consistent, low-latency, multi-datacenter redundant, NoSQL service configured, operational and online.

いくつかの API コールを AWS へ送るだけで、世界で 42位のスーパー・コンピュータが構成できるという事実は、私を仰天させた(42: the Answer to the Ultimate Question of Life, the Universe and Everything)。それと同要に、いくつかの DynamoDB API をコールすることで、スケーラブル/コンシステンシー/ロー・レイテンシなマルチ・データセンターにおける冗長性と、コンフィグレーションされた NoSQL サービス、そして、オンラインによるオペレーションの全てが得られるとは、まさに COOL なことである。

–jrh

ーーーーー

_ perspectivesなんというか、息をのむ迫力です。 優れたテクノロジーと AWS のスケールが組み合わされると、このようなものが出来てしまうのですね。 最後の締め括りで、James Hamilton さんが言っているように、DynamoDB であるうがスパコンであろうが、API を叩けば誰でも使えるという、コモディティ感覚が素晴らしいです。 ある意味、「京」などは、その足元にも及びません。 文句なしに スゴイ! 以下の<関連>も、ぜひ ご覧ください。 ーーー __AC Stamp 2

ーーーーー

<関連>

イベンチュアル・コンシステンシーはお好き? — by James Hamilton
Stonebraker と CAP Theorem と Databases – by James Hamilton
Database System エラーと Eventual Consistency と CAP Theorem _1
Database System エラーと Eventual Consistency と CAP Theorem _2
Amazon の James Hamilton が語る、効率の良いデータセンター運用のコツとは?
Facebook メッセージを支えるストレージ・インフラを解説 – James Hamilton

Google が OSS NoSQL として発表した、LevelDB の狙いは Chrome にあるのか?

Posted in Google, HTML5, NoSQL by Agile Cat on August 1, 2011

Google Open-Sources NoSQL Database Called LevelDB
By
Klint Finley / July 30, 2011 10:30 AM
http://www.readwriteweb.com/hack/2011/07/google-open-sources-nosql-data.php

_ Read Write

_ googleIn May Google open-sourced a BigTable-inspired key-value database library called LevelDB under a BSD license. It was created by Jeff Dean and Sanjay Ghemawat of the BigTable project at Google. It’s available for Unix based systems, Mac OS X, Windows, and Android.

この 5月に Google は、LevelDB という名の、BigTable を彷彿とさせる key-value データベース・ライブラリを、BSD 許可証の下でオープン化した。 それは、Google の BigTable プロジェクトに属する、Jeff Dean と Sanjay Ghemawat により作られたものである。そして、Unix ベースのシステムおよび、Mac OS X、Windows、Android で利用できる。

Although it first appeared in Google Code months ago, a blog post from Google earlier this week made the project more widely known.

それは、数カ月前に Google Code に登場したが、今週(7/30)に Google がブログにポストしたことで、プロジェクトの存在が広く知れわたった。

imageLevelDB is not a database server like other other key-value stores like Redis or Membase. Instead, it would most likely be used as an embedded database for other applications, much the way SQLite or Berkley DB are used. The technical advantage to using LevelDB instead of other key-value stores is its support for ordered data. Also, its BSD license is more liberal than the GPL Sleepycat license of Berkley DB.

LevelDB は、Redis や Membase といった、key-value ストアのデータベース・サーバーではない。それは、他のアプリケーションにエンベッドされるデータベースとして、使用される見込みが高い。つまり、SQLite やBerkley DB の用法に近いものとなる。他の key-value ストアに換えて、LevelDB を利用する際のテクニカルなアドバンテージは、ソートされたデータのサポートとなる。それに加えて、BSD ライセンスは、Berkley DB に適用される Sleepycat ライセンスよりも自由度が高い。

According to the announcement:

以下は、アナウンスメントからの抜粋である:

For example, LevelDB may be used by a web browser to store a cache of recently accessed web pages, or by an operating system to store the list of installed packages and package dependencies, or by an application to store user preference settings. We designed LevelDB to also be useful as a building block for higher-level storage systems. Upcoming versions of the Chrome browser include an implementation of the IndexedDB HTML5 API that is built on top of LevelDB. Google’s Bigtable manages millions of tablets where the contents of a particular tablet are represented by a precursor to LevelDB.

たとえば LevelDB は、最近にアクセスされた Web ページをキャッシュする Web ブラウザにより、あるいは、インストール済みのパッケージや依存性をリストする OS により、そして、ユーザー・プリファレンスをストアするアプリケーションなどにより利用されるだろう。さらに、私たちは、ハイ・レベルなストレージ・システムのための、有益なビルディング・ブロックとして、LevelDB をデザインしてきた。 これから登場してくる、将来の Chrome ブラウザ・バージョンは、この LevelDB 上に構築され、IndexedDB HTML5 API の実装を取り込むことになる。 Google の Bigtable は、何百万というタブレットを管理するが、その場所において、特定タブレットのコンテンツが前処理されることで、LevelDB へ向けて表示されていく。

LevelDB isn’t limited to just being used as an embedded database, however. Basho is already exploring the possibility of using LevelDB with Riak as an alternative to Bitcask or InnoDB. The company conducted some benchmarks, which you can find in this blog post.

しかし、 LevelDB の用途は、エンベッドされたデータベースだけに限定されるものではない。 すでに Basho は、Bitcask や InnoDB に代わる選択肢として、LevelDB と Riak を組み合わせて利用する、可能性について研究している。 そして、いくつかのベンチマークが行われたが、その結果を、このブログ・ポストで確認することが可能だ。

Google also released its own set of benchmarks here.

さらに Google は、それらのベンチマークで用いたセットを、ココ で公表している。

According to the project site the key features are:

  • Keys and values are arbitrary byte arrays.
  • Data is stored sorted by key.
  • Callers can provide a custom comparison function to override the sort order.
  • The basic operations are Put(key,value), Get(key), Delete(key).
  • Multiple changes can be made in one atomic batch.
  • Users can create a transient snapshot to get a consistent view of data.
  • Forward and backward iteration is supported over the data.
  • Data is automatically compressed using the Snappy compression library.
  • External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions.
  • Detailed documentation about how to use the library is included with the source code.

And the limitations are:

  • This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes.
  • Only a single process (possibly multi-threaded) can access a particular database at a time.
  • There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library.

See Also

ーーーーー

NoSQL も、まずは利用シナリオありきで、考えられるようになってきなのですね。IndexedDB HTML5 API って、どれほどのパーフォーマンスを見せてくれるのでしょう。 :) とても楽しみですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

NoSQL Database で 認識しておくべき 9つのポイント
NoSQL のユースケースを一般論と具体論で整理する
NoSQL の CouchDB が Android に搭載されるという話
Big Data を 美味しくいただくための、クッキング・ブックを作ろう
http://www.quora.com/LevelDB

GW プチ特集 – Facebook の 2011年 1月~4月

Posted in Facebook by Agile Cat on May 8, 2011

勢いは、一向に止まることなく ・・・

facebook_logo

それにしても、この 4ヶ月間に、よくもまぁ、これだけの話題を提供してくれるものだと、もう、何を聞いても驚かなくなってきたというのが、Facebook に対する正直な感想です。 しかし、Oregon に作ったデータセンターの仕様を、すべて公開してオープンソースにしてしまうという大胆な発想には、もう驚かないと言っても驚いてしまう Agile_Cat でして、そんな方も多いのではないかと思っています。 ーーー __AC Stamp 2

ーーーーー

December 30 : 2010 年の ビジター数(全米)で、Facebook が Google を追い抜く!

January 2 : Facebook が、もとの Sun Microsystems キャンパスに引越し?

January 3 : 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理!

January 10 : Facebook が 3月15日で終了する、というウワサで大騒ぎの全米

January 13 : FB.com ドメインを、7億円で購入する Facebook

February 6 : Facebook と YouTube に注がれる、私たちの大切な時間

February 8 : Facebook の 2004 – 2010 を、タイムラインで振り返る

February 12 : Web メールの時代は 終わってしまうのか?

February 13 : エジプトで戦った Google の Wael Ghonim が Zuck にお礼を

February 20 : Facebook が 攻めきれない国々をリストアップする

February 22 : 革命に湧くエジプトでは、赤ちゃんに Facebook と名付ける?

February 22 : Facebook 関連の クラウド API を調べたら 21 個が見つかった

February 27 : Facebook Likes で、Eminem が Lady Gaga を抜いてトップヘ

March 2 : Facebook が、グループ・メッセージングの Beluga を買収

March 8 : Facebook が目指す、リアルタイム分析のインフラとは?

April 6 : MySpace を殺したのは Microsoft スタックなのか? それは違うだろう。

April 8 : Facebook – Oregon データセンターの写真が一挙公開!

April 8 : Facebook – 対訳 – Efficient Data Centers with the Open Compute Project

April 11 : Facebook と Zuck が、Obama 大統領のライブ・イベントをホストする

April 12 : Facebook Phone – INQ Cloud Touch を GIGAOM が初レビュー

April 17 : Twitter と Facebook の、人間関係すったもんだ

April 21 : Facebook の Sergy Brin アカウントは 本物なのか?

May 4 : Agile_Cat 空撮隊 – Facebook Oregon データセンターを探索するも ・・・

May 5 : 詳細な解説つきの Facebook Oregon DC フォト・ツアー

May 7 : Agile_Cat 探偵団 – Twitter と Facebook からの参照数を比較する

ーーーーー

さて、これから夏へかけて、そして、秋から冬にかけて、いったい何を見せてくれるのかと、とっても楽しみな Facebook ですね! ーーー __AC Stamp 2

ーーーーー

<関連>

Facebook 2010 総集編 Agile_Cat 版

 

Netflix の API は、200 億リクエスト/月 を処理する

Posted in Amazon, API, Entertainment, Netflix by Agile Cat on March 31, 2011

Netflix API Now Serving 20+ Billion Requests Per Month
Romin Irani, March 29th, 2011
http://blog.programmableweb.com/2011/03/29/netflix-api-now-serving-20-billion-requests-per-month/

_ ProgrammableWeb

Netflix continues to see tremendous growth in its Netflix API. The API which saw humble beginnings in 2008 has taken a giant leap in usage, ever since Netflix started streaming functionality to devices. In what could be one of the largest usages of a public API, the current number of requests for its API is around 20 billion per month and increasing by the day, forcing Netflix to look at measures to decrease them.

Netflix の API が、ものすごい勢いて成長し続けている。 Netflix のストリーミング機能が、2008 年から各種のデバイス向けに提供され始めた時から、この API も継続して提供されているが、最近になって、その使用量が大幅に拡大している。最も多く利用されるパブリック API の1つとして、Netflix のAPI の現時点におけるリクエスト数は 20 billion / month 前後に達し、また、さらに増加している。そのため、この API の使用を低減させるための処理を、Netflix は強いられるような状況にある。

at1042In December, we covered how Netflix was able to scale significantly by moving its API and other services over to Amazon Web Services (AWS). In an interesting blog post, Director of Engineering Daniel Jacobson has given the API numbers and laid out plans on how they are going to tackle this deluge of API usage.

この API と各種のサービスを Amazon Web Services(AWS)に移行することで、Netflix はスケールを大幅に拡大したと、私たちは 12月の記事でカバーしている。また、同社の Director of Engineering である Daniel Jacobson は、その興味深いプログ・ポストにおいて API を説明し、さらには、この API 使用の大洪水への、取り組みついて計画を述べた。

netflix-api-request-growth

Just look at the numbers. A 37x growth in 13 months, 20+ billion API requests in January of this year and the number may even be higher by now. One way to look at these numbers would be continuously boost your infrastructure requirements to anticipate higher load/usage. Netflix, however, wants to get to the root of the issue and as highlighted in the blog entry, its has set two clear goals for its API redesign after seeing these numbers:

まずは、一連の数値に注目して欲しい。 13ヶ月で 37倍に増大し、また、今年の 1月には 20+ billion 以上のAPI リクエストが発生し、その量は今後も伸び続けると予測される。 一般的に、このような傾向の値は、さらなる利用量と負荷の増大をもたらすため、インフラストラクチャの要件を連続的に引き上げていく。 しかし Netflix は、そのブログ・ポストで強調したように、問題の今回に着手することを望み、各種の値を計測した後に、API デザイン変更における 2つの目標を明確にした:

  • Decrease the total number of requests
  • Decrease the payload

It is good to see this discussion in the open. Netflix acknowledges that the number of resources that are being served via its REST API is too many (around 20) and with overlapping needs, it results in several series of calls from the device to its API before all the information is obtained. Hence, the need to look at these resources closely and design them in such a way that with minimum number of requests, the device gets what it needs. The flip side to reducing the number of requests would be that the payload may start getting bigger. To address this, Netflix is looking at approaches like partial response and even providing a SQL-like variability for their database, so that devices get what they need.

こうした状況が、オープンに語られるのは、きわめて好ましいことである。 Netflix は、REST API がサポートするリソース数(およそ20)が、あまりに多く、また、重複が要求されることを認めている。そして、すべての情報をユーザーが得るまでに、デバイスから API へ向けた、いくつかの連続するコールが生じていた。 したがって、デバイスが必要とするデータを、最小のリクエスト数で得られるようにするための、リソースの再設計が要件となった。 リクエスト数を削減する反作用として、データ本体の量が肥大し始めるかも知れない。 それに取り組むために、Netflix はパーシャル・レスポンス的なアプローチに注目した。 そして、さらに、SQL のような変化性(variability)を、自身のデータベースに を提供することで、必要とするデータをデバイスが得られるようにした。

Netflix is one of the best case studies of how APIs are becoming the cornerstone around which engineering makes its plans. It comes as no surprise that heavy usage of an API presents its own challenge in making sure that infrastructure and API design will be able to cater to unpredictable load in the future. Sometimes it pays to think about the basics like Netflix has done to look at reducing the number of requests and even payload size.

Netflix は、ベストなケース・スタディの1つである。つまり、エンジニアリングの観点からの計画を、API を基礎として取り入れる方式を示している。 この インフラストラクチャと API のデザインは、将来における予測不能な負荷に、対応できるのだろうか。しかし、API 利用への大きな依存により、新しい課題が生ずるという考え方は、驚きには値しない。 Netflix が実現したように、リクエスト数とデータ量の削減という、きわめて基本的な事柄について、時には再考すべきである。

Image Credits : The Netflix Tech Blog

 

 

ーーーーー

以前に、 Real World NoSQL シリーズで Netflix を紹介したときにも、ずいぶんとオープンな会社だと思いましたが、API の考え方についても情報を提供してくれるとは、とても有難いことですね! Google の MapReduce 論文や、Facebook による OSS コミットの辺りから活発になってきた、エコシステム作りが実を結び、あらゆるプロバイダーがスケールアウトを実現していくための、きわめて有用な基盤が確立してきていることが、ほんとうによく理解できる事例だと思います。 ーーー __AC Stamp 2

ーーーーー

<関連>
Real World NoSQL シリーズ – Netflix における Amazon SimpleDB
NoSQL のユースケースを一般論と具体論で整理する
NoSQL Database で 認識しておくべき 9つのポイント
Big Data を 美味しくいただくための、クッキング・ブックを作ろう

Tagged with: , , , ,

Facebook が目指す、リアルタイム分析のインフラとは?

Posted in Facebook, NoSQL by Agile Cat on March 8, 2011

How Facebook Is Powering Real-Time Analytics
By
Derrick Harris Mar. 4, 2011, 9:21am PT
http://gigaom.com/cloud/how-facebook-is-powering-real-time-analytics/

_ Gigaom

Facebook is working on a real-time analytics dashboard that will let users determine which content on their pages is getting the most attention from visitors. As described in an educational session on Wednesday night in Facebook’s Seattle office, the service, which tracks both impressions and actions  for plugins and newsfeeds, should be valuable to companies seeking to maximize the effectiveness of the marketing efforts on the popular social media site. However, the highlight of the session was the infrastructure underlying the forthcoming service.

Facebook が取り組んでる、リアルタイム分析ダッシュボードとは、ユーザーのページ上のコンテントの中で、何がビジターの注意を引き付けているのを、判断させるためのものである。 Facebook の Seattle オフィスで、水曜日(3/2)の夜に開催されたエデュケーション・セッションで説明されたように、 プラグインとニュースフィードに関する Impression と Action を追跡するサービスは、この人気ソーシャル・メディア・サイトにおける、マーケティング戦略の有効性を最大にしようとする企業にとって、貴重なものになるはずだ。 ただし、このセッションのハイライトは、この新しいサービスの基礎となる、インフラストラクチャに関するものであった。

image

クリックで動画ページへ ⇒

The session video gives plenty of details, but here are some highlights. The analytics service tracks about 100 different metrics; is built atop HBase, with support from two Facebook-developed tools called pTail and Puma; and it aims for less than 30 seconds of lag time, a goal it has met a majority of the time during testing. It’s interesting that Facebook is becoming such a big user of the Hadoop-based HBase database, but the company line thus far is that the Cassandra NoSQL database it developed a few years ago just can’t hang with HBase when it comes to reliability and performance. HBase also underpins Facebook’s recently launched “social inbox” feature.

このセッション・ビデオでは、たくさんの詳細情報が提供されるが、いくつかのハイライトも含まれている。この、分析サービスは、およそ 100種類の基準を追跡する。そして、Facebook が開発した pTail とPuma という、2つのツールによりサポートされ、また、HBase 上に構築される。さらに、タイム。ラグに関しては 30秒以内という目標をたて、タイム・テストの大半において、そのレベルが達成されているという。 Facebook が、Hadoop ベースの HBase データベースにおける、ビッグ・ユーザーになることは興味深い。しかし、これまでのところ、同社の方針は数年前に開発した Cassandra NoSQL データベースであり、信頼性と性能の話になると、 簡単に HBase へ移行できないとのことである。 HBase に関しては、最近に Facebook が立ち上げた、“social inbox” 機能を下から支えている。

ーーーーー

この分析というのは、Facebook Page(以前の Fan Page)に関するもので、現時点では、だいたい 2日~3日遅れで更新されているという感じです。 詳しい内容については、大元さんのブログをご参照ください。 とても丁寧に説明してくださっています。 ーーー __AC Stamp 2

ーーーーー

<関連>
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook、Twitter、Digg などでの Cassandra の状況について
Facebook の Social Inbox は、単なる Email ではない!
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!

%d bloggers like this: