Google Cloud Platform Japan 公式ブログ

[ 海外事例 ] マーケティング会社が Google BigQuery で天候データから顧客行動を分析

2015年4月28日火曜日

この投稿は、Google Cloud Platform ホームページで公開している Interactions 社の事例の抄訳です。

事例の概要

Interactions 社の目的は、小売業や製造業のクライアントの計画策定の助けになる、販売パターンや顧客行動といった高水準のデータ分析を改善する方法を探ることでした。同社はさまざまなソリューションを検討した後、Google BigQuery を選択しました。もともと取引データやポイントカードデータを扱っていた同社は、POS データと公的な気象データを組み合わせて BigQuery で分析することで、大雪のときの顧客行動に関する新しい知見を得ることができました。

13 億行のデータを分析

POS およびアメリカ海洋大気庁 (NOAA) のデータ

28 の製品カテゴリで売上の顕著な増加が見られた

悪天候時の顧客行動パターンに関する新たな知見が得られた

Interactions 社とは

Interactions は、1988 年に設立され、世界中の小売企業やブランドに、店内製品デモンストレーションやアウトドアエクスペリエンスマーケティングプログラムを提供しています。社員数は 45,000 人以上、本拠地はサンディエゴ、毎年 200 万件以上のイベントを企画・実施、毎日 5,500 件ものイベントを運営しています。

膨大な行のデータ

Interactions 社は天候と買い物の関連性を探るプロジェクトを進めるにあたり、Google、およびソフトウェア企業 Tableau と密接に連携しました。Tableau のデータ視覚化ソフトウェアと BigQuery の組み合わせは、小売店とアメリカ海洋大気庁 (NOAA) から入手した 13 億行のデータをインタラクティブに調べることを可能にしました。「従来の方法ではこのような分析は不可能だったでしょう」、Interactions 社のリサーチアンドアナリティクススペシャリスト、マーカス・ドミトゥルザクは語ります。「以前は事業目標が変わるたびにデータを抽出する必要があり、その作業を IT チームが行っていました。BigQuery の場合、データを 1 度クラウドにアップロードするだけです。あとはデータに接続して、データセットを自由に作ったり壊したりできます。ビジネスユーザーにとって非常に強力な武器です」

買い物客のパターンが明らかに

Interactions 社の天候データプロジェクトは 2012 年から 2013 年の冬に始まりました。同社は、似たような悪天候を特定し、それらを重大度によって分類し、それぞれの悪天候のピーク前、ピーク時、ピーク後で販売にどのような影響があったのかを測定しました。BigQuery と Tableau で販売と顧客行動のパターンを調べたのです。
Interactions 社はクリエイティブで柔軟なハイブリッドアーキテクチャを使用し、自動化された抽出、変換、ロード (ETL) プロセスで、元になったオペレーションデータベースシステムのデータのブランチを BigQuery に作成しました。天候データは ETL プロセスで POS データと統合されました。これにより、日常業務に影響を与えない、分析プロジェクト用の最新のサンドボックスが完成しました。Tableau と BigQuery を組み合わせたことで、トライアンドエラーの分析が可能になり、データ抽出やクエリリクエストで IT 部門を煩わせることなく、分析を繰り返せるようになりました。

クエリのたびに「新しい本」を読むかのよう

Interactions 社の発見には、販売数が急激に増加あるいは減少した在庫品目、悪天候の程度による顧客行動の変化、などがありました。同社は膨大な件数のデータから販売数が大幅に増えた 28 の商品カテゴリを突き止めました。それらのカテゴリの販売数は同じような悪天候の前日に 20 ～ 261% も増えていたのです (酒類販売量の突発的増加も含まれています)。そして悪天候のピークとともに販売数は落ち、その後 4 日間その状態が続きました。悪天候が予測されながらも実際にはそうはならなかった地域でも同じような変化が見られました。
「データに問いかけて初めて分かることがたくさんあります。データは私たちに知見を与えてくれます」、Interactions 社のグローバルマーケティングアンドアナリティクス担当副社長ジョバンニ・デメオは説明します。「それが面白いところでもあるのです。クエリを実行するたびに新しい本を開くようなものです」。別の言い方をすると、BigQuery は蛇口のようなものだ、とデメオは言います。「必要なときだけ蛇口をひねって使うことができる、それが非常に重要な点です。同じデータ量を同じ速度で処理できる他のどのシステムにも、そのようなメリットはありませんでした」

オンデマンドでスケーラブルなリソース

「データ分析は、当社が小売業や製造業の顧客関係維持を支援する上での基盤です」、デメオは語ります。「BigQuery は他のプラットフォームよりも新しく、実験的なことを試すことができて楽しかったです。私たちはデータで何ができるのかを知りたかったのです」
「従来のインフラストラクチャは、分析に新しいデータソースを追加するたびに多額の資本投資が必要で、構築にも長い時間がかかりました」。そう語るのは Interactions 社のグローバルインフォメーションストラテジー担当上級副社長アビ・ベニワルです。「Google BigQuery は必要な時間、費用、投資額がまったく異なり、コストと時間を大幅に節約できます」
BigQuery は従量課金制のサービスで、一般的なエンタープライズデータウェアハウスで求められる多額のライセンス料やサポート料は必要ありません。また全てのデータはクラウドに格納されるため、IT 部門の負荷を削減できます。デメオはこう言います。「私たちは常に、最小限の投資で、収益を最大化する方法を探しています。BigQuery は理想的な組み合わせで、オンデマンドで拡張性に優れたリソースです」
導入事例はこちら

クラウドの料金体系を理解する: 第 2 部 – ローカル SSD 編

2015年4月27日月曜日

* この投稿は、米国時間 4 月 21 日、Google Cloud Platform Global Head of Solutions の Miles Ward によって投稿されたものの抄訳です。 はじめに 習うより慣れろということで、ローカル SSD を直接、そしてより気楽に体験していただくために、割引価格をご用意しました。2015 年 4 月 21 日から 2015 年 5 月21 日まで、ローカル SSD を $0.055/ GB /月、つまり 75％割引で提供します。この期間後は、料金は通常の $0.218/ GB /月に戻ります。ローカル SSD を試す絶好のチャンスですので、ぜひお試しください。「クラウドの料金体系を理解する」というブログを公開して以来、最も多くリクエストを頂いた項目は、ストレージのコストと性能の詳細について、特に当社の製品が他のクラウドサービスに対してどこが異なっているかに関してです。
ソリッドステートディスク（SSD）は素晴らしい技術ですが、一方で多種多様なデバイス、構成、コネクタ、およびドライバが桁違いに性能に大きな違い出ることを理解することが重要になります。すべてのソリッドステートディスクが同じように作られているわけではないからです。さらに、クラウドプロバイダーによっては、まったく異なるパッケージの SSD を提供する場合もあります。今回、統計を列挙したり実際の状況分析を示したりするのではなく、ローカル SSD を使用したシステム例を具体的に示し、Google Cloud Platform および AWS で実行した際の違いを分析してみましょう。

以前のポストと同様に、Web スケールのアプリケーションのために、NoSQL のキー値をストアするバックエンドをデプロイする場合を例として考えてみましょう。ここでは、分かりやすく単純化した例として、3 ノードのクラスタをデプロイし、最大性能を得るためにローカル SSD にデータをホストすることにします。
Google Compute Engine 上で、4 つのローカル SSD ボリュームが接続された n1-highmem-8 インスタンスを使用します。これは、AWS の i2.2xlarge インスタンスに、 CPU、RAM、および SSD のストレージボリュームを持たせた仕様とほとんど同等です。ここでは、最低でも 75000 IOPS を実現して、高速クエリを達成するようにセットアップしようとしているのです。
以下の計算は 2015 年 4 月 3 日に行ったため、その料金計算結果をこのポストに記載したものであることに注意してください。不一致があるとすれば、このポストの公開以後に料金変更や計算手順変更があったためである可能性があります。 料金計算結果: Google Cloud Platform 見積料金: 月額: $1883.04
Amazon Web Services 見積料金: 月額: $3744.18 Google Cloud Platform のほうがかなり安いことに気づかれたでしょう。その理由の 1 つは、Googleに Sustained Use Discounts と呼ぶ自動継続割引があるためです。しかし、それがなくとも 39 ％も割安です。詳細な数値を次に示します。

i2.2xlarge の場合の利点:

17 % メモリ量が大きい
7 % SSD スペースが大きい

n1-highmem-8 に 4 つの SSD パーティションを接続した場合の利点:

39 % 割安
807 % 読み出し IOPS が大きい
380 % 書き込み IOPS が大きい

気づきましたか？ 読み出し IOPS が 807% も大きいのです！ほぼ半分のコストで 9 倍以上の速さを生み出しています。
では、このことは NoSQL のワークロードにどのような影響があるでしょうか？読み出しに限定したワークロード（その多くはレポートや分析などのシステム）が時間とともに大きくなると仮定した場合、インスタンスで SSD における読み出しキャパシティが使い尽されると、ノードを追加してクラスタをスケールアウトする必要があります。読み出しトラフィックが 6 倍になったとしてみましょう。
料金計算結果: Google Cloud Platform 見積料金: 月額: $1883.04 (上記とまったく変わらず) Amazon Web Services 見積料金: 月額: $22465.08 Google での SSD 読み出しスループットと同等にするためには、AWS では、次に大きいサイズのインスタンス（i2.4xlarge）にステップアップし、3 倍多く実行する必要があります。 Google Cloud Platform の SSD が提供する追加の読み出し性能は、同等のみならずシンプルな 3 ノードのシステムを維持することを意味しますが（管理/運用コストを「本当に節約」できます）、同じ低価格のままです。書き込みに限定したワークロードの場合でも、Google を選んだほうが同様に有利です。
この例よりも小さな規模で始める場合はどうでしょうか？すべてのアプリが 680 K IOPS を必要とはしませんね。これは、Google Cloud Platform の SSD 実装と AWS インスタンスとの間の最も重要な違いの 1 つです。つまり、Google では、標準型、大容量メモリ、および高性能 CPU のインスタンスに SSD を 375 GB 単位で追加することができるのです。このことは、高効率な SSD で始めて、直線的にスケールアップできることを意味します。ただし、AWS では、効率的なスクラッチディスクとして使用するためのいくつかの小さなシングルコピー SSD がインスタンスに含まれていることに注意することが重要です。これらは、負荷の高いデータ使用向けに設計されているわけではないので、AWS では性能仕様は文書化されていません。
SSD は Google のすべてのプライマリーインスタンスで提供されていますので、はるかに小さなインスタンスタイプでも設定が容易ですし、ローカル SSD の性能を維持することができます。各プロバイダで利用可能な 3 ノードの最小構成にスケールダウンしてみましょう。それでもフル性能の SSD にアクセスできます。この構成は、Google では 1x375GB のローカル SSD を持った n1-standard-1 インスタンスに相当し、AWS では 1x800GB のローカル SSD を持った i2.xlarge インスタンスに相当します。
料金計算結果:
Google Cloud Platform 見積料金: 月額: $341.90 Amazon Web Services 見積料金: 月額: $1873.20
圧倒的な差です。Google では、このシステムは非常にコスト効率が良く、3 週間実行しても無料トライアルの範囲内で試せます。 SSD の具体的な料金比較ローカル SSD の場合、クラウド間で直接料金比較を行うのは多少問題がありました。というのも、AWS はコンピューティングとローカルストレージを単一の SKU にバンドルしていますが、Google Compute Engine はそれらを分離して、顧客が自由にデプロイメントのサイズを決めたり最適化したりできるようにしているからです。
しかし、一般に公開されている AWS のドキュメントを使用すれば、SSD の料金と量だけが異なった同様なインスタンスタイプの構成と料金を比較することによって、EC2 のローカル SSD の料金を導き出すことは可能です。すべての構成情報は Amazon EC2 インスタンスのウェブページから、すべての料金情報は Amazon EC2 料金表ページから引用しました。すべてのケースにおいて、ノースバージニア州でのオンデマンド料金を使用しています。基本的には、r3（メモリ最適化）と i2（ストレージ最適化）のそれぞれのインスタンスタイプを比較しています。同量の CPU とメモリを持つが SSD の量が異なり、料金が違うものをペアでまとめてグループ化し、料金の違いによって SSD 容量の違いを分けることによって、AWS が顧客に課金する 1GB のローカル SSD あたりの料金を導出することができます。4 種類のそれぞれの r3/i2 ペアを比較すると、AWS は $0.0007/GB/時間のローカル SSD 料金であると算出されます。
一方、Google は 375GB 単位でローカル SSD を $0.218/GB/月で提供していることになります。1 時間あたりの料金に直すと $0.0003/GB/時間となります。従って、Google では少なくとも 4.8 倍高速なローカル SSD を提供しながら AWSよりも 57%割安であると結論づけられます。
インフラシステムの設計で最善の決断をしようとする際には、料金が重要な点であると我々は考えています。クラウド料金についての考えや問題、分かりにくい事、分析が困難な事、予測が困難な事など、我々にできることがあれば、Stack Overflow でご連絡ください。 -Posted by Miles Ward, Global Head of Solutions, Google Cloud Platform

Google Cloud Platform を活用するメディア・映像業界 - ラスベガスの NAB レポートから

2015年4月24日金曜日

* この投稿は、米国時間 4 月 14 日、Google Cloud Platform VP の Brian Stevens の投稿を日本にて編集したものです。

1 本の長編アニメ映画のレンダリングには、1 億時間もかかる場合があります。

「Google」と「メディア」という 2 つの単語を聞いて、何を思い浮かべますか？ YouTubeでしょうか？実は、Google におけるメディアとは「YouTube」以上を意味するのです。
メディアやエンターテインメント業界は Google Cloud Platform が注目している主要エリアです。これは 9 万 7 千人が来場するラスベガスのNABショーで、4 月 14 日に行われたクラウドカンファレンスの基調講演でお話ししたことですが、私たちはプラットフォームとパートナーエコシステムを急速に拡大しながら独自にメディア特有の課題を解決しています。また最新のVirtual NAB カンファレンスの一部として、Google の Jeff Kember とMiles Ward もプレゼンテーションをしています。
メディア、映像業界は、クラウドの力を利用することにより、コンテンツの作成、変換、アーカイブ、そして配信の方法を大きく変化させています。
Google Cloud Platform が業界特有のワークフローに合わせて調整できるようにしてこそ、Google Cloud Platform はメディア業界を最大限に支援できるようになるでしょう。この例として、ビジュアルエフェクトのレンダリング向けサービスが挙げられます。アーティストがリアルな一場面をモデリング、アニメーティング、コンポジティングするような熟練の仕事とは別に、イメージを作り出すためにはたいてい膨大な計算を必要とします。比較的シンプルなビジュアルエフェクトのショットまたはアニメーションでも、 1 秒分のビデオを構成する 24 フレームのレンダリングに数時間を要します。
Google Cloud Platform はレンダリングを大幅に加速し、簡素化します。さらに、請求されるのは消費されたプロセッササイクルとビットに対してのみです。エンドツーエンドのレンダリングソリューションを探している方には Google Zync Render を提供しています。2015 年の第 1四半期にベータ版が発表された Zync は、小中規模スタジオ向けのターンキーサービスです。既存のオンプレミスソフトウェアのワークフローを直接統合し、ローカルのレンダーファームと同じように自然で早い反応を得ることができます。また、The Foundry などと連携することによって、最高興行収益をあげたいくつかの映画の作成に使われたツールも Google Cloud Platform から提供しています。
Zync Render Workflow

Google Cloud Platform による費用対効果のよいコンピュートやストレージを利用して、スタジオは継ぎ目のないレンダリングパイプラインを拡張して、爆発的なキャパシティニーズに対処し、制作の締め切りにつきまとう典型的な障害を取り除くことができます。すでに、Framestore, RodeoFX, iStreamPlanet, Panda, Industriromantik といったメディアのお客様が大成功を収めています。また、よりジェネラルなプラットフォームも構築し、業務のあらゆるステージやコンテンツのライフサイクルについて、メディア企業をサポートできるようにしています。その一例が Google Cloud Nearline ストレージです。非常に低コストで事実上データ量を無制限に保存できるもので、検索時間はテープで経験するような数時間ではなくおよそ数秒です。これはメディアコンテンツのアーカイブに最適です。
さらに私たちは、先頃、大容量のコンテンツを高速処理する数値計算ワークロード向けに、32 コアの VM インスタンスを発表しました。そして先日、Avere Systemsとの協力を発表し、パフォーマンスに影響を与えることなくクラウドストレージとオンプレミスストレージとを橋渡しすることが可能になりました。これはクリエイティブなコラボレーションやコンテンツ制作のための機会を大きく切り開くものです。 -Posted by Brian Stevens, VP for Google Cloud Platform

Google BigQuery 新機能詳細 - ビッグデータを新しい次元へ

2015年4月24日金曜日

Andrew Kowal によって投稿

クラウド流ビッグデータを誰でも使えるようにするべく、Google Cloud Platform のビッグデータサービスが大きく前進しているということを先日お伝えしました。Google BigQuery に新機能を追加し、EU ゾーンの提供を開始したことには簡単に触れましたが、この BigQuery のパフォーマンスと機能の拡張により、より安全にデータをコントロールしていただけるようになっています。本日は、BigQuery の新機能について詳しく説明します。
ヨーロッパのデータロケーションコントロール完全なマネージドサービスの利用を継続しながら、BigQuery のデータを EU ゾーンに保存するかを選べるようになります。つまり、地理データコントロールのオプションを持つ一方で、ローレベルのクラスタ保守管理の負担が取り除かれることになります。設定方法の詳細については、Google Cloud Platform 技術サポートチームにお問い合わせください(別途サポートプランのご利用が必要となります)。
ストリーミングの挿入 BigQuery で最も人気のある機能の 1 つは、リアルタイム分析のためのサービスへのストリームデータ挿入機能です。大量のストリームに対して低レイテンシ分析を可能にするために、デフォルトの挿入レートリミットを、1 テーブルごとに毎秒 10,000 行から 1 テーブルごとに毎秒 100,000 行に引き上げました。また、行サイズのリミットを 20 KB から 1 MB に増やしました。料金体系も、行単位からバイト単位に移行し、より柔軟かつスケールするようになります。
セキュリティ機能 BigQuery にデータ期限のコントロールと行単位でのアクセス許可を追加し、より広範囲の企業向けアプリケーションに対応することができるようになります。行単位のアクセス権により、ユーザーごとに異なるビューを作成する必要がなくなるので、ファイナンスや人事など部門が異なってもセキュアにアクセスしてデータを取得することが保証されます。また、BigQuery 内のデータは未使用時には暗号化されます。 Google Cloud Platform の他サービスとの統合 Google Cloud Logging は、運用を管理し、システムがビジネスアプリケーションの稼働状況を知るための強力なツールセットを提供します。また、Google App Engine と Google Compute Engine のアプリケーションがそれぞれのログを BigQuery にストリーミングすることも可能になりました。これにより、リアルタイムでログデータを分析し、システムの実行状況やユーザーのアプリケーション利用状況を知ることができます。
アプリケーションログをマーケティングデータや提携先企業のデータと融合することで、アウトリーチの有効性を迅速に評価することができます。あるいは、ユーザーのプロファイル情報から得られたコンテキストをアプリケーションログに適用して、特定顧客とのやり取りから得られた顧客行動を逸早く評価することができるため、IT 部門とやビジネス部門の双方にとって有意義な価値を迅速かつ容易に生み出せます。
ニーズの多かった機能加えて、リクエストの多かった次のような機能を実装しました。

Google Cloud Datastore からのコンテンツのロード

クエリ結果のネスト

FULL および RIGHT OUTER JOINS の利用

小計を含むように集計をロールアップ

直近に削除されたテーブルからのデータ回復

ウェブ UI改善の活用

機能の完全なリストについてはリリースノートを参照してください。
前例のないスケール BigQuery は、ユーザーがクラスタのデプロイやアップデートをしなくても、優れた拡張性とパフォーマンスを提供します。そのため、莫大なデータから意味のある傾向や特徴を取得することに集中することができるようになります。例えば:

BigQuery は顧客データの 1 日あたり合計 100 TB 以上ものリアルタイムストリームを受け入れ、それらに対して直ちにクエリを実行することができます。これらのデータはすべて、他のソースから毎日ロードされる数百テラバイトに追加されていきます。IoT のような変化の大きい大規模アプリケーションを使用している場合でも、実行中のアプリケーションに対して迅速かつ的確な判断を行うことができます。

BigQuery のユーザーには、単純な SQL クエリでペタバイト単位のデータや数十兆行をスキャンするようなクエリを実行している方もいます。このような場合でも、システムのプロビジョニング、メンテナンス、フォールトトレランス、パフォーマンスチューニングなどに配慮する必要はありません。

BigQuery の新機能を使用するとさらに多くのデータを分析することが可能になり、最新の方法でこれまでより高速にアクセスすることができるようになります。
始めるには、BigQueryの詳細をご覧いただき、ドキュメントもご参照ください。まずは、無料トライアルからお試しを。
-Posted by Andrew Kowal, Product Manager

株式会社 Good Feel（グッド・フィール）の導入事例: Google Cloud Platform で実現した、連打式戦術カードバトルゲーム

2015年4月23日木曜日

Facebook アプリの PHANTOM CHRONICLE（ファントムクロニクル）というゲームをご存知ですか？テンポの良いシンプルなカードバトルゲームでありながら、世界中で 100 万ダウンロードを超えて遊ばれています。

その Android 版としてリリースされたのが、PHANTOM CHRONICLE RUSH FIRE（ファントムクロニクルラッシュファイアー）。世界観はそのままに、スマートフォン用にゲームシステムがリメイクされ、”連打式戦術カードバトル” という名が示している ”連打” による ”破壊的スピード” のアクション性と、カードの配置による戦術が組み合わさって、Facebook 版とはまた違う面白さを楽しるゲームになっています。主に家庭用のゲームソフトを作っている、開発元の株式会社 Good Feel（グッド・フィール）さんに、なぜソーシャルゲーム、スマートフォンゲームを自ら発信するようになったのか、そして Facebook 版から今回の Android 版も含めて、そのバックエンドに Google App Engine を使っている理由をお聞きしました。写真左から、株式会社グッド・フィール制作部第２制作グループ、ディレクターの阿部裕一さん、開発を担当されている加藤大和さん、プロデューサーの畠山恵一さん。阿部さんは、Facebook 版の頃からプランナー、ディレクターとして企画や開発の取りまとめを行い、加藤さんも同様に継続してサーバーサイドの開発を続けています。畠山さんは、部全体で他のタイトルも含めたプロデューサーとして、広告やプロモーション関連のマネージメントをされています。ゲームの形が変わっても、本質的な面白さや楽しませ方は不変
そもそも Facebook でアプリケーションをリリースした理由と、今 Android アプリケーションをリリースした理由、これまで家庭用ゲームソフトを開発されていた皆さんが何故ソーシャル / スマートフォンゲームをリリースされたのですか？ 畠山さん: 2009-10 年くらいの段階で、ソーシャルゲームとして、モバゲーさんやグリーさんが出てきました。僕はクリエイティブよりビジネス面に多くかかわってきましたので、直観的にこれをやらないとまずい、ゲームのあり方が大きく変わるのではないかと思ったわけです。僕らは家庭用ゲームのノウハウはそれなりに持っていますが、どうも違う。正直、最初にソーシャルゲームを遊んだときは、なんだこの面白くないものはと思いました（笑）でもたくさんの人が楽しんでいる。それはなんでだろう、そこが一番最初の始まりですね。この遊び方というのを僕らが知らなかったら生き残れないんじゃないか、という思いも個人的にありました。 Android アプリをリリースすることに関しては、ある意味、自然な流れだと思っています。これまで家庭用ゲームソフトを作る仕事をしてきましたが、ハードは、時代の流れで変わっていきます。そのとき必要とされるハードに向けて作る、でも僕らの作るものは変わらないと思いますけどね。

プランニングする上で、家庭用ゲームソフトと違い、遊ぶ人の価値観を違うものとして考えなければいけないことも多かったと思います。 阿部さん: 家庭用ゲームの場合、最初にお金を払って購入しますので、買ったからには最後まで遊びたい、ストーリーが気になるとか、”どれだけ楽しめるか、じっくり楽しめるか” ということに、価値観を感じられる方も多いと思います。一方で、スマートフォンゲームの場合には、今これが欲しい、すぐ強くなりたい、というように、短い時間で楽しむことに変わってきています。バランスをとってじっくり遊ばせるのか、バランスをあえて崩した遊びにするのか。そういった考え方が大きく違ってきていて、苦労しているところです。ただ、ゲームを遊んでいただく中での面白さや、楽しませ方というところの本質は変わっていないと思ってます。面白さの感じ方、そこまでの段取り、手順が大きく違ってきていると感じていますね。

PHANTOM CHRONICLE は、ゲームシステムの特徴もありますが、まずはカードとその絵柄に目が行きます。 畠山さん: 最初に Facebook で展開したゲームは、海外をターゲットにしたアクション RPG のようなゲームを作っていましたが、運用を含め上手くいきませんでした。その当時、日本国内ではカードバトルが全盛で、それを海外で展開し、人気の出たカードバトルのゲームが出てきた頃でしたので、Facebook ゲームでもカードバトルは、いけるのではないかと考えたわけです。確信は何もないまま、アメリカをメインターゲットとして出してみたところ、最初は少ない出だしでしたが、途中から、何が原因かはっきりわからないのですが、ユーザーが大幅に増えて、アメリカのユーザーはもちろん、意外だったのは南米系の方々や、東南アジア系の人たちに、幅広く遊んでいただけるようになりました。ダウンロード数で、トータル 130 万くらいのユーザーに遊んでいただいています。グラフィックは、いわゆるトレーディングカード風に作っていて、今回の Android アプリもターゲットは最初から北米に設定し、スタートしています。

Google App Engine で実現した「止まらない」サービス
PHANTOM CHRONICLE RUSH FIRE のバックエンドは Google App Engine ということですが、最初に Facebook 版をリリースされた頃から App Engine を利用されているのですか？ 畠山さん: Google App Engine は 2010 年の頃、ソーシャルゲームを始めようとした頃から調査をしていて、本格的な導入を検討し始めたのが 2011 年。実際に使ったのが 2012 年の 11 月。第１弾 Facebook ゲームのときに初めて使いました。その後、第 2 弾で PHANTOM CHRONICLE を作るにあたっても、一番ナレッジがあり、実績があったので使っています。当時、なぜ App Engine に興味を持たれたのですか？ 畠山さん: 当時は、自社でサーバーを構築してやるというのも検討しましたが、何分ベンチャー企業なので、ゼロからの構築はまず難しい。それで AWS の EC2 であるとか調べた中で、一番使いやすそうだったのが App Engine。それに従量課金だったことも、”ダメだったら安くすむ” ということは、ベンチャー企業にとって一番のメリットです。 App Engine は、インターネット上でいろいろな技術情報を調べる中で出てきたという感じです。2009 年くらいは Mixi のゲームが流行っていて、例えば、そのゲームを作るとした場合、まずサーバー立てるにはどうしたらいいのだろうと、開発者のフォーラムだとかを探しまわり、その中で見つけた感じです。先ほど Facebook で急にユーザーが増えたというお話でしたが、特に問題なく対処できました？ 加藤さん: そうですね。世間で良く聞くインストールが集中してサーバーが落ちたということは経験してないですね。なので、ユーザーの数にかかわらず、一定の動きをしてくれています。 阿部さん: そういうところは App Engine で助かっております。実際にずっと運用し続けていまして、メンテナンスなどでサービスを止めたことはありません。ユーザー数が急に増えるといった変化の中でも、サーバーの増築等を行わず、サービスを止めずに運用し続けられている、安定して稼働できているのは、凄く助かっていますね。インフラの運用を Google におまかせできる。 畠山さん: 本当にそういうところは大きなメリットだと思います。 App Engine でのアプリケーション開発で使われているプログラミング言語など開発環境や、開発で困ったこと、最近取り入れた機能など教えてください。 加藤さん: 最初の Facebook のアプリケーションが Java で、それを引き継いで開発を始めたので、言語は Java ですね。フレームワークに Slim3 を使っています。Datastore の読み書きなどが綺麗にまとまって、面倒な処理を Slim3 が吸収してくれている部分もあって、開発はし易いです。App Engine を使っていて、使い方がよくわからなくて困った、という経験はあまりないですね。最近ですと、Facebook のプロジェクトから、スマートフォンのプロジェクトを始めるときに、App Engine Modules という機能が出来て、それまでは Backends という形で提供されてきたものがよりロジカルに分割できて、かつ機能的にも強固になって、次はこれを使おうと調べました。ドキュメントも何度も見て、自分の今の開発環境でどうやったらできるのかと実験した上で使っています。 Google Cloud Platform に期待しているところや、こういう機能を使っていきたいというところはありますか？ 加藤さん: むしろまだまだ勉強不足なところがあって、今使っているところでも App Engine や Slim3 の機能を使いこなしているとは思っていないので、それが先ですね。 阿部さん: 私も PHANTOM CHRONICLE RUSH FIRE の開発で手一杯で、十分調べきれていませんが、Cloud SQL と Cloud Storage は少し興味を持っていまして、今社内でやっている部分や、他社さんの製品を使っているところを、できれば集約したいなと考えています。BigQuery は特に、データ集計で苦労していますのでもう少し調べたいと思っています。

ソーシャルに、継続的に運営するゲームへの変化

以前取材したところで、これまでに家庭用のゲームを作ってきた会社だと、サーバーサイドを担当できる開発者や知識が不足しているという話を聞きました。 畠山さん: その通りだと思いますね。実際にソーシャルゲームを作り始めるとクライアントのゲームよりもサーバーサイドが主になりますね。でも、専任のサーバーサイド開発者がいるわけではなく、さりとて、どの会社も欲しいサーバーサイドのエンジニアを中途で採用するのも難しい。となると、やっぱり社内の優秀な人をそこに投入して、育て、さらに後輩を育ててもらうという流れでやっていくしかないかなと思っています。最近のスマートフォンゲームを見ているとゲームは運営の時代なのかと思うのですけど、やはりそういう変化はあります？ 阿部さん: そうですね。ユーザーさんが、どのように遊んでくれているのか、どこで停滞しているのか、どの機能を使っているのかを把握した上で、難しいところを簡単にするとか、簡単なところを難しくしたりだとか、いろんなイベントを足していったりだとか、常に流動的に変わっていきます。ユーザーさんが求めている所を熱いうちに叩かなければならない、速く対応しなければいけない、というところは非常に苦労しているところであり、気をつけているところです。売り切りのゲームでは 1 から 10 まで準備して、あとはゆっくり結果を待つだけでしたけど、直ぐに対応出来る分、対応しなきゃいけないということが、面白くもあり、大変なところでもありますね。そのとき運営にもそれなりの人数が必要になると思うのですが、開発も含め、どれくらいの規模で運営されているのですか？ 畠山さん: 人数的には、開発チーム全員が結果的に「運用」にも関わっています。専用の運用人員は居ませんが、うちよりも少ない人数で運用している 100 万ダウンロード規模のゲームもある様ですし、やり方はいろいろではないでしょうか。また、どこもスタートしたときは、数名でそれをまわす方法を考えて、必要なところに必要な人材を入れているのではないかと思っています。グッド・フィールでも、今できる範囲でやれることをして、ビジネスの成長にあわせ必要な人材を追加できればと考えています。

Google を使ったアプリビジネスとゲームのこれから
プロモーションに Adwords を使うそうですね。開発、プロモーション、エンゲージメント、収益化まで全体に Google を使っていただいています。 畠山さん: 1 つの塊になって、その中でビジネスが展開できることは、凄くメリットがあるような気がします。他に、Facebook を使っていますが、簡単に使える反面、詳細な説明が少ない分、自力で調べて自力でやる事になります。その点、Adwordsの場合、日本語での丁寧な説明がホームページで展開されている上、弊社は幸運な事にGoogleからサポートを受ける機会があり、担当の方から使い方のアドバイスを得られるなど、こうしたサポート面でも助かっています。

最後に、皆さんが思っている、これからのゲームのあり方について一言お願いします 畠山さん: ゲームの世界に入ったら普通の世界に戻ってこれないんじゃないのかというくらいの没入感を持って遊ぶゲームと、今のスマートフォンで展開されている様な、隙間時間から自分の都合のいい時間を使って、都合の良い遊びをするゲーム、この 2 極化になるのではと思っています。 阿部さん: 畠山が話したより没入感のあるゲームは、私も是非やってみたいですし、今後出てくると思ってます。一方で、自分の生活の隙間時間に、ちょっとずつ関わってくる何かという感じで、ゲームがもっと浸透していくと思っております。特に最近のゲームは、他のユーザーとの繋がりがかなり重視されています。友達と話すネタだったり、競争だったりとか、そのためにやってみようというところもあると思いますので、そういう意味では今後もどんどん広がっていくと思いますね。 加藤さん: コンシューマーゲームではエンディングという大きな一つの区切りがありますが、こういったオンラインゲームでは、バージョンアップで要素が増えていくため、そういった区切りが無いですよね。その代わり、それぞれのユーザーが小さな目標を定めて達成、クリアしていくという遊び方と、それに合わせた提供の仕方というのがあると思うので、ユーザーの目線としても提供側としてもそこを意識していく必要があるのかと思っています。導入事例はこちら

Google Cloud Dataflow ベータ版について詳しく - ビッグデータを簡単に

2015年4月22日水曜日

* この投稿は、米国時間 4 月 16 日、 Director of Engineering の Grzegorz Czajkowski によって投稿されたものの抄訳です。MapReduceFlumeJavaMillWheelGoogle Cloud DataflowGoogle Cloud Platform ビッグデータサービスクラウド流ビッグデータGoogle Cloud DataflowGoogle Cloud Platform

統一された扱いやすいプログラミングモデルにより、バッチとストリーム処理のパイプラインをマージ - データ処理パイプラインの容易な高速化、パワフルな決定の遂行、インサイトの獲得、バッチと連続ストリーム処理との切り替えコストの削減が可能になります。

延着データ処理のためのパワフルな API プリミティブにより、データ処理ニーズに求められるコレクトネスモデルを細かくチューニング - 時刻のみならずイベント時間に基づいてデータ処理したり、制限のないソースからのデータ処理の際にアップストリームのデータ遅延を滞りなく対処したりすることができます。

完全なマネージドサービスを利用し、ダイナミックに適応可能な自動スケーリングと自動チューニングを備えているため、すぐにでも優れたパフォーマンスが得られます。開発者であるかシステムオペレータであるかには関わらず、リソースのプロビジョニングに気を配ったり、リソース使用率を最適化したりすることに時間をかける必要はもはやありません。オートメーション、完全なマネージドサービス、プログラミングモデルの相乗化により、設備投資や運用コストを劇的に削減します。

簡素化したモニタリングインターフェースにより、高度に並列化されたプロセスの管理やデバッグの複雑さを軽減します。このインターフェースは、基盤となる実行プレーンにコードがマッピングされるのではなく、処理ロジックに論理的にマッピングされます。

Google Cloud Platform において、Google Cloud Storage、Google Cloud Datastore、Google Cloud Pub/Sub、Google BigQuery などのサービスに最適化されたサポートと統合化されたデータ処理を利用できます。

Data ArtisansApache FlinkClouderaApache Spark
Stack OverflowGoogle Cloud Dataflow-Posted by Grzegorz Czajkowski, Director of Engineering

クラウド流ビッグデータと Google Cloud Dataflow のベータ版リリース

2015年4月21日火曜日

* この投稿は、米国時間 4 月 16 日、 Product Manager の William Vambenepe によって投稿されたものの抄訳です。

NoOps：クラウドプロバイダーは、拡張性と信頼性を高めるために、インフラのデプロイ、管理、アップグレードをして拡張性と信頼性を高める努力をすべきなのは、あなたではなくクラウドプロバイダーであるべきです。 “NoOps” とは、そうしたタスクや最適化をあなたに代わって行い、あなたはデータの値を理解したり利用したりすることに専念することができます。

コストパフォーマンス：”NoOps” ソリューションは、使いやすさや迅速さに加え、運用作業を省けるので明確なコストメリットが得られます。しかし、クラウド流ビッグデータではコスト効率はさらに先を行きます。自動スケールし、インフラ消費を最適化し、アイドルクラスタなどの未使用リソースを除去します。コスト / 性能分析に基づいてクエリ数や処理の待ち時間を上下させてコストを管理します。コストを調整するためにシステムを構築し直す必要はありません。

安全かつ容易なコラボレーション：Google Cloud Storage の中のファイルや Google BigQuery 中のテーブルのデータセットを、コピーしたりデータベースのアクセス権を付与したりすることなく、組織内外の協力者と共有することができます。データは、あなたがコントロールするものしか存在せず、仕事のパフォーマンスに影響を与えることなく、許可されたユーザーが（あなたに負担をかけずに）アクセスすることができます。

最先端の機能：Google Cloud Dataflow はデフォルトで信頼性の高いストリーム処理を提供しましかし、ストリーム処理が高い信頼性で容易に実行できたとしても、バッチ実行のオプションを排除することにはなりません。同じパイプラインをバッチモードで実行することができて、その場合、コストを削減し、履歴データを分析することができます。大規模のストリーミングデータを一貫処理することが必ずしも複雑で脆弱ではないとしたら、最も重要な事例にとっては最適でしょう。

Google Cloud PlatformHadoop我々のビッグデータサービス Google Cloud Dataflow のベータ版をリリース今すぐ始めて Google BigQuery の新機能Google の技術サポート総合ビッグデータサービスGoogle Cloud Pub/SubGoogle Cloud StorageBigQueryHadoop/Spark クラスタ自動デプロイメントzulilyBig Data Webinar公開データセットに対して最初のクエリを実行

-Posted by William Vambenepe, Product Manager

Google Cloud Platform Japan Blog

[ 海外事例 ] マーケティング会社が Google BigQuery で天候データから顧客行動を分析

クラウドの料金体系を理解する: 第 2 部 – ローカル SSD 編

Google Cloud Platform を活用するメディア・映像業界 - ラスベガスの NAB レポートから

Google BigQuery 新機能詳細 - ビッグデータを新しい次元へ

株式会社 Good Feel（グッド・フィール）の導入事例: Google Cloud Platform で実現した、連打式戦術カードバトルゲーム

Google Cloud Dataflow ベータ版について詳しく - ビッグデータを簡単に

クラウド流ビッグデータと Google Cloud Dataflow のベータ版リリース

12 か月間のトライアル

Labels

Archive

Feed

Company-wide

製品・サービス

デベロッパー