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

Sports Authority の導入事例 : Google Cloud Platform で毎秒 2,000 トランザクションを処理し、商品在庫情報を顧客に提供

2016年2月29日月曜日

* この投稿は米国時間 2 月 19 日、Google Cloud Platform の Product Marketing Manager である Jon Byrum によって投稿されたもの（投稿はこちら）の抄訳です。Sports AuthorityGoogle Cloud Platformsportsauthority.com 正しいクラウドプロバイダーの選定Google Apps for WorkGoogle Cloud PlatformGoogle App EngineGoogle Cloud Datastore

数百万種に上る商品の変更レコードを、Informatica を使用して毎晩 IBM メインフレームから Google Cloud Storage にプッシュするバッチプロセス

App Engine 上で実行される Python コードによって Cloud Datastore にデータをロードするタスクキュージョブの起動プロセス

同社のオンライン販売サイトに検索機能を提供する一連の SOAP、REST API

SOAPUILOADUIApp EngineCloud Datastore

ウェブサイトで商品検索の際に表示される画面。地理的に近い店舗がリスト化され、指定した商品の在庫が店舗ごとに確認できる店内キオスクで他店舗の在庫を検索Google Chromebox

顧客が他店舗の在庫状況を確認できる店内キオスク

店舗用社内ポータルも運用

Sports Authority は、本社と各店舗が密にコミュニケーションをとるための店舗用社内ポータルとタスク管理システムも新たに構築し、すでに運用しています。

このシステムにより、店舗チームのメンバーは、以前よりも効率よく業務を立案して遂行し、顧客のニーズにしっかりと対応できるようになりました。店舗用ポータルは App Engine、Cloud Datastore、Google Custom Search を使用しており、地域の Google パートナーである Tempus Nova の力を借りて構築されています。

社員が日常業務を管理するために使用している店舗用社内ポータルGoogle Cloud PlatformGoogle Cloud Platform- Posted by Jon Byrum, Product Marketing Manager, Google Cloud Platform導入事例はこちら

Google Cloud Platform の情報を Podcast で公開

2016年2月29日月曜日

* この投稿は米国時間 2 月 24 日、Google の Developer Advocate である Mark Mandel と Francesc Campoy Flores によって投稿されたもの(投稿はこちら)の抄訳です。Google Cloud PlatformGoogle Cloud PlatformGoogle Cloud Platform Podcast

デベロッパーアドボケイトチームMark MandelFrancesc Campoy

今週のニュースのまとめ

コミュニティに貢献する質問

ビッグデータ、Kubernetes、HTTP/2 といった技術的な興味深いトピックの徹底分析

「Cloud Vision API」と「開発者の経験」についてGoogle Cloud 製品マネージャーである Ram Ramanathan と Chris Sells へのインタビュー

Cloud Platform を実際にどのように活用しているのかわかる Shine Technologies のお客様の声

RSS iTunes-Posted by Mark Mandel, Developer Advocate and Francesc Campoy Flores, Developer Advocate

データセンター向けの新しいディスクを探求

2016年2月27日土曜日

* この投稿は米国時間 2 月 23 日、Google の Infrastructure の VP である Eric Brewer によって投稿されたもの(投稿はこちら)の抄訳です。2016 USENIX conference on File and Storage Technologies (FAST 2016)ホワイトペーパー

- Posted by Eric Brewer, VP Infrastructure, Google

Google Cloud Debugger の UI 改良、より使いやすく直感的に

2016年2月26日金曜日

* この投稿は米国時間 2 月 17 日、Google Cloud Platform の Product Manager である Sharat Shroff によって投稿されたもの（投稿はこちら）の抄訳です。Google Cloud DebuggerCloud DebuggerCloud Debugger 1. 言語、ランタイム、プラットフォームCloud DebuggerCloud DebuggerCloud Debugger

App Engine、App Engine Managed VM、Compute Engine で実行される Java アプリケーション

App Engine、App Engine Managed VM、Compute Engine で実行される Python アプリケーション

Compute Engine で実行される Go アプリケーション

App Engine Managed VM、Compute Engine（ Alpha ）で動作する Node.js アプリケーション

2. デバッグのための UI 改良Cloud DebuggerCloud DebuggerCloud DebuggerCloud DebuggerCloud Debugger セクション

スナップショットの取得。Cloud Debugger はデプロイなどの一般的なワークフローに統合されています。

さまざまなソースコードリポジトリの中から適切なものを選ぶことで、デプロイされたアプリケーションに対応するソースコードをセットアップ、選択できます。ローカルリポジトリとクラウドリポジトリの両方がサポートされるようになりました。Cloud Debugger をソースコードなしで使うことも可能です。

おなじみのツリービューレイアウトを使用して、複雑なソースコード階層をたどることができます。

URL のシェアと同じくらい簡単に、他のプロジェクトのメンバーとスナップショットをシェアし、彼らと共同で作業することができます。

これらは、Cloud Debugger を使いやすくするとともに、本番環境でのエラーの診断をより生産的な操作に結び付けるための、UI 拡張のほんの始まりにすぎません。

3. ソースコードを使ったデバッグ、ソースコードなしのデバッグ

ソースコードの格納場所やアクセス手段に関係なく、アプリケーションの状態をチェックしてソースコードにリンクバックできます。

ソースへのアクセスなしでデバッグ

多くのケースでデベロッパーがソースコードへのアクセス手段を提供できていないことを、私たち Google は認識しています。Cloud Debugger は、ファイル名と行番号だけを入力すれば、その位置のスナップショットを取得できます。

キャプチャしたソースを使用してデバッグ

キャプチャしたソースコードをアップロードすれば、ソースリポジトリに接続しなくても、複数のセッションを介してアプリケーションのデバッグを支援できます。

ローカルソースを使用したデバッグ

任意のローカルソースファイルを Cloud Debugger で指定すれば、そのファイルからスナップショットを取得できます。ローカルファイルでデバッグする場合、ソースコードはそのデバッグセッションのみで使われます。Googleのサーバーにアップロードされるソースコードはありません。

クラウドソースリポジトリを使用したデバッグ

以前と同様に、Cloud Source Repositories が提供するソースコードストレージや管理機能を使用して、アプリケーションのソースコードに対するアクセスを提供すれば、デベロッパーは Cloud Debugger を使うことができます。

ソースリポジトリは、Git を介してバージョン管理を提供し、Cloud Console と新しい gcloud コマンドラインツールを使って管理できます。

ソースコード管理システムが使用可能な場合は、デベロッパーコンソールを使ってソース管理リポジトリの中の正しいバージョンのソースコードを指定するだけで、正確なソース情報が表示されます。

4. いつものツールで思うがままにデバッグ

IntelliJ IDEA を使用しているデベロッパーの場合は、使い慣れた IDEA デバッガインターフェースの下で本番環境のアプリケーションをデバッグできます。

あなたの Java ソースコードを Google と共有できない場合でも、あなたが Cloud Debugging セッションにいる間は、Cloud Tools for IntelliJ プラグインはローカルマシンのコードを使用するため、問題はありません。

今後数週間の間に、Cloud Debugger のさらなる改良が発表される予定です。期待してお待ちください。

また、私たち Google はいつものように直接のフィードバックを歓迎します。Stack Overflow に掲載されるバグ報告や提案についても、きちんとチェックしていきます。

本番環境のアプリケーションを Cloud Debugger で検査したことのない方は、今こそ始めてみてください。機は熟したのです。

- Posted by Sharat Shroff, Product Manager, Google Cloud Platform

Custom Machine Types が正式リリースに ― コンピュートコストが最大 50 % 減

2016年2月25日木曜日

* この投稿は米国時間 2 月 17 日、Google Cloud Platform の Product Manager である Sami Iqram によって投稿されたもの（投稿はこちら）の抄訳です。Google Compute EngineCustom Machine Types （カスタムマシンタイプ）GA （正式リリース）ベータ版の提供が開始市場をリードする価格性能比Google Cloud Platform平均 19 %（最大 50 % ）

Wix : 7,500 万人以上のユーザーにサービスを提供するメディアプラットフォームを支えるコンピュートのコストを 18 % 削減しています。

Lytics : 幅広い顧客行動に基づくマーケティングインサイトを Customer Data Platform を使って引き出すため、各種のコンピュートに応じて必要なリソースを正確に見積もって使用し、20 ～ 50 % のコスト節減を実現しています。

iRewind : 2015 年だけで 50 万本以上の動画を生み出した制作システムの基幹的な処理のコストを最大 20 % 節約しています。

Google Compute EngineGoogle Compute Engine分単位の課金継続利用割引Google Container EngineDeployment ManagerCompute Engineインスタンスの作成

$ gcloud components update
$ gcloud compute instances create my-custom-vm --custom-cpu 6
--custom-memory 12 --zone us-central1-fWeb サイト- Posted by Sami Iqram, Product Manager, Google Cloud Platform

GCE と Red Hat Gluster Storage によるクラウドベースのスケーラブルファイルサーバー

2016年2月25日木曜日

* この投稿は米国時間 2 月 18 日、Cloud Solutions Architect である Vic Iglesias によって投稿されたもの（投稿はこちら）の抄訳です。Google Cloud PlatformGoogle Cloud StorageDataStoreBigQueryGoogle Compute Engine （GCE）永続ディスク最大 64 TB最大 15,000 IOPS

GCEここ- Posted by Vic Iglesias, Cloud Solutions Architect

Spotify の導入事例: 音楽ストリーミングの巨大インフラを Google Cloud Platform へ移行

2016年2月24日水曜日

* この投稿は米国時間 2 月 23 日、Google Cloud Platform の Lead Sales Engineer である Guillaume Leygues によって投稿されたもの(投稿はこちら)の抄訳です。

この度、Spotify がバックエンドを Google Cloud Platform に移行するプロジェクトを進めていることを公表いたします。

7,500万以上のユーザーを抱える企業が、自社製のインフラストラクチャからクラウドへ移行させることは、そう頻繁に起こることではありません。

しかしあと数週間、数ヶ月もすると、多くの熱狂的な Spotify ユーザーが楽しんでいる音楽体験が GCP によって届けられるようになります。

Spotify は全ての人のために音楽を特別なものにしたいと考えています。現在、Spotify は20 億を超えるプレイリストをホスティングし、ユーザーが 3000 万曲以上の楽曲にアクセスすることを可能にしています。

また、アーティスト、アルバム、ジャンル、プレイリスト、レコードレーベル別に、どんなデバイスからも楽曲を検索することができ、Discover Weekly という機能によって世界中何百万もの人々にパーソナライズされたプレイリストが提供されています。

これまで Spotify では、ユーザーにとってシームレスな使用体験を提供するために、技術者たちが自らコアインフラを運営し、データセンター領域、 PC ハードウエアやネットワーキング機器を買ったり、借りたりしていました。

しかしこの作業は次第に無視できないものとなってきました。革新的な機能やソフトウェアにの開発に注ぐべき自社の大切なリソースを、このような形で使用してしまうことに価値があるのだろうかと、幾度となく自問自答するようになりました。

そして結果的に Spotify は、データセンター開発への資源投下をやめることを決断し、慎重な検討やテストの結果、パブリッククラウド中から Google Cloud Platform を選択しました。

さらに同社は Google Cloud Platform への移行をサービストラックとデータトラックの二つの流れに分けました。

Spotify のアーキテクチャはマイクロサービス化されており、すでにそのうちの幾つかはオンプレミスのデータセンターからGoogle Cloud へ移行し、 Google Cloud Storage や Compute Engine 、その他サービスを利用しています。

Compute Engine があれば、チームは超高速 IOPS SSD やローカル SSD のストレージ能力による、安定したパフォーマンスの発揮が期待できます。

オートスケーリングにより、必要なタイミングで適切なリソースを使うことができるようになるので、強靭でコスト効率の高いアプリケーションをつくることが可能です。

Spotify は現在、ストレージに関しては Cloud Datastore や Cloud Bigtable を導入しています。

この豊かなストレージサービス群で、技術者はデータ保存やデータベース維持に時間を取られず、複雑なバックエンドロジックの開発に集中することができるのです。

Spotify はまた、Google の Direct Peering や Cloud VPN 、 Cloud Router などの Cloud Networking サービスを使ってペタバイト単位のデータを移動しています。

その結果、迅速さと信頼性の高さに裏打ちされた体験を、世界中のユーザーにもたらすことが可能になっています。

データについては、Spotify は全く新しいテクノロジースタックの導入を行っています。例えば、Hadoop や MapReduce、Hive、自社製ダッシュボードツールから、 Google Cloud Pub/Sub や Dataflow 、BigQuery、Dataproc など最新データ処理ツールへの移行を始めました。

BigQuery や Dataproc では、データチームが複雑なクエリを実行し、数時間どころか１~ 2 分で答えを得ることができます。

これによって Spotify はより深く、双方向的な高頻度の分析、製品開発、機能試験、より高度なユーザーインターフェイス機能を実行することができます。

Spotify は全てのイベントをそのエコシステムに集めて転送するために、Google のデーターメッセージングおよびストリーミングのためのグローバルサービスである Cloud Pub/Sub を使用しています。

これにより、高信頼性の no-ops で毎秒数10万件ものメッセージ処理を実現しています。

さらに Spotify はその ETL ワークロードの動力として Google のデータ処理サービスである Cloud Dataflow を導入しています。バッチ処理もストリーム処理も、 1 つのクラウドベースマネージドサービスで行うことができるのです。

Google としても、全社的に先進的なユーザーエクスペリエンスを追求する姿勢を持った Spotify と一緒にプロジェクトができることは大変エキサイティングなことです。

Google Cloud Platform の使用を開始した Spotify が次に何をつくるのか楽しみで仕方ありません。

※ GCP NEXT 2016 の開会基調講演では Spotify の Engineering and Infrastructure 副社長である Nicholas Harteau 氏によるトークをご紹介しますので、ぜひご参加ください。また、Spotify のセッションでは、Spotify がどのように Google Cloud BigQuery や Dataflow を取り入れているのかもご紹介します。

- Posted by Guillaume Leygues, Sales Engineer, Google Cloud Platform

導入事例はこちら

ついに Google Cloud Vision API のベータ版リリース！

2016年2月23日火曜日

* この投稿は米国時間 2 月 18 日、Google Cloud Platform の Product Manager である Ram Ramanathan によって投稿されたもの（投稿はこちら）の抄訳です。私たち Google は、このたび Google Cloud Vision API のベータリリースを発表しました。ベータ版では誰でも画像の内容を解析できます。たとえば「スポーツカー」や「寿司」、「鷹」といった日常的な物体から、画像内のテキストや製品ロゴまで、画像に含まれるさまざまな要素の検出が可能です。Google Cloud StorageCloud Vision API料金も発表

画像内の物の検出 : Google Photos で使われているのと同じテクノロジーにより、たとえば花やよく知られたランドマークなど、さまざまな物体を画像から検出します。

不適切なコンテンツの検出 : Google SafeSearch のパワーを使い、クラウドソーシングによって集められた画像からさまざまなタイプの不適切コンテンツを検出してモデレートします。

感情の分析 : 画像に写っている人々の喜び、悲しみ、怒りなどの感情を分析します。よく知られた製品ロゴの検出も可能です。

テキストの抽出 : OCR により、画像に含まれるテキストを抽出します。広い範囲の複数言語からどの言語によるテキストかを自動判別することも可能です。

昨年 12 月の初めに Cloud Vision API の限定プレビューを発表して以来、数千もの企業がこの API を試用し、数百万もの画像アノテーションリクエストを送ってきました。私たちは皆さんからのフィードバックとコメントをとても感謝しています。Cloud Vision API の応用範囲の広さにも驚かされました。

ソーシャルな写真の編集とブランディングアプリケーションを手がける Photofy は、多くの人々が撮った写真を 1 日に 15 万枚以上もモデレートしています。

同社 CTO の Chris Keenan 氏によると、Cloud Vision API を使う前は、サービスを不正使用から守ることはほとんど不可能でした。

Cloud Vision API の導入とともに、ユーザーが作成した写真の中から暴力的、性的な可能性があるものにフラグを付け、不正使用防止ポリシーを実効性のあるものにすることができました。

地域密着型 SNS を提供する Yik Yak の AI 技術責任者、Marsal Gavaldà 氏は、数百万枚もの画像を Cloud Vision API に解析させた経験から、この API のオブジェクト検出能力、コンテンツ分析力、複数の言語によるテキスト抽出の精度と再現率を高く評価しています。

API で識別できたオブジェクトの数は、他のクラウドプロバイダーによる類似サービスと比べて桁違いに多いとのことです。

なお、ベータ期間中は、ユーザーが使用できる画像数の上限は月あたり 2 千万枚です。また、Cloud Vision API はリアルタイムのミッションクリティカルなアプリケーションで使うことを意図したものではありません。

Cloud Vision API のドキュメントも公開されています。ドキュメントには、Pythonと Java で API の使い方を説明するチュートリアルとサンプル、Android と iOS を対象とするモバイルアプリのサンプルが含まれています。

Cloud Vision API は、役立つ情報を世界に発信するアプリケーションの構築を目指すという、私たち Google の長い旅の第一歩です。

そんな旅にご参加いただけるのであれば、今すぐ API を試してみてください。そして、ぜひこちらに質問やフィードバックをお寄せください。

私たちのお気に入りのロボットを、ぜひもう一度ご覧ください

- Posted by Ram Ramanathan, Product Manager, Google Cloud Platform

株式会社リクルートライフスタイルの導入事例： Google Cloud Bigtable などの Google 最新機能を駆使して、リアルタイム分析のコストを 10 分の 1 に。

2016年2月22日月曜日

今や常識となったビッグデータの活用を一歩先に進め、それをリアルタイムに分析・利用するという動きが活発になりつつあります。株式会社リクルートライフスタイルの取り組みもその最先端の 1 つ。その現場では、これまでになかった機能をローコストに実現するため、Google Cloud Platform の数々の新機能が駆使されていました。

■ 事例概要 Google Cloud Platform の様々なサービスを利用し、『じゃらんnet』や『ホットペッパービューティー』などのサービスでログのリアルタイム分析基盤を構築。 ■ 写真左から株式会社リクルートライフスタイル ■ 利用中の Google Cloud Platform サービス Google BigQuery、Google Cloud Bigtable、Google Cloud Dataproc、Google Cloud Pub/Sub、Google Container Engine など株式会社リクルートライフスタイルは、『じゃらんnet』や『ホットペッパーグルメ』『ホットペッパービューティー』など、それぞれのジャンルで国内最大級の規模を誇るサービスを開発・運営している企業。当然のことながらその利用者数とそこから生まれるデータは膨大で、その活用は急務と言えました。そのアクセスログを新たなビジネスチャンスに結びつけようという具体的な動きが始まったのは 2015 年の夏ごろ。吉田さん率いる少数精鋭のエンジニアによる社内プロジェクトがスタートし、まずは大量のログデータを集計・可視化する基盤作りを始めることになりました。

「それまでもログを可視化する仕組みは存在していたのですが、主にコスト面の事情から直近 3 日分のデータしか利用できないなど、できることが限られていました。そんな中、『じゃらんnet』から、より長期間のログを活用したいという声が上がってきまして…。解決方法を模索していく中で Google Cloud Platform に行き着きました」（吉田さん）まず吉田さんたちが使い始めたのが Google BigQuery。単純にコスト面で有利なことに加え、何より高速であるということもリクルートライフスタイルの各種サービスが求めるニーズに合致していました。「我々の規模のサービスのログをリアルタイム解析したいと考えると、もうBigQuery しか考えられないというくらいのインパクトを感じました」（明智さん）

これを受けて 2015 年秋頃には単にログを溜めるのではなく、それをリアルタイムに集計し、リアルタイムにサービスに返すという試みもスタート。当時まだ公開されたばかりの Google Cloud Bigtable をいち早く採用するなど、新しい技術をさらに貪欲に活用し始めます。「当時は β サービスが始まったばかりだったということもあって、少なからずトラブルもあったのですが、Google の丁寧なサポートもあり、乗り越えることができました。こうした有望そうなサービスを積極的に試していくのも我々のような実験的プロジェクトの使命。もし何かトラブルがあっても、サービス本体への直接的な影響はまださほど大きくありません。こういうところでリスクを取って、会社に知見や経験を蓄積していくことも大切だと考えています」（吉田さん）こうして、徐々にプロジェクトで利用するサービスの大半を Google Cloud Platform に移行。現在は BigQuery、Bigtable のほか、Google Cloud Dataproc、Google Cloud Pub/Sub、Google Container Engine などを活用し、各サービスの膨大なログを処理しています。中でも特に Dataproc の本格導入はリクルートライフスタイルが事実上の国内第一例となりました。「Dataproc で気に入っているのが全体的な動作が機敏であること。ジョブを投げるとすぐに結果が帰ってくるので、トライ＆エラーがしやすい。実験段階で何度も起動したり落としたりとうことを繰り返すのでとても助かりました」（宮井さん）

「これまでおよそ 5 分かかっていたことが 1 分くらいで返ってくるというのはなかなかに衝撃的な体験でしたね。開発・検証の無駄が大幅に削減できたことで、はっきりと生産性が上がったという実感があります」（吉田さん）もちろん Google Cloud Platform への移行を考えた最初の理由であるコスト削減も達成。現在は 4 万スループット/秒程度の利用を想定しているそうですが、吉田さん曰く「Google 以外のサービスと比べて、費用が 5 ～ 10 分の 1 程度になりました」とのこと。実験的なプロジェクトということで、予算が限られる中、これは非常に大きな成果だったと言います。現在、『じゃらんnet』では、宿泊プランの検討時に「昨日この宿泊施設を●名が予約しました」などといった情報が表示されるようになっています。「こうした情報をユーザーに提示することでコンバージョン率が跳ねるということは分かっていますから、今後はそれを他のサービスにも拡大していきたい。今回、Google Cloud Platformでこの仕組みを低コストに実現できることが分かりましたので、よりいっそう活用していくことになるでしょう」（吉田さん）「具体的には Google Cloud Logging や Google Cloud Monitoring の導入を検討中です。また、これら新規サービスを積極的に活用していくために開発管理ツールの Cloud Deployment Manager も試してみたいですね」（宮井さん）

「後は Amazon Web Servicesで言うところのAWS Lambda に相当するアプリ実行環境がほしいですね。現在はまだそれに相当する機能が存在しない(注)のですが、今後、これらの機能が実装されていくのであれば、将来的に Google Cloud Platform に全面移行するということも充分にありえると思っています。」（吉田さん）【注】取材後の2016年2月11日、Google Cloud Platformに Google Cloud Functions が追加（現在はα版）されました。【関連リンク】 ■株式会社リクルートライフスタイル Tech Blog 「「AWSからGCPに切り替えたらコストが1/10になった」CETエンジニア吉田啓二氏インタビュー」導入事例はこちら

Google Cloud Platform でモバイルアプリを構築する

2016年2月18日木曜日

* この投稿は米国時間 2 月 10 日、Google Cloud Platform の Technical Writer である、Syne Mitchell によって投稿されたもの（投稿はこちら）の抄訳です。

需要に応じた自動的なスケーリング

デバイス間の自動的なデータ同期

オフラインでの適切な対処

通知やメッセージの送信

こちらのページ（Google Cloud Platform を使ったモバイルアプリの構築）では、Google サービスの対照比較が行われているほか、チュートリアルやサンプルコードへのリンクが提供されています。

これらのリンクや詳細情報は、ページ内の図をクリックして確認できます。このドキュメントで解説されている設計パターンをご紹介しましょう。

Firebase を使ったリアルタイムのデータ同期

iOS、Android、ウェブアプリを構築するためのフルマネージドプラットフォームの Firebase では、自動的なデータ同期と認証サービスを活用できます。

Firebase がアプリ開発をどのように単純化しているのかを理解するためには、チャットアプリについて考えてみるとわかりやすいでしょう。Firebase でデータを保存すると、デバイス間で自動的にデータを同期したり、デバイスのストレージを最小化したり、認証サービスを利用することができます。バックエンドサービスを作成する必要は一切ありません。

https://lh5.googleusercontent.com/zRv6HJ6-A36f6uKo28SZ02jT_JtqIFubyONvKvR3UaPlwtsB7wDaan6isxMHgRNscknmhD4upWfGELBoa7BOwdDTeR2jH-L_ml_AxpnRYY1roCxf-0_9PRd-TM9cmpZDOt7lFSuH

Google App Engine で Firebase でのマネージドコンピューティングが可能に

ユーザーデータの処理や、イベントのオーケストレーションにバックエンドの計算が必要な場合は、App Engine で Firebase を使用することで、リアルタイムで自動的にデータを同期できるようになります。また、ホスティング環境の監視、アップデート、スケールに対応するアプリケーションプラットフォームも活用できます。

この例として、To Do リストを実装するアプリについて考えてみましょう。この場合は Firebase でのデータの保存によって、デバイス間で確実にリストをアップデートできるようになります。

App Engine で実行されるバックエンドサービスから Firebase に接続することで、保存されるデータの処理や使用が可能です。To Do アプリについては、リマインダーを毎日メールで送信できます。

https://lh4.googleusercontent.com/YkoNQKdMrTQnUxLqCtSB0QjVIpDJztSSnvPQdyrIjzXgDtluDeWFHAgfyUkXnVVw_gnaKgx60RbjY_fQSPvjBZZMowTqMUKC81D_osgz0z1A13eCjoneI7N9rcR5uHJEJYiuJnSX

App Engine Managed VMs が可能にする、 Firebase での柔軟なコンピューティング

モバイルバックエンドサービスでネイティブバイナリの呼び出し、ファイルシステムへの書き込み、他のシステムの呼び出しが必要な場合は、Firebase を App Engine Managed VMs と一緒に使用することで、リアルタイムで自動的にデータを同期できるほか、App Engine の標準的なランタイム以外でコードを実行する柔軟性を備えた、アプリケーションプラットフォームを活用できます。

App Engine との併用に類似しているものの、App Engine Managed VMs で Firebase を使用する場合にはより多くの選択肢があります。たとえば、既存のネイティブバイナリを使ってチャットのメッセージを俳句に変換するアプリについて考えてみましょう。

この場合は Firebase でデータの保存と同期を行い、App Engine Managed VMs で実行されるバックエンドサービスからデータに接続することが可能です。バックエンドサービスで新しいメッセージの検出とネイティブバイナリによる俳句への変換が行われた後、完成した俳句が Firebase へプッシュされます。

https://lh4.googleusercontent.com/4FqJTn5DVyi6iBxvVOKRu_aG_O_RdnwZE9SmFSAcq1sZ7LUae--fjqzdPu0J_MQ--htJ0fJswub5DsE9wPoIPwjiuZjTPtESsnjX34kXKK-7txo7zvuORIYHJOzcbXI2BJewWMCl

App Engine と Google Cloud Endpoints を使った、クライアントライブラリの自動生成

Cloud Endpoints を使用すれば、 App Engine とやりとりするためのラッパーを作成する必要がなくなります。ここでは、Cloud Endpoints によってクライアントライブラリが生成されるため、モバイルアプリから直接 API 呼び出しを行うことができます。

アプリにリアルタイムのデータ同期が必要ない場合や、バックエンドサービスがすでにメッセージングや同期に対応している場合は、Cloud Endpoints と App Engine の併用によってクライアントライブラリを自動で生成することで開発時間を短縮できます。リアルタイムの同期が不要なアプリとして、商品を検索して近所の店舗を見つけるものなどが挙げられます。

https://lh6.googleusercontent.com/8zkJF1Sj7mNeyMVxiUZXi-8iC65nT6fJNALnDWILqZgmzjMNnfvcRLiGKwICPePpPQuiZJt1-7ocjSX8qpsitwchVe2aF_phimsiSnZfNu94Xgh5h8eeGB_STyO_FbJIqkeYzlTg

Compute Engine と REST、または gRPC の使用による完全な管理

Google Compute Engine では、Google のインフラストラクチャで仮想マシンの作成と実行が行われます。サーバーに対する管理者権限がユーザー付与されるため、設定をすべて管理できます。

物理マシンや仮想マシンでバックエンドサービスがすでに実行され、そのサービスにカスタムのサーバー構成が必要な場合、Cloud Platform でコードを実行する一番の早道は Compute Engine にサービスを移行することです。この場合、仮想マシンの維持とアップデートはユーザーの作業になります。

Compute Engine は、バックエンドサービスでサードパーティ製のライブラリや、カスタムのサーバー構成が使用される場合に有効です。

https://lh4.googleusercontent.com/F2-FppzyS4pNyMoi9dpj-0veHcuqaDlK8ZCSXIxAd2VD2mtRLdwjwT8AqoPiPJXTmYywsa3uhxwafxCcgCFE9MRUDTjQLyEcfBxli6ejUHBpG4SO_dTYgvKzF1jMHJroQCarbsAG

上記の設計パターンのほか、サービスの構築、テスト、監視、モバイルアプリからサービスへの接続（プッシュ通知の送信など）に関する詳細については、こちらのページ（モバイルアプリのバックエンドサービスを構築する）をご覧ください。

- Posted by Syne Mitchell, Technical Writer, Google Cloud Platform

Google のクラウドを使用して 350 万冊の書籍データを公開

2016年2月18日木曜日

* この投稿は米国時間 2 月 16 日、The GDELT Project の創設者である Kalev Leetaru によって投稿されたもの（投稿はこちら）の抄訳です。今回のゲストブログは、The GDELT Project の創設者である Kalev Leetaru 氏です。The GDELT Project は、100 種類以上の言語で書かれたほぼすべての国のニュースメディアをモニタリングして、私たちのグローバル社会を動かしている事件や物語を明らかにしようとしています。Google BigQuery2 つの公開 BigQuery データセットサンプルクエリ2 世紀分の本の地図ステップ１複合オブジェクト

図 1 2 世紀分の本の地図ステップ２ステップ３ステップ４ステップ５Google BigQueryBigQueryブログBigQueryサンプルクエリパイプライン処理
- Posted by Kalev Leetaru, founder of The GDELT Project

Google Cloud Platform ゲーム業界向けイベント「Change The Game」を開催します。

2016年2月16日火曜日

開催概要 http://www.roppongihills.com/facilities/access/index.htmlhttps://goo.gl/DEKFE0

Google Cloud Storage による JGroups ベースのクラスタリングとノードディスカバリ

2016年2月12日金曜日

* この投稿は米国時間 2 月 4 日、Solutions Architect である Grace Mollison によって投稿されたもの（投稿はこちら）の抄訳です。JGroupsGoogle Cloud StorageGoogle Compute Engine

Cloud Storage 上での JGroups クラスタリングバージョン 3.5 以降の JGroups は、GOOGLE_PING という JGroups プロトコルを使用して Google Cloud Platform 上のクラスタメンバー（ノード）を見つけられるようになりました。

GOOGLE_PING は、Cloud Storage バケットのフラットファイルに各メンバーの情報を格納します。そして、これらのファイルを使ってクラスタの初期メンバーを見つけ出します。新しいメンバーを追加したときには、新メンバーは Cloud Storage バケットから他のクラスタメンバーのアドレスを読み出し、各メンバーに ping を送って自分の存在を知らせます。

デフォルトでは、JGroups メンバーは UDP のマルチキャスト通信を使用して、ネットワーク上の他のインスタンスに自分の存在をブロードキャストします。

ただし、GCP は他のほとんどのクラウドプロバイダーやエンタープライズネットワークと同様にマルチキャストをサポートしていないので、GCP と JGroups は妥当なフォールバックとして TCP のユニキャスト通信をサポートしています。

TCP 上のユニキャストというモデルでは、新インスタンスはすでにクラスタに含まれているノードのリストを反復処理し、個々のノードに別々に通知を送って自分が追加されたことを通知します。

JGroups 構成ファイルを格納するための Cloud Storage 設定

JGroups がファイルストレージとして Cloud Storage を使えるようにするには、まず Cloud Storage バケットを作らなければなりません。

Cloud Platform Console で Cloud Storage ブラウザに移動します。
Create bucket をクリックします。
Create bucket ダイアログで下記を設定します。

バケット名の要件に従ったバケット名
ストレージクラスとして Standard
バケットデータが格納される位置

次に、相互運用をセットアップして、新しい Cloud Storage デベロッパキーを作ります。デベロッパキーは認証のために必要です。

GOOGLE_PING は Cloud Storage XML API を介して認証を必要とする要求を送ります。Cloud Storage XML API は Cloud Storage デベロッパキーを使って HMAC （keyed-hash message authentication code）認証を行います。

デベロッパキーの生成手順は次のとおりです。

Google Cloud Platform Console でストレージ設定ページを開きます。
Interoperability タブを選択します。
今までに相互運用を設定したことがない場合は、Enable interoperability access をクリックします。

注意：相互運用アクセスを有効にすると、Cloud Storage は他のクラウドストレージのために書かれたツールと相互運用できるようになります。GOOGLE_PING は JGroups の Amazon を対象とする S3_PING を基礎としているので、相互運用アクセスが必要なのです。

　４. Create a new key をクリックします。

　５. アクセスキーとシークレットの値をメモします。これらは後で必要になります。

重要：デベロッパキーは秘密にしておいてください。デベロッパキーはあなたの Google アカウントとリンクしており、他のアクセス認証情報と同じように扱う必要があります。

GOOGLE_PING を使えるように JGroups 構成を設定する

Cloud Storage バケットとデベロッパキーの作成後は、GOOGLE_PING クラスを使うようにアプリケーションの JGroups 構成を設定します。JGroups を使うほとんどのアプリケーションは、次のようにすれば GOOGLE_PING クラスを使うようになります。

JGroups XML 構成ファイル（ほとんどの場合は jgroups.xml ）をエディタで開きます。
UDP ではなく TCP を使うようにファイルを書き換えます。（<tcp bind_port="7800">）
PING セクションの GOOGLE_PING の設定を次のように変更します。your-jgroups-bucket の部分はあなたが実際に使っている Cloud Storage バケットに、your-access-key と your-secret の部分はあなたのアクセスキーとシークレット値に書き換えます。

<!-- PING timeout="2000" num_initial_members="3"/ -->

     <GOOGLE_PING
                location="your-jgroups-bucket"
                access_key="your-access-key"
                secret_access_key="your-secret"
                timeout="2000" num_initial_members="3"/>

これで、GOOGLE_PING はあなたの Cloud Storage バケットを使い、クラスタ名に合わせた名前を持つフォルダを自動的に作るようになります。

注意：デフォルトでは、仮想マシンはポート 80 を使用してバケットとの間でセキュアではない通信を行います。インスタンスとバケットの間に暗号化接続をセットアップするために、GOOGLE_PING 要素に次の属性を追加してください。（<google_ping ...="" port="443">）JBoss Wildfly アプリケーションサーバーを使用している場合は、JGroups subsystem に GOOGLE_PING プロトコルを追加するように設定すればクラスタリングを構成できます。

デモンストレーション

この節では、GOOGLE_PING が動作しているところを実際に見てみましょう。

下記のサンプルは、同じ Cloud Platform プロジェクトに含まれる Compute Engine インスタンスのクラスタをセットアップします。ping ターゲットとしては内部 IP を使います。

最初に、Compute Engine インスタンス上に（Vert.x を使用して）センダーアプリケーションを作り、それをクラスタの最初のメンバーにします。

$ java -Djava.net.preferIPv4Stack=true
-Djgroups.bind_addr=10.240.0.2 -jar
my-sender-fatjar-3.1.0-fat.jar -cluster -cluster-host 10.240.0.2

注意：一般に、バインドの対象は Compute Engine インスタンスの内部 IP アドレスにすべきです。外部にルーティングできる IP アドレスを使ってインスタンスをクラスタリングしたい場合は、次のパラメータの external_ip の部分を実際の外部 IP に書き換えたうえで、java コマンドに追加してください。

-Djgroups.external_addr=<external_ip>

アプリケーションを起動すると、まだレシーバノードをセットアップしていないので “No reply” と表示されます。

このセンダーノードは、私の Cloud Storage バケットにフォルダと .list ファイルを作ります。私の JGroups クラスタは JGROUPS_CLUSTER という名前で構成されており、Cloud Storage フォルダにも自動的に JGROUPS_CLUSTER という名前が付けられます。

.list ファイルは、JGroups の JGROUPS_CLUSTER クラスタのすべてのメンバーをリストアップします。JGroups では、クラスタを作るために最初に作ったノードがクラスタコーディネータに指名されます。そのため、私が作ったノードには T というマークが付けられています。これは、ノードのクラスタコーディネータのステータスが true になっていることを示します。

次に、同じく Vert.x を使用して、第 2 の Compute Engine インスタンス上でレシーバアプリケーションを起動します。

$ java -Djava.net.preferIPv4Stack=true
-Djgroups.bind_addr=10.240.0.2 -jar
my-receiver-fatjar-3.1.0-fat.jar -cluster -cluster-host
10.240.0.2

このコマンドを実行すると、新しいメンバーノードのために、.list ファイルにエントリが追加されます。

.list ファイルにノードが追加されると、新ノードは、最初のメンバーノードから “ping!” メッセージを受信し始めます。

第 2 のノードは、個々の “ping!” メッセージに対して “pong!” メッセージを返します。第 1 のノードは “pong!” メッセージを受信すると、センダーアプリケーションの標準出力に “Received reply pong!” と表示します。

始めよう

ぜひ無料トライアルにサインアップして、GOOGLE_PING を試してみてください。

- Posted by Grace Mollison, Solutions Architect

ビッグデータに焦点をあてたブログを開設

2016年2月9日火曜日

* この投稿は米国時間 2 月 3 日、Google Cloud Platform の Managing Editor である Jo Maitland によって投稿されたもの（投稿はこちら）の抄訳です。皆さんがリンクをクリックしてこの投稿を読み始めるまでの間に、Google Cloud Platform は数百万件のビッグデータ分析イベントを処理しています。そしてこの後の処理件数は数十億件に達するでしょう。それが Google が力を入れて開発している分散システムと大規模データ処理技術です。内部構造や新機能に関する詳細な情報「Spark や Dataflow のプログラミングモデルのメリットを夜中まで議論するといったことがよくある」「わずかな料金を支払えば、セットアップすることなく数秒で数 TB のデータを処理できると思うとワクワクする」「自社のデータ処理のために、Google のサービスを支えるインフラストラクチャの使い方を学びたい」ビッグデータのブログ- Posted by Jo Maitland, Managing Editor, Google Cloud Platform

GCP NEXT 2016 ：クラウドの重要トピックを網羅した技術セッション

2016年2月4日木曜日

* この投稿は米国時間 2 月 2 日、Google Cloud Platform の Developer Advocate である Kelsey Hightower によって投稿されたもの（投稿はこちら）の抄訳です。Google Cloud PlatformGo プログラミング言語KubernetesGCP NEXT 2016Google Cloud Platform

GCP NEXT 2006 のカンファレンスプログラムについてGoogle Cloud PlatformGoogle Cloud Platform

“From idea to market in less than 6 months : Creating a new product with GCP”　- 発表： CI&T （App Developer トラック）

“Painless container management with Google Container Engine & Kubernetes”　- 発表： Brendan Burns & Tim Hockin ,Google （Infrastructure & Operations トラック）

“Cloud data warehousing with BigQuery featuring Dropbox Nighthawk”　- 発表： Jordan Tigani ,Google & Dropbox （Data & Analytics トラック）

“Security analytics for today's cloud-ready enterprise”　- 発表： Matt O’Connor ,Google & PwC （Solutions Showcase）

スピーカーを募りGoogle Cloud Platform今すぐに登録Google+TwitterLinkedIn- Posted by Kelsey Hightower, Developer Advocate, Google Cloud Platform

高速ローカル SSD のサイズが最大 3TB/VM に

2016年2月3日水曜日

* この投稿は米国時間 2 月 1 日、Senior Product Manager である John Barrus によって投稿されたもの（投稿はこちら）の抄訳です。このたび、Google Cloud Platform の高速なローカルストレージソリューションであるローカル SSD のサイズが倍増しました。Google Compute Engine

2015 年 1 月に発表キーバリューストア（KVS）NoSQL データベースライブマイグレーション技術Compute Engine のコンソールサービスドキュメント- Posted by John Barrus, Senior Product Manager

Cloud9 IDE が Google Cloud Platform をサポート

2016年2月2日火曜日

* この投稿は米国時間 1 月 27 日、Product Manager である Chris Sells によって投稿されたもの（投稿はこちら）の抄訳です。Cloud9 をご存知でしょうか。Cloud9 はクラウド内の開発環境で、機能豊かなコードエディタと sudo 権限付きの Ubuntu コマンドラインを備えています。Google Cloud PlatformGoogle App EngineCloud9 のドキュメント始め方Cloud9 の中で Google を認証してくださいCloud Source Repositories

gcloud と Google Cloud SDK の使い方

ワークスペースの仮想マシンには Google Cloud SDK がプリインストールされており、Cloud Platform 上のプロジェクトにアクセスするように自動的に設定されます。

Cloud9 からの直接的な編集、ビルド、デプロイ

Cloud9 を使えば、プロジェクトのコードを編集し、変更内容をクラウドソースリポジトリにプッシュできます。準備が整ったら、IDE から直接コードをビルドして、App Engine にデプロイします。

Cloud9 と Cloud Platform : 次に来るものは？

現在、Cloud9 は App Engine の Java アプリケーションをサポートしていますが、今後数週間のうちに新たなプログラミング言語や機能のサポートが追加されます。質問やコメントがある方は、ぜひ Cloud9 のコミュニティサイトにお越しください。

動いているところを見たいですか？　下記をクリックして、Cloud9 で Cloud Platform プロジェクトがいかにすばやくセットアップできるかを実際にご覧ください。

私たち Google は、Cloud9 が Cloud Platform をサポートすることをシェアできて非常にうれしく思っています。今後追加される言語と機能についても、ぜひご注目ください。

- Posted by Chris Sells, Product Manager

株式会社 Donuts の導入事例： Google App Engine を活用し、わずか半年でサービスイン

2016年2月2日火曜日

機能、価格など、さまざまな点で差別化されているクラウドプラットフォームですが、“開発しやすさ”も重要なポイント。もちろん、その点でも Google Cloud Platform は高く評価されています。例えば、株式会社 Donuts では全くの新規サービスをたった半年で正式サービス開始にこぎ着けることができました。その秘訣とは？

■ 事例概要 ■ 写真左から株式会社Donuts Web事業部ジョブカングループ開発チームリーダー久野慎弥さん Web事業部ジョブカンディレクター松本航洋さん ■ 利用中の Google Cloud Platform サービス Google App Engine、Google Cloud Storage、Google Cloud Datastore、Google Cloud SQL 「単車の虎」や「Tokyo 7th シスターズ」など、国内スマホゲームの雄として名を知られる株式会社Donuts ですが、それはあくまで同社の「柱」の1つ。2007年の創業当時から企業向け ASP 事業など、非ゲーム事業も積極的に展開していました。そんな同社が、この 2 月に正式サービスをスタートしたクラウド型ワークフローシステムが「ジョブカンワークフロー」。社内稟議の申請→承認を効率化させ、意志決定をスピードアップさせるというサービスです。旧来の同種サービスと比べて使いやすく、何より安価な価格設定とすることで、これまでこういったサービスを導入していなかった中小企業への普及を狙っています。実はこのサービス、開発開始が 2015 年 8 月。わずか 4か月で β 版に到達し、その 2 か月後にサービスインしたというのだから驚きです。しかもその開発はたった 2 名のエンジニアが主導したとのこと。今回はそのお二人、開発チームリーダーの久野慎也さんと、ディレクターの松本航洋さんにお話をお伺いしました。

「ジョブカンワークフローを開発するにあたって利用したのが Google App Engine。昨年 8 月に開発をスタートするにあたり、社外アドバイザーの方に勧められたのがきっかけでした。正直なところ当初は半信半疑だったのですが、実際に触ってみると、ものの 1 時間くらいでサービスの骨組みが完成してしまいびっくり（笑）。プロダクトスタートアップのツールとして実に正しい姿だと感激しました」（久野さん）「一番助かったのはインフラの部分を考えなくて良いことですね。普通だと、利用者数の規模を想定しながら作っていかねばならないのですが、チームにインフラ専任者がいなかったため、それをどうするかが悩みの種でした。ところが、Google App Engine を導入したことでそれが解消。アプリを書くことだけに専念でき、開発期間が大幅に短縮されました。また、バージョン管理の使い勝手の良さも気に入っています。クリック 1 つで前のバージョンに戻れるので、とりあえずアップデートして、ダメだったら元に戻すということが気軽にできるんですよ。これはほかにないメリットだと思います」（松本さん）

β テスト開始後も、この特性は大いに活躍。サービスの仕様上、企業ごとに細かな要望が上がってくるそうなのですが、その対応も非常にスムーズに進んだそうです。結果、大きなトラブルもなく、予定通り 2 月の正式サービス開始を実現することができました。

もちろんジョブカンワークフローは今後も積極的な機能向上を予定。組織内での意志決定速度をよりいっそう効率化していくため、外部チャットツールとの連携やスマホ対応など、さまざまな機能を追加していくそうです。「この辺りのトライ＆エラーも Google App Engine なら簡単。より一層、使い勝手を突き詰めていきたいですね」（久野さん）

「あと、機能の追加・改善がものすごく早いのも Google Cloud Platform の良いところだと思います。例えば、当初はデータベース周りの機能がやや弱く、将来的な不安があったのですが、先日導入された第 2 世代Google Cloud SQL で全て解消。理想のものになりました。現時点でちょっと気になっているのはコンソールが使いにくいこと程度でしょうか。いろいろなことができるがゆえに逆に混乱してしまうんですよね。ただ、これについてもすぐに改善されるのだろうなと勝手に期待しています。後はアジアサーバーを用意してくれれば完璧ですね（笑）」（松本さん）社内で Google Cloud Platform を使うのは始めてだったそうですが、Google のサポートが良かったことも好印象だったというお二人。導入当初にレクチャーを受けたことで、ほとんど勉強らしい勉強をすることなく開発をスタートできたと言います。「後は、料金が非常に安いこともありがたく思っています。こんなに使っているのにたったこれだけの料金でいいの？　と驚いたほど（笑）。おかげで、サービス料金を下げることができ、企業導入の敷居を下げることができました。今後は Google Cloud Platformのほかのサービスも試してみたいですね。特に個人的に一番気になっているのがGoogle BigQuery。これを駆使して、ジョブカンワークフローとは別の、何か新しいサービスを企画できたらなと考えています」（松本さん）導入事例はこちら

Google Cloud Platform Japan Blog