Agile Cat — in the cloud

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 の転送速度を可能にする、ノイズ・キャンセリング・ビームの理論とは?

Google と Virgin が思い描く宇宙開発の夢とは? その宇宙船を Youtube で!

Posted in Google, Network, Satellite by Agile Cat on October 16, 2014

Google and Virgin Galactic Negotiate Stake in Satellite Technology
http://wp.me/pwo1E-7Xi
By Sean MartinJune 12, 2014 14:41 BST
http://www.ibtimes.co.uk/google-virgin-galactic-negotiate-stake-satellite-technology-1452418

_ IBT

Technology giant Google is in talks with Sir Richard Branson’s Virgin Galactic to strike a deal that will give the search engine access to the former’s satellite-launch technology, as well as handing over an equity stake in its space travel endeavour, according to Sky News.

テクノロジー・ジャイアントの Google だが、Richard Branson 卿の Virgin Galactic と交渉し、その検索エンジンと衛星打ち上げテクノロジーを結びつけようとしている。 それだけではなく、未来の宇宙旅行に関する取り組みについても、資本参加する可能性があると、Sky News が伝えている。

Google is in talks with Virgin Galactic to buy a stake in the business Reuters

The talks with Branson’s £1.2bn (€1.5bn, $2bn) company are part of Google’s strategy to put hundreds of satellites into orbit as it hopes to make the internet more accessible across the globe.

この、Branson の £1.2bn (€1.5bn, $2bn) の会社との交渉は、インターネットへのアクセスを世界中から容易に行えるようにするために、数百の衛星を軌道上に浮かべたいとする、Google におけるストラテジーの一部である。

Negotiations are at an advanced stage as the two firms have been discussing the venture for several months, according to Sky.

この冒険について、両社が数ヶ月もかけて交渉するつれて、議論の内容も前進していると、Sky News は述べている。

There are apparently two parts to any potential deal. The first would see Google pump millions of pounds into a joint project which will see Virgin Galactic fold its technology that it has in the pipeline.

この契約には、二通りの可能性があることが、明らかになっている。1つ目は、ジョイント・プロジェクトを立ち上げ、そこへ向けて Google が数百万ポンドのキャッシュを注ぎ込む方式だが、準備しているテクノロジーを、Virgin Galactic が止めてしまう可能性もある。

The second part will see Google spend roughly £17.8m for a stake in Virgin Galactic’s holding company, which would equate to roughly 1.5% of the business.

2つ目は、Virgin Galactic の持株会社に対して、その事業の約 1.5%に相当する £17.8m を、Google が注ぎ込むことで株式を取得するという方式である。

Youtube ⇒

Sky goes on to say that no deal is yet set in stone and that the terms and conditions could change before any deal is announced.

Sky は、この契約については、まだ何も決定されていなく、その内容が発表される前に、条項や条件が変更されるだろうとしている。

Although Virgin has been adamant that the service will begin this year, some quarters have suggested that problems with its development will dampen its practicality.

このサービスについて Virgin は、年内に開始すると強く主張しているが、いくつかの情報筋が、開発に伴う問題により、その実用性が減退していると示唆している。

However, a deal with one of the technology sectors’ leading pioneers, as well as one of the most commercially viable companies in the world, could prove to be the confidence booster that Virgin Galactic may need.

しかし、このテクノロジー分野をリードする先駆者として、さらに言えば、商用的な実現性に世界で最も近づいている企業として、Virgin Galactic が必要とする具現化を、この契約は促進するだろう。

Google is currently embroiled in a race against its internet rivals to be the first one to offer worldwide internet access.

その一方で、いまの Google は、グローバルなインターネット·アクセスを最初に提供するという、インターネットの世界におけるライバルたちとのレースに巻き込まれている。

Related

ーーーーー

それにしても、凄まじく、また、カッコの良い映像ですね。 なんというか、スペースシャトルのコンセプトを、つまり着陸が可能で、使い回しできる宇宙船を、もっと小型にして、経済性を高めたという感じですね。 おそらく、成層圏までは行かない低軌道に衛星を浮かべるための、有人作業船なのでしょう。 これ以外にも、Google はいくつかの宇宙開発に取り組み始めているようです。 それらも、順を追って紹介していきたいと思います。

ーーーーー

<関連>

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

%d bloggers like this: