Google Cloud Platform Japan 公式ブログ: 5月 2016

ビッグデータプラットフォーム比較 : 精彩放つ BigQuery と Dataproc

2016年5月31日火曜日

* この投稿は米国時間 5 月 17 日、Google Cloud Platform の Developer Advocate である Felipe Hoffa によって投稿されたもの（投稿はこちら）の抄訳です。Mark Litwintschikオープンデータネタバレ注意 : この計測で Google BigQuery と Google Cloud Dataproc が優れた結果を残しているのは喜ばしいことです。それを詳しく紹介する前に、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 秒前後

Google BigQuery

25 分で 10 億行をロード

クエリは 2 秒以下

クラスタのデプロイがなく、サイズに関する意思決定は不要

BigQuery へのデータのロードは高速（さらに高速に）で無料（課金はロード後のストレージのみ）。他プラットフォームの場合はデータロードの CPU 時間に課金

クエリは、それまでにテストしたどの環境より何倍も高速

最適化不要。BigQuery はデフォルトで効率が良く、高速

実際に試してみるときは、オープンデータとして 10 億行が BigQuery にロードされているため、25 分待つ必要はなく、月々の無料クォータでこれをはじめとするオープンデータセットを利用可能

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 倍遅い

AWS の EMR 責任者 Rahul Pathak 氏AWS のヘッドエバンジェリスト Jeff Barr 氏Elasticsearch のエンジニア Zachary Tongビッグデータのテックリーダーで 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 秒以下に

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

なんとクエリが 4 秒に

機械学習アプリを大幅に高速化する TPU カスタムチップを開発

2016年5月27日金曜日

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

TPU ボードRankBrainStreet View囲碁の世界チャンピオンである Lee Sedol 氏との対局

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

クラウドで農業支援 : GCP をめぐる最近の動きから

2016年5月26日木曜日

* この投稿は米国時間 5 月 13 日、Google Cloud Platform Blog の Editor である Alex Barrett によって投稿されたもの（投稿はこちら）の抄訳です。失われたマヤ文明の都市四角い土地の正体

Google Cloud PlatformGoogle Compute Engine（GCE）Google Cloud Storage WinField Data Silo5 Unique Features of Google Compute Engine That No IaaS Provider Could Match継続利用割引同社ブログGoogle I/O 2016

Cloud Vision API でイメージの「銀河」を探索しよう

2016年5月25日水曜日

* この投稿は米国時間 5 月 24 日、Google Cloud Platform の Staff Developer Advocate である佐藤一憲と、Reactive Inc. の Product Manager である堺礼氏によって投稿されたもの（投稿はこちら）の抄訳です。

GCP NEXT 2016Cloud Vision ExplorerCloud Vision APIお試しCloud Vision APIGoogle Cloud PlatformCloud Vision APIGoogle Cloud Storage料金ページ Cloud Vision API を使って「銀河」を探索

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 APIWikimedia Commons 65 万枚の分類されていない画像Cloud Vision API イメージギャラクシーを生み出したクラスタ分析技術クラスタ分析

次元削減（dimensionality reduction）GloVet-SNE（t-Distributed Stochastic Neighbor Embedding）

From Wikimedia Commons (CC-BY/CC-BY-SA)TensorFlow HTTP/2 による滑らかな動きGoogle Cloud Storage（GCS）WebGLReactGCS に実装された HTTP/2 プロトコルGitHub のリポジトリ

GCP NEXT 基調講演でのデモ

Land O'Lakes の挑戦 : 100 億人分の食料をまかなう農業を GCP で後押し

2016年5月24日火曜日

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

Cloud Technology Partners（CTP）Google App EngineGoogle Cloud SQLGoogle Compute Engine（GCE）Cloud PlatformGoogle Maps APIGoogle Cloud PlatformGoogle Cloud Pub/SubGoogle BigQueryGoogle Cloud BigtableGoogle Cloud Platform技術セッション- Posted by Jennifer Garcia, Product Marketing Manager, Google

.NET チュートリアル : GCP で ASP.NET アプリを実行する簡単な方法

2016年5月24日火曜日

* この投稿は米国時間 5 月 11 日、Development Programs Engineer である Jeffrey Rennie によって投稿されたもの（投稿はこちら）の抄訳です。
Google Cloud PlatformGoogle App EngineGoogle Compute EngineGoogle Cloud DatastoreCompute Engine.NET クライアントライブラリASP.NETHello World チュートリアル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

Google Cloud Platform の新しいセキュリティと個人情報保護の ISO 認証を取得

2016年5月19日木曜日

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

Google Cloud PlatformISO27017ISO27018新しい認証を追加ISO27001Google Cloud PlatformCloud DataflowCloud BigtableContainer EngineCloud DataprocContainer RegistryCompute EngineApp EngineCloud SQLCloud StorageCloud DatastoreBigQueryGenomicsGoogle Cloud Platformこちら

エアロセンス株式会社の導入事例：自社開発ドローンとクラウドサービスで測量と設備管理を圧倒的に高精度・効率化、Google Cloud Platform の先進テクノロジーでを活かして新たな市場を開拓。

2016年5月18日水曜日

少ない人員、限られた時間、予算など、制限された状況下でスピーディに結果を出すことが求められるスタートアップ。生まれたばかりの企業に求められるクラウドプラットフォームの条件とは？　そのヒントを、話題のドローン技術を駆使して新たな市場を開拓しつつあるエアロセンス株式会社に聞いてきました。

■ 写真左からエアロセンス株式会社クラウドサービス部シニアソフトウエアエンジニア松本大佑さん取締役 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 を使うことで、解析にかかる時間を劇的に短縮させることができます。今後、さらに魅力的な機能が増えていくことに期待しています」（松本さん）導入事例はこちら

App Engine 向けの Stackdriver Trace が GA リリース

2016年5月18日水曜日

* この投稿は米国時間 5 月 10 日、Product Manager である Sharat Shroff によって投稿されたもの（投稿はこちら）の抄訳です。営業コストも抑えられますGoogle Cloud PlatformGoogle StackdriverStackdriver TraceGoogle App Engine

レイテンシの影響を評価

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

Kubernetes によってコンテナのワークロードポータビリティが次のレベルに

2016年5月17日火曜日

* この投稿は米国時間 5 月 8 日、Content Writer である Alex Barrett によって投稿されたもの（投稿はこちら）の抄訳です。CgroupsKubernetesKubernetesKubernetes の IP を譲渡しましたKubernetesKubernetesGoogle Container EngineGoogle Cloud PlatformKubernetesKubernetesKubernetesKubernetesKubernetesKubernetesKubernetes を Microsoft Azure で実行する方法Kubernetes無料トライアルKubernetes- Posted by Alex Barrett, Content Writer

ビッグデータの話題で持ちきりだった一週間 : GCP をめぐる最近の動きから

2016年5月16日月曜日

* この投稿は米国時間 5 月 6 日、Content Writer である Alex Barrett によって投稿されたもの（投稿はこちら）の抄訳です。Google Cloud PlatformGoogle Cloud Dataflow と Apache SparkCloud Dataflowこちら同社の見解Mark Litwintschik

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 クラスタをどう構築するか）

Visualizing Big Money with Big Data- Posted by Alex Barrett, Content Writer

なぜ Apache Beam なのか : Dataflow のライバル参入を促す理由

2016年5月16日月曜日

* この投稿は米国時間 5 月 3 日、Staff Software Engineer & Apache Beam PPMC である Tyler Akidau によって投稿されたもの（投稿はこちら）の抄訳です。Google Cloud Dataflow SDKApache Beam なぜ Google にとって意味をなすことなのか？

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

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

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

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

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

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

Apache Beam 機能マトリクスBeam ModelWhat / Where / When / HowStreaming 102

2016 年 4 月時点で、Apache Beam ランナーがサポートする機能をさまざまな角度からまとめた Apache Beam 機能マトリクス次のように語っています「私たちは非常に早い時期から 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 統一の作業を進めています」将来はどうなるのか?Gearpump まとめGoogle Cloud Dataflow- Posted by Tyler Akidau, Staff Software Engineer & Apache Beam PPMC

BigQuery が Google Drive と統合

2016年5月13日金曜日

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

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

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

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

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

BigQuery公開プレイリストデータBigQueryBigQuery

BigQueryBigQuery

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

フェデレーションデータソースGCP NEXT 2016BigQuery発表

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

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

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

Table Partitions のアルファ版

BigQuery- Posted by Tino Tereshko, BigQuery Technical Program Manager

GCP と Synergyse、 Google Apps がもたらす相乗効果

2016年5月12日木曜日

* この投稿は米国時間 5 月 2 日、Google Cloud Platform の Content Writer である Alex Barrett によって投稿されたもの(投稿はこちら)の抄訳です。Google AppsSynergyse が Google ファミリーに加わりこちらGoogle AppsGoogle Chrome の拡張機能Google Cloud Platform

Google エンジニアが語る App Engine のインパクト

2016年5月12日木曜日

* この投稿は米国時間 4 月 26 日、Technical Support の Director である Luke Stone によって投稿されたもの（投稿はこちら）の抄訳です。プロダクトマネジャー : エンジニア : プロダクトマネジャー : Google App EngineGoogle App EngineGoogle App Engine- Posted by Luke Stone, Director of Technical Support

株式会社サイバーエージェントの導入事例：エンジニアの切磋琢磨を促す“ヒダッカソン”で Google Cloud Platform を利用

2016年5月11日水曜日

今回いつもとはやや趣の異なる活用事例を紹介。スマートフォン向けアプリゲームの開発でも知られるサイバーエージェントグループが社内のハッカソン的イベントで Google Cloud Platform を活用したというお話をお伺いしてきました。変化が激しい“現場”の 1 つとして知られるゲーム業界のエンジニアは Google Cloud Platform をどのように評価したのでしょうか？

■ 写真左から
株式会社グリフォン
エンジニア岩上裕樹さん株式会社サイバーエージェント
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 App Engine で動く Ruby ランタイムがベータに

2016年5月11日水曜日

* この投稿は米国時間 5 月 5 日、Google Cloud Platform の Product Manager である Justin Beckwith によって投稿されたもの（投稿はこちら）の抄訳です。Google App Engine で動作する Ruby ランタイムApp Engine
始めましょう導入ガイドサンプル対話的なチュートリアルPostgreSQLMySQLCloud DatastoreGoogle Container EngineGoogle Compute Engine Google の API やサービスが使えるgcloud Ruby gemGoogle Cloud DatastoreGoogle Cloud Pub/SubGoogle BigQueryrequire "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 Ruby などのオープンソースへの取り組み

https://github.com/GoogleCloudPlatform/ruby-docker

https://github.com/GoogleCloudPlatform/gcloud-ruby

https://github.com/google/google-api-ruby-client

Google Cloud Platform@googlecloud招待リクエスト#ruby チャネル- Posted by Justin Beckwith, Product Manager, Google Cloud Platform

Cloud Dataflow と Stackdriver Debugger によるデータ変換のデバッグ

2016年5月10日火曜日

* この投稿は米国時間 4 月 21 日、Software Engineer である Ben Chambers によって投稿されたもの（投稿はこちら）の抄訳です。Google Stackdriver DebuggerGoogle Cloud DebuggerスナップショットGoogle Cloud DataflowDebuggingWordCount

早速、--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 ジョブではごく普通のシナリオです。