Agile Cat — in the cloud

API により拡大する、サービスの可能性 と 新たなリスクとは?

Posted in .Selected, API, Social, Strategy by Agile Cat on November 22, 2013

What APIs Are And Why They’re Important

Brian Proffitt – September 19, 2013

_ Read Write (2)

APIs make the modern Web what it is today. Here’s a simple guide to what they are, how they work and why we care.

API により、いまふうの Web がもたらされている。 以下に、それが、何ものであり、どのように動作し、また、取り扱われるべきかを示していく。


It’s getting harder to turn around in tech without bumping into some reference to APIs, or application programming interfaces. Here at ReadWrite, for instance, we’ve recently discussed Google’s flip-flops on the open Calendar API and why Pinterest hasn’t made its APIs public yet. I’ve even put forth the notion of getting my own API.

最近のトレンドだが、いくつかの API 参照に突き当たることなく、テクノロジーを上手い方向へ転換させることが難しくなってきている。 何の話かと言えば、そう、Application Programming Interfaces のことである。実際のところ、最近の ReasWrite では、Google がオープンな Calendar API に大転換した理由と、Pinterest  が未だに API を公開しない理由が、ちょっとした議論を呼んでいる。 そして、私も、自身の API を取得するという概念を打ち出している。

If you work with APIs, you already know why they’re important. But the rest of you may well be wondering: What are APIs, and why do we care so much about them?

あなたの仕事で、API が用いられているなら、その重要性について、すでに認識しているだろう。しかし、あなたの心の中には、その意味と、それに強くこだわる理由について、若干の疑念が残されているだろう。

This is your story.


APIs: Windows To The Code

In the simplest terms, APIs are sets of requirements that govern how one application can talk to another. APIs aren’t at all new; whenever you use a desktop or laptop, APIs are what make it possible to move information between programs—for instance, by cutting and pasting a snippet of a LibreOffice document into an Excel spreadsheet. System-level APIs makes it possible for applications like LibreOffice to run on top of an OS like Windows in the first place.

簡単に言えば、API とは、なんらかのアプリケーションが、他と会話するための方法を管理する、要件のセットのことである。だからと言って、API は まったく新しいもというわけではない。あなたが、デスクトップやラップトップを使用するとき、API が機能することで、プログラム間で情報を移動できるのだ。具体的に言うと、LibreOffice でドキュメントの一部をカットし、Excel のスプレッドシートにペーストすることなどが、それにあたる。また、System レベルの API は、Windows のような OS の上で、LibreOffice などのアプリケーションを走るようにしてくれる。 そもそも、それが、API の始まりである。

On the Web, APIs make it possible for big services like Google Maps or Facebook to let other apps "piggyback" on their offerings. Think about the way Yelp, for instance, displays nearby restaurants on a Google Map in its app, or the way some video games now let players chat, post high scores and invite friends to play via Facebook, right there in the middle of a game.

その一方で、Web における API は、Google Maps や Facebook といった大掛かりなサービスと、自社製アプリの組み合わせを実現してくれる。例として、Yelp の方式について考えてみる。まず、そのアプリ内に取り込んだ Google Maps で、近くにあるレストランを表示できる。また、ビデオゲームで遊んでいる最中のプレイヤーたちに、Facebook を介して、チャットを提供し、ハイスコアのポストや、ゲームへの招待などにも対応していく。

APIs do all this by "exposing" some of a program’s internal functions to the outside world in a limited fashion. That makes it possible for applications to share data and take actions on one another’s behalf without requiring developers to share all of their software’s code. Code-sharing on that scale wouldn’t just ruffle the feathers of programmers who’d rather keep it secret; it would also be grossly inefficient.

API は、プログラム内の機能の一部を、限られた方式で外の世界へエクスポーズすることで、そのすべてを実現していく。 それにより、2つのアプリケーション間でデータが共有され、双方のアクションが互いに代行されるようになるが、そのソフトウェアにおける全コードの共有が、開発者に求められることはない。そのスケールにおけるコードの共有は、それを秘密にしておきたいプログラマーの、心の中を波立たせるものにはならないだろう。 つまり、心配するほどの、秘密の開示には至らないのだ。

That’s true even for open-source programs. Who has the time to comb through all the code for somebody else’s application—which, trust me, can be awfully messy—just to use one function? (It’s also possible to run into tricky licensing issues if you’re not careful.)

それは、オープンソース・プログラムとして考えても、とても意味のあることだ。たった 1つの機能を使用するために、他人のアプリケーションにおける、すべてのコードの枝葉までしらべるなんていう(私を信じてくれるなら、その行為が、ひどく厄介なことも信じて欲しい)、暇人がいると思うだろうか? (そこまで考慮できないなら、トリッキーなライセンスを発行することも可能である)

APIs simplify all that by limiting outside program access to a specific set of features—often enough, requests for data of one sort or another. Feel free to think of them as doors, windows or levers if you like. Whatever the metaphor, APIs clearly define exactly how a program will interact with the rest of the software world—saving time, resources and potentially nasty legal entanglements along the way.

API により簡素化されるのは、特定の機能のセットに対して、制約された外部プログラムからのアクセスで実現される、すべての事柄である。 つまり、大半のケースでは、何らかのデータに対するリクエストで、事足りてしまう。 それが気に入るなら、ドアとでも、窓とでも、レバーとでも、自由に捉えることができる。どのようなメタファーを用いるにしても、ソフトウェアの世界で手の届かなかった領域を、API が正確かつ明確に定義すると言える。そして、これから先も、時間とリソースを節約し、厄介な法的問題を回避していくだろう。

How APIs Work

These days, APIs are especially important because they dictate how developers can create new apps that tap into big Web services—social networks like Facebook or Pinterest, for instance, or utilities like Google Maps or Dropbox. The developer of a game app, for instance, can use the Dropbox API to let users store their saved games in the Dropbox cloud instead of working out some other cloud-storage option from scratch.

このところ、とりわけ API が重要になってきているのは、大規模な Web サービスを活用する、新しいアプリケーションを開発する手法を、API 自身が決定するようになっているからである。実際のところ、Facebook や Pinterest のようなネットワークを、そして、Google Maps や Dropbox のようなユーティリティを、活用するケースなどが挙げられる。また、ゲーム・アプリの開発者も、同じような判断を下している。 たとえば、ユーザーがゲームの結果を保存するクラウド·ストレージであるが、それをスクラッチで開発するのではなく、Dropbox API を用いて、Dropbox クラウドに保存させるようにしている。

In one sense, then, APIs are great time savers. They also offer user convenience in many cases; Facebook users undoubtedly appreciate the ability to sign into many apps and Web sites using their Facebook ID—a feature that relies upon Facebook APIs to work.

ある意味において、API により、素晴らしいかたちで時間が節約される。そして、API は多くの場合において、ユーザーに利便性を提供する。 たとえば、Facebook ユーザーであれば間違いなく、数多くのアプリや Web サイトに、Facebook ID を用いてサインインできることを高く評価しているはずだ。 もちろん、これも、Facebook-ID に依存するものである。

Viewed more broadly, though, APIs make possible a sprawling array of Web-service "mashups," in which developers use mix and match APIs from the likes of Google or Facebook or Twitter to create entirely new apps and services. In many ways, the widespread availability of APIs for major services is what’s made the modern Web experience possible.

しかし、もう少し俯瞰してみると、不規則に広がった Web サービスの群れが、API により Mashup されている状況が理解できるだろう。開発者たちは、完全に新しいアプリケーションやサービスを作成するために、Google や Facebook やTwitter といった同類から得られる、異なるものを組み合わせるために API を使用しているのである。多くの点において、主要なサービスにおける API の、広範囲におよぶ可用性こそが、現代的な Web エクスペリエンスを実現しているのだ。

When you search for nearby restaurants in the Yelp app for Android, for instance, it will plot their locations on Google Maps instead of creating its own maps. Via the Google Maps API, the Yelp app passes the information it wants plotted—restaurant addresses, say, along with the Yelp star rating and more—to an internal Google Maps function that then returns a Map object with restaurant pins in it at the proper locations. Which Yelp can then display inside its app. (On iOS, Yelp taps Apple’s Maps API for the same purpose.)

さらに言えば、Android 用の Yelp のアプリで近くのレストランを検索するとき、そこでは独自マップが作成されることもなく、探している場所が Google Maps に表示されると気づくだろう。つまり、Google Maps の背後に置かれた機能が、そのレストランの場所をつなぎ合わせ、Map オブジェクト上に正確にピン止めしているのだ。そして、Yelp は、自身のアプリの中に、その Map オブジェクトを表示する ( iOS 用の Yelp は、同じ目的のために、Apple の Maps API を叩いている)。

We see APIs like this all the time. Elsewhere on this page you should see the icons to share this article on Facebook, Google+, Twitter, LinkedIn or Reddit. These are just links that call on the APIs associated with each of those services to allow users to Tweet or post about an article without leaving the site itself. APIs also allow our comment system, run by a service called Disqus, to accept user comments and then display them right here on ReadWrite without our intervention.

このように、いつも私たちは、API を参照している。たとえば、この記事を共有するための、Facebook や、Google+、Twitter、LinkedIn、Reddit などのアイコンを、ページのどこかで確認できるはずだ。つまり、このサイトから離れることなく、この記事に関するツイートやポストを実現するために、リンクから API を経由して、それらのサービスを呼び出しているのだ。さらに、API から Disqus というサービスを呼び出すことで、私たちのコメント・システムが動き出す。それは、ユーザーのコメントを受け付けた後に、私たちの仲介を必要とすること無く、あなたのコメントを ReadWrite のページに表示する。

When APIs Go Bad

Of course, just because an API is available now, that doesn’t mean it always will be. Twitter, for instance, notoriously limited third-party applications’ use of its APIs just over a year ago—a move that had the practical effect of killing off alternative Twitter clients and driving users to Twitter’s own site and apps, where Twitter can "monetize" them by displaying ads … er, promoted tweets. Twitter insisted the move was necessary to deliver a "unified" Twitter experience.

もちろん、いまでは API が利用できるようなったという理由だけでは、これからも常に存在し続けると捉えることができない。たとえば、Twitter を例にすると、サードパーティ・アプリからの API 使用に制限をかけるという、ひどいことを 1年ほど前に行っなっている。そして、他の Twitter クライアントを殺し、Twitter 自身のサイトとアプリに、ユーザーを誘導するという、具体的な効果をもたらすことになった。それらの場所は、広告やプロモーションのつぶやきにより、Twitter がマネタイズを図るためのものであったのだ。しかし、Twitter の主張はというと、統一された Twitter エクスペリエンスを提供するために、必要な措置であったとなる。

Other examples abound. Companies can shut down services and APIs that your applications depend on—or they can go out of business entirely, as Memolane and Everyblock did last February. And let’s not get started on all of the services that Google regularly shuts down when it doesn’t see any profit in them—like Google Health or more recently, Google Reader. These kinds of service shutdowns can leave you in a lurch if your application depends on those APIs to function.

他にも、たくさんの例がある。 あなたのアプリが依存している サービス や API が、それらを提供している企業により、シャットダウンされてしまうという事態も起こり得るのだ。 昨年 2月の、Memolane Everyblock のケースが、それに当てはまるだろう。また、Google も、たとえば HealthReader のような、利益をもたらさないものを、定期的に廃止していくので、すべてのサービスを使い始めるべきだとも言えない。この種のサービス停止が生じると、それらの API と機能に依存しているアプリが、置き去りにされてしまう。

There’s still more than a hint of the Wild West in today’s API landscape. But none of these complications seem likely to dampen developer enthusiasm for APIs, nor that of users for the incredible variety of apps and services they make possible.

今日の API を取り巻く風景の中には、フロンティアのためのヒント以上のものが潜んでいる。しかし、これらの、合併症とも言える出来事が、API へ向けた開発者の熱意に水を差すとも思えず、また、それが可能にする、素晴らしいアプリやサービスが、消えていくこともないだろう。

See also: The New API Gold Rush


TAG indexAgile_Cat の日常において、どにように API が機能しているのかというと、まず、WordPress とソーシャル・メディアの連携が挙げられます。 このコンテントも、ポストされた瞬間に、2つのサービスを連携する API が動き出し、Twitter 側に新規のポストを示すリンク情報が流れていきます。 また、最近のお気に入りである、Business Insider や Mashable などの Android アプリからは、2タップするだけで、Evernote に Web クリップを取り込むことが可能です。 まぁ、一言でいって、毎日が API 漬けなのですが、それは、みなさんも一緒のはずです。依存するだけではなく、代替の手段を常に考えておくことも、API の時代には必要なのかもしれませんね。image



Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
BaaS で自由になる? それとも便利になる? そして DoCoMo の i-Concier は?
Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!
Facebook が Open Graph API を遮断 : 外れてしまった Yandex の狙い
NY の地下鉄では、スマホ・チケットの試みが始まるらしい

Android デベロッパーに朗報 : Analytics 機能により Google Play 内でのトラッキングを実現

Posted in .Selected, DevOps, Google, Mobile, Post-PC by Agile Cat on October 16, 2013

Google Developers Finally Get Analytics In Their App-Building Console

Dan Rowinski – October 04, 2013

_ Read Write (2)

Google just took another step in its mission to give Android developers better tools to analyze and monetize their apps.

Google は Android デベロッパーに対して、そのアプリを効率よく分析しマネタイズしていくためのツールを提供するという、新たなミッションへ向けて第一歩を踏み出した。

Google makes good on its promise at the I/O developers conference in May.

The company has officially announced that it has integrated Google Analytics into its Google Play Developer Console for Android developers. Google had said that Analytics was coming to the Developer Console at its I/O conference in May this year.

同社のオフィシャル・アナウンスメントによると、Google Play Developer Console に Google Analytics が統合され、Android デベロッパーの便宜が図られるようになる。Google は Analytics について、今年 5月の I/O カンファレンスで、Developer Console に取り込まれていたと発言している。

Android developers can now download the Google Analytics software developer kit (SDK) and place it into an app and upload it to the Google Play Store. The Analytics SDK is also available for iOS apps.

Android デベロッパーは、Google Analytics SDK をダウンロードし、それをアプリに埋め込み、Google Play にアップロードできるようになっている。また、この Analytics SDK は、iOS アプリにも対応できるという。

Google Analytics for the Developer Console has four main aspects:

Google の Analytics for the Developer Console は、以下の 4つの狙いを持つ:

クリックで拡大 ⇒

Google Play Referral Flow: Helps developers figure out where Google Play traffic is coming from (search, marketing campaigns, blogs or media articles etc.). This feature helps marketers figure out how successful their campaigns are and where the best traffic comes from.

Google Play Referral Flow: デベロッパーが、Google Play トラフィックの導線(サーチ/キャンペーン/ブログなど)を理解できるようにする。この機能により、マーケティング担当者は、最適なトラフィックが発生する場所を特定し、キャンペーンを成功へと導いていく。

Views in Google Play: Referral Flow shows how many people have viewed the app in Google Play.

Views in Google Play: 前述の Referral Flow により、どれだけの人々が対象アプリを参照したのかを、Google Play 内で把握できるようになる。

Installs: Once figuring out where the traffic came from through the Referral Flow, Analytics tracks users that actually clicked and downloaded the app through Google Play.

Installs: Referral Flow を介して、トラフィックが生じる場所が把握できると、Google Play でアプリをクリックし、ダウンロードしたユーザーを、Analytics が追跡することになる。

New Users: Goes beyond the straight download numbers to show people that have opened the app and begun to use it and become “Active Users.”

New Users: 単なるダウンロード数ではなく、実際にアプリをオープンして、使い始めている Active Users 数をを表示する。

クリックで拡大 ⇒

The goal for Google is to show not just the raw number of views and downloads, but also how much people have engaged with the app and what version of Android they are using. With the Analytics SDK, developers can know what Android API Level their users are employing. This is beneficial information for developers that need to know how many people are using older versions of Android, such as versions 2.3.7 Gingerbread that may not have certain capabilities that are in newer versions of the operating system.

Google のゴールは、単なる参照とダウンロードの数だけでなく、どのくらいの人々が対象アプリにつなぎとめられ、また、どの Android バージョンが使用されているのかを示すことにある。Analytics SDK を用いることで、ユーザーが利用している Android API Level を、デベロッパーは知ることが可能だ。 つまり、どれだけの人々が、たとえばバージョン 2.3.7 Gingerbread のような、古い Android バージョンを使用していのかを、知る必要のあるデベロッパーにとって、とても有益な情報となる。なぜなら、このオペレーティング・システムの、最新バージョンにおける特定の機能を、旧バージョンはサポートしていない可能性があるからだ。

Google employs “flow visualization” in Analytics to show how a user got to the app and what actions they took within the app.

Google は、Analytics において “flow visualization” を採用し、そのアプリをユーザーが取得する方式や、そのアプリで使用されるアクションなどを示すようにしている。


image28この 8月にポストした『 Google I/O 2013 の約束 : すべて 順調! PHP もバッチリだ! 』という抄訳では、この Android デベロッパー・サポートに触れられていませんでした。 しかし、さすがは Google 先生、やることが理に適っていて、とても感心してしまいます。言われてみれば、当たり前のことなのですが、この記事を読むまで、アップ・ストアのトラッキング結果がデベロッパーにフォードバックされる世界など、思いもつかなかったことです。 これは、とてもカッコ良いですね!image



Developer の調査: いまふう デベロッパー の 特質とは?
Kinvey の Mobile BaaS と、Red Hat の PaaS が統合される!
OpenStack エンジニアに対する、求人の高まりを示すチャートとは?
Google App Engine が PHP をサポートする: 75% の Web をカバーしているから

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?’

David Cohen on June 25、2013

_ 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

Amazon AWS には、リージョン間で 200倍もの速度差があるって?

Posted in .Selected, Amazon, Network by Agile Cat on June 12, 2013

Amazon Web Services speeds can vary by up to 200X depending on region

June 3, 2013 –
John Koetsier

_ VB Cloud

Australia is slow, Singapore is fast, and Europe to Oregon is twice as fast as Europe to California.

Australia は遅くて、Singapore が速い、そして、Europe から Oregon は、Europe から California に対して、2倍の速度を持つ。

Increasingly, we rely on “the cloud” to deliver web services. But the cloud is not one amorphous thing, and the cloud is not all equal. As every developer knows, what we generically call the cloud reduces down, ultimately, to physical servers and wires. And even within one company’s cloud — such as Amazon — there are vast differences in speed and optimization from region to region.

私たちは、Web でのサービスを提供するために、クラウド への依存度を高めている。しかし、クラウドは不定形のものではなく、また、すべてに対して等しいものでもない。そして、すべての開発者が認識しているように、一般に提唱されているものは、何かクラウドにおいて低減されるのかという視点であり、最終的には物理的なサーバーとワイヤーにまで落としこまれるものとなる。 しかし、たとえば Amazon などの、1つの企業が提供するクラウドの内側であっても、そのスピードと最適化において、リージョンごとに大きな格差が生じている。

What that ultimately means is that developers who don’t pay attention to cloud regions, as server debugging company Takipi discovered, can actually cause their apps to run 10 or even 200 times slower than necessary.

サーバーをデバッグする Takipi が発見したところによると、クラウドのリージョンに注意を払わなくてもよいはずの開発者たちが、そうではない状況に置かれているという現実がある。つまり、前述の最終的という言い回しが示すように、自分たちのアプリが、想定の 10 倍速で実行されたり、反対に 200倍も遅くなってしまう状況にあるのだ。

And Amazon doesn’t disclose any of that data. “We noticed that in many cases there’s 10X (or even more) difference in the performance of services due to AWS/S3 regions and external APIs,” Takipi co-founder Iris Shoor told me via email.

そして Amazon は、この種のデータについて、なにも開示していない。Takipi の Co-Founder である Iris Shoor は、「 私たちが気づいたのは、多くの場合(または殆どの場合)において、AWS/S3 のリージョンごとに、また、外部接続 API ごとに、サービスにおける性能差が 10倍もあることだ」 と、電子メールを介して伝えてきた。

In fact, Amazon’s cloud performance could vary in speed from region to region by as much as 200 times.

実際に、Amazon クラウドの性能は、リージョンごとの速度差が 200倍 にも達する場合もある。

For example, upload times vary significantly within each region. Uploading a file in Virginia to Amazon’s U.S. East cloud region, also in Virginia, takes three time longer than uploading a file in Singapore to AWS in Singapore. But it’s moving files between regions to serve differing international clients that will cause the greatest slowdowns: Shifting a file from Amazon’s São Paulo Region in Brazil to its Sydney, Australia region takes 200 times longer than shifting files between geographically close regions like Amazon’s U.S .West (Oregon) and U.S. West (California).

アップロード時間を例にして、その顕著なケースをリージョンごとに比較してみよう。Amazon の U.S. East クラウド・リージョンにある Virginia に、(Virginia から)ファイルをアップロードすると、AWS の Singapore リージョンに、(Singapore から)ファイルをアップロードする場合よりも、3倍もの時間がかかってしまう。そして、インターナショナル・クライアントたちは、リージョン間でのファイルの移動において、大幅なスローダウンという問題に直面していく。つまり、Brazil にある  Amazon の São Paulo リージョンから、Australia の Sydney リージョンへとファイルを移動すると、たとえば Amazon U.S.West (Oregon) から、U.S.West (California) へと移行する時と比べて、なんと 200倍もの時間がかかってしまうのだ。

“It seems that the new region — Australia — is by far the slowest,” Shoor says. “Uploading files to Australia can cause 10X latency versus other regions.”

そして Shoor は、「 新しいリージョンだと思われる Australia が、きわめて遅い。 Australia へ向けたファイルのアップロードは、他のリージョンと比較して、10倍ものレイテンシーを引き起こすことがある」と述べている。

And that makes sense — Australia is an island continent served by a limited number of international connections, and the file has a lot longer to go. But it is something to keep in mind when building global services.

そして、Australia はインターナショナル接続数が限られた島国であり、それらのファイルは長距離を旅することになる。しかし、それが理に適っているとしても、グローバル・サービスを構築する際には、心に留めておくべき点となる。

And some of the latency issues aren’t easily explainable due to geographical isolation — they’re more likely side effects of Amazon Web services system design. For example, there’s a big difference between uploading a file from Amazon’s S3 servers in Ireland to the U.S. East Coast and transferring the same file from the same location to the U.S. West Coast. The West Coast, Takipi says, will take twice the time, despite the fact that it’s only 25 percent further.

ただし、いくつかのレイテンシに関する問題は、地理的な距離だけ、簡単に説明できるではない。そこには、Amazon Web Services における、システム・デザインの副作用もあるだろう。たとえば、Ireland にある Amazon S3 Server から、U.S. East Coast と U.S. West Coast へ向けて、ファイルをアップロードする際にも大きな違いが生じる。その距離が 25% だけ遠くなるという事実にもかかわらず、時間的には 2倍もかかると、Takipi は述べている。

Even worse, Europe to California takes twice the time of Europe to Oregon: “It’s possible to make amazing optimizations just by changing the region,” says Shoor. “For example, choosing Oregon over CA for a company that serves the European market will cut the upload time by half.”

さらに悪いことに、Europe から California へ向けた場合は、Europe から Oregon へ向けた場合の、2倍もの時間を必要とする。それに対して Shoor は、「 リージョンを変更することで、驚くほどの最適化を達成できるはずだ。たとえば、European 市場をターゲットとする企業の場合は、California に替えて Oregon 選択するだけで、アップロード時間を半分に短縮できる」と述べている。

One of the main problems when hunting down the cause of slow services, Takipi says, is API latency. And regionality has a huge impact there, even if you’re as geographically optimized as you can possibly be.

サービスのスローダウンにおいて、その原因を追求するための重要は視点は、API のレイテンシにあると、Takipi は述べている。そして、リージョンの選択において、それが地理的に最適化されている場合であっても、大きな劣化が生じる可能性がある。

For example, Shoor says, even if your app is optimized for Australia and you’re using Amazon cloud services in Australia, Facebook’s API is 11 times slower down under, on average, than it is elsewhere.

あなたのアプリが Australia に最適化されていて、Australia の Amazon クラウド・サービスを使っている場合であっても、Australia  から Facebook の API を使うと、他のリージョンと比較して、平均で 11倍以上も遅くなると、Shoor は言う。

To monitor those slowdowns, Takipi is currently building “Project Barkdog,” a service to inform developers of slow APIs globally. Barkdog will likely launch in a couple of weeks, and will inform developers via email or Twitter when APIs that they’re using are slowing down.

こうした速度の低下を監視するために、グローバルにおける API の状況を開発者に通知する Project Barkdog を、Takipi はサービスとして構築している。 おそらく、Barkdog は数週間後には立ち上がり、それぞれの開発者たちが使用している API の速度が低下したときに、Mail や Twitter を介して通知することになる。

“It’s possible to speed up performance significantly,” Shoor says. “Amazon doesn’t share any of this data.”

「 パフォーマンスが、大幅に改善される可能性はある。 しかし、Amazon は何もデータを共有しないだろう」と、Shoor は発言している。

Image credits: Takipi, Amazon iCloud by John Koetsier, Globe by WoodleyWonderWorks/Flickr


TAG index昨年の 2月に、『Amazon が安いのか? Hosting が安いのか? コスト分析モデルで比較する!』という抄訳をポストしましたが、そこではデータセンターからインターネットへのアウト・バウンド ・トラフィック量が、AWS を選択するかしないかの分岐点あると述べられていました。つまり、ネットワークをキャリアに依存する AWS の強みと弱みが、そこに集約されているのでしょう。 このポストも同様に、それを論点にしているように思えます。また、IDC によると、すべての IT ワークロードの、わずか 5% がクラウドに移行したに過ぎないようです。 それぞれのユーザーに最適化されたクラウド選びが、これからも、延々と繰り返されていくのでしょうね。__AC Stamp 2



Amazon AWS の年商は、どう見ても $ 1 billion を超えている
Microsoft が IaaS に進出 : ライバルは Amazon AWS だ!
なんと! 2013 Q1 のクラウド売上は $2B : 順位は AM>SF>MS>IBM>GO
空芯型ファイバーにより、光速の 99、7% に到達するテクノロジーとは?


iOS のエコシステムとは? Apple ビジネスの規模を推測し、そのポリシーを学ぶ

Posted in .Selected, Apple, BaaS, Mobile, Post-PC by Agile Cat on March 28, 2013

How big is the iOS app ecosystem?

January 30, 2013 by bwhalley


This is an excerpt of the first chapter of “How To Make An App: iOS Edition“, a new eBook released by Kinvey. If you’re interested in reading the entire eBook and developing iOS apps, you can get this eBook now and sign up for a Kinvey account for a free app backend.

この記事は、Kinvey が新たに発行した電子ブック  “How To Make An App: iOS Edition“ の第一章を抜粋したものである。 もし、この eBook 全体を読みたいなら、そして iOS アプリを開発したいなら、Kinvey が提供する フリー・アプリ・バックエンドのアカウントに Sign Up することで、無料で入手することが可能である。


It’s a story that never gets old. The weekend that iPad Minis and the fourth generation iPads went on sale (November 2-5, 2012) Apple sold over 3 million of the devices — a record for first-weekend iPad sales. Two months earlier the company had set another record: first weekend sales of over 5 million for the iPhone 5. Since the introduction of the first iPhone back in 2007, iOS-based devices (iPhone, iPad, iPad Mini and iPod Touch) continue to rewrite the definition of what constitutes a successful product. By the end of 2012 over 400 million iOS devices have been sold.

そこには、決して朽ちないストーリーがある。 iPad Mini と iPad 4th Gen は発売された週末(2012年11月2-5日)に、Apple は 300万台以上のデバイスを販売し、iPad 発売直後の Weekend 記録を塗り替えた。そして、その 2カ月前に同社は、もう 1つの Weekend 記録である、iPhone 5 発売直後の 500万台を達成している。 2007年に最初の iPhone が紹介されて以来、iOS ベースのデバイス(iPhone/iPad/iPad Mini/iPad Touch)は、プロダクトの成功要因の定義を、書き換え続けている。 そして、2012年末までに、iOS デバイスは、4億台以上も販売されている。

What makes iOS devices so successful? Innovation and product features are clearly a big part. Before the iPhone most people had not interacted with a multi-touch interface. They had never zoomed with a pinch or switched between portrait and landscape by merely rotating a device in their hand. Carrying a phone that knew where they were, could suggest places to eat, and could offer directions on how to get there was also a novel experience.

iOS デバイスを、そこまで、成功させるのは何なのか? イノベーションとプロダクトにおける特徴が、ハッキリとした大きな領域を占めている。 iPhone が登場する以前、大半の人々は、マルチ・タッチ・インタフェースとのインタラクションを経験していなかった。 つまり、スクリーンを摘んでズームさせたり、タテ・ヨコの表示を切り替えたりという経験は、ユーザーたちにとって初めての経験だったのである。 自分たちの居場所を教えてくれて、レストランまでの道順を示し、さらには、そこまで連れて行ってくれる電話器は、それまでには存在しない、新しいエクスペリエンスであった。

But features like multi-touch, accelerometers and GPS are only part of the appeal. Even with all its innovations, iOS still might not have taken off the way it has if the only people figuring out ways to use those innovations worked at Apple. Most of the capabilities available in an iPhone or iPad in fact don’t come from Apple at all. They come from legions of third-party developers who work in a vast ecosystem that is also an Apple innovation. That ecosystem includes the iPhone, iPad, iPad Mini, iPods, App Store, iTunes, ad networks — and that’s just on the consumer side. On the developer side, you have Xcode, App Loader, testing tools, iTunes Connect — the list goes on.

しかし、マルチ・タッチや、加速度センサー、そして GPS といった機能は、iOS デバイスをアピールする一部に過ぎない。 もし、それらのイノベーションの活用方法を、Apple の従業員だけが理解しているような状況だったら、iOS は依然として離陸していなかったかもしれない。 実際のところ、iPhone や iPad で利用できる大半の機能は、Apple 以外の企業から提供されている。 つまり、広範囲におよぶエコシステムに参加する、サードパーティー・デベロッパーの大群から、それらの機能が提供されること自体が、Apple におけるイノベーションでもあるのだ。 そのエコシステムには、iPhone/iPad/iPad Mini/iPod/App Store/iTunes/アド・ネットワークが含まれるが、それらは、ユーザーの目線から見えるものとなる。 そして、デベロッパー目線からだと、Xcode/App Loader/Testing Tool/iTunes  Connect などがリストアップされてくる。

As of September 2012, the App Store hosted over 700,000 apps that have collectively been downloaded over 30 billion times. Apple reported for October 2012 that App Store monthly revenues were running at $333 million — a rate of about $4 billion per year — remarkable for a store that only opened in July 2008.

2012年9月の時点において、App Store には 700,000種類以上のアプリがホストされており、そのダウンロード回数は、トータルで 300億回を超えている。 Apple の 2012年10月のレポートによると、App Store の月商は $333 million であり、年商に換算すると $4 billion になる。 2008年7月にオープンしたことを考えると、注目に値する売上額である。

Another innovation that has spurred iOS app development is “The Cloud.” Cloud services make it easier for independent developers to create, support and make money from their apps. The Cloud solves data storage and cross-device and user-to-user sharing problems. If an app stores data in the Cloud, that part of the application is call the “backend,” while the part of the app that runs on the phone and interacts with the user called the “front end.”

iOS アプリ開発に拍車をかけた、もう 1つのイノベーションが “The Cloud” である。 クラウドのサービスにより、それぞれの開発者たちは、アプリの開発/サポート/利益回収を、とても容易に行えるようになった。 このクラウドは、データ・ストレージとクロス・デバイスを提供し、また、ユーザー間で問題の共有という解決策も実現した。 もしアプリが、データを Cloud にストアするなら、そのパートは “Backend” と呼ばれる。その一方で、フォンの中で走り、ユーザーとインタラクトするパートは、“Frintend” と呼ばれる。

A cloud may be “private” — i.e., the services belong to an organization for the benefit of its employees and business partners. Or a cloud may be “public” — i.e., a company (such as Amazon or Kinvey) owns the services, which developers can then integrate into their own apps. If you are a developer and want to build your own backend, you certainly can do that. Whether you want to or not depends on whether your backend provides functionality common to many different apps.

あるクラウドは、Private になるかもしれない。そのサービスは組織に帰属し、その従業員とパートナーに利益をもたらす。 また、あるクラウドは、Public になるかもしれない。 そこでは、(Amazon や Kinvey のような)企業がサービスを所有し、デベロッパーたちのアプリと、それらのサービスが統合されていく。 したがって、デベロッパーたちが、自身の Backend を構築したいと望むなら、それも可能となる。 つまり、それらの Backend に依存する、依存しないは、多様なアプリで共有できる機能を、対象となる Backend が提供している、提供しないに、依存することになる。

If it does (as in a shopping cart or user authentication) then perhaps that time and money would be better spent on features that offer unique value to your customer. You may be better off hooking into a commercial backend provider via an API. Then you can focus on what counts most — a unique user experience and application-specific functionality. That brings us to the first step in making an app, which is to define your MVP and decide which features are most critical to your launch.

もし、それが実現されているなら(ショッピングカートやユーザー認証のように)、そこに費やされる時間と費用は、おそらく、あなたのユーザーに対して、ユニークな価値を提供するための、より妥当な使い道となるだろう。 つまり、API を介して、商用の Backend プロバイダーを引きこむほうが、あなたにとって有用な方式となるだろう。 続いて、あなたは、一番に大切にすべき、ユニークなユーザ・エクスペリエンスとアプリ固有の機能に、集中していけるようになる。 それにより、私たちも、アプリ開発における最初のステップを踏みだす。 つまり、あなたにとっての MVP を定義し、あなたのローンチにとって最も重要な機能を、判断していくことになる。


TAG indexすでに、Kinvey については ご紹介していると思いますが、Mobile BaaS のトップ・ランナーと言って差し支えない存在の、Boston ベースのスタート・アップです。もう、とにかく何でもつなげますから、アプリ・デベロッパーは先のことを考えながら、どんどんと進んで、じゃんじゃんと儲けてくださいというスタンスの企業とのことです。 その Kinvey が、How To Make An App: iOS Edition“ という電子ブックを発行しました。ご興味のある方は、ぜひ トライしてみてくださ~い!  image



IBM の Mobile ファースト宣言 : それは Cloud ファーストを意味する!
エンタープライズに必要なモバイル・セキュリティ : 6つの階層って知ってました?
AWS イベントでの Parse が スゴそう – BaaS の勢いが加速する?
Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ
Bloomberg 金融アップストアがオープン : Apple みたいに 30% をイタダキ!

Facebook が Open Graph API を遮断 : 外れてしまった Yandex の狙い

Posted in .Selected, API, Facebook, Open Graph, Social, Yandex by Agile Cat on March 27, 2013

Wonder No More. Yandex Pulls Social Discovery App After Facebook Closes Door On Graph API Use + Says It’s A Competing Search Engine
Ingrid Lunden – January 30th, 2013


Some closure on the story of how Yandex — the Russian search giant — built a social discovery app that relied on Facebook interconnection to gather data, and then found Facebook blocking its service within hours of launching.

ロシアのサーチ・ジャイアントである Yandex だが、これまでに開発してきた、ソーシャル・ディスカバリー・アプリの廃止に追い込まれている。それは、Facebook が集めるデータとの接続に依存するものだが、ローンチから数時後に、そのサービスを Facebook がブロックしていることが判明した。

Today Yandex said that after discussions with the social network, Facebook has finally, terminally said that the app violates its Platform Policies, specifically on the point of Wonder being a competing search engine. Facebook will not reinstate the ability to use Facebook’s Graph API, so as a result, Yandex is planning to pulll the app from the app store and put it on hold for now.

今日(1/30)のことだが、Yandex は、このソーシャル・ネットワークと議論した後に、Wonder が Platform Policies に違反し、さらには、競合するサーチ・エンジンになっているという、Facebook の発言を引用している。Facebook は、その Graph API を、Yandex に対してブロックし続けるだろう。 それを踏まえて、このアプリをアップ・ストアから引き下げ、保留にすることを、Yandex は計画している。

The full statement from Yandex:

以下は、Yandex からのフル・ステートメントである:

“We discussed the issue with Facebook and it was confirmed that Facebook views the application Wonder as something that violates the Facebook Platform Policies (section I.12) and that the access to Facebook’s Graph API will not be restored.

“According to Section I.12, no data obtained from Facebook can be used in any search engine or directory without the company’s written permission. The reason behind Facebook’s decision to revoke our access to their data appears to be that they do consider Wonder to be a search engine, while our understanding of what it is differs from this view.

“Wonder’s functioning, in its current state, as well as the quality of user experience it provides, largely depends on the access to Facebook’s Graph API. Since this access was revoked, we decided to put our application on hold for the time being. We will be considering partnership opportunities with other social networks and services to offer our users a richer internet experience via Wonder.”

この問題について、私たちは Facebook と議論した。そして Facebook が、この Wonder アプリに対して、Platform Policies(Section I.12)だと見なし、また、Graph API へのアクセスが復活しないことが確認された。

Section I.12 によると、Facebook から得られる、あらゆるデータは、同社による書面での許可を受けることなく、いかなるサーチ・エンジンおよびディレクトリで、利用することができないとされている。彼らのデータに対するアクセスが取り消された背景には、Facebook が Wonder を サーチ・エンジンであると認識しているのに対して、私たちは異なるものだと認識しているという、考え方の相違があると思われる。

現時点における Wonder の機能は、提供されるユーザー・エクスペリエンスの質的な向上であるが、それと並行して、Facebook の Graph API アクセスに大きく依存している。 そのアクセスが無効とされたことで、このアプリについては、保留にすると決定した。 したがって、私たちは、他のソーシャル・ネットワークおよびサービスとパートナーシップを構築し、Wonder を介したリッチなインターネット・エクスペリエンスを提供していくことになるだろう。

The emergence of Wonder, and a week before the blockage of Voxer, has kicked off a new level of scrutiny about how Facebook allows other apps to appropriate its data: in effect, the company has said that it is not sharing with apps that don’t share back, or that replicate core functionality without permission.

Wonder の出現と、その1週間前に起こった Voxer の出来事は、他のアプリケーションが Facebook のデータを利用する適切な方式という、新しいレベルにおける調査の始まりでもあった。 そして、その結果において同社は、共有した結果を戻さないアプリや、コアとなる機能を許可なく複製するアプリとは、共有していかないと発言している

The Wonder app, which was nearly a year in the making, was put together by Yandex Labs, which is based in Palo Alto, CA. I actually met the three leads on the project, Maxim Grinev, Maria Grineva and Sergey Fayfer, for the first time in person yesterday, as I’m in town for the week.

約 1年をかけて開発されてきた、この Wonder アプリは、Palo Alto, CA をベースとする、Yandex Labs によりまとめ上げられた。 昨日(1/29)のことだが、その街を訪れた私は、このプロジェクトの 3人のリーダーである、Maxim Grinev および、Maria Grineva、Sergey Fayfer と会ってきた。

They told me about how the idea germinated from their own move to the Bay Area a year ago, when they were trying to figure out what to do and where to go when they arrived, because, in their collective mind, there wasn’t a good enough social app out there to provide that kind of recommended viewpoint.

彼らは、何処へ行って何をすれば良いのかを 1年前に理解し、Bay Area に引っ越してきたことで、このアイデアが生じたと、話してくれた。なぜなら、この種のリコメンデーションの視点を、充分なかたちで提供するソーシャル・アプリは存在しないという認識が、彼らの中で共有されていたからである。

The app then went on to be built using a number of different features — including Nuance-powered voice recognition, API feeds from various other social networks like Foursquare, and new algorithms for how to digest and cancel out repetitive news in favor of more up to date information — but without the core dataset provided via Facebook’s Graph API, the carpet was effectively pulled from under Wonder.

そして、このアプリは、数多くの機能を用いることで構築されていった。そこに含まれるものとしては、Nuance がパワーを提供する音声認識や、Foursquare などのソーシャル・ネットワークフィードされる多様な API、そして、人々が好む最新情報を抜き出し、また、重複を排除していくための、新しいアルゴリズムなどが挙げられる。しかし、Facebook の Graph API たら提供される、コアとなるデータセットに依存することなく、そのカーペットを効果的に、 Wonder の足元まで持ってくることは不可能だ。

Considering that Facebook flat-out thinks of Wonder as a search engine, and one that competes against Facebook itself, makes one speculate about what else Facebook has planned for its own, new Graph Search feature in the future.

Facebook が率直に、Wonder をサーチ・エンジンとみなし、また、自身と競合するものと認識したことで、現時点で計画されている範囲を超えて、これからも新しい Graph Search 機能が登場してくると、推測することが可能になる。

And if there are more apps — or would-be apps in development — that might find themselves blocked in future, will we see companies begin to look for alternative solutions? Is there room for another social data aggregator like Facebook in the market?

そして、もし、それら以外のアプリが、また、これから開発されるアプリが、将来においてブロックされると認識されるなら、それらの企業は代替えのソリューションを探し始めるのだろうか? そして、このマーケットには、Facebook のような、別のソーシャル・データ・アグリゲータのための空間が存在するのだろうか?

Equally, it’s worth wondering whether we will see some of the smart technology that went into Wonder appearing elsewhere — something Yandex had already said it would consider even when it first launched its Wonder “experiment.” It was potentially a route for Yandex to build its profile and dataset for U.S. consumers, and English-language users, so it’s clear that these markets remain in the company’s sights.

それと同様に、Wonder が示したような領域へ、新たに飛び込んでいくスマートなテクノロジ-について、考える価値も生じていくる。 それは、Yandex が Wonder に「実験」を開始した当初から、すでに考えていたであろう、何かである。また、それは、アメリカのユーザーと、英語圏のユーザーのための、プロファイルとデータセットを構築するという、Yandex のための潜在的なルートでもあった。 したがって、このマーケットが、同社の視界の中に留まり続けることは明確である。


Company: Yandex
Launch Date: September 23, 1997

Yandex is an internet technologies company that operates in Russia, CIS and Turkey. It is the largest Russian and fifth-largest world internet search engine. Yandex is an acronym for the phrase Yet Another Indexer. As of December 2011, Yandex had 60.9% of the Russian search market (source: Yandex’s mission is to give the answer to the user anytime and anywhere. Company provides its services for desktop and mobile users and develops embedded solutions as well. The company specializes on highly-targeted sophisticated…

Yandex は、Russia/CIS/Turkey で運用される、インターネット・テクノロジー企業である。 それは、Russia で最大であり、世界でも 5番目に大きな、インターネット・サーチ・エンジンである。 Yandex は、Yet Another Indexer から頭文字を抜き出した名称である。 2011年12月の時点おいて、Yandex は Russia のサーチ・マーケットの 60.9% を有している(情報源:。 Yandex のミッションは、Anytime and Anywhere で、ユーザーに答えを提供することである。 同社は、デスクトップとモバイルのユーザーに対して、また、エンベッド・ソリューションにおいて、そのサービスを提供している。 そして、きわめて洗練された、高度な目標に対して、特化されている・・・


TAG index先日に、『 Yandex の Wonder は、ロシアからアメリカへ向けた観測気球なのか? 』というタイトルの抄訳をポストしましたが、この Yandex の狙いは外されてしまったようですね。Facebook に蓄積した情報であれば、(その持ち主が同意するなら)何でも引き出せる Open Graph は、これからの IT を構成する、きわめて重要なテクノロジーになるはずです。 しかし、この Wonder のケースのように、外部からの API を介した検索は NG というのが、Facebook の基本スタンスのようです。この話は、あくまでも Facebook と Yandex の取り決めという、限定された範囲にフォーカスするものですが、プライバシーと利便性とリテラシーについて、より本質的なところで、議論していく必要があるのだろうと思います。Open Graph からは、目が離せませんね。Image(221)



Facebook の Open Graph : すでに 4000 億回 の インタラクションを達成
Facebook の Graph Search について、簡単だが説明したい : GigaOM
Google の Knowledge Graph は、スタートレックを目指す!
Yandex が Bing を追い越した : 検索マーケットの4番手に踊り出る
Yandex と CERN がコラボ! 機械学習と物理学は 共鳴するのか?

Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する

Posted in .Chronicle, .Selected, Amazon, Google, Research by Agile Cat on March 17, 2013

By the numbers: How Google Compute Engine stacks up to Amazon EC2

By Sebastian Stadil, Scalr – March 15, 2013

_ Gigaom

Summary: When Google launched its EC2 rival, Google Compute Engine, last June, it set some high expectations. Sebastian Standil’s team at Scalr put the cloud infrastructure service through its paces — and were pleasantly surprised at what they found.

Summary: 昨年の 6月に Google Compute Engine が、EC2 のライバルとしてローンチしたとき、いくつかの高い期待値が設定された。 Scalr の Sebastian Standil チームは、このクラウド・インフラ・サービスに対する厳しいテストを、自分自身のペースで行なっているが、その結果として見出したものは、嬉しい驚きである。


At Scalr, we’ve been happy customers of Amazon’s infrastructure service, EC2, since 2007. In fact, we’ve built our tools for EC2 because we saw an opportunity to leverage its flexibility to help AWS customers easily design and manage resilient services. But as competitors spring up, we always test them to see how they compare, especially in regards to io performance.

Scalr における私たちのチームは、2007年から現在にいたるまで、Amazon のインフラ・サービスである EC2 の顧客として満足してきた。 実際のところ、私たちが EC2 用のツールを構築したのは、サービスを設計/管理する AWS の顧客を、さらに柔軟な世界へ容易に取り込んでいくチャンスを見出したからだ。しかし、コンペティタが登場するたびに、その性能をテストし(とりわけ I/O の性能)、AWS と比較してきた。

On a warm June day in San Francisco, the Scalr team attended Google I/O 2012. Google was rumored to be launching a EC2 competitor, which we were interested in for our multi-cloud management software. It launched. And boy did it sound good. You see, EC2 and GCE offer pretty much the same core service, but Amazon has been plagued by poor network and disk performance, so Google’s promise to offer both higher and more consistent performance struck a real chord.

6月の San Francisco にしては、温かいと感じる日に、私たち Scalr チームは、Google I/O 2012 に参加した。 Google には、 EC2 のコンペティタをローンチするというウワサがあり、また、私たちのマルチ・クラウド・マネージメント・ソフトウェアにとって、興味深い対象でもあった。 そして、それはローンチされた。 さらに言えば、きわめて響きの良いものであった。 よく聴いて欲しいのだが、「 大まかなところで EC2 と GCE は、同じコア・サービスを提供する。 しかし、プアなネットワークとディスク・パフォーマンスという、Amazon が引きずっている悩みに対して、一貫性のあるパフォーマンス・スタックを、質と量の両面で高め、それらを調和させていくことを、Google は約束する 」と言っているのだ。

Not ones to be fooled by marketing-driven, hyped-up software, we applied for early access and were let in so we could start testing it ourselves. Once we got in, we felt like kids in a candy store. Google Compute Engine is not just fast. It’s Google fast. In fact, it’s a class of fast that enables new service architectures entirely. Here are the results from our tests, along with explanations of how GCE and EC2 differ, as well as comments and use cases.

マーケティングに騙されるわけでもなく、ソフトウェア・ハイプに乗せられるわけでもなく、私たちはアーリー・アクセスにエントリーし、そこに参加し、私たち自身のテストを開始できた。 そして、そこに入った途端に、自分たちが、まるでキャンディ・ストア内の子供たちになったように思えてきた。 Google Compute  Engine は、単に速いだけではない。 それ、Google の速さなのである。 実際のところ、まったく新しいサービスの、アーキテクチャを可能にするほどのファースト・クラスなのである。 以下に示すのは、私たちのテストの結果であり、それは GCE と EC2 の差異を説明し、ユースケースを伴うものでもある。

A note about our data: The benchmarks run to collect the data presented here were taken twice a day, over four days, then averaged. When a high variance was observed, we took note of it and present it here as intervals for which 80 percent of observed data points fall into.

一連のデータに関しては、1日に 2度のサンプリングを、4日以上にわたり継続し、その平均値を求めた結果であることを、指摘しておく。大きな変動が観察されたときには、それを記録し、観察されたデータ・ポイントの 80% が、安定した値を示している期間のデータを、以下に示すようにしている。


First off, GCE’s API is beautifully simple, explicit and easy to work with. Just take a look at it. Their firewalls are called “firewalls,” vlans are “networks,” and kernels are “kernels” (AKIs, anyone?). Anyone familiar with Unix will feel right at home.

まず、第一に、 GCE の API は美しいほどにシンプルであり、明快であり、また、容易に動かせる。 以下を、見てもらえれば、すぐに意味がわかる。 そのファイアウォールは “firewalls” と呼ばれ、VLAN は “networks” であり、そして、カーネルは “kernels”である (AKIs, anyone?)。 Unix を使い慣れた人であれば、まさに、自宅へ戻ってきた気分だろう。

Fast boot

Second, VMs are deployed and started with impressive speed (and we’ve extensively used 10 clouds). It routinely takes less than 30 seconds to login as root after making the insert call to launch a VM. As a reference point, this is the amount of time it takes AWS to get to the running state, after which you still need to wait for the OS to boot, for a total of 120 seconds on a good day, and 300 on a bad one (data points taken from us-east-1).

第二に、VM のディプロイとスタートであるが、素晴らしいスピードで処理される(そして、10個のクラウドでの利用まで、その範囲を広げている)。通常であれば、VM の始動を要求にしてから 30秒以内で、root としてログインするところまでたどり着く。 リファレンス・ポイントとして、その状態になるまでに、AWS がが必要とする時間を確認すると、 調子の良い日で 120秒、悪い日で 300秒という時間が、OS をブートするまでの待ち時間となる(このデータは us-east-1 のものである)。

Boot times are measured in seconds.

We don’t know what sort of sorcery Google does here, but they clearly demonstrate engineering prowess. That’s 4-10x faster.

どのような種類の魔術を、Google が駆使しているのかは分からないが、明らかに優れたエンジニアリング能力を実証している。 その速度差は、4x ~ 10x に相当する。


Those of you familiar with Amazon’s EBS volumes know that you can attach and detach volumes to any instance, anytime. On GCE, you can’t (at least not yet). This precludes you from switching drives to minimize downtime: attaching a volume on a running server allows you to skip the boot and configure stages of bringing a new node up, which is useful when promoting an existing mysql slave to master and you just need to swap out storage devices.

Amazon の EBS ボリュームに精通した人たちであれば、あらゆるインスタンスに対して、いつでもボリュームを attach/detach できることを知っている。 しかし GCE においては、それが出来ない(少なくと現時点では)。 それにより、デバイスの切り替えにおいて、ダウンタイムを最小限にすることが不可能になる。 つまり、実行中のサーバーにボリュームを付加することで、新しいノードを立ち上げるための、ブートとコンフィグレーションのステージを、スキップすることが不可能なのだ。それは、既存の MySQL Slave を Master に昇格させるときや、ストレージ・デバイスを入れ替えるときに、きわめて有用なものなのだ。

While GCE’s “disks” (as they call them) have that one disadvantage, they offer some unique advantages over Amazon volumes.

このように、GCE の "disks"(と呼ばれている) にはディスアドバンテージがあるが、Amazon ボリュームに対して、いくつかのユニークなアドバンテージも提供している。

Read/write speeds are measured in MB/s. Higher numbers mean faster throughput.

Read/Write のスピードは、MB/秒 で測定されている。 したがって、大きな値のほうが、高いスループットを示す。

For example, disks can be mounted read-only on multiple instances, which makes for more convenient fileserving than object stores, especially for software such as WordPress (see disclosure) or Drupal that expect a local filesystem. Disks are really fast too, and don’t seem to have the variable performance that plagued EBS before the introduction of Provisioned IOPS. See for yourself in the following benchmarks.

たとえば、この disks は、マルチ・インスタンス上に read-only でマウントできる。そして、それは、オブジェクト・ストアよりも、利便性の高いファイル・サービスを実現する場合がある。 とりわけ、ローカルなファイル・システムを要求する、WordPress (see disclosure)やDrupal のようなソフトウェアのケースが、それに該当する。 さらに言えば、この disks は、きわめて高速であり、また、Provisioned IOPS を導入する前に EBS を悩ませる、変化しやすいパフォーマンスという特性を持っていないと思われる。 以下のベンチマークを、確認して欲しい。

As you can see, GCE and EC2 are equivalent on reads, but GCE is 2-4x faster on writes.

ここで確認できるように、GCE と EC2 は Read において互角であり、Write では GCE が 2x~4x ほど優る。


A short note about multi-cloud. I’m talking here about services that span multiple clouds, such as replicating a database from us-east-1 to us-west-1, for disaster recovery or latency-lowering purposes, not the multi-cloud management capabilities widely used in the enterprise. I believe that first kind of multi-cloud is a myth driven by the industry’s less tech-savvy folks. I’ve seen too many people attempt it unsuccessfully to recommend it: what usually happens is the slave database falls behind on the master, with an ever-increasing inconsistency window, because the load on the master exceeds the meager bandwidth available between master and slave. Our friends at Continuent are doing great work with Tungsten to accelerate that, but still.

マルチ・クラウド全体について、述べているのではないことを指摘しておく。 ここで取り上げるのは、たとえば us-east-1 から us-west-1 へ向けた、データベースの複写という範囲での、マルチ・クラウド・サービスである。それは 、DR(Disaster Recovery)や低レイテンシを実現するためのものであり、エンタープライズで広く使われる、マルチ・クラウドの管理能力のことではない。 私は、広範囲におよぶマルチ・クラウドというものは、この業界における、それほど技術に精通していない人々により、広められた神話だと確信している。まぜなら、その促進において、余りにも多くの人々が、失敗するのを見てきたからだ。 一般的に見て、常に増加していく矛盾という視点において、Master データベースの背後に置かれた、Slave データベースが崩壊していくのである。なぜなら、Master における負荷が、Master と Slave の間で利用可能な、不十分なバンドワイズの範囲を超えていくからである。 Continuent における友人たちが、それを加速するために、Tungsten と素晴らしい仕事をしているのだが。。。

Higher bandwidth is better and
means faster up and downlinks.

大きな値の方が Up/Down において高速となる。

Google’s network is so fast, however, that this kind of multi-cloud might just be possible. To illustrate the difference in speeds, we ran a bandwidth benchmark in which we copied a single, 500 Mb file between two regions. It took 242 seconds on AWS at an average speed of 15 Mbit/s, and 15 seconds on GCE with an average speed of 300Mbit/s. GCE came out 20x faster.

しかし、Google のネットワークは、きわめて高速である。 したがって、その種のマルチ・クラウドも可能になるかもしれない。そのスピードにおける差異を例証するために、500 MB のファイルを、2つのリージョン間でコピーするという、ベンチマークを実施してみた。 その結果は、AWS の平均が 242秒(15 Mbit / s)であり、また、GCE の平均が 15秒(300 Mbit / s)というものだった。 GCE の方が、20× も高速という結果になった。

After being so very much impressed, we made a latency benchmark between the same regions. We got an average of 20ms for GCE and 86ms for AWS. GCE came out 4x faster.

この、GCE の、素晴らしいデータが得られた後で、リージョン間でのレイテンシについて、同条件でのベンチマークを実施してみた。 そして、GCE では平均で 20ms という値が得られ、AWS では平均で 86ms という値が得られた。 つまり、GCE の方が、4x も高速であるという結果になった。

Lower latency is better and means
shorter wait times.


This might allow new architectures, and high-load replicated databases might just become possible. Put a slave in different regions of the US (and if/when GCE goes international, why not different regions of the world?) to dramatically speed up SaaS applications for read performance.

それにより、新しいアーキテクチャが実現するかもしれない。 つまり、高負荷におけるデータベース複写が、可能になるという話である。たとえば、アメリカ国内における個々のリージョンに( GCE のインターナショナライズが実現すれば、世界中のリージョンが対象)、SaaS アプリケーションの Slave を配置すれば、Read に関するパフォーマンスが劇的に向上するだろう。

Of course, unless Amazon and Google work together to enable Direct Connect, bandwidth from GCE to EC2 will still be slow. I also hear that Amazon is working on creating a private backbone between regions to enable the same use cases, which would be an expected smart move from them.

もちろん、 Amazon と Google が、Direct Connect を実現するために協調しなければ、GCE から EC2 へ(その逆も)向けたバンドワイズは低いままとなるだろう。 そして、同じユース・ケースを実現するリージョン間プライベート・バックボーンを、Amazon も構築しているという話を耳にしている。Amazon による、スマートな対応になると期待される。

Multi-region images

We’re not quite sure why AWS doesn’t support this, but images on GCE are multi-region (“multi-zone” in their terms), that is to say when you snapshot an instance into an image, you can immediately launch new instances from that image in any region. This makes disaster recovery that much easier and makes their scheduled region maintenance (which occurs a couple of times a year) less of a problem. On that note, I’d also like to add that it forces people to plan their infrastructure to be multi-region, similar to what AWS did for instance failure by making local disk storage ephemeral.

この件に関して、AWS がサポートしない理由が分からないが、GCE 上のイメージは、マルチ・リージョン(GCE では Multi-Zone と呼ばれている)に対応している。それは、インスタンスのスナップショットを、イメージとして取り込んだときに、そのイメージから得られる新しいインスタンスを、あらゆるリージョンで即座に展開できるというものだ。 つまり、DR(Disaster Recovery )が容易になり、定期的なリージョン・メンテナンス(通常では年に2回程度)における問題が低減される。 ここで指摘しておきたいのは、それぞれのインフラに関する、マルチ・リージョン化を計画すべきという点である。 それは、AWS が、ローカル・ディスク・ストレージを ephemeral(短期)に留めることで、インスタンスの劣化に対処するのと、同じような意味合いを持つ。

So should you switch?

AWS offers an extremely comprehensive cloud service, with everything from DNS to database. Google does not. This makes building applications on AWS easier, since you have bigger building blocks. So if you don’t mind locking yourself into a vendor, you’ll be more productive on AWS.

AWS においては、DNS からデータベースにまで至る、きわめて包括的なクラウド・サービスが提供されている。 だが、Google は、そうではない。 あなたの開発するビルディング・ブロックが大規模なら、AWS におけるアプリケーション構築の方が容易になる。 つまり、ベンダー・ロックを厭わないなら、AWS 上で生産性を高めていけるだろう。

But that said, with Google Compute Engine, AWS has a formidable new competitor in the public cloud space, and we’ll likely be moving some of Scalr’s production workloads from our hybrid aws-rackspace-softlayer setup to it when it leaves beta. There’s a strong technical case for migrating heavy workloads to GCE, and I’ll be grabbing popcorn to eagerly watch as the battle unfolds between the giants.

しかし、それはそうとして、Google Compute Engine の登場により、AWS はパブリック・クラウド・スペースにおいて、手強いコンペティタを持つことになる。そして、GCE がベータから脱するとき、Scalr のプロダクト・ラインにおいても、Aws-Rackspace-Softlayer というハイブリッド設定に対して、手を加えることになるだろう。ヘビーなワークロードを、GCE に移行させるという、テクニカルなケースがあるはずだ。そして、巨人同士のバトルが展開される様子を、私はポップコーンを片手に、観客席から熱心に見守ることになるだろう。

Sebastian Stadil is the founder of Scalr, a simple, powerful cloud management suite, and SVCCG, the world’s largest cloud computing user group. When not working on cloud, Sebastian enjoys making sushi and playing rugby.

Note: Data scientists from LinkedIn, Continuuity, Quantcast and NASA will talk about their hardware and software stacks at our “guru panel” at Structure:Data next week, March 20-21, in New York City.

Disclosure: Automattic, maker of, is backed by True Ventures, a venture capital firm that is an investor in the parent company of this blog, GigaOM. Om Malik, founder of GigaOM, is also a venture partner at True.

Related research


TAG indexかなりシリアスな内容のポストであり、GigaOm のサイトにも、数多くのコメントが寄せられています。 また、AWS の Jeff Barr さんも、『 The AWS Report – Sebastian Stadil of Scalr 』というタイトルで、Scalr Sebastian Stadil さんへのインタビューを紹介しています。 そのタイミングが、この GigaOM へのポストの前日というのも、ちょっと気になるところです。 内容は、以下のコメントと Youtube 動画です。image115

In the latest episode of The AWS Report, I spoke with Sebastian Stadil of Scalr to learn more about their cloud management software:



Google Compute Engine は、どこで Amazon AWS を上回るのか?
Google Compute Engine の登場で、どのような影響が IssS 業界に?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
Google の Knowledge Graph は、スタートレックを目指す!
Google I/O – 2013 の登録開始:しかし 48分間で売切れてしまった


Facebook の Open Graph を使うなら、Kinvey の BaaS が良さそうだ

Posted in .Selected, API, BaaS, Facebook, Open Graph, Social by Agile Cat on November 16, 2012

Kinvey Service Fixes Crack In Facebook’s Open Graph Back-End

Dan Rowinski – November 12th, 2012


Facebook’s Native Mobile Problem With Open Graph

In 2010, Facebook attempted to redefine the meaning of "verbs" in the Web Era. The company’s Open Graph turned users actions (such “Jon ran” or “Susie listened”) into status updates, tied to Web apps. The Open Graph opened up a new world of data to Facebook and its developer community. But there was a hitch and, like many of Facebook’s recent issues, the source was mobile. In the Mobile Era, Facebook’s Web-centric approach has caused it many problems, from monetization to user experience in its mobile app on iOS and Android.

Facebook は 2010年に、Web Era における「Verb」の意味を再定義しようと試みた。同社の Open Graph は、ユーザー・アクションを、Web アプリケーションに結びつけられたステータス・アップデートに置き換えた( たとえば、“Jon ran”、“Susie listened” など)。 この Open Graph は、Facebook とベロッパー・コミュニティへに対して、新しいデータの世界へのドアを開けた。 しかし、Facebook における最近の問題のように、モバイルからのソースを、接続する必要があった。 そして Mobile Era になり、この Facebook の Web セントリックなアプローチは、iOS や Android といったモバイル・アプリにおける、マネタイズからユーザー・エクスペリエンスにいたるまで、数多くの問題をもたらしてきた。

Image(66)クリックで拡大 ⇒

On the other hand, Facebook’s biggest strength is its ability to make connections between its users’ friends, what they “like” and what they do. The more threads that Facebook can tie to a user, the better able it is to sell advertising to them. That makes Open Graph the biggest single innovation Facebook has introduced in the last few years.

その一方で、Facebook の最大の強みは、Like などのアクションに関して、ユーザーのフレンドたちの間で、コネクションを作る能力にある。 そして、Facebook がユーザーたちを結びつけるスレッドには、広告を販売していく能力まであるのだ。それこそが、この数年において、Facebook が Open Graph に導入してきた、最も大きなシングル・イノベーションなのである。

Integrating Open Graph has been a problem since the it was announced in 2010 and expanded in late 2011 to include the new Timeline profile. Apps with Web-based back ends, such as Spotify, have been easily able to use Open Graph but the option for most native developers was beyond their means. But developers with “native” mobile apps had to go through extraordinary lengths to tie the Open Graph to their applications and only a handful of well-funded startups (such as Instagram or RunKeeper) with big development teams have been able to pull it off. The problem was that the backend systems for native mobile apps are difficult to optimize to Open Graph.

2010年の発表から、Timeline プロファイルを取り込んだ 2011年後半の拡張に至るまで、Open Graph の統合は問題をかけ続けてきた。Spotify のような、 Web ベース・バックエンドを持つアプリケーションは、Open Graph を容易に使うことができたが、大半のネイティブ・デベロッパーのための選択肢は、彼らの手段を超えたところにあった。 しかし、Native のモバイル・アプリを取り扱うデベロッパーは、自身のアプリと Open Graph を結び付けるために、並外れた長さのパスを通り抜けなければならなかった。そして、大規模な開発チームと資金力を持つ、ほんのひと握りのスタートアップ(Instagram や RunKeeper などの)だけが、それをやり遂げることができた。つまり、ネイティブ・モバイル・アプリのためのバックエンド・システムを、Open Graph に最適化することが難しいという、問題が存在していた。

Kinvey’s Middle Point

A startup in Boston is aiming to fix that. Kinvey, a “Backend-as-a-Service” provider for mobile application development, has created a simple way for native developers to connect their apps to Open Graph and allow users to use easily use more "verbs" on their timelines from their smartphones and tablets.

ある Boston のスタートアップが、その問題を FIX しようとしている。 モバイル・アプリ開発のための Backend-as-a-Service であるKinvey は、ネイティブ・デベロッパーのアプリと Open Graph を接続するための、容易な方法を作り上げている。そして、ユーザーたちは、スマートフォンとタブレットから、自身の Timeline 上で、さらに多様な Verb を利用できる。

Image(182)クリックで拡大 ⇒

Open Graph functions by pulling in data from Web endpoints by connecting the action (verbs like "run," "cook," "listen" etc.) with metadata from the Web app. So, if I am baking cookies, I can hit the “I baked cookies” button on some webpage and Facebook will crawl for the metadata associated with that action and post it to Timeline. This works only because the webpage has metadata, stored on the Web, that Facebook can crawl. Mobile apps do not often have this type of metadata available to be searched, nor any backend system or URL that Facebook can crawl.

Open Graph の機能は、Web アプリからのメタデータと、アクション( run、cook、listen など)を結び付けることで、Web エンド・ポイントからデータを引き出す。したがって、私がクッキーを焼いているなら、いくつかの Web ページ上で、「私はクッキーを焼いた」ボタンをクリックできる。そして Facebook は、そのアクションと結び付けられるメタデータを探し出し、Timeline にポストしてくれる。 この機能は、Web ページがメタデータを持ち、それが Web ページにストアされ、さらに Facebook がクロールできるときにのみ、上手く処理される。 しかし、大半のモバイル・アプリは、この種のサーチに対応するメタデータを持っていない。 さらに言えば、Facebook がクロールできる、バックエンド・システムも URL も同様である。

Kinvey has a simple solution. It takes the metadata (known as the “object”) from a mobile app and hosts it on its own servers. It then takes that data and creates its own Web endpoints for Facebook to crawl. It is a clever bit of integration. Kinvey is not changing the basic nature of Open Graph nor doing anything extraordinarily technical, rather it is creating a new middle point between a developers’ apps and the Open Graph – with an interface that lets them push or retrieve data. Kinvey sets up the entire system on its own and handles the data flow for the developers.

Kinvey には、シンプルなソリューションがある。 それは、モバイル・アプリからメタデータ( ojeect のこの)を受け取り、自身のサーバー上にホストする。 続いて、そのデータを取得し、Facebook からクロールできる、自身の Web エンドポイントを生成する。 それは、インテくグレーションのための、利口なやり方である。 Kinvey は、Open Graph の基本的な特性を変えることもなく、また、テクノロジーに走りすぎることもない。どちらかと言えば、データを Push/Get するためのインタフェースを用いて、デベロッパーのアプリと Open Graph の間に、ミドル・ポイントを作るだけである。Kinvey は、自身の環境にシステム全体を設定し、デベロッパーのためにデータ・フローを処理する。

Good For Everyone?

The benefit for mobile developers is clear: they can extend native apps actions to Facebook’s entire population and make them accessible on Timeline without creating an entirely new structure.

モバイル・デベロッパーにとって、明らかなメリットが生じる。 つまり、ネイティブ・アプリのアクションを、Facebook の全ユーザーへ向けて拡張できる。そして、まったく新しい構造を作ることなく、Timeline へのアクセスを実現していく。

Facebook benefits because it does not have to completely reconfigure Open Graph to serve the large native mobile developer environment. Plus, it gets previously unavailable data from smartphone and tablet users. This could significantly help Facebook spread through the app ecosytem just as it has already done with Web pages.

Facebook にも、メリットが生じる。なぜなら、巨大なネイティブ・モバイル・デベロッパー環境をサポートするために、Open Graph を再定義する必要がなくなるからだ。 さらに、以前には対応できなかった、スマートフォンとタブレットのユーザから、データを受けとることが可能になる。 それにより、すでに Web ページで完了しているように、Facebook の大規模な拡散を、アプリ・エコシステムを介して促進できる。

Users get the benefits of Open Graph on the Web extended to mobile applications.

そして、ユーザーは、Web 上での Open Graph のメリットを、モバイル・アプリにも拡張できる。


Image(219)BaaS にも、いろいろなタイプがあるはずなので、一概には言えませんが、このように、エンド・ポイント間のミドル・ポイントとして機能するというのは、とても分かりやすい話ですね。Image(220) なんというか、Agile_Cat にとっては、OpenGraph も BaaS も、茫洋として、掴みどころがなかったのですが、この記事は、双方に対する理解を、一度に進めてくれる、とても素晴らしい内容だと思います。 嬉しいです! Image(221)



Facebook – Open Graph Beta の概説
Facebook が Open Graph アクションをアップデート
モバイル BaaS って何だ? Appcelerator による Cocoafish 買収から探ってみよう
Yahoo の Mojito は、Mobile デバイスに対応する OSS Dev プラットフォームなのだ
AppMobi の狙いは、Mobile + OSS + HTML5 の惑星大直列なのだ!

%d bloggers like this: