Agile Cat — in the cloud

Google の MVNO:Project Fi の内容が 明らかになった!

Posted in .Selected, Google, Mobile, Network by agilecat.cloud on April 23, 2015
This is Google’s new wireless phone service: Project Fi
Lisa Eadicicco – April 22, 2015
http://www.businessinsider.com/google-wireless-phone-service-2015-4
 
_ Business Insider
 
Google just announced Project Fi, its new wireless phone service. The company is partnering with T-Mobile and Sprint for the new project. For now, it’s only available on the Google Nexus 6 phone.
 
ついに Google が、新たなワイヤレス・フォン・サービスである、Project Fi を発表した。 この新しいプロジェクトのために、同社は T-Mobile および Sprint と提携している。 そして、現時点では、Google Nexus 6 だけが対応している。
 
Project Fi is a bit like a traditional carrier plan you would get from a AT&T, Verizon, Sprint, or any other provider, except Google is focusing on two key areas: making it easier to switch between Wi-Fi and cellular, and letting you pay only for the data you actually use.
 
この Project Fi は、従来からのキャリア・プランと、つまり AT&T/Verizon/Sprint などのプロバイダから提供されるプランと似ている。ただし、Google は2つの領域にフォーカスしている。 具体的に言うと、Wi-Fi と セルとの接続を容易に切り替え、実際に使用されたデータにのみに課金する点が異なっている。
 
man-phone-window.pngYouTube/Google
 
For example, when you’re using Project Fi, the service will automatically connect you to whichever network is fastest and within range.
 
たとえば、Project Fi を使用しているなら、その場所で利用できる最も高速のネットワークが、このサービスににより選択/接続される。
 
So, if you’re using cellular but there’s a faster Wi-Fi service nearby, it will automatically switch, and vice versa. Google also says it uses encryption to protect your data once your device is connected.
 
したがって、セル接続されている場合でも、より高速の Wi-Fi サービスが近くにあるなら、また、その逆の状況であっても、自動的な切り替えが行われる。
 
そして Google は、このサービスと、あなたのデバイスが接続された直後から、データを保護するための暗号化が用いられると発言している。
 
And, Google also says it will credit you for unused data that you’ve already paid for once your cycle is up. That’s the real advantage you can’t get with a wireless carrier today.
 
さらに Google は、対応する期間が終了した後であっても、すでに支払いが行われているデータ通信料に関して、繰越を認めると発言している。それは、現時点で既存のワイヤレス・キャリアから得ることができない、本当のメリットである。
 
For $20 per month, you get all the basics such as talk, text, and international coverage. Then, you pay a flat rate of $10 per gigabyte of data. So 1GB of data is $10 per month, 2GB is $20 per month, and so on.
 
$20/月のプランで、通話/テキスト/国際電話などの、すべての基本的なサービスが得られる。 それで足りなければ、続いて $10/GB の定額料金を支払う。 つまり、1GB のデータが $10/月額で得られ、2GB のデータが $20/月額で得られるという具合である。
 
That’s a big deal — not only is Google crediting you for the data you don’t use, but the pricing plan is really simple and transparent compared to those offered by carriers.
 
素晴らしいことである。 Google は未使用のデータ分を繰り越すだけではなく、その料金プランについても、他のキャリアから提供されるものと比べて、きわめてシンプルで透明性のあるものにしている。
 
You can also connect your phone number to any device that supports Google Hangouts, so that you can make or receive phone calls on phones, laptops, and Chromebooks among other devices.
 
また、Google+ Hangouts をサポートする、あらゆるデバイスに対して、その電話番号を接続できるようになる。それにより、スマホでも、ラップトップでも、Chromebook でも、電話をかけること、そして受けるとこが、可能になのだ。
 
Google’s Sundar Pichai mentioned at Mobile World Congress that Google was working on a small-scale wireless network, but this is the first time Google has given concrete details.
 
Google の Sundar Pichai は Mobile World Congress で、小規模なワイヤレス・ネットワークで取り組んでいると話していたが、その具体的な詳細について、Google は初めて明らかにしたことになる。
 
ーーーーー
google-55a日本では当たり前になってきている MVNO ですが、ようやくアメリカでも Google が具体化したということなのでしょう。 先月の「Google の考える MVNO は、単なる MVNO では 無い!」という抄訳で、Sundar Pichai の MWC 発言を追いかけていますが、どのようにアメリカ市場に受け入れられるのか、とても興味があります。なお、このポストの冒頭に、T-Mobile および Sprint と提携と書かれていますが、この2つのキャリアが同時に掴めた場合でも、速い方に接続されるのでしょうかね?  そうだとしたら、とても羨ましいサービスですよね! _AC Stamp
ーーーーー
<関連>
Google の Chromebit は、$100 以下で買える Chromebook ドングルなのだ!
Android フォークの CyanogenMod に Microsoft が出資? 新たな戦いが始まる?
iPhone 6C 廉価版のウワサが 台湾の情報筋から:価格は $400〜$500 か?
激変するスマホ市場とプレイヤーたち:2010 〜 2014 の変遷を1枚のチャートで!
2014 スマホ OS 総決算:Android が 81.5% で、iOS は 14.8% だ!
 
 

Facebook の ネットワーク環境:そこに Cisco の支配は有り得ない

Posted in .Chronicle, .Selected, Cisco, Data Center Trends, Facebook, Network, Open Compute by agilecat.cloud on March 19, 2015
Facebook Just Gained A Big Ally In Its Battle With Cisco
Julie Bort – Dec. 4, 2014
http://www.businessinsider.com/facebook-gains-juniper-as-new-ally-in-battle-with-cisco-2014-12
 
_ Business Insider
 
Last summer, an organization led by Facebook fired a huge shot at Cisco. On Thursday, on4e of Cisco’s oldest rivals, Juniper, jumped in to back Facebook in a big way.
 
昨年の夏のことだが、Facebook が率いる組織が、Cisco に対してきつい一撃を浴びせた。 そして、この木曜日(12/4)には、Cisco にとって最も古いライバルである Juniper が、この Facebook の試みに対して、最大級の支援を申し出るポジションへと飛び込んできたのだ。
 
Wedge_Mark_ZuckerbergJustin Sullivan Getty Images
 
Facebook CEO Mark Zuckerberg
 
And the threat to Cisco from Facebook went from huge to enormous. It won’t kill Cisco, but it will shake the trees a little bit and force Cisco to make some uncomfortable choices.
 
それにより、Cisco が Facebook に対して抱く脅威が、さらに増大することになる。 Cisco が倒されるようなことは起こり得ないが、この大樹を多少は揺さぶり、また、時には不快な選択を促すことになるだろう。
 
The shot was a new piece of networking equipment called the Wedge, which pushed Facebook into the $23 billion Ethernet switch market, currently dominated by Cisco.
 
前述の一撃とは、Wedge という名の新しいネットワーク機器のことであり、Cisco が支配している $23 billion Ethernet スイッチ市場に、Facebook を参戦させるものである。
 
This new switch wasn’t an actual product. It was a design for a new product, one that Facebook gives away for free through its Open Compute Project (OCP).
 
とは言え、この新しいスイッチというものは、現実的なプロダクトにはなっていなかった。つまり、Facebook が率いる Open Compute Project(OCP)を介して、新たなプロダクトのために無償で提供される、デザインという位置づけとなっていた。
 
OCP is a radically new way to build and buy computer hardware. Anyone can contribute to the designs and use them for free, ordering them from a contract manufacturer.
 
OCP が実現するのは、コンピュータ・ハードウェアの構築/購入のための、まったく新しい方式である。誰もがデザインをコントリビュートすることが可能であり、また、無償で使用することも可能である。 つまり、契約を交わしたマニュファクチャに発注することで、それらを具体的なレベルで製造できるのだ。
 
Now, Juniper has done exactly that. It designed its own version of the OCP switch, which works with its operating system, Junos OS. It ordered this design from a contract manufacturer, Alpha Networks, and Juniper will sell this switch to enterprises with big data centers.
 
まさに、いま、Juniper は、それを行っている。 同社は、OCP スイッチと自身の Junos OS を連携させるという、独自のバージョンをデザインしたのだ。そして、そのデザインを、契約マニュファクチャである Alpha Networks に発注し、大規模データセンターを有するエンタープライズに、この製造されたスイッチを販売していく。
 
There are a few important things about all of this.
 
この、一連の流れにおいて、いくつかの重要なポイントがある。
 
Facebook’s switch isn’t just a radically new way to buy a piece of hardware, it’s also part of a radically new way to design networks called software-defined networking (SDN).
 
ただし、Facebook のスイッチは、ハードウェアを購入するための、新しい方法だけに本質があるわけではない。それは、Software-Defined Networking(SDN)と呼ばれるネットワークをデザインするための、まったく新しい方法としても機能する。
 
SDN takes all the fancy features found in networking equipment and puts them into software that runs on servers. You still need the network equipment, but you need less of it and less expensive varieties. It will almost certainly cause a price war one day, if companies start to experiment with it and like it.
 
SDN とは、ネットワーク機器上で検出された、すべての想像上の機能を受け取り、それらをサーバー上で走るソフトウェアに置き換えていく。依然として、誰もがネットワーク機器を必要とするが、その数を減らし、また、コストも引き下げる必要がある。その種の実験もしくは、それに類するものを、複数の企業が開始すると、いつの日にかは、ほぼ確実に価格戦争の原因になっていく。
 
Facebook’s involvement with SDN will encourage them to do just that. If it works for Facebook, it could work for them.
 
Facebook による SDN への取り組みは、同じことを行おうとする企業を勇気づける。つまり、そこでの成果は Facebook だけのものではなく、同じ方向を目指すエンタープライズにとっても、きわめて有用なものとなるはずだ。
 
The Wedge, and Juniper’s version of it (named the “OCX1100″), is designed to work with lots of open source software, too. People can program it with a common language like Python. It works with popular open source management tools from Chef and Puppet Labs.
 
この Wedge と Juniper のバージョン(OCX1100)は、膨大なオープンソース・ソフトウェアと連携して、動作するようにもデザインされている。そして、Python のような共通の言語を用いて、それらをプログラムすることが可能である。さらに、Chef や Puppet Labs などから提供される、人気のオープンソース・マネージメント・ツールとも協調する。
 
All the network equipment makers are creating SDN switches, Cisco included. In fact Cisco says that its SDN product released last year is selling well.
 
Cisco を含めて、すべてのネットワーク機器メーカーが、SDN スイッチを作成している。実際のところ、昨年に Cisco がリリースした、その SDN プロダクツはよく売れていると言う。
 
But Cisco’s gear is not like the Wedge. Traditional switches from Cisco or Juniper are a single piece of equipment. They look like this:
 
しかし、Cisco のギアは、Wedge のようなものではない。 Cisco や Juniper から提供される、従来からのスイッチは、以下のような一体型の機器となっている:
 
Wedge_CiscoCisco Catlyst switches
 
The Wedge is designed to stitch together standard bits of hardware, that you can change as you see fit. It’s like Legos, only for a computer server, like so:
 
その点、Wedge は、目的に合わせた変更が可能なよう、スタンダード・ハードウェアを集めて、組み上げていくためにデザインされている。 それは、以下のようなものであり、コンピュータ・サーバーを対象とした Lego のようなものだ:
 
Wedge_DesignFacebook Wedge 
network switch
 
Facebook has no interest in competing with Cisco. It just wants to build reliable, low-cost and easy-to-maintain equipment to use in its own data centers. OCP hardware saved Facebook over $1 billion in its first three years, CEO Mark Zuckerberg said. Many other companies want the same.
 
Facebook は、Cisco と競合しようとしているのではない。自身のデータセンターで使用するための、高信頼性/低コスト/容易なメンテナンスを実現する設備を、単に構築したいと考えているだけなのである。OCP ハードウェアを活用し始めた Facebook は、最初の 3年の間に $1 billion を節約できたと、CEO の Mark Zuckerberg が発言している。 そして、他の企業も、同じことを行いたいだけなのである。
 
Most enterprises, even big telecom companies, don’t want to deal with designing and building their own Lego-like servers.
 
それが大手のテレコムであったとしても、ほとんどのエンタープライズは、Lego のような独自サーバーを設計/構築したいとは考えていない。
 
That’s where Juniper comes in. They can buy a Wedge from Juniper.
 
そこが、Juniper の目の付け所である。 つまり、それらのエンタープライズは、Juniper から Wedge を購入できるのだ。
 
Cisco is well aware of the Wedge. In October, a few months after the Wedge launched, Cisco joined the OCP as a a Gold member. It told its customers that if they want OCP products, they can come to Cisco. They don’t need to go to Alpha Networks or Juniper.
 
Cisco は、Wedge のことをよく知っている。 Wedge がローンチした数ヶ月後の 10月に、Cisco は Gold メンバーとして OCP に参加した。そして、OCP プロダクトを欲しがる顧客がいるなら、彼らは Cisco に来ると語っていた。 つまり、Alpha Networks や Juniper に行く必要は無いというわけだ。
 
Still, should Juniper’s OCP switch become popular, this should put Cisco in an uncomfortable position. Should it jump on the bandwagon, create its own Wedge, and put a knife in the back of its own SDN switch, which is selling well? Cisco has spent about $1 billion to create that product.
 
とは言え、Juniper の OCP スイッチに人気が集まれば、Cisco にとっては不本意なポジションが待っている。この流れに乗って、独自の Wedge を構築すべきなのか? それは、よく売れている、独自の SDN スイッチを、背後からナイフで突き刺すことにならないのか? このプロダクトを作成するために、すでに Cisco は $1 billion も費やしているのだ。
 
Or should it watch customers go to Juniper and its other competitors involved with OCP, like Arista?
 
さもなければ、顧客が Juniper に流れていくのを黙ってみているのか? さらに言えば、そこには Arista のような、OCP のメンバーも参戦してくるだろう。
 
Cisco had no comment on the Juniper switch, but did tell us, “Cisco has been a leader in advancing multiple open source programs, including the Open Compute Project.”
 
この Juniper のスイッチについて、Cisco はノーコメントを貫いている。 しかし、同社は、「 Cisco の先進性は、多数のオープンソース・プログラムでリーダーを務めているところにもあり、そこには Open Compute Project も含まれる」と、私たちに答えている。
 
SEE ALSO:  Why Cisco Has Showered These 3 Men With Billions Of Dollars
 
ーーーーー
open-computeこのポストは、2014年12月のものであり、この後に続くコンセプトとして、すでに 6-pack が登場しています。 ここで紹介されている Wedge と Fabric をセットにしたものですが、それ自体も SDN のためのホワイトボックスという位置づけになります。すでに、Pluribus というスタートアップが動き出しているようです。 この会社は、長年にわたり Cisco の幹部を務めていた Kumer Srikantan に率いられ、Yahoo の創業者である Jerry Yang に支援され、$50 million を調達しているとのことです。 同社のプロダクトは、Facebook の Wedge と同様のスタイルで構築され、市販のコンポーネントでハードウェアを構成し、独自のオープンソース・フレーヴァーのソフトウェアを有しているようです。 まさに、OCP デザインを活用したビジネス・モデルというわけです。_AC Stamp
ーーーーー
<関連>
Open Compute : Summit 2015:ついに Apple が正式参加!
Facebook 第四艦隊 Iowa DC が、ネットワークを刷新して出撃!
Facebook と OCP から、Wedge という名の オープン・スイッチが発表された!
Facebook は Open Compute のおかげで、3年で 1200億円も節約できた!
無印サーバー:Quanta は出荷量の 90% 以上:Wiwynn は前年比で 100% 増
 

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

%d bloggers like this: