* この投稿は米国時間 5 月 17 日、Google Cloud Platform の Developer Advocate である Felipe Hoffa によって投稿されたもの（投稿はこちら）の抄訳です。


私は、Mark Litwintschik 氏が執筆しているブログ ポスト シリーズの大ファンです。彼は、NYC TLC がオープン データとして公開している 10 億回のタクシー運行記録を使用して、周りにあるすべてのビッグデータ プラットフォームで計測を行っています。

ネタバレ注意 : この計測で Google BigQuery と Google Cloud Dataproc が優れた結果を残しているのは喜ばしいことです。それを詳しく紹介する前に、Mark が明らかにした結果をわかりやすく視覚化すると、次のようになります。


Mark が早い段階で明らかにしたことを振り返ってみましょう。

PostgreSQL

• (COUNT+GROUP BY) という単純なクエリに対する最初の結果 : 1 時間超
• カラムナ ストレージ エクステンションを使った同じクエリ : 2 分超
• COUNT+AVG クエリ : 3 分以下

Elasticsearch

• 最初の試行ではすべてのデータをロードできなかった（ “1,711 GB のインデックス データを格納し、ハイ ウォーターマークに引っかからないだけのスペースを確保できるほど大きい 1 台の 2 TB SSD ドライブは存在しない” ）
• データを読み込んでインデックスを作るのに、“70 時間よりもほんのちょっと短い時間” がかかる
• COUNT+GROUP BY クエリ : 18 秒以下
• COUNT+AVG クエリ : 8 秒以下
• 1 か月後、Mark は Elasticsearch にデータセットを全部ロードする方法を見つけたものの、結果はより遅くなった

AWS EMR 上の Spark

• Amazon EMR “クラスタ（上の Spark）は、プロビジョニングとすべてのノードのブートストラップまで 20～30 分かかることがある”（それに対して Dataproc クラスタの場合は 90 秒以内に準備完了）
• Parquet へのデータの移動に “約 2 時間かかる” 場合あり
• クエリは AWS 上の Presto よりも 4 倍から 40 倍遅い

AWS EMR 上の Presto（5 ノード）

• AWS EMR 上でクラスタを起動するのに 20 分以上が必要（なぜ 90 秒ではないのか）
• データのロードは “完了まで 3 時間 45 分かかった”
• COUNT(*)、AVG() クエリに最長 70 秒

ローカル マシンでの Hive と Presto の比較

• クエリは 2 分から 5 分。Presto は Hive よりも最高で 4 倍高速

無料使用枠内での AWS Redshift

• 計測されたスピードでのロード : “データセット全体では約 6～8 時間でロードされるはず”
• 無料使用枠を維持すると、データの 20 % しかロードされない。“200 M のレコードのロードには 1 時間 4 分 25 秒かかった”
• この投稿ではクエリのベンチマークには言及していないが、Redshift のスピードを保つために VACUUM、ANALYZE コマンドを実行し続けることの重要性について言及（これらはデータベースの速度を下げ、ユーザーはデータベースを使えなくなるにもかかわらず、これらのタスクのために使ったサーバー / 時間は課金対象）

大規模クラスタでの AWS Redshift

• あるエキスパートが Twitter で最良のアドバイスを提供くれたものの、Redshift にデータセット全体をロードするのに約 10 時間
• クエリは 1 秒前後

すべての結果は、ごく普通の感じに見えます。しかし、その後（2016 年 4 月 6 日）、Mark は BigQuery を試してみようと思いたちます。

Google BigQuery

• 25 分で 10 億行をロード
• クエリは 2 秒以下

えっ、その理由は？

• クラスタのデプロイがなく、サイズに関する意思決定は不要
• BigQuery へのデータのロードは高速（さらに高速に）で無料（課金はロード後のストレージのみ）。他プラットフォームの場合はデータ ロードの CPU 時間に課金
• クエリは、それまでにテストしたどの環境より何倍も高速
• 最適化不要。BigQuery はデフォルトで効率が良く、高速
• 実際に試してみるときは、オープン データとして 10 億行が BigQuery にロードされているため、25 分待つ必要はなく、月々の無料クォータでこれをはじめとするオープン データセットを利用可能

上述のとおり、他よりもずっと高速で単純なプラットフォームが見つかったので、Mark の探究はここで終わってもよかったのですが、彼にはもっと大きな目標がありました。彼はあらゆるプラットフォームのあらゆる可能な構成を試したいと思っていたのです。その後に起きたことをまとめてみましょう。

AWS EMR 上の Presto（50 ノード）

• AWS EMR の場合、クラスタを実行可能な状態にするために、またも 20 分前後の時間が必要（Google Cloud Platform なら同じタスクに 90 秒以下）
• データはすでに S3 の ORC ファイルとしてロード済みなので、再度のロードは不要
• 10 倍のノード（以前、EMR 上で Presto を実行したときと比べて）で、クエリのスピードアップは 1.3 倍～3 倍（40 秒以下）

Google Cloud Dataproc 上の Presto

• クラスタの立ち上げに要した時間に関する言及はないものの、以前の結果から考えると、90 秒プラス Presto のインストール時間（30 秒以内）
• CSV から ORC への変換は 3 時間以内
• 最初のクエリは AWS EMR の 4 倍遅い

間違いありません。Mark の最初の Dataproc でのテストは、同等の構成の AWS EMR よりもクエリが遅かったのです。

しかし、話はここで終わりません。私が Mark のブログ ポスト シリーズを気に入った理由の 1 つは、業界のビッグデータ プレーヤーたちが彼のツイートに引き付けられている点です。

今までに私がツイートで見かけた人物は、AWS の EMR 責任者 Rahul Pathak 氏、AWS のヘッド エバンジェリスト Jeff Barr 氏、Elasticsearch のエンジニア Zachary Tong 氏など、そうそうたる顔ぶれです。

私たちはエンジニアであり、それゆえベンチマークを見つけると、数字を上げようとしてそれに飛びつくのです。Google からも、ビッグデータのテック リーダーで OSS ソフトウェア エンジニアの Dennis Huo が参戦しました。レースはますます面白くなっているのです。

S3 と HDFS（AWS 上）の比較

• S3（または同等の GCS）でのデータ管理にはさまざまな利点があるものの、HDFS にデータのコピーをロードしておくと 1.5 倍までパフォーマンスが向上することを Mark が発見（一部のクエリは 40 秒以下に）

Google Cloud Dataproc 再調査 : 33 倍高速に

• 10 ノードで、立ち上げに 2 分以下（以前 90 秒以下という数字を示したが、今回は Presto のインストールも行っており、それを全部含めて 120 秒以下）
• 別の圧縮手段（Zlib、Snappy）、インデックスのストライド サイズ、インデックスのストリップ サイズを操作した結果、クエリは 44 秒以下に
• その後、GCS ではなく HDFS をテスト。一部のクエリは 10 秒以下に

このように、クエリが 10 秒以下まで短縮されたのです。他の構成やサービスでこれに匹敵するパフォーマンスは、今のところ見たことがありません。

50 ノードの Google Cloud Dataproc（勝者）

• なんとクエリが 4 秒に

Mark は何度も試行錯誤を繰り返した結果、BigQuery のちょうど半分のスピードでこれらのクエリを Presto 上で実行するのに最適な構成を見つけました。今のところ、Google Cloud 上の Presto だけではありますが。

先ほども触れたように、このレースで最も興味がそそられるのは、どれだけのプレーヤーとプラットフォームが、BigQuery に匹敵するスピードをたたき出す最良の構成を見つけ出し、名乗りを上げるかということです。


結果をまとめると、「Presto 構成レース」を制したのは、4 秒のクエリを記録した Google Cloud Dataproc です。将来は、さらに処理効率を高めた構成が現れることでしょう。

とはいえ、Mark のテスト結果を見れば、価格からも性能からもベスト チョイスが BigQuery だということは明らかであり、Presto を使いたいなら Google Cloud Platform が実行場所として最良です。

この種の競争は実にすばらしいものです。もっと速く、もっと費用対効果の高い結果を示すために皆が競争すると、誰もが勝者になります。もちろん、最も得をするのは皆さんなのですが。

* この投稿は米国時間 5 月 18 日、Google の Distinguished Hardware Engineer である Norm Jouppi によって投稿されたもの（投稿はこちら）の抄訳です。


機械学習は、広くご愛用いただいている多くの Google アプリケーションにチャーミングな魅力を与えます。実のところ、Google では現在、Street View から Inbox の Smart Reply、ボイス サーチに至るまで、100 以上のチームが機械学習を使用しています。

とはいえ、私たち Google には信じて疑わない 1 つの真理があります。それは、優れたソフトウェアは、それを動かすハードウェアが優れているときに最も明るく輝くということです。数年前、機械学習アプリケーション向けのカスタム アクセラレータを独自に具現化するべく、極秘プロジェクトを立ち上げたのもそのためです。

その結果生まれたのが、機械学習を念頭に TensorFlow 用として設計されたカスタム ASIC、Tensor Processing Unit（TPU）です。

Google 社内のデータセンターでは 1 年以上前から TPU を使ってきましたが、これを機械学習に使用するとワットあたりの最適化性能が 1 桁以上も改善されました。これは、ほぼ一気に 7 年（ムーアの法則の 3 世代分）先のテクノロジーを先取りしたようなものです。

TPU は機械学習アプリケーション用に設計されており、チップは計算精度の低さに対する耐性が高くなっています。つまり、演算ごとに必要とされるトランジスタの数が少なくて済むのです。

これにより、1 秒間に実行できる演算をより多くチップに詰め込み、高度で強力な機械学習モデルをより高速に適用できるようになりました。そのため、ユーザーは、よりインテリジェントな結果をより速く得ることができます。

下の写真は TPU を搭載したボードです。Google のデータセンター ラックのハードディスク ドライブ スロットに収まるように設計されています。

TPU は、Google が研究成果をいかに速く実用化するかを示す実例でもあります。最初に半導体をテストしたときから、Google のデータセンターでアプリケーションを TPU で実際に動かすまでに要したのは、わずか 22 日でした。

TPU はすでに、RankBrain での探索結果の関連性を高めることや、Street View におけるマップやナビゲーションの精度と品質の向上など、Google の多くのアプリケーションにパワーを供給しています。

囲碁の世界チャンピオンである Lee Sedol 氏との対局で、AlphaGo のエンジンになったのも TPU です。TPU により、AlphaGo はずっと速く思考し、ずっと先まで指し手を考えられるようになりました。

私たち Google の目標は、機械学習の産業を牽引し、そのイノベーションをお客様が活用できるようにすることです。Google のインフラストラクチャ スタックに TPU を組み込むことで、TensorFlow や Cloud Machine Learning のようなソフトウェアの開発者たちに対して、高度なアクセラレーション機能、すなわち Google のパワーを提供できるようになります。

機械学習は、お客様や一般消費者に利益をもたらすインテリジェントなアプリケーションの構築方法を変えつつあります。可能性が現実になっていく瞬間を、私たちは目撃しようとしているのです。

* この投稿は米国時間 5 月 13 日、Google Cloud Platform Blog の Editor である Alex Barrett によって投稿されたもの（投稿はこちら）の抄訳です。


失われたマヤ文明の都市か、たんなる荒地なのか・・・。

カナダの 15 歳の少年、William Gadoury 君によって発見された Google Maps 上の四角い土地の正体は、いまだ不明です。


遺跡発見の顛末はさておき、最近は地理空間データに信頼を置いている Google Cloud Platform のユーザーもいます。そのうちの 1 社である Land O’Lakes は、Google Compute Engine（GCE）と Google Cloud Storage の上で動作する新しい WinField Data Silo ツールを発表しました。

このツールは、ユーザーのシステムに格納された農業データと Google Maps API を連携させ、地理空間データとしてリアルタイムに表示します。机の上でも、あるいは収穫機の操縦席でも高度な地理空間データ機能を利用できることは、Google Cloud Platform にとってユニークな差別化要素の 1 つです。

ユニークといえば、クラウド アーキテクトの Janakiram MSV 氏が執筆した記事 “5 Unique Features of Google Compute Engine That No IaaS Provider Could Match”（IaaS プロバーダーが太刀打ちできない GCE のユニークな 5 つの機能）が、米 Forbes に掲載されました。

同氏はその 1 つ目に GCE の継続利用割引を挙げています。この記事のとおり、GCE では仮想マシンの実行料金に割引が適用され、1 か月で最大 30 % 割引されます。利用料金は自動的に割引されるので、ユーザーは割引のために事前に何かをする必要はありません。

こうした料金モデルの優位性については、市場情報プロバイダーの Geofeedia も Janakiram MSV 氏と同意見のようです。同社によると、（AWS の）リザーブド インスタンスという料金モデルは、クラウド コンピュータ リソースをプロビジョニングするうえでまったく受け入れられていません。


Geofeedia のプロダクション エンジニアリング ディレクターである Charlie Moad 氏は、「アジャイル ソフトウェアの世界では、1 つのソフトウェアを作成しても、それのみで 3 年間ハードウェアのニーズに応えるのは極めて難しい」と同社ブログで述べています。

また Moad 氏は、複数地域対応のアプリケーション構築のための GCP ネットワーキング、ファイアウォールのルール、プロジェクト中心型のアプローチについて言及しています。

ところで、先日開催された Google I/O 2016 はいかがだったでしょうか。遺跡発見に関する続報と併せて、次回もお楽しみに。

* この投稿は米国時間 5 月 24 日、Google Cloud Platform の Staff Developer Advocate である 佐藤一憲 と、Reactive Inc. の Product Manager である堺礼氏によって投稿されたもの（投稿はこちら）の抄訳です。
3 月にサンフランシスコで開催された Google Cloud Platform 最大のイベント GCP NEXT 2016 で、Google のシニア フェローである Jeff Dean が、Cloud Vision Explorer を使って Cloud Vision API を紹介しました。

今回、この素晴らしいデモが一般公開され、誰でも体験できるようになりました。ぜひお試しください。


Cloud Vision API について改めて紹介すると、これは Google Cloud Platform が提供する画像分析サービスです。使いやすい REST API を介して強力な機械学習モデルを利用でき、高い精度での画像分析が可能です。

Cloud Vision API は、画像内のオブジェクトを数千ものカテゴリに高速に分類したり、画像に含まれる顔の位置や感情を検出したり、画像に含まれる文字列の検出と読み取り (OCR) を行うことができます。画像を API にアップロードして分析する方法に加え、Google Cloud Storage 上に保存された画像を分析することもできます。

ラベル検出機能は 1,000 画像あたり 2 ドル、その他の機能は 1,000 画像あたり 0.60 ドルから利用可能です（料金ページを参照）。また、誰でも 1 か月 1,000 画像まで無料で API を使用できます。

Cloud Vision API を使って「銀河」を探索

Google Chrome（最新版）で上述のデモにアクセスし、LAUNCH ボタンをクリックすると、“イメージ ギャラクシー” が表示されます。


イメージ ギャラクシーには 20 から 25 のグループが含まれており、名前（たとえば、sea、snow、vehicle）はそれぞれ画像の内容の分析結果を反映したものになっています。グループの中でズームアップすると、数千の画像のサムネイルが現れます。

何千もの画像の内容を把握する Vision API

Cloud Vision Explorer に表示される 80,984 枚の画像は、最大級のフリー メディア リポジトリである Wikimedia Commons からダウンロードされたものです。Commons には現在 65 万枚の分類されていない画像がありますが、個々の画像の説明がないために、それらの画像の価値を生かすことが難しい状況です。

そこで Cloud Vision API の出番です。Vision API は、このように膨大で無秩序な画像が集められたサービスでその能力をいかんなく発揮します。

イメージ ギャラクシーを生み出したクラスタ分析技術

このデモを作るうえで課題となったことの 1 つは、イメージギャラクシーの生成です。クラスタ分析と呼ばれる手法により、Vision API の出力にもとづいて類似する画像を複数のグループに分類して 3D 空間にマッピングしています。

このイメージギャラクシーの中では、たとえば猫の画像は、車や運動場の画像よりも、犬のような類似する画像の近くに配置したいところです。


そこで Cloud Vision Explorer では、ラベルとスコアに基づいてすべての画像のベクトル表現を定義し、さらに次元削減（dimensionality reduction）を適用してベクトル表現を 3D 空間に収める手法を用いています。

このベクトル表現は、単語をベクトルに変換する GloVe 辞書を使用して、“cat” や “dog” などのラベルを高次元のベクトル（通常は 200 次元以上）に変換したものです。スコアに基づいて、ラベルに対応するベクトルを線形結合すると、個々の画像のベクトル表現が得られます。

これで、個々の画像に対応するベクトルを取得できます。この高次元データセットを可視化するため、t-SNE（t-Distributed Stochastic Neighbor Embedding）と呼ばれる次元削減のアルゴリズムを用いました。t-SNE によって個々の画像のベクトルを 3 次元ベクトル（x, y, z）に変換します。


つづいて3D 空間におけるクラスタ（人、椅子、車などのカテゴリ）を抽出するために、ユークリッド距離による K-means 法を適用し、個々のクラスタに色を付けました。クラスタの名前は、集まった画像の中で最も多いラベルを使うことにしました。

このクラスタ分析のモデルは Python で実装されており、Google が開発したオープンソースの機械学習ライブラリである TensorFlow によって実装されています。

HTTP/2 による滑らかな動き

Cloud Vision Explorer のもう 1 つの重要なポイントは、UI の滑らかな動きです。10 万もの画像を含む画面でこの動きを可能にするため、開発チームは Google Cloud Storage（GCS）をバックエンドとし、WebGL と React を組み合わせて使用することにしました。

必要なロジックはすべて JavaScript クライアントにまとめ、バックエンド サービスとしては GCS だけを使いました。Explorer でズームインしたときに表示されるサムネイルの作成には、GCS に実装された HTTP/2 プロトコルを使っています。

GCS をバックエンドとしているため、Web サービスのバックエンドをゼロから設計、運用する手間をかけずに、Google の各種サービスに匹敵するスケーラビリティと可用性を実現しています。

なお、ソースコードは GitHub のリポジトリで公開されています。


Jeff Dean による GCP NEXT 基調講演でのデモでは、Cloud Vision API とクラスタ分析の組み合わせにより、数千もの画像を構造化して可視化できることが示されました。

この手法は、個人向けや業務用途の画像ライブラリのインタラクティブな検索ツールなど、さまざまなユースケースに応用できます。ぜひ、ご活用ください。

* この投稿は米国時間 5 月 12 日、Google の Product Marketing Manager である Jennifer Garcia によって投稿されたもの（投稿はこちら）の抄訳です。


2050 年には世界人口が 100 億人を超え、その食料をまかなえるだけの生産量が農業にも必要となります。そのためには、農業従事者 1 人あたり 250 人分の食料を生産しなければなりません。これは、現在の 1 人あたりの生産量よりも 61 % 多い量です。

こうした爆発的に増加する食料需要に応えるため、農業協同組合の Land O'Lakes はクラウドによって現代農業に革新を起こそうとしています。その取り組みは、子会社で農業ソリューションの大手プロバイダーである WinField のブランドで実を結びつつあります。

Land O'Lakes が先ごろ発表した、Google Cloud Platform（GCP）を利用して構築された WinField Data Silo は、農業者がデータに基づいて的確な判断を下せるように支援するクラウド ベースのアプリケーションです。


農業者は作物の生育過程で十数回、重要な判断を下します。いつ種をまくか、どこにどれだけの水と肥料をやるかといった具合です。

従来、こうした判断は主に勘に頼って行われていました。しかし、多くのソースから同時にデータを収集して取り込み、分析できるクラウド ベースのビッグデータ ツールがあれば、農業者は精密な情報を活かして収穫の最大化を図れます。

Land O'Lakes は農業向けの高機能な意思決定ツールを目指し、農業者がデータを活用できるクラウド ネイティブなシステムとして Data Silo を構築しました。


Data Silo は、データの収集、取り込み、蓄積を行い、農業者や小売業者、サードパーティ プロバイダーに提供します。以前はばらばらに存在していたシステムを接続し、ユーザーが作物と農作業に関する情報を迅速に共有できるようにします。

Data Silo を使えば、農業者は簡単にデータをそのプラットフォームにアップロードし、ダッシュボードを作成して情報を検索できます。こうして、特定の耕地でどの作物を栽培すべきかといった農学上のベスト プラクティスのガイダンスが得られる一方、それらのデータの所有者やアクセス権限を管理できます。



Land O'Lakes は、Google Cloud Platform Technology Partner である Cloud Technology Partners（CTP）の協力を得て、Data Silo をゼロから開発しました。CTP は最初のフェーズにかかわり、Google App Engine と Google Cloud SQL を利用して、プロジェクト開始から数週間でワーキング プロトタイプを構築しました。

Land O'Lakes は最終的に、Data Silo を Google Compute Engine（GCE）に移行し、GCE 上でそのウェブ ベース PHP アプリケーションの運用や、モバイルおよびウェブ ベース インターフェースの提供、既存の監視およびセキュリティ システムとの連携を行うようにしました。さらに、複雑な GIS 関数を実行するため、PostgreSQL データベースと PostGIS ライブラリを実装しています。


Cloud Platform の重要な差別化要素の 1 つは、高度な地理空間データ機能にあります。Land O’Lakes は Data Silo を Google Maps API と連携させることで、有意義なラベルのレイヤが重ねられた地理空間データをモバイル デバイスやデスクトップで閲覧できるようにしています。

Data Silo ユーザーは、作物の種類や生育期間、収穫などのデータを、ユーザー定義ビューでソートして見ることができます。マップは、ユーザーがシステムにアップロードする新しいデータでリアルタイムに更新されます。


Google Cloud Platform の各種機能は、Land O’Lakes と Data Silo にユニークな可能性を提供しています。Data Silo は現在、農業者が農作業に関するデータを保存し、共有する場として主に機能していますが、将来は、さまざまな農業アプリケーションのデータ ハブに進化する可能性があります。

たとえば、Data Silo とともに Google Cloud Pub/Sub を使用してデータを統合したり、Google BigQuery と Google Cloud Bigtable を使用して作物の収穫増につながる分析を行ったりということが可能になるかもしれません。

Land O'Lakes は 50 年以上にわたって成長を続け、30 万以上の農業者のニーズに対応してきました。農業者の生産量拡大に加えて、省資源と環境への影響低減を支援するため、Land O'Lakes は新しい技術に多額の投資を行っています。

柔軟かつ安全で簡単にスケーリングできるクラウドを利用できることは、Land O'Lakes にとって、Data Silo のリリースと将来のイノベーションを成功させるうえで不可欠なのです。

Land O'Lakes がどのように Google Cloud Platform を導入したのかを詳しく知りたい方は、GCP NEXT での同社の技術セッションをご覧ください。


- Posted by Jennifer Garcia, Product Marketing Manager, Google

* この投稿は米国時間 5 月 11 日、Development Programs Engineer である Jeffrey Rennie によって投稿されたもの（投稿はこちら）の抄訳です。

Google Cloud Platform（GCP）がサポートするプラットフォームやプログラミング言語はさほど多くない、と考えるのは早計です。私たち Google は、Google App Engine で動作する Python や Java のエンジンを作り、その後も PHP、Go と続けてきました。そして今度は、Google Compute Engine で .NET Framework をサポートします。

Google は先ごろ、Google Cloud Datastore や、Compute Engine で動作する Windows 仮想マシンのようなサービスのために、.NET クライアント ライブラリを公開しました。これで、Cloud Platform 上で ASP.NET アプリケーションを直接実行することも可能になります。

この環境にすぐに慣れていただくために、ASP.NET アプリケーションの構築と Cloud Platform へのデプロイの方法を紹介した、2 つの新しいチュートリアルも併せて公開しました。

このうち Hello World チュートリアルは、ASP.NET アプリケーションを Compute Engine にデプロイする方法について説明しています。

* この投稿は米国時間 4 月 28 日、Google Cloud Platform の Product Manager である Matthew O’Connor によって投稿されたもの（投稿はこちら）の抄訳です。
先日、エンタープライズのお客様の個人情報保護への取り組みの決意を示すものとして、Google は Google Cloud Platform で クラウドセキュリティ向け ISO27017 と、個人情報保護の ISO27018 の 2 つの新しい認証を追加しました。また、私たちは ISO27001 を 4 年連続で更新しております。


これにより、 ISO の認証を取得している Google Cloud Platform サービスに Cloud Dataflow、Cloud Bigtable、Container Engine、Cloud Dataproc、 Container Registry が追加されることになりました。これに、Compute Engine、App Engine、 Cloud SQL、Cloud Storage、Cloud Datastore、BigQuery、Genomics を加えたサービスが、今後、定期的に認証監査を受けることになります。


この様な認証により、私たちの実施している世界レベルのセキュリティや個人情報保護への取り組みに対して、独立した第三者機関による監査が行われることになり、これはお客様自身のコンプライアンスへの取り組みにも資することになります。Google は、何年にもわたり先進のインフラストラクチャの構築を進め、世界中のエンタープライズのお客様に提供を行ってまいりましたが、私たちはクラウドでのデータ保護に関する透明性を、今より更に高めたいと考えています。

Google Cloud Platform のコンプライアンスに関する詳細はこちらをご覧ください。

■ Google Cloud Platform のその他の導入事例はこちらから

* この投稿は米国時間 5 月 10 日、Product Manager である Sharat Shroff によって投稿されたもの（投稿はこちら）の抄訳です。


私たち Google は常にサービスとウェブのスピードにこだわっています。高速なサイトはユーザーを満足させ、エンゲージメントを向上させるからです。また、高速なサイトでは営業コストも抑えられます。

私たちと同様に、Google Cloud Platform のお客様もスピードに高い価値を置いています。そこで私たちは、Google のエンジニアがサイトの最適化に使用しているツールの一部を社外に提供することを決めました。その 1 つが、Google Stackdriver ファミリのメンバーである Stackdriver Trace です。

Stackdriver Trace は先ごろ、1 日あたり 1,000 億件以上のリクエストを受け付ける Google App Engine（GAE）向けに GA（正式リリース）となりました。このツールは、GAE で動作する各アプリケーションを自動的に分析し、パフォーマンスのボトルネックや問題の兆候を発見します。

レイテンシの影響を評価

Stackdriver Trace は、アプリケーションのランタイム パフォーマンスとレイテンシに関する詳細なインサイトをほぼリアルタイムに提供します。

具体的には、トレースの対象となる各リクエストのデータを継続的に評価し、パフォーマンス ボトルネックの兆候となるパターンをチェックします。パフォーマンス分析に伴うオペレーション オーバーヘッドをなくすために、アプリケーションのパフォーマンスを常に自動的に分析します。

また、アプリケーションのレイテンシをバージョンやリリース間で比較評価するレポートの生成も可能です。レイテンシの変化を検出する機能により、このサービスは各レポートを評価し、時間経過の中でレイテンシの大きな変化があったかどうかを調べます。

* この投稿は米国時間 5 月 8 日、Content Writer である Alex Barrett によって投稿されたもの（投稿はこちら）の抄訳です。


アプリケーション コンテナと Docker や Rocket のパッケージ フォーマットが、開発者の間で人気を集めています。これらを使用すると、「パッケージを 1 回作成すれば、どこでも動く」ため、作業が容易になるからです。

ただ、いかに使いやすい技術でも、多用されるあまり管理しきれなくなり、成功があだになってしまうこともあります。このことを Google は嫌というほど知っています。

社内システムの運用を通じて、私たち Google はだいぶ前に、コンピュート リソースを最も効率的に共有する方法はコンテナを使うことだと理解しました。そしてコンテナを大規模に運用するには、自動化とオーケストレーションを利用する以外に方法はありません。

そこで私たちは、Cgroups と Borg を開発しました。前者については、コンテナ エコシステムの確立に役立つように Linux Foundation に寄贈しました。また、後者は Google のクラスタ管理システムの愛称です。

時計の針を進めましょう。最近のコンテナの台頭を受け、開発者は一般に Borg が提供するサービスの発見、構成、オーケストレーションといった機能の恩恵を受けるというのが、私たち Google の考えです。これらの機能は、マルチノードのコンテナ ベース アプリケーションの構築と実行を容易にすることを目的としています。

そうして生まれたのが Kubernetes です。Kubernetes は Borg から派生したオープンソース ソフトウェアです。誰でもコンテナ環境の管理に利用できます。


Google は今年、Cloud Native Computing Foundation（CNCF）に Kubernetes の IP を譲渡しました。CNCF のバックアップのもとで、IBM、Docker、CoreOS、Mesosphere、Red Hat、VMware といった加盟企業が Google と手を組み、Kubernetes が Google 環境だけでなく、企業が選んだどのパブリック クラウドやどのプライベート クラウドでも機能するように取り組んでいます。

では、このことはコンテナを基幹技術として利用する企業にとって、どのような意味を持つのでしょうか。

Kubernetes は、企業が 1 社のクラウド プロバイダーにロックインされるのを回避できるように支援することで、コンテナが提供するワークロード ポータビリティを次のレベルに向上させます。

たとえば、現在は Google Container Engine を使用していても、IBM のミドルウェアを利用したくなる時が来る可能性もあります。

また、AWS を長年使っている企業が、Google Cloud Platform の先進的なビッグデータや機械学習のサービスを利用したい場合もあるかもしれません。.NET アプリケーションを実行する機能を目当てに Microsoft Azure を使っている企業が、OpenStack が稼働する既存の社内リソースを利用したいこともあるでしょう。

このような場合に、Kubernetes はコンピュート リソース上でアプリケーション中心の API を提供することで、マルチクラウド シナリオの実現を支援します。

将来は複数のクラウドを組み合わせて使用するようになるとしたら、コンテナ オーケストレーション戦略の基盤として Kubernetes を選択することが理にかなっています。現在では、ほとんどの主要なパブリック クラウド プロバイダーが、コンテナ オーケストレーションやスケジューリングをサービスとして提供しています。

私たちのサービスである Google Container Engine（GKE）は Kubernetes をベースにしています。その Kubernetes を CNCF に引き渡すことで、私たちは、クラウド プロバイダーが提供するものか、お客様が自社で実行するものかを問わず、あらゆる Kubernetes 実装上でお客様のアプリケーションが動くようにすることを目指しています。

現時点でも、Kubernetes は選択した任意のクラウド環境で実行できます。信じられないなら、CoreOS の Tectonic（AWS で動作します）や、Kubernetes を Microsoft Azure で実行する方法をチェックしてみてください。

マルチクラウド アプリケーションを実行するために Kubernetes をセットアップし、実行する方法についてのチュートリアルを準備していますので、ぜひご覧ください。あるいは無料トライアルで Kubernetes をすぐに使ってみてください。


- Posted by Alex Barrett, Content Writer

* この投稿は米国時間 5 月 6 日、Content Writer である Alex Barrett によって投稿されたもの（投稿はこちら）の抄訳です。


一週間のニュースをまとめようとしても、明確なテーマが思いつかず、無関係なトピックが脈絡なく並んでいるだけということが時々あります。ところが、5 月の第 1 週は違いました。このブログも Google Cloud Platform 界隈も、ビッグデータと分析の話題で持ちきりでした。

この週は華々しく幕を開けました。ビッグデータ コンサルティング会社の Mammoth Data が、Google Cloud Dataflow と Apache Spark を比較したベンチマーク テストの結果を発表したからです。Google のデータ処理サービスである Cloud Dataflow は、テストで使用されたコア数に応じて Spark を 2～5 倍上回る好スコアを記録しました。


Cloud Dataflow は有料サービスですが、そのプラットフォームの API は先ごろ、Apache Beam というIncubator プロジェクトとして Apache Software Foundation に受け入れられました。

Google の Apache Beam 担当スタッフ ソフトウェア エンジニアである Tyler Akidau の投稿によると、このプロジェクトの目的は、ストリーミングとバッチでのデータ並列処理をさまざまなプラットフォーム間でポータブルに実現する、使いやすく強力なモデルを提供することにあります。

Tyler の投稿の全文はこちらでご覧になれます。data Artisans の Kostas Tzoumas 氏も、Apache Beam に関する同社の見解に加えて、Apache Beam と Apache Flink の関係を解説しています。

ビッグデータの権威である Mark Litwintschik 氏のブログで連載されている “A billion taxi rides”（10 億回のタクシー乗車）シリーズでも Google を取り上げています。このシリーズでは、ニューヨーク市での総計約 11 億回に上るタクシーおよび Uber 乗車に関するデータを、各種のデータ アナリティクス ツールを駆使して分析しています。

同氏は、このシリーズの 4 月末から 5 月初めにかけての投稿（下記）で、Cloud Dataproc の実践的な活用ノウハウも紹介してくれました。

• 33x Faster Queries on Google Cloud Dataproc（Cloud Dataproc でどうやってクエリを 33 倍も高速化したか）

• Performance Impact of File Sizes on Presto Query Times（Presto クエリ時にファイル サイズがパフォーマンスに与える影響）

• 50-node Presto Cluster on Google Cloud Dataproc（Cloud Dataproc で 50 ノードの Presto クラスタをどう構築するか）

ビッグデータや分析についてもっと知りたい方は、Google と Bitnami の共同ウェビナー “Visualizing Big Money with Big Data”（ビッグデータで巨額資金の流れを可視化）にぜひご登録ください。

このウェビナーでは、政治資金の調査を行っている非営利団体 Center for Responsive Politics の選挙データを使用します。Google BigQuery とオープンソースのデータ可視化ツール Re:Dash を利用すると、米国の選挙における資金調達問題の大きさが、残念ながら一目瞭然です。


- Posted by Alex Barrett, Content Writer

* この投稿は米国時間 5 月 3 日、Staff Software Engineer & Apache Beam PPMC である Tyler Akidau によって投稿されたもの（投稿はこちら）の抄訳です。


data Artisans や Cloudera、Talend、その他数社のパートナーと共同で、Google Cloud Dataflow SDK とランナーを Apache Beam Incubator プロジェクトに移行すると決めたとき、私たち Google の頭の中には、ある目標が浮かんでいました。

それは、ストリーミングとバッチの両モードに対応する、使いやすくて強力なデータ並列処理モデルを、さまざまなプラットフォームを通じポータブルな形で世界に提供することです。

最初のコードをめぐるドタバタも収まった今、それまではデータ処理に関する OSS の世界に直接かかわってこなかった Google にとって、この目標が意味を持つのはなぜでしょうか。Google はどのようにして、ここにたどり着いたのでしょうか。こうした点について簡単にお話ししておきたいと思います。

なぜ Google にとって意味をなすことなのか？

Google は営利企業ですので、Apache Beam への移行がビジネス上の動機に基づいていても不思議ではないでしょう。ひとえに、できるだけ多くの Apache Beam パイプラインを Cloud Dataflow の上で実行できるようにしたいということです。

とはいえ、ライバルとなる他のランナーにもプラットフォームをオープンにするという戦略はわかりにくいかもしれません。しかし、本当はまったく逆なのです。これには、さまざまなメリットがあります。

• Apache Beam をサポートするランナーが増えれば増えるほど、Apache Beam のプラットフォームとしての魅力は高まります。

• Apache Beam を採用するユーザーが増えれば増えるほど、Google Cloud Platform（GCP）の上で Apache Beam を実行したいと思うユーザーは増えます。

• Apache Beam の開発に携わる人間が増えれば増えるほど、データ処理の最先端を先鋭化させることができます。

これらのメリットは、Google だけでなく、Apache Beam にかかわるすべてのプレイヤーが享受できることに注目してください。

データ処理パイプライン構築のためのポータブルな抽象レイヤがあれば、今までよりもはるかに簡単に新しいランナーが参入でき、パフォーマンスや信頼性、運用管理などの面でより優れたものを提供し、技術イノベーションを競えるようになります。

言い換えれば、API ロックインを取り除くと実行エンジンの自由市場が生まれます。すると、競争が激しくなり、最終的には業界全体の底上げにつながります。

どのようにして進めるのか？

これまで Google は、OSS コミュニティとの間でイノベーションを共有することに関して冷淡な態度をとってきました。その方針を転換し、データ処理用のオープンソース コードを通じてイノベーションを共有する方向に舵を切ったのは、Apache Beam を共同で立ち上げたときからです。なぜ今なのでしょうか。

これには理由があります。

• 従来、Google は主として社内だけでビジネスを進めてきましたが、クラウドの顧客らとの交流を通じて OSS の価値を知るようになったのです。Hadoop コミュニティの成功が良い例です。こうしたことから Apache Beam のような動きが可能になりました。

• これは Beam 固有の事情ですが、Beam への移行が意味を持つのは、Beam Model（従来の Dataflow モデル）を高度にサポートし、オンプレミスや Google 以外のクラウド シナリオできわめて魅力的なオプションを提供する OSS のランナーがすでに存在する場合に限られます。

これがなぜ重要なのかは、先ごろ公開された Apache Beam 機能マトリクスを見れば明らかでしょう。このマトリクスは、個々のランナーが現在どこまで Beam Model をサポートできているかを広い視野でとらえています。言い換えれば、異なるランナーで実行したときに、Apache Beam パイプラインにどの程度のポータビリティを期待できるかが大まかに描かれているのです。

このマトリクスでは、関連する機能をグループとしてまとめるため、What / Where / When / How の疑問文と機能との対応を 4 つの表に分けて示してあります（これらの疑問文を目にしたことがなく、なぜ重要なのかがわからない方は、Streaming 102 を参照してください）。



2016 年 4 月時点で、Apache Beam ランナーがサポートする機能をさまざまな角度からまとめた Apache Beam 機能マトリクス


パイプラインのポータビリティという目標を Apache Beam が達成するためには、オンプレミスや Google 以外のクラウドで実行され、Cloud Dataflow の強力なライバルになるようなランナーが少なくとも 1 つは必要です。

マトリクスを見ればわかるように、現在この要件を満たすランナーは Apache Flink です。Flink があってこそ、Beam は本当の意味で、この産業において欠かすことのできない魅力的なプラットフォームになりうるのです。

Flink が現在の姿まで発展してきたのは、パワーとシンプルさを兼ね備えた Beam Model のおかげです。Flink を支えてきた data Artisans の CEOである Kostas Tzoumas 氏は、次のように語っています。

「私たちは非常に早い時期から Beam にかかわっています。（中略）Dataflow モデルがストリームおよびバッチのデータ処理の正しいモデルだということは、私たちの中ですぐに明らかになりました。

1 つのプラットフォームのもとで、リアルタイム アナリティクスとヒストリカル アナリティクスを統一するという Google のビジョンを、私たちは全面的に支持しました。（中略）私たちは、この基礎的な仕事からヒントを得て、Dataflow のホワイトペーパーに書かれていた概念の多くを組み込むために Flink の DataStream API を書き換えました。

Dataflow SDK とランナーが Apache Beam として Apache Incubator に移行することが決まったとき、私たちは Beam のコードベースに Flink ランナーを加えてほしいという要請を Google から受けました。（中略）Beam Model こそ、ストリームおよびバッチの両モードでデータ アプリケーションを作るときのリファレンス プログラミング モデルに相応しいと信じていたので、このチャンスに全力を注ぐことにしたのです。

1 つ疑問があるとすれば、Flink のネイティブ API（DataStream）と Beam API の関係はどうなっているのかということです。（中略）2 つの API の間の違いは主として構文（そして趣味の問題）であり、私たちは Beam と Flink の両 API をソース互換にすることを最終的な目標として、Google との間で API 統一の作業を進めています」

将来はどうなるのか?

現在は Flink が最先端かもしれませんが、他のランナーが Flink に追いつけないというわけではありません。業界には面白い選択肢が多数存在します。もちろん、私たち Google もできる限り多くのランナーを Beam でサポートするつもりですし（実行エンジンの自由市場はこのようにして機能していくのです）、それらすべてのランナーがモデルの多くの部分をサポートすることを望んでいます（ポータビリティはこのようにして実現されるのです）。

Storm 1.0 は先ごろ、基本的なイベントタイム サポートを追加しました。また、Spark 2.0 は Structured Streaming のセマンティクスに Beam Model のサブセットを組み込もうとしています（Spark はウォーターマークと非整列ウィンドウを持たず、マイクロバッチ ハートビートに合わせてトリガをハードコードしているようです）。

これらはどちらも限られたユースケースでは優れた選択肢になります。開発者にとっては、それぞれのランナー実装において足りない機能を補い、より包括的なセマンティクス スイートを提供する方向も選べます。最近登場した Gearpump なども、Beam ランナーとしてとても期待できる存在です。

幸いなことに、データ処理実行エンジンの自由市場では、パフォーマンスやレイテンシ、スケーラビリティ、運用保守のしやすさなどの面で（そして基本的にまだ解決されていない分野で）、まだまだイノベーションや差別化を生む余地が十分に残されています。

近い将来、API をロックインして市場の独占を目指す競争ではなく、ユーザーの満足を獲得するための競争がランナーの間で起きるでしょう。これは、業界全体のためには歓迎すべきことです。

まとめ

ストリーミングとバッチの両面でデータ処理の未来を担うのは Apache Beam であると、私たち Google は固く信じています。API ロックインによるシェア拡大を競うのではなく、ユーザーを喜ばせるために競う洗練されたランナーによる健全なエコシステムが、Apache Beam の周りに育ってくれることを期待しています。

前出の機能マトリクスからも明らかなように、現時点で最も優れたランナーは、GCP では Google Cloud Dataflow、オンプレミスと Google 以外のクラウドでは Apache Flink です。しかし、他のランナーもこれらに追いつこうとしていますし、業界全体として Beam Model のセマンティクスをサポートする方向にシフトしつつあります。Beam ユーザーにとっては良いことずくめでしょう。

ストリーミングとバッチの未来は Apache Beam にあります。あなたが考えなければならないのは、どのランナーを選ぶかです。


- Posted by Tyler Akidau, Staff Software Engineer & Apache Beam PPMC

* この投稿は米国時間 5 月 6 日、BigQuery の Technical Program Manager である Tino Tereshko によって投稿されたもの（投稿はこちら）の抄訳です。


Google BigQuery は、サーバーレスでフルマネージドのアナリティクス データ ウェアハウスです。ユーザーにダウンタイムなどの負担をかけることなく、頻繁に新機能とアップグレードを提供しています。


BigQuery をさらに使いやすくするため、BigQuery チームはユーザーの生産性や相互運用性を高める機能の提供に力を注いでいます。チームが先ごろ発表した Google Drive との統合はその一環であり、これによって次のことが可能になります。

• BigQuery UI から Google Sheets へのクエリ結果の直接保存

• Google Drive からファイルへの直接クエリ（BigQuery へのロード不要）

• BigQuery から編集中の Google Sheets スプレッドシートへのクエリ

人気モバイル ゲームの Fruit Ninja を開発している Halfbrick Studios では、こうした新機能を一足早く体験しました。同社のデータ アナリストである Sam Gillespie 氏は、その感想を次のように語っています。

「Google Sheets の柔軟性と BigQuery の地力が結びつき、結果やインサイトをよりスピーディにシェアできるようになった。BigQuery に Google Sheets を直接リンクすることで、使い慣れたインターフェースでデータに新情報を加えることが可能だ。今まで以上に迅速にデータから学べるし、アナリストがどこにいても彼らのデータを取得できる」

Google Sheets を BigQuery テーブルとして利用

Google Sheets スプレッドシートを参照するテーブルを BigQuery に作ることができます。たとえば私は、Google Sheets を使ってお気に入りのミュージシャンを管理しています。



私の音楽的センスは別として、これらのアーティストが出している人気の曲のリストを、BigQuery の公開プレイリスト データを使って作りたいと思います。私の好みは頻繁に変わるので、プレイリストも頻繁に変えられるようにしたいところです。

まず、BigQuery の新テーブル作成 UI を使用して、Google Sheets のアーティスト リスト スプレッドシートを直接読み出す BigQuery テーブルを定義します。


これでテーブルを定義できました。このテーブルを使ってクエリを発行すれば、プレイリストから人気曲を取り出すことができます。

ただし、今は単に楽しみたいだけなので、“Never Gonna Give You Up”（絶対に諦めない）という Rick Astley との約束を破り、Cyndi Lauper を聞くことにしましょう。その場合は Google Sheets スプレッドシートを更新するだけです。


そして、BigQuery で SQL クエリを再実行してみましょう。“artists” テーブルはスプレッドシートの内容を直接読み出してくるので、Cyndi Lauper の曲を知りたいということが BigQuery にシームレスに伝わるはずです。


Google Sheets スプレッドシートの内容を “Time After Time”（何度も何度も）変えても、スプレッドシートを使ったクエリを次に実行したときには、BigQuery が自動的に新しい内容を読み出してくれます。

クエリ結果の Google Sheets への保存

BigQuery UI に表示された “Save to Google Sheets” ボタンをクリックすると、クエリの結果が Google Sheets に保存され、スプレッドシートを開くためのプロンプトが表示されます。


これらの機能の詳細については、フェデレーション データ ソースのドキュメントを参照してください。

ちなみに、3 月に開催された GCP NEXT 2016 で、私たち Google は BigQuery と Google Drive の統合のほか、次のようなアップデートについても発表しました。

• Long Term Storage（長期保存）の料金を 50 % 値下げ

• 多くのクエリのスピードを 10 倍以上に高速化する Capacitor ストレージ エンジン

• データのロード スピードを 5 倍に高速化する Poseidon データ インジェスト/イグレス エンジン

• Table Partitions のアルファ版

いつもと同じように、BigQuery はこれらの機能をシームレスにお届けします。ダウンタイムはなく、行動を起こしたり構成をいじったりする必要もありません。フルマネージドの真価はここにあるのです。


- Posted by Tino Tereshko, BigQuery Technical Program Manager

* この投稿は米国時間 5 月 2 日、Google Cloud Platform の Content Writer である Alex Barrett によって投稿されたもの(投稿はこちら)の抄訳です。


2013 年以降、述べ400 万人超の方々が、Gmail や Calendar、 Drive、 Docs を使う際に Google Apps スイートのバーチャルトレーニングコーチ Synergyse を利用してきました。

先日 Synergyse が Google ファミリーに加わり、全 Google Apps ユーザーが、無料でこの拡張機能をインストールすることができる様になります。（現在、統合作業中ですが、こちらからインストールできます。

お金のことはさておき、 Google をアプリケーションデザインパートナーとして選べば何ができるかを Synergyse アーキテクチャが教えてくれます。

用意に利用でき統合された Google Apps スイートを利用している、何百万の個人のお客様やビジネスユーザーは、Synergyse をトレーニングモジュールをシンプルな Google Chrome の拡張機能として使うことができるのです。

更に、 Synergyse のバックエンドは Google Cloud Platform によって支えられており、新しいユーザーがオンラインになると、インタラクティブでコンテキストに合わせたトレーニングをオンデマンドで提供します。

また、 Synergyse はクラウドでホストされているため、チームはトレーニングモジュールを追加したり更新したりすることも簡単にでき、しかも GCP の上に構築されているので、検索や音声認識など、 Google の先進機能を組み込むのも簡単です。

これは、オープンであることやコラボレーション、インテグレーションをプロダクト開発の基本方針にした際に何ができるか示す証拠、とでもいうようなものです。

* この投稿は米国時間 4 月 26 日、Technical Support の Director である Luke Stone によって投稿されたもの（投稿はこちら）の抄訳です。


2011 年 12 月、Google 在籍 9 年目だった私は、ソフトウェア開発者 10 人のチームを率いて AdSense 事業をサポートしていました。私たちは 30 以上のソフトウェア システムを担当し、その大部分は、それまでの 10 年間に構築されたビジネス インテリジェンスのウェブ アプリケーションでした。

これらはいずれもその都度、良かれと思われたスタック上に構築されていました。その一部は、Google の（当時）最新のウェブ サーバー ライブラリをベースとし、Borg（Google の柔軟なクラスタ管理技術）上で直接動作する最先端のカスタム サーバーでした。

また、マネージド ホスティング サービス上の LAMP スタックもありました。なかには、誰かのワークステーションで cron ジョブとして実行されていたものもあります。

さらに、一部は奇妙で複雑なものになっていました。Borg 上で LAMP スタックが動作し、Apache が本番ロード バランサおよび暗号化システムと連携するようにカスタマイズされているといった具合です。

かくして、毎日のように新しい妙なトラブルが発生していました。どうにかシステムを動かし続けるのがやっとというのが、当時の私たちの状況でした。

チームにはストレスがたまっていました。プロダクト マネジャーもエンジニアも不満を抱えていたのです。こんな会話が日常茶飯事でした。


プロダクト マネジャー : 機能 A を追加するのは簡単という話だったけど、もう 4 日たっているよ。

エンジニア : わかってます。でも、まずパッケージ マネージャをアップグレードしたうえで、古くなった API から移行しなければならなかったんです。その作業はほぼ終わっています。私も機能 A に取りかかりたいんです。

プロダクト マネジャー : そうか。まだこれからか。


私はチームを調査し、私たちの効率が悪い根本原因を探りました。すると、業務時間の 60 % をメンテナンスに費やしていることが判明しました。この割合はどのくらいが適当なのか意見を募ったところ、しぶしぶながらも 25 % ならば許容範囲という結論に落ち着きました。

そこで私たちは、メンテナンスにかける時間の割合をそこまで減らすという目標を立てました。これが実現すれば、10 人の開発者のうち 3.5 人分の時間をメンテナンス以外の仕事に回せる計算でした。

Google App Engine が 2011 年 9 月に正式なサービスとしてリリースされて間もないころ、これを熱心に薦めてくれた友人がいました（彼は個人サイトで使っていました）。メンテナンスの負担が少なく、スケーリングが自動的に実行され、Google Cloud Datastore やユーザー管理といった機能がビルトインされていると、べた褒めでした。

同じく友人の Alex Martelli も、いくつかの個人プロジェクトで Google App Engine を使っていました。私自身も 2010 年からユーザーでした。チャリティ ウェブ サイトで使っていたのです。

こうしたことから、私たちはチームのウェブ運用のために Google App Engine を全面的に採用することを決断しました。チームにとって PaaS への第一歩でした。

そのころ、私たちは Dremel（BigQuery の社内版）も使い始めました。Dremel は MapReduce と比べて格段に高速で、スケーラビリティもほぼ互角でした。私たちはすべてのデータ処理のコードを、Dremel を使用するように書き換えることを決めました。

ただし当時は、Dremel と App Engine を組み合わせて使う場合、足りない機能がいくつかありました。可視化やデータ パイプラインといったものです。

そこで私たちは早急にソリューションを開発しましたが、それらは Google の数百のプロジェクトでいまだに使われています。今では Google Cloud Platform のユーザーも、Google Cloud Datalab でそれらに似た機能にアクセスできるようになっています。


続いて私たちは、ソフトウェア開発者の仕事のあり方が一変するのを目の当たりにしました。確かに、30 のシステムを書き換えなければなりませんでしたが、それらはどのみち書き換える必要がありました。

書き換えを経て始まったクラウドでの開発は、極めて迅速に進みました。App Engine のログを見て驚いたことを思い出します。私は 1 回のコーディング セッションで、コード作成、テスト、デプロイのサイクルを 100 回もこなしていたのです。システムはいったん動き出すと、ずっと稼働し続けました。

私たちは次のプロジェクトにどのスタックを採用するかを議論しなくなりました。Google Cloud Platform で自明な選択肢を選んで、構築を始めるようになったからです。私たちがクラウド インフラストラクチャでバグを見つけると、専門家がすぐに修正してくれました。ライブラリの互換性のトラブルシューティングに何時間も費やしていたのとは大違いです。


App Engine を導入して何よりも良かったのは、メンテナンスにかかる時間の割合をたちまち 25 % に削減でき、さらに減らし続けることができたことです。導入 2 年後に再調査したところ、チームがメンテナンスに費やす時間の割合はわずか 5 % となったことがわかりました。

おかげで、別の前向きな課題に取り組めるようになりました。私たちは、ビジネス部門がアイデアを生み出すペースに対応してなお余力があり、バックログ（未処理案件）もなくなったからです。

そこで四半期末ごとに 2 週間をかけて “ハッカソン” を開催し、自分たちにできることの模索を始めました。開発者の半数をクラウド以外の忙しいチームに送り込んだほか、大きなプロジェクトに挑戦し、もっと大規模な開発チームを上回るペースで成果が出るようになりました。


PaaS の導入が私たちのチームにもたらした変化に鑑み、私はあらゆる人に PaaS を経験してほしいと考えています。ありがたいことに、この技術は Google のエンジニアだけでなく、世界中の開発者が利用できます。

これは、私が 1999 年に Google 検索に初めて触れて以来見てきた中で、最もインパクトが大きい技術です。この技術を活用すれば、開発者は無味乾燥な作業をやめて、私たちの生活に価値をもたらすアプリケーションの開発に力を注ぐことができるのです。


- Posted by Luke Stone, Director of Technical Support

■ Google Cloud Platform のその他の導入事例はこちらから

* この投稿は米国時間 5 月 5 日、Google Cloud Platform の Product Manager である Justin Beckwith によって投稿されたもの（投稿はこちら）の抄訳です。


このたび、Google App Engine で動作する Ruby ランタイムがベータへと歩を進めたことを、私たち Google はうれしく思います。

Ruby on Rails や Sinatra といったフレームワークは、クラウド用のウェブ アプリケーションや API の迅速な開発を容易にすることで知られています。一方、App Engine は Google のインフラストラクチャ上でサービスを構築、デプロイ、管理、自動スケーリングするための使いやすいプラットフォームをデベロッパーに提供します。

始めましょう

Ruby ランタイムのスムーズな導入に向け、私たちは導入ガイド、サンプル、対話的なチュートリアルを用意しました。これらを利用すれば、コードを書き、Google の API やサービスを利用し、本番環境にデプロイするまでの道筋が見えてくるはずです。

Ruby ランタイムでは慣れ親しんできたツールやデータベースが使用できます。アプリの開発には Rails や Sinatra などのウェブ フレームワークが使えますし、PostgreSQL や MySQL、もしくは Cloud Datastore を使えばデータを格納できます。

このランタイムはほとんどのアプリとサービスを管理できるだけの柔軟性を備えていますが、インフラをさらにきめ細かく管理したい場合は、Google Container Engine や Google Compute Engine に簡単にマイグレートできます。

Google の API やサービスが使える

gcloud Ruby gem を使えば、スケーラブルな NoSQL データベースである Google Cloud Datastore、Google Cloud Pub/Sub、Google BigQuery といった Google の高度な API やサービスを利用できます。

require "gcloud"

gcloud = Gcloud.new
bigquery = gcloud.bigquery

sql = "SELECT TOP(word, 50) as word, COUNT(*) as count " +
      "FROM publicdata:samples.shakespeare"
job = bigquery.query_job sql

job.wait_until_done!
if !job.failed?
  job.query_results.each do |row|
    puts row["word"]
  end
end

BigQuery などのサービスは、Google のユニークなクラウド テクノロジーを取り込んで魅力的なアプリケーションを作ることを可能にします。

Ruby などのオープンソースへの取り組み

私たち Google はオープンソースに本腰を入れています。新しい Ruby Docker ランタイム、gcloud gem、Google API クライアントなどはすべてオープンソースです。

• https://github.com/GoogleCloudPlatform/ruby-docker
• https://github.com/GoogleCloudPlatform/gcloud-ruby
• https://github.com/google/google-api-ruby-client

私たちは Ruby のデベロッパーを Google Cloud Platform に迎え入れることを楽しみにしています。また、できるだけ快適な環境で皆さんが仕事を進められるよう、これからも投資を続けていきます。

Cloud Platform の Ruby サポートはまだ始まったばかりです。このブログや GitHub リポジトリを欠かさずチェックし、次に来る波に備えてください。

ぜひ、皆さんの考えをお聞かせください。Twitter の @googlecloud、Google Cloud Slack への招待リクエストと #ruby チャネルへの参加を通じて、どしどしご要望をお寄せください。


- Posted by Justin Beckwith, Product Manager, Google Cloud Platform

* この投稿は米国時間 4 月 21 日、Software Engineer である Ben Chambers によって投稿されたもの（投稿はこちら）の抄訳です。


分散データ処理のデバッグは容易ではありません。でも、Google Stackdriver Debugger（元は Google Cloud Debugger）を使用すれば、そうしたデバッグが楽になります。コードの特定位置で実行状態のスナップショットを取得でき、特定の行に達するまでのコールスタック、各位置でスコープの範囲内にある変数とその値がわかるようになるからです。

今回は、新しいバージョン 1.5.1 の Dataflow SDK を使った Google Cloud Dataflow ジョブで Stackdriver Debugger がいかに簡単に使えるかを説明しましょう。

データ変換パイプラインの例としては DebuggingWordCount を使います。このサンプルは、指定したフィルタ（デフォルトは “Flourish” と “stomach” ）に合致する単語の数だけを数えます。合致しない単語のロギングなど、さまざまなデバッグ機能も含まれていますが、周到なロギング機能があらかじめ用意されていない現実のパイプラインで起きた問題のデバッグをシミュレートしたいので、このログは使いません。