タグ: Cloud

Dropboxのコラボレーション層Paperがメジャーアップデートで多様なコンテンツに対応

Dropboxのようなストレージサービスが企業ユーザーの獲得を目指すときは、単純なファイル共有を超えた機能の提供が必要になる。Dropboxが、これまで欠けていたコラボレーションの層としてPaperを作ったのも、そのためだ。今日（米国時間9/3）同社は、プログラムを切り替えたりせずにコラボレーションツールの中だけで仕事ができるための、拡張機能をPaperに導入した。

“Paperは、チームのためのDropboxのコラボレーションの場だ。複数のユーザーが一緒に仕事をできるための機能がいろいろあり、締め切りを決めてオーナーにタスクを割り当てたり、YouTubeやSoundCloudやPinterestなどのマルチメディアコンテンツを埋め込むこともできる”、とDropboxは説明している。

今日発表された拡張機能で、Paperの中にさらにほかの要素を取り込めるようになった。たとえばPaperの中でDropboxのフォルダーへリンクして、ファイルの中身を見たり、サブフォルダーへ降りて行ったりもできる。リンクはフォルダーそのものへのリンクなので（コピーではないので）、ファイルへのアップデートはPaperの中のビューにもすぐ反映する。これはDropboxのような企業にとって、かなり思い切った機能だ。

画像提供: Dropbox

今のDropboxは、スプレッドシートをパワーアップしたような機能Airtableをサポートしているが、今回のPaperのアップデートで、Airtableを埋め込みコードでPaperに取り込めるようになった。これも、Airtable本体のアップデートが即、Paperのビューに反映される。

さらにこれからのPaperは、Googleのコラボレーション機能のように、図表を作れるLucidchartをサポートする。これも、フォルダーやAirtableと同じく、ライブのビューをPaperの中で見られる。つまり図表本体が変わればPaper上の図表も変わる。

Paperの中で、これだけいろいろなことができるから、プログラムをあちこち切り替える必要がない。最近BoxがActivity StreamとRecommended Appsを発表したのも、同じような理由からだ。Slackが企業で人気が高いのも、同じ理由だ。つまり、ひとつのコラボレーションツールの中で、いろんなアプリケーションのコンテンツをシェアできる。そのために大量のタブや、別のアプリケーションを開かなくてもよい。

Dropbox Paperではさらに、ユーザーがあちこちのアプリケーションのコンテンツサイロを訪ねなくても、一箇所でいろんなプレビューを見ながら、最後まで中断なく仕事ができる。Dropboxはこの機能を、企業顧客獲得の決め手にしたいのだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

GoogleがKubernetesの開発インフラの自社負担から降りてすべてをCNCFに委ねる

Googleが今日（米国時間8/29）、同社がCloud Native Computing Foundation(CNCF)に、Google Cloudのクレジット900万ドルを提供して、Kubernetesコンテナオーケストレータの同団体による今後の開発を支援し、プロジェクトの運用に関わるコントロールを同団体に委ねる、と発表した。このクレジットは3年分割で提供され、Kubernetesソフトウェアの構築や試験、配布などに要する費用に充当される。

これまではGoogleが、このプロジェクトを支えるクラウドリソースのほとんどすべてをホストしていた。その中にはたとえばCI/CDによるテストのためのインフラストラクチャや、コンテナのダウンロード、同社クラウド上のDNSサービスなども含まれている。しかしGoogleは今回、一歩後退することになった。Kubernetesコミュニティの成熟に伴い、GoogleはKubernetesのすべてのサポートワークをコミュニティに移そうとしている。

テストのためのインフラストラクチャからコンテナダウンロードのホスティングまで、すべてを合わせるとKubernetesプロジェクトは常時、15万あまりのコンテナを5000基の仮想マシン上で動かしている。その費用は、相当に大きい。Kubernetesのコンテナレジストリはこれまで、1億3000万回近いダウンロードに応じてきた。

それにまた現在のCNCFは、互いに競合する多様なメンバーを抱えている。Alibaba Cloud, AWS, Microsoft Azure, Google Cloud, IBM Cloud, Oracle, SAP, VMwareなどがその例だ。全員がCNCFの仕事やKubernetesのコミュニティから利益を得ている。Googleはこれまで黙っていたが、そろそろKubernetesのインフラストラクチャを動かす重荷を、それにふさわしい者に担わせるべきだろう。それにコミュニティのメンバーの一部は、KubernetesがGoogleのインフラストラクチャにあまりにも密接に結びついていることを、嫌っていた。

GoogleのKubernetes EngineのプロダクトマネージャーWilliam Denissが、今日の発表声明でこう書いている: “Kubernetesの運用責任をプロジェクトのコントリビューターが共有することによって、彼ら全員が持ち寄る新しいアイデアや効率性を生かせるようになるだろう。それが楽しみである”。彼によると今後も、Kubernetesのインフラストラクチャの運用には、Googleの意思が適宜反映されていく、という。

CNCFの事務局長Dan Kohnはこう述べる: “KubernetesのコミュニティにGoogleの大きな財政支援があることによって、このプロジェクトのイノベーションと採用の安定的なペースが今後も減衰することなく維持されるだろう。Google CloudがKubernetesのテストとインフラストラクチャに関わるプロジェクトをコントリビューターの手に渡したことによって、プロジェクトはオープンソースであるだけでなく、オープンなコミュニティによってオープンに管理されるものになる”。

今後長期的には、インフラストラクチャがGoogleのクラウドから離れることになるのか、そのへんはまだ分からないが、3年後に他のクラウドプロバイダーが同様のクレジットを提供することは、大いにありえるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google Cloudが音声↔テキストAPIを大幅アップデート、WaveNetでより自然な音声を

Google CloudのText-to-SpeechとSpeech-to-Text APIが今日（米国時間8/29）、大量のアップデートを行い、サポートする言語を増やし、いろんなスピーカーからの自動生成音声を聴きやすくし、スピーカーの音声認識ツールを改良してテキスト書き起こしの精度を上げる、などの機能向上を導入した。

このアップデートにより、Cloud Text-to-Speech APIが一般的に可利用になった。

多くのデベロッパーにとっていちばん魅力的なのは、17の新しいWaveNetベースの音声が複数の新しい言語でローンチしたことだろう。WaveNetはGoogle自身の技術で、機械学習を使ってテキスト読み上げのオーディオファイルを作る。その結果、より自然に聞こえる音声になった。

このアップデートで、Text-to-Speech API（テキスト読み上げAPI）は今や14の言語とそれらの変種をサポートし、標準音声30とWaveNetの音声26を揃えている。

ここへ行くと、今回加わった新しい音声も含め、自分のテキストでGoogleのデモを試すことができる。

新しい機能の中では、オーディオプロフィールもおもしろい。これは、再生するメディアに合わせてオーディオファイルを最適化する機能だ。たとえば、スマートフォンのスピーカーとテレビの下にあるサウンドバーでは、音が違うだろう。オーディオプロフィールを使うと、音声を、電話の通話やヘッドフォンやスピーカーなどなどに合わせて最適化できる。

[元の音声と最適化の結果]

Speech-to-Text（書き起こしAPI）の方では、複数のスピーカーからの音声をより正しく書き起こせるようになった。機械学習を使っていろんなスピーカーを認識し、ひとつひとつの語にスピーカー番号のタグをつける（スピーカーの数は人間が指定する）。たとえばスピーカー2つのステレオファイルなら、それぞれの言葉の出どころを区別できるし、怒った顧客がカスタマーサポートに電話をしている音声なら、やはり各語の話者を識別できる。

複数言語のサポートも、新しい。検索には前からあったが、これからはそれをデベロッパーが利用できる。この書き起こしAPIに対しては、最大で4つの言語を指定できる。するとAPIは、今どの言語が喋られているかを、自動的に聞き分ける。

さらに、Speech-to-Text APIは、単語のレベルでの自信点を返す。すでに個々の談話レベルの自信点はあったが、今度からはデベロッパーは単語レベルのアプリ構築ができる。たとえば、“please set up a meeting with John for tomorrow at 2PM”（明日の午後2時にジョンとのミーティングをセットアップしてくれ）に対して‘John’や‘2PM’の自信度が低ければ、ユーザーにそれらを二度繰り返させるアプリを書けばよい。‘please’の自信度が低くても、それは重要でない単語だから、そのままでよい。Googleのチームは、そう説明している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

VMwareがマルチクラウド管理のCloudHealth Technologiesを買収

VMwareは今週ラスベガスで、顧客のためのカンファレンスVMworldを開催しており、その席で同社は、ボストンのCloudHealth Technologiesを買収したことを発表した。買収の条件は公表されていないが、ロイターの報道では買収価額は5億ドルとされている。

CloudHealthはVMwareに、重要なマルチクラウド管理プラットホームを提供する。そのツールはAWS, Microsoft Azure, Google Cloud Platformなどをサポートし、ユーザーは、クラウドのコストや利用、セキュリティ、パフォーマンスなどを一つのインタフェイスから管理できる。

クラウド市場はAWSが大きくリードしているが、それは広大で急成長中の市場であり、多くの企業が複数のプラットホームを使い分けている。それぞれの目的にもっとも合ったクラウドサービスを使いたいからだ。

このマルチクラウドのアプローチには単一のプロバイダーに縛られないという利点はあるが、一方、その管理がたいへんになる。そこでCloudHealthはマルチクラウドのユーザーに、単一のツールでそれらの環境を管理する方法を提供する。

CloudHealthのマルチクラウド管理。写真提供: CloudHealth Technologies

VMwareでプロダクト管理とクラウドサービスを統括しているCOOのRaghu Raghuramによると、CloudHealthはマルチクラウドのオペレーションに伴うジレンマを解決する。彼曰く、“CloudHealth Technologiesが加わったことによって、複数のクラウドにまたがるコストとリソースや、アプリケーションのセキュリティとパフォーマンスを一元管理し、問題に迅速に対応できるようになった”。

つい先月、CloudHealthがサポートするクラウドプラットホームにGoogle Cloud Platformが加わった。CTOのJoe Kinsellaは、GCPのサポートを加えたことについて、こう述べている: “GCPでは、2015年にDiane Greeneが来て以来、いろんな企画が動き出し、エンタープライズへの適性が強化されている。その結果、われわれの顧客の間にも、急激に関心が高まっている”。

これによりCloudHealthの顧客も、大手プラットホーム三社のクラウドを安心して併用できるようになる。そして、かねてから顧客のハイブリッド環境や、マルチクラウド環境の管理を目指してきたVMwareにとっても、CloudHealthがいわば“買い時”になってきた。

これまで同社は、パブリッククラウドだけでなくプライベートクラウドやデータセンターも含めたすべての環境の一元管理を目指していた。それに対しVMwareもまた、さまざまなVMを使っている企業の、ハイブリッド環境の支援を、近年は志向してきた。

CloudHealthは、マルチクラウド管理のソリューションだけでなく、Yelp, Dow Jones, Zendesk, Pinterestなど、3000社の顧客をVMwareに連れてくる。

CloudHealthは2012年に創業され、これまで8700万ドルを調達している。最近では2017年6月のシリーズDで、Kleiner Perkins率いるラウンドにより4600万ドルを調達した。それよりも前のリード投資家は、Sapphire Ventures, Scale Venture Partners, そして.406 Venturesだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

CI/CDを末端企業にも普及させたいArmoryはY Combinator出身で$10Mを調達

オープンソースのSpinnakerプロジェクトをベースとするCI/CDプラットホームArmoryが今日（米国時間8/22）、シリーズAのラウンドにより1000万ドルの資金を調達したことを発表した。このラウンドはCrosslink Capitalがリードし、Bain Capital Ventures, Javelin Venture Partners, Y Combinator, そしてRobin Vasanらが参加した。

ソフトウェア開発は、ここ数年で確かに変わった。間隔の長いアップデート・サイクルに代わり、継続的デリバリが主流になってきた。このコンセプトは今では、継続的インテグレーション/継続的デリバリ(continuous integration/continuous delivery)を表すCI/CDと呼ばれている。Armoryのプロダクトは、このタイプのソリューションをデプロイするときに伴う複雑性を、軽減しようとする。

同社を創業したときファウンダーたちは、CI/CD技術のバックエンドのベースとしてSpinnakerを使う、と決めた。それは、GoogleやNetflixなど業界の大物たちが支持しているプロジェクトだからだ。ArmoryのCEOで協同ファウンダーのDaniel R. Odioが、今回の資金調達を発表するブログ記事でこう述べている: “Spinnakerは大規模で本格的なマルチクラウドのデプロイを支えるスタンダードになるだろう。自分たちで新たに継続的デリバリのプラットホームを内製で構築する、そんな車輪の再発明を避けて、SpinnakerをArmoryプラットホームのコアにするという、大きな賭をした”。

同社によると、その賭は報われ、Spinnakerの同社バージョンはエンタープライズのソリューションで広くデプロイされている。同社の目標は、Fortune 2000社がソフトウェアのデプロイを今よりずっと速くできるようになることだ。そしてそのためには、CI/CDのアクセスと理解が欠かせない。

今企業は、どんな企業でもソフトウェア企業になりつつあるから、どの企業もこれまでとは異質な部分を抱え込むことになる。GoogleやNetflixのような超大物は、最先端の方法により、ソフトウェアを驚異的なスピードでデプロイする方法を経験から学び構築しているが、製品の製造技術＝ソフトウェア開発技術ではない、そこらのふつうの企業は、ソフトウェア技術者もそんなに多くないから、Googleなどに追随することは難しい。

その空隙を補ってくれるのが、Armoryのような企業だ。同社は、オープンソースの技術を核として、その複雑性を包み隠すパッケージにより、高度なソフトウェアデプロイ技術を持たない普通の企業でもCI/CDを導入できるようにする。

中でもとくに同社が強調するマルチクラウドでクラウドネイティブなソフトウェア開発方式は、ユーザーのアプリケーションやインフラストラクチャを、オンプレミスも含む複数のクラウドに分散可能にする。そのようなデプロイ技術の重要な部分が、継続的デプロイを管理する技術だ。

Armoryは2016年にローンチし、ベイエリアに拠を構える。これまで1400万ドルを調達したが、そのうちの400万ドルのシードラウンドは昨年行った。同社はY Combinator 2017冬季の卒業生であり、Y Combinatorは今回の投資に参加している。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

AWS、VPSサーバーのLightsailを半額に値下げ

2016年に提供開始したAWS Lightsailは、Digital Ocean、OVHを始めとする低価格バーチャルプライベートサーバー（VPS）製品に対するAmazonの答だった。Lightsailはごく基本的なサービスとしてスタートしたが、この2年間にブロックストレージ、Windowsサポートの追加、リージョンの拡大などが加わった。

本日（米国時間8/23）Amazonは、新たに2つのインスタンスサイズを追加し、LinuxベースのLightsailインスタンスのほとんどを半額に値下げした。Windowsインスタンスも値下げされるが、値下げ幅は大部分が約30%だ。

Linuxインスタンスの中で唯一50%の値下げでなかったのは、5ドル/月の512 MBインスタンスで新価格は3.50ドル。これでも悪くはない。ニーズによっては512 MBでもプロジェクトをいくつか動かすのに十分なので、1 GBが必要ないユーザーはLightsailを使えばDigital Oceanの最小構成である5ドル/月よりも数ドル安くできる。実際、Lightsailの1 GBインスタンスも5ドル/月になったのも驚きではない。

どのインスタンスタイプも、SSDストレージ、SSHアクセス、固定IPアドレスを含めVPSホスティングサービスに期待される機能をすべて備えている。

例によってWindowsインスタンスは少々高くて（つまるところWindowsのライセンスはただではない）512 MBインスタンスが月額8ドルだ。より使いでのある1 GBインスタンスには毎月12ドルが必要だ。

新しいインスタンスサイズについては、16 GBインスタンスが4つのvCPUと320 GBのストレージ、および余裕の6 TBデータ転送速度を備える。32 GBインスタンスはvCPUとストレージが倍になりデータ転送速度が7 TBになる。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Google、データセンターの空調管理をAIに一任

データセンターの中は暑くてうるさい——そしてサーバーをオーバーヒートから守ることは運用コストの大きな部分を占めている。業界の大物、Facebook、Microsoft、Googleらがさまざまな方法で冷却コストの節減を目指しているのも当然だ。Facebookは可能な限り外部の空気を冷やす。Microsoftは水中データセンターを実験中。そしてGoogleは、同社のAIモデルを使っていっそうの節約を目論んでいる。

数年前、Googleは傘下のDeepMindを通じて、データセンターに最適な冷却方法を運用者に提供するために、機械学習の利用を探ってきた。しかし、当時はまだシステムは推奨するだけで実施するかどうかは人間のオペレーターが判断していた。今後その人たちは、午後の昼寝時間を長くとれるようになる。モデルが十分に進歩した結果、AIを備えたシステムに冷却システムの制御を任せられるとチームが判断したからだ。もちろん、オペレーターは今も介入できるが、AIが中止の決定をくださない限り、システムは無人運転を続ける。

  1. DME_DCIQ_v09-01.max-2000x2000

  2. DME_DCIQ_v09-02.max-2000x2000

  3. DME_DCIQ_v09-03.max-2000x2000

  4. DME_DCIQ_v09-04.max-2000x2000

 View Slideshow
Exit

新しい冷却システムは現在複数のGoogleデータセンターに設置されている。5分毎に、システムがデータセンター内の数千個のセンサーから値を取得しその情報を元に最適な行動を選択する。もちろん、そこには様々な抑制と均衡が働いているので、Googleのデータセンターがこのために崩壊する可能性は低い。

多くの機械学習モデルと同じく、システムはデータを収集すればするほど賢くなる。現在、これまでのデータセンターのエネルギー利用と比べて平均30%のエネルギー節約を実現している。

ひとつ指摘しておくべきなのは、Googleはわずかな節約のためだけなく、これを自社の機械学習サービスの宣伝のひとつと考えていることだ。つまるところデータセンターでうまくいくなら、大きなオフィスビルディングにも適用できるはずだ。「長期的には、このテクノロジーをほかの環境にも適用し、より大規模な空調にも役立てる可能性があると考えている」、とDeepMindが今日の発表文に書いている。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

Google Firebaseのアップデートでアプリ内メッセージング、JIRAの統合などが加わる

Firebaseは今やGoogleのデフォルトのアプリ開発プラットホームであり、買収から今日までの4年間で機能とGoogleのサービスとの統合を大きく拡充したきた。そして今日（米国時間8/16）は、そのさらなるアップデートにより、新しい機能と、より深い統合と、そしていくつかの新しいデザインがこのサービスに導入された。

このリリースのハイライトは、アプリ内メッセージングのローンチだ。この機能により、ユーザーがそのアプリを使っているときに、特定のユーザーに向けた(targeted)、しかもそのときの状況に合った(contextual)メッセージを送れる。このアプリ内通知機能はルック＆フィールをデベロッパーがカスタマイズでき、今日から展開されるが、たぶんもっと重要なのは、この機能がFirebase PredictionsやGoogle Analytics for Firebaseと統合されていることだ。そのため、ユーザーの現在の行動に反応するだけでなく、どれぐらいのお金を使いそうか、とか、アプリの使用をやめそうか、などの予測(predictions)に基づいてメッセージを送れる。

また今回のアップデートでFirebaseは、AtlassianのJIRAと統合される。これからはFirebaseのユーザーが、Firebase内のクラッシュレポートに基づいてJIRAのIssue（‘課題’）を作れる。この統合は、数週間後に有効になる。

2017年にTwitterから買収したクラッシュレポートツールCrashlyticsとの、より深い統合が実現した。これからはそのデータをBigQueryにエキスポートして分析し、GoogleのData Studioで視覚化できる。そしてBigQueryにデータを置いたら、Firebaseのデフォルトの保持/削除のルールとは無関係になる。

レポートに関しては、Firebase Cloud Messagingにレポート用のダッシュボードがつき、またFirebase ConsoleのProject Overviewのデザインが一新されて、アプリの健康状態やステータスをひとつのページで見られるようになった。Latest Releaseセクションでは、ライブデータもフィーチャーされる。これらの機能は今日から展開が始まり、数週間後には全員に行き渡る。

WebのコンテンツをホストできるサービスFirebase Hostingは、今回のアップデートにより、ひとつのプロジェクト内で複数のWebサイトをホストできるようになった。Webサイトのアップデートをプッシュしたら、変更されたファイルだけがアップロードされる。ささやかなスピードアップだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

クラウドネィティブ環境のためのセキュリティベンダーTwistlockがシリーズCで$33Mを調達

世界がクラウドネイティブなアプローチへ移行していくに伴い、アプリケーションとそのデプロイのセキュリティを確保する方法も変わりつつある。クラウドネイティブ環境のセキュリティを提供するTwistlockが今日、Iconiq CapitalがリードするシリーズCのラウンドで3300万ドルを調達したことを発表した。

これまでの投資家YL Ventures, TenEleven, Rally Ventures, Polaris Partners, およびDell Technologies Capitalも、このラウンドに参加した。これで同社の資金調達総額は6300万ドルになる。

Twistlockは、コンテナとサーバーレスのセキュリティという、困難な問題を解決する。両者はいずれも、本質的に短命な存在だ。それらは寿命が1秒の数分の一と短いので、問題が起きたときその追跡が難しい。同社のCEOで協同ファウンダーのBen Bernsteinによると、彼の会社は最初から、コンテナとサーバーレスコンピューティングがどれだけ短命でも、依然としてエクスプロイトされうる、という前提に立って、クラウドネイティブ環境を保護するためのセキュリティプロダクトを作っている。

Bernsteinは曰く、“寿命の長短は関係ない。むしろ重要なのは、それらの生き方が従来のコンピューターに比べて予測可能であることだ。従来のコンピューターは非常に長時間動くし、しかも多くの場合人間が使っているから、予測は簡単ではない”。

スクリーンショット提供: Twistlock

企業がクラウドネイティブな環境へ移行して、Dockerによるコンテナを使ったり、それらをKubernetesなどのツールで管理するようになると、デプロイ量の大きい、高度に自動化されたシステムを作ることになる。デプロイは自動化で簡単になるが、いろんな問題に対する脆弱性はそのまま放置される。たとえば悪者がコード注入攻撃でプロセスのコントロールを握ったりすると、誰も知らない間に大量の問題が起きていたりする。

Twistlockはそれを防ぐとともに、エクスプロイトがいつ起きたのかを顧客に認識させ、診断分析によりその原因を調べる。

それはサービスであるとはいえ、従来型のSaaSとは様子が違う。すなわちそれは同社のサーバーから提供されるサービスではなくて、顧客が使っているクラウド（パブリックまたはプライベート）にインストールされるサービスだ。今同社の顧客は200社あまりで、その中にはWalgreensやAetnaなど、誰もが知っている企業も含まれているが、顧客リストを公開することはできない。

2015年に創業された同社はオレゴン州ポートランドに本社があり、R&D部門はイスラエルにある。現在の社員数は80名だ。他社との競合についてBernsteinは、従来のセキュリティベンダーはクラウドネィティブをまだうまく扱えない、と言う。そして最近登場してきた若手スタートアップに比べると、少なくとも現状では、成熟度では自分たちが上だ、とも言っている。

“今はまだ、競争が激しくはないが、今後徐々にそうなるだろう”、と彼は述べる。今回得られた資金は、主にマーケティングと営業の拡充に充当して顧客ベースの拡大を図りたい。またクラウドネィティブのセキュリティも競合とともに技術が進化していくので、技術でもつねに先頭を走っているようにしたい、とBernsteinは言っている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

PrometheusモニタリングツールがCNCFの新たな‘卒業’プロジェクトとしてKubernetesに加わる

Cloud Native Computing Foundation(CNCF)はまだそれほどメジャーな名前ではないが、今急成長しているコンテナオーケストレーションツールKubernetesなど、いくつかの重要なオープンソースプロジェクトの本拠地だ。今日CNCFは、モニタリングツールPrometheusが、同団体の第二の“卒業”プロジェクトとしてKubernetesに加わったことを発表した。〔*: 卒業プロジェクト, graduated projecとは、育成涵養段階を脱して、単独・独立の“一人前の”プロジェクトとして扱われること。〕

その発表は、今週ミュンヘンで行われているPrometheusのカンファレンスPromConで行われた。CNCFのCTO兼COOのChris Aniszczykによると、卒業プロジェクトとはプロジェクトの全般的な成熟を表していて、コントリビューションやコミュニティや採用が多様になったことを意味している。

Prometheusの場合は、今すでに20名のアクティブメンテナーがおり、1000名以上のコントリビューターが13000あまりのコミットを行っている。コントリビューターの中には、DigitalOcean, Weaveworks, ShowMax, そしてUberなどがいる。

CNCFのプロジェクトはサンドボックスで始まり、インキュベーションの段階へ入り、そして最後に卒業する。卒業の条件は、CNCFのCode of Conduct（行動規範）の遵守、セキュリティ監査に合格、そしてコミュニティの統治構造が定義されていることだ。また、“コードの質とセキュリティのベストプラクティスに持続的にコミットしていること”も必要だ。

Aniszczykによると、Prometheusツールは時系列データベースにクエリー言語を結びつけたシステムで、ユーザー（主にデベロッパー）がターゲットシステムの問題を知るためにはそのクエリー言語で検索し、それに対する分析結果（アナリティクス）を得る。すでに感づいておられたと思うが、それはとくに、コンテナに適したツールだ。

Kubernetesと同様、のちにPrometheusになるプロジェクトも、ルーツはGoogleにある。Googleはコンテナを積極的に採用した初期の企業のひとつで、Kubernetesの前身であるBorgや、Prometheusの前駆システムBorgmonを開発した。Borgの仕事はコンテナのオーケストレーションを管理することで、Borgにmon(monitor)を付けたBorgmonの仕事はそのプロセスをモニタして技術者にフィードバックを提供し、コンテナの全ライフサイクルにおいて、その中で起きていることを察知させる。

ルーツはBorgmonでも、今ある姿のPrometheusは二人の元Googleエンジニアが2012年にSoundCloudで開発した。2016年5月には第二のCNCFプロジェクトとしてKubernetesに加わり、そして当然のように、第二の卒業プロジェクトになった。

その過程におけるCloud Native Computing Foundationの役割は、クラウドネイティブコンピューティングを推進することだ。どんなに違いのあるインフラストラクチャでも共通のやり方で管理できる、とするその概念は、オンプレミスとクラウドのリソース管理に伴う複雑性を大幅に軽減した。CNCFはLinux Foundationの一員であり、そのメンバーにはテクノロジー業界の大物たちが多い。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google CloudがNvidiaのTesla P4推論アクセラレーターをサポート

今やクラウドプラットホームは、GPUのサポートなくして完全とは言えない。今日のハイパフォーマンスワークロードや機械学習のタスクは、それなくしてサポートできないからだ。それらは多くの場合、機械学習のモデルの構築に使われることが多いが、しかし今日（米国時間8/6）Googleは、Nvidia P4アクセラレーターのサポートをローンチし、既存のモデルをより高速に走らせることによる推論の性能アップにフォーカスしようとしている。

また、これらの機械学習のワークロードのほかに、Google Cloudのユーザーは、高速なグラフィクスカードを必要とするリモートディスプレイのアプリケーションを、GPUを使って動かすことができる。そのためにGPUは、リモートデスクトップにログインするユーザーのためにサーバーサイドのグラフィクスの応答性を高めるシステム、Nvidia Gridをサポートする。

P4には8GBのDDR5メモリがあり、最大で毎秒22テラの整数演算ができるから、ほとんど何でもできるカードだ。しかも買うと2200ドル以上はするから、時間制で借りる方が賢明だろう。

Google Cloud上でP4を使うと、標準料金では1時間60セント、プリエンプティブルでよければ21セントだ。Googleの料金としてはP100やV100 GPUより安いが、ただし両者はユースケースがまったく違う。

この新しいGPUは最初、us-central1(Iowa), us-east4(N. Virginia), Montreal(northamerica-northeast1), europe-west4(Netherlands)の各リージョンで提供され、徐々にそのほかのリージョンでも提供される予定だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

サービスメッシュIstioがバージョン1.0に到達、マイクロサービスアーキテクチャの成熟を推進

Istioはマイクロサービスのサービスメッシュで、Google, IBM, Lyft, Red Hatなどによるオープンソースの共同プロジェクトだ。そして今日（米国時間7/31）は、そのツールのバージョン1.0がローンチした。

サービスメッシュをよく知らない人がいても、不思議ではない。むしろ今は、知らない人の方が多い。でもIstioはたぶん、今のオープンソースプロジェクトの中ではもっとも重要なもののひとつだ。それは、コンテナや、マイクロサービス、サーバーレスコンピューティングなど、今の業界のトレンドのいくつかが交わるところに位置し、エンタープライズがそれらをより容易に導入できるようにする。今Istioは200あまりのコントリビューターがいて、バージョン0.1がローンチして以来4000回以上もチェックインされている。

Istioの中心的な機能は、マイクロサービスのルーティングやロードバランシング、フローコントロール、そしてセキュリティだ〔日本語参考記事〕。それは既存の分散アプリケーション群の上に座って彼らの安全な対話を助け、またログ取りやテレメトリー、そして全体を安全に制御下に置くために必要なポリシーを提供する。カナリアリリースもサポートしているので、アップデートの本番ローンチの前に少数者でテストすることもできる。それはGoogleのようなWebスケールの企業が、内部的に前からやっていることだ。

GoogleのプロダクトマネージャーJennifer Linが、説明してくれた: “マイクロサービスの時代になると、いろんなものの移動や変化が激しくなる。Kubernetesの成功によってコンテナのオーケストレーションまわりは抽象化を果たしたが、Istioはオープンソースのプロジェクトとしてその次のステップを担い、マイクロサービス開発のための基盤となり、またVMベースのワークロードをなるべく多くサービス管理のレイヤへ移すためのパス（径路）も提供する。そのためそれは、サービスのための正しいレベルの抽象化にフォーカスし、またサービスを管理するための無矛盾な（整合性ある）環境を作る”。

1.0のリリースの前から、eBayやAuto Trader UKなどいくつかの企業がすでにIstioをプロダクションに採用している。Linの主張ではそれは、マイクロサービスを採用した多くの企業が今直面している問題を、Istioが解決してくれるというサインだ。“ますます多くの、ますます高度な顧客たちが自分たち独自のサービス管理レイヤを作ろうとトライし、そんな彼らがまだ1.0になる前からIstioに切り替えている。いくつかの有名大企業も含む多くの顧客が、‘1.0でなくても十分プロダクションで使える。われわれが作った粗っぽいものに比べると、随分ましだ’、と言っている”。

IBMのフェローでクラウド担当VPのJason McGeeも彼女の話に同調し、こう言っている: “Istioがローンチしてから以降のわれわれのミッションは、だれもがマイクロサービスで成功できるようにすることだ。とりわけ、エンタープライズがね。だからこそわれわれはコミュニティにフォーカスし、セキュリティとスケールの改良に努め、これまであらゆるサイズの企業のためにアジャイルなクラウドアーキテクチャを築いてきた経験から学んだことを、重点的にIstioにコントリビューションしてきた”。

大手のクラウド選手たちの多くが、今や直接にIstioをサポートしている。IBMは同社のKubernetes Serviceがそのベースだ。GoogleはGoogle CloudのユーザーにマネージドIstioサービスすら発表しているし、またKubernetesとIstioをベースに構築されるサーバーレスアプリケーションのために特製したオープンソースのツールも提供している。

今日のパーティーにはMicrosoftとAmazonの姿が見えないようだが、このプロジェクトが元気であるかぎり、彼らも必ず来るだろう。

現状ではIstioは、主なオープンソース団体のどれにも属していない。Kubernetesの本拠地であるCloud Native Computing Foundation(CNCF)は、Istioとそんなに変わらないlinkerdを推している。この種のプロジェクトは1.0がリリースされるころになると、長期的に支えてくれそうな団体を探すことが多い。Istioもきっとそのうち、居場所を見つけるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

サーバーレスアプリケーションのデプロイと管理を助けるServerless, Inc.が新たに$10Mを調達

Serverless, Inc.は、早くからサーバーレスを手がけ、2015年にはデベロッパーのためのオープンソースのフレームワークを作っている。今日では同社は、これまでのプロダクトをベースとして、サーバーレスアプリケーションのデプロイとデリバリをデベロッパーがもっとコントロールできるようにしたい、と考えている。そのために同社は、Lightspeed Venturesが率いるシリーズAのラウンドにより1000万ドルを調達した。これで同社の調達総額は、1300万ドルになる。

同社はまた、総合的なツールセットServerless Platformを発表した。これには、Serverless Framework（フレームワーク）のほかに、Serverless Dashboard（ダッシュボード）とServerless Gateway（ゲートウェイ）が含まれている。これらのうち、フレームワークでデベロッパーは、さまざまなクラウドプラットホームで使用するサーバーレスのコードをセットアップでき、ファンクションのルールやインフラストラクチャの依存性などの、クラウドごとの違いに対応できる。ダッシュボードは、デプロイに関する情報を視覚化し、サーバーレスファンクションの動作を、さまざまなクラウドプラットホームの上でモニタできる。

図表提供: Serverless, Inc.

ゲートウェイは、レガシーのツールをサーバーレスのアプローチに取り込む方法を提供する。同社の説明によると: “Serverless Gatewayで企業は容易にサーバーレスを既存のサービスのメッシュに統合できる。それらはコンテナやSaaS、そのほかのレガシーシステムなどさまざまだ。Event Gatewayが、サーバーレスのコンピュートと共に、企業のすべてのビジネスイベントにコードで反応する強力な方法を与える”。

同社のファウンダーでCEOのAusten Collinsによると、企業がサーバーレスファーストの考え方に移行すると、アプリケーションの構築とデプロイの費用が低下するが、しかしそのためには、チーム全体や大きな組織全体にわたって使えるツールが必要である。そして同社は、そんなツールを提供していくのだ、と。

“サーバーレスの開発を実運用にまで持っていくためのツールの需要が、今拡大している。それは、チーム全体のデベロッパーや、あるいは全社のデベロッパーが、サーバーレスの開発を安全かつスタンダードなやり方で実践できるためのツールだ”、とCollinsは説明する。

Collinsによると、フレームワークと通信ゲートウェイは今後もつねにオープンソースだ。同社が企業に課金するのは、サーバーレスのコードのインサイトを得るためのダッシュボードと、ゲートウェイのホステッドバージョンへのアクセスだ。しかしゲートウェイは、オープンソースバージョンを使って企業が自力でホストしてもよい。

サーバーレスによって、デベロッパーは必要なインフラストラクチャを気にせずに、自分たちのアプリケーションを動かすことができる。彼らが書くのはインフラストラクチャにアクセスするコードではなく、イベントをトリガするファンクションであり、そのイベントを動かすために必要なコンピュートとメモリーとストレージは、クラウドのベンダーが面倒を見る。

デベロッパーは、適切なインフラストラクチャのデプロイについて悩む必要がなくなり、ただ、ファンクションがイベントをトリガするときに使うインフラストラクチャに関してのみ、課金される。それは従来の、アプリケーションのためにサーバーをまるまるデプロイし、それらが使われても使われなくても24/7支払うやり方に比べると、きわめて対照的だ。

このやり方は確かに、アプリケーションの開発とデプロイに伴う複雑性をかなり取り去ってくれるが、しかし企業などの一連のポリシーに従ってコードを正しくデプロイし管理していく責任はデベロッパーの肩に100％残る。Serverless, Inc.が提供するようなツールは、そんな新しいやり方には（そのままでは、それだけでは）欠けているかもしれないコントロールやインサイトを、デベロッパーに与える。

2015年にローンチした同社は、現在社員が22名いるが、彼らは分散オフィスの形をとっている。メインのオフィスは、サンフランシスコにある。顧客の中には、EA SportsやNordstrom, Reuters, Coca-Colaなどがいる。今回得られた資金は、主に、同社プラットホームの拡大に充てられる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

GoogleがGoogle Driveを単独のサービスとしても提供、いずれはG Suiteのユーザーにするつもり？

企業でGoogle Driveを使いたければ、G Suiteの有料会員になるしかない。そこに含まれる、いろんな生産性ツールに用がなくても。でも今日（米国時間7/25）からは、あなたの会社はGoogle Driveだけの有料会員ユーザーになれる。

これまで、Googleのクラウド上のオフィスツールに関して企業からの要望がもっとも多かったのが、この、“Driveだけ”だった。そこで今回より、Google Driveは単独のサービスとしても使えるようになった。個人的には、そんなに需要は大きくないのでは、と思うけれども、そのストレージ機能や共有機能はG Suite上のバージョンとまったく同じだ。

基本料金はアクティブユーザー一人あたり月額8ドルで、それプラス、全社の保存量1GBにつき4セントだ。

Googleとしては、単独のGoogle Driveのユーザーを将来のG Suiteの見込み客とみなしているだろう。またGoogle自身も、まだまだレガシーのメールクライアントやWord, Excelなどデスクトップの生産性ツールに依存している企業が多いことを、百も承知だ。そんな企業に、いきなりクラウドを使えと言っても無理である。

Googleによれば、Driveのユーザーは今週中に10億に達する。“達した”と言わずに、“達する”と言うのは、なかなか奥ゆかしいね。でも実際に達した暁には、Googleの8番目のユーザー10億超えアプリケーションになる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

GoogleのBigQueryの中で機械学習のモデルを作れるBigQuery ML…データの移動が要らない

機械学習のモデルの構築にはまだ多くの障害があり、その一つが、データのあるところからモデルを構築するところへ、大量のデータを移動することだ。Googleはその工程を少しでも容易にするために、データウェアハウスBigQueryの中でモデルを作れる機能、 BigQuery MLを立ち上げた。

BigQuery MLを使うと、モデルをファインチューニングするためにデータを行ったり来たりさせることなく、データウェアハウスの中で線形回帰やロジスティック回帰を使ってモデルを構築できる。しかも、モデルを構築して予測を得るためにやるべきことは、少量のSQLを書くことだけだ。

データの移動がそんなに大きな問題だとは、ふつうの人には思えないかもしれないが、単なる物理的な移動ではなくて選択や整形などの処理が必要だから、かなりの時間を要する。そのぶん、モデルの構築に投じるべき時間がしわ寄せされる。

BigQuery MLでは、機械学習の経験の浅い者でも、容易にモデルを構築できる。まず、SQLの変種のようなもので、作りたいモデルの種類と、入力データを指定する。するとBigQueryMLがモデルの構築を開始し、そこから直ちに予測が得られるようになる。 RやPythonでコードを書く必要はない。

BigQuery MLは、今ベータを利用できる。

[若者の失業の解決、アルツハイマー病の検出、ほか]

画像クレジット: TechCrunch

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google、検索テクノロジーを企業に提供へ

Googleにとって最初のハードウェア製品ラインの一つは、検索アプライアンスだった。企業のファイアウォール内にGoogleの検索ツールを持ち込む特注サーバーだ。この製品はまもなくなくなるが、Googleは今日（米国時間7/25）、その精神的後継と言えるものをCloud Searchの改訂とともに発表した。これまでCloud SearchはG Suiteデータのみをインデックスしていた。これからは、企業内あるいはクラウドにある様々なサードパーティーサービスからデータを収集できるようになる。社内のあらゆるデータを従業員が検索できるようにしたい大企業にとって、これまでよりはるかに利用価値が高くなる。

「これは、事実上Googleの検索技術と知識のすべてを提供し、顧客のコンテンツに適用するものだ」とGoogleは言った。

この新サービスの初期顧客の一社であるWhirlpoolは、独自の検索ポータルを開発し、この新サービスを使って10種以上のサービスから1200万件以上文書をインデックス化した。

「これは従業員が企業を横断する全情報をアクセスできるようにするものであり、従来孤立化していたデータも含め、データベースであれ伝統的生産性ツールのデータであれ、すべて単一のインデックスで利用できる」とGoogleは説明した。

この機能を実現するために、Googleは様々なサードパーティー・サービスとCloud Searchの間を橋渡しするソフトウェア・アダプターを開発している。今後Googleは、より多くのサービスに対応することで、このクラウドベース技術の能力をかつての検索アプライアンスと同等にしたいと考えている。

新サービスは限定ユーザー向けに提供開始されている。将来はG Suiteユーザー向け、およびスタンドアロンバージョンとして提供される予定。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

GoogleのサーバーレスプラットホームCloud Functionsが一般供用を開始

Cloud Functionsは、Googleのサーバーレスプラットホームで、AWS LambdaやMicrosoftのAzure Functionsと、もろに競合する。今日サンフランシスコで行われたCloud Nextカンファレンスで、このプラットホームの一般供用が発表された。

GoogleがCloud Functionsを発表したのは2016年だから、長いベータだ。感じとしては、Googleはサーバーレスに、AmazonやMicrosoftほどのリソースを投じていなかったのではないか、と思われる。AWSやAzureはそれに対し、サーバーレスに大きく賭けている。また、サーバーレスの導入や利用、管理、デバッグ、セキュリティなどを助けるスタートアップも、このところ増えている。

Googleのプロダクトはベータを抜けるとSLA（サービスの品質の保証）が付くが、Cloud Functionsもそうだ。ただし一般供用といっても、当面はアメリカとヨーロッパのリージョンのみだ。

Googleは今日、これまでのようにGoogleが単純にホストするクラウドプラットホームのほかに、エンタープライズ向けにハイブリッドクラウドを提供するGoogle Cloud Servicesを発表した。そこでユーザーがCloud Functionsをセルフホストすることはできないが、Googleは、サーバーレスアプリケーションを動かしたい企業にはKubernetesを自己のデータセンターで動かすことを勧めている。…実はぼくも、‘サーバーレス’という言葉が好きじゃないけどね。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

Google CloudのAutoMLサービスはFigure Eightとパートナーして訓練データの充実を目指す

機械学習のモデルの訓練やテスト、微調整などを支援するプラットホームFigure Eightが今日（米国時間7/24）、Googleとの重要なコラボレーションを発表した。それによると、今後Google CloudのAutoMLサービスでは、Figure Eightが機械学習のデータの作成やアノテーションを行なうときのデファクトスタンダードのパートナーになる。

Figure EightのCEO Robin Bordoliによると、Googleは前から顧客だったが、AutoMLがベータになり、そのプロダクトポートフォリオを拡大している現状では、両社がもっと密接に協働すべき、との結論に達した。Bordoliの主張では、デベロッパーが機械学習のモデルを構築するときの今だに最大の難関が、データの訓練だ。Googleも、そのことをよく認識している。“彼らの認識では、データ訓練の欠如がAutoMLの採用を阻む基本的な障害だ”、と彼は述べる。

AutoMLの最初のプロダクトは機械視覚がメインだったから、Figure EightとGoogleのパートナーシップも、ビジュアルデータによるモデルの訓練が多かった。Figure Eightのサービスを利用することによって、比較的経験の浅いデベロッパーでも、データの収集やAutoML向けの準備、それによる実験などができていた。

Figure Eightが類似のプラットホームと違うのは、その工程に人間が関与することだ。Bordoliの主張では、訓練データのアノテーションを完全にAIツールにまかせることなんて、できない。それは、人間にだけまかせるわけにはいかないのと、同じだ（世界中の人びとを集めてタグ付けをやらせないかぎり）。

GoogleのGoogle Cloud AutoMLのプロダクトマネージャーFrancisco Uribeはこう語る: “うちの顧客の重要なニーズが、人間によるラベル付けだ。Figure Eightとのパートナーシップによって、そのニーズのサポートが強化される”。

このパートナーシップに基づいてFigure EightはAutoML専用のテンプレートと、データをアップロードするプロセスをたくさん作った。同社はまた、顧客がデータを作って訓練する際の お手伝いも提供する（それにより、公平なAI(AI fairness)の担保を目指す）。Google CloudのユーザーはFigure Eightのプラットホームを使って最大1000までの画像にラベルを付け、また同社のアノテーターを利用することもできる（アノテーションを自分でやらない場合）。

今日の発表に至るまでにFigure Eightはすでに、100億以上のデータラベルを生成しており、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 LauncherがGCP Marketplaceと改名、コンテナアプリケーションのデプロイもサポート

Cloud Launcherは長年、Googleが開設したクラウドアプリケーションのマーケットプレースで、サードパーティのベンダーはほんの数クリックで自分のアプリケーションをGoogleのクラウドへデプロイできる。でもその名前からは、そこに商用アプリケーションを置けることや、それらの課金をGoogleが処理してユーザーの通常のGCPの料金請求に加えてくれることなどが、分かりにくい。そこでGoogleは今回、名前をGCP Marketplaceに変えることにした。

それだけでなく、今日（米国時間7/18）のアップデートでは、商用とオープンソース両方の、コンテナアプリケーションも置けるようになる。ユーザーはそれらを、Google Kubernetes Engineへ容易にデプロイできる（ほかのKubernetesサービスを使ってもよい）。これまで、このマーケットプレースは従来的な仮想マシンだけを提供してきたが、でも今や、コンテナのサポートを求める顧客がとても多いのだ。

Googleがいみじくも主張するように、Kubernetes Engineはコンテナの管理から大量の面倒を取り去ってくれるが、でもそれらをKubernetesのクラスターへデプロイするのは手作業の場合が多かった。そこでこのマーケットプレースでは、コンテナアプリケーションのデプロイも数クリックでできるようにし、しかもGoogleのKubernetes EngineだけでなくほかのKubernetesへのデプロイもサポートする、とGoogleは約束している。

Google CloudのプロダクトマネージャーBrian Singerによると、彼のチームはKubernetes Engineのチームと密接に協力して、このような統合をできるかぎりシームレスにしてきた。そして今マーケットプレースにあるソリューションは、GitLabのようなデベロッパーツールや、グラフデータベースNeo4j、データ管理サポートKastenなども含んでいる。WordPress, Spark, Elasticsearch, Nginx, Cassandraといったオープンソースのプロジェクトも利用できる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）