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



すべての結果は、ごく普通の感じに見えます。しかし、その後（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 が実行場所として最良です。

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


ラベル:


TPU ボード

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

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

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

Lee Sedol 氏との対局で使われた AlphaGo の TPU を収めているサーバー ラック

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

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


ラベル:




遺跡発見の顛末はさておき、最近は地理空間データに信頼を置いている 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 はいかがだったでしょうか。遺跡発見に関する続報と併せて、次回もお楽しみに。


Share on Twitter Share on Facebook


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）はそれぞれ画像の内容の分析結果を反映したものになっています。グループの中でズームアップすると、数千の画像のサムネイルが現れます。

From Wikimedia Commons (CC-BY/CC-BY-SA)

いずれかのサムネイルをクリックすると、Google の機械学習モデルが検出した情報が右側に表示されます。下の猫の画像の場合、システムはそれぞれ 99 %、99 %、93 %の確率で “Cat”、“Pet”、“British shorthair” を認識しています。

From Wikimedia Commons (CC-BY/CC-BY-SA)


何千もの画像の内容を把握する 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）に変換します。

From Wikimedia Commons (CC-BY/CC-BY-SA)


つづいて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 とクラスタ分析の組み合わせにより、数千もの画像を構造化して可視化できることが示されました。

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


Share on Twitter Share on Facebook




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
Share on Twitter Share on Facebook


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 にデプロイする方法について説明しています。


一方、Bookshelf チュートリアルでは、信頼性が高く、スケーラブルで管理が簡単な ASP.NET MVC アプリケーションを、Cloud Platform サービスを用いて作成する方法についてまとめています。

このチュートリアルではまず、.NET で構造化データを格納する方法を解説しています。SQL がお好きなら、Entity Framework を使って Cloud SQL に構造化データを格納しましょう。接続文字列と ALTER TABLE 文にうんざりでなければ、構造化データを Cloud Database に格納してください。

これ以外にも、バイナリ データの格納方法や、バックグラウンド ワーカー タスクの実行方法について解説しています。


ぜひ、チュートリアルの内容を試していただき、ご意見、ご感想をお寄せください。

もっとも、今回の .NET サポートはほんの出発点に過ぎません。Google は現在、.NET プログラマーの方にも Google API に慣れ親しんでいただくため、オープンソース ライブラリの構築を進めています。Google Cloud Platform と ASP.NET アプリケーションをめぐる今後の動きにご注目ください。


- Posted by Jeffrey Rennie, Development Programs Engineer
Share on Twitter Share on Facebook


先日、エンタープライズのお客様の個人情報保護への取り組みの決意を示すものとして、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 のコンプライアンスに関する詳細はこちらをご覧ください。
Share on Twitter Share on Facebook
ラベル:




■ 写真左から
エアロセンス株式会社

クラウドサービス部 シニアソフトウエアエンジニア
松本大佑さん



取締役 CTO
佐部浩太郎さん



クラウドサービス部部長
小早川知昭さん




■ 利用中の Google Cloud Platform サービス
Google App Engine、Google Compute Engine、Google Container Engine、Google Cloud Datastore など




エアロセンス株式会社は、自律型無人航空機（UAV）いわゆる「ドローン」とクラウドサービスを組み合わせたソリューションを提案するスタートアップ企業。自動運転カーや各種ロボティクス事業で知られる株式会社ZMPとソニーモバイルコミュニケーションズ株式会社が共同出資する形で 2015 年 8 月に設立されました。



「現在、我が社の中心的業務となっているのが、ドローンを使った測量事業。土木建設現場などの上空にドローンを飛ばして自動撮影した写真をクラウド上で計算し、従来だと一ヶ月かかっていたような測量を、数日で行っています。3D モデルの精度も数 cm 程度で、土量計測に関しては文字通り精度の桁が上がっています。


（復元した点群データ）

(90haの工事現場全域を土量計測した結果。整地計画との高低差を色で表している)

写真は、南三陸の嵩上げ工事現場。90 ヘクタールもの広さですが、三日間ですべて撮影し切りました。その後クラウド上で作成した点群データと土量モデルの一部です。
ドローンからクラウドアプリまで全体システムを自ら設計しているので、ドローンの飛行に限らず様々な処理を自動化・最適化することができ、このように効率的かつ精度の高いオペレーションを実現することができます。
（エアロセンス株式会社取締役 CTO 佐部浩太郎さん）



ほか、大規模工事の進捗管理や設備管理など、既に多くの実績を上げているエアロセンス。そのプラットフォームに Google Cloud Platform を選んだ理由について、実際の開発・運用を担当するエンジニア、松本大佑さんは以下のように語ってくださいました。

「何よりもまず、Google App Engine を使いたかったからです。我々は少人数のベンチャー企業なので、サーバーの運用に人員を割くことができません。GAE であればミドルウェアのアップデートを自身で行ったり、あるいはインフラの一時停止に伴うお客様へのご案内などに時間を割く必要がありません。GAE のおかげで、開発だけに集中することができています」



そうして Google Cloud Platform を使い始めたエアロセンスですが、使い続けていく中で、その先進性が同社業務に大いに役立つということに気がつき始めたそうです。

「Google って最先端のテクノロジーをどんどん使えるようにしてくれますよね。エンジニアとしてはそれがとても魅力的。特に我々のような B2B のベンチャーはそういった技術の差が大きな武器になります。先日も、Google Container Engine のローリング アップデートを初めて試して感動しました。何と言うか……かっこいい（笑）。失敗してもきれいに片付けてくれるので、気軽にデプロイしてみようという気分になります。例えば、コンテナの数を動的に増やして並列処理をするシステムを構築したのですが、実際運用するとなるとコンテナの管理に困るという現実があります。GKE を使えばこの問題も解決できます」（松本さん）




「Google Cloud Platform は単なるオンプレミスの置き換えではないんですよね。今までできていたことを安くできるとか、便利にできるとかいうのではなく、“今までできなかったこと”をできるようにしてくれるのが素晴らしいです。例えば、Google Cloud Vision API や TensorFlow。これをサービスに組み込むことで、空撮写真のどこに何があるのかを自動検出することができるようになります。エアロセンスでは、広大な設備の管理をドローンを使って行うというサービスもすでにお客様に提供しています。広い敷地内で発生する異変を人間の目で漏らさずチェックすることには多大な労力が必要ですが、Googleのテクノロジーの力を借りることで、非常な効率化が可能です。」（同社クラウドサービス部部長・小早川知昭さん）



そんな同社のエンジニアチームが現在取り組んでいるのが、撮影・処理された空撮データをクラウド上で解析し Web アプリケーションとしてお客様に提供する仕組み。

「まず今はお客様が必要とするデータをドローンからの画像を元に作成し提供していますが、今後はお客様がエアロセンスのサービスを前提にワークフローを構築していく、ドローンがお客様の業務ワークフローの一部となるようにしていかなければなりません。その第一歩が、エアロセンスのクラウドサービスです」（小早川さん）


「バックエンドのデータ解析だけではなく、Web アプリケーションでも、Google Cloud Platform を使っています。ソフトウェア開発者の気持ちをよく理解して作られた開発環境とヘルプのおかげで非常に開発効率が高かったです。Google App Engineでは Go 言語を使って開発したのですが、ローカル開発環境が充実しているのはもちろん、デプロイが高速で驚きました。おかげさまで、およそ 2～3 か月でほぼ商用レベルまで持っていくことができました。他のプラットフォームではこうは行かなかったと思います」（松本さん）



（開発中のWeb アプリケーション。ドローンから得た様々なデータを地図上で参照することができる）

ほか、さらなるビジネス拡大に向け、空撮地図や３次元モデルをクラウド上で自動生成する処理の高速化や、GIS 機能の強化を急ピッチで進めているという同社。Google Container Engine や Google Cloud Bigtable を積極的に利用する計画だそうです。この 4 月には開発中の垂直離着陸飛行機型のドローンを活用した医薬品配送事業への進出も発表しました。



「Google Cloud Platform を上手に使いこなして、我々にしかできないサービスを作りあげていきたいですね。個人的には、GPU インスタンスが使えるようにならないかと期待しています。もし実現していただけると、GPGPU を使うことで、解析にかかる時間を劇的に短縮させることができます。今後、さらに魅力的な機能が増えていくことに期待しています」（松本さん）




■ Google Cloud Platform のその他の導入事例はこちらから
Share on Twitter Share on Facebook
ラベル: , , , , ,




レイテンシの影響を評価

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

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

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


Stackdriver Trace API は、トレースにカスタム スパンを追加するのに利用できます。スパンとは、RPC リクエストやコード セクションなど、トレース内のワーク ユニットを指します。

カスタム ワークロードについては、Stackdriver Trace SDK を使ってスパンの開始と終了を独自に定義できます。このデータは Stackdriver Trace にアップロードされ、それらに基づいて前述の Trace Insights と Analytics 機能がすべて利用できます。


Stackdriver Trace はすでに他の Stackdriver ツールと統合されています。その中には Monitoring、Logging、Error Reporting、Debugger などが含まれます。

Stackdriver Trace は現在、分散環境でシームレスに機能し、App Engine で動作するすべての言語のランタイムをサポートしています。今後は他の GCP プラットフォームにも対応していきますので、ご期待ください。



始めましょう


「私たちのモバイル ゲームを支えるバックエンドに不可欠なのが、高速なレスポンスです。
Stackdriver Trace は、リクエストの処理にかかる時間の詳細な測定結果（高スコアの取得やスコアボードの更新といった作業ごとの内訳）を提供してくれます。Cloud Trace を使用すれば、RPC が適切にバッチ処理され、並列に実行されているかどうかが簡単にわかります。
App Engine ではセットアップや構成の必要がなく、すぐに使い始めることができる点も、大変気に入っています」

「私たちのプロダクトである Streak の主なユースケースは、ユーザーの求めに応じていつでも顧客情報にアクセスできるようにすることです。したがって、バックエンド サービスのレイテンシは重要なビジネス指標です。

Stackdriver Trace は、低速な API エンドポイントを特定し、最適化するのに役立っています。新しいコードのリリース後にトレース分析が行えるため、私たちの API にアクセスする速度の改善を定量化できています」



私たちは、アプリケーション パフォーマンスに関する Google の技術および運用ノウハウを開発者や企業が活用できるように継続的に支援しており、Google Cloud Platform の新たなステップとなる Stackdriver Trace が、この取り組みに貢献することを期待しています。

Stackdriver Trace をぜひ使いこなしてください。そしてフィードバックやご意見をお寄せください。


- Posted by Sharat Shroff, Product Manager
Share on Twitter Share on Facebook
ラベル:

ラベル:

ラベル:



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
Share on Twitter Share on Facebook




私の音楽的センスは別として、これらのアーティストが出している人気の曲のリストを、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 の統合のほか、次のようなアップデートについても発表しました。




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


- Posted by Tino Tereshko, BigQuery Technical Program Manager
Share on Twitter Share on Facebook
ラベル:

Share on Twitter Share on Facebook


■ 写真左から

株式会社グリフォン
エンジニア 岩上裕樹さん





株式会社サイバーエージェント
SGE(Smartphone Games & Entertainment) 事業統括室　CTO 白井英さん






■ 利用したGoogle Cloud Platform サービス
Google Compute Engine




株式会社サイバーエージェントは、インターネット広告事業、メディア（Ameba）事業、ゲーム事業を三本柱とする企業。国内ナンバーワンという広告事業やAmebaが有名ですが、ゲーム事業も複数のヒットタイトルを提供しています。

そんな同社が昨年から取り組み始めた社内ハッカソンイベントが「ヒダッカソン」（同社副社長・日高裕介さんのお名前から命名）。ゲーム事業に関わる子会社 9 社が所属するSGE（Smartphone Games & Entertainment）という組織のエンジニアを集めて行う、やや特殊なハッカソンで、サーバサイドとネイティブの 2 部門において、その技量を競うというものです。その経緯と狙いについて、同社ゲーム部門を統括する白井英さんは以下のように語ります。


「弊社独自の取り組みとして新規事業や事業課題解決案などサイバーエージェントのあした（未来）につながる案を考える『あした会議』という 1 泊 2 日の合宿があるのですが、昨年 SGE 事業部の新卒版で、ゲーム部門を支えるエンジニアをもっと評価するべきではないか、目立たせるべきではないかという声が上がったんです。そこで社内のエンジニアを集結させ、用意した“お題”に時間内でどこまで対応できるかという開発競争を実施しました。第 2 回目となる今年はさらに参加人数が増え、サーバサイド部門 78 名、ネイティブ部門 70 名、のべ約 150 名で開発力を競ってもらいました」

そのサーバサイド部門の“戦場”となったのが Google Cloud Platform（Google Compute Engine）。昨年は他社のクラウドサービスを利用したのですが、今回はイベントに変化を付けていきたいということもあって Google を採用。「大陸クエスト」という架空のゲームに必要となる 37 個の API を仕様書に基づきどんどん作っていくという競争を行ないました。

「サーバ関連のトラブルは皆無。競技的な面でも非常に重要なところなので、ここはさすが Google さんと感心しています。ちなみにプランは n1-highcpu-4 を使いました。できあがった API の判定プログラムなどでそれなりの負荷をかけているにも関わらず全くレスポンスが落ちなかった点もよかったですね」（白井さん）

結果、サーバサイド部門で優勝したのは新卒一年目の若手エンジニア。実は昨年の優勝者も新卒者だったとのこと。「ベテラン エンジニアは現場ではもうレビュー側に回ったりしているので、瞬発力的なものではもう若手に敵わないところがあるのかもしれませんね。かくいう私も去年は 10 位だったのですが、今年はかすりもしませんでした（笑）」（白井さん）

ここ 2 回のヒダッカソンを通じて、社内エンジニアを目立たせるという目的はある程度果たせたと語る白井さん。また、それ以外にもエンジニア間の交流が促されるなど、多くのプラスの成果があったそうです。

「これからも年に 1 度くらいのペースで続けていきたいですね。次回は参加エンジニア同士でお題を出し合うなど、競技の仕組み自体をちょっと変えてみようかなどと画策しています。その際は、ぜひまた Google Cloud Platform を使わせていただければ」（白井さん）




＜ヒダッカソン参加者インタビュー＞
最後に、昨年のヒダッカソン・サーバ部門優勝者で、今回、両部門に参加した株式会社グリフォン所属の若手エンジニア岩上裕樹さんに、大会の感想をお伺いしました。


「ヒダッカソンの良いところは、純粋に開発だけに集中できるところです。今は、リーダーもやっているので、普段の業務ではプログラミングのみに集中することはあまりないので、非常に楽しかったですね。サーバ部門では、プラットフォームが Google に変わると聞いて身構えていたのですが、実際に使ってみると、良い意味で何も変わりませんでした。むしろインスタンスの立ち上げが簡単など、感心する点も多かったです。機会があれば業務でも使ってみたいと思いました」（岩上さん）






■ Google Cloud Platform のその他の導入事例はこちらから
Share on Twitter Share on Facebook
ラベル: ,


始めましょう



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 クライアントなどはすべてオープンソースです。




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

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

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


- Posted by Justin Beckwith, Product Manager, Google Cloud Platform
Share on Twitter Share on Facebook



早速、--filterPattern=Flourish,stomach を指定してパイプラインを実行したところ、出力が生成されないことに気づきました。そこで Dataflow UI を見てみたところ、フィルタに合致した単語は存在しない旨、アグリゲータは報告していました。

そして、WordCount.CountWords ステップでは出力があったのに、ParDo(FilterText) ステップでは出力がなくなっていたことがわかりました。また、パイプラインの中のアサーションは失敗していました。

ParDo(FilterText) には入力があったのに、出力がなくなっていたことから（カスタム カウンタで各ステップの入力数を見ればわかります）、私はフィルタリングを実行する条件文が分岐する箇所（unmatchedWords がインクリメントされるところ）でスナップショットを取得することにしました。


ステップ 1 ：デバッガのもとでパイプラインを実行

やるべきことは、--enableCloudDebugger オプションを指定し、Cloud Dataflow サービス上でパイプラインを実行することだけでした。実行すると、次のようなメッセージが表示されます。

To debug your job, visit Google Cloud Debugger at: https://console.cloud.google.com/debug?project=<...>&dbgee=<...>

表示されたリンクをクリックするか、https://console.developers.google.com/debug で私のプロジェクトを選択すれば、Debugger UI にたどり着けます。なお、複数のパイプラインを実行している場合は、メニューからパイプラインを選択しなければならないことがあります。デフォルトでは最新のパイプラインが選択されます。


ステップ 2 : ソースコードにアクセスする

Debugger UI でコードを参照できるようにするためには、Debugger UI がソースコードにアクセスできなければなりません。アクセスできれば、ファイル名と行番号を入力しなくても、行をクリックするだけでスナップショットを取得できます。

Source Code Options には、ローカル ファイルシステムのディレクトリや Cloud Source Repository など、さまざまなオプションがあります。

話を単純にするために（そして、ソースコードをどこにもアップロードしていないので）、私は “View source code from local files” を選び、パイプライン ソースコードを格納しているディレクトリを指定しました。


ステップ 3 : スナップショットを取得する

スナップショットは、右側のテキスト ボックスに位置を入力して Enter キーを押すか、ソースコードの行番号をクリックすれば取得できます。すでに UI でソースコードを表示できるようにしてあるので、私は DebuggingWordCount.java ファイルに移動し、148 行目のスナップショットを要求しました。


フィルタを通過しなければおかしいと思われる単語のときにどうなるかを知りたかったので、それを次の式を使って条件にしました。

"Flourish".equals(((com.google.cloud.dataflow.sdk.values.KV) c.element()).getKey())

条件がプライベート フィールドにアクセスできていることに注目してください。しかし、ジェネリクス（たとえば KV を返す element() ）を使うときは、明示的なキャストが必要になります。


注意 : 通常、すべての条件評価は CPU 時間の 0.01 未満に制限されています。この条件はすべての要素で評価され、要素に対する実際の処理が比較的単純な場合は（破棄）、スナップショットはデバッガによってキャンセルされてしまいます。


したがって、この条件をデバッガに評価させるためには、--maxConditionCost=0.6 を指定しなければなりませんでした。このパラメータは Dataflow ジョブをサブミットするときに指定します。


ステップ 4 : スナップショットがキャプチャされるのを待つ

スナップショットを設定すると、Stackdriver Debugger サービスは実行中のすべての Dataflow ワーカーと通信します。いずれかのワーカーがスナップショットをオンにした行を実行しようとすると、スナップショットがキャプチャされます。


ステップ 5 : スナップショットを使用し、間違いの箇所を突き止める

どの値が処理されているのかを知りたければ、ProcessContext （ c と呼ばれているもの）を展開し、context を掘り下げます。探しているのは要素ですが、それは context において WindowedValue として格納されています。あちこちをつついてみて、this$0 を展開したところ、使われているフィルタがわかりました。


私が指定した filterPattern (Flourish,stomach)  が正規表現として使われていたことが原因だと判明しました。そこで、フィルタパターンを Flourish|stomach に変更して再実行すると、すべてが正しく動作しているように見えます。


たったこれだけ !

今回は、Stackdriver Debugger を使って Dataflow パイプラインのスナップショットを要求する方法を説明しました。少数のワーカーのもとで実行される比較的単純な例を使用しましたが、仮に数 GB のデータに対して500 個のワーカーを実行していた場合でも同様の手順で問題ないはずです。これは、クラウド規模の ETL ジョブで はごく普通のシナリオです。


- Posted by Ben Chambers, Software Engineer
Share on Twitter Share on Facebook
ラベル: