Spotifyの「2019年まとめ」提供、Google Dataflow史上最大のジョブの舞台裏

2019年12月前半に、Spotifyはその年にユーザーが最も多くストリーミング再生した曲を集めた「Wrapped(まとめ)」プレイリストをパーソナライズして提供した。これ自体は以前から提供されているもので特に新しいものではないが、2019年は過去10年間を振り返るプレイリストも提供された。これはかなり大規模のジョブだ。増え続ける無料ユーザーと有料サブスクリプション利用者に向けてどのようにこのプレイリストを生成したのか、Spotifyは舞台裏の一部を明かした。

画像:Frazer Harrison/Getty Images for Spotify / Getty Images

SpotifyがGoogle Cloud Platformの大口利用者であることは、秘密ではない。2016年にSpotifyはGoogle Cloudへの移行を発表し、2018年にはその後の3年間でGoogle Cloudのインフラストラクチャに4億5000万ドル(約500億円)以上を支出する見込みであることを明らかにしている。

同じく2018年、この年のWrappedでSpotifyはGoogle Cloud Platform上で史上最大のGoogle Cloud Dataflowでジョブを実行した。Dataflowは数年前にGoogleが実験を開始したサービスだ。Spotifyのエンジニアリング担当バイスプレジデント、Tyson Singer(タイソン・シンガー)氏は筆者に対し次のように語った。「2015年に我々はビッグデータを処理するApache BeamとGoogle Cloud DataflowのためのScala API『Scio』を開発し、オープンソース化した。我々はDataprocではなくDataflowを選択した。スケールする際に運用のオーバーヘッドが少なくて済むことと、Dataflowが予測されるストリーミング処理のニーズに合っていたことがその理由だ。現在はDataflow用に設計され最適化された優れたオープンソースのツールセットがあり、社内のほとんどのチームで使用しているほか、Spotify以外でも使われている」

Wrapped 2019には、1年間のまとめと10年間のまとめがあった。Spotifyが実行したジョブは2018年の5倍の規模だったが、かかった費用は4分の3で済んだ。このことについてシンガー氏は、チームがプラットフォームを熟知したからだと考えている。「このようなグローバルのスケールでは、複雑になるのが当たり前だ。Google Cloudのエンジニアリングチームや専門家と緊密に協力し、前年までの経験から学んだ結果、我々が実行したDataflowのジョブはこれまでに書かれた中で最も洗練されたもののひとつとなった」

専門知識があっても、データ分析を最適化しユーザーの興味を引くストーリーを伝えるために、データセット全体のイテレーションを回すことはできない。シンガー氏は「これを処理するジョブは大規模で複雑だ。Google Cloud Dataflowに負担をかけすぎないために、複雑さと処理を切り離す必要があった。つまり我々はアイデアから、データ分析、ユーザーごとに固有のストーリーを生み出すに至るまで、もっとクリエイティブになる必要があった。そして時間内にコストを下げてスケールする必要もあった。十分に注意を払わないと、リソースを無駄にし下流のチームの速度を落としてしまう危険があった」と語る。

この作業負荷を処理するために、Spotifyは社内のチームをデータ処理、クライアント向けの設計、バックエンドシステムの3つのグループに分け、さらにデータ処理のジョブを細かく分けた。これはチームにとってきわめて異例のアプローチだった。「2019年、SpotifyはDataflowの『Shuffle』という機能を使った大規模なジョブを実行した。大量のデータがあり、誰が何をしたのかを理解するためにそのデータを整理する必要があったためだ。これはとてもパワフルだが、データ量が多いとコストがかさむ」。

2020年、SpotifyのエンジニアはGoogle CloudのBigtableを中間ストレージレイヤーとして使うことによりShuffleの使用を最小限にとどめた。シンガー氏は「常にデータの再グループ化が必要というよりは、多くのデータをパラレルに処理し格納するために、BigtableをDataflowのジョブ間を修復するツールとして使用した。Dataflowのジョブを小さいコンポーネントに分割し、コアの機能を再利用することで、ジョブのスピードを上げレジリエンスを高めることができた」と説明する。

シンガー氏は、少なくともコスト削減の一部はBigtableを使うこのテクニックによるものと考えている一方で、課題をデータ収集、アグリゲーション、データ変換のジョブに分解してからさらに複数のジョブに分割したことも指摘する。「こうすることで、より多くのデータをパラレルに処理するだけでなく、再実行するジョブを選択してコストを抑えた」

シンガー氏のチームのエンジニアたちが開発したテクニックの多くは、現在、Spotify全体で使われている。同氏は「Wrappedを機能させることで、我々はユーザーを理解するためのツールを作り、ユーザーのために優れた製品を作ることができる。Scio、Dataflow、ビッグデータ処理に関する我々の専門技術と専門知識は、Spotifyの製品ポートフォリオを強化するために広く使われている」と述べた。

[原文へ]

(翻訳:Kaori Koyama)

Google Cloudに秘密データを管理するSecret Managerが登場

米国時間1月22日、Google CloudはSecret Manager発表した。これを利用してユーザーは、APIのキーやパスワード、証明などのデータを安全に保存できる。これによりGoogle Cloudは、ユーザーが単一のツールでこの種のデータを管理し一元化できる場所を提供する。それは高度なIT部門のあるエンタープライズですら往々にして欠けている機能だ。

Googleのデベロッパーアドボケイト(サードパーティーの開発者を支援する役職)のSeth Vargo(セス・バルゴ)氏とプロダクトマネージャーのMatt Driscoll(マット・ドリスコ)氏は本日の発表声明で「多くのアプリケーションが、データベースやAPIキーへのアクセスに本人証明情報を要求している。しかし企業にはデータの複雑怪奇な拡散現象や可視性の邪魔、そして統合化の欠如があるので、秘密データの保護が難しい」と語る。

Googleはすでに秘密情報を管理するオープンソースのコマンドラインツールBerglasを提供している。Secret ManagerとBerglasは相性がいいので、ユーザーは秘密情報をオープンソースのツールであるBerglasからSecret Managerに移し、Berglasを使ってクラウドベースのツールであるSecret Managerからのデータを作ったりアクセスしたりできる。

またGoogleは、暗号鍵を管理するKMSで、管理の完全な鍵管理システムを(他のクラウドサービスと同様)提供している。BerglasとKMSは、互いに補い合う関係だ。Googleも言っているが、KMSは秘密データを保存しない。ユーザーがどこかに保存した秘密データを暗号化するだけだ。そしてGoogle Cloudへの秘密データの保存と管理は、Secret Managerが行う。

Secret Managerには、達等エバ秘密データのバージョンを管理したり監査ログを取るツールもある。Secret Managerにある秘密データは、プロジェクトのグローバルリソースでもあるとGoogleは強調している。競合するツールは、1つのリージョンの秘密データを管理することが多い。

この新しいツールは現在ベータで、Google Cloudのすべての顧客が利用できる。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Google Cloudに安価な汎用仮想マシン「E2ファミリー」を追加

米国時間12月11日、Google(グーグル)はGoogle Cloud PlatformE2シリーズのバーチャルマシンタイプを追加したことを発表した。新しい汎用コンピュートインスタンスは大幅なコスト削減を可能にする。料金は現在のN1インスタンスと比較して最大31%安くなるという。

E2ファミリーは標準的なIntel(インテル)およびAMDのCPUをサポートするが、グーグルによれば独自のCPUスケジューラにより「仮想CPU、メモリをダイナミックに物理的CPU、メモリにマッピングし可用性を最大限に高める」ことができるという。さらに新システムは仮想マシンの作動場所についても柔軟であり、必要があれば別のホストに簡単に移動できる。これらの特徴を実現するため、グーグルは専用のCPUスケジューラを構築し、「レイテンシーの大幅な低減をもたらし、並列処理に必須なコ・スケジューラとしてLinuxのデフォルトシステムより優れている」という。新しいスケジューラのウェイクアップレイテンシーはマイクロ秒以下であり、コンテキストスイッチも高速だという。

グーグルがここで強調している効率化は他のマシンタイプにも適用できそうだ。 おそらく今後のアップデートでGoogle Cloudの他のインスタンスファミリーにも同様の改善がなされていくだろう。

グーグルは新しいインスタンスがライバルの同種のプロダクトより優れていると断言しているのが興味深い。同社は本日の発表で「他のクラウドベンダーの同種のプロダクトと比較してい、E2バーチャルマシンは複雑な料金計算や人為的なスロットリングの必要なしにCPUを連続的に高負荷で稼働させるこことができる。これが可能となったのはCompute Engine仮想化テクノロジーとダイナミックなリソース管理能力の長年にわたる積み重ねによるものだ」と述べている。AWS、Azureの同種のマシンとE2ファミリーを比較したベンチマークの結果を見たいものだ。

これまでの例と同様、Googleでは事前に設定したコンフィグレーションのインスタンスのセットを提供する。最小構成はvCPUx2、メモリ8GB、最大はvCPUx16、メモリ128GB。さらに負荷の小さいワークロードの場合、Google Cloudは新たにE2ベースで既存のf1-micro、g1-smallのマシンタイプを提供する。構成はvCPUx2、メモリは1GBから4GBでof RAMでCPUのベースラインパフォーマンスは0.125 vCPUから0.5 vCPUまでとなっている。

【Japan編集部追記】 E2マシンタイプは米国、ヨーロッパでは提供されているが、まだ東京、大阪リージョンでは提供されていない。アジアでは台湾、シンガポール・リージョンで提供されている。

原文へ

(翻訳:滑川海彦@Facebook

Google Cloudが継続的デリバリサービスSpinnakerを正式にサポート

Google Cloudは米国時間7月21日、Spinnaker for Google Cloud Platform発表した。その名のとおり、継続的デリバリ(Continuous Delivery、CD)サービスSpinnakerをGoogleのクラウド上で容易に使えるようになる。

Spinnakerは最初Netflixが社内用に作り、それを今ではNetflixとGoogleが共同開発している。Netflixはそれを2015年にオープンソースにし、その後はオープンソースのCDプラットホームとしていちばん多く使われるようになった。今では、AdobeやBox、Cisco、Daimler、Samsung(サムスン)などもSpinnakeを使って開発工程を高速化している。

Spinnaker for Google Cloud Platformは、GoogleのKubernetes Engine上で動き、サービスのインストールはほんの数クリックで済む。インストールされたSpinnakerには、必要なツールすべてと、サービスのユーザーインタフェイスDeckが含まれている。ユーザーはGoogle Kubernetes EngineやCloud Memorystore for Redis、Google Cloud Load BalancingなどがGoogle Cloud上で使用するリソースの料金を払うことになる。

could spinnker.max 1100x1100

同社はGoogle Kubernetes EngineやCompute Engine、App EngineなどでコードのテストやデプロイができるようSpinnakerを事前に構成しているが、そのほかのどんなパブリッククラウドやオンプレミスクラウド上でも使用できる。Googleが最近ローンチした継続的インテグレーション(CI)サービスCloud Buildを統合し、バックアップの自動化や監査の統合、GoogleのStackdriverによるモニタリングなどもサポートしている。

GoogleでSpinnakerの開発を指揮しているMatt Duftler(マット・ダフトラー)氏が本日の発表声明で「このソリューションはデベロッパーだけでなくDevOpsやSREの人たちにも役に立つようにしたい。デベロッパーは最小のオーバヘッドで速く仕事がしたいと願っている。プラットホームのチームは、彼らが推奨するやり方をSpinnakernの中へエンコードして、それらを安全に使用できるようにする。Spinnaker for Google Cloud Platformを最初から使っていくと、社内の開発チームによるプロジェクトの着手と進行がより速くなるだろう」と述べている。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Google Cloudがサービスメッシュのためのネットワーキング管理ツール「Traffic Director」を発表

いつも新しいテクノロジーが、新しい用語の一群を引き連れてやってくる。コンテナ化された世界では、アプリケーションは離散的な小片すなわちマイクロサービスに分割される。そんなサービスが増殖すると、サービスメッシュと呼ばれるサービスのネットワークが作られ、その上で彼らは対話する。このような新しいテクノロジーはつねに管理層(マネジメントレイヤ)が必要になり、とくにここではネットワークのアドミニストレーターが新しいコンセプトであるサービスメッシュを理解しコントロールしなければならない。

米国時間4月9日のGoogle Cloud Nextカンファレンスで同社は、オープンなサービスメッシュのためのTraffic Directorのベータを発表した。それはサービスメッシュの中で起きていることの、ネットワークの管理者による理解を助ける。

Google Cloudで技術的インフラストラクチャのエンジニアリングを担当しているヴァイスプレジデントのBrad Calder氏が、このツールを紹介するブログ記事でこう言っている。「サービスメッシュの採用を加速しその管理の苦労を減らすために、Traffic Directorをご紹介できることはきわめて喜ばしい。それはサービスメッシュのためのエンタープライズ対応の構成とトラフィックコントロールのプレーンであり、その上ではグローバルな回復力とインテリジェントなロードバランシング、および、カナリアデプロイメントのような高度なトラフィックコントロールが可能である」。

Traffic Directorは、オペレーションがサービスメッシュを自分たちのネットワーク上にデプロイする方法を提供し、その仕事ぶりやシステムのほかの部分との対話をより強力にコントロールできるようにする。このツールはGCP上のVirtual MachinesやCompute Engineで利用でき、コンテナ化されたアプローチではGCP上のGKE(Google Kubernetes Engine)で使える。

このプロダクトは4月10日の時点でやっとベータだが、そのロードマップには新たなセキュリティ機能とハイブリッド環境のサポート、そして最終的には、昨日同社が紹介したハイブリッド管理ツールAnthosとの統合も行われる。

関連記事: Google’s hybrid cloud platform is coming to AWS and Azure(ハイブリッド環境&マルチクラウド環境管理ツールAnthosの紹介、未訳)

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

Google Cloudはクラウドのシェアを伸ばす方法として垂直市場に深入り、まずリテールから

GoogleはAdobeやSalesforceではないが、でもリテイラー(小売業)の要求に見事にフィットするスキルがあり、それによって顧客の体験を良くすることができる。そのスキルの中には、ピーク時でもお店のWebサイトやアプリが確実に動き続けるようにすることも、含まれるだろう。米国時間4月10日のGoogle Cloud Nextカンファレンスで同社は、その垂直戦略(業種別戦略)の例として、複数のソリューションから成るパッケージを紹介した。

また今朝は、同社がSalesforceとのパートナーシップの新たな段階を発表した。それは、コンタクトセンターのAIツールとチャットボットをSalesforceのデータと組み合わせて、両社の長所をより強化し、より良いカスタマーサービスの体験を作り出すプロダクトだ。

しかしGoogleにはSalesforceのような有名企業とのパートナーシップだけでなく、リテイラー向けの独自のサービスもある。それはたとえば、お馴染みのブラックフライデーのような小売店向け販促サービスだ。クラウドの価値がいちばん分かりやすいのは、ブラックフライデーのようなイベントだ。ご存知のようにその日には、サーバーが大量のトラフィックの爆撃に見舞われる。

クラウドは常に、このようなイベントを容易にスケールアップできるが、しかし完全ではない。Amazonは昨年、Prime Dayにサーバーが遅くなった。リテールのウェブサイトが遅くなったりダウンすれば大量の売上を失うから、Googleはそれが起きないように企業を助けたい。

そのために同社は、オンラインのリテイラー専用のサービスeCommerce Hostingを提供する。この特別プログラムでリテイラーは、技術的なレビューやピーク時のオペレーションのサポートなど、行き届いた世話をしてもらえる、という。つまり小売企業のサイトが需要増でダウンしたときでも、損失の大きい惨憺たる結果が生じないようにする。

またGoogleのリアルタイム在庫管理ツールを使えば、店員もお客もどの品番のソックスがあるか、ないかを正確に知ることができる。これもGoogle Contact Center AIと同じく、AIを使っている。Cloud Visionテクノロジーにより、顧客がカメラを商品に向けると、類似製品や関連製品を教える。そしてRecommendations AIは、お客が買った商品の関連商品をおすすめする。

ShopifyやIkeaなども、同社のリテールの顧客だ。またAccentureやCapGemini、DeloitteのようなSIパートナーや、Salesforce、SAP、Tableauのようなソフトウェアパートナーとも協働している。

Googleはこのように多面的なサービスを揃えて、さまざまな垂直市場(業種別市場)に対応しようとしている。それにより、どの業種にも、クラウドのアドバンテージを享受してもらいたい。これが、Google Cloudがソリューションを売っていく新たな方法であり、それによってクラウドのマーケットシェアを増やしたいのだ。

関連記事: Salesforce and Google want to build a smarter customer service experience…SalesforceとGoogleがカスタマーサービスで提携(未訳)

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

API管理サービスのApigeeもハイブリッドのバスに乗り込んできた

今年のGoogle Cloud Nextは、ハイブリッド環境のサポートが大きなテーマだった。だから、同社が2016年に2億6500万ドルで買収したAPI企業Apigeeもまさに、その機に乗ろうとしている。米国時間4月9日、Apigeeはハイブリッド環境向けのプロダクトApigee Hybridのベータを発表した。

長年Oracleにいて最近Google Cloudに来たAmit Zavery氏とNandan Sridhar氏が、共著のブログ記事でこの新製品を説明している。「それはAPI管理プラットホームであるApigeeの新たなデプロイメントオプションであり、それによりユーザーはランタイムをどこででもホストできる。自分のデータセンターでもよいし、あるいはパブリックなクラウドのどれかでもいい」。

今朝Googleが発表したハイブリッド環境管理サービスAnthosと同様に、こちらはAPIをどこで動かしても単一の方法で管理しよう、というものだ(Anthos参考記事12)。

Zavery氏らのブログ記事は、次のように述べている。「Apigee Hybridによって、すべての環境にまたがる単一のそして完全なAPI管理ソリューションが得られる。ユーザーはAPIとそれらが露出するデータをコントロールでき、企業内のすべてのAPIに対する統一的な戦略を確保できる」。

この発表は、多様な環境から成る顧客のコンピューティングシステムをひとつの全体としてサポートしようとするGoogleの全体的な戦略の一環だ。そういう混成環境のことを、昨今はハイブリッドクラウドと呼ぶことが多い。今日のクラウドネイティブの世界では、この考え方は、ユーザーのデプロイメントをそれらがある場所にとらわれずに管理するための、単一のファブリックを提供することに通ずる。

このApigee Hybridも、そんな考え方の延長であり、しかもそれは今やコンテナ化とクラウドネイティブコンピューティングの最前線に位置するオープンソースツールのKubernetesを開発したGoogleにふさわしいやり方だ。ハイブリッドだから純粋にクラウドネイティブではないが、その精神は引き継いでおり、コンピューティング全般に対するGoogle Cloudのアプローチの視界にはしっかりと含まれている。だからこそ、それは、今年このカンファレンスで定義されようとしているのだ。

関連記事: GoogleAPI開発の上場企業、Apigee62500万ドルで買収へ

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

Google Cloudの2つの新データセンターがソウルとソルトレイクシティで2020年稼働

米国時間4月9日に開催されたGoogle Cloud Nextで同社は、2020年までに新しいデータセンターを2つ稼働させる。ひとつは韓国のソウル、もうひとつは米国のユタ州ソルトレイクシティである、と発表した。

同社は、他のウェブスケール企業たちと同じく、これまでの数年間、新たなデータセンターの建設に邁進してきた。今では15リージョンが計45ゾーンをホストしている。これにより同社は13カ国にプレゼンスがあり、2016年から2018年にかけては470億ドルという巨額の資本的支出を行ってきた。

Googleのデータセンター(画像提供: Google)

プロダクト管理のディレクターのDominic Preuss氏は、次のように述べた。「韓国ソウルの可用性は2020年の早期に発表できるだろう。これにより、アプリケーションを構築する顧客には3つのゾーンを持つ1つの新しいリージョンが提供される。なお、顧客には、その市場の自分たちの顧客にサービスを提供しようとしている多国籍企業や、グローバル展開を目指している地元企業が含まれる。これによって弊社は彼らのニーズに対応することができ、彼らは自分たちが望むやり方で顧客に奉仕できるようになる」。

さらに付け加えて、「ソルトレイクシティはオレゴンとロサンゼルスに次いで合衆国西部における弊社の第3のリージョンになる。デベロッパーは西部において、複数のリージョンにまたがる分散アプリケーションを構築できるようになる」。

なお、同社の発表では日本の大阪の新しいデータセンターは数週間後に稼働を開始する。インドネシアのジャカルタに建設中のデータセンターは、来年前半に稼働開始の予定だ。

【訳注】上の地図はおかしいので、正しくはこちらをご覧ください。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

GoogleはコンフィデンシャルコンピューティングのフレームワークAsyloに注力

昨年の5月にGoogleは、コンフィデンシャルコンピューティング(confidential computing, 機密計算)のためのオープンソースのフレームワークAsylo導入したクラウドの大手ベンダーの多くが歓迎しているこのテクニックは、システムのそのほかの…たぶん信頼性が低い…部分から隔離された、信頼性の高い実行環境をセットアップする。ワークロードとそれらのデータも信頼性の高い特別な領域に置かれるので、ネットワークやオペレーティングシステムの脆弱性に対するさらなる保護層が加わる。

とくに新しいコンセプトではないが、Googleによると、実際に採用することはきわめて困難だった。Google CloudのエンジニアリングディレクターJason GarmsとシニアプロダクトマネージャーNelly Porterが、今日のブログ記事で述べている: “このような利点にもかかわらず、この新興技術の採用は(1)特定のハードウェアへの依存、(2)複雑で難しい、(3)コンフィデンシャルコンピューティングの環境で使えるアプリケーション開発ツールがない、などにより阻まれていた”。そしてAsyloフレームワークの約束は、これらの言葉からも分かるように、コンフィデンシャルコンピューティングを容易にすることだ。

Asyloを使うと、これらの隔離された領域(enclave(s))で動くアプリケーションを容易に作れて、IntelのSGXなどさまざまなハードウェア/ソフトウェアベースのセキュリティバックエンドを使えるようになる。アプリケーションが移植されてAsyloをサポートするようになると、そのコードはAsyloがサポートする他のどんな隔離領域でも動く。

ただし現状では、コンフィデンシャルコンピューティングを取り巻く技術や実践の多くが流動的だ。Googleによると、まず、Asylo APIを使ってアプリケーションを作り、さまざまな隔離領域で動かすための、確立したデザインパターンがない。またハードウェアも、メーカーによって仕様が一定でないので、ハードウェアのレベルでの技術の相互運用性が保証されない。

“業界と協力して、コンフィデンシャルコンピューティングのアプリケーションをサポートするもっと透明で相互運用性のあるサービスを作っていきたい。そしてそれによって、(正しい互換性の)証明文書の検査や、複数の隔離領域間の通信プロトコル、複数の隔離領域にまたがる連邦的アイデンティティシステムなどを、分かりやすいものにしていきたい”、とGarmsとPorterは書いている。

そしてそのためにGoogleは今日(米国時間2/6)、Confidential Computing Challenge(C3)〔一種の懸賞企画〕というものを立ち上げた。それは、デベロッパーがコンフィデンシャルコンピューティングの新しいユースケースを作れるようにし、また、その技術を前進させていくことが目的だ。このチャレンジに入賞したら、賞金15000ドルと、Google Cloud Platformの使用クレジット5000ドルぶんがもらえる。賞品としてハードウェアもあるが、機種等は不明だ(PixelbookやPixelスマートフォンじゃないかな)。

また、Asyloのツールを使ってアプリケーションを作るやり方を学べるハンズオンラボが、3つ用意される。それらは、Googleのブログにあるコードを利用するなら、最初の1か月は無料だ。

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

データサイエンティストたちのモデルの活用度を高めるGoogle CloudのKubeflowパイプラインとAI Hub

今日(米国時間11/8)Google Cloudが、KubeflowパイプラインとAI Hubを発表した。この二つのツールは、データサイエンティストが、自分の作ったモデルをいろんな組織や企業で共通的に利用できるようにすることが主な目的だ。

Google CloudでAIとML製品を担当しているプロダクトマネージメントのディレクターRajen Shethによると、同社は、データサイエンティストたちが、モデルを作るけどそれが一度も使われない、という経験をしょっちゅうしていることを知っている。Googleによると、機械学習を団体競技にたとえるなら、モデルはデータサイエンティストから、それらを使ってアプリケーションを作るデータエンジニアとデベロッパーにパスされなければならない。

対策としてGoogleが発表したのが、Kubeflowパイプラインだ。それはKubeflowのエクステンションで、KubeflowはKubernetesをベースとするオープンソースの機械学習用フレームワークだ。パイプラインは要するにコンテナ化されたビルディングブロックのことで、機械学習のエコシステムに属する人たちを連係させて機械学習のワークフローを作り、管理する。

そうやってモデルをコンテナに入れたら、その後データサイエンティストは必要に応じてその中のモデルを単純に調整し、継続的デリバリのようなやり方で再ローンチできる。Shethによると、これによって企業内のモデルの利用の可能性がさらに広がる。

“Kubeflowパイプラインはユーザーに、いろんなパイプラインで実験する方法を提供し、信頼性があって再現可能な環境の中で最良の結果を作りだすものはどれか、を決められる”、とShethは、この新しい機械学習機能を発表するブログ記事に書いている。

同じく今日発表されたAI Hubは、その名のとおり、データサイエンティストがそこでいろんなMLコンテンツを見つけられる場所だ。そこには、KubeflowパイプラインやJupyterノートブック、TensorFlowモジュールなどなどがあるだろう。それは一種の公開リポジトリになり、Google Cloud AIやGoogle ResearchなどGoogleのさまざまなチームが素材を提供し、研究開発に関わるGoogleの専門的知識技能をデータサイエンティストが利用できる場になる。

しかしGoogleはこのハブに、公開ライブラリ以上のものを求めている。同社の見方では、そこはチームが自分たちの企業内で情報をプライベートに共有できる場にもなって、二重の目的に奉仕する。これによって、重要なビルディングブロックが中央的なリポジトリで可利用になるから、モデルの利用の拡大に大きく貢献するだろう。

AI Hubは今日からアルファで利用でき、Googleからの初期的コンポーネントの一部や、内部的リソースを共有するためのツールが提供される。そして今後は徐々に、提供物と能力の拡大が定常的に行われる予定だ。

Googleによると、これによってモデルが汎用のビルディングブロックになり、それによりモデルを容易に共有できる方法が提供され、モデルがさまざまに実用される機会が増えるだろう。これらのツールは、それを達成するための第一歩だ。

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

Google、Hangouts Meet用デバイスにボイスコマンドを導入

本日(米国時間7/24)Googleは、サンフランシスコで行われた同社のNextカンファレンスで、近々Googleの電子会議用ハードウェアを強化しボイスコマンドを使えるようにすると発表した。

多くの人々にとって会議のセットアップは今も大きな頭痛の種である。同社はGoogle Assistantなどのツールで使われている音声対応人工知能と同じものを、会議用ハードウェアにも載せたいと考えた。そこで今日、GoogleはVoice Command for Meetを発表した。

これでユーザーは、”Hey Google, start the meeting.” と言えるようになる。そしてこれはまだ始まりにすぎない。Googleは、今後コマンドを増やしていくことを約束した。この機能は今年中に提供される予定だ。

つい昨年秋、GoogleはHangouts Meetハードウェアプログラムをスタートさせた。これは、Meetの利用者が、Googleあるいは多くの会議室で見られるCiscoやPolycomの伝統的ハードウェアを使って会議を開催する方法を提供するものだ。Googleの報告によると、Hangout Meet対応の会議室はすでに何千か所も作られている。

会議のセットアップや参加者の招待などを音声で行う簡単なコマンドを提供することで、時として複雑になる会議運用を著しく簡易化できる。会議システムは生まれてから何年にもなるのに、不必要に複雑で多くの人たちをいら立たせてきた。

もちろんユーザーたちは、Google HomeやAmazon Echoなどのおかげで、デバイスとのやり取りには慣れている。

音声対応ハードウェアを会議室に持ち込もうとしているのはGoogleだけではないことにも注目されたい。昨年11月、 CiscoはCisco Spark Assistantを発表し、Cisco製会議室用ハードウェア専用の音声コマンドを提供した。それを支える音声認識技術はMindMeldの買収によるものだ。Ciscoは2017年5月にこの会話型AIのスタートアップを1.25億ドルで買収した

[原文へ]

(翻訳:Nob Takahashi / facebook

Google Cloudが古典的ファイルシステムを必要とするアプリケーションのためのストレージオプションを用意

Google Cloud Platform(GCP)のストレージオプションが、新たにまた一つ増える。そのCloud Filestoreと名付けられたサービスは、来月ベータでローンチするが、それは要するに、クラウド上の完全な管理を伴うnetwork attached storage(NAS)だ。これにより、ストレージに対して従来的なファイルシステムのインタフェイスを必要とするアプリケーションを、GCP上で動かせるようになる。

従来のようにストレージの利用インタフェイスとしてオブジェクトストレージやデータベースしかないGCPのような環境で標準的なファイルシステムを使いたければ、それ専用に恒久的に使うハードディスクを使ってファイルサーバーを急ごしらえするしかない。Filestoreはそんな面倒を取り除き、ユーザーが必要に応じて簡単にストレージを確保できるようにする。

Filestoreは、高スループット、低レイテンシー、そして高IOPSを約束している。料金体系はプレミアムとスタンダードの2種、そしてプレミアムは、1GB/月が30セントで、ストレージの容量にかかわらず700MB/sのスループットと30000IOPSを約束する。スタンダードは1GB/月が20セントで、パフォーマンスは容量でスケールし、Filestoreに10TB以上を保存するまではピークパフォーマンスに達しない。

GoogleはFilestoreをロサンゼルスで行われたエンターテインメントとメディア関連のイベントでローンチした。その業界には、共有ファイルシステムを必要とする大量のエンタープライスアプリケーションがあり、またそのような種類のエンタープライスアプリケーションは、他のさまざまな業界にもたくさんある。

Filestoreベータは来月ローンチする。ベータ時点では、アップタイムの約束はなく、またベータを終えるETAもまだない。

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

Kubernetesのための機械学習ツールKubeflowが発表から4か月で最初のバージョンをリリース

Googleが作ったオープンソースのコンテナオーケストレーションツールKubernetesは、おそらく同社が想像しなかったほど華々しく成長した。そしてその人気が増すとともに、多くの関連プログラムが生まれてきた。今日(米国時間5/4)はGoogleが、オープンソースのツールKubeflowのバージョン0.1のリリースを発表した。これは、Kubernetesのコンテナに機械学習をさせるためのツールだ。

Googleはかなり前にKubernetesをCloud Native Computing Foundationへ移したが、積極的な関与は継続し、今回のKubeflowもそのひとつだ。このプロジェクトは昨年末オースチンで行われたKubeconで発表されたばかりだが、早くもかなりの勢いがついている。

GoogleでKubeflowを運用しているDavid Aronchickは、その前の2年半、Kubernetesのチームを率いた。その彼の言うKubeflowの基本的な考え方とは、データサイエンティストたちが、Kubernetesのクラスターの上で機械学習のジョブを動かせるアドバンテージを享受できることだ。Kubeflowを使って機械学習のチームは、既存のジョブを簡単にクラスターに付けられる。

今日の発表でプロジェクトは前進を開始し、その節目を報告するブログ記事は、安定性のアップと、コミュニティの要望に応じて実装した多くの新機能を強調している。新機能には、機械学習のジョブをコラボレーションと対話により訓練するJupyter Hubや、Tensorflowの訓練とホスティングなどが含まれる。

Aronchickが強調するのは、このプロジェクトがオープンソースなので、いろんなツールを使えるということ。最初のバージョンがGoogleの機械学習ツールばかりサポートしていても、 Tensorflowに縛られることはない。今後のバージョンでは、そのほかのツールのサポートも期待できる。

最初の発表からわずか4か月あまりでコミュニティは急速に成長し、70名を超えるコントリビューターと20社あまりのコントリビューター企業がいて、15のレポジトリーに700以上のコミットが行われた。次のバージョン0.2は、夏になる。

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

Google Cloudのマネージドデータベースサービスがクラウドサービスとしての機能を充実

Googleがクラウドから提供しているデータベースが今日(米国時間4/25)、アップデートされた。画期的な新製品に生まれ変わったわけではないけど、それらのアップデートはすべて、企業がクラウドへ移行するときに経験するさまざまな痛点に対処している。

Googleのプロダクト管理のディレクターDominic Preussによると、Googleは長年、データベースの世界における思想のリーダーを自負している。思想のリーダーとは言ってもこれまでは、Bigtableに関するペーパーなどが主で、実際の製品で示す思想ではなかった。しかし最近では、グローバル分散データベースCloud Spannerが示すように、市場でもその姿が目立つようになった。

Preussによると、Googleのエンタープライズユーザーは彼らの既存のワークロードをクラウドへ移すことから始めるところが多い。しかしそれが一巡したら、新しいアプリケーションをクラウドに載せようとする。そしてそのとき求めるのが、クラウドのプロバイダーがアプリケーションやインフラの管理を肩代わりしてくれる、いわゆるマネージドサービスだ。

今日の発表も、エンタープライズに、彼らが求めるある種のマネージドデータベースサービスを提供していくことがメインのテーマだ。

まずそれは、ベータでローンチされるCloud Memorystore for Redisだ。これは完全に管理されるインメモリのデータストアで、大きなバッファリングをインメモリのキャッシュでやりたい、などのニーズに応える。

ビッグデータワークロード用のNoSQLデータベースサービスCloud Bigtableに、新しい機能が加わった。その、いずれregional replication(リージョナルレプリケーション)という正式名で呼ばれることになる機能は、オンプレミスのワークロードにApache Cassandraを使っていたエンタープライズに、Google Cloudにおけるその代替系を与える。そして、この、異なるゾーンにまたがるレプリケーションにより、Google Cloudに保存するデータの可用性と耐久性が高くなる。

今回のアップデートには、Cloud SQL for PostgreSQLのSLAにおける可用性を99.95%にすることも含まれる。またCloud Spannerには、コミットのタイムスタンプがつく。

Googleのクラウドデータベース周辺には、今後どんな新メンバーが登場するのか。Preussはその答を言わないが、今同社はエンタープライズができるだけ多くのワークロードをクラウドへ移行できるようにしたい、と考えているそうだ。つまり、マネージドサービスが今後も増える、ということだろう。

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

Google Cloudがアプリケーションパフォーマンスモニタリングのツール集を提供

Googleのクラウドプラットホームでは、社内用に作ったツールやサービスがGoogleのプロダクトとして顧客に公開提供されることが多い。今日(米国時間3/28)同社は、その一環として、Google Cloud Platformの上でアプリケーションを構築するデベロッパーにとって重要な、アプリケーションのパフォーマンス管理(application performance management)ツール集Stackdriver APMを発表した。

APMの考え方はやや変わっていて、問題の責任をオペレーションに渡すのではなく、デベロッパーがアプリケーションを調べる。つまりアプリケーションを作ったデベロッパーがコードにいちばん近いところにいるので、そこから出てくる信号もいちばんよく理解できるはずだ、とする。

StackDriver APMは、三つのツールで構成される: プロファイラーとトレース(トレーサー)とデバッガだ。トレースとデバッガはすでに利用できるが、しかしプロファイラーと併用することによって、三つのツールが協働してコードの問題を特定し、調べ、そして修復できるようになる。

Stackdriver APMを発表するブログ記事でGoogleのプロダクトマネージャーMorgan McLeanはこう書いている: “これらのツールのすべてが、どんなクラウドの上で動くコードやアプリケーションでも扱えるし、オンプレミスのインフラでも使える。つまり、アプリケーションがどこで動いていても、一貫性がありアクセス性の良いAPMのツールキットを使って、アプリケーションのパフォーマンスをモニタし、管理できる”。

ほかにStackDriverにはモニタリングとロギングのツールもあり、これら完全なAPMのスイートが、SplunkやDatadog、New Relic、AppDynamics(Ciscoが買収)などのベンダと競合することになる。しかしGoogleのプロダクト管理担当VP Sam Ramjiによると、これらのベンダは競合他社であるだけでなくパートナーでもあり、お互いのツールが協働して問題解決に取り組むことを、Googleも十分に理解している。

“しかし、コアシステムがみんなによく見えるようにする点では、うちが一番だ。人びとはこれまで使ってきたお気に入りのツールをこれからも使って、彼らの企業の事業目的という見地からプロダクションシステムを検査したり、適切なタイミングでアラートしていくだろう”、と彼は述べる。

まず最初は、プロファイラーの出番だ。これによりデベロッパーは、軽量級の(全量ではなく)サンプリングベースのツールで、アプリケーションのすべてのインスタンスからデータを収集する。

Stackdriver Profiler. 画像提供: Google

プロファイラーが集めたデータから問題を判定したプログラマーは、次にトレースを動かす。Ramjiによると、コードの問題はほとんどつねにクリティカルパスの後(あと)にあるから、このツールを使えば、問題が分散システムの全域にわたって伝搬していく様子を理解できる。トレースの画面(下図)は視覚化されたアナリティクスのような形をしていて、これらにより問題の性質と、計算資源に対するそのインパクトが分かる。

Stackdriver Traceツール。 画像提供: Google

そして最後がデバッガだ。Ramjiがこれをとくに好きなのは、若き日の90年代のツールを思い出させるからだ。当時はデバッガでアプリケーションを止めたり動かしたりしながら、問題の所在を突き止めていた。このAMPのデバッガもやはり、指定した箇所でコードを止めて、問題の核心を見つける。

ただしこの現代的なデバッガには、Ramjiが“マジック”と呼ぶものがある。デベロッパーによるコードの停止や再開が、顧客に影響を及ぼさないのだ。McLeanもこう書いている: “プログラマーにおなじみのブレークポイント方式のデバッグ処理を提供するが、それによって顧客へのネガティブなインパクトはない”。

Stackdriver APMは今日(米国時間3/28)から可利用になり、完全なサービスから成る完全なモニタリングスイートが提供される。これでGoogleは、モニタリング〜デバッグという分野でも、既存の選手たちと競争するつもりのようだ。

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

AppleはiCloudのデータをGoogle CloudとAmazon S3に保存している

AppleがiCloudのためにサードパーティーのクラウドサービスを利用していることはよく知られている。そしてCNBCは、Apple自身の文書に興味深い情報があることを発見した。現在Appleは、iCloudデータの保存にAmazon S3およびGoogle Cloudのストレージサービスを使っている。

去る2016年、CRNはAppleがクラウドストレージに関してGoogleと契約を結んだことを報じた。しかし、Appleの文書は初めてこの関係を正式に認めた。

この情報は2018年1月発行のApple iOS 11セキュリティー・ガイドに書かれている。そこにはユーザーのファイルが小さな断片に分割かつ暗号化されて保管されていると説明されている。暗号化キーとメタデータ情報はAppleの自社サーバーに保管される。しかし、暗号化されたファイル自身はサードパーティーのサービスに保管される。

ユーザーは、AmazonやGoogleが自分のiCloudデータを管理しているとは思いもよらないだろうが、暗号化キーがなければAmazonとGoogleはこれらのファイルをどうすることもできない。つまり、AmazonやGoogleにデータを見られる可能性は極めて低い。

「暗号化されたファイルの断片にユーザーを特定できる情報は含まれておらず、S3、Google Cloud Platformなどのサードパーティー製ストレージサービスを利用して保存される」と文書に書かれている。

かつてAppleは、Microsoft Azureとの提携関係に言及したことがある。文書の文言はいまひとつ明確ではない。Appleは名前を出さずに他のサービスも使っているかもしれない。

いずれにせよ、これはいわゆる「非対称競争」の好例だ。AppleとGoogleはスマートフォン市場のシェア争いで非常に激しい戦いを繰り広げているが、AppleはGoogleの顧客でもある。AppleはAmazonやMicrosoftとも別の分野で競合している。したがってAppleがライバルとの関係を完全に断ち切るためには、クラウドホスティングをいっそう強化する必要がありそうだ。

[原文へ]

(翻訳:Nob Takahashi / facebook

Google Cloud PlatformがGPU使用のVMインスタンスを最大36%値下げ、AWSを意識か

Googleが今日(米国時間11/20)、Google Compute Engineの、Nvidia’s Tesla GPUを使用するインスタンスを最大36%値下げする、と発表した。アメリカのリージョンでは、やや古いK80 GPUを使うと1時間0.45ドル、新しくて強力なP100マシンは1.46ドルになる(いずれも秒課金による)。

またプリエンプティブルVM用のローカルSSDは、40%値下げされる〔参考: 8月の値下げ〕。GPUは、プリエンプティブルVMでは使えない。だから値下げは朗報でも、GPUのユーザーには関係ない。

今回のGPUインスタンスの値下げは明らかに、クラウド上で機械学習のワークロードを動かすユーザーのためだが、そのほかにも物理シミュレーションや分子モデリングなど、数百のコアを持つGPUを有利に使えるアプリケーションはいろいろある。たとえばGoogle Cloud Platform上ではまだベータであるP100は、コア数が3594 だ。

インスタンス一つにつき、P100は最大4基、K80なら8基を使える。通常のVMと同じくGPUユーザーにも継続利用割引はあるが、実際にはGPUを1か月動かしっぱなし、というユーザーはあまりいない。

AWSの今年のデベロッパーカンファレンスが来週からラスベガスで行われるが、Googleの今回の発表は明らかにそれを意識していると思われる。AWSも今年はAIや機械学習関連の発表が多いだろうし、値下げも当然ありうるだろう。

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

GoogleのCloud Spannerデータベースがマルチリージョンをサポート、年間ダウンタイム累計5分未満を約束

Googleのグローバルな分散データベースCloud Spannerが今日(米国時間11/14)アップデートされ、マルチリージョン(複数リージョン)がサポートされた。データベースを複数のリージョンにまたがって複製しても、レイテンシーは増えず、良好なパフォーマンスが保証されるという。また、サービス水準合意(Service Level Agreement, SLA, サービス品質保証)も、顧客が満足すると思われる方向へ改定された。

上記後者(新SLA)によると、Cloud Spannerデータベースは99.999%(five nines)の可用性が保証される。Cloud SpannerのプロダクトマネージャーDeepti Srivastavaによると、これは年間のダウンタイムに換算すると5分未満となる。

“システムの可用性と効率を高める改造を行ったので、サービスにそのことが反映されると期待される”、と彼女は述べる。なお、Cloud Spannerは、このようにサービスとして提供される前には、AdWordsなどGoogle内部のプロダクトで使われていた。今でもそうだから、GoogleにとってAdWordsがダウンしたら直接、売上に響く。だからまずGoogleにとって、それはダウンタイムがあってはならない。今では同社の人気サービスの多くが、Cloud Spannerを使っている。

“それは、Googleが動かしているミッションクリティカルなアプリケーションの最前線でテストされている”、とSrivastavaは説明する。

しかしこれまでは、複数リージョンにまたがるサポートが欠けていたので、Cloud Spannerを一箇所に置くことしかできなかった。それが、今日のマルチリージョンサポートの発表で変わった。ユーザー企業は、データベースをエンドユーザーに近いところに置けるようになる。それにより当然、レイテンシーが減り、応答性が良くなるだろう。

Cloud Spannerは今年の初めにベータで提供されたが、それはまるでマジックのように思えた。それは、SQLデータベースのようなトランザクションの一貫性と、NoSQLデータベースのスケーラビリティを兼備している。この両者が揃うことは稀であり、今日ではEvernoteやMarketoなどもCloud Spannerを利用している。

Googleは、Cloud Spannerの導入はわずか4クリックで完了、と謳っているが、既存のデータベースを移行する場合はそう簡単ではないだろう。Srivastavaによると、それはシステムのタイプ次第だ、という。まったく新しいアプリケーションのために新たに導入するのは簡単だが、Cloud Spannerを使うために既存のデータベースシステムのアーキテクチャを変えなければならない場合は、それなりの時間がかかるだろう、と彼女は語る。

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

Google Clond Platformはエンタープライズに専用オンランプとしてのインターコネクトを提供

Googleは9月に、Google Cloudのエンタープライズユーザーのための専用インターコネクトローンチした。Google Cloud Platformへのこのような直接接続は、企業にGoogle Cloudへのプライベートなオンランプを与え、それは自社のデータセンターと、Googleのデータセンターで動くアプリケーションを組み合わせるときとくに重要だ。今日(米国時間10/31)その専用インターコネクトがベータを脱して、いくつかの新しい機能を獲得した。

企業はGoogleのクラウドに接続するために、GoogleがサポートしているコロケーションファシリティからGoogleのネットワークにつながる。Googleが先月ベータを発表したときは、そういうロケーションが35あった。今日のアップデートで、さらに4箇所(アトランタ、ムンバイ、ミュンヘン、モントリオール)が加わった。〔参考

並行して重要なのは、GoogleがグローバルなデータセンタープロバイダーEquinixとパートナーしたことだろう。それは、“専用インターコネクト(Dedicated Interconnect)へのアクセスをグローバルな複数のマーケットに提供するため”、とされている。このパートナーシップの詳細は不明だが、これによりGoogleのインターコネクトのリーチが現在のロケーションを超えて拡大するだろう。ただしこのサービスはすでに、Equinixのデータセンターの相当多数をサポートしている。

このDedicated Interconnectには、新たなロケーションに加えてCloud Router Global Routing(専用ルーティング)のサポートがある。これにより企業は、自分のデータセンターをGoogle Cloud Platformにつないで、その世界中のさまざまなリージョンにある自社のサブネットのすべてに、このインターコネクトから容易にアクセスできる。

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

クラウドインフラストラクチャ市場ではAWSの支配が当分続きそう、後続との差は大きい

【抄訳】
AWSは今四半期でも、クラウドインフラストラクチャ市場の無敵のトップだ。いわゆる成長率ではMicrosoftやGoogle、Alibabaなどが高いが、彼らは分母が小さすぎるから、その成長はAWSから見れば痛くも痒くもない。

AWSの今四半期の売上は、45億7000ドルという巨額だ。この額はアナリストたちの予想45億1000万ドルを上回り、この成長率が続けば2017年の年商が180億ドルに達しそうなペースだ。

“でも、Microsoftのクラウド部門は年商200億ドルでしょ?”、と言うのは無意味な比較だ。なぜならそのクラウド部門なるものに大きく貢献しているのはAzureのようなインフラプラットホームではなくて、Office365などのSaaSビジネスだ。IaaSとかSaaSとか、クラウド方面の謎のような言葉は、この記事で勉強できるだろう。

クラウド市場を追い続けるアナリスト集団Synergy ResearchのJohn Dinsdaleによると、クラウド市場のマーケットシェアを云々するときはSaaSを別立てで計算すべきである。そしてIaaSとPaaSおよびプライベートクラウドを合わせた市場では、SynergyによるとAWSのシェアは35%だ(下図)。他社は、はるか後方に引き離されている。

【中略】

Synergyが作った上図を見ると、AWSはいわゆる“ダントツ”である。Microsoftも頑張ってはいるが、AWSには接近できない。同じくアナリスト企業のCanalysは、やや低い31%をAWSのシェアとしているが、市場の全体像としてはSynergyの結果とほぼ同じだ。

ちょっと意外なのは、これら競合サービスの成長率の高さかもしれない(上図および下図)。Canalysの数字では、AWSの成長率およそ40%に対してMicrosoftは90%、Googleはおよそ75%だ。でも、小額な売上増でも、分母が小さいと増加率は大きくなるのであり、いずれにしても当分は、AWSの牙城はびくともしない。

もちろんクラウド市場はまだ飽和にはほど遠くて、今後ますます大きくなると予想されるが、成長率の高いMicrosoftも含めて、AWSにとって‘脅威’と言えるほどのコンペティターはまだ存在しない。

CanalysのリサーチアナリストDaniel Liuは、こう言う: “AWSは多様なサービスとデベロッパーの大きな知名度により、先行馬としての優位を維持し続ける。しかし後続集団の中での先頭は、伝統的にエンタープライズに強く、Office互換性という有利性を持つMicrosoftだろう。Microsoftのもうひとつの強みは、強力なハイブリッドクラウドソリューションにおける技術と経験だ”。

一方AWSのCEO Andy Jassyは、自社の優位性についてそれほど楽観的ではない:

“これからの市場では、一人勝ちはありえない。この業界はコストが大きいし、サービスの品揃えの豊富さと最先端性が重要だから、30社が市場にひしめくということはありえないだろう。でも、成功者が複数社になることはほぼ確実で、それらの名を今挙げることはできない。でも長年のエンタープライズ顧客が多くて営業に大軍を抱える古顔たちが、きっとその中にはいるだろう”。

でも、少なくとも現状のクラウドコンピューティング市場では、各社間の売上規模の格差が大きく、またクラウドサービスの内容も多様なので、成長率等の数字を見るときは注意が必要だ。

〔訳注: 各社、発表している数字の部門分けなどがまちまちなので、成長率90%、75%のMicrosoftやGoogleが、成長率40%のAWSに追いつくのは何年後か、という単純計算も、一般に公表されている数字からはできない。〕

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