GoogleのBigQueryによる大規模データ分析をGoogle DriveやGoogle Sheetsのユーザーにも可利用に…CloudとAppsの融合を進める

cbf_009

Googleが今日(米国時間5/6)、Google Cloud PlatformとGoogle Appsのツールを部分的に接近させるような発表を行った。Googleの、サーバー不要(serverless)の分析型データウェアハウジングサービスBigQueryが、これからは、Google Driveからファイルを読んだり、Google Sheetsのスプレッドシートにアクセスできるようになる。

これまでは、Googleのクラウドコンピューティングサービスと、Google Appsの消費者ないし企業向けの一連の生産性ツールは、まるで両者間にファイヤーウォールでもあるかのように、互いに遮断されていた。しかし今日Googleのスポークスパーソンが述べたところによると、同社は今、両サービスを統合するためのより良い方法を模索しており、それにより今後はGoogle AppsとGoogle Cloud Platformの両方を合わせたような、統一的ソリューションを提供していく予定だ。

Screen Shot 2016-04-05 at 1.09.27 PM

そのスポークスパーソンはこう語る: “Diane Greeneが何度か指摘したように、顧客はGoogleの複数のプロダクトを使っているので、弊社としてもエンタープライズチーム全体との協働により統一的なソリューションを作り、最良のユーザー体験を提供していきたい。今回の統合によって、高度で大規模なデータ分析を生産性アプリケーションのエンドユーザーが気軽に利用できるようになり、データ主体のワークロードを単純化し、エンタープライズの顧客がGoogle Cloud PlatformとGoogle Appsの両方を容易に使いこなせるようにしていきたい”。

具体的にはこうなる: ユーザーはBigQueryによる分析結果を直接、Google Sheets(“GoogleのExcel”)にエキスポートできる。またBigQueryから直接、Google Driveのファイルにアクセスして分析を行える(データをいったんBigQueryにロードする必要がない)。さらにBigQueryは、編集中のGoogle Sheetsにも直接アクセスできる。

ユーザーはGoogle Driveに、最大5TBまでのファイルを保存できる。BigQueryはもっと大きなデータベースでも楽に扱えるが、でもGoogle Driveからのユーザーは、もっと小さなファイルを使用/保有しているだろう。非常に大きなデータベースともなれば、BigQueryの料金も必ずしもお安くはないが、各月の最初の1TBのデータ処理は無料だから、小さなデータ集合やGoogle Drive上の大きなスプレッドシートでBigQueryを試すぶんには、ふところもほとんど痛まないだろう。

Screen Shot 2016-05-03 at 2.13.42 PM

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

GoogleがクラウドモニタリングツールStackdriverを改造してAWSとGoogle Cloudの統一的なビューを提供

screen-shot-2016-03-23-at-1-12-06-pm

今日(米国時間3/23)サンフランシスコで行われたGCPNext16で、GoogleがGoogle StackDriverのローンチを発表した。それはIT部門が全システムを統一的にモニタし、アラートを受け取り、異常事を管理し、ログを取り、これら各カテゴリーをダッシュボード上に視覚化して点検できる、という総合管理ツールだ。

Googleがマサチューセッツ州ケンブリッジのStackdriverを買収したのは2014年で、当時の同社は主にAWS上のクラウドのモニタリングをメインの業務としていた。Googleは同社のチームを支援して、AWSのサポートを続けながらGoogle Cloud Platform(GCP)もモニタリングの対象にできるようにした。

しかも今のStackdriver(“Google StackDriver”)は、単一のツールによるAWSとGCPの一体的管理とモニタリングが売りであるだけでなく、その高度なカスタム化を可能にしている。たとえば、CPUスパイクよりもむしろメモリスパイクがあるとアプリケーションが問題を起こす、という場合は、アプリケーションにメモリの問題が生じたときのアラートを報告させるようにできる。そうすれば、少なくとも理論的には、問題が制御不能の状態に陥る前に対策を講じられるだろう。

Stackdriverが記録するログを検索すると、GCPとAWSのクラスタを単一のインタフェイスで調べることができる。インスタンスが容量ぎりぎりになっていたらアラートするので、担当SVPのDiane Greeneは今日のキーノートで、クラウドのベンダが顧客の成功を確実化できる、という言い方をした。彼女によると、ベンダ(Google)は顧客の容量(インスタンスのサイズ)計画を助けられるし、リソースの追加が必要になれば早めにお知らせできる。これらのことで顧客は、頭を悩ます必要がなくなる。このツールは、そういったインサイトをユーザーに提供する。

そのためにこのツールは、エラー報告も出力する。これもまた高度なカスタム化が可能で、クラウド上で動いているアプリケーションの問題点を、ユーザーに警告する。

Greeneによると、このツールの主なねらいは、クラウドのインスタンスに今何が起きているかを視覚化して、簡単に分かるようにすることだ。それがGCPであっても、AWSであっても、同じように、そしてまた、柔軟性に富みカスタマイズの幅の大きいモニタリング環境であること。

基本的にGoogleはここで、二つのことをやろうとしている。ひとつは、GCPとAWSを一体的にモニタすることによって、AWSとは違う姿勢を見せつけること。そしてまた、自分たちもクラウドの技術者でありユーザーだから、技術者の仕事をやりやすくするためのツールならお手の物、という自分たちの強みの訴求だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Appleはインフラストラクチャ多様化の一環としてGoogleのCloud Platformを使用か

cbf_009

今日(米国時間3/16)飛び交っている噂によると、Appleは同社のクラウド事業の一部をAWSからGoogleのCloud Platformに移しつつある。本誌も独自に調べてみたが、確かにAppleはiCloudのストレージの多様化に努めているようで、その事業用としてGoogleも利用するようだ。

これは、いちばん控えめに言っても、Googleにとってはまた一つの大勝利で、AWSにとっては敗北だ。これまでも、Dropboxは合衆国におけるストレージ事業の相当量をAWSから自社内へ移したし、Spotifyはそのビジネスの少なくとも一部をAWSからGoogleへ移した。

これまでの試合経過を見ると、今月はGoogleにとってとくに良い月だった…とりわけ、同社のクラウドビジネスの新しいトップDiane Greeneにとっては。SpotifyやAppleのような有名企業が顧客なら、そのほかのエンタープライズ顧客もますますGoogleに魅(ひ)かれるだろう。GoogleのCloud PlatformはGoogle自身のデータセンターの技術がベースだが、しかしそのことはこれまで、AWSやMicrosoftのAzureに対する有利な競合要因になっていない。AWSには古顔の有利性があり、Azureの背後にはMicrosoftの強力な営業力とハイブリッドクラウド技術への特化がある。ただしAzureは、バックにいくら強力なMicrosoftがいても、クラウドビジネスではずーっと後方の二位だ。

まだ、プラットホームの移行に関するApple自身の意思決定の内容は不明だ。AWSやGoogleも、この件に関しては口をつぐんでいる。

某匿名情報筋によると、Appleは今確かに、複数のパブリッククラウドベンダ、中でもとくにMicrosoft AzureとGoogleを、自社のオプションとして検討している。しかしまだ、最終的な意思決定は行われていない。、なおAppleはすでにiCloudサービスやメディアのサービングにおいて、AzureとAWSを使っている。

要するに事態が本当に(今日の噂どおりに)‘AWSからの離脱’なのか、その辺も明確でない。ただしAppleが、クラウドのサプライヤーのポートフォリオの中身を多様化しようとしていることは、確かなようだ。

状況のもうひとつの側面として、今Appleはオレゴン州プラインビルのデータセンターを拡張中であり、合衆国とヨーロッパで新しいデータセンターも作るらしい。そして、これに今回の話が絡むのなら、AWSからGoogleへ、Googleからさらにプラインビルへ、という線はないだろう。新しいデータセンターの竣工を、単純に待つだろうから。

もしもAppleが、単純にインフラストラクチャの多様化を目指して、これまでのAzure、AWS、および自社データセンターに加えてGoogleも使う、ということなら、無理のない線だ。また、AppleがGoogleのクラウド上の特定のサービスを使うつもりなら、データ分析プラットホームBigQueryあたりが、ねらい目だろう。

われわれにとって既知の事項のひとつは、Akamaiの最近の決算報告だ。Akamaiはその中で、同社の最大のクライアントのうちの2社が、多様化しつつある、と言っている。“過去数年間にわたり、中でもとくに弊社の最大の二つの顧客 が、Akamaiの全体的な売上の約13%を占めてきた”、とAkamaiのCEO Tom Leightonが述べている。“2016年を展望するならば、これら二つのアカウントが依然として弊社の最大のメディア顧客であり続け、弊社の総売上の約6%に貢献するだろう。貢献率のこの7ポイントの変化は、彼らのDIY努力の増加がその原因であり、それは、今後の2四半期における、低い前年比売上増加率が予想される主な理由でもある”。

Akamaiの最大のクライアントがAppleであることは衆智だから、上の言葉は、AppleがCDN(Content Delivery Network)事業の一部も自社化しようとしていることを、意味している。

Googleは来週サンフランシスコで、大規模なクラウドイベントGoogle Nextを開催する。もしも(←これは確かにビッグな“もしも”だが)同社が、同社の新しい顧客について何かを発表するつもりなら、それはたぶん、このイベントにおいてだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Spotifyが音楽ストリーミングのインフラにGoogle Cloudを選ぶ

2016-02-24-spotify

今日(米国時間2/23)、音楽ストリーミングのSpotifyはブログ記事でGooogleと提携したと発表した。これにより、SpotifyはサービスのインフラストラクチャーとしてGoogle Cloud Platformを採用した。

これまでSpotifyは複数のデータセンターで各種ベンダーのハードウェアを利用して配信を行ってきた(データセンターにはAWSが含まれており、AWSブログでケーススタディーとして紹介されている)。しかしSpotifyはクラウド・プラッフォームが成熟段階に達し、全面的にアウトソースするに足る信頼性を獲得したと考えたようだ。

Spotifyは「われわれにとってGoogleのような市場のリーダーと組んで仕事をすることは一大事件」だと述べている。しかし逆にGoogleにとっても、Spotifyのようなこの分野のリーダーのサービスに全面的にホスティングを任されたことは「一大事件」だろう。Spotifyは全面的なクラウド化にあたってAWSの利用を拡大することもできたし、MicrosoftのAzureクラウドをプラットフォームに選ぶこともできたはずだ。

しかしSpotifyはダイアン・グリーンの指揮するGoogleのエンタープライズ・クラウドを選んだ。Googleクラウド・チームは去年の11月にマウンテンビューに買収されるまでは Greneが創業したBebopというスタートアップだった。

こうした買収では Googleは創業チームには十分な報酬を与えて別離を促すのが通例だ。しかしグリーンを新事業部のトップに据えたのは、Googleとしては彼女の能力に対する全面的な称賛に等しいといってよいだろう。Spotifyはこの提携について「極めて競争の激しいジャンルであり、予見しうる将来にわたってビッグ・プレイヤーによる戦いが続けられるだろう」と書いている。私はこの部分をだからいつでも提携先を乗り換えることができる」という意味に読んだが、そう取ったのは私だけかもしれない。

いずれにせよ、これでSpotifyのインフラ部門は巨大なストリーミング・サービスの運営という重荷を下ろすことができたのは間違いない。

〔日本版〕リンク先TechCrunch記事にもあるようにダイアン・グリーンはVMWareの共同ファウンダー、CEOであり、仮想化テクノロジーの普及に大きな功績があった。シリコンバレーの伝説的人物で2012年からはGoogle(現在は親会社のAlphabet)の取締役を務めている。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

Googleの画像認識/分類API、Cloud Vision APIが誰でも使える公開ベータへ

2016-02-17_1653

短期間、小規模なプレビューをやったあと、Googleは今日(米国時間2/18)、Cloud Vision APIの公開ベータを発表した。このAPIを使ってデベロッパーは、画像認識や分類の機能を自分のアプリケーションに持たせることができる。

Cloud Vision API 2

Googleの技術は、画像からテキストを取り出す、といった基本的なこともできるが、しかしその真価は、画像中の物を実際に認識できることにある。それはGoogle Photosの画像検索でも使われており、花とか食べ物、動物、各地の目標物などを見分ける。GoogleによるとこのAPIのアルゴリズムは、数千種類の物を認識できるよう訓練されている。

このAPIでいちばんおもしろいのは分類機能だと思うが、でもこのサービスは不適切なコンテンツを指摘することもできる。だからたとえば、写真中心のアプリケーションをPG級(保護者同伴必須)に指定したければ、Cloud Vision APIでそれを指定できる。また、集めた写真の中のハッピーな人だけを見たければ、このAPIの感情分析機能を利用できる。

料金は使い方によって異なるが、たとえば画像中に特定のラベルを見つけたいなら、1000画像あたり2ドルだ。単純な文字読み取りなら、1000画像あたり60セントとお安い。

  1. cloud-vision-1.png

  2. cloud-vision-2.png

ベータ中は数量制限があり、一人が1か月あたり最大2000万画像までしか扱えない。すでにプレビューの時点でこのサービスを実装した企業も数社あり、たとえばYik Yakは、このAPIを使ってテキストの取り出しと画像の特徴検出をやっている。

このVision APIは、MicrosoftのProject Oxfordなどと競合することになる(後者は現在プレビュー)。Project Oxfordには、コンピュータビジョンの機能や、顔認識、感情分析などの機能がある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleのクラウドプラットホームがカスタムマシンタイプを提供、CPU数とメモリ量を細かく指定可能

google-servers-datacenter

Googleが今日(米国時間11/18)、同社のクラウド上の仮想マシンの‘新しい買い方’をスタートした

これまでの仮想マシンは、Google Cloud PlatformやAWS、Azureなど、どこを選んでも、その‘買い方’はほぼ同じだった。CPUとRAMの構成に関する既定のセットがいくつかあって、計算処理を優先するかメモリ容量を優先するかによって、それらの中からどれかを選ぶ、という買い方だ。

しかしGoogleのCompute EngineでこのたびベータでローンチしたCustom Machine Types(カスタムマシンタイプ)では、仮想CPU(vCPU)の数とRAMの量をユーザが指定できる。

custom_machine_type-slider

従来は、vCPU二つで力不足になってきたら、既定のセットの中からvCPU四つのマシンタイプを選ぶ。当面三つで十分な場合は、お金の無駄遣いになってしまう。

今度の新しいCustom Machine Typesでは、最大32までのvCPUと、vCPU一基あたり6.5GiBまでのメモリをユーザが指定できる。正確を期すことが大好きなGoogleは、従来のギガバイトでなく、デジタル(2進数)情報の標準単位であるギビバイトを使うことにしたのだ。なにしろあなたのアプリケーションのニーズが変われば(当然変わるだろうけど)、コアやメモリの数量をあとからでも自由に調整できるのだ。

下表は、vCPUとメモリの量に応じた、従来のマシンタイプ(青)と、今回のカスタムマシンタイプ(白)の料金比較だ:

custom_vms_google_cloud

上の例は、インスタンスが1か月フル稼働した場合の各マシンタイプの月額料金で、Googleの継続利用割引が適用されている。これまでのGoogleの仮想マシンと同じく、カスタムマシンタイプも毎分料金制があり、また、Google本体の空きメモリを利用するpreemptibleマシンの割引もある。

合衆国リージョンでは、vCPU1基の使用料が1時間0.03492ドル、1GiBのRAMの1時間の使用料が0.00468ドルである。preemptibleマシンではvCPUが0.01002ドル、RAMが0.00156ドルになる。ヨーロッパとアジアではやや高くて、たとえば標準のvCPUは0.03841ドルになる(合衆国0.03492ドル)。

カスタムマシンタイプはすでに、GoogleのコマンドラインツールやAPIでサポートされている。Google Developer Consoleからのグラフィカルな指定はまだだが、数日後には実現するだろう。

カスタムマシンタイプで使えるオペレーティングシステムは、CentOS, CoreOS, Debian, OpenSUSE, またはUbuntuだ。

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

Googleのデータセンターのネットワーキングインフラストラクチャ、10年間の進化の過程

2014-09-30_1420

Googleは今日(米国時間8/18)、家庭のWiFiの高速化技術を発表したが、同社内部ではこれまで長年、それよりもずっと複雑なネットワーキングの問題に取り組んできた。Googleのデータセンターを構成するマシンの数は数十万のオーダーだから、そこらのふつうのルータやスイッチでそれらを接続することはできない。サーバ間を流れるすべてのデータを管理するためにGoogleは、独自のハードウェアとソフトウェアを作ってきたが、今日は同社の研究部門のブログ記事などで、同社のネットワーキングインフラストラクチャの進化の軌跡を紹介している。

Googleの内部ネットワークの現在のセットアップはJupiterネットワークと呼ばれ、その容量は第一世代のネットワークの100倍、全体の二分割帯域幅(bisection bandwidth)*は毎秒1ペタバイトに達する。Googleによると、このスピードは、10万台のサーバが合衆国国会図書館のデジタル化された全データを、1/10秒以下で読み取る速度に相当する。〔*: bisection bandwidth, ネットワークを二分割したとき両部分間に存在する全帯域の合計。〕

ブログ記事の中で筆者のAmin Vahdat(Googleのフェロー)は。“このようなネットワークパフォーマンスがGoogleのサービスの能力をすさまじく強力にしてきた”、と書いている。“しかも帯域の高低差がないから、技術者たちは帯域のいろんなレベルに合わせてコードを最適化する必要がない。たとえば初期には、サーバの配置によって性能やエラー率に差が生じたため、データをどこに置くかという悩ましい問題がつねにあった。すべてのサーバをラックの最上位の(最高速の)スイッチにぶら下げたりすると、たった一つのスイッチのトラブルで大きな被害が生じたりするのだ”。

image02

10年前のGoogleのネットワークは、まだこれほどの性能に達していなかった。当時はYouTubeを買収する前、そしてGmailやGoogle Earth、Google Mapsなどのサービスを立ち上げた直後だった。そのあとの短い10年間で、同社のネットワーキングニーズはきわめて急速に変わっていったのだ。

2005年当時のマシンは、こんな感じだ:

  1. fh10_board.jpg

  2. firehose1-1_chassis.png

  3. copy-of-fh_cabling-1.jpg

その10年を振り返った論考によれば、同社は2004年にはまだ、標準的なサーバクラスタを配置していたが、上図の2005年のマシンは、同社のFirehose 1.0データセンターアーキテクチャで配置(デプロイ)したネットワークの最初の機種だ。その2005年のマシンの目標は、1万台のサーバ間で1 Gpsの二分割帯域幅を実現することだった。それを達成するためにGoogleは、スィッチングのファブリックを内製のサーバに直接統合しようとしたが、しかしそうすると、“サーバのアップタイムが理想に達しなかった”。

Firehose 1.1でGoogleは初めて、カスタムのデータセンタークラスタファブリックをデプロイした。“FH1.0の経験から、通常のサーバにスイッチのチップを入れてはいけないことを学んだ”、と当時の技術者の一人が書いている。そこでGoogleはカスタムのエンクロージャーを作り、Closアーキテクチャと呼ばれるデータセンターネットワークへ移行した。

2008年に、FH 1.1はWatchTowerへと進化した。ケーブルは、通常のネットワーキングケーブルではなく10Gのファイバを使った。Googleはこのバージョンのデータセンターネットワークを、全世界のデータセンターで展開した。

それは、こんなラックだ:

WT2

1年後に、WatchTowerはSaturnに変身した。WatchTowerのファブリックは87 Tbpsまでスケールできたが、Saturnはその混みあったラック上で207 Tbpsまでスケールアップした。

  1. saturn_chassis.png

  2. wtbundles.jpg

  3. pluto-png.jpg

Saturnは、Googleによく仕えた。その後3年間もGoogleのデータセンターネットワークのアーキテクチャは、Saturnで十分間に合ったのだ。

上記論考には、こう書かれている: “サーバ一台あたりの帯域要求が継続的に成長していくだけでなく、データセンターのすべてのクラスタの、むらのない均一な帯域も求められた。40G対応の高密度商用チップの登場に伴い、Closファブリックをデータセンター全体に拡張して、クラスタ間ネットワーキングの層もそこへ入れることを、検討できるようになった”。

それは、一つのデータセンターを一つの巨大なコンピュータのように扱えるアーキテクチャだ。ソフトウェアが計算資源とストレージ資源の分散を管理し、ネットワーク上のすべてのサーバからそれらを可利用にしている。

Jupiterのハードウェアはたしかに、同社の初期の内製ネットワーキングハードウェアとは外見的にも異なっているが、しかし多くの点で、同社がそもそもの初期からSoftware Defined Networking(SDN)の考え方を採用して、イノベーションのスピードを上げてきたことも事実だ。

Googleは今日、同社のネットワーキングのセットアップを、いろんな側面から詳説する4つの小論を発表した。Googleは現行のハードウェアやソフトウェアのアーキテクチャの限界に他社よりも早くぶつかる方だから、Googleからのこの種の情報提供によって同社の外での新しいイノベーションが、これまでも生まれてきている。

すべてのスタートアップが自前のデータセンターを構えるわけではないが、でも他のデータセンターの運用者たちは確実に、これらの論考の細部から多くを学び、自らのソリューションに、そして結果的にはユーザの利益に、反映していくことだろう。

Jupiter-superblock3

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Google Cloud Launcherで、よく使われる120あまりのオープンソースパッケージを素早くデプロイできる

GoogleとBitnamiが今日、GoogleのCloud Platformで立ち上げる新しい機能により、デベロッパは120あまりのポピュラーなオープンソースアプリケーションをCloud Platformへデプロイできる。GoogleとBitnamiがパックした120あまりのアプリケーションには、WordPress、Drupal、Redis、MongoDB、Gitlab、Djangoなどのほか、RubyやLAMPアプリケーション、Puppetなどのためのインフラストラクチャスタックも含まれる。

Googleが言うようにVMベースのソリューションをセットアップするとき、デベロッパはサービスのさまざまな部位を構成するために多くの時間を費やす。しかしこのCloud Launcherを利用すると、必要なアプリケーションやサービスを指定するだけで、数クリックでその作業が完了する。

GoogleのプロダクトマネージャVarun Talwarが今日の発表声明の中でこう述べている: “デベロッパは設計やコーディングに時間を割くべきであり、ライブラリを見つけてデプロイしたり、依存性を調整したり、バージョニングの問題を解決したり、ツール類を構成したり、といった作業は、デベロッパの貴重な時間を奪う”。

Googleはこれらのパッケージの多くを今後、同社のCloud Monitoringサービスに統合する予定だ。

なおGoogleはすでに、Casandra、MongoDB、Drupal、Joomlaなど一連の人気アプリケーションに関しては、これと同様の”click-to-deploy“(クリックツーデプロイ)サービスを提供している。今回の新しいサービスは、この既存の機能にBitnamiのパッケージを足したもののようだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa


Googleのリアルタイム・メッセージングサービス「Cloud Pub/Sub」が公開ベータに


本日(米国時間3/4)Googleは、Cloud Pub/Subの公開ベータ版を初めて公開する。これは同社のバックエンド・メッセージングサービスで、デベロッパーがマシン間でメッセージをやりとりしたり、スマート端末からデータを収集したりする作業を楽にするものだ。基本的には、クラウド上のスケーラブルなメッセージング・ミドルウェアで、デベロッパーはホストサービスに関わらずアプリケーション間で素早くメッセージを交換できる。Snapchatは、Discover機能で既にこれを利用しており、Google自身も、クラウドモニタリングサービス等のアプリケーションに利用している。

Pub/Subはかなりの期間アルファ版だった。Googleは昨年のI/Oデベロッパーカンファレンスで、初めて(静かに)これを披露したが、大きく取り上げることはなかった。これまで同サービスはプライベートアルファだったが、今日からは全デベロッパーが使える。

Pub/Sub APIを使うと、デベロッパーは最大1万件のトピック(アプリがメッセージを送る先の実体)を作ることができ、1秒間に最大1万通のメッセージを送れる。Googleは、「毎秒100万メッセージのテストにおいても」通知は1秒以内に送られると言っている。

このサービスの典型的な利用ケースは、Googleによると、ネットワーククラスタの負荷バランス、非同期ワークフローの実装、複数システムへのロギング、多種デバイスからのデータストリーミング等だ。

ベータ期間中は無料でサービスを利用できる。ベータが終了すると、デベロッパーは、最初の1億APIコールまでは、100万コールにつき0.40ドルを支払う。それ以上メッセージを送りたいユーザーは、次の24億コールまでは100万コールにつき0.25ドル、それ以降は100万コールにつき0.05ドルを支払う。

Pub/Subがベータになった ― そしてGoogleが正式版の価格まで発表した ― ことで、今年の夏のGoogle I/Oあたりでは正式公開となりそうだ。

[原文へ]

(翻訳:Nob Takahashi / facebook


DockerアプリケーションをGoogleのクラウドプラットホーム上で展開運用するための管理サービスをアルファで立ち上げ

Googleが今日(米国時間11/5)、Google Container Engineというもののアルファテストを開始する、と発表した。それは、Googleのクラウドプラットホームの上でDockerによるコンテナを使用するアプリケーションを構築し運用するユーザに提供する、もろもろの管理サービスだ。

Dockerは今のデベロッパ界隈でいちばんホットな技術であり、デベロッパとの会話の中で必ず登場する名前だ。GoogleのCloud Platformのチームも、そのプラットホーム全体ををDockeベースで行くことに決め、顧客であるデベロッパが分散アプリケーションをより容易に構築運用できるようにしたい、と考えている。

基本的に今度の新サービスは、GoogleのオープンソースプロジェクトKubernetesをベースとする”Cluster-as-a-Service”のプラットホームだ。言い換えると、デベロッパは自分のクラスタを、Googleがその巨大なデータセンター向けに開発した独自のコンテナ技術を利用して管理できる。ユーザのアプリケーションは通常、複数のDockerコンテナで構成されるが、Kubernetesはそれらの動的(==ランタイムの)管理を助ける。

Googleによると、自社のクラウドプラットホームの“高速ブートと効率的なVMホストとシームレスな仮想化ネットワークの組み合わせ”は、“コンテナベースのアプリケーションを稼働させるための理想的な場所”だ、という。競合他社はこれに異議を唱えるだろうが、Dockerコンテナアプリケーションに対してこのレベルの管理サービスを提供しているところは、まだほかにない。

Googleは最初5月に、同社のManaged VM service(管理サービスを伴うVMサービス)の一環としてDockerイメージのサポートを開始した。これらの管理つきVMは今アルファを終えようとしており、自動化スケーリングのサポートが加わったことによりデベロッパは、Googleのプラットホーム上でDockerコンテナを、難しい作業を伴わずに利用できる。アルファやベータのGoogle的な定義では、ベータは、アクセス制御なし、課金なし、ただし技術的サポートに関するSLA(service level agreement)もなし、という意味だ。

そして今回のDockerクラスタ管理サービスはまだアルファだから、機能は不十分だし、不測のシステム事故はいつでもありえる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


GoogleのクラウドプラットホームもついにBaaSを提供へ…Firebase買収でリアルタイム機能を充実

Googleが今日(米国時間10/22)、アプリ/アプリケーションのためのバックエンドサービスFirebaseを買収したことを発表した。データの保存とシンクをリアルタイムで行う、などのタスクをiOSやAndroid、それにWebのアプリケーション向けに提供するので、デベロッパの開発努力を相当楽にしてくれる。今現在の登録ユーザはおよそ11万名のデベロッパで、サービスはそのまま継続し、多様なプラットホームへの対応も維持される。〔*: デベロッパはますます、BaaSの利便性を求める。参考記事: モバイル-クラウドエンタプライズ。〕

ほぼ3年前にローンチしたFirebaseは、Googleに加わったことでサービスの大幅なスケールアップが可能になった、としている。同社曰く: “Googleの技術力とリソースと技術的インフラがあれば、もっともっと多くのことをもっともっと早くできる”。Firebaseのチームはまた、自分たちが今のGoogleにない部分を補う、と見ている。この買収によって、Googleの顧客はアプリケーションを早く書けるようになり、FirebaseのユーザはGoogleのインフラにアクセスできる。

Googleにとってこの買収は技術と人材の獲得が目的のようだが、しかしそれと同時に、Firebaseの10万あまりのデベロッパがGoogleのクラウドプラットホームのユーザになるメリットもある。

GoogleがFirebaseから得た機能の紹介は、11月4日に行われるイベントGoogle Cloud Platform Liveで行われる。買収が完了したのはごく最近と思われるが、買収結果をGoogle Cloud Platformに導入するのは、前から相当早いのだ。

Googleが同社のクラウドプラットホームを充実させるために行う重要な買収は、今回が三度目だ。最初はモニタリングサービスのStackdriveを買収して、それをすぐに統合、そして次は、映画のデジタルプロダクションのための特殊効果をCGIするZyncだった。

これまで、Andrew LeeとJames Tamplinが創業したFirebaseは、2012年のシードラウンドで約700万ドル、2013年のシリーズAで560万ドルを調達している。

 

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Googleが同社のクラウドで映画の視覚効果の制作もできるためZync Renderを買収

Googleが今日(米国時間8/26)、 Zync Renderを買収したことを発表した。 Zync Render(ZYNC)は、映画スタジオなどがクラウドで視覚効果(visual effects, ビジュアルエフェクト)を描く(レンダリングする)ためのサービスだ。同社の技術はStar Trek: Into DarknessLooperなどで利用されている。Googleがここを買収したねらいは、映画スタジオなどに同社のCloud Platformを、彼らの制作の場としてもっと使ってもらうためだ。

現在ZYNCはAmazonのEC2向けに最適化されているが、これからはGoogleのCloud Platformに統合される。ZYNCによると同社の技術は1ダース以上もの長編商業映画や、数百ものコマーシャルに利用され、その全描画時間は650万時間にもなる。

Googleが今日述べているように、映画の特殊効果を描画するためには、とても強力なインフラストラクチャを必要とする。多くのスタジオが自社独自のレンダーファームを持っていて、クラウドサービスは主に、制作効率化のための容量拡大として利用される。しかしそういう専用のコンピューティングインフラを持ってないところや、自社でやりたくないところは、エフェクトのレンダリングもクラウドからのコンピューティングサービスに依存したい。

Googleは、課金は分単位と言っているが、サービスのそれ以外の詳細はまだ明らかでない。ZYNCの側は、“Google Cloud Platformのような大規模で安定性の高いインフラを使えるなら、これまでよりもさらに良いサービスを顧客に提供できる。大きな仕事も十分にできるし、提供パッケージの種類も増やせる、料金もよりリーズナブルにできるだろう”、と言っている。

なお、Amazonはこれまで何度も、うちは視覚効果をレンダリングするためのプラットホームとして最適だ、と主張してきた。同社は、ZYNCも仕事をしたStar Trek: Into Darkness — における、Atomic Fictionの仕事ぶりに関するケーススタディーまで発表している。Microsoftもときどき、うちのクラウドは映画制作にも最適、と売り込みの言葉を述べている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


GoogleのCloud PlatformがSSDによるパーシステントディスクとHTTPロードバランシングを提供

あと数日でGoogleのデベロッパカンファレンスGoogle I/Oが始まるが、同社はそれを待つこともなく今日(米国時間6/16)、同社のCloud Platformの二つの新しい機能をローンチした。今日のGoogleの発表によると、その二つは何(いず)れもデベロッパが前から要望していたもので、ひとつはHTTPのロードバランシング、もうひとつはSSDを使ったパーシステントなストレージだ。どちらも今はプレビューなので、テストしてみたいデベロッパはここで申し込む。

毎秒のI/Oの頻度がものすごく高いアプリケーションを抱えるデベロッパは、前からSSDを要望していたが、今度からは月額0.325ドル/GBでそれを使えるようになる。これまでのパーシステントストレージは0.04ドルだったから、相当に高い。ただしI/O操作そのものへの課金はない。AmazonのEC2のインスタンスにはSSDを使うものもあるが、それらにはパーシステントストレージの機能はない。

ディスクベースのパーシステントストレージでは、1GBのリードが約0.3IOPS、ライトが1.5IOPSだったが、SSDベースではリード、ライトともに最大30IOPSとなる。最大持続スループットも、SSDは相当に高い。

 

HTTPのロードバランシング機能は、Googleによると、最大で1秒あたり100万リクエストまでスケールできる(ウォームアップ時間なし)。コンテンツベースのルーティングをサポートし、Googleがとくに強調するのは、複数のリージョンにまたがってロードバランスできることだ。グローバルなサービス提供者がレイテンシを下げたいとき、助かるだろう。また複数のインスタンスにまたがるロードでレイテンシを抱えていたデベロッパも、そのリクエストを最適化できる。いずれの場合もアプリケーション自身は一つのIPアドレスにアクセスするだけなので、ロードバランスをとくに意識しない。だから使いやすい機能だ、とGoogleは言っている。

ただしこのロードバランシングは当面、SSLプロトコルをサポートしない。SSLを利用したいデベロッパは、Googleの既存の、プロトコルベースのロードバランシングシステムを使わなければならない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Googleのリアルタイムビッグデータ分析サービスBigQueryが大幅値下げと能力アップ

非常に大きなデータ集合を高速に分析するためのGoogleのクラウドツールBigQueryが今日(米国時間3/25)、最大85%という大幅値下げをした。そしてそれと同時に、Amazon Kinesisなどの競合サービスと互角に戦うための重要な新機能も加えた。もうすぐデベロッパたちは、最大で毎秒10万行までのリアルタイムデータをBigQueryに送り、リアルタイムで分析してもらえるようになる。

これで、リアルタイム分析に依存する多種多様なサービスにとって、BigQueryが使うツールの候補になる。今日行われるCloud PlatformのイベントでGoogleは、電力会社がこのツールを使うと、地域の電力利用状況をリアルタイムで刻々分析しながら、数分後の停電の可能性を検知できる、という例を見せる。あるいは電力会社はBigQueryを使って数マイル範囲内のメーターの今の状態を知り、過去5分間に電気の利用がなかったところを判別できる。

そのほか、マーケティングや金融業などでも、データやログ、さまざまな計測値などをリアルタイムで分析できる。

ビッグデータ分析の世界でGoogleのサービスは、比較的安い。オンデマンドのクェリは1テラバイトあたり5ドル、毎秒5GBの予約クェリは月額料金が“わずか”2万ドルだ。これらの額は、ほかのサービスプロバイダよりも75%安い、とGoogleは主張している。

BigQueryのこれまでのリアルタイムストリーミング機能はあまり強力ではなくて、 その最大消化能力は1テーブルあたり毎秒1000行だった。それで十分なアプリケーションもあるが、それはAmazon Kinesisの足元にも及ばない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google App EngineのユーザにIaaS的な自由度を与える新フレームワークManaged Virtual Machines

Googleは今日(米国時間3/25)、同社のCloud Platform上の新サービスとしてManaged Virtual Machines(管理つきの仮想マシン)をローンチする。それは、デベロッパが自分のアプリケーションをクラウドでホストする際に選ぶオプションのメニューに、柔軟性を持たせるためだ。これまでのオプションは、Compute EngineのようなIaaSを使うか、あるいはApp EngineのようなPaaSを使うかという選択肢がメインだったが、Virtual Managed Machinesは、同社によると、両者の良いとこ取りを提供する。

Webアプリケーションやモバイルアプリのためのバックエンドの置き方動かし方として、Google Compute EngineやAmazonのEC2のようなサービス(IaaS)を使ってクラウド上のサーバを完全に自由に管理するか、あるいはParseやGoogle App Engineのようないわゆるホスティングサービス(PaaS)におまかせするか、という選択肢がある。PaaSを選ぶとサーバの管理は楽になるが、勝手にサービスの大幅な構成変更をする(データベースを変えるなど)などの柔軟性はない。

Google Cloud Platformのプロダクト担当Greg DeMichillieが先週語ったところによると、上記二つのどっちにすべきか、という見込み客からの質問が多い。GoogleはCompute EngineとApp Engineで両方を提供しているが、“App EngineのユーザがApp Engineではできないことが必要になって途方に暮れる、ということも多い”、という。

Managed Virtual Machinesなら、二つのうちどっちかを選ぶ、という必要はない。DeMichillieが比喩的に言う“ラインの外側に色を塗りたくなったら”、App Engineを使ってる状態でサービスの一部をManaged Virtual Machine(s)の上で動かせばよい。ユーザは、MVMの上なら何でもインストールでき、アプリケーションのスケーリングなどは引き続いてApp Engineが面倒見る。サービスの展開をCompute Engineで開始したユーザも、サービスの一部をいつでもApp Engineに移行でき、そのためにはYAMLファイルをちょっと書き換えるだけでよい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Googleのクラウド・コンピューティングとクラウド・ストレージの新料金表

今日(米国時間3/25)サンフランシスコで開催されたGoogleのクラウドプラットフォーム・イベントで、ほとんどすべてのクラウド・サービスの料金の大幅値下げが発表された。また料金体系の簡素化や自動的に適用される長期利用割引などの新しいシステムも導入された。

Google Compute Engineは上の表のように、すべてのサイズ、リージョン、クラスで32%料金が引き下げられた。App Engineの料金も30%引き下げられ、料金体系の簡素化が図られた。

クラウド・ストレージの料金は68%値下げされて1GBあたり月額0.026ドル、DRAストレージの場合は1GBあたり0.02ドルとなった。Googleによれば、この料金は4500TBを専有するユーザーに適用されたいた大口割引よりもさらに安いという。

今日はクラウドSQLやクラウドDBなど、他のクラウド・ストレージの料金についての値下げ発表はなかったが、おそらく近日中にこれらも値下げされるか、あるいは今回値下げされたストレージに統一されるだろう。

長期利用割引を考慮に入れなくても新料金は多くのライバルより安い。予約インスタンスなど一部ではAmazonのEC2の料金をも下回るものとなった。

【中略】

これまでGoogle、Amazon、Microsoftは互いに相手の動向をうかがってクラウドサービスの料金を決めてきた。Googleの大幅値下げ攻勢で、これらライバルも値下げに動くことになるだろう。Amazonは今週サンフランシスコでAWS Summitカンファレンスを開催するが、どういう発表があるか注目だ。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Google、クラウド・プラットフォームで全面攻勢―大幅値下げ、新サービスをローンチ

今日(米国時間3/25)、Googleはサンフランシスコで開催したCloud Platform Liveイベントクラウドプラットフォームに関して多数の重要な発表を行った。Amazon Web Service(AWS)が依然としてデファクト・スタンダードとなっているこの分野で、Googleが競争力を大きく高めるべく攻勢に出たという印象だ。

しかし「攻勢に出た」というだけでは言い足りないかもしれない。Googleはクラウド系のほぼすべてのサービスで劇的な料金引き下げを発表した。

たとえば、クラウドコンピューティングのCompute Engineの料金はすべてのサイズ、リージョン、クラスにわたって32%値下げされた。クラウド・ストレージは68%引き下げられ、オンデマンドのGoogle BigQueryに至っては85%の値下げとなっている。

Googleはクラウド・サービスの料金はムーアの法則でハードウェアの価格が低下するのに歩調を合わせて来なかったと指摘した。しかし今後Googleはムーアの法則に合わせて料金を引き下げていくという。実はこれまでGoogleのクラウド・サービスの料金は他のベンダーと比較してそれほど安くなかった。しかし今後は料金の引き下げ競争でもトップを走る構えだ。

Googleはまた料金体系を単純化した。Amazonの料金体系は複雑なことで悪名高い。Googleはその反対を目指すという。たとえばAmazonの場合、割引を受けるためには前払いでインスタンスを予約する必要があるが、今回Googleは長期利用割引というシステムを導入した。これはユーザーが1ヶ月の25%以上の期間にわたってクラウド・サービスを利用すると自動的に割引が適用になるというものだ。

さらにGoogleはバグのトレーシング機能やクラウド・コンソールから直接アプリケーションを修正できるオンライン・コード・エディタなどデベロッパーの生産性を向上させる新たなツールを多数発表した。

Managed Virtual MachinesのローンチによってGoogleはクラウド上での開発に一層の柔軟性を与える。GoolgeのApp Engineはスケール性は高いが、機能に制限があり、Compute Engineには事実上、機能の制限がないが、管理運用にスキルが必要だった。これに対してデベロッパーは新たなバーチャルマシンを利用することで双方の「いいとこどり」ができるという。

GoogleはまたAmazonのRoute 53のライバルとなるクラウドDNSを発表した。Googleによれば、Google Cloud DNSはサービスとしての権威DNSサーバを提供するものだという。Googleクラウド・サービスのユーザーはネットワーク・インフラを運営するためにすでに利用しているコンソールからDNSも管理できるようになるということだ。

またCompute EngineではWindows Server 2008 R2の限定プレビューも開始され、Red Hat Enterprise LinuxSUSE Linux Enterprise Serverがラインナップに加わった。

エンタープライズや多量のデータ処理を必要とするスタートアップのためのBigQueryも今日から料金が85%引き下げられる。このプラットフォームは毎秒最高10万行のデータを処理でき、その分析結果はほぼリアルタイムで利用できる。Amazonがすでにリアルタイムでのビッグデータ処理サービスに力を入れており、しかも大量データ処理はGoogleが得意中の得意とする分野であるにもかかわらず、Googleは今までこの種のサービスにあまり力を入れていなかった。

クラウド・サービスに対してGoogleがどこまで本気なのかという一抹の疑念があったとすれば、それは今日のイベントで完全に払拭されたといってよいだろう。Googleは多少出遅れたとはいえ、既存のビジネスモデルに固執しているわけではないことが示された。一度動き出せばGoogleは圧倒的な技術力と巨大なリソースにものを言わせて小規模なベンダーがとうてい太刀打ちできないようなサービスを提供する。今回のGoogleの動きのもっとも大きな影響は、AmazonやRackspaceを始めとする既存のプレイヤーにさらなるイノベーションを迫ることになった点だろう。

Googleが今日のイベントを3月26日にやはりサンフランシスコで開催されるAmazonのAWSサミット・カンファレンスの直前に設定したのはもちろん偶然ではない。 当然Amazonも大きなサプライズを用意していることだろうが、Googleのたくみな動きはAmazonを後手に回らせた印象を与えること成功した。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Googleの大規模データベースCloud SQLサービス、ついに正式公開―SLA、暗号化、サポートを提供

Googleは2年半ものプレビュー期間を経て、 完全な機能を備えた大規模MySQLデータベース・サービスCloud SQLをとうとう正式公開した

正式公開されたGoogleの企業向けサービスの常としてCloud SQLにも99.95%の稼働率を保証するSLAが提供される。Googleは20%のアクセス失敗が1分以上続いた場合ダウンタイムと認めるという。これはなかなか気前のよい基準だ。

さらにCloud SQLに格納されるユーザーデータは自動的に暗号化される(ただしバックアップの暗号化は依然として「近日公開」となっている)。 Googleのデータセンター間のCloudSQLトラフィックも暗号化され、ユーザーとの間のトラフィックにはSSLが利用できる

デフォールトの最小インスタンスでも500GBのデータが扱える(従来は250GBだった)、Googleによれば、このデータは複数のゾーンに複製され、追加料金なしに自動的にバックアップが取られる。ただしCloudSQLのバーチャルマシンは最小構成の場合0.125GBのRAMしか割り当てられないので、これで500GBのデータが処理できるかどうかはユーザーが判断しなければならない。

Cloud SQLの料金体系は次のようなものだ。まずストレージとネットワーク・アクセスのコストを別にしたオンデマンドのバーチャルマシンは1時間あたり0.025ドルだ。多くのユーザーが利用開始にあたって選択すると予想される最小パッケージは1日あたり0.36ドルでRAMが0.125GB、 ストレージが0.5GB、I/Oが20万回提供される。ハイエンドのインスタンスとなると、たとえば、16GBのRAM、10GBのストレージ、3200万回のI/Oで1日あたり46.84ドルとなる。

Amazonの類似したサービス、RDS for SQL Serverの料金はオンデマンドのマシン1台について1時間あたり0.024ドルだ。

Cloud SQLの他に、NoSQLデータベースをクラウドで利用したいデベロッパーのためにGoogleは巨大データセット用のBigQueryデータベースとGoogle Cloud Datastore(こちらはまだプレビュー版)を提供している。Cloud Datastoreは2013年のGoogle I/Oで発表された。Cloud SQLの例にならうなら、こちらのプレビュー期間はまだしばらく続きそうだ。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Google Cloud Platform–Cloud Storage上でHadoopを簡単に使えるためのコネクタを提供開始

かねてからGoogle Cloud StorageはHadoopに対応しており、デベロッパはデータをここに置くことによって、分散コンピューティングによる高度なデータ分析ができる。そして今日(米国時間1/14)Googleは、新たなコネクタをリリースして、Google Cloud Platform上でのHadoopの利用が、より容易にできるようにした。

クラスタやファシステムの管理をそのGoogle Cloud Storage connector for Hadoop(HadoopのためのGoogle Cloud Storageコネクタ)がデベロッパに代わって行うので、デベロッパは物理レベルの面倒な管理業務から解放され、データの処理に専念できる。

Googleが2003年に開発したGoogle File Systemは、今ではHadoopの土台だ。HadoopはApache Software Foundation(通称Apache)が管理するオープンソースの分散コンピューティング環境で、データをサーバのクラスタ上に分割分散して分散処理によるデータ分析を行う。今ではHadoopのまわりに、多様なソフトウェアやサービスから成るエコシステムが形成され、ClouderaやHortonworksなど多くの企業がそれを支えている。

Google Connector for Hadoopは、Googleの最新のクラウドストレージシステムColossusを使用する。また、シンプルなコネクタライブラリを使用して、Hadoopに直接Google Cloud Storageへアクセスさせ、データ処理を行わせる。

Googleは、このコネクタの利点をいくつか挙げている。HadoopのクラスタをGoogle Cloud Storageが一か所で管理するので、デベロッパはHadoopの使用をすぐに開始できる。Google本体のスケーラビリティを利用するので、可利用性がつねに高い。データのコピーを持つ必要がないので経費節約になる…つまり、バックアップ用にコピーを作るなどは、Google Cloud Storage自身が勝手にやってくれる。

今やHadoopは、ビッグデータ分析の分野における主流派だ。先月の記事でも書いたように、Hadoopは、Twitterなど、毎日ペタバイトのオーダーでデータを処理するインターネット企業にとって欠かせない技術だ。また一般企業でも、処理する情報量の爆発的な増大とともに、やはりHadoopを利用せざるをえなくなっている。

しかしHadoopを本格的かつ有効に利用するためには複雑な技術課題が多く、高度な経験知識をもった技術者を何人も必要とする。そこで今回のGoogle Cloud Storage Connector for Hadoop(Hadoop用のGoogle Cloud Storageのコネクタ)のようないわば‘仮想技術者’がいろいろ登場することによって、Hadoopを誰もが気軽に使えるものに、していく必要があるのだ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


GoogleのBigQueryにリアルタイムのストリーミング挿入と時限クェリが加わる

Googleが今日(米国時間9/18)、BigQueryの大型アップデートを発表した。それはクラウドからのサービスで、大量のデータをSQLで分析し、とくに、リアルタイムデータの分析に適している。今日からBigQueryのユーザはイベントをデータベースに、行単位でストリーミングできる。そのためのAPIが今日から提供される。

Googleの説明によると、これによって、従来のようにデータをバッチでアップロードするだけでなく、データが発生し可利用になるたびにリアルタイムでそれらを保存できる。BigQueryが行うビッグデータのバルクロード機能はもちろん使えるが、デベロッパがこの新しいリアルタイム機能を試せるために、2014年1月1日までは無料で使える。そのあとは、データベースに10000行挿入するたびに1セントを払う。データ保存料は1ギガバイトあたり月額0.08ドル、クェリ(バッチクェリ)は処理後のデータ1ギガバイトにつき0.02ドルだ。

この新しい機能は、Googleによれば、リアルタイムで常時大量のデータが発生するオンラインショップや、何百万ものユーザや接続デバイスにサービスを提供するWebアプリケーションに向いている。

また、最前の24時間内の特定範囲のデータだけを調べる、というクェリが新たにサポートされた。BigQueryのクェリは基本的に全列スキャンだが、ほんとうは一部だけ見たいというユーザにとっては時間と費用の無駄だった。リアルタイムデータでは、とくにそんなニーズが多いだろう。たとえば、数時間(数日)前まで分かればよい、とか。

今日のアップデートではさらに、SUM()、COUNT()、AVG()、STDDEV_POP()といった新しいウィンドウや統計機能、そして過去のクェリを見ることのできるブラウザツールも提供された。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))