Agile Cat — in the cloud

2014年:Agile Cat ディジタル広告の マトメ

Posted in .Chronicle, Advertising by Agile Cat on December 22, 2014

ディジタル・アドは、今様の 打ち出の小槌 なのか?
http://wp.me/pwo1E-86Z

いまでは、Advertising というカテゴリもありますし、右ペインにはショートカット・アイコンも貼ってある、Agile Cat ディジタル・アドのマトメです。 ディジタル・アドを意識しだしたのは、2012年からだと思いますが、Google と Facebook の大躍進が、その理由となります。さらに言えば、この広告ビジネスから、Android という OS が生まれ、Facebook というソーシャルが育ち、あっという間に世界を埋め尽くしてしまったという凄まじい現実に、目を見開かされたという感じがします。

Microsoft は Windows でライセンスを売り、Apple は iOS でデバイスを売り、Google は Android で広告を売る、、、という表現を、今年はセミナーなどで、よく用いました。 年の初めころは、こんな話をしてもキョトンとする人が多かったように記憶していますが、春から夏へ、そして、秋から冬へと時間が経つにつれて、話した瞬間に「ナルホド」と頷いてくれる人が増えてきたように感じています。

このカテゴリを作るときは、自分でも、ほんとうに良いのかなぁと、半信半疑なところがありましたが、この領域を把握しないことには、Google と Facebook の経済的な立脚点が見えてきません。 その意味で、ここれに費やしてきた時間は、決して無駄ではなかったというのが、いまの、率直な、思いです。

ーーーーー

01/03: モバイル広告 : 2014年は 64%も伸びる!
01/07:
Apple App Store と モバイル・アド の売上を比較する
01/29:
Super Bowl 対決:勝つのは TV か、FB か、TW か?
02/26:
Yandex と Google が ディスプレイ広告で提携:世界を牛耳る同盟に?
04/16: Google の 2014-Q1 収支を分析する:GigaOm
05/14:
だから検索はやめられない:Google/Yandex/Baidu の収益性を確認する
05/15: Google と Facebook が支配する モバイル広告の世界
05/20:
Google と Facebook で 75% を支配するモバイル広告
05/27:
Twitter も Asia を目指すことになる : しかし、マネタイズは大丈夫か?
05/28: iOS は 53% で Android は 166%:アプリ売上の成長率
06/17:
Google の 2014 Q2 収支:モバイル・ベースの薄利多売に投資家たちは OK
06/23:
Facebook 脅威の Q2 決算:3000 億円の売上げと 48% の粗利率 !

07/17: Facebook が実験する BUY ボタン:Amazon や eBay にとって脅威に?
07/17: リアルタイム入札が モバイル広告を加速させる
07/28:
Facebook Page for iPhone という、Apple にとって悩ましき存在とは?
08/22: Amazon も広告事業に参入し、Google の後を追うのか?
09/16:
一番の お客様は Amazon 様です: Google AdWards の凄まじさ
09/26: 広告ビジネス: Yahoo と AOL を統合しても、GO と FB は止められない
09/29: Facebook アドが 外の世界へ: Atlas が Google に 本気で挑んでいく
09/15: モバイル・アドの急成長:2018年には全米デジタル広告の 50% を超える?
10/06: クッキーは死んだ:そして Facebook/Google/Apple の広告が激変!
10/16: Google の収益構造を分析してみた:その気になるポイントとは?
10/16: モバイル・アドに苦悩する Google と、答えを見つけ出した Facebook
10/22:
モバイル・ビデオ広告 が 本格化:小さなスクリーンに 札束が詰め込まれる
10/28: Facebook の 2014 Q3 決算を分析する:モバイル広告の伸びがスゴイ!
10/28: Facebook がビッグ・ウェーブに乗った:収益の 66% をモバイルで稼ぐ!
10/30: Facebook の Graph API がアップデートされ、AD API も強化された!
11/13: Facebook と Google によりソーシャル・ログインの 80% を占有

ーーーーー

新聞やテレビといった従来型のメディアから、 Google や Facebook が広告予算をぶん取ってきて、それが IT のエコシステムを回す資金になっていくという新しい展開は、2014年の大きな流れの1つだったと思います。つまり、Eric Schmidt の言う第五の権力が、第四の権力から、経済を奪い取り始めているのでしょう。そう考えると、Apple にも、Amazon にも、Microsoft にも、この領域でのビジネスに、もっと本格的に取り組んで欲しくなってきますね。 Agile Cat としては、もちろん 2015年も、このカテゴリを充実させていきます!

ーーーーー

<関連>

2014年:Agile Cat ソーシャル関連の マトメ
2014年:クラウドの一年を 振り返る、チャート の マトメ
2014年:Agile Cat 日曜版の マトメ

ーーーーー

2013年 : OpenStack の マトメ
2013年 : Post-PC と 地殻変動 の マトメ
2013年 : Asia の 炸裂するパワーの マトメ
2013年 : 世界の データセンターの マトメ
2013年 : Open Compute Project の マトメ
2013年 : 日曜版 の マトメ

2014年:Agile Cat ソーシャル関連の マトメ

Posted in .Chronicle, Social by Agile Cat on December 21, 2014

数十億の人々が参加する、世界規模の壮大な実験・・・
http://wp.me/pwo1E-86E

ネットワークを介して、人と人をつないでいくと、なにが起こるのでしょうか? そして、人と人をつなぐために、なにをすれば良いのでしょう? また、なにを回避すべきなのでしょう? こんな問に対して、その人、その人の、答えがあるでしょうし、すべての人々にとって完璧な答えなど有り得ません。 しかし、さまざまな妥協をしながらも、人と人はつながっていきます。そして、そのパワーが、いまの IT をドライブしていく、最大の推進力になっています。

それは、この数年に渡って言われ続けていることであり、この 2014年も、やはりソーシャルが主役の年だったと捉えることができます。昨年の秋から言われていた、若者の Facebook 離れという説も、それほどの大ごとではなかったようです。言い換えれば、ソーシャルの多様性を証明した出来事でもあるのです。 そして、Facebook は WhatsApp を買収することで、この世界における支配力を、さらに強めていきました。

もちろん、Facebook と言えども、妥協の産物に過ぎません。そのため、そこら中に隙間が残されています。 たとえば、ビジネス・パーソンのための LinkedIn や、マイクロ・ブログ系の Twitter や Tumblr などがある一方で、ビジュアル系としては Pinterest や Instagram などが頑張っています。 そして、さらに、メッセージ系では WhatsApp や、WeChat、Line などが勢力を伸ばしています。

ーーーーー

01/02: Facebook はアメリカ市場でも成長し続ける:それを示す1枚のチャート
01/03: Snapchat には $100 Billion の価値がある:Marc Andreessen
01/14:
Facebook の ロシア侵攻が始まる:Yandex との提携が実現!
01/29: Facebook のアクティブ・ユーザー数が 12億人に達した
01/29:
Super Bowl 対決:勝つのは TV か、FB か、TW か?
01/30:
Facebook に若者離れは無いようだ
02/04:
Facebook が 10歳 になった:ステキな 手書きイラストで おめでとう!
02/20: Facebook の WhatsApp 買収:31本の報道記事リンク集
02/19:
WhatsApp:① 買収額の $19 Billion を、歴史の中に位置づけてみる
02/19: WhatsApp:② 10億人という ユーザー数に、FB よりも早く到達する?
02/21: WhatsApp:③ Facebook を上回る、ユーザーを惹きつけるパワー
02/20: WhatsApp:④ Skype や Line と、どのように世界を住み分ける?
02/21:
WhatsApp:⑤ 今年の試算だと、テレコムたちは $33 B も奪い取られる
02/20: WhatsApp:⑥ キャリアの SMS ビジネスを、メッセージ・アプリが破壊
03/04: Snapchat の CTO が、Google Cloud Platform Live に登壇する?
03/19: Twitter は、DM の暗号化を諦めてしまったのか?
03/27:
Line のユーザー数が 4億人に近づく:WeChat も WhatsApp も強敵だ!

04/09: インドの FB ユーザー数が1億人に達した:しかも 84% がモバイル接続だ
04/17:
Twitter の悩みは、なかなか増えないアクティブ・ユーザー数にある
04/22: 快速 WhatsApp は、すでに5億ユーザーに到達している!
05/04:
Twitter と Amazon が 提携:シンプルなタグでカートとツイートを直結!
05/08: LINE の収益が倍増している:どこに成長の秘密があるのか?
05/15: Youtube と Facebook がモバイル・トラフィックの 1/3 を占有している
05/23: B2C は Facebook で B2B は LinkedIn:大きく異なるソーシャルのシェア
05/27: Twitter も Asia を目指すことになる : しかし、マネタイズは大丈夫か?
06/26: 世界のメディアは モバイルのために存在する:それを示す1枚のチャート

07/17: Facebook が実験する BUY ボタン:Amazon や eBay にとって脅威に?
07/24: FB+WhatsApp+Instagram のユーザー数は、世界の総人口の 1/3 に!
07/28: Facebook Page for iPhone という、Apple にとって悩ましき存在とは?
08/09: Twitter ロゴの秘密:初代バージョンは タダ同然の $15 で買われてきた
08/11: Snapchat の凄まじい人気が、Twitter を追い抜いてしまった
09/03: Facebook が買収し続けている特許の内容が、とても興味深い
09/09:
Line in Thailand : ツーリスト・ポリスのスタンプが可愛い!
09/22: Facebook が語るモバイル・チューニングの極意:これで途上国も OK!
09/26: ソーシャルと滞在時間:Engagement Index 指標でも FB がダントツだ!
09/29: 香港での抗議を支える Off-The-Grid チャット: それが FireChat だ!

10/03: Yahoo が Snapchat に出資か? $10 B になるというウワサも流れている
10/20: FB アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!
10/28: Facebook の 2014 Q3 決算を分析する:モバイル広告の伸びがスゴイ!
10/28: Facebook がビッグ・ウェーブに乗った:収益の 66% はモバイル!
10/30: Facebook の Graph API がアップデートされ、AD API も強化!
11/05: iOS から Android へ : Facebook は優先順位を切り替えるのか?
11/06:
Twitter と MIT  の コラボ が、膨大なソーシャル・ストリームを分析
11/13: Facebook と Google によりソーシャル・ログインの 80% が占有
12/03: ダーク・ソーシャルが支配するオンライン共有の世界

ーーーーー

まさに百花繚乱。 モバイルという、数十年に一度の大波に乗って、ありとあらゆるソーシャル・メディアが、世界中に広がっていきます。 そして、何十億人というユーザーたちが、それぞれの距離感を大切にしながら参加することで、ソーシャル・メディアという壮大な実験を進めてきたのが、2014年という年なのでしょう。こうして、一年間のタイトルを並べてみると、そんな力強さを感じてしまいます。

ーーーーー

<関連>

2014年:クラウドの一年を 振り返る、チャート の マトメ
2014年:Agile Cat 日曜版の マトメ

ーーーーー

2013年 : OpenStack の マトメ
2013年 : Post-PC と 地殻変動 の マトメ
2013年 : Asia の 炸裂するパワーの マトメ
2013年 : 世界の データセンターの マトメ
2013年 : Open Compute Project の マトメ
2013年 : 日曜版 の マトメ

ダーク・ソーシャルが支配するオンライン共有の世界:それを示す1枚のチャート

Posted in Research, Social by Agile Cat on December 18, 2014

Dark Social Dominates Online Sharing
http://wp.me/pwo1E-86h
Niall McCarthy, December 3rd, 2014
http://www.statista.com/chart/3019/percentage-of-shares-by-sharing-channel/

_ Statista

Dark Social refers to web traffic coming from outside sources that cannot be tracked by analytics software. The term was coined back in 2012 and it happens when someone shares content or a link though communications formats such as emails, forum posts or instant messages.

ダーク・ソーシャルとは、分析ソフトウェアによるトラッキングが不可能な、外部からの Web トラフィックのことを指す。この用語が作られたのは、2012年のことである。それは、電子メールの送受信や、フォーラムへのポスト、そしてインスタント・メッセージの交換といったコミュニケーション方式により、人々がコンテントやリンクを共有するときに、発生する状況を示すものである。

This chart shows the percentage of shares by sharing channel.

このチャートは、それぞれの共有チャネルごとのシェアを示す。

Even though advertisers primarily focus their efforts on activities occurring in “the light” on platforms like Facebook and Twitter, Dark Social actually dominates online sharing, accounting for 69 percent of all shares globally. Europe and the UK in particular have become Dark Social strongholds, with 77 and 75 percent of all shares respectively occurring in the dark. In North America, that number is less at 59 percent but still considerable.

広告主が、Facebook や Twitter などの「ライト・ソーシャル」プラットフォーム上で生じるアクティビティに、主としてフォーカスしているにもかかわらず、グローバルにおけるオンライン共有の 69% が、実際にはダーク・ソーシャルにより支配されている。それらの中でも、とりわけ Europe と UK が、ダーク・ソーシャルの拠点となっており、それぞれにおけるシェアは、77% と 75% に達している。North America においては、そのシェアが 59% まで下がるが、それにしても、相当な比率となる。

ーーーーー

Agile Cat が使っている WordPress の Admin 画面では、それぞれのコンテントに関する PV 数や、リファラ件数(参照元)などが表示されるのですが、その数は常に一致しません。 そのズレ方も、日によってマチマチなのですが、PV 全体を 100% とすると、リファラが明確なものが 50% ほど、そして、Top Page の参照(ブクマ?)が 25% ほどです。 つまり、残りの 25% の参照元が不明なのですが、この部分がダーク・ソーシャルなのだろうと理解しています。 たとえば、A さんから B さんに送られたメールやメッセージに、Agile Cat へのリンクが貼られていて、それをクリックすることでコンテントを読んでもらっても、WordPress としては、どこから来たのか分からない、、、ということなのでしょう。そして、世間一般では、Agile Cat のケースよりも、もっと大きな比率を、ダーク・ソーシャルが占めているわけです。とても興味深いトレンドですね。

ーーーーー

<関連>

Facebook と Google によりソーシャル・ログインの 80% が占有されている
Twitter と MIT の コラボ が、膨大なソーシャル・ストリームを分析していく
ソーシャルと滞在時間:Engagement 指標でも Facebook がダントツだ!
Facebook が実験する BUY ボタン:Amazon や eBay にとって脅威になるのか?
Facebook Page for iPhone という、Apple にとって悩ましき存在とは?

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

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

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

ーーーーー

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

ーーーーー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Youtube ⇒

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ーーーーー

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

ーーーーー

<関連>

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

Facebook と Youtube が モバイル・トラフィックの 40% を占める 米国:それを示す1枚のチャート

Posted in Mobile, Research by Agile Cat on December 12, 2014

Facebook And YouTube Account For Almost 40% Of All Mobile Internet Traffic
http://wp.me/pwo1E-85R
Dave Smith – Dec. 9, 2014
http://www.businessinsider.com/facebook-and-youtube-account-for-almost-40-of-all-mobile-internet-traffic-2014-12

_ Business Insider

At Business Insider’s IGNITION event last week, Business Insider CEO Henry Blodget detailed the future of the digital landscape, pointing out some important trends. For example, more than a quarter of all internet traffic now comes from smartphones and tablets — and two big internet properties are responsible for a huge amount of that traffic.

先週に Business Insider が主催した IGNITION というイベントで、当社の CEO である Henry Blodget は、いくつかの重要なトレンドを指摘しながら、デジタルの世界の未来について詳しく説明した。たとえば、すべてのインターネット・トラフィックの 1/4 以上が、スマホとタブレットから発生している。また、2つの大きなインターネット・プロパティが、その膨大なトラフィックの要因となっている。

_  space

BI Intelligence

Based on data from a Sandvine report charted for us by BI Intelligence, Facebook and YouTube accounted for nearly 40% of all mobile web traffic in North America in September. Facebook accounted for 19% of that aggregate mobile traffic, YouTube was close behind with 18%, and the third largest share belonged to “general web traffic” through web browsers, at 11%. As BI Intelligence’s Mark Hoelzel points out, ads make up a big percentage of Facebook’s and YouTube’s mobile traffic, since autoplay video ads increase the mobile data demands on those social networks.

BI Intelligence がチャートにした、Sandvine レポートのデータをベースにすると、この 9月における北米の全モバイル Web トラフィックの約40%を、Facebook と Youtube が占めることになる。集計されたモバイル・トラフィックのうち、Facebook が占める割合は 19% であり、Youtube の 18% が僅差で続いている。そして、3番手は、Web ブラウザを介した、「一般的な Web トラフィック」の 11% となる。BI Intelligence の Mark  Hoelzel が指摘するように、Facebook と Youtube のモバイル・トラフィックにおいては、広告が大きな割合を占めている。なぜなら、自動的に再生されるビデオ広告が、これらのソーシャル・ネットワーク上のモバイル・データ量を、増加させているからである。

ーーーーー

アメリカ市場に限定した調査の結果ですが、まず、目を引くのが、Netflix に対する Youtube の圧倒的な強さです。 モバイルでは、こんな比率になる、、、というのが、正直な感想です。 また、今月は、モバイル・トラフィックを低減するための、Facebook の取り組みについて紹介してきましたが、それでも、これだけの帯域を消費しているのですね。 2年ほど前に、「Facebook が1位で、Google Maps が2位 : モバイル・アプリ 2012 ランキング」という抄訳をポストしましたが、こちらは、各モバイル・サービスにおける滞在時間を比較したものです。 今日のポストと比較すると、それぞれのサービスの性質が見えてきて、とても面白いです。

ーーーーー

<関連>

Facebook アプリ:Push + Delta + Thrift で モバイル帯域を 40% も削減!
Facebook が語るモバイル・チューニングの極意:これで途上国のインターネットも OK!
日本と世界のインターネット・トラフィック – 2014年/11月(アメリカ編)
急降下する Samsung のシェア:最新のスマホ勢力図を1枚のチャートで!
iOS と Android:これまでの出荷台数の推移を、1枚のチャートで!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On the server side Facebook also innovated:

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

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

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

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

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

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

ーーーーー

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

ーーーーー

<関連>

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

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

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

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

_ Business Insider

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

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

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

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

Stephan Ridgway
Flickr, CC

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

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

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

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

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

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

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

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

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

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

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

Wait, Android developers? Android-first, really?

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

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

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

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

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

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

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

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

ーーーーー

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

ーーーーー

<関連>

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

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: