Agile Cat — in the cloud

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

Digital Ocean が IPv6 の完全サポートを発表:放置すれば クラウドの普及が IP アドレスの問題を悪化させる

Posted in Data Center Trends, Digital Ocean, Network by Agile Cat on October 9, 2014

Upstart cloud player Digital Ocean to roll out IPv6 worldwide
http://wp.me/pwo1E-7Wg

By Barb Darrow – Jun. 17, 2014
https://gigaom.com/2014/06/17/upstart-cloud-player-digital-ocean-embraces-ipv6/

_ Giga Om

Summary: Digital Ocean needs a ton more IP addresses for all those compute “droplets” it runs for customers. So it’s moving all its data centers to IPv6 by years’ end.

Summary: Digital Ocean は、その顧客たちが実行する、Droplets という名のコンピューティングのために、膨大な IP アドレスを必要としている。 それ故に、今年の末までに、すべてのデータセンターを IPv6 に移行するという。

photo
Digital Ocean

We’ve heard the IPv6 wave is coming — although none too soon — and Digital Ocean is going to ride it. The New York City-based IaaS provider plans to announce Tuesday that it is adding support for the new protocol — which will open up millions of new IP addresses — in its data centers in Singapore, Amsterdam, New York, and San Francisco.

以前から、IPv6 の波は来ているのだが、誰もが知らぬ素振りをする中で、Digital Ocean は乗ると決めたようだ。この New York ベースの IaaS プロバイダーは、無数の IP アドレスへ向けてドアを開ける新しいプロトコルのサポートを、Singapore/Amsterdam/New York/San Francisco のデータセンターに加えると、火曜日(6/17)に発表する予定である。

It’s a sort of rolling release, however. Singapore is up first, where the support will be tested out and the company will use that experience to implement across the other data centers, CEO Ben Uretsky said in a recent interview. All of those data centers should be fully aboard IPv6 by years’ end, he added.

しかし、このリリースでは大雑把すぎる。CEO である Ben Uretsky が最近のインタビューで語ったところによると、そのためのテストを行なっている Sigapore が、最初に IPv6 サービスを立ち上げ、そのエクスペリエンスを他のデータセンターに展開していくようだ。この年末までに、すべてのデータセンターは、完全に IPv6 に乗っているはずだと、彼は付け加えている。

With more mobile devices, sensors and — face it — virtual machines running in clouds coming online by the minute, the demand for unique IP addresses is exploding and that’s leading to IPv4 IP address exhaustion. “The issue is that IPv4 provides something like 4 billion unique addresses, which seemed sufficient in 1980 when the protocol was created, but nowadays there are billions of smartphones alone,” he noted. There are IPv4 workarounds, but they are not elegant, he said.

大量のモバイル・デバイスとセンサーに対応するためには、クラウド上の仮想マシンを次々と立ち上げ、オンライン接続していく必要がある。ユニークな IP アドレスに対する需要は爆発的なものとなり、また、IPv4 IP アドレスは枯渇へと向かっていく。Ben Uretsky は、「 IPv4 プロトコルが作成された 1980年当時には、40億の IP アドレスで充分だと思われていたが、そこに問題が生じている。しかし、いまでは、スマートフォンだけでも数十億台が存在しているのだ。IPv4 による、その場しのぎの回避策もあるが、エレガントではない 」と、指摘している。

The regional IP address authorities — the American Registry for Internet Numbers (ARIN) in the U.S. — have pretty much hit the bottom of the barrel. Uretsky said there are about 15 million IPv4 addresses left in the U.S. with Europe and Asia pretty much sold out, while there is some remaining capacity in Latin America and Africa. (Microsoft already occasionally assigns IP addresses from other regions to U.S. workloads and if Microsoft can’t get new IPv4 addresses you know we’re in dire straits.)

US におけるリージョナル IP アドレス管理組織である American Registry for Internet Numbers (ARIN) は、その枯渇を訴えている。 それでも、US には 1500万ほどの IPv4 アドレスが残っているが、Europe と Asia の状況は悪化しており、Latin America と Africa には若干の余裕があると、Uretsky は述べている。(すでに Microsoft は、US のワークロードに対して、他の地域からの IP アドレスを割り当てている。 このようなかたちで、Microsoft が新たな IPv4 アドレスを取得できなくなると、私たちは苦境に陥ると認識すべきだ)

Source: Akamai

“Cloud computing has accelerated pace of IP address consumption — each of these Droplets we sell and every single Amazon EC2 server needs one. Cloud vendors lowered the barriers to entry but we also exacerbated this address problem,” Uretsky said.

「 クラウド・コンピューティングにより、IP アドレスの消費ペースが加速している。 私たちが販売している個々の Droplets や、それぞれの Amazon EC2 などが、1つの IP アドレスを必要とする。クラウド·ベンダーにより参入障壁が引き下げられたが、このアドレスの問題を、私たちは悪化させている 」と、Uretsky は発言している。

What this means is that all the big cloud providers — Microsoft Azure, Amazon Web Services, Google etc — need to get off the stick vis-a-vis IPv6 support in their clouds which should happen sooner rather than later. (Google App Engine does support IPv6, as does Amazon’s ELB load balancing service.) IBM SoftLayer already supports IPv6 and Verizon Cloud, due out this year, also supports IPv6.

彼が言いたいのは、すべての大手クラウド・プロバイダーたち(Microsoft Azure/Amazon Web Services/Google など)が、IPv6 サポートに関する睨み合いをやめて、それぞれのクラウドにおいて、直ちに対応すべきという点に集約される(Google App Engine や、Amazon ELB load balancing service などは、IPv6 をサポートしている)。IBM Softlayer は、すでに IPv6 をサポートしている。 また、Verizon Cloud も、年内には IPv6 をサポートするとしている。

Related research

What developers should know when choosing an MBaaS solution Sept 2013
The importance of benchmarking clouds June 2014
Consumer products will drive enterprise breakthroughs June 2014

ーーーーー

最後のマトメを読むと、それぞれのクライド・プロバイダーが、IPv6 サポートに取り組んでいるようですが、この元気の良いスタートアップが、それらの先輩たちを急かしているように見えてきます。 文中にもあるように、1980年当時は 40億の IP アドレスで充分と思われたとしても、少なくとも 10億台近いスマホが、今年だけで増えそうというご時世なのですから、やはり、クラウド事業者には考えて欲しい問題ですよね。

ーーーーー

<関連>

これが DigitalOcean だ! AWS 以上のペースでサーバーを増し、ビヨンセ様の夢もかなえる!
DigitalOcean が シンガポールに上陸する! それを 支えるのは Equinix だ!
Akamai と OpenDNS が提携:もっと もっと Web を速くしたい!
Equinix が新たに展開する Performance Hubs とは?
Facebook と Open Compute から、Wedge という名の オープン・スイッチが発表された!
Cisco レポート 2014年版:モバイル・トラフィックの世界 No.1 は、日本の 1.87GB/月だ!

Akamai と OpenDNS が提携:もっと もっと Web を速くしたい!

Posted in Data Center Trends, Network by Agile Cat on August 29, 2014

Akamai signs deal with OpenDNS to make the web faster
http://wp.me/pwo1E-7Nn

By
Stacey Higginbotham – June 3, 2014
http://gigaom.com/2014/06/03/akamai-signs-deal-with-opendns-to-make-the-web-faster/

_ Giga Om

Summary: Akamai’s job is to speed up the web, but as more companies use alternative DNS services, that can be difficult. So it’s signed a deal with OpenDNS to get content to people faster.

Akamai の仕事は Web の高速化であるが、数多くの企業が代替の DNS サービスを使用するようになると、それも困難になり得る。したがって、より高速に、人々にコンテンツを提供するために、同社は OpenDNS と契約を締結することになった。

ーーーーー

Content delivery network Akamai is still attempting to speed up the web and it has teamed up with OpenDNS to add optimized DNS routing to its arsenal of services. For customers using OpenDNS, content hosted on Akamai’s servers will arrive faster — as much as four times fast in some cases. This is similar to the deal OpenDNS signed in 2011 with Google.

CDN を提供する Akamai は、さらに Web を高速化しようと試み、また、そのサービスの根幹である最適化された DNS ルーティングを追加するために、OpenDNS と提携することになった。それにより、OpenDNS を利用する顧客にとって、Akamai にホストされるコンテンツは、より高速に配信されることになり、また、いくつかのケースでは 4倍もの高速化が達成されるという。それは、2011年に Google が OpenDNS と提携したときに似ている。

photo
Mr. Vi/Thinkstock

Akamai signed this deal in January and now is announcing that it has implemented it in all of its locations. The partnership is based on a standard that attaches location data to a DNS request so a user’s request for content goes to server nearby. Typically, a CDN or content provider routes a user based on the address of the DNS server, as opposed to the user’s location, but they aren’t always in the same region, especially as more businesses choose alternative DNS providers such as OpenDNS, Dyn, Google’s service and others.

Akamai は、この契約を 1月に締結しており、いまでは、すべてのロケーションにおいて実装が完了していると発表した。そのパートナーシップは、DNS リクエストにロケーション・データを付加するという、スタンダードに基づいたものであるため、コンテンツに対するユーザー・リクエストは、最寄りのサーバーへと転送される。一般的に、CDN や コンテント・プロバイダーは、DNS サーバーのアドレスに基づき、ユーザーのロケーションとは反対の方向へと、ユーザーをルーティングしていくのだが、それらが、常に同じリージョンにいるとは限らない。 とりわけ、数多くの企業が、OpenDNS/Dyn/Google Service などの、代替の DNSプ ロバイダーを選択すると、その傾向が強くなる。

So now a user in Austin, Texas who types in the URL for a YouTube video will share part of his IP address as part of the DNS request. That way, the domain name system server can route the request to a Google data center in Dallas, as opposed to one in Ireland. This can substantially speed up access to content, which is what people hire Akamai for in the first place.

したがって、YouTube ビデオの URL を、Austin, Texas から入力するユーザーは、DNS リクエストの一部として自身の IP アドレスを共有することになる。この方式を用いれば、対象となる DNS サーバーは、そのリクエストを Dallas のGoogle データセンターへとルーティングできるようになり、Ireland に飛ばしてしまうようなことは、起こり得なくなる。そして、コンテントへのアクセスが、きわめて高速化されるが、人々が最初のロケーションとして Akamai を選ぶ理由も、そこにあるのだ。

Related research

How to deliver the next-generation web experience – January 2013
Infrastructure Q2: Big data and PaaS gain more momentum – July 2011
What to consider when architecting your organization for the cloud – May 2014

ーーーーー

いまから 2年ほど前に、「世界の DNS インフラも、地味ながら 頑張ってる!」という抄訳をポストしていますが、そこには、「5年前には、123 ヶ所の DNS ルート・サーバー・サイト(DNS のバックエンド)が、インターネット上に展開されていた。 それが、いまでは、2倍以上に膨れ上がり、300ヶ所を超すサイトが存在している」と記されていました。 そして、今日の記事を見る限り、DNS は更に進化しているようであり、また、Akamai がきわめて重要な役割を果たしていることも分かりますね。 もっと、もっと、Web を速くしてくださ~い。 

ーーーーー

<関連>

Akamai の 61,000 台のサーバーは、70カ国で 1,000 Networks をサポートする
この 3年間で、インターネット上での攻撃が 2000% も増えている – Akamai の調査
Akamai がダウンすると、インターネットも道連れに?
Rackspace と Akamai が、CDN サービスで提携
Akamai が 3.45 TBits / 秒のピークを記録

Facebook と Open Compute から、ついに Wedge という名の オープン・スイッチが発表された!

Posted in .Selected, Data Center Trends, Facebook, Network, Open Compute, Strategy by Agile Cat on June 20, 2014

Facebook to share first Open Compute Switch, the Wedge
http://wp.me/pwo1E-7AG

By Juha Saarinen on Jun 19, 2014
http://www.itnews.com.au/News/388499,facebook-to-share-first-open-compute-switch-the-wedge.aspx

Operates like an FBOSS.

Social networking site Facebook says it has built and is testing its first modular network switch, the Wedge, which it claims will provide the same power and flexibility as a server.

ソーシャル・ネットワーク・サイトである Facebook が言うには、初めてのモジュール式ネットワーク・スイッチである Wedge の構築が終わり、いまはテストの段階にあるようだ。 そして、この Wedge であるが、OCP サーバーと同様の、パワーとフレキシビリティを提供するという。

The work on the Wedge has been done by Facebook as part of the Open Compute Project, alongside vendors such as Broadcom, Intel, Mellanox and Accton which also contributed designs for open switches.

Wedge に関する作業は、 Open Compute Project 一環として、Facebook により完了しているが、いくつかのオープン・スイッチのデザインをコントリビュートした、Broadcom/Intel/Mellanox/Accton といったベンダーとの協業の結果でもある。

Facebook engineers Yuval Bachar and Adam Simpkins say the Wedge switch represents a departure from current networking design paradigms, and aims to run more like the existing OCP servers the company operates already.

Facebook のエンジニアである Yuval Bachar と Adam Simpkins は、この Wedge スイッチについて、現在のネットワーク・デザイン・パラダイムからの旅立ちを表現し、数多くの企業ですでに稼働している、現在の OCP サーバーのような世界を目指していると言う


クリックで拡大 ⇒

Hardware schematic of Facebook’s OCP Wedge switch

To achieve this, Facebook added a "Group Hug" microserver that punts packets inside the Wedge.

このアーキテクチャを実現するために、Facebook は Wedge の内部に、パケットを運ぶための Group Hug マイクロサーバーを追加している。

This is based on a 64-bit ARM-based AMD Opteron A1100 processor that was announced in January this year and is substantially smaller than the switching backplane form the 16 40 gigabit per second ports.

それは、今年の 1月に発表された 64 Bit ARM ベースの、AMD Opteron A1100 プロセッサをベースにしたものであり、16 個の 40 G bps ポートを構成する、既存のスイッチング・プレーンよりも、かなり小型化されている。

Facebook said it wants a proper server in the switch to bring the devices into their distributed management systems and run a standard Linux-based operating environment.

そして Facebook は、自身の分散マネージメント・システムにデバイスを取り込み、また、標準的な Linux を運用するスイッチのための、適切なサーバーを作り上げたいと述べている。

The Linux-based operating system for the switch is aptly named FBOSS and uses existing software libraries and systems that manage Facebook’s servers. This includes initial installation, upgrades, downgrades and decommissioning of systems in data centres.

このスイッチのための Linux ベース OS は、FBOSSという適切な名前を持つものであり、また、Facebook のサーバーを管理するために、既存のソフトウェア・ライブラリやシステムを使用するものとなる。このマネージメントの概念には、データセンター内における、イニシャル・インストールおよび、アップグレード、ダウングレード、システムの廃止などが含まれている。

Both the Wedge and FBOSS are being tested in Facebook’s network at present, ahead of the release of the designs to the OCP so that other members can use them.

いま、Wedge と FBOSS の双方が、Facebook のネットワーク内でテストされており、また、OCP のメンバーたちが利用できるようにするために、そのリリースへ向けてデザインを固めている状況にある。

The Open Compute Project was launched by Facebook in 2011 and aims to innovate open, scalable data centre technologies, with hardware and software that can be modified and replaced by users.

この Open Compute Project とは、2011年に Facebook により立ち上げられたものであり、ユーザーによる改変/置換が可能なハードウェア/ソフトウェアを用いて、オープンでスケーラブルなデータセンター・テクノロジーを革新していこうという目的を持っている。

Beyond server and networking technologies, the OCP is also advancing designs for storage, chassis, power supplies, device racks, energy-efficient, low-loss data centre electricity supplies, as well as cooling of facilities.

OCP の目指すものは、サーバーとネットワークのテクノロジーだけではない。具体的に言うと、最先端のストレージ/シャーシ/パワー・サプライ/ラックをデザインし、さらには、エネルギー効率の良い、省電力型のデータセンターを、クーリングも含めて検討していく。

Facebook is aiming to build all its new data centres with OCP designs, so as to enjoy benefits of economies of scale as well as rapid deployment, and lowered power usage.

Facebook は、すべての新しいデータセンターを、OCP デザインを用いて構築しようとしている。つまり、スケールを達成するだけではなく、デプロイメントの期間を短縮し、電力の消費量を引き下げることで、経済的なメリットを実現しようとしているのだ。

ーーーーー

2013年 1月に Santa Clara で開催された Open Compute Summit では、「モノリスを破壊する」というメッセージが発信されていました。 その中の一つに、この Wedge と命名されたオープン・スイッチの構想も含まれていたのでしょう。 それから、数カ月後に方針が示され、さらに1年を経て、このようなアーキテクチャによるプロダクトが整って来たわけです。この間のヒストリーについては、OCP Japan からコントリビュートされた、OCP News Archive:Open Switch で参照できます。 以下は、Open Compute による、モノリス破壊宣言です。

すべてにおいて、最もエキサイティングなのは一連の新規開発であり、これまでのテクノロジーをさらに有効利用していくための、大きなステップを与えてくれる。 1つの産業として、私たちが直面する課題は、そこで構築/消費されていくハードウェアが、きわめてモノリシックであるという点だ。つまり、私たちのプロセッサは、私たちのマザーボードと不可分であり、さらに言えば、特定のネットワーク・テクノロジーなどとも不可分である。こうした硬直した関係で、すべてが構成されているのだ。 そのため、急速に進化するソフトウェアに追いつくことの出来ないコンフィグレーションが、不完全なシステムへと導かれ、たくさんのエネルギーとマテリアルを浪費してしまう。

ーーーーー

<関連>

Facebook と OCP : オープン・スイッチ仕様を Broadcom と Intel と Mellanox が提出
Facebook は Open Compute のおかげで、この3年で 1200億円も節約できた!
Blu-ray ディスクを 10000枚:Facebook が考えるペタ/エクサ時代のコールド・ストレージとは?
SAP と HANA が、Open Compute に恋する理由
Open Compute Project : ついに Microsoft も参加を表明した!

 

%d bloggers like this: