Agile Cat — in the cloud

Big Data の調査:Google の DataFlow は、MapReduce の正当な継承者になり得るのか?

Posted in Big Data, Google, Hadoop, MapReduce, On Monday by Agile Cat on July 28, 2014

Data Cloud/Big Data: Google Introduces DataFlow as Successor to MapReduce
http://wp.me/pwo1E-7HE

By Dick Weisinger – July 25, 2014
http://formtek.com/blog/data-cloudbig-data-google-introduces-dataflow-as-successor-to-mapreduce/

_ formtek

Do you feel left behind when it comes to technologies like Hadoop and MapReduce?  The great thing about the rapid speed that technology is changing and obsolescing is that if you miss one trend it’s not long before it’s been superseded by something else.  That lets you leapfrog directly into the newer technology without having wasted time and resources on the older technology.  Although you’ve got to jump in sometime!

Hadoop や MapReduce といったテクノロジーの話になると、時代に取り残されていると感じるだろうか? そして、それらのテクノロジーにおける素晴らしいスピードは、それ自身を変化させ、また、旧式化させていく。 したがって、何らかのトレンドを見逃したとしても、それほど時間を置くことなく、それらに取って代わるものを見出すことができる。 つまり、古いテクノロジーに時間と資源を浪費することなく、新しいテクノロジーへ向けて、ダイレクトにジャンプすることが可能なのだ。 どんなタイミングでジャンプするのかという、課題は残されるのだけどね!

 Google announced in June that they’ve long ago dropped MapReduce technologies like Hadoop.  And in fact they’re even going to open up their ‘better way’ of analyzing Big Data sets to the public.  It’s part of the Google Cloud Platform.  And the components of the new Google technology called DataFlow have cool names like Flume and MillWheel.

Google が 6月に発表したのは、ずっと以前に MapReduce(Hadoop の原型)テクノロジーを廃止していたことである。実際のところ、Big Data の分析を開かれたものにするために、Google としての Better Way に取り組もうとしているのだ。それは、Google Cloud Platform の一部も構成する。この、Google における新しいテクノロジー・コンポーネントは、Flume MillWheel のようにクールな、DataFlow という名前を与えられている。

The limitation of MapReduce strategies are that they are run as batch jobs.  To use MapReduce and standard Hadoop, all the data needs to already exist and to have been collected before the job begins.

MapReduce ストラテジーにおける制約は、バッチ・ジョブとして実行される点にある。MapReduce や標準的な Hadoop を使用するには、そのジョブの開始する前に、存在すべき全データが揃っていなくてはならない。

Greg DeMichillie, Director of Product Management, wrote that ”a decade ago, Google invented MapReduce to process massive data sets using distributed computing.  Since then, more devices and information require more capable analytics pipelines—though they are difficult to create and maintain.  Cloud Dataflow makes it easy for you to get actionable insights from your data while lowering operational costs without the hassles of deploying, maintaining or scaling infrastructure. You can use Cloud Dataflow for use cases like ETL, batch data processing and streaming analytics, and it will automatically optimize, deploy and manage the code and resources required.”

Director of Product Management である Greg DeMichillie は、「 Google は 10年前に発明した MapReduce は、分散コンピューティングを用いて、大規模なデータセットを処理するためのものである。それ以来、より高機能な分析パイプラインが、数多くのデバイスと情報のために必要とされてきたが、それらを開発/維持していくのは困難なことであった。Cloud Dataflow を用いれば、それらのデータから、実用的な洞察を容易に得られるようになる。 その一方で、インフラストラクチャのディプロイ/メンテナンス/スケーリングに煩わされることもなく、運用コストを削減できる。この Cloud Dataflow は、ETL/バッチ・データ処理/ストリーミング分析のようなユースケースに対して、用いることが可能になっている。そして、必要とされるコードとリソースを、自動的に最適化し、展開し、管理していく」と述べている

Brian Goldfarb, Google Cloud Platform head of marketing, said that with Big Data that “the program models are different. The technologies are different. It requires developers to learn a lot and manage a lot to make it happen.  It [Google DataFlow] is a fully managed service that lets you create data pipelines for ingesting, transforming and analyzing arbitrary amounts of data in both batch or streaming mode, using the same programming model.”

Google Cloud Platform の Head of Marketing である Brian Goldfarb は、Big Data との対比について、「 プログラム·モデルが異なり、また、テクノロジーも異なる。それを実現するためには、デベロッパーが必要とするのは、より多くのことを学び、より多くのことを管理することである。Google DataFlow は、バッチとストリーミングのモードにおいて、同じプログラミング・モデルを用いて、大量のデータを洞察/変換/分析する、データ・パイプラインを作成するための完全なマネージド・サービスである」と発言している

Urs Hölzle, senior vice president of technical infrastructure Google, said that ”Cloud Dataflow is the result of over a decade of experience in analytics.  It will run faster and scale better than pretty much any other system out there.”

Google の Senior VP of Technical Infrastructure である Urs Hölzle は、「 Cloud Dataflow は、分析における、私たちの 10年以上にもおよぶ経験から生まれたものである。 それは、他のシステムと比べて、高速で動作し、スケーリングにも優れている」と、述べている

ーーーーー

Todd Hoff さんの、「Google Instant では、リアルタイム検索のために MapReduce を排除!」というポストによると、Google が MapReduce を止めたのは 2010年ということになります。 それから、すでに、4年が経っているのですね。 Hoff さんは、「 Google の 3つの世代を振り返る – Batch, Warehouse, Instant 」という素晴らしい記事も書いています。 どちらも、読み応え 十分の記事ですが、よろしければ ど〜ぞ!

ーーーーー

<関連>

Cloud の調査:マイグレーションの期間は終わり、クラウド・ネイティブ・アプリの時代が始まる
SaaS and ECM の調査:クラウドは何も失わず、メリットだけを提供する
Cloud の調査: Docker によるアプリのパッケージ化は、大きな実績を残し始めている!
Cloud の調査: すべては Hybrid へと集約されていくのか?
Big Data の調査:未来においても Hadoop の支配は続くのか?

Snapchat の CTO が、Google Cloud Platform Live に登壇するということは?

Posted in Events, Google, SnapChat, Social, Web Scale by Agile Cat on March 15, 2014

Snapchat CTO and co-founder Bobby Murphy to appear at Google Cloud Platform Live on March 25
http://wp.me/pwo1E-7jG

Posted: Tuesday, March 4, 2014
http://googlecloudplatform.blogspot.jp/2014/03/snapchat-cto-and-co-founder-bobby.html

Bobby Murphy, CTO and co-founder of Snapchat, will be joining Google Senior Vice President Urs Hölzle on stage during the keynote of Google Cloud Platform Live. Bobby will be sharing his experience building one of the world’s most popular apps on Google Cloud Platform.

Snapchat の CTO and  Co-Founder である Bobby Murphy だが、Google Cloud Platform Live でキーノートを務める Senior VP Urs Hölzle のステージに登壇するようだ。 そして、Bobby は、この世界で大人気のアプリを Google Cloud Platform で、構築したときのエクスペリエンスを共有することになる。

Snapchat’s users share over 400 million snaps everyday.

なんせ、Snapchat のユーザーたちは、400 million 以上のスナップを、毎日のように飛ばし合っているのだ。

Google Cloud Platform Live is taking place 3 weeks from today. Bobby will be joining a great line up of other speakers, including Google Senior Fellow Jeff Dean. We’ll announce new features, take a deep dive on tips, tricks and technology, and share our vision for the future of cloud computing.

Google Cloud Platform Live は、3週間後に開催される。そして Bobby は、Google の Senior Fellow である Jeff Dean といった、素晴らしいスピーカーたちによるラインナップに参加する。私たちは、そこで提供される新しい機能や、ティップス、テクノロジーを追いかけ、また、このクラウド・コンピューティングにおける未来のビジョンを共有していく。

We are nearly at capacity in all our locations, but for people who are still interested in attending you can request an invitation to join us in-person in San Francisco or attend a livestream of the keynote at Google New York City, Google Seattle or Google London. And for those who can’t make it in person, you can always tune in online.

すべてのロケーションにおいて、私たちのキャパシティは満杯に近いが、参加したいのなら San Francisco にリクエストして欲しい。 また、 Google New York City および、Google SeattleGoogle London でも、ライブ・ストリームが提供される。それも無理な人は、オンラインで参加することも可能だ。

ーーーーー

imageSnapchat が Google Cloud Platform というのは意外ですが、ウルトラ・ハイパー・スケールを狙っている同社が、このようなスター・プレイヤーを誘致したとしても、それは、それで、ナルホドと思える話です。 Nameservers を調べてみたら GoDaddy なのですが、システムの本体は Google にあるということなのでしょうか? ついでに、Whatsapp も調べたら、Nameservers は SoftLayer になっていました。 なんか、ワクワクする展開ですね。ac-stamp-232

ーーーーー

<関連>

Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する
GCE が正式にリリースされた : どのようにして、AWS と戦っていくのか?
Google Compute Engine は、どこで Amazon AWS を上回るのか?
GCE の登場で、どのような影響が IssS 業界に?
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2

VMware の考える SDN は、OpenFlow だけでは完成しない

Posted in .Selected, OpenFlow, SDN, VMware by Agile Cat on April 25, 2012

VMware isn’t going to let network virtualization pass it by
http://wp.me/pwo1E-491
By
Stacey Higginbotham Apr. 11, 2012
http://gigaom.com/cloud/vmware-isnt-going-to-let-network-virtualization-pass-it-by/

_ Gigaom

VMware teamed up with Stanford and Berkeley on Tuesday to create an industry consortium around software defined networks, called the Open Networking Research Center. The company, famous for hypervisors that virtualize servers isn’t about to watch while companies attempt to build the same disruption in networking. The consortium counts CableLabs, Cisco, Ericsson, Google, Hewlett-Packard, Huawei, Intel, Juniper, NEC, NTT Docomo, Texas Instruments and VMware as its founding sponsors.

この火曜日に VMware は、Open Networking Research Center という SDN に関する業界コンソーシアムを立ち上げるために、Stanford および Berkeley とチームを構成した。 いくつかの企業は、ネットワークにおける急激な刷新(破壊)を共有しようと試みるが、サーバーの仮想化において、つまりハイパー・バイザで実績を積み上げてきた同社は、そのようには見ていないようだ。なお、このコンソーシアムは、CableLabs/Cisco/Ericsson/Google/Hewlett-Packard/Huawei/Intel/Juniper/NEC/NTT Docomo/Texas Instruments/VMware を、そのファウンディング・スポンサーとして数える。

Much as server virtualization abstracts the hardware for the software that runs on it, allowing people to put different virtual machines on top of one server, virtualizing the network abstracts the cables and ports from the demands of the applications. But that’s not enough. To really achieve the flexibility that webscale and cloud companies demand, the network must be both virtualized and programmable.

サーバーの仮想化はハードウェアを抽象化し、その上でソフトウェア走らせるようにする。 そして、その数だけの仮想マシンを、1台のサーバー上に配置できるようにする。 さらに、ネットワークの仮想化は、アプリケーションの要求に応じて、ケーブルとポートを抽象化していく。 しかし、それでは十分と言えない。 Web スケールとクラウド・カンパニーが必要とする柔軟性を、ほんとうの意味で達成するには、仮想化とプログラマブルという要因をネットワークに加えなければならない。

The current enabler for this shift in networking is OpenFlow, a protocol developed out of Stanford and championed by a group formed last March called the Open Networking Forum. Many of the companies that have joined the VMware at the ONRC are also members of the ONF, including VMware. OpenFlow is a means to separate the intelligence associated with moving packets around the network with the gear that does the moving. At that point the intelligence can run on commodity servers, a factor that was seen as bad news for Cisco, Juniper and other networking companies which may see their margins drop and profits erode.

現時点において、このネットワークのシフトを可能にする存在は、Stanford で開発されたプロトコルの OpenFlow となる。それは、この 3月に組織化された、Open Networking Forum というグループにより支持されている。 ONRC で VMware と行動をともにする数多くの企業は、この ONF のメンバーであり、また、VMware も参加している。 OpenFlow とは、パケットを転送する装置を用いて、ネットワーク上を飛び交うパケットから、インテリジェンスを分離するための手段である。 その点において、このインテリジェンスは普及品サーバーで動作するため、Cisco や Juniper などのネットワーク・デバイス会社にとって BAD ニュースとなる。 なぜなら、それらの企業はマージンが下がり、利益が圧迫されるからだ。

imageAllwyn Sequeira, CTO and VP for security and networking for VMware says that the creation of the ONRC is designed to push the concepts of software defined networks in general rather than the OpenFlow protocol. He said an SDN requires three elements: a controller that manages the networking gear; the controller protocol fused to control the devices (this may not be OpenFlow); and the apps on top of the controller that direct the network.

VMware の CTO であり、 VP for Security and Networking でもある Allwyn Sequeira は、OpenFlow プロトコルというより SDN のコンセプトをプッシュするところに、ONRC を結成した意味があると発言している。 SDNを構成するには、① ネットワーク・ギアを管理するコントローラおよび、② いくつかのデバイス(OpenFlow 非対応も含む)を制御するために結合されたプロトコルのコントローラ、そして、③ コントローラを介してネットワークを操作するアプリケーションという、3つの要素が必要になると彼は言う。

And he notes that OpenFlow adds the critical element of programmability to networking, likely residing in the controller with other protocols, but the creation of a software defined network doesn’t need it. He points to VMware’s own firewall and load balancing products as well as its VXLAN and other networking software as an example.

また、OpenFlow などのプロトコルを用いる既存のコントローラには、ネットワークをプログラミングするための重要な要素が加えられているが、それらが SDN の作成において必要とされることはない、彼は指摘している。 なぜなら、VMware のファイヤー・ウォールやロード・バランシングのプロダクトに加えて、VXLAN などのネットワーク・ソフトウェアが、その例として挙げられるからだと、彼は言う。

VMware’s networking products.

That’s a common argument from the industry, with folks from Juniper and Cisco pointing to their existing fabrics and products as an example of network virtualziation. So the key for the ONCR and the industry moving forward seems to be about how to make SDNs programmable since they already exist. Sequeira says this requires OpenFlow.

それは、仮想ネットワークの例として、現存のファブリックとプロダクトを指し示す、Juniper や Cisco のテーマというより、この業界における共通のテーマとなる。 この業界と ONCR には、すでに存在する資産があるため、SDN をプログラマブルにする方式が重要となり、また、それを模索しながら前進していくと思われる。 そして Sequeira は、そのために OpenFlow が必要になると発言している。

“We had a complete SDN stack with no OpenFlow and it was good enough for almost all the things that customers wanted to do,” Sequeira said. “There is the virtualization of the switches and firewalls and none of that requires OpenFlow. However, to program it requires OpenFlow even though even a little of that can be done without it.”

「 私たちは、OpenFlow に頼ることなく、完璧な SDN スタックを積み上げており、それは、ほとんど全ての顧客の要求に対応できる。 スイッチとファイアーウォールの仮想化は存在しており、そこでは、少しも OpenFlow を必要としない。 しかし、それをプログラムするためには、すべてにおいて必要というわけではないが、OpenFlow が要求される」と Sequeira は発言している。

And while Sequeira recognizes the importance of OpenFlow, he doesn’t see some wholesale migration to OpenFlow-only networks. Current networking software and gear will work with OpenFlow but will not solely use the protocol. Which, given the statements by Urs Hölzle, SVP of technical infrastructure at Google, that there is no easy way for OpenFlow to communicate with other network protocols, have me thinking that we’re going to need more efficient ways to communicate from one network protocol to OpenFlow.

そして Sequeira は、OpenFlow の重要性を認識する一方で、いくつかの Wholesale は OpenFlow-ony ネットワークへ移行しないだろうと見ている。 最新のネットワークを構成するソフトウェア/ギアは、OpenFlow に対応するだろうが、そのプロトコルだけを使うわけではない。 Google の VP of Technical Infrastructure である Urs Holzle のステートメントを前提にすると、OpenFlow と他のネットワーク・プロトコルを連携させるための、容易な方式は無いということになる。 つまり、こうした現実から生じるものとして、他のネットワーク・プロトコルから OpenFlow にコミュニケートするための、より効率の良い方式が求められるようになってくる。

So the biggest battle in SDNs looks like it will be for the controller, which companies such as IBM, Nicira and Big Switch have developed. The question is: will OpenFlow be the lingua franca between rival controllers or will each strive to create it’s own proprietary network — programmable, running on commodity hardware, but still a fundamentally locked ecosystem?

したがって、SDN における最大のバトルは、IBM/Nicira/Big Switch などが開発を進めている、コントローラに関するものになるだろう。 残される疑問は、以下のとおりである。 まず、OpenFlow は、ライバルであるコントローラ間の共通語になる気があるのか? それとも、それぞれのプロトコルは、自身によるプロプライエタリ・ネットワークを構築するために競い合うのか?つまり、プログラマブルであり、コモディティ・ハードウェア上で走るにしても、基本的にはロックインされているエコシステムに過ぎないのか?

Related research and analysis from GigaOM Pro:

ーーーーー

TAG indexこの辺りの、OpenFlow をめぐる議論が、これから活発になってくるのでしょうね。 以前にポストした「OpenStack における SDN コネクションを探求する」にも、似たような記載がありました。 これは、OpenStack に OpenFlow を取り込む場合の記事ですが、VMware の指摘と同じことが語られています。 前後編で、ちょっと長いですが、お薦めのコンテントです。 ーーー __AC Stamp 2

したがって、OpenStack における Quantum と OpenFlow は、機能的に補完関係にあると説明されている。 ただし、Urquhart が指摘するように、OpenFlow の位置づけは、Quantum 抽象概念上のプラグインから利用できる、1つのメカニズムに過ぎない。 その点について、心に留めておいてもらいたいのは、OpenStack wiki で詳細に記述されるように、「OpenStack ネットワークにプラグインされる先進的なネットワーク・サービス(オープン・ソース/クローズド・ソース)」を構築するために、また、先進的なネットワーク機能を導入する、新しいプラグインの開発を容易にするために、Quantum  の利用が可能だという点だ。

ーーーーー

<関連>

Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow 関連ポストへのリンク集(20本強)

 

Google と OpenFlow と SDN について本音を語ろう – Urs Holzle

Posted in .Selected, Google, OpenFlow by Agile Cat on April 20, 2012

Google’s next OpenFlow challenge: taking SDNs to the consumer
http://wp.me/pwo1E-48b
By
Stacey Higginbotham Apr. 17, 2012
http://gigaom.com/cloud/googles-next-openflow-challenge-taking-sdns-to-the-consumer/

_ Gigaom

Google is running all of its backbone traffic on a software-defined network built using OpenFlow, and it hopes that this year it can begin the process of extending that type of programmable network to its consumer-facing network: the network that delivers applications such as Maps and YouTube to consumers and businesses. Urs Hölzle, SVP of technical infrastructure and Google Fellow, today at the Open Networking Summit detailed how Google is using OpenFlow on its network to lower costs and reduce complexity, which I wrote about last week.

Google は、すべてのバックボーン・トラフィックを、OpenFlow を用いて構築した SDN 上で走らせている。そして、今年は、この種のプログラマブル・ネットワークが、コンシューマと接するネットワークにまで、拡大していくプロセスが始まることを希望している。 つまり、そのコンシューマ対応のネットワークとは、一般消費者や企業に対して、Maps と YouTube といったアプリケーションを配信するネットワークのことである。 Google の SVP of Technical Infrastructure である Urs Holzle は、今日の Open Networking Summit で、同社における OpenFlow の用法について説明した。それは、先週に私が書いたように、ネットワークの複雑さを、より低コストで解決していくというものであった。

Urs Hölzle, SVP of technical
infrastructure at Google

But in that talk he also said that Google hopes to build an SDN that could handle the far more complex and important types of traffic that it delivers to users. That network requires much more reliability and also has to interface with far more devices and protocols, making the task of turning it into an SDN more fraught. As an example, Hölzle told me he expects the internal WAN network to achieve a 99.95 or a 99.99 percent reliability rate (it’s not quite that yet) but any user-facing service has to achieve something closer to the telecom ideal of five nines.

その話の中で、Google が望むものは、ユーザーに配信される遥かに複雑で重要なトラフィック・タイプを、SDN の構築により処理することだとも、彼は説明している。 そのネットワークは更なる安定性を必要とし、また、より多くのデバイスおよびプロトコルとインタフェースを取らなければならない。その結果として、SDN への置き換えるべきタスクが、さらに膨らんでくる。 例として Holzle が挙げたのは、インターナル WAN ネットワークが 99.95%~99.99% の安定レート(まだ、そこまでい届いていない)を達成することを、彼が期待していることだ。しかし、いかなるユーザーと接するサービスであっても、ファイブ・ナインというテレコムに理想に近い値を達成しなければならない。

Another issue associated with changing the external network to a software-defined network is the gear. In his talk, Hölzle explained the type of gear Google began building in 2010 in order to build this OpenFlow network. It was a basic switch using merchant silicon and running almost no software, just the software needed to get it up and running, and an OpenFlow agent. Everything else was handed off to a controller.

エクスターナル・ネットワークの SDN への置き換えに付随する、もう1つのテーマはネットワーク・ギアである。 彼の話によると、同社における OpenFlow ネットワークを構築するために、この種の装置を、Google は 2010年から作り始めている。 それは、ベーシックなスイッチであり、商用の半導体を用い、ソフトウェアはほとんど走らせないものとなる。 ただし、起動と実行のために必要なソフトウェアと、OpenFlow エージェントだけは例外である。そして、その他のすべてが、コントローラに受け渡された。

imageBut to take such a network to the external site, Google wants someone else to build the hardware. Hölzle says it does look like firms will build the type of gear he wants that uses OpenFlow as the management API, and he expects Google to start looking at the problem of how to move the external-facing network to an SDN this year. That doesn’t mean it will happen anytime soon–although Google did manage to transfer all of its WAN traffic to an OpenFlow network in two years–but that it will happen.

しかし、このようなネットワークを外部サイトに展開するためにも、誰かがハードウェアを作ってくれることを、Google は期待している。 彼の望むネットワーク・ギアをつくる企業は、マネージメント API として OpenFlow を使う事になると、Holzle は言う。そして、Google は年内までに、外部に接するネットワークを SDN に置き換える方式において、どのような問題が生じるのか、それに注目してきたいと付け加えている。 それは、直ぐにというものではないが、必ず実現される。なぜなら、Google は 2年の歳月をかけて、すべての WAN トラフィックの、OpenFlow ネットワークへの移行を、成し遂げているからだ。

And that’s important because the same cost savings that Google is seeing on its WAN network could end up helping lower the cost of delivering bits over consumer broadband networks, and thus help ISPs reduce their costs. Hölzle hopes that might reduce the need for ISP network protection schemes such as broadband caps, but I’m not as optimistic.

そして、こうした一連のことが重要な理由は、コンシューマ・ブロードバンド・ネットワーク上で配信するコストを、Google の WAN ネットワークが低減してきたことを、同社が確認していることであり、また、その方式が ISP のコストを低減させる点にある。さらに 、ISP ネットワークのプロテクション・スキームである、たとえばブロードバンド・キャップなどの必要性を低減することも、Holzle は望んでいるようだが、私は それほど楽天的にはなれない。

Related research and analysis from GigaOM Pro:

 

ーーーーー

TAG index先週にポストした「Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには」の続編という感じですね。Santa Clara で開催された Open Networking Summit からは、Google による OpenFlow のコミットという話が伝わってきていますが、おそらく、この記事も前回と同様に、Holzle さんへの事前のインタビューから起こされたのでしょう。 そして、Summit の終了後なら公開できる内容を、まとめているのだと思います。Google による OpenFlow と SDN への取り組みが、どのように進んでいくのか、とても楽しみですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

クリエーションラインが展開する、CloudStack/MidoNet/Cloudian 統合戦略とは?
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow を使うのは 誰? – NEC に聞く
OpenFlow と Big Data の 深い関係について

Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには

Posted in .Selected, Google, OpenFlow, SDN by Agile Cat on April 11, 2012

How Google is using OpenFlow to lower its network costs
http://wp.me/pwo1E-46j
By
Stacey Higginbotham Apr. 9, 2012
http://gigaom.com/cloud/how-google-is-using-openflow-to-lower-its-network-costs/

_ Gigaom

Google is checking out a new form of networking protocol known as OpenFlow in the communications networks that run between its data centers. The search giant is testing the use of software-defined networks using OpenFlow in order to lower the cost of delivering information between its facilities, says Urs Hölzle, SVP of technical infrastructure and Google Fellow in an interview with me.

Google は、データセンター間を結ぶコミュニケーション・ネットワークにおいて、OpenFlow として知られる新しい形式の、ネットワーク・プロトコルを調査している。 この検索の大手は、そのファシリティ間で情報を配信するコストを低減するために 、OpenFlow を用いる SDN(Software Defined Networks)をテストしていると、Google Fellow であり SVP of Technical Infrastructure でもある Urs Holzle が、私とのインタビューで話してくれた。

Google’s infrastructure is the stuff of engineer dreams and nightmares. The company’s relentless focus on infrastructure has led it to create a competitive advantage because it can deliver search results faster and for less money than the next guy. Much like Dell conducts studies showing that lowering a table where people assemble its computers saves seconds and costs, Google understands that investing in infrastructure can help it shave a few cents off delivering its product. And the next area that’s ripe for some infrastructure investment might be networking, specially using the OpenFlow protocol to create software defined networks.

Google のインフラストラクチャには、エンジニアの夢と悪夢が詰め込まれている。 そして、同社のインフラに対する執拗なフォーカスにより、競争上の優位性が引き出され、誰よりも速く安く検索結果を届けるという結果をもたらしてきた。 Dell などの数多くの企業は、コンピュータをアセンブルする際の、時間の短縮とコストの低減を実現するための研究を行なっている。 その一方で Google は、インフラへの投資により、オンライン配信における数セントの削減が、積み上げられることを理解している。 そして、いくつかのインフラストラクチャ投資における次の領域として、OpenFlow プロトコルを活用した SDN 構築という目的がある。

For Google, at a certain point, communications between servers at such a large-scale can be a problem, notes Hölzle, who is speaking at the Open Networking Summit in Santa Clara next week. He explains that the promise of OpenFlow is that it could make networking behave more like applications thanks to its ability to allow the intelligence associated with networking gear to reside on a centralized controller.

Google の場合には、あるポイントにおいて、このようなラージ・スケールのサーバー間で、コミュニケーションに問題が生じるかも知れないと、来週に Santa Clara で開催される、Open Networking Summit のスピーカーでもある Holzle は指摘している。OpenFlow がもたらすものは、ネットワークをアプリケーションのように振る舞わせることであり、センタライズされたコントローラの中に、インテリジェントに組み合わされたネットワーク・ギアを論理的に配置していく能力だと、彼は説明する。

Previously, each switch or piece of networking gear had its own intelligence that someone had to program. There was no holistic view, nor a way to abstract out network activities from the networking hardware. But with OpenFlow the promise is you can program the network and run algorithms against it that can achieve certain business or technical goals.

これまでのスイッチやネットワーク・ギアは、誰かがプログラムしなければならない、それら自身のインテリジェンスを持っていた。 そこには、全体論的な視野が無く、また、ネットワーク・ハードウェアから離れて、そのアクティビティを抽象化する術もなかった。 しかし、OpenFlow を用いることで、ビジネスおよびテクニカルにおける特定のゴールを達成していくための、ネットワークのプログラミングと、アルゴリズムの実行が約束される。

“I think what we find exciting is OpenFlow is pragmatic enough to be implemented and that is actually looks like it has some legs and can realize that promise,” he said. However, he added, “It’s very early in the history and too early to declare success.”

「私たちが気づいている気分の高揚は、プログラムによる OpenFlow の実装が十分な意味を持ち、また、実際にいくつかの経路を利用できそうなことだ。 それにより、目論見を実現できそうだと、私は考えている」と、彼は発言している。 しかし、「その歴史はきわめて短く、また、成功を宣言するにはあまりにも早すぎる」とも、付け加えている。

Google is trying the protocol out between data centers, although Hölzle didn’t disclose details about how much Google is saving and how widespread the implementation is. Hölzle said the search giant was trying to see how it could make its wide-area network and long-distance network more flexible and speed up the delivery of services to users without adding costs. However, costs for Google aren’t just measured in terms of bandwidth, but also in terms of people required to operate the network or configuring it.

Google は、データセンター間のプロトコルについては公表しようとしているが、その範囲と費用対効果について、Hölzle は詳細を明らかにしなかった。 Holzle が言うには、この検索の大手が確認しようとしているのは、広域におよぶ長距離ネットワークの柔軟性を、さらに高めるための方式であり、また、コストを増大することなく、ユーザーに対するサービスの配信を高速化する方法である。 しかし、Google におけるコストは、ネットワークの帯域幅という観点でけでは測定できない。つまり、ユーザーが必要とする運用や設定という視点も、欠かせない要因となる。

TAG index“The cost that has been rising is the cost of complexity — so spending a lot of effort to make things not go wrong. There is an opportunity here for better network management and more control of the complexity, and that to me is worth experimenting with,” Hölzle said. “The real value is in the [software-defined network] and the centralized management of the network. And the brilliant part about the OpenFlow approach is that there is a practical way of separating the two things: where you can have a centralized controller and it’s implementable on a single box and in existing hardware that allows for a range of management and things that are broad and flexible.”

「コストにおける上昇分は、複雑さからくるものである。 つまり、物事を間違った方向へ向かわせないように、膨大な労力を費やしていることになる。 そして、より良いネットワーク管理を実現し、複雑さをコントロールするチャンスがある。それが OpenFlow であり、また、私にとって実験する価値のあるものとなる。現実の価値は、SDN の中にあり、また、ネットワークのセンタライズされた制御の中にある。 そして OpenFlow アプローチの素晴らしい部分は、2つのものを切り離すための、現実的な方式を提供する点である。 センタライズされたコントローラーを利用でき、また、シングルボックスもしくは既存のハードウェア上に、それを実装できるなら、幅広い管理が実現され、また、物事に広がりと柔軟性が提供される」と、 Holzle は言う。

But OpenFlow still requires some work. Hölzle said that there are issues with how you communicate between OpenFlow networks and those that aren’t. So, today, Google takes its OpenFlow traffic and hands it over to a router running alternative network protocols such as MPLS or BGP, what Hölzle calls a “normal” router. He expects that to change over time as things standardize within OpenFlow and among vendors. As he said at multiple times throughout the conversation, these are early days for OpenFlow and software-defined networks.

しかし、OpenFlow には、いくつかの課題が残されている。 Holzle は、OpenFlow ネットワークと、それ以外のネットワークを結ぶ通信の方法に問題があると発言している。 したがって、いまの Google では、受け取った OpenFlow トラフィックを、MPLS もしくは BGP などのネットワーク・プロトコルを実行するルーターに手渡している。 それらについて、Holzle は NORMAL ルーターと呼んでいる。そして、それらのものが、OpenFlow の中で、あるいはベンダー間において、長い時間をかけて標準化されていくと、彼は予想している。この会談において、彼が何度も繰り返して言ったように、OpenFlow と SDN(Software Defined Networks)は黎明期にある。

Related research and analysis from GigaOM Pro:

 

 

ーーーーー

TAG index他にもあるのでしょうが、Agile_Cat が知るかぎり、Google が OpenFlow や SDN について初めて語るコンテントです。 価値は、OpenFlow ではなく SDN にあるとは、とても良い言葉で、さすが Google 先生と言わざるを得ません。 また、DC の 内と外では、使うべきプロトコルが違いますよと示唆しているようにも聞こえます。 来週の Open Networking Summit では、どんな発表があるのでしょうか? とても楽しみです。 ーーー __AC Stamp 2

ーーーーー

<関連>

OpenStack における SDN コネクションを探求する _1
OpenStack における SDN コネクションを探求する _2
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow 関連ポストへのリンク集(20本強)

 

%d bloggers like this: