事例の概要

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 は理想的な組み合わせで、オンデマンドで拡張性に優れたリソースです」





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


はじめに
習うより慣れろということで、 ローカル 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



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 による費用対効果のよいコンピュートやストレージを利用して、スタジオは継ぎ目のないレンダリング パイプラインを拡張して、爆発的なキャパシティ ニーズに対処し、制作の締め切りにつきまとう典型的な障害を取り除くことができます。すでに、FramestoreRodeoFXiStreamPlanetPandaIndustriromantik といったメディアのお客様が大成功を収めています。

また、よりジェネラルなプラットフォームも構築し、業務のあらゆるステージやコンテンツのライフ サイクルについて、メディア企業をサポートできるようにしています。その一例が Google Cloud Nearline ストレージです。非常に低コストで事実上データ量を無制限に保存できるもので、検索時間はテープで経験するような数時間ではなくおよそ数秒です。これはメディア コンテンツのアーカイブに最適です。

さらに私たちは、先頃、大容量のコンテンツを高速処理する数値計算ワークロード向けに、32 コアの VM インスタンスを発表しました。そして先日、Avere Systemsとの協力を発表し、パフォーマンスに影響を与えることなくクラウド ストレージとオンプレミス ストレージとを橋渡しすることが可能になりました。これはクリエイティブなコラボレーションやコンテンツ制作のための機会を大きく切り開くものです。

-Posted by Brian Stevens, VP for Google Cloud Platform





クラウド流ビッグデータを誰でも使えるようにするべく、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 EngineGoogle Compute Engine のアプリケーションがそれぞれのログを BigQuery にストリーミングすることも可能になりました。これにより、リアルタイムでログデータを分析し、システムの実行状況やユーザーのアプリケーション利用状況を知ることができます。

アプリケーション ログをマーケティングデータや提携先企業のデータと融合することで、アウトリーチの有効性を迅速に評価することができます。あるいは、ユーザーのプロファイル情報から得られたコンテキストをアプリケーション ログに適用して、特定顧客とのやり取りから得られた顧客行動を逸早く評価することができるため、IT 部門とやビジネス部門の双方にとって有意義な価値を迅速かつ容易に生み出せます。

ニーズの多かった機能

加えて、リクエストの多かった次のような機能を実装しました。

機能の完全なリストについてはリリースノートを参照してください。

前例のないスケール

BigQuery は、ユーザーがクラスタのデプロイやアップデートをしなくても、優れた拡張性とパフォーマンスを提供します。そのため、莫大なデータから意味のある傾向や特徴を取得することに集中することができるようになります。例えば:
  • BigQuery は顧客データの 1 日あたり合計 100 TB 以上ものリアルタイム ストリームを受け入れ、それらに対して直ちにクエリを実行することができます。これらのデータはすべて、他のソースから毎日ロードされる数百テラバイトに追加されていきます。IoT のような変化の大きい大規模アプリケーションを使用している場合でも、実行中のアプリケーションに対して迅速かつ的確な判断を行うことができます。
  • BigQuery のユーザーには、単純な SQL クエリでペタバイト単位のデータや数十兆行をスキャンするようなクエリを実行している方もいます。このような場合でも、システムのプロビジョニング、メンテナンス、フォールト トレランス、パフォーマンス チューニングなどに配慮する必要はありません。


BigQuery の新機能を使用するとさらに多くのデータを分析することが可能になり、最新の方法でこれまでより高速にアクセスすることができるようになります。

始めるには、BigQueryの詳細をご覧いただき、ドキュメントもご参照ください。まずは、無料トライアルからお試しを。

-Posted by Andrew Kowal, Product Manager


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

その Android 版としてリリースされたのが、PHANTOM CHRONICLE RUSH FIRE(ファントム クロニクル ラッシュファイアー)。世界観はそのままに、スマートフォン用にゲーム システムがリメイクされ、”連打式戦術カードバトル” という名が示している ”連打” による ”破壊的スピード”  のアクション性と、カードの配置による戦術が組み合わさって、Facebook 版とはまた違う面白さを楽しるゲームになっています。

主に家庭用のゲーム ソフトを作っている、開発元の株式会社 Good Feel(グッド・フィール)さんに、なぜソーシャル ゲーム、スマートフォン ゲームを自ら発信するようになったのか、そして Facebook 版から今回の Android 版も含めて、そのバックエンドに Google App Engine を使っている理由をお聞きしました。

写真左から、株式会社 グッド・フィール 制作部 第 2 制作グループ、ディレクターの阿部 裕一さん、開発を担当されている加藤 大和さん、プロデューサーの畠山 恵一さん。

阿部さんは、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 月。 第1弾 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 SQLCloud Storage は少し興味を持っていまして、今社内でやっている部分や、他社さんの製品を使っているところを、できれば集約したいなと考えています。BigQuery は特に、データ集計で苦労していますのでもう少し調べたいと思っています。

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


以前取材したところで、これまでに家庭用のゲームを作ってきた会社だと、サーバー サイドを担当できる開発者や知識が不足しているという話を聞きました。

畠山さん: その通りだと思いますね。実際にソーシャル ゲームを作り始めるとクライアントのゲームよりもサーバー サイドが主になりますね。でも、専任のサーバー サイド開発者がいるわけではなく、さりとて、どの会社も欲しいサーバー サイドのエンジニアを中途で採用するのも難しい。となると、やっぱり社内の優秀な人をそこに投入して、育て、さらに後輩を育ててもらうという流れでやっていくしかないかなと思っています。


最近のスマートフォン ゲームを見ているとゲームは運営の時代なのかと思うのですけど、やはりそういう変化はあります?

阿部さん: そうですね。ユーザーさんが、どのように遊んでくれているのか、どこで停滞しているのか、どの機能を使っているのかを把握した上で、難しいところを簡単にするとか、簡単なところを難しくしたりだとか、いろんなイベントを足していったりだとか、常に流動的に変わっていきます。ユーザーさんが求めている所を熱いうちに叩かなければならない、速く対応しなければいけない、というところは非常に苦労しているところであり、気をつけているところです。売り切りのゲームでは 1 から 10 まで準備して、あとはゆっくり結果を待つだけでしたけど、直ぐに対応出来る分、対応しなきゃいけないということが、面白くもあり、大変なところでもありますね。


そのとき運営にもそれなりの人数が必要になると思うのですが、開発も含め、どれくらいの規模で運営されているのですか?

畠山さん: 人数的には、開発チーム全員が結果的に「運用」にも関わっています。専用の運用人員は居ませんが、うちよりも少ない人数で運用している 100 万ダウンロード規模のゲームもある様ですし、やり方はいろいろではないでしょうか。また、どこもスタートしたときは、数名でそれをまわす方法を考えて、必要なところに必要な人材を入れているのではないかと思っています。グッド・フィールでも、今できる範囲でやれることをして、ビジネスの成長にあわせ必要な人材を追加できればと考えています。


Google を使ったアプリ ビジネスとゲームのこれから


プロモーションに Adwords を使うそうですね。開発、プロモーション、エンゲージメント、収益化まで全体に Google を使っていただいています。

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


最後に、皆さんが思っている、これからのゲームのあり方について一言お願いします

畠山さん: ゲームの世界に入ったら普通の世界に戻ってこれないんじゃないのかというくらいの没入感を持って遊ぶゲームと、今のスマートフォンで展開されている様な、隙間時間から自分の都合のいい時間を使って、都合の良い遊びをするゲーム、この 2 極化になるのではと思っています。

阿部さん: 畠山が話したより没入感のあるゲームは、私も是非やってみたいですし、今後出てくると思ってます。一方で、自分の生活の隙間時間に、ちょっとずつ関わってくる何かという感じで、ゲームがもっと浸透していくと思っております。特に最近のゲームは、他のユーザーとの繋がりがかなり重視されています。友達と話すネタだったり、競争だったりとか、そのためにやってみようというところもあると思いますので、そういう意味では今後もどんどん広がっていくと思いますね。

加藤さん: コンシューマーゲームではエンディングという大きな一つの区切りがありますが、こういったオンラインゲームでは、バージョンアップで要素が増えていくため、そういった区切りが無いですよね。その代わり、それぞれのユーザーが小さな目標を定めて達成、クリアしていくという遊び方と、それに合わせた提供の仕方というのがあると思うので、ユーザーの目線としても提供側としてもそこを意識していく必要があるのかと思っています。





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


我々はまた、Cloud Dataflow エコシステムの成長に貢献している主要なオープンソース コントリビュータとも協力しています。例えば、最近では、Data Artisans と共同で Apache Flink 向けランタイムサポートを、また、Cloudera と共同で Apache Spark 向けランタイムサポートのコラボレーションをそれぞれ発表しました。

これまでにアルファ版のユーザーから寄せられた数々の提案、レポート、サポートに謝意を表します。そうした情報は Cloud Dataflow をより良い製品にするのに間違いなく役立ちました。今回発表した Cloud Dataflow のベータ版は誰でも使用できますので、Stack Overflow での質問やフィードバックを歓迎しています。Google Cloud Dataflow を試してみて、ビッグデータを簡単に活用できることを願っています。

-Posted by Grzegorz Czajkowski, Director of Engineering

Share on Twitter Share on Facebook

スキューバ機材は人間が海面下で活動するのに役立ちますが、海洋生物の効率性と俊敏性には遠く及びません。クラウドのビッグデータならば、スキューバダイバーではなく、イルカになれるのです。Google Cloud Platform は、クラウド用に構築されたパワフルでスケーラブルな、使いやすく、効率的な一連のビッグデータサービスを提供しています。これらソリューションをいち早く利用して、クラウド流ビッグデータを取り入れてみてください。


-Posted by William Vambenepe, Product Manager
Share on Twitter Share on Facebook


動き補償とは

動き補償はもともとビデオ圧縮のために使われていた技術であり、現在はほぼすべてのビデオコーデックで使われています。この技術の開発者らは、隣接するフレームが通常は(シーンの変更を除いて)あまり異なっていないことに気づき、その事実に基づいて、個別に各フレームを圧縮するよりも良好な結果が得られる符号化スキームを開発しました。要するに、動き補償を用いた圧縮は、フレーム間で起きる変化を検出し、その情報を使ってより効率的な符号化を実現するのです。 次のような 2 つのフレームがあると考えてください。


左側の Panda が


Panda が右側に

ここで、動き補償アルゴリズムは、両方のフレームに同じパンダがあって、位置だけが異なる、という事を検出します。

動き補償の第一段階;動き検出

圧縮するのに同じパンダを二度も格納したいと考えるでしょうか。この点に着眼することによって実現したのが、動き補償を用いた圧縮が実行することなのです。パンダは一度しか格納せず(通常はフレーム  #1 全体を格納します)、動きについての情報を新たに追加します。そうすると、デコンプレッサはこの情報を使用して、残りの情報(フレーム  #1 をベースにしたフレーム #2)を組み立てることができます。


以上が概要ですが、実際には上記の例のようにスムーズにいくわけではありません。オブジェクトが同じということはほとんどありませんし、通常はいくらか歪みや非線形変換が生じます。動きのスキャンは計算量が非常に多いので、探索空間を制限したりコードを最適化したりしなければなりませんし、アセンブリを手で書くことさえする必要もあります。


動き補償によるフレームレート変換

動き補償はフレームレート変換にも使用することができ、めざましい結果をもたらすことが大いにあります。

説明のため、さきほどの移動するパンダの例に戻りましょう。フレームレートを、毎秒 2 フレーム(FPS)から 3 FPS に変更したいとしましょう。ビデオ速度を維持するために、各フレームは短い時間(0.5 秒に対して 0.33 秒)だけ画面に表示されます。

フレーム数を増やす 1 つの方法は、フレームを重複させて 3 FPS にすることがありますが、品質が低下してしまいます。ご覧のように、フレーム #1 が重複しています。

フレームを複製することで2 FPSから3 FPSへコンバート


このように、出力が 3 フレーム、入力が 2 フレームありますが、その効果は視覚的に魅力があるとはいえません。人間にとって自然に見えるようなフレームを最初の 2 つのフレーム間に挿入することが必要です。つまり、真ん中にパンダを置く必要があります。これが、動き補償が扱う仕事、つまり動きの検出ですが、この技術を圧縮のために使用するのではなく、収集した情報に基づいて新しいフレームを作成することに利用するのです。その様子を次に示します。

動き補償で 2 FPS から 3 FPS にコンバート:Panda が中央に!

新しいフレームを作って、真ん中にパンダを置いたことに注意してください。

Google Compute Engine などの Google Cloud Platform 製品によって、エンコーディングのパフォーマンスを 30 % 向上させるだけでなく、インフラ基盤から、利用者のイノベーションを促進することへとフォーカスをシフトさせることができました。その際、継続割引を利用することができるため、結果的に契約や予備キャパシティへの署名に煩わされることなくインフラコストを引き下げることができました。またビデオファイルは非常に大きく、頻繁に移動する必要がありますが、Google が持つネットワークのパフォーマンスが助けとなります。我々が Cloud Platform をどう使用しているかについてはこちらのビデオをご覧ください。


Panda は、技術者やデジタル コンテンツ プロバイダーが集う世界最大の集会の一つである、 NAB show に今年参加します。2 階南側のホールにある StudioXperience エリア、SU621 の中で Filepicker と一緒に展示する予定です。


- Posted by Google Cloud Platform Team
Share on Twitter Share on Facebook

iStreamPlanet は、私たちのインフラストラクチャーの広がりを活用して Google ネットワークに高品質な接続を行っているお客様の1つです。先頃、iStreamPlanet は Aventus を立ち上げましたが、SaaS ベースのこの製品により、コンテンツオーナーは高品質なライブビデオをさまざまなデバイスで簡単にユーザーに提供することができます。Google Cloud Platform 上で実行することにより、iStreamPlanet は、お客様に対して数日ではなく数分でライブビデオイベントを作成することができ、Google Cloud Platform の Direct Peering を利用して帯域幅コストを 40 %以上も削減できます。


私たちはまた Google Cloud Platform のテクノロジーパートナーとして CloudFlare を向かい入れました。CloudFlare は、世界的な分散型ネットワークに対するキャッシング ソリューションだけでなく、ウェブサイトのスピード最適化、安全性、DDOS プロテクションを提供します。CloudFlare はほとんど設定をする必要がなく、スピードを最適化し、お客様のコンテンツのロードが平均で 2 倍早くなるという結果を報告しています。


これまで15年にわたって構築されてきた Google のネットワークは成功への鍵であり、検索から Map、YouTube から Google Cloud Platform まで、私たちのお客様やユーザーが毎日のように頼りにしているサービスを支えています。是非こちらからご相談いただき、Google のネットワークをどのように活用できるのかを共に模索し、あなたのユーザーが世界のどこにいようと提供できる具体的なニーズを発見しましょう。Google Cloud Networking についてはこちらで詳しくお読みいただけます。


-Posted by Morgan Dollard, Cloud Networking Product Management Lead
Share on Twitter Share on Facebook

アプリを構築するとき、もっと生産性を高めたいと思うでしょう。皆さんのフィードバックをいただき、そのコメントやアイディアに基づいて、デベロッパー コンソールをより便利で使いやすく、そして美しくするための新しい方法を試験的に開始しました。


まず改善したのは、デベロッパー コンソールのユーザー インターフェース(UI)における無駄なスペースです。UI に取られるスペースが少ないほうが生産性を高めるとの意見がありました。レイアウトを最適化することで、ひと目でより多くの情報をスキャンできるようになります。

この改善で、標準的なノートパソコンで表示される行数はこれまでのおよそ2倍となり、スクロールしなくても見られる情報量が増えたことがわかるかと思います。カラムがすっきりとコンパクトになり、特に多くのカラムが表示される場合により見やすくなりました。他のブラウザ ウィンドウやアプリケーションを開いている場合でもマルチタスクがしやすくなります。


この他にも間隔、フォント サイズ、ボタン、アイコン、その他あらゆる UI の要素を調整し、ログ、インスタンス リスト、コードなど、それに関わらずすべての箇所の確認がより簡単にできるようになりました。


新しいデザインのもう 1 つの利点は、今後のアップデートにより、一連の流れを失うことなく、ページがロードされるのを待ったりすることなく、より多くを見たり作業したりできるようになることです。リソースのリストを参照するときも、リストから離れることなく、すぐにアイテムの詳細を見たり編集したりすることができるようになります。
最終的には、皆さんがもっと楽に仕事ができるように改善していきたいと思っています。Google がコンソールの改善に時間を費やすことで、デベロッパーの皆さんが本当にやりたいこと、つまり素晴らしいものを作りあげ、世に送り出すということにもっと時間をかけられるように。


デベロッパー・コンソールをより便利に使いやすく、美しく精巧にするためのアイディアがあれば、どうぞこちらのフォームでお知らせください。


まだまだこれからも改善を続けます。


-Posted by Matthew Brown, Designer
Share on Twitter Share on Facebook

我々の想定は正しかったのです。Redis なら、クラスタ内に Google Compute Engine サーバがたった 2 台あるだけで一秒あたりのオペレーション数 100 万という閾値を突破することができました。


Redis を Compute Engine 上で使用すれば、一秒あたり 100 万オペレーションを達成するために沢山の cloud サーバは必要ではないのです。一台か、二台、それだけで十分です。
Redis を Compute Engine で利用する方法についてもっと知りたい場合はこちらからどうぞ。

Share on Twitter Share on Facebook

かなり野心的な試みに聞こえますね。世界にインパクトを与えるベンチャーの多くがそうであるように、今回のケースでもキャンペーンを舞台裏で企画しているチームはみなさんが思っているよりもずっと小さいのです。このペースの早い、地球規模のプロジェクトのウェブサイトを担当する開発チームは、何と 2 人。Mukesh Randev と Jonathan Horne の 2 人で、彼らは Adtrak というイギリスのメディア エージェンシーのウェブ デベロッパーです。ノッティンガムから世界を変えようと試みる素晴らしい二人組、は言い過ぎですね、とりあえずウェブサイトをオンライン状態に保とう、と試みたのです。


プロジェクトが立ち上がってから動き出すまでの間はたったの 14 日弱で、その間に起きた変化はめまぐるしいものでした。ロゴは 17 回も変更され、レイアウトとトップのメッセージも頻繁に変わりました。トップページの寄付リンクはアメリカとイギリス用がありましたが、イギリスだけでいいのか?など…。Jonathan がずっと懸念していたのは、このサイトが公開され、合計 1 億を超すツイッターフォロワーを持つアーティスト達が世界中に寄付を呼びかけたとき、トラフィックはものすごい量と早さで押し寄せることでした。


チームは Google Cloud Platform を使っており、まだ使い方には慣れていなかったのですが、負荷に対応できるようにするために、オート スケーリングをどうしても設定したいと考えていました。また、Google DNS を使って、Wordpress をホストしている Google Compute Engine のインスタンスへとトラフィックを促し、MySQL の ローカルインスタンスをデータベースとして使っていました。


標準的なベストプラクティスでは、この種のダイナミックなウェブサイトは「適切」に運営されなければなりません(例えばロードバランサ、レプリカプール、オートスケーラを使い、MySQL を MemCacheD 付きの CloudSQL に移行し、WordPress をパフォーマンスのために設定するなど)そんなとき、ある考えが思い浮かびました。その時の会話はこうです:


Miles:「ダイナミックなもので WordPress を通して処理しているものには何があるんだ?」


Mukesh:「特にはないんだ。支払い処理はオフロードだし、コメントは DISQUS を使ってるけど、レイアウトのためだけだし。それに、そうすれば広告・メディアチームがイベントの当日にアップデートができるしね。」


サイトは全てスタティックだったため、上記全てのサービスを始めから作るかわりに、Band Aid 30 のウェブサイトを Google Cloud Storage にコピーすることにしました。Cloud Storage は、強力な分散エッジルーティングであり、スタティックなコンテンツに対して高いパフォーマンスを誇るキャッシュシステムである Google のフロントエンドと一体化しています。このシステムがどくらいの量のコンテンツをサポートしているか… YouTube、Google Play、Picasa……圧倒的なコンテンツ量になります!


サイトのコピーというと複雑に聞こえますが、そんなことはありません。実際のところ、コマンドライン プロンプトでたったの 3 行です:


//go get my website, make sure you go to an empty folder first
wget --convert-links -q --mirror -p --html-extension --base=./ -k -P ./ http://ipaddressforyourstagingserver

//put that website in the cloud
gsutil cp -R * gs://www.yourrockingwebsite.com

//let everyone read it
gsutil -m acl set -R -a public-read gs://www.yourrockingwebsite.com 


これだけです!どこから見てもシンプルそのものです。


シンプルである、ということはコスト削減にもなるということです。ダイナミックなセットアップ − 明らかにより機能的なセットアップなのですが − は、多数のサイト同時エディタや、データをもとにした機能、より優れたロギングなどを可能なものにしてくれますが、一方で著しく運営費用が高くなってしまいます。これら全てを網羅するとおおよそこのくらいになると考えられますが、そうするとコストは月$10,000 USD を超えてしまいます。

さて、一方で我々が実際に構築したものと比べてみましょう:
そう、たったの $9.17 で(読み間違えではありません)この本番用ウェブサイトを公開日に運営することができ、しかもパフォーマンス上の小さな障害にも、オペレーション上の緊急事態にも一度も遭遇することはありませんでした。


最初に取ろうとしていたアプローチから、実に、99.9% のコスト削減です。Band Aid 30 の他に必要なコストがゼロだったと仮定すると(もちろんゼロではないのですが)、集まった 2,500,000 ポンドの寄付金に対して 40,621,592.14%の投資利益率(ROI)という計算になります。まずまずの出来ではないでしょうか。


Band Aid 30 がエボラ出血熱の被害者の方々のために役立つこと、Mukesh と Jonathan、Adtrak チーム全体が素晴らしい結果を出したこと(それも 14 日以下で)、そして、Google がこうして少しでも協力できたことに、とても嬉しく思っています。


- Miles Ward, Global Head of Solutions, Google Cloud Platform 
Share on Twitter Share on Facebook

数週間前、クラウド上の処理負荷を簡単にベンチマークできる Perfkit を公開しました。その際にもお伝えした通り Perfkit は進化しており、アプリケーションを支えるサーバを増やしていった際に、レイテンシに及ぼす影響を測るためのツールも盛り込むように開発を続けてきました。


我々はこの新しいパフォーマンス ベンチマーク ツールを、Online Data Intensive Simulator または OLDISIM と呼んでおり、スタンフォード大学の Multiscale Architecture and Systems Team (MAST) チームとの共同開発を行っています。このベンチマーク ツールは、Google Search や NoSQL データベースアプリケーションなど、レイテンシに対して要求が高い分散・ファンアウト型の多くの最新のアプリケーションをモデルにしています。


Google 社内でも、ハードウェアとソフトウェア両方の改善において、処理負荷に対するスケールの幅とスケールの効率を計測するために OLDISIM を使っています。スケールアウトが効率化に行えると、可能な限り最小のサーバ数で素晴らしいユーザ体験を提供できるようになり、ユーザの新しいニーズにより一層応えていく事ができるようになります。よりサーバ数を少なく、よりエネルギーを高く、そして、より低コストのソリューションを実現できます。サービスが実際どのようにスケールアウトしていくのかを予測するのは、開発研究の環境では通常とても難しいことですが、下の表で示すとおり、OLDISIM の測定結果と、現状の Google Search のパフォーマンスは、スケーリングの効率において強い相関関係にあることが実験の結果分かっています。

Google のベンチマークに対するニーズは、世の中のインターネット処理負荷のスケールアウトに対する課題に類似しています。我々は PerfKit Benchmarker を通して OLDISIM をオープンソースコミュニティに Apache V2 ライセンスとして公開しています。OLDISIM を使えば、Hadoop や NoSQL 製品を含む殆どのファンアウト・合成型のアプリケーションを、より簡単にモデル化したりシミュレーションできるようになります。それぞれのノードに組み込むワークロードを指定するだけで、スケーリング効率とアプリケーションのレイテンシを測定することができます。

OLDISIM は GitHubインストラクションにあるように利用してもよいですし、PerfKit Benchmarker を使って一般的なクラウドプロバイダ上で実行することも可能です。コマンドは ”pkb.py --benchmarks=oldisim” だけです。


OLDISIM チーム、PerfKit Benchmarker チームともに GitHub であなたのフィードバックをお待ちしております。感想や提案、また問題があればぜひお知らせください。


Happy Benchmarking!


- Posted by Ivan Santa Maria Filho on behalf of the Cloud and Platforms Performance Teams

Share on Twitter Share on Facebook

(写真: 株式会社アイリッジ 開発グループ 開発チーム マネージャー 野口 卓也さん

昨日の会社帰りに訪れた近所のスーパー、あるいは先週末に春物を探しに行った洋服店でもいいでしょう、その店舗の経営者になったと想像してください。集客するにはどうしたらいいか、商品として何を揃えればいいのか、様々なことを考えなければならないわけですが、そのとき Web をどう使いますか?

Web に情報を置いても EC サイトでもなければ集客に役立たないし、実店舗の商品の提供の仕方には関係ないと考えた人もいると思います。しかし、Think with Google で昨年行ったリサーチの中で、例えば以下の様な調査結果が出ています。

  
一方で、特にこれを読んでいる皆さんだと、上記のような状況を想定し、オンラインへ効果的に情報を載せてコミュニケーションしていくことや、オンラインからオフラインへの施策として O2O ソリューション、さらにオムニチャネル化を考えましたよね。今回事例として紹介する株式会社アイリッジさんは、このような O2O ソリューション、特に位置情報との連動にフォーカスした popinfo というサービスを展開しています。既に様々な業種の多くの企業に導入されてる popinfo のバックエンドは Google Cloud Platform が支えています。

popinfo を構築するにあたって、何故 Google Cloud Platform なのか、どのように使っているのか、開発グループ 開発チーム マネージャー 野口 卓也さんにお聞きしました。

O2O のトータルソリューションとしての popinfo


popinfo は、どういうサービスなんですか?

O2O ソリューション全体を通じた総称です。クーポン、スタンプラリー、ゲーム、アナリティクス、システムの連携や導入企業へのコンサルティングも含めたトータル ソリューションとして、お客様にあわせ、スマートフォンを接点とした集客や販促を実現しています。

会社の名前も最近よく耳にします

資金調達をして知名度が上がったり、純粋に導入が増えたこと。それに、昨年より準備を進めてきた「デジタルマーケティングクラウド」で Japan-UK Tech Awards を受賞したこと、代表の小田が Morning Pitch に出たり、様々な企業との提携が進んだことによるものだと思います。

その中で、野口さんはどういう仕事をされているのですか?

開発をしているグループが 20 人程いて、そのグループで幅広くアーキテクチャの設計、開発、運用と、その導入プロジェクトの推進、新規事業開発をしています。また、開発効率の向上のため、開発手法の導入や社内 IT 全般も見ていますし、主要プロジェクトのパフォーマンスとセキュリティを中心に改善も行っています。その中でも、新規事業を担当しています。2 月にリリースした、スマートフォンでの決済サービスのシーレス(C-less)の開発に携わったりであるとか、O2O を導入してどれくらい効果があったか、One-to-One でよりパーソナライズされた顧客体験を実現するようなビックデータ解析の領域や、それをビジュアライズするようなソリューションの開発を進めています。

新しいアーキテクチャーへの移行


Google Cloud Platform は、どう利用していますか?

Web アプリケーションは主に GAE にホスティングしています。ビッグデータの保存と解析に Cloud Storage と BigQuery という利用が多いです。新規のサービス、popInfo の中のサービスの開発に Docker を使って作っていて、そこで今は Compute Engine を使っています。まだアルファなのでプロダクションでの展開はありませんが Container Engine への移行も検討しているところです。また、現在、アルファ版として提供されている Cloud Dataflow の検証(Java SDK)も進めています。弊社の主要言語はPython ですので、SDK for Python の提供を心待ちにしています。

その中で、会社としてインフラ担当がインフラを見るというような体制にはしていなくて、インフラ全体を広く見ていくという仕事も担当しています。オンプレミスからクラウドだったり、AWS から Google Cloud Platform への移行も進めています。

移行を進めている理由は?

数百インスタンスという規模になったときに費用が嵩んでしまうことが課題で、まずは AWS で最適化を行いましたけど、それでも効率良くはならなかった。それに前金で払わないと安くならないという課題もあって。

また、アーキテクチャが古く、昔からある部分を残して、その上に互換性のある新しい機能が出てくるとレガシーな部分が残ってしまう。レガシーのないものを使いたいというのもあります。AWS が東京にデータセンターを作る前から US のリージョンを使っていて、平行して App Engine を使っていたので、その AWS の部分の移行を進めています。

また、新規に開発を進めた「スマートフォンでの決済サービスのシーレス(C-less)」では初めから Google Cloud Platformを利用することにしました。

App Engine ではなく Compute Engine を使うこともあるそうですが、使い分けはどのように?

お客様によっては、オンプレミスの考え方を持っている方からすると PaaS サービスの従量課金が理解されづらくて、コスト感をわかりやすくするために Compute Engine を使うことがあります。

プロダクションレベルではまだかもしれませんが、コンテナ テクノロジーを利用しようとしている理由はなんですか?

サーバを見なきゃいけないエンジニア、専属のインフラエンジニアがいないので、運用のコストが高くなっているので、より運用がしやすく、自動化できるように。また、捌き切れない仕事を外部の協力会社にお願いすることがあるのですが、運用していく中で不具合があると対応できなくなりがちなので、それをアプリケーションだけじゃなくて OS 含めた全体を納品してもらうことで、問題を特定しやすくし、全体の運用を効率化できるので。

BigQuery はどのように、何に使っているのですか?

今だと、popinfo の中で提供しているモバイル SDK からのデータを蓄積し、その利用のされ方を解析しています。アプリ内で収集されたイベントログと、位置情報、iBeacon のチェックインのログであるとかのデータ集計ですね。BigQuery へのデータ送信は fluentd を使い、BigQuery で集計したデータのビジュアライズに、独自で作成したものと、Tableau を使っています。

これらのバックエンド システム以外にも iOS、Android のアプリや SDK も含めていろいろな開発進めていると思うのですが、開発はどう進めているのですか?

チーム毎にやり方は柔軟に対応するようにしていて、クライアントに対してソリューションを提供しているようなときは、ウォーター フォールになることが多いです。自社でのサービス開発については、Scrum で進めています。

使っているツールもプロジェクト毎に違うのですか?

そうですね。イシュー管理もそれぞれで、エンジニア主導なケースは GitLab issues で、クライアント・プロジェクトマネージャー主導のプロジェクトでは、Backlog.jp や Redmine を使い分けています。ソース コード管理は GitLab を社内で持っていて、使いたい人がいれば使います。コミュケーションには、Skype と Slack を使っていて、Slack は自動的にシステムと連携する部分でうまくいっているので、人対人はSkype、人対ソフトウェアは Slack という形ですね。

O2O のこれからと、バックエンド システムのこれから


オンライン、オフラインも人が活動する場所である以上、区別する必要はなく、O2O も一過性の流行ではなく、ショールーミング、オムニチャネル化も含め当たり前のことになると思います。今後どうなっていくと考えていますか?

今までのO2Oだと、スマートフォンや PC に対する取り組みから実店舗に誘導する、という面が強かったところがあります。そうではなく、オンライン、オフラインを統合してのユーザーの体験を向上する方向に向かうと思っています。O2O ソリューションもそういう方向に発展していくと思っていて、例えば弊社の開発したシーレスは決済の体験を向上させるもので、その他広告も、もっとユーザーが必要としていることが必要なときに届くようになる。そういった方向から弊社も決済事業と広告事業を進めています。

バックエンド システムでは、先ほどコンテナの利用についてお伺いしましたが、コンテナは今後主流になっていくと思いますか?

デプロイのスピードを考えても、なると思いますね。サーバの仮想化がさらにもう 1 次元高レベルになるものだと思っているので。広がるまでには、もう少し時間がかかると思っていますが。

最後に、今後 GCP に期待していることを教えてください。

MySQL を中心に使っているので、Cloud SQL ですね。もっと発展してほしい。それと、日本にデータセンターがあると安心だという声も多いので、国内にデータセンターが欲しいです。実際、直接対応しているクライアントだと問題ないのですが、間に SIer さんに入ってもらっている案件では、それが求められるときがあります。



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


アラートを取得してインシデント管理をしよう

例えば Google Compute Engine のインスタンスが、想定 CPU 負荷の 50% を一時間超えてしまった場合など、問題が起きたときにお知らせを受け取れたら? Android 用 Cloud Console は、Cloud Monitoring とも一体化しているので、システムの数値が基準から逸れたときには、自動でインシデントをトラッキングします。アラートの表示はAndroid のお知らせドロワーから直接設定ができますし、コメントもできるのであなたがもう既に問題に取りかかっていることもあなたのチームメンバーに共有できます。

App Engine と Compute Engine のプロパティをチェックし、素早く変更を加える

障害を調査しているときは、実行状態やゾーン、または IP など、リソースのヘルスとプロパティをチェックしなくてはならないことが多いですよね。本アプリは、App Engine と Compute Engine のインスタンスの詳細を閲覧したりグラフを監視できるようになっています。また、App Engine のバージョンを変更したり、Compute Engine のインスタンスの起動や停止したりといったオペレーションを行うこともできます。

早速始めよう

本アプリは Google Play Store からダウンロードできます。アプリの設定のコツについては、こちらのガイドを参考にしてみてください。

フィードバックお待ちしています

Android 版 Cloud Console は現在ベータ段階で、iOS 版アプリは年内にリリース予定です。この先も新機能追加や、現状ある問題の解決に引き続き取り組んでいきます。これからの開発に一石を投じるには、あなたのフィードバックやアイデア、提案を [email protected] まで送ってください!


- Posted by Michael Thomsen, Product Manager
Share on Twitter Share on Facebook

また起動時にソフトウェアをインスタンスに設定しインストールするのに使う Chef  と Compute Engine の起動スクリプトの使い方も学んで頂くこともできます。他にも便利な技術的ナコンテンツが沢山ありますので、こちらの記事や、GitHub project page も(このページでは前述のチュートリアルが閲覧可能で、Issue のセクションでは質問をしたり提案をすることもできます)チェックしてみてください。早速、よりスケーラブルで障害耐性のあるアプリケーションを構築をはじめましょう。


-Posted by Evan Brown, Solutions Architect


Share on Twitter Share on Facebook