Agile Cat — in the cloud

赤道上に浮かべる 180基の衛星:Google は成層圏バックボーンを目指すのか?

Posted in .Selected, Google, Satellite, Strategy by Agile Cat on December 17, 2014

Google-backed Global Broadband Venture Secures Spectrum for Satellite Network
http://wp.me/pwo1E-86a
Peter B. de Selding | May. 30, 2014
http://www.spacenews.com/article/satellite-telecom/40736google-backed-global-broadband-venture-secures-spectrum-for-satellite

ーーーーー

<注記> ちょっと古い記事であり、ここで取り上げられている WorldVu は、最近では Elon Musk の SpaceX と提携するだろう、という記事も出ています。

ーーーーー

PARIS — A company based in Britain’s tax-friendly Channel Islands and backed by Google and the founder of satellite broadband trunking provider O3b Networks has secured radio spectrum rights to build a low-orbit satellite constellation to provide global broadband to individual consumers, industry officials said.

PARIS — Britain Tax Friendry の Channel 諸島を拠点とし、Google および、衛星ブロードバンド·トランキング·プロバイダー O3b Neuworks の Founder に支援される企業が、低軌道衛星群を構築するための無線スペクトルの権利を確保し、利用者となる企業に対してグローバル・ブロードバンドを提供していくことになると、業界関係者たちが語っている。

Brian Holz, 03b’s former chief technology officer, is leaving the company for WorldVu. Credit: Photo courtesy of Brian Holz

The company, which uses the name L5 in its regulatory filings and is registered in St. Helier, Jersey, under the name WorldVu Satellites Ltd., has picked up Ku-band spectrum initially planned for use by a now-defunct company called SkyBridge to launch a constellation of 360 small satellites for a global Internet service.

その会社は、L5 という名称で規制当局への申請を行い、WorldVu Satellites Ltd. という名で St. Helier, Jersey 島に登記されている。そして、いまは消滅してしまった SkyBridge という会社が、グローバル・インターネット・サービスを提供するために、360個の小型衛星群を運用しようと計画したときの、Ku-band というスペクトルを拾い上げ、新たなビジネスを立ち上げようとしている。

The International Telecommunication Union (ITU), the Geneva-based United Nations affiliate that regulates satellite orbital slots and wireless broadcast spectrum, shows L5 filings as promising to start service in late 2019.

Geneva ベースの国連関連団体として The International Telecommunication Union (ITU) があるが、この人工衛星の軌道スロットと無線ブロードキャスト・スペクトルを規制する組織の報告書を見ると、2019年の後半には L5 がサービスを開始する可能性が高いと分かる。

The satellites, tentatively designed to operate in circular orbits of 800 and 950 kilometers inclined 88.2 degrees relative to the equator, have been given regulatory deadlines of between late 2019 and mid-2020 to enter service, according to ITU records.

この衛星は、赤道を基準に 88.2 度の緯度幅をカバーし、800km 〜 950km の高度で軌道を描くよう、暫定的にデザインされている。そして ITU の記録によると、サービスに入るための規制上のデッドラインとして、2019年の後半〜2020年の半ばという期限が与えられている。

WorldVu appears to be a Google response to the same question being asked by all the big global Internet service providers, search engines and social networks: How do you reach hundreds of millions of potential users residing in places without broadband access?

グローバルかつ大規模に展開される、すべてのインターネット·サービス·プロバイダ/検索エンジン/ソーシャル・ネットワークに共通する疑問への、Google の回答が WorldVu なのだと思われる。つまり、ブロードバンドでアクセスできない場所に住んでいるかもしれない無数のユーザーに、どのようにしてリーチするのかという問いに対する答えとなる。

Facebook purchased Britain’s Ascenta unmanned aerial systems designer as part of what it calls its Connectivity Lab project, which is exploring satellite and atmospheric Internet nodes. Google earlier this year purchased Titan Aerospace, a drone designer of what are sometimes called "atmospheric satellites." With WorldVu, Google appears to be adding a play in conventional exo-atmospheric version.

Facebook は Connectivity Lab プロジェクトと呼ぶ活動の一環として、イギリスの Ascenta という無人航空機システムのデザイナーを手にしており、それにより、衛星を用いた大気圏内インターネット・ノードの構築を模索している。その一方で Google は、今年の初めに Titan Aerospace を買収しているが、これも大気圏内衛星とも言える、ドローンのデザインが絡んでいる。つまり、Google は WorldVu により、これまでの大気圏バージョンでの活動を強化しているように見える。

注記:地球の大気圏は 1000km に及ぶ。

The ITU’s Master International Frequency Register is routinely peppered with filings — satellite networks in ITU parlance — that clog the system, hoard spectrum rights and ultimately never are built.

ITU の Master International Frequency Register は、ITU 用語で衛星ネットワークと呼ぶ書類により、毎日のように攻め立てられている。 つまり、それによりシステムが目詰りし、スペクトル権を買い溜めされるが、最終的には構築されないという状況が繰り返されていた。

In the case of L5/WorldVu, there is reason to suspect this is not just another paper satellite.

しかし、L5/WorldVu のケースでは、単なるペーパー・サテライトではないと、推測させる理由がある。

For starters, WorldVu is located in the same small town where Greg Wyler registered and founded O3b Networks, which also started with modest support from Google and is now building a business of providing high-speed fixed and mobile Internet links to customers located between 40 degrees north and 40 degrees south of the equator. O3b’s mission, as the company likes to point out, is to connect the “other 3 billion people” around the globe “who have been denied broadband access for reasons of geography, political instability and economics.”

まず、第一に、Greg Wyler が O3b Networks を設立/登記した、同じ小さな街に WorldVu は位置しており、また、Google からのささやかな支援が開始されている。そして、現在は、北緯 40度と 南緯 40度の間に住む人々をサポートするための、ワイヤー/モバイルによるインターネット·リンクを提供するためのビジネスを立ち上げている。O3b が、よく口にする同社の使命は、地理/政治/経済などの理由により、ブロードバンドへのアクセスが不可能だとされる、もう一方の世界の「 30億人 」をインターネットに接続することである。

Joining Wyler in the WorldVu venture are Brian Holz, O3b’s former chief technology officer; and David Bettinger, a long-time chief technology officer of satellite ground terminal provider iDirect.

WorldVu の冒険において、Wyler と行動を共にする Brian Holz の前職は O3b の CTO であり、また、David Bettinger は衛星用の地上ターミナル・プロバイダーである、iDirect の CTO を長年にわたって務めてきた。

Holz’s departure from O3b at this juncture in the company’s history — a component defect on the first four satellites has delayed the launch of the second four, now scheduled for July — might be viewed as curious.

同社の歴史おいて、つまり、第一陣の 4つの衛星におけるコンポーネントの欠陥により、第二陣の 4つの衛星の打ち上げが 7月にズレ込んでいるという時点で、O3b のプロジェクトから Holz が離脱するのは、不思議なことだと思われるだろう。

While the current satellites operate well, their life expectancy has been compromised by the defect in the onboard component, called the centralized power supply and frequency generator unit.

現時点で、それらの衛星は上手く機能しているが、集中電源と周波数ジェネレータをいう、オンボード・コンポーネントの欠陥により、その平均寿命は期待値に届かないだろう。

In a May 27 response to SpaceNews inquiries, O3b said Holz “is leaving us for Google, which as you know is an O3b shareholder, but he will continue to serve on O3b’s technical advisory committee.” Attempts to reach Wyler, or anyone else, at the address listed for WorldVu were unsuccessful.

5月27日の SpaceNews からの問い合わせに対して O3b は、「 周知のとおり、O3b の株主でもある Holz は Google へと去っていくが、O3b の技術諮問委員は継続して務めることになる」と述べている。つまり、Wyler たちが連携していくような、WorldVu が考えていた試みは、上手く行かなかったことになる。

Holz has been replaced at O3b by Stewart Sanders, a senior vice president at satellite fleet operator SES of Luxembourg, which is O3b’s biggest shareholder.

Holz の後任には、 O3b の最大の株主であり、複数の衛星を管理する SES of Luxembourg の、Senior VP である Stewart Sanders が就任することになった。

An industry official familiar with the move said Holz will remain active at O3b at least through the launch of the second group of satellites, and his departure was arranged in a way to minimize perturbations at O3b, which remains a startup enterprise.

この動きに詳しい業界関係者は Holz について、第二陣の衛星群と打ち上げるまで、彼は少なくとも O3b でのアクティブな状況を維持し、スタートアップ・エンタープライズである O3b の、不安要素を最小限に抑えるよう再考された、と述べている。

“There is no way that Brian was going to do anything that would hurt O3b,” the industry official said, adding that L5/WorldVu should not be seen as a future O3b competitor.

「 O3b を傷つけることなく、何らかの行動を Brian が起こせるかというと、それは不可能である」と、その業界関係者は述べているが、将来的に L5/WorldVu と O3b がライバル関係になるかというと、それも違うと、付け加えている。

“O3b provides low-latency broadband trunking to telcos and large mobile platforms through relatively expensive ground stations,” the official said. “WorldVu wants to connect the world with affordable links to millions of individuals not now on the grid.” Google’s ultimate involvement in the venture “remains speculative at this point,” the official said.

「 O3b は、相対的に見て費用のかかる地上局を介して、テレコムと大手モバイル・プラットフォームに、低レイテンシのブロードバンドをバルクで提供する。 その一方で、WorldVu は、いまはグリッドにアクセスできない無数の人々に、安価なリンクで接続したがっている」と、その業界関係者は述べている。 そして、最終的には、この冒険に Google も関与するだろうが、「現時点では推測も伴う」と付け加えている。

L5/WorldVu’s ambition is to succeed where previous global satellite Internet projects have failed. O3b is using Ka-band frequencies that were abandoned by the now-defunct Teledesic venture, in which more than $1 billion was invested before its backers threw in the towel.

L5/WorldVu の野望は、これまでのグローバル・サテライト・インターネット・プロジェクトが失敗した領域で、成功を収めることである。 O3b が使用している Ka-band 周波数帯域は、いまは無き Teledesic というベンチャーが放棄したものであり、その支持者たちが諦めるまでに、$1 Billion 以上が投資されている。

SkyBridge had a similar idea, but in Ku-band. It too was abandoned for lack of financing, and it is the legacy SkyBridge frequencies that L5/WorldVu proposes to use.

SkyBridge も、Ku-band においてだが、同じような考えを持っていた。 そして、あまりにも膨大な資金を必要とするため、SkyBridge が放棄したものを、L5/WorldVu が使用すると提案しているわけだ。

Youtube ⇒

The Teledesic and SkyBridge projects accomplished the key goal at ITU of securing regulatory approval for nongeostationary-orbiting satellite communications networks.

Teledesic と SkyBridge のプロジェクトは、非静止軌道衛星通信ネットワークのための、規制当局の承認を確かなものにするという意味で、ITU における主要な目標を達成している。

Both networks agreed to incorporate complicated power-flux-density adjustments so that their satellites’ frequencies would not disturb broadcasts from satellites using the same spectrum from higher geostationary orbit.

この 2つのネットワークは、複雑な電波密度の調整を組み込むことで合意していた。それにより、同じスペクトルを使用する、より高い高度の静止軌道衛星からのブロードキャストを、二社の衛星の周波数が妨害しないようになっている。

It is an issue that WorldVu will face — especially when its hundreds of satellites pass over the equator — as Ku-band is widely used by telecommunications operators who have priority rights to the same spectrum.

それは、WorldVu が直面することになる問題だ。 つまり、同じスペクトルにおいて優先権を持っているテレコム事業者が、Ku-band を広範囲で使用するにつれて生じることになる、何百もの衛星が赤道上を通過する際の問題である。

Just as important for L5/WorldVu is the dramatic decrease in prices for sophisticated satellite antennas, satellite power-generation systems and payload electronics. It is here that Teledesic and SkyBridge confronted issues that drove up the costs of the systems and ultimately forced their collapse.

また、L5/WorldVu にとって重要な事柄として、きわめて洗練された、衛星のアンテナおよび発電システムと、搭載する電子機器に関する、劇的なコストの削減が挙げられる。それこそが、Teledesic と SkyBridge の前に立ちはだかった問題であり、システムのコストをつり上げ、最終的にはプロジェクトを崩壊へと至らしめた。

“Lots of things have changed since then,” the industry official said. “Satellite technology is no longer considered black magic. Look what’s being done with Earth observation constellations like SkyBox Imaging and Planet Labs and the new generation of cubists.”

「 あれから、あらゆるものが変化した。もはや、衛星テクノロジーを魔術として捉えるべきではない。 SkyBox Imaging や Planet Labs といった、地球の観測を志す、新たな世代の台頭を見てほしい」と、前述の業界関係者は述べている。

SkyBox Imaging — a California company building a constellation of high-resolution optical Earth imaging satellites in which Google is said to be interested — and Planet Labs of San Francisco have both launched the first of their imaging satellites.

ちなみに、SkyBox Imaging とは、地上のイメージを高解像度で撮影する California の企業であり、Google が興味を示しているとされる。また、San Francisco の Planet Labs も、地上イメージを撮影するための、自身の衛星を打ち上げている。

In addition to offering limited scale economies in satellite production, smaller satellites hold out the hope for lower launch costs when measured on a per-delivered-megabit basis.

さらに言えば、配信するデータをメガビット単位で規定できるなら、その望みを叶える実用的な小型衛星を打ち上げるための、規模の経済が具体化してきているのである。

ーーーーー

とても夢のある話で、訳していてワクワクしてしまいました。 海底に設置されたケーブルと赤道上に並ぶ衛星により、多層化されたインターネット・バックボーンのメッシュが、この地球を包み込んでいくのでしょうね。 さらに言えば、より低軌道に浮かぶ衛星やドローンなどを介して、地上に網を張りにくいアフリカや南米などにも、インターネット接続を提供するという流れが、さらに加速していくかもしれません。また、Google に関しては、この記事がポストされた直後の 6月に、Skybox Imaging という衛星スタートアップを買収しているので、なんらかの方針の変更が生じているのかもしれません。 Elon Musk の SpaceX も含めて、2015年は衛星に関する動向も追いかけて行きたいと思っています。

ーーーーー

<関連>

Google が買収した、Skybox Imaging という衛星スタートアップについて
Google と Virgin が思い描く宇宙開発の夢とは? その宇宙船を Youtube で!
Intelsat と SpeedCast が連携して、グローバル接続をカバーする通信衛星とは
Alcatel-Lucent の海底ケーブルが、31Tbps の記録を達成!
空芯型ファイバーにより、光速の 99、7% に到達するテクノロジーとは?

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC by Agile Cat on December 11, 2014

Facebook Mobile Drops Pull For Push-based Snapshot + Delta Model
http://wp.me/pwo1E-85F
Monday, October 20, 2014
http://highscalability.com/blog/2014/10/20/facebook-mobile-drops-pull-for-push-based-snapshot-delta-mod.html

We’ve learned mobile is different. In If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong we learned programming for a mobile platform is its own specialty. In How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks we learned bandwidth on mobile networks is a precious resource.

私たちは、モバイルが別の世界のものであることを学んできた。If You’re Programming A Cell Phone Like A Server You’re Doing It Wrong では、モバイル・プラットフォームのためのプログラミングが、独特のものであることを知った。そして、How Facebook Makes Mobile Work At Scale For All Phones, On All Screens, On All Networks では、モバイル・ネットワークの帯域幅が、きわめて貴重なリソースであることを学習した。

Given all that, how do you design a protocol to sync state (think messages, comments, etc.) between mobile nodes and the global state holding servers located in a datacenter?

それら、すべてのことを考慮して、ステート(メッセージやコメントなど)をシンクさせるためのプロトコルを、どのようにデザインすべきなのだろうか? ここでは、複数のモバイル・ノードと、データセンターのサーバーに置かれたグローバル・ステートの、同期について考えていく。

Facebook recently wrote about their new solution to this problem in Building Mobile-First Infrastructure for Messenger. They were able to reduce bandwidth usage by 40% and reduced by 20% the terror of hitting send on a phone.

最近のことだが、Facebook の Building Mobile-First Infrastructure for Messenger というポストにおいて、この問題に関する彼らの新しいソリューションが紹介されている。それによると、帯域幅の使用率が 40% まで、そして、スマホでの送受信を阻害する要因が 20% まで、削減できたという。

That’s a big win…that came from a protocol change.

それは、素晴らしい成功体験であり、また、プロトコルの変更にもたらされたものである。

<関連> Facebook が語るモバイル・チューニングの極意

Facebook Messanger went from a traditional notification triggered full state pull:

The original protocol for getting data down to Messenger apps was pull-based. When receiving a message, the app first received a lightweight push notification indicating new data was available. This triggered the app to send the server a complicated HTTPS query and receive a very large JSON response with the updated conversation view.

Messenger がデータをダウンロードする際の、オリジナルのプロトコルは Pull ベースのものであった。 このアプリはメッセージを受信するとき、新しいデータがあることを示す、ライトウェイトなプッシュ通知を最初に受信する。それは、アプリに対するトリガーであり、その結果として、サーバーへ向けて複雑な HTTPS クエリーを送信し、また、アップデートされた会話を取り込んだ、きわめて大規模な JSON レスポンスを受信することになる。

To a more sophisticated push-based snapshot + delta model:

Instead of this model, we decided to move to a push-based snapshot + delta model. In this model, the client retrieves an initial snapshot of their messages (typically the only HTTPS pull ever made) and then subscribes to delta updates, which are immediately pushed to the app through MQTT (a low-power, low-bandwidth protocol) as messages are received. When the client is pushed an update, it simply applies them to its local copy of the snapshot. As a result, without ever making an HTTPS request, the app can quickly display an up-to-date view.

私たちは、前述のモデルに代えて、Push ベースの SnapShot + Delta モデルに移行することを決めた。 この新しいモデルでは、クライアントは自身のメッセージに関する、イニシャルの SnapShot を取得する(一般的には、これまでの HTTPS Pull のみとなる)。 続いて、Delta アップデートが読み込まれるが、それはメッセージを受信した直後に、MQTT(リソースと帯域において負荷の少ないプロトコル)を介してアプリに Push されるものである。また、クライアントからアップデートが Push されるときには、ローカルに保持される SnapShot に、その内容がコピーされる。その結果として、これまでのような HTTPS リクエストを必要とすることなく、アプリはアップデートされたビューを表示できるようになる。

We further optimized this flow by moving away from JSON encoding for the messages and delta updates. JSON is great if you need a flexible, human-readable format for transferring data without a lot of developer overhead. However, JSON is not very efficient on the wire. Compression helps some, but it doesn’t entirely compensate for the inherent inefficiencies of JSON’s wire format. We evaluated several possibilities for replacing JSON and ultimately decided to use Thrift. Switching to Thrift from JSON allowed us to reduce our payload size on the wire by roughly 50%.

さらに、私たちは、メッセージと Delta アップデートから、JSON エンコーディングを切り離すことで、このフローを最適化した。もし、開発者のオーバーヘッドを最低限に抑えたかたちで、ヒューマン・リーダブルで柔軟なデータ転送を実現するなら、JSON は素晴らしいソリューションとなる。しかし、JSON における送受信の形式は、きわめて効率が悪い。 圧縮により、いくつかの問題は解決するが、JSON の固有の非効率性を、完全に補完することは不可能だ。私たちは、JSON を置き換えるための、いくつかの可能性について評価し、最終的には Thrift を使用することにした。JSON から Thrift へ移行することで、転送における実質的なサイズを、およそ 50% に低減できた。

On the server side Facebook also innovated:

Iris is a totally ordered queue of messaging updates (new messages, state change for messages read, etc.) with separate pointers into the queue indicating the last update sent to your Messenger app and the traditional storage tier. When successfully sending a message to disk or to your phone, the corresponding pointer is advanced. When your phone is offline, or there is a disk outage, the pointer stays in place while new messages can still be enqueued and other pointers advanced. As a result, long disk write latencies don’t hinder Messenger’s real-time communication, and we can keep Messenger and the traditional storage tier in sync at independent rates. Effectively, this queue allows a tiered storage model based on recency.

Iris は、メッセージングのアップデート(新しいメッセージやメッセージ・リードによるステートの変化など)で用いる順列キューのことであり、Massenger アプリに送信された最新のアップデートと、伝統的なストレージ階層において、別々のポインタを持つことが可能になっている。ディスクおよびスマホへのメッセージ送信が成功すると、それに対応するポインタが前進する。もし、スマホがオフラインであったり、ディスクに障害が発生した場合には、対象となるポインタを所定の位置に留めながら、新しいメッセージをキューに保持し、他のポインタを前進させることができる。その結果として、ディスクへの書き込みなどの、大きなレイテンシが発生しても、Messenger のリアルタイム通信を妨げることはない。 そして、Messenger のレベルと伝統的なストレージ階層を、それぞれの頻度で同期させることも可能だ。このキューの効率性により、新しい階層型ストレージ·モデルが実現する。

Delta based syncing strategies are very common in Network Management systems where devices keep a north bound management system in sync by sending deltas. The problem with a delta based approach is it’s easy for clients to get out of sync. What if changes happen at a rate faster than than deltas can be moved through the system? Or queues get full? Or the network drops updates? The client will get out of sync and it won’t even know it. Sequence numbers can be used to trigger a full sync pull if there’s an out of sync situation.

Delta ベースの同期ストラテジーは、ネットワーク・マネージメント・システムにおいて、きわめて一般的なものである。 そこでは、デバイスが Delta を送信することで、上位階層のマネージメント・システムとの同期を維持する。 Delta ベースのアプローチにおける問題点は、その同期のメカニズムから、クライアントが容易に逸脱してしまうことである。 何らかの変更が Delta よりも速く、対象となるシステムを介して移動することが、実際に起こり得るだろうか? また、キューが溢れると、どうなるだろうか? さらに言えば、ネットワーク上でアップデートが失われたら、何が起こるだろうか? いずれにせよ、クライアントは同期から逸脱し、起こっていることを知ることもできない。そのような場合には、シーケンス・ナンバーを用いる。 それにより、完全な同期を引き起こし、同期から逸脱している状況を解消できる。

It’s also good to see Facebook got rid of JSON. The amount of energy and bandwidth wasted on moving and parsing fat JSON packets is almost criminal.

Facebook が JSON から離れることは、別の観点でも歓迎すべきことだ。このような巨大なシステムが、重たい JSON パケットを解析して転送するために、膨大なエネルギーと帯域幅を消費することは、きわめて罪作りなことでもあるのだ。

ーーーーー

先日にポストした「Facebook が語るモバイル・チューニングの極意」に続いて、今回も Todd Hoff さんの記事を紹介することができました。途上国におけるモバイル通信の状況を前提とした、ストレスを最小限に抑えた環境を提供したいという、Facebook の一貫したストラテジーが見えてきますね。 ただ、これは、途上国だけの問題ではなく、たとえば日本においても、モバイル・トラフィックの大幅な削減という、大きなメリットをもたらすはずです。 そして、私たちが使用している大半のサービスは、① モバイル・デバイス、② モバイル・インターネット環境、③ バックエンド・テクノロジー、④ データセンター・インフラのバランスの上に成り立っているわけですが、とりわけ途上国においては、① と ② のケアが不可欠なのでしょう。

ーーーーー

<関連>

iOS から Android へ : Facebook は優先順位を切り替えるのか?
Facebook が キャリアの協会に参加 : 狙いは Internet.org だ!
Mark Zuckerberg と Internet.org : コネクティビティが社会経済をバランスさせる
Facebook とモバイルの巨人たちが、Internet.org を立ち上げた!
Facebook に続け : 10億に挑む Android と iOS

iOS から Android へ : Facebook は優先順位を切り替えるのか?

Posted in .Selected, Apple, Facebook, Google, Mobile, Post-PC by Agile Cat on December 9, 2014

Facebook Is Seeing More And More App Developers Go Android-First
http://wp.me/pwo1E-85q
Jim Edwards – Nov. 5, 2014
http://www.businessinsider.com/facebook-sees-android-first-app-developer-trend-2014-10?&platform=bi-androidapp

_ Business Insider

Facebook is seeing a trend in Europe of app developers going "Android-first."

Facebook は、ヨーロッパにおけるアプリ開発者の、Android-First へと移りゆく動向を注視している。

That’s significant because for years, Apple’s iOS operating system for iPhone and iPad has been the preferred first stop for any company launching an app. If an app succeeds on iOS, then only later will a company think about making a version for Android. Often months or years later, and sometimes never.

それが、大きな意味を持つのは、この数年にわたり iPhone と iPad で走る Apple の iOS が、あらたなアプリを立ち上げる、あらゆる企業が最初に取り組むプラットフォームとして、不動の地位を維持し続けてきたからである。そして、対象となるアプリ が iOS 上で成功した後にのみ、デベロッパーたちは Android バージョンを考えるというのが常である。多くの場合、それらのアプリの iOS 版と Android 版には、数ヶ月から数年の時間差があり、時には iOS のみというケースもあった。

Stephan Ridgway
Flickr, CC

That’s why Android apps tend to look and feel a bit second-rate compared to the same apps on iPhone — they often are just that. The iOS/Android split is weird because globally 80% of users are on the Android system, yet iOS and its roughly 10% of users are the top priority for developers.

そこに、Android アプリののルック&フィールが、同じアプリの iPhone の二番煎じになりやすい理由があるのだ。そして、実際に、そのようなケースが多々ある。グローバル・ユーザーの 80% が Android システムを利用している一方で、およそ 10% という iOS のシェアが、開発者にとってトップ・プライオリティになっている。 それなのに、iOS と Android のアプリを切り分けるのは、ちょっと奇妙な選択となる。

So it would be dramatic for companies to reverse that trend.

つまり、トレンドが逆転するという、ドラマティックな展開もあり得るのだ。

Yet that is what Facebook is seeing among some companies in Europe, according to Facebook’s Europe, Middle East, and Africa platform director, Julien Codorniou. Developers are beginning to sense that because more people are Android users than Apple users, they’re losing money by working on the smaller iOS platform first, he told Business Insider UK.

しかし、Facebook はヨーロッパにおいて、いくつかの企業の動きを見続けていると、同社の Europe, Middle East, and Africa Platform Director である Julien Codorniou は Business Insider UK に述べている。そして、デベロッパーたちは気付き始めているのだ。Apple ユーザーよりも Android ユーザーの方が多数を占め、また、最初に規模の小さい iOS プラットフォームに対応することで、ビジネス・チャンスを失っていることに。

Historically, Apple has been the preferred platform. Apple’s higher-income users are often more lucrative targets for app advertisers and in-app payments and shopping. It’s also simpler for developers to use, Apple has only one version of iOS running at any one time (the newest one) and the vast majority of Apple users keep their devices updated to the newest version. Android, by contrast, is "fragmented" into several different versions across hundreds of different phones — and all those versions are a headache for developers who must make a separate app tailored for each one.

歴史的にみて、Apple は好ましいプラットフォームだと捉えられている。 Apple のユーザーは高所得者に偏っているため、広告/アプリ/ショッピングを展開する際に、ビジネスのターゲットに成りやすいのである。その一方で、デベロッパーにとっても、取り組みやすい環境となっている。つまり Apple は、常に最新の iOS バージョンのみをプッシュし、大半の Apple ユーザーは最新バージョンにアップデートされたデバイスを手にしている。それとは対照的に、Android は各種のスマホ上の、各種のバージョンとして「断片化」されている。 そして、それらのバージョンごとの、個別アプリを開発する必要性が、デベロッパーにとって頭痛の種となる。

Julien Cordoniou: "People look at the numbers. They want downloads, installs. They know that the monetization is catching up on Android."

But Codorniou told us Facebook has a team of evangelists encouraging Android developers to use Facebook as a way to build and promote their apps: "As of today, I have four guys from my team in Paris talking to Android developers about the greatness of Parse, Facebook login, app links, app events. It’s a very important bet for us."

しかし、Codorniou が言うには、デベロッパーたちが自身のアプリを構築し、プロモートするための手段として Facebook を活用するよう、Android の開発環境を支援するためのエバンジェリスト・チームがあるようだ。そして、 「現時点において、4人で構成されるチームが Paris にある。そして、Parse/Facebook LogIn/App Link/App Event の素晴らしさを、Android デベロッパーたちに説明している。 それは、私たちにとって、きわめて重要な賭けである」と、私たちに語ってくれた。

Wait, Android developers? Android-first, really?

なぜ、Android デベロッパーなのか? ほんとうに、Android-First を考えているのだろうか?

"People look at the numbers," he says. "They want downloads, installs. They know that the monetization is catching up on Android. Of course iOS is the better platform when it comes to monetization, but it’s easier to update your app on Android. There are many people on an Android phone. … The world you described [in which Apple is dominant] was true a year ago, but I see that things are changing."

彼は、「 開発者たちは、数字に注目している。彼らは、数多くのダウンロードとインストールを望んでいる。そして、Android におけるマネタイズが、iOS を捕まえかけていることを知っている。もちろん、マネタイズに関しては、iOS の方が優れたプラットフォームであるが、Android アプリのアップデートも簡単になっているのだ。周知のとおり、Android フォンには、膨大なユーザー数がある。あなた方が、Apple が支配する世界と説明してきたことは、1年前には本当だったが、物事が変化していることを、私は目にしている」と述べている。

"The vision we have with Parse and with the platform in general is to accelerate the time to market. It should not take you six months to develop from iOS to Android."

そして、「Parse と汎用プラットフォームを活用する、私たちのビジョンにより、出荷までの時間が大幅に短縮される。 iOS から Android に切り替わったとしても、その開発のために、6ヶ月も要することなど、あり得ないはずだ」と、彼は続ける。

"There is a pattern coming from Eastern Europe. The Russian developers develop on Android first because of a big audience, and it maybe being easier to develop. They liked the fact that they could submit a new version of the app every day. [With Apple, you have to get each new version of the app approved before it hits the App Store. There is no version-approval system for Android.] This is a trend that I see and I think it is going to accelerate."

最後に、「 Eastern Europe で生まれた、開発のパターンがある。それは、Russian のデベロッパーたちの進め方であり、多数のユーザーがいる Android の優先順位を上げるが、おそらく容易な開発を実現している。彼らは、新しいバージョンのアプリを、毎日のようにサブミットできる状況を好んでいる。Apple の場合には、App Store に出す前に、それぞれのバージョンについて承認を得なければならない。 しかし、Android では、バージョンに関する承認の仕組みは存在しない。そこに、Android が加速している要因があると、私は見ている」と、彼は述べていた。

Do you work at an app developer that switched to go Android first? Contact Business Insider UK at jedwards@businessinsider.com to tell us your story.

ーーーーー

途上国マーケットを支援するための Internet.org を作り、貧しい人々のためにインターネット環境を整備しようとしている Facebook にとって、Android ファーストへの転換は、きわめて整合性の高い戦略となるはずです。 とは言え、Apple 自体に対してはまだしも、iOS エコシステムを構成するデベロッパーには、気遣うことになりそうですね。 また、Facebook の収益の 66% が、モバイル広告からもたらされていることを考えれば、いずれは Android ファーストになっていくのでしょう。 問題は、そのタイミングですが、いつ頃なのでしょうか? とても気になりますね。

ーーーーー

<関連>

Facebook が語るモバイル・チューニングの極意:途上国のインターネットも OK!
Facebook がビッグ・ウェーブに乗った:すでに収益の 66% はモバイルから!
FB+WhatsApp+Instagram のユーザー数は、世界の 1/3 に相当する 22億人だ!
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Instagram が史上最大のマイグレ:200億枚のイメージを AWS から FB へ!
Facebook が買収し続けている特許の内容が、とても興味深い
Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している

Xiaomi が北京から脱出:インターナショナル・ユーザーのデータは 海外 DC へ!

Posted in .Selected, Asia, Data Center Trends, Mobile, Post-PC by Agile Cat on December 5, 2014

Xiaomi Moves Overseas Mobile Phone Data Away From Chinese Servers
http://wp.me/pwo1E-84C

October 28, 2014 
http://www.chinatechnews.com/2014/10/28/21076-xiaomi-moves-overseas-mobile-phone-data-away-from-chinese-servers

_ China Tech News

Hugo Barra, global vice president of Xiaomi, recently issued a statement that claims Xiaomi is moving its international user data from servers in Beijing to U.S. and Singapore.

Xiaomi の Global VP dearu Huge Barra が、同社のインターナショナル・ユーザー・データを、Beijing のサーバーから U.S. および Singapore に移行しているという、ステートメントを発表した。

This is reportedly a response to previous incidents which exposed that Xiaomi smartphones automatically returned global user data to Beijing servers. Chinese telecommunications regulations require Chinese companies to store domestic data on local Chinese servers.

それは、Beijin のサーバーへ向けて、自動的に Xiaomi スマホから送信されていた、グローバル・ユーザー・データの漏洩という、最近の出来事への対応だと伝えられている。China における電気通信法では、同国内のユーザー・データに関しては、China のローカル・サーバーにストアすべきと規制されている。

Is this move by Barra enough to quell security and privacy concerns that a Chinese mobile phone company may be in cahoots with the Chinese government for harvesting global user data?

この Barra のアクションにより、グローバルにおけるユーザー・データを刈り取るために、China の政府とスマホ・メーカーが共謀しているという、セキュリティとプライバシーの懸念は、鎮静化されるのだろうか?

According to Barra the international user data migration aims to improve experience of users all over the world, cut down latency and reduce failure rates. At the same time, it will help the company maintain high privacy standards and comply with local data protection regulations.

Barra の説明によると、今回のインターナショナル・ユーザー·データの移行は、グローバルにおけるユーザー・エクスペリエンスの向上および、レイテンシの低減、障害の回避を目指すものとなる。しかし、それと同時に、高度なプライバシー基準の維持と、それぞれの国々におけるデータ保護規制の遵守にも寄与するはずだ。

Based on Xiaomi’s plans, the company will first migrate their global e-commerce platforms and user data for all international users from Beijing data centers to Amazon AWS data centers in California, U.S. and Singapore, which is expected to be completed at the end of October 2014. It will benefit users in all international markets, including Hong Kong, India, Indonesia, Malaysia, Philippines, Singapore, and Taiwan.

Xiaomi は、今回の計画に基づき、グローバルなコマース・プラットフォームとインターナショナル・ユーザー・データから、全面的な移行を開始する。それは、Beijing のデータセンターから、California, U.S. と Singapore の Amazon AWS データセンターへ向けたものであり、2014年10月末までに完了すると予測されている。 その結果として、Hong Kong/India/Indonesia/Malaysia/Philippines/Singapore/Taiwan などを含む、すべてのインターナショナル・マーケットのユーザーにメリットがもたらされる。

For the second step, Xiaomi will migrate their MIUI services and corresponding data for all international users from Beijing data centers to Amazon AWS data centers in Oregon, U.S. and Singapore, realizing the migration of Mi account, cloud messaging and Mi cloud services. The migration is expected to be completed at the end of 2014.

次のステップで Xiaomi は、すべてのインターナショナル・ユーザーのための、MIUI サービス(カスタム ROM?)と、それに対応するデータを、Beijing のデータセンターから、Oregon, U.S. と Singapore の Amazon AWS データセンターへ移行する。それにより、Mi Account/Cloud Messaging/Mi Cloud Service の移行が達成される。それらは、2014年末までに完了するという。

Finally, Xiaomi plans to improve user experience in emerging markets such as India and Brazil in 2015. Due to the lack of Amazon AWS services in those markets, Xiaomi will cooperate with local data center providers.

最後になるが、Xiaomi が意図しているのは、2015年に急成長が期待される India や Barazil での、ユーザー・エクスペリエンスの向上である。 ただし、それらの国々では、Amazon AWS のデータセンターが欠落しているため、Xiaomi 自身がローカルのデータセンター・プロバイダと協調していくことになるだろう。

ーーーーー

とても興味深い展開ですね。これまで、すべてを呑み込んできた中国市場から、今度は外へと飛び出す企業が出てきたわけです。 この背景には、いわゆるバック・ドア問題が有ったわけですが、Xiaomi としては潔白を証明したいのでしょうし、北京政府としても同社のグローバル化を妨げることが、中国のためにならないと判断しているのでしょう。 GOOD ですね!

ーーーーー

<関連>

中国の Xiaomi App Store が、10億ダウンロード を 1年で達成
Xiaomi の Mi Pad がスゴイ! Retina + Tegra K1 で $240 だ!
スマホ 下克上 _1 : 中国では Xiaomi が Samsung を追い抜く
Apple と China Telecom :中国人ユーザーのデータは、中国本土の DC へ
Apple と China Mobile が合意 : 7億人の中国市場に iPhone がリーチする!

欧州からのチャレンジ:Interoute の 仮想 DC ゾーンは London -New York を 68ms で接続する!

Posted in .Selected, Data Center Trends, Hybrid by Agile Cat on December 3, 2014

Europe’s most distributed cloud comes to America
http://wp.me/pwo1E-84q
Interoute Virtual Data Centre takes its IaaS cloud platform global
London, 18 June, 2014
http://www.realwire.com/releases/Europes-most-distributed-cloud-comes-to-America

Interoute, owner operator of Europe’s largest cloud services platform, has today launched a new Interoute Virtual Data Centre (VDC) zone in New York in a move that will further expand its cloud services globally. With latency as little as 68ms[1] between Interoute’s London and New York VDC zones, users of Interoute’s IaaS (Infrastructure as a Service) platform have the benefit of a low latency, globally distributed cloud at their fingertips.

Europe 最大のクラウド・サービス・プラットフォームを所有する Interoute だが、今日のアナウンスメントにより、新たな Interoute Virtual Data Centre (VDC) ゾーンを New York に立ち上げ、そのクラウド・サービスをグローバルへと向けて、さらに拡大していくことを明らかにした。London と New York の Interoute VDC ゾーンを、わずか 68ms [1] で接続することで、Interoute IaaS のプラットフォームのユーザーたちは、低レイテンシのメリットを享受しながら、グローバル・スケールの分散クラウドを容易に展開できる。

[1] 68ms measured with a Ping test from the Interoute VDC London zone to the Interoute VDC New York zone conducted 6/6/2014.

Interoute CTO, Matthew Finnie, commented, "European developers and businesses with their sights set on the US need more than just a data centre to effectively gain a foothold there. They need a networked cloud to give them the speed and performance to compete. Interoute VDC provides massively distributed cloud architecture, globally, and we’ve thrown in the network for free. Opening our first US zone in New York is part of Interoute’s expansion beyond our European base, following the launch of our Hong Kong zone earlier this year.”

Interoute の CTO である Matthew Finnie は、「 US マーケットを視野に入れる、Europe の開発者や企業は、そこに足掛かりを得るだけの、単に効率だけを考えたデータセンター以上のものを必要としている。そこで必要となるのは、充分なスピードとパフォーマンスを提供する、ネットワーク化されたクラウドである。Interoute の VDC は、大規模な分散クラウド·アーキテクチャをグローバルに提供しており、また、その顧客たちはネットワークを自由に活用できる。最初の US ゾーンを New York にオープンすることは、Europe をベースにする Interoute の拡大政策の一部であり、年初の Hong Kong に続くものだ」と、コメントしている。

Interoute has VDC zones in eight countries across the globe, with six in Europe. Interoute VDC is built into the foundations of Interoute’s international MPLS and internet backbone, a key part of the internet in Europe, bringing businesses closer to their customers. The network extends beyond the data centre, providing connectivity to customers worldwide.

Interoute は、グローバルで 8カ国に VDC ゾーンを持ち、そのうちの 6つが Europe に置かれている。Interoute の VDC は、その International MPLS と Internot Backborn の上に構築されており、また、それらが Europe のインターネットにおける主要な部分を形成するため、企業と顧客の距離を縮めることが可能になる。 このネットワークは、最寄りのデータセンターの先へと伸びているため、顧客とのコネクティビティをワールドワイドで実現できる。

Interoute VDC customers are given access to the entire network of computing resource across the platform and can choose to create custom compute and storage in any location globally. Customers can also use quick deployments from the Interoute CloudStore to instantly create their machines through a series of simple menu-driven options. Interoute VDC offers the option of public, private (MPLS) or hybrid cloud services as standard, defined at the network level.

Interoute VDC の顧客は、このプラットフォームを横断するかたちで、コンピューティング・リソース・ネットワーク全体へのにアクセス権を与えられ、グローバルにおける任意のロケーションで、カスタムなコンピューティングとストレージを選択/作成することが可能となる。また、顧客たちは、一連のメニュー・オプションを介して、Interoute CloudStore から自身のマシンを作成し、瞬時にディプロイできる。そして、Interoute VDC では、Public/Private(MPLS)/Hybrid の各オプションを選択できるが、それらも、ネットワーク·レベルのスタンダードとして定義されている。

Customers have the flexibility to move and store data where it is needed, whether that is in Europe, North America or Asia. This high level of location density and automation means customers can restrict their data to a single location or distribute it rapidly across new geographies and markets to provide a faster end-user experience by minimising latency in their cloud architecture and  help ensure business compliance with relevant data legislation. Because the computing power of Interoute VDC is built into the network, data transfer between international Interoute VDC zones is free.

顧客たちは、それが Europe/North America/Asia であろうが、必要とされるロケーションへデータを移動して、ストアするという柔軟性を手にする。この、ロケーションに関するハイ・レベルな密度設定と自動化により、ビジネスとして取り組む新たな地域や市場で、分散されたデータをエンドユーザーたちに迅速に提供することが可能になる。 その一方で、単一のデータを集約するという制約を設けることも、もちろん可能となる。そして、それらを実現する要因として、このクラウド·アーキテクチャにおける最小化されたレイテンシと、適切なデータ法規を用いたビジネス・コンプライアンスの支援という側面が挙げられる。 その理由は、Interoute VDC のコンピューティング・パワーが、そのネットワークに組み込まれたものであり、International Interoute VDC ゾーン間でのデータ転送が無料になるところにある。

Jon Collins, Principal Advisor at Inter Orbis & Analyst at GigaOm Pro, commented: "Much of the focus in recent years has been on Infrastructure as a Service aspects of cloud computing – that is, how to make best use of the vast pools of hosted, virtualised servers now available. The benefits of this approach are widely appreciated and give us a direction of travel for future development. As our understanding has increased, so has the awareness that the traditional approach to cloud computing of "somewhere" in the cloud, without taking physical limitations of transmission into account, limits the potential scope and sophistication of applications. The next phase in development is total integration, incorporating networking constraints and opening the door to a massively distributed approach to computing. This shift will see increasing emphasis on the network as a differentiator, as use of the cloud continues to grow.”

GigaOm Pro において、Inter Orbis & Analyst の Principal Advisor である Jon Collins は、「 近年におけるクラウド·コンピューティングでは、大半の注目を IaaS が集めている。つまり、ホストされている仮想化されたサーバーの広大なプールを、その時々に最大限に活用するための方式が論じられている。このアプローチにおけるメリットは広く認識されており、また、将来のデプロイメントに関する方向性を与えてくれる。そして、私たちの理解が高まるにつれて、このクラウド・コンピューティングに対する伝統的なアプローチは、クラウド内の「どこか」という意識をもたらすようになる。しかし、そこには、考慮すべき物理伝送の制限や、アプリケーションの範囲と精度に関する潜在的な制限などは存在しない。次に開発すべきフェーズは、ネットワークに制約を取り込みながら、大規模コンピューティングへ向けた分散アプローチのドアを開くための、トータルなインテグレーションである。そのシフトにより、差別化要因としてのネットワークと、クラウド利用を継続して拡大させるネットクークの、重要性が増していくだろう」と、述べている。

ーーーーー

以前にも、この Interoute の香港 Virtual Data Centre (VDC) に関する抄訳をポストしましたが、アジアだけではなく北米をも含む 仮想データセンター・ゾーンに拡大しているようですね。 とは言え、その他の情報は少なく、以前としてナゾに包まれた Interoute ですが、このところの、たとば Google をめぐる EU の対応などをみても、そう簡単にはアメリカのクラウドには乗ってこないのかもしれませんね。 また、London と New York の Interoute VDC ゾーンを、わずか 68ms で接続といのもスゴイです。引き続き、この Interoute の動きは追いかけて行きたいと思っています。

ーーーーー

<関連>

ヨーロッパを 仮想 DC でカバーする、謎の Interoute クラウドが香港に進出!
DigitalOcean が シンガポールに上陸する! それを 支えるのは Equinix だ!
DigitalOcean+CoreOS+Docker:このフレッシュ・トリオが 大変革を引き起こす!
これが ウワサの DigitalOcean だ! AWS を上回るペースでサーバーを増している!

Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!

Posted in .Selected, DevOps, Facebook, Mobile, Network, Post-PC, Strategy by Agile Cat on December 2, 2014

How Facebook Makes Mobile Work at Scale for All Phones, on All Screens, on All Networks
http://wp.me/pwo1E-84k
September 22, 2014 – ImageTodd Hoff
http://highscalability.com/blog/2014/9/22/how-facebook-makes-mobile-work-at-scale-for-all-phones-on-al.html

When you find your mobile application that ran fine in the US is slow in other countries, how do you fix it? That’s a problem Facebook talks about in a couple of enlightening videos from the @scale conference. Since mobile is eating the world, this is the sort of thing you need to consider with your own apps.

アメリカ国内では快適に走るモバイル・アプリが、その他の国では遅くなると分かったとき、どのように修正すればよいのだろう?それは、@scale conference における何本かのビデオで、Facebook が指摘している問題である。そして、この世界をモバイルが呑み込んで以来、あらゆるアプリにおいて考察すべき、ある種の問題でもある。

<関連> Facebook アプリ:Push + Delta + Thrift でモバイル帯域を 40% も削減!

In the US we may complain about our mobile networks, but that’s more #firstworldproblems talk than reality. Mobile networks in other countries can be much slower and cost a lot more. This is the conclusion from Chris Marra, Project Manager at Facebook, in a really interesting talk titled Developing Android Apps for Emerging Market.

アメリカにおいても、私たちはモバイル・ネットワークに文句を言うだろうが、Twitter の #firstworldproblems で語られていることが真実だ。その他の国々におけるモバイル・ネットワークは、はるかに遅いものであり、また、より多くの費用がかかる。以下に示すのは、Developing Android Apps for Emerging Market という興味深いタイトルの講演の中で、Facebook の Project Manager である Chris Marra が結論づけたものである。

Facebook found in the US there’s 70.6% 3G penetration with 280ms average latency. In India there’s 6.9% 3G penetration with 500ms latency. In Brazil there’s 38.6% 3G penetration with more than 850ms average latency.

Facebook が調べた結果によると、アメリカにおける 3G の浸透率は 70.6% であり、レイテンシは 280ms である。それがインドとなると、3G の普及率は 6.9% であり、レイテンシ は 500ms になる。そしてブラジルの場合は、38.6% と 850ms だ。

Chris also talked about Facebook’s comprehensive research on who uses Facebook and what kind of phones they use. In summary they found not everyone is on a fast phone, not everyone has a large screen, and not everyone is on a fast network.

さらに Chris は、Facebook のユーザーである人々および、そこで用いられるスマホに関して、同社が実施している包括的な調査についても話してくれた。要約すると、誰もが高性能のスマホを使い、大きなスクリーンを持ち、高速のネットワークを使用できると思ったら、それは大きな間違いということだ。

It turns out the typical phone used by Facebook users is from circa 2011, dual core, with less than 1GB of RAM. By designing for a high end phone Facebook found all their low end users, which is the typical user, had poor user experiences.

その結果として、Facebook ユーザーが使用する典型的なスマホは、2011年頃のモデルから始まり、Dual-Core の CPIU を搭載し、RAM は 1GB 以下ということが分かってきた。 ハイエンド・スマホに合わせてデザインしてきた Facebook は、ローエンドのデバイスを持つユーザーが大半であり、そのすべてがプアなユーザー・エクスペリエンスを持つことを理解した。

For the slow phone problem Facebook created a separate application that used lighter weight animations and other strategies to work on lower end phones. For the small screen problem Facebook designers made sure applications were functional at different screen sizes.

Facebook は性能の低いスマホのために、軽いアニメーションなどの戦略を適用するために、使別のアプリを作成した。また、同社のデザイナーたちは、小さなスクリーンという問題に対処するために、異なる画面サイズであっても、機能的にアプリが振る舞えるようにしていった。

Facebook has moved to a product organization. A single vertical group is responsible for producing a particular product rather than having, for example, an Android team try to create all Android products. There’s also a horizontally focussed Android team trying to figure out best practices for Android, delving deep into the details of what makes a platform tick.

つまり、Facebook 自身が、プロダクトを構築するための組織に転身しているのだ。例を挙げるなら、すべての Android プロダクツを、そのためのチームが開発するのではなく、特定のプロダクトを構築するために、垂直方向へと問題を掘り下げていくグループに責任が振り分けられている。ただし、プラットフォームに適合するものを詳細まで踏み込み、Android のためにベスト・プラクティスを把握していく、水平方向に焦点を当てた Androidチームも存在する。

Each team is responsible for the end-to-end performance and reliability for their product. There are also core teams looking at and analyzing general performance problems and helping where needed to improve performance.

そして、個々のチームが自身のプロダクトに関して、その性能と信頼性を隅から隅まで担当することになる。さらに、コアとなるチームが、全体的なパフォーマンスの問題を分析し、それを向上させるために必要な支援を行う。

Both core teams and product teams are needed. The core team is really good at instrumentation and identifying problems and working with product teams to fix them. For mobile it’s important that each team owns their full product end-to-end. Owning core engagement metrics, core reliability, and core performance metrics including daily usage, cold start times, and reliability, while also knowing how to fix problems.

コアとプロダクトの、双方のチームが必要とされている。コア・チームは、適切に測定を行い、問題を特定し、それらを修正するために、プロダクト・チームと協調していく。モバイル開発において重要な事は、それぞれのチームが自身のプロダクトについて、隅から隅まで責任を負うことである。また、コアとしての共有メトリクス/信頼性/性能の指標を確立し、そこにアプリを立ち上げたときや、連続して使用したときの、信頼性を加える一方で、問題の解決方式を認識していく。

To solve the slow network problem there’s a whole other talk. This time the talk is given by Andrew Rogers, Engineering Manager at Facebook, and it’s titled Tuning Facebook for Constrained Networks. Andrew talks about three methods to help deal with network problems: Image Download Sizes, Network Quality Detection, Prefetching Content.

低速のネットワークに関連する問題を解決するという、包括的なテーマがある。今回は、Facebook の Engineering Manager である Andrew Rogers の、Tuning Facebook for Constrained Networks というタイトルが付けられたトークを紹介したい。Andrew の話は、ネットワークに関連する問題を解決する、Image Download Sizes/Network Quality Detection/Prefetching Content という、3つの方法論に集約される。

Overall, please note the immense effort that is required to operate at Facebook scale. Not only do you have different phones like Android and iOS, you have different segments within each type of phone you must code and design for. This is crazy hard to do.

総論として、Facebook のスケールで運用するには、膨大な労力が要求される点に注意してくほしい。そこには、Android と iOS といったモバイルの種別だけではなく、それぞれのデバイスごとのセグメントがあり、それに対してコーディングしていく必要があるのだ。それを実践していくことは、まさしくクレイジーである。

Reducing Image Sizes -  WebP saved over 30% JPEG, 80% over PNG

  • Image data dominates the number bytes that are downloaded from Facebook applications. Accounts for 85% of total data download in Facebook for Android and 65% in Messenger.
  • イメージ・データは、Facebook アプリにダウンロードされる、バイトの大半を占める。 Android 用の Facebook においては、全ダウンロード・データの 85% を占め、Messenger では 65% を占めている。
  • Reducing image sizes would reduce the amount of data downloaded and result in quicker downloads, especially on high latency networks (which we learned were typical).
  • イメージ・サイズを削減すれば、ダウンロードされるデータの量が低減され、より迅速なダウンロードが達成されるだろう。それは、高レイテンシのネットワークにおいて、特に有効な手段となる(そこから、私たちは学んだ)。
  • Request an appropriate image size for the viewport
  • 表示環境にあわせた、適切なサイズのイメージを要求する。
  • Resize on the server. Don’t send a large image to the client and then have the client scale the image down to a smaller size. This wastes a lot of bandwidth and takes a lot of time.
  • サーバー上で、イメージのサイズを変更する。クライアントへ向けて大きなイメージを送信し、クライアント側でイメージを小さくするという手法を取ってはならない。 そのような方式だと、大量の帯域幅を無駄にし、長時間を要することになる。
  • Send a thumbnail (for profile pictures) and a small preview image (this is seen in the newsfeed), and then a full image (seen in photo stories) when a user asks to zoom in it. A low-res phone may never need a full image. Most of the time a thumbnail and a small preview is all you need.
  • サムネイル(画像のサムネイル)と、小さなプレビュー・イメージ(例 NewsFeed)を送信し、ユーザーが拡大を要求したときに、フル・イメージを送信する(例 Photo Story)。低解像度のスマホの場合は、フル・イメージが不要かもしれない。また、大半のケースにおいて、サムネイルとプレビューで、すべての要求に応えられる。
  • Significant savings. Scaling a 960 pixel image that is 79KB is size to 240 pixels wide yields a 86% size reduction, to 480 pixels is a 58% size reduction, to 720 pixels is at 23% size reduction.
  • データ転送量を、大幅に削減できる。たとえば、960 pixel スケールのイメージは 79KB であるが、240 pixel なら 86%、480 pixel なら 58%、720 pixel なら 23% の削減が達成される。
  • With screen sizes becoming larger scaling images isn’t as effective as it used to be. Still worth doing, but the payoff isn’t as much.
  • スクリーン・サイズより大きなイメージを、効果的に利用できるケースはほとんど無い。何らかの価値があるかもしれないが、その代償は大きい。
  • Change the image format
  • イメージ・フォーマットの刷新
  • 90% of images sent to Facebook and Messenger for Android use the WebP format.
  • Android 用の Facebook および Messenger では、90% のイメージで WebP フォーマットが用いられている。
  • WebP format released by Google in 2010.
  • WebP フォーマットとは、Google が 2010年にリリースしたものである。
  • WebP saves 7% download size over JPEG for equivalent quality.
  • WebP は、同品質の JPEG に対して、7% のサイズ圧縮を実現にする。
  • WebP saved over 30% download size over JPEG by tuning quality and compression parameters with no noticeable quality differences. A big savings.
  • WebP は、画質チューニングと圧縮パラメータにより、JPEG に対して 30% のデータ削減を可能にするが、視覚的な劣化は生じない。 それにより、ダウンロード・サイズを大幅に削減できる。
  • WebP also supports transparency and animation, which is useful for their Stickers product.
  • さらに WebP は、透過性とアニメーションをサポートするため、Sticker などのプロダクトに適している。
  • WebP saves 80% over PNG.
  • WebP は PNG の 80% に、データ量を低減する。
  • For older versions of Android the images are transported using WebP but transcoded on the client to JPEG for rendering on the device.
  • Android の古いバージョン用のイメージは、WebP を使って転送されるが、レンダリングのためにクライアント上で JPEG に変換される。

Network Quality Detection – Adjust Behavior to Network Quality

  • On the same network technology 2G, 3G, LTE, WiFi, connections speeds in the US were 2-3x faster than in India and Brazil.
  • 2G, 3G, LTE, WiFi といった、それぞれのネットワーク・テクノロジーにおいて、India や Brazil に対して U.S. は、2倍〜3倍の接続速度を有する。
  • LTE is often faster than WiFi, so you can’t just base the connection speed on technology.
  • 大半のケースにおいて、LTE は WiFi より高速であるため、テクノロジーの接続速度を論拠にはできない。
  • Built into the client the ability to:
  • Measure throughput on all large network transfers
  • 以下の機能を、クライアント内に作り込む:
  • 大規模ネットワークを通過する際のスループットを測定する。
  • Facebook servers provide a Round Trip Time (RTT) estimate in the HTTP header in every response
  • Facebook のサーバーは、すべてのレスポンスにおける HTTP ヘッダー内で、Round Trip Time (RTT) 推定値を提供している。
  • The client maintains a moving average of throughput and RTT times to determine network quality.
  • そのため、クライアントは、ネットワーク品質を判断するために、変動するスループットと RTT 時間の、平均値を保持できる。
  • Connections are bucketized into the following groups: Poor is < 150kbps. Moderate is 150-600kbps. Good is 600-2000kbps. Excellent is > 2000kbps.
  • 接続スピードは、以下のグループに分類される:Poor 150kbps 以下:Moderate 150〜600kbps:Good 600〜2000kbps:Excellent 2000kbps 以上。
  • Feature developers can adjust their behavior depending on the connection quality.
  • それらの接続品質に応じて、それぞれの機能の振る舞いを適正化していく。
  • Some possible responses based on quality:
  • その通信品質に基づき、いくつかの対策がある:
  • Increase/decrease compression.
  • Issue more/fewer parallel network requests. Don’t saturate the network.
  • 圧縮比の増減。
  • 並列ネットワーク・リクエストの増減。それにより、ネットワークをサチらせない。
  • Disable/enable auto-play video. Don’t cause more traffic on slow networks.
  • ビデオ自動再生の ON/OFF。 低速ネットワークでは、大量のトラフィックを要求しないようにする。
  • Pre-fetch more content.
  • より多くのコンテントを、プリ・フェッチする。
  • A tool developed at Facebook called Air Traffic Control supports the simulation of different traffic profiles. Each profile can be configured: bandwidth, packet loss, packet loss-correlation, delay, delay correlation, delay jitter. Extremely helpful in finding unexpected behaviour on slow networks.
  • Facebook では、内製のツールである Air Traffic Control により、各種のトラフィック・プロファイルのシミュレーションを行なっている。それそれのプロファイルは、帯域幅/パケット損失/パケット損失相関/遅延/遅延相関/遅延ジッタなどで構成されている。低速のネットワーク上で、予期できない動作などを見つけるのに、きわめて便利である。
  • There are buckets for videos, but not sure what they are.
  • ビデオ・トラフィックに関しては、その内容が不明である。

Prefetching Content

  • Issuing network requests for content ahead of when the content is actually needed on the device.
  • 実際にデバイスでコンテントが必要になる前に、ネットワーク・リクエストを発行する。
  • Prefetching is especially important on networks with high latency. Waiting to issue a download request for an image the user will be looking at a blank screen.
  • プリ・フェッチングは、とりわけ高レイテンシのネットワークで重要となる。イメージをダウンロードするリクエスト発行を待っているのでは、ユーザーにブランクの画面を見せることになる。
  • Issue network requests for feeds early in the app startup process so the data will be present when the feed is displayed to the user.  The download can occur in parallel with other initialization tasks.
  • アプリ起動プロセスで、フィードの先頭へのネットワーク・リクエストが発行されていれば、ユーザーに対して表示するときに、すでにフィードの準備が整うことになる。このダウンロードは、他のイニシャル・タスクと並行して、引き起こすことが可能である。
  • Keep a priority queue of network requests. Don’t block foreground network requests on background network requests or the user won’t see the data they are currently interested in.
  • ネットワーク・リクエストの、プライオリティ・キューを維持する。バックグラウンドのネットワーク・リクエストにより、フォアグラウンドのネットワーク・リクエストをブロックしてはならない。また、ユーザーが興味を持っているデータを、見せないような状況も避けるべきだ。
  • Monitor for overfetching and excess consumption of device resources. Over fetching could fill up the disk or waste a lot of money on the user’s data plan.
  • 過剰なフェッチングとデバイス·リソース消費をモニタリングする。フェッチングが行き過ぎると、全体的なディスク容量が不足し、また、データ・プランによっては、ユーザーのコストを増大させる。

Miscellaneous

  • Client uploading to servers. The idea is to send fewer bytes over the wire from the client to the server, which means resizing images on the client side before they are sent to the server. If an upload fails retry quickly. It’s usually just a problem in the pipe.
  • クライアントからサーバーへのアップロードに関しても、サーバーに送信する前にクライアント側でイメージをリサイズし、データ転送量を低減すべきである。アップロードに失敗した場合は、速やかに再試実行する。 一般的に、この問題はパイプ内のもとと認識すべきだ。
  • There are 20 different APKs (Android application package) for the Facebook app, cut by API level, screen size, and processor architecture.
  • Facebook アプリ用として、20種類の APK(Android Application Package)が存在する。 具体的に言うと、API レベルや、スクリーン・サイズ、プロセッサ・アーキテクチャなどにより分類されている。

Related Articles

Update: Instagram Improved Their App’s Performance. Here’s How.

ーーーーー

この長い記事を訳しながら、似ているなぁと思い始めてきたのが、Google の Street View 撮影部隊の話です。 どちらも、データセンターに積み上げたコンピューティング・パワーや、優秀な頭脳から生み出されるアルゴリズムでは解決の出来ない、労力と根気の世界の話です。 とは言え、このような労働集約型の作業に、膨大なリソースを投じるには、その正当性を裏付けるだけのストラテジーが必要です。 言い換えれば、途上国のマーケットに賭ける、Facebook の強い思いが生み出した唯一無二の方法論が、そこにあるはずなのです。 そして、そのノウハウを、こうして開示してくれる Facebook と、分かり易く整理してくれた Todd Hoff さんに感謝です。すばらしい!

ーーーーー

<関連>

FB+WhatsApp+Instagram のユーザー数は、世界の 1/3 に相当する 22億人だ!
Facebook の Graph API がアップデートされ、AD API も強化されたようだ!
Instagram が史上最大のマイグレ:200億枚のイメージを AWS から FB へ!
Facebook が買収し続けている特許の内容が、とても興味深い
Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している

DigitalOcean+CoreOS+Docker:このフレッシュ・トリオが 大変革を引き起こす!

Posted in .Chronicle, .Selected, Container, Digital Ocean by Agile Cat on November 22, 2014

Hot cloud DigitalOcean throws its support behind the Docker-friendly CoreOS operating system
http://wp.me/pwo1E-82z
September 5, 2014 – Jordan Novet
http://venturebeat.com/2014/09/05/hot-cloud-digitalocean-throws-its-support-behind-the-docker-friendly-coreos-operating-system/

_ VB

Cloud providers — those companies that store remote data — are coming around to welcome a new kind of operating system, one that updates itself not unlike Google Chrome browser. CoreOS, the fledgling startup behind this operating system, today announced that the OS can now be set up with a mouse click on the fast-growing DigitalOcean cloud.

クラウド·プロバイダーとは、顧客のデータをリモートにストアする企業であるが、そんな彼らが、Google Chrome ブラウザとは異なる方式で自身をアップデートする、ある種の新しいオペレーティング・システムを歓迎し始めている。それが CoreOS であるが、このオペレーティング・システムを支えるホットなスタートアップの発表によると、急成長している DigitalOcean クラウド上でも、マウス・クリックだけで設定が完了するようになったようだ。

Image Credit
DigitalOcean

The development points to the increasing acceptance of containers that wrap up application code and can be moved from one server environment to another with no tinkering. The startup Docker released its container technology under an open-source license last year and has accelerated the adoption of containers as an alternative to virtualization software for running multiple applications on each physical server.

それらを用いた開発のポイントは、アプリケーション·コードをラップするコンテナを受け入れ易くするところにあり、また、作成されたコンテナが、なんの苦労も必要とせずに、複数のサーバー環境間を渡り歩けるようにするところにある。そして、もう1つのスタートアップである Docker は、このコンテナ・テクノロジーを昨年に、オープンソース・ライセンスの下でリリースしており、仮想化ソフトウェア代替手段としてコンテナの採用を加速している。 つまり、それにより、各種の物理サーバー上で実行が可能な、大量のアプリケーションを生み出しているのである。

CoreOS builds on top of Docker, by enabling developers to shoot their applications inside Docker containers across scores of physical servers. Google and Rackspace have partnered with CoreOS to make it possible to easily set up the Linux-based operating system on their respective cloud infrastructures. It’s also possible to boot CoreOS on the market-leading public cloud, Amazon Web Services. And with smaller but trendy DigitalOcean hopping aboard, CoreOS could become more common for applications born in the cloud.

Docker 上に構築される CoreOS は、物理サーバー間の線引を超えていく Docker コンテナの内側に、自身のアプリケーションを詰め込みたい、デベロッパーたちの思いを実現していく。すでに GoogleRackspace は、CoreOS に関する提携をスタートしており、それぞれのクラウド・インフラ上で、この Linux ベース OS の設定を容易にするために取り組んでいる。さらに言えば、このマーケットをリードする、パブリック・クラウドである Amazon Web Services 上でも CoreOS を起動できる。そして今回、規模は小さくても、ホットでトレンディな DigitalOcean が乗ってきたことで、クラウド・ネイティブなアプリケーションにとって、CoreOS が共通項となる可能性が生じてきた。

Now CoreOS faces the grand challenge of convincing companies to run its operating system in their on-premises data centers and become a standard like Red Hat.

CoreOS にとって、現時点における大きなチャレンジとは、使い慣れた OS をオンプレミスのデータセンターで運用しているエンタープライズたちを説得し、Red Hat のようなスタンダードとして、自らのポジションを位置づけていくことである。

The recent funding round should help in that affair, along with CoreOS’ acquisition of Quay for storing private Docker files. Stay tuned to see what happens next on “The CoreOS Revolution.”

最近のファンド・ラウンドにおける資金調達は、プライベートに Docker ファイルをストアする Quay を、CoreOS が買収するという戦略を推進するはずだ。“The CoreOS Revolution” は、次に何を引き起こすのだろうか? 引き続き、注目していきたい。

ーーーーー

DigitalOcean と、Core OS と、Docker という組み合わせですが、ほんの数年前には、どれとして、この世に存在していなかったという、超フレッシュなトリオということになります。世の中の常として、大規模なプロダクトやサービスは、基本は変えずに周囲を補強することで進化していきます。 しかし、それらとて、テクノロジーの海に浮かぶ小舟であり、新たな大波に乗って登場してくるスタートアップたちに、時として本質論で厳しく攻め立てられていきます。 なんというか、大きな潮流の変化を感じるトピックですね。

ーーーーー

<関連>

DigitalOcean:AWS を上回るペースでサーバーを増し、ビヨンセ様の夢もかなえる!
DigitalOcean が シンガポールに上陸する! それを 支えるのは Equinix だ!
Digital Ocean が IPv6 の完全サポートを発表
CoreOS:足し算から引き算へと、Linux ディストリビューションを再編する
Docker によるアプリのパッケージ化は、すでに大きな実績を残し始めている!

 

Microsoft の決断:フル .NET サーバー・コア・スタックをオープンソース化する!

Posted in .Chronicle, .Selected, Microsoft, Strategy by Agile Cat on November 13, 2014

Microsoft makes full .NET server-side core stack open source
http://wp.me/pwo1E-81h
By Juha Saarinen on Nov 13, 2014 6:47 AM
http://www.itnews.com.au/News/397803,microsoft-makes-full-net-server-side-core-stack-open-source.aspx

_ it news

Enables .NET to run on Apple OS X and Linux.

Microsoft today said the full .NET server core stack will be open sourced and expanded to run on Linux and Apple OS X, removing the requirement to use WIndows for the popular development platform.

今日、Microsoft は、Full .NET サーバー・コア・スタックをオープンソース化すると発表した。 つまり、ポピュラーな開発プラットフォームである Windows を使用するという要件を排除し、Linux や Apple OS X の上で動作するよう拡張していくことになる。

Soma Somasegar, Microsoft’s developer division vice president said the open-sourcing will include the ASP.NET 5 framework for building websites, as well as the full .NET runtime and framework itself.

Microsoft の Developer Division VP である Soma Somasegar は、このオープンソース化には、Web サイト構築の ASP.NET 5 Flamework だけでなく、Full .NET のランタイムおよびフレームワーク自体が含まれると述べている。

The .NET Core is a subset of the .NET framework and they share key components such as the just-in-time compiler and the Strings and List types, Microsoft said.

この .NET Core は、.Net Framework のサブセットであり、Just-In-Time Compiler や Strings and List types といった、主要コンポーネントも共有されると、Microsoft は述べている。

However, .NET Core was specifically created to become open source as well as cross-platform.

ただし、.NET Core は、オープンソース化されるだけでなく、明確なクロス・プラットフォーム化のために構築されている。

Somasegar said Microsoft’s aspiration is to have developers at any level, from hobbyists to commercial coders, given access to platforms such as Visual Studio, .NET, the Azure cloud and other resources.

Somasegar の発言によると、Microsoft が熱望するのは、プロのコーダーからホビーストにいたるまで、あらゆるレベルのデベロッパーに利用してもらうことであり、また、Visual Studio/.NET/Azure Cloud といった、各種のプラットフォームにアクセスしてもらうことである。

Today’s announcement follows the April creation of the .NET Foundation by Microsoft, which saw a slew of tools and projects including the Roslyn compiler being released as open source.

今日の発表は、この 4月に Microsoft により設立され、Roslyn コンパイラを含むツールやプロジェクトを、オープンソースとしてリリースした、.NET Foundation に続く出来事となる。

The company also took steps to assuage developers that Microsoft would not pursue intellectual property rights for the open source projects.

さらに Microsoft は、このオープンソース・プロジェクトに関する知的財産権は継続されないとし、デベロッパーたちの警戒心を和らげるための措置を取っている。

Microsoft will release the .NET Core server stack under a MIT open source license and Somasegar said there will be an explicit patent promise issued, to clarify users’ patent rights to .NET. Other projects use the Apache 2 license, with documentation released under Creative Commons Attribution 4.0.

Microsoft は、MIT オープンソース・ライセンスの下で、この .NET Core サーバー·スタックをリリースする予定だ。 そして Somasegar は、ユーザーであっても .NET に関連する特許を保持できるという、知的財産権に関する明確な考えを述べている。その他のプロジェクトは、Apache 2 ライセンスが適用され、また、ドキュメントに関しては Creative Commons Attribution 4.0 が適用されるという。

A code repository for .NET projects has been set up on Github. The Visual Studio integrated development environment (IDE), highly rated by coders, will also be opened up, Somasegar said.

また、.NET プロジェクトに関するコード・リポジトリは、Github 上に開設される。 そして、コーダーたちが高く評価する Visual Studio IDE(integrated development environment)もオープン化されると、Somasegar は述べている。

Microsoft has also released a new Visual Studio Community 2013 edition that Somasegar said is a free, fully-featured version of the paid-for IDE. It can be used for free as long as that use is limited to non-enterprise application development.

Microsoft は、最新の Visual Studio Community 2013 Edition 版を、有償の IDE としてリリースしているが、Somasegar の発言によると、エンタープライズ・アプリケーションの開発を除いて、無償で使用できるようになる。

Previews of the upcoming Visual Studio 2015 and .NET 2015 tools for cross-platform mobile and cloud development were also floated by Somasegar, along with a new release management service and deployment projects utility.

これから登場してくる、クロス・プラットフォームでモバイルとクラウドに対応する、Visual Studio 2015 および .NET 2015 や、それに関連する、新しいリリース・マネージメント・サービスや、デプロイメント・プロジェクト・ユーティリティも、この Somasegar の発言により流動的になってきた。

Developers targeting Google’s Android mobile operating system can now use the x86 based Visual Studio Emulator for Android which is part of Visual Studio 2015, Microsoft said.

Google の Android モバイル OS をターゲットにする開発者も、Visual Studio 2015 の一部として取り込まれ、x86 ベースの Visual Studio Emulator for Android  を使用ができるようになると、Microsoft は述べている。

Update 4 for the current Visual Studio 2013 IDE was also released today, with features such a tool to access graphics processors.

現行の Visual Studio 2013 IDE に関する Update 4 は、グラフィックス·プロセッサにアクセスするためのツールなどと共に、今日にリリースされる。

ーーーーー

とにかく、Welcome です! これで、ライセンスに縛られることなく、Microsoft のサーバー・サイド・プロダクトを使えるようになるので、ユーザーにとって大きな安心感がもたらされることになります。 そして、Microsoft 自身も Windows に制約されることもなく、あらゆるプロダクトを広範囲におよぶプラットフォームに提供していけます。 利用する側も、供給する側も、誰もがハッピーな結果につながるはずです!

ーーーーー

<関連>

Microsoft と IBM が、きわめて広範囲におよぶ、クラウドの提携を発表!
SingTel と TelecityGroup は、インターネット非依存で Azure 接続を実現する
Microsoft への提言:Red Hat を買収して クラウドを強化したら どうだろう?
2015年の Android は、Windows の4倍の勢力に成長する:Gartner
Windows XP のサポートが終わるが、あの緑の草原も、いまはブドウ畑に・・・

 

%d bloggers like this: