Agile Cat — in the cloud

Facebook 第四艦隊 Iowa DC が、ネットワーク・アーキテクチャを刷新して出撃!

Posted in .Selected, Data Center Trends, Facebook, Network, Open Compute by agilecat.cloud on February 19, 2015
Facebook Launches Iowa Data Center With Entirely New Network Architecture
Yevgeniy Sverdlik – November 14, 2014
http://www.datacenterknowledge.com/archives/2014/11/14/facebook-launches-iowa-data-center-with-entirely-new-network-architecture/
 
DC-Knowledge.png
 
Facebook announced the launch of its newest massive data center in Altoona, Iowa, adding a third U.S. site to the list of company-owned data centers and fourth globally.
 
Facebook は、最新の大規模データセンターを、Altoona, Iowa で立ち上げたと発表した。それは、US 国内においては 3番目の、そして、グローバルでは 4番目のファシリティとして、同社のリストに加えられることになる
 
The Altoona facility is the first in Facebook’s fleet to feature a building-wide network fabric – an entirely new way to do intra-data center networking the company’s infrastructure engineers have devised.
 
この Altoona ファシリティは、ビルディング全体をカバーするネットワーク·ファブリックを、Facebook DC 艦隊では初めて搭載している。それは、同社のインフラ・エンジニアが考案した、データセンター内のネットワーキングを刷新するものである。
 
Faacebook Iowa DCThe social network is moving away from the approach of arranging servers into multiple massive compute clusters within a building and interconnecting them with each other. Altoona has a single network fabric whose scalability is limited only by the building’s physical size and power capacity.
 
このソーシャル・ネットワークは、大量のサーバーを詰め込んだ、大規模コンピューティング・クラスタ間を、相互に接続していくアプローチから離れようとしている。そして、Altoona に配備されたシングル・ネットワーク・ファブリックの拡張性を制約するものは、ビルディングの物理的なサイズと、電力キャパシティだけとなる。
 
Inter-Cluster Connectivity Became a Bottleneck
 
Alexey Andreyev, network engineer at Facebook, said the new architecture addresses bandwidth limitations in connecting the massive several-hundred-rack clusters the company has been deploying thus far. A huge amount of traffic takes place within each cluster, but the ability of one cluster to communicate with another is limited by the already high-bandwidth, high-density switches. This means the size of the clusters was limited by capacity of these inter-cluster switches.
 
Facebook のネットワーク・エンジニアである Alexey Andreyev が言うには、これまでに同社がディプロイしてきた、数百台のラックで構成される巨大クラスタ間の、接続における帯域幅の制約に対して、この新しいアーキテクチャで取り組んでいくとのことだ。発生する膨大なトラフィックは、それぞれのクラスタ内で処理されるが、クラスタ間を通信させる能力は、高帯域幅/高密度といわれるスイッチが限界を定める。つまり、クラスタのサイズは、それらを接続するスイッチの容量により、制約されていたことになる。
 
By deploying smaller clusters (or “pods,” as Facebook engineers call them) and using a flat network architecture, where every pod can talk to every other pod, the need for high-density switch chassis goes away. “We don’t have to use huge port density on these switches,” Andreyev said.
 
小規模なクラスタをディプロイし(Facebook のエンジニアはポッドとも呼ぶ)、フラットなネットワーク・アーキテクチャを用いることで、すべてのポッド間でのコミュニケーションが可能となり、高密度スイッチ・シャーシへの必要性が消える。Andreyev は、「それらのスイッチ上の、膨大なポート密度を使用する必要がなくなった」と述べている。
 
It’s easier to develop lower-density high-speed boxes than high-density and high-speed boxes, he explained.
 
高密度のハイ・スピード・スイッチより、低密度のハイ・スピード・スイッチを作成する方が容易であると、彼は説明している。
 
Each pod includes four devices Facebook calls “fabric switches,” and 48 top-of-rack switches, every one of them connected to every fabric switch via 40G uplinks. Servers in a rack are connected to the TOR switch via 10G links, and every rack has 160G total bandwidth to the fabric.
 
個々のポッドには、Facebook が Fabric Switch と呼ぶ 4つのデバイスと、48 Top-Of-Rack スイッチが取り込まれ、それぞれの Fabric Switch が 40G Uplink を介して、すべての Fablic Switch に接続される。 また、ラック内のサーバーは 10G Link を介して TOR スイッチに接続され、すべてのラックと Fablic の間には、合計で 160G 帯域幅が確保される。
 
Facebook Iowa NetworkHere’s a graphic representation of the architecture, courtesy of Facebook:
 
The system is fully automated, and engineers never have to manually configure an individual device. If a device fails, it gets replaced and automatically configured by software. The same goes for capacity expansion. The system configures any device that gets added automatically.
 
このシステムは完全に自動化され、それぞれのデバイスに関するマニュアル・コンフィグレーションを、エンジニアに要求することはない。デバイスに障害が発生した場合は、ソフトウェアによる置換えと、自動的なコンフィグレーションが実施される。それと同じことが、キャパシティの拡張に対しても適用される。 つまり、このシステムにより、あらゆるデバイスがコンフィグレーションされ、自動的に追加されていく。
 
Using Simple OEM Switches
 
The fabric does not use the home-baked network switches Facebook has been talking about this year. Jay Parikh, the company’s vice president of infrastructure engineering, announced the top-of-rack switch and Facebook’s own Linux-based operating system for it in June.
 
ただし、今年になって Facebook が話していた内製のネットワーク・スイッチが、このファブリックに使われるわけではない。この 6月に、同社の VP of Infrastructure Engineering である Jay Parikh が、Top Of Rack スイッチと Facebook 独自の Linux ベース OS の存在について発表していたので、注釈として加えておく。
 
The new fabric relies on gear available from the regular hardware suppliers, Najam Ahmad, vice president of network engineering at Facebook, said. The architecture is designed, however, to use the most basic functionality in switches available on the market, which means the company has many more supplier options than it has had in the older facilities that rely on those high-octane chassis for inter-cluster connectivity. “Individual platforms are relatively simple and available in multiple forms or multiple sources,” Ahmad said.
 
新しいファブリックは、一般的なハードウェア・サプライヤーからの供給されるギアに依存していると、同社の VP of Network Engineering である Najam Ahmad が発言している。このアーキテクチャをデザインしたが、マーケットで入手可能な最も基本的なスイッチを使用することになる。それにより当社は、クラスタ間を接続するハイ・スペック・シャーシに依存した、古いファシリティを有するのではなく、より多くのサプライヤーからソリューションを選択できるようになる。そして、「個々のプラットフォームは、相対的に見て、複数のフォームまたは複数のソースから選ばれる、シンプルで利用しやすいものになる」と、Ahmad は述べている。
 
New Architecture Will Apply Everywhere
 
All data centers Facebook is going to build from now on will use the new network architecture, Andreyev said. Existing facilities will transition to it within their natural hardware refresh cycles.
 
これから Facebook が構築していく、すべてのデータセンターにおいて、この新しいネットワーク・アーキテクチャが採用される。そして、既存のファシリティも、それぞれのハードウェア・リフレッシュ・サイクルに合わせて、新しいアーキテクチャに移行していくと、Andreyev は発言している。
 
The company has built data centers in Prineville, Oregon, Forest City, North Carolina, and Luleå, Sweden. It also leases data centers space from wholesale providers in California and Northern Virginia, but has been moving out of those facilities and subleasing the space until its long-term lease agreements expire.
 
すでに同社は、Prineville, Oregon/Forest City, North Carolina/Luleå, Sweden にデータセンターを構築している。また、California と Northern Virginia では、卸売プロバイダからデータセンター・スペースをリースしているが、それらのファシリティからの転出が進められており、長期にわたるリース契約の残存期間は、サブリースされるものと思われる。
 
In April, Facebook said it had started the planning process for a second Altoona data center, before the first one was even finished, indicating a rapidly growing user base.
 
この 4月に Facebook は、Altoona データセンターにおける 2号棟の計画を、1号棟の完成を待たずにスタートするとアナウンスしている。 つまり、そのユーザー・ベースが、急速に成長しているのだ。
 
The company has invested in a 138 megawatt wind farm in Iowa that will generate electricity for the electrical grid to offset energy consumption of its data center there.
 
また、同社は、Iowa の 138 MW 風力ファームに投資している。それにより、自身のデータセンターが消費する電力を、送電網に対してオフセットしていくことになる。
 
ーーーーー
open-computeこれまでのような、クラスタに依存するアーキテクチャでは、いかに高帯域幅/高密度なスイッチを用いても、その処理能力が、クラスタ間での通信速度の限界を定める。そして、クラスタのサイズは、それらを接続するスイッチの容量により制約されるので、クラスタという考え方を捨てる。 つまり、10万台のサーバーで構成される、1棟のデータセンターが、1つのクラスタだ、、、という、いかにも Facebook らしいデータセンターが誕生しました。 それが、Prineville/Forest City/Lulea に続く4つ目の、この Iowa の Altoona なのです。 先日に、「アジアの Facebook MAU は 4.5億人:儲からないけど、どうするの?」という抄訳をポストしましたが、そのアジアのユーザーのために、このようなデータセンターを構築してくれたのでしょうか? ここは、ご好意に甘えるとして、バンバンと Facebook を使わせていただきましょう :)  _AC Stamp
ーーーーー
<関連>
Facebook のユーザー数は 14億人:世界の 70億人の、5人に1人が使っている!
Facebook Lite がデビュー:取り組むべきは途上国マーケットの 2G 環境だ!
Facebook エンジニア と Android ローエンド:積極的に使ってアジアを知る!
Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!
Facebook が語るモバイル・チューニングの極意:これで途上国も OK!
Facebook と Mark の途上国戦略:Coca-Cola スタイルの長期スパンで考えていく
 
 

Huawei の年商が US$46B に成長:すでに Google に迫る勢いだ!

Posted in .Chronicle, Asia, Network, Research by Agile Cat on January 15, 2015

China’s Huawei Technologies says 2014 profit likely rose 17%
http://wp.me/pwo1E-8cg
January 13, 2015
http://www.thestar.com.my/Tech/Tech-News/2015/01/13/Chinas-Huawei-Technologies-says-2014-profit-likely-rose-17/

_Star Online

BEIJING: Huawei Technologies Co Ltd likely booked a 17% increase in operating profit last year, as worldwide adoption of fourth-generation (4G) mobile technology boosted earnings at China’s leading telecommunications equipment maker.

BEIJING: Huawei Technologies Co Ltd は、2014年の営業利益として、約 17%増という実績を発表するだろう。つまり、グローバルにおける 4G モバイル・テクノロジーの採用が、この China で最大の通信機器メーカーの収益を押し上げたことになる。

Profit likely reached 33.9bil yuan (US$ 5.43 bil) to 34.3bil yuan (US$ 5.49bil) in 2014, on a roughly 20% increase in revenue at 287bil yuan (US$ 45.92 bil) to 289bil yuan (US$ 46.24 bil), the company said in unaudited results.

2014年における利益は、33.9bil yuan (US$ 5.43 bil) 〜 34.3bil yuan (US$ 5.49bil) というレベルが見込まれ、前年比で 20% ほどの増加となる。 また、売上に関しては、287bil yuan (US$ 45.92 bil) 〜 289bil yuan (US$ 46.24 bil) に達すると、非公式ながらも同社は発言している。

RISING STAR
Reuters

Huawei competes with Sweden’s Ericsson for the top spot in the market for communications towers and other infrastructure, while racing to develop 5G technology.

Huawei は、5G テクノロジーのレースで、つまり通信タワーや関連するインフラというマーケットにおいて、Sweden の Ericsson とトップの座を争っている。

In the meantime, the gradual switch to 4G networks has boosted business at both players. Huawei said revenue at its carrier network business rose 15% last year.

その一方では、4G ネットワーク市場へと向けた段階的な移行が、この両社のビジネスを促進している。 Huawei によると、キャリア・ネットワーク事業において、昨年の売上が 15% も上昇しているという。

China’s three carriers alone built close to 1 million 4G towers by the end of 2014, according to some estimates.

いくつかの推測によると、2014年末までに、China のモバイル・キャリア三社(Terecom/Unicom/Mobile)だけで、100万ヶ所に 4G 通信タワーが構築されるという。

Chief financial officer Meng Wanzhou said Huawei’s 2014 operating profit margin likely matched 2013’s 12%, and that the company would continue to invest 10% of revenue in research and development.

Huawei の CFO である Meng Wanzhou によると、2014年における同社の営業利益率は、2013年の 12% と同じレベルになるという。 そして、同社は、そのうちの 10% を、今年も R&D に投入していくという。

Huawei executives in 2013 said the company would invest US$600mil (RM2.13bil) in 5G research through 2017. At the same time, the company will continue to pursue its multi-year expansion into smartphones and enterprise computing.

2013年の時点で Huawei 首脳陣は、5G テクノロジーの研究のために、2017年までに US$600mil を費やすと発言していた。それと同時に、同社は複数年にわたるスパンの中で、スマートフォンおよびエンタープライズ·コンピューティングのマーケットを拡大していくだろう。

Revenue last year rose 32% in Huawei’s consumer devices business and 27% in its enterprise division.

Huawei における昨年の売上は、コンシューマ・デバイス事業で 32% の成長を、また、エンタープライズ事業では 27% の成長を達成している。

— Reuters

ーーーーー

このポストは、マレーシアの The Star からのものであり、原文では通貨として RM が用いられていましたが、その部分を US$ で換算しています。 このトピックに関しては、Light Reading も「Huawei Boasts 2014 Revenues of $46B」という記事をポストしてますので、タイトルに記載した売上額に間違いはないと思います。Huawei の規模を把握するために、2014年 Q3 の Google と比較してみましたが、その四半期は $16.6B であり、単純に4倍すると $60B 程度になります。また、Microsoft は 2014年 7月期で、$86.8B という年間売上を計上しています。 この二社と比較するだけで、Huawei の規模が見えてきます。 Agile Cat も、これには驚きました。

ーーーーー

<関連>

China Mobile が、マレーシアの最大手モバイル・キャリアに出資か?
Apple と China Telecom が提携:中国人ユーザーのデータは本土の DC へ
Xiaomi が北京から脱出:インターナショナル・ユーザーのデータは 海外 DC へ!
中国のインターネット・ユーザー:6.3 億人に到達! Mobile が PC を逆転
2015年のデバイス市場:中国の $1.8Bに対して、インドは $4.8Bの成長だ!

Google も Cloud Exchange に乗った:これで Equinix は Cloud Big-3 を手中に!

Posted in Data Center Trends, Equinix, Google, Hybrid, Network by Agile Cat on January 14, 2015

Google shacks up with Equinix for cloud boost
http://wp.me/pwo1E-8c8
Ari Levy – 5 Nov, 2014
http://www.cnbc.com/id/102151522

For the 100 billion Internet searches and more than 6 billion hours of YouTube videos streamed monthly, Google is building supersized data centers across the globe. But for certain functions, the company is better off using other people’s property.

1ヶ月の間に 1000億回のインターネット検索を処理し、YouTube による 60億時間以上のストリーミング配信に対応する Google は、世界中に超大型データセンターを構築している。 しかし、特定の機能に関しては、他社の資産を活用するほうが、同社にとって有益なのである。

Equinix, which operates more than 100 data centers in 32 metro areas worldwide, is announcing on Wednesday that Google will be using its facilities to help clients in 15 markets, including New York, Atlanta, Frankfurt, Germany, and Hong Kong, access Google’s business applications and cloud infrastructure.

世界における 32地域の大都市圏で、100ヶ所以上のデータセンターを運営する Equinix が、この水曜日(11/5)に発表したのは、Google が 15ヶ所のマーケットにおいてクライアントをサポートするために、同社のファシリティを使い始めるという内容である。それらのマーケットには、New York/Atlanta/Frankfurt/Germany/Hong Kong などが含まれ、また、そのリージョンの顧客たちは、Equinix のネットワークを介して、Google のビジネス・アプリや、クラウド・インフラにアクセスできるようになる。

Baran Ozdemir
Vetta
Getty Images

The Google cloud needs all the help it can get. While the Mountain View, California-based company dominates the online advertising market, it’s playing catch-up to Amazon Web Services in on-demand cloud computing as it also battles Microsoft’s Azure technology.

Google のクラウドは、手に入れることが可能な、すべてのサポートを必要としている。 つまり、この、Mountain View, California-based の会社は、オンライン広告のマーケットは支配していても、オンデマンドのクラウド・コンピューティングの世界では、Amazon Web Services に追い付くために努力し、また、Microsoft Azure のテクノロジーと戦わなければならないのだ。

The three companies are engaged in a brutal price war as they try to lure businesses looking to offload their computing and storage instead of handling it internally. Amazon and Microsoft are already Equinix customers. Now businesses can use any or all of them via Equinix.

この三社は、きわめて熾烈な価格戦争に突入している。そして、ユーザー企業を取り込む魅力的な価格を提示するために、自社のデータセンター内で処理していたコンピューティングとストレージの負荷を、Equinix のファシリティにオフロードすることで軽減しようとしている。 Amazon と Microsoft は、すでに Equinix の顧客である。 そして、いま、ユーザー企業は Equinix を介して、それらのクラウドにおける、ほとんどの機能にアクセスすることが可能になっている。

"This completes our access to the big three cloud providers," said Equinix Chief Technology Officer Ihab Tarazi. Businesses can "get significantly higher bandwidth for very low economics and be able to completely leverage the cloud."

Equinix の CTO である Ihab Tarazi は、「クラウドの世界における Big-3 プロバイダが、私たちへのアクセスを完全なものにしたことで、ユーザー企業は、きわめて高速の帯域幅を確保し、また、優れた経済性を達成することになる。 つまり、完璧にクラウドを利用できるようになるのだ」と述べている。

Google disclosed the deal with Equinix on Tuesday as one of several announcements tied to its cloud platform. The company also introduced Google Container Engine and a partnership with Docker to make it easier to create and manage applications across machines.

Google は、この火曜日(11/4)に、そのクラウド・プラットフォームに関連する発表を行なっているが、その中の1つとして Equinix との今回の契約が明らかにされている。さらに Google は、より簡単にアプリケーションを作成し、また、マシン間での移動を管理するために、Google Container Engine を発表し、Docker との提携も明らかにしている。

It’s all part of Google’s deeper dive into the world of business software, and it’s not cheap. In the third quarter, Google spent $2.4 billion on capital expenditures, largely on data center construction and real estate costs.

Google がビジネス·ソフトウェアの世界に取り組んでいくという、この一連の発表により、その全容が明らかにされたが、それらは、決して安直なものではない。Google は 2014年 Q3 において、データセンターの建設と不動産の取得を主とする、 $2.4 billion もの設備投資を行なっているのだ。

"Everybody’s moving their infrastructures to the cloud," Google Chief Financial Officer Patrick Pichette said on the earnings call last month. "It is an area where we have fundamentally great assets to contribute to this industry, both in terms of the flexibility, the cost structure, the technology. And that’s why we’re investing heavily in there."

2014年10月の収支説明会において、Google の CFO である Patrick Pichette は、「すべての企業が、自身のインフラをクラウドに移行しようとしている。そして、そこは、私たちが大きな資産を形成しているエリアである。つまり、柔軟性/コスト構造/テクノロジーという基本的な観点において、この産業に貢献できるのだ。そして、私たちが多額の投資を行なっている理由が、そこにあるのだ」と述べている。

Google owns and operates 12 data centers in the U.S., Europe and Asia, according to its website. Much of the software that Google as well as Amazon and Facebook have developed to bolster the speed and capacity of servers and databases is being replicated across the technology industry.

Google の Web サイトによると、同社は US/Europe/Asia で、12ヶ所のデータセンターを所有/運用している。そして、Google/Amazon/Facebook などが、サーバーとデータベースの速度/能力を強化するために開発した、数多くのソフトウェア・テクノロジーが、この業界全体に広まりつつある。

But that doesn’t mean corporate America is ready to spin all of its most critical data up to the public cloud. Using Equinix, they can plug into the power of Google’s infrastructure without relying on it entirely.

しかし、それだけで、アメリカのユーザー企業が、すべての重要なデータをパブリック・クラウドに展開するための、準備を整えたというわけではない。そして、Equinix を利用するなら、すべての Google に頼ることなく、そのインフラを取り込めるようになるのだ。

Equinix has more than 4,500 customers using its facilities. In April, the Redwood City, California-based company launched a service called Cloud Exchange to provide an added layer of security and enhanced connectivity for businesses that may have previously been reluctant to move applications to the cloud.

Equinix のファシリティは、4500社以上のユーザー企業に使用されている。2014年4月に、Redwood City, California-based の同社は、ユーザー企業のためにセキュリティ層を加え、また、接続性を強化するための、Cloud Exchange と呼ばれるサービスを立ち上げている。それにより、これまでは移行が躊躇されていたアプリケーションの、クラウド化が促進されるかもしれない。

ーーーーー

2014年10月に、「Google の収益構造を分析してみた:その気になるポイントとは? 」というポストを訳していますが、この Equinix との提携は記載されていませんでした。 別の調べ物をしていて、今回の記事を見つけたわけですが、この提携に気づくことになり、ほんとうに良かったです :) なんというか、Google だけは独自ネットワーク路線かと思っていましたが、これで Equinix はグランド・スラム状態ですね。 ほんとうに、強いです。 また、年明けには、SofrLayer も Equinix の Cloud Exchange に対応、という記事がポストされていました。 近々に対訳を掲載しますので、そちらも、お楽しみに〜 

ーーーーー

<関連>

AT&T と Equinix:エンタープライズ向けのクラウド・アライアンスを締結
Equinix が新たに展開する Performance Hubs とは?
コロケ-ションの世界:グローバルの覇者 Equinix と アジアの NTT を比較する
Equinix Cloud Exchange による、洗練されたハイブリッド・クラウド
DigitalOcean が シンガポールに上陸する! それを 支える Equinix
DigitalOcean の London がオープン:Equinix がファシリティを提供

2014 Agile Cat:データセンター と インフラ の マトメ

Posted in .Chronicle, Data Center Trends, Network, Open Compute, Satellite by Agile Cat on December 23, 2014

2015年は アジアへのインフラ投資が盛んになる・・・
http://wp.me/pwo1E-876

今年も、いろいろな話題が満載の、データセンターとインフラ系のマトメです。 まず、1月に開催された OCP Summit では、Mark Zuckerberg が登壇し、Facebook は OCP により 1200億円も節約できたと説明しました。 また、新たなメンバーとして、このサミットで Microsoft の参加が発表され、10月には Cisco も参加しました。とにかく、どんどんと超党派化してきている OCP をみると、OCP Japan のお手伝いをしている Agile Cat としても、嬉しい限りです。また、誰もが注目する DCIM(Data center infrastructure management)に関しては、Dell/HP/Intel/Emerson などが推進する、Redfish という標準化案が気になるところですね。

そして、今年のメガ・データセンターですが、Facebook のスウェーデンとアイオワがオープンし、Google もオランダに大規模 DC を構築すると発表しています。また、Microsoft が韓国に構築するというウワサも流れています。 この、私たちの住むアジアは、爆発的に成長するデータセンター・トラフィックに対して、まだまだ供給が追いついていない地域であり、日本のテレコム勢も大規模な投資を継続しているようです。 そして、海底ケーブルに関しては、シンガポールからインド洋の沿岸を通り、フランスまで伸びていく SEA-ME-WE 5 が注目を集めています。 こんな話を聞くと、北極海経由で、日本とヨーロッパ、そして、日本とアメリカ東海岸をつなぐケーブルが欲しくなりますね。

ーーーーー

01/28: Facebook は OCP のおかげで、この3年で 1200億円も節約できた!
01/28: Blu-ray ディスクを 10000枚:エクサ時代のコールド・ストレージとは?
01/28: Open Compute Project : ついに Microsoft も参加を表明した!
01/29:
AT&T と Equinix:エンタープライズ向けのクラウド・アライアンスを締結
01/29: FB が選んだ CA の DCIM:そのハイパー・スケール管理は?
02/04:
送電網の UPS として機能する次世代バッテリー・テクノロジー!
02/05: Sprint と Nokia が、Spark トライアルから絞り出す 2.6 Gbps とは?
02/05: Cisco:モバイル・トラフィック No.1 は、日本の 1.87GB/月だ!
02/13: Microsoft の巨大データセンターが韓国に構築されるらしい
03/05:
Equinix が新たに展開する Performance Hubs とは?
03/12:
海底ケーブル:SEA-ME-WE 5 がシンガポールとフランスを接続する!
03/28: コロケーションの世界:グローバルの Equinix と アジア NTT を比較する

ーーーーー

04/02: Digital Realty が 北米 4ヶ所の DC で、Open-IX サーティフィケーション
04/03: Green DC:ビジネスでの優位性に加えて、環境への影響も考慮すべき
04/04: Long-Term Low-Cost のコールド・ストレージは 5 PB へと向かうのか?
04/17: Google のインフラ投資は ケタ外れ:それを示す1枚のチャート
04/23:
台湾の Wistron と Inventec が、ARM サーバーの生産に着手する!
04/23: IBM はPower チップのオープン化と、Google の戦略
04/25:
NTT Com の、マレーシア 第4データセンターがオープンした
04/29: Level 3 と Digital Realty が AWS と Azure を取り込む
05/07:
ヨーロッパを 仮想 DC でカバーする、Interoute クラウドが香港に進出!
05/13: SingTel と Telecity は、非インターネットで Azure 接続を実現する
05/14: Google は言う:クラウドの料金も ムーアの法則に従うべきだ!
05/21: DigitalOcean が シンガポールに上陸! それを 支えるのは Equinix だ!
05/27: Data Center の調査: 未来のデータセンターは、小型で手元に置かれる
05/30: 赤道上に浮かべる 180基の衛星:Google は成層圏バックボーンを目指す?
06/01: Rackspace の OnMetal サービスが、Post-VM 時代のクラウドを提起する
06/01: IBM のクラウド戦略:SoftLayer London データセンターが立ち上がる
06/02: SoftLayer の Hong Kong DC がオープン: IBM の $1.2B はアジアへ?
06/11: Google が買収した、Skybox Imaging という衛星スタートアップについて
06/12: Google と Virgin が思い描く宇宙開発の夢とは? 宇宙船を Youtube で!
06/17: Digital Ocean が IPv6 の完全サポートを発表
06:18:
Interoute の 仮想 DC ゾーンは London -NY を 68ms で接続する!
06/18: SSD のビジネスは、2014年に 60% も拡大する : 台湾からのレポート
06/19: Facebook と OCP から、Wedge という名の オープン・スイッチが発表!
06/23: Akamai と OpenDNS が提携:もっと もっと Web を速くしたい!
06/30: Instagram のマイグレ:200億枚のイメージを AWS から FBへ!

ーーーーー

07/01: Rackspace の OnMetal サービスが、Post-VM 時代のクラウドを提起する
07/02: Internap の ベアメタル OpenStack が、Hong Kong DC にも展開!
07/23: Google: 始まりは自作サーバー、そして 5000億円/四半期のDC 資産へ
08/27: KDDI が 東京と大阪に構築する Telehouse DC と超弩級の電力密度!
09/04: Telehouse の New York IX が CoreSite と接続:北米最大の GW を実現
09/05: Facebook のゴージャスな DC を、15枚の写真で紹介しよう!
09/09:
Dell/HP/Intel/Emerson の Redfish は、IPMI 以来の標準に?
09/23: Google が オランダの海岸線に作る、120MW の Eemshaven DC とは?
10/22: Google データセンターの世界:とても豪華な写真集
10/24:
Data Center の調査:大変革を促す4つの要因とは? – Gartner
10/28:
Xiaomi が北京から脱出:インターナショナル・データは 海外 DC へ!
11/11: IDC : 2017年を境に DC数は減少にいたるが、キャパは成長し続ける
11/18: Google:オランダの 62MW 風力発電プロジェクトと大型契約を締結!
12/09: Cloud の調査:DC トラフィックは、2018年の時点で 8.6 ZB に至る

ーーーーー

さて、2015年の IT インフラは、どのように進化していくのでしょうかね? 個人的には、人工衛星を使ったインターネット・バックボーンに興味津々というところです。 Google や Facebook や SpaceX などが名乗りを上げているようですが、衛星が小型化/軽量化されてくると、その打ち上げコストも一挙に低下し、宇宙開発が大きく進歩するはずです。 それが、2015年なのか、まだ先なのか、その辺りが見えませんが、この領域は Agile Cat 2015 で追いかけて行きたいと思っています。

ーーーーー

<2014年:マトメの一覧>

2014:Top-20 ポスト 総マトメ(root)

ーーーーー

2014:月曜版 On Monday のマトメ
2014:王者の風格 Google のマトメ
2014:大人になった Facebook の マトメ
2014:新しい動向の マトメ
2014:とっても元気な アジアの まとめ
2014:データセンター と インフラ の マトメ
2014:ディジタル広告の マトメ
2014:ソーシャル関連の マトメ
2014:iOS/Android/iPad/Chromebook の マトメ
2014:日曜版の マトメ
2014:クラウドの一年を 振り返る、チャート の マトメ

ーーーーー

2013: 総マトメ Top-10
2012: 総まとめ ページ

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

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 を占有している

Google が買収した、Skybox Imaging という衛星スタートアップについて

Posted in Google, Network, Satellite by Agile Cat on November 26, 2014

Google purchases Skybox Imaging satellite firm for $500m
http://wp.me/pwo1E-834
Mark McSherry – 11 June 2014
http://www.independent.co.uk/news/business/news/google-buys-skybox-imaging-satellite-firm-for-500m-9525170.html

Google said late on Tuesday it agreed to buy satellite start-up firm Skybox Imaging for $500 million in cash. Google said Skybox’s satellites will help keep Google Maps accurate with up-to-date imagery.

Google は、火曜日(6/10)の午後に、サテライト・スタートアップである Skybox Imaging を、$500 million で買収する合意に至ったと発表した。そして Google は、Skybox の衛星により、Google Maps のイメージを、最新かつ正確に保つことが可能になると述べている。

In time, Google said it hopes that Skybox’s team and technology will also be able to help improve internet access and disaster relief — areas that Google said it has long been interested in.

Google は Skybox のチームとテクノロジーについて、インターネット・アクセスを向上させ、災害時の支援を改善するものになると発言している。 そして、それは、Google が長年に渡って興味を抱いてきた領域である。

Skybox said on its website that it builds satellites, writes code, and deploys data centres.

その一方で Skybox は、衛星を構築し、コードを書き、データセンターをディプロイしていると、その Web サイトで語っている。

In its statement, Skybox said the time was right “to join a company who can challenge us to think even bigger and bolder, and who can support us in accelerating our ambitious vision.”

そのステートメントにおいて、Skybox は正しいタイミングだったと述べている。そして、「さらに広大で大胆な考え方を持つ、挑戦させてくれる企業に参加し、私たちの野心的なビジョンが加速するようサポートしてもらっている」と、続けている。

Skybox said it had built and launched the world’s smallest high¬-resolution imaging satellite, which collects images and video every day.

Skybox は、高解像度イメージを取得する、世界で最小の衛星を構築して打ち上げ、それにより、日々のイメージとビデオを収集していると述べている。

“We have built an incredible team and empowered them to push the state-of-the-art in imaging to new heights,” said Skybox.

「 私たちが創ったチームは、信じられないほどの能力を持っている。そして、高次元のイメージ処理を、最先端のテクノロジーで促進するために、このチームを育成していく」と、Skybox は 述べている。

ーーーーー

先日の TechCrunch に、「SpaceX がインターネット接続用低価格小型衛星を開発」という記事がポストされていました。 この SpaceX とは、Tesla の Elon Musk が率いるスタートアップであり、ヨーロッパ・ベース(?)の WorldVu という衛星プロジェクトと連携して、この壮大な試みを推進するとされています。 しかし、WorldVu と Google の間にも、共同プロジェクトのウワサがあるのです。そして、この Skybox Imaging は、通信というより地表イメージの取得と配信がメインのようですが、Google にとって、2つの衛星プロジェクトが必要なのか不要なのか、その辺りが、とても興味深いところです。 いずれにせよ、2015年は衛星がホットになりそうなので、引き続き、追いかけて行きたいと思っています。

ーーーーー

<関連>

Google と Virgin が思い描く宇宙開発の夢とは? その宇宙船を Youtube で!
Intelsat と SpeedCast が連携して、グローバル接続をカバーする通信衛星とは
Alcatel-Lucent の海底ケーブルが、31Tbps の記録を達成!
空芯型ファイバーにより、光速の 99、7% に到達するテクノロジーとは?
400 Gbps の転送速度を可能にする、ノイズ・キャンセリング・ビームの理論とは?
インターネットの世界を、海底ケーブル・マップから眺めてみる

Intelsat と SpeedCast が連携して、グローバル接続をカバーする通信衛星とは

Posted in Network, Satellite by Agile Cat on November 21, 2014

Intelsat and SpeedCast join forces to provide enhanced global connectivity
http://wp.me/pwo1E-82l
News | by CIOL Bureau
http://www.ciol.com/ciol/news/216145/intelsat-speedcast-koin-forces-provide-enhanced-global-connectivity

LUXEMBOURG & HONG KONG: Intelsat S.A., the world’s leading provider of satellite services, announced today that it has established a strategic agreement to provide access to its global C- and Ku-band broadband mobility network to SpeedCast, the leading global satellite communications and maritime service provider.

LUXEMBOURG & HONG KONG: 衛星サービスにおける世界的なリーディング・プロバイダーである Intelsat S.A.は、やはり、衛星通信と海事サービス・プロバイダーの分野で世界をリードする SpeedCast と、C-band および Ku-band におけるモバイル・ブロードバンド・ネットワークへのアクセスを提供するために、戦略的パートナーシップを確立したと発表している。

Under the multi-year agreement, Intelsat will provide SpeedCast access to Intelsat’s global C-band and Ku-band satellite capacity as well as to its terrestrially managed network, IntelsatOne?. The agreement will also provide SpeedCast access to Intelsat’s global broadband mobility network, which is comprised of 13 customized Ku-band mobility beams on ten satellites spread around the geostationary belt. SpeedCast will leverage Intelsat’s satellites and terrestrial network to deliver enhanced broadband and mobility solutions to the Maritime, Oil & Gas and Enterprise markets with expanded coverage and greater flexibility.

この複数年におよぶ契約に基づき、Intelsat は SpeedCast に対して、同社のグローバル C-band/Ku-band 衛星キャパシティに対するアクセスだけではなく、地上との間のマネージド・ネットワーク(IntelsatOne?)も提供する。また、この契約により、SpeedCast は Intelsat のグローバル・ブロードバンド・モバイル・ネットワークへのアクセスも取得する。それにより、静止軌道上に展開される 10基の衛星が提供する、カスタマイズされた 13種類の Ku-band モバイビリティ・ビームを利用できるようになる。つまり、SpeedCast は Intelsat の衛星と、帯域とモビリティを強化した地上間ネットワーク・ソリューションを活用することで、広範囲のカバーと高度な柔軟性を、海運/石油/ガスといったエンタープライズ市場に提供することになる。

"This new strategic arrangement between SpeedCast and Intelsat is another exciting step in the transformation of SpeedCast into a major global player in the satellite communications markets, on land and at sea" said Pierre-Jean Beylier, CEO, SpeedCast.

SpeedCast の CEO である Pierre-Jean Beylier は、「 SpeedCast と Intelsat が新たに締結した、この戦略的パートナシップにより、次のエキサイティングなステップが生じる。つまり、陸上と海上をカバーする衛星通信マーケットにおける、主要グローバル・プレーヤーに SpeedCast が仲間入りすることになる」と、述べている。

"Intelsat’s global C-and Ku-band network will further enhance our ability to deliver reliable, cost-effective and fast connectivity to our customers." "Broadband mobility represents one of the fastest growing markets for satellite services," stated Stephen Spengler, president and chief commercial officer, Intelsat.

「 Intelsat のグローバル C-band/Ku-band ネットワークは、高信頼性/低コスト/迅速な接続性を顧客て提供するという意味で、当社の能力を強化するものとなる。ブロードバンド・モバイビリティは、衛星サービスというフィールドにおいて、最も急成長しているマーケットでもある 」と、同社の President and Chief Commercial Officer である Stephen Spengler は述べている。

"The new and enhanced agreement with SpeedCast provides both companies with a strong platform to further expand our ability to serve customers. Our partnership with SpeedCast will further strengthen our collective ability to deliver the reliable and efficient broadband and mobile connectivity that today’s global businesses demand and need."

そして、「 新たに締結される SpeedCast との広範囲におよぶ契約により、私たちの顧客サービス能力を拡大する、強固なプラットフォームを両社は手にすることになる。SpeedCast とのパートナーシップは、今日のグローバル企業が求める、信頼性と効率を備えるブロードバンド/モバイル接続を提供することで、私たちの協業を強化していく」と続けている。

ーーーーー

先日に「Google と Virgin が思い描く宇宙開発の夢とは? その宇宙船を Youtube で!」という抄訳をポストしましたが、その直後に痛ましい事故が起こってしました。 犠牲となったパイロットのことを考えると、意気消沈の Agile_Cat ですが、ブライソン卿は開発を継続するとのことなので、頑張ってほしいと願っています。 どう考えても、宇宙とインターネットは切っても切れない関係だと思いますし、やがては宇宙空間にデータセンターが構築される日が来るとも信じています。 そんなことから、このサイトでも、継続して宇宙は追いかけて行きたいと思っています。 今回は、衛星の老舗である Intelsat の話です。

ーーーーー

<関連>

インターネットの世界を、海底ケーブル・マップから眺めてみる
Google が成層圏に浮かべるワイヤレス基地局 : 気球とソーラーの全容が明らかに!
Google の飛行船団が、途上国の空からワイヤレスを降らす?
Google のインフラ投資額 : これまでに $21B をデータセンターに!
空芯型ファイバーにより、光速の 99、7% に到達するテクノロジーとは?
Alcatel-Lucent の海底ケーブルが、31Tbps の記録を達成!
400 Gbps の転送速度を可能にする、ノイズ・キャンセリング・ビームの理論とは?

%d bloggers like this: