番組で説明した資料はこちらで公開しています。



Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。

※この投稿は米国時間 2019 年 2 月 1 日に Google Cloud blog に投稿されたものの抄訳です。

現代のエンタープライズ開発では、組織内外のデベロッパーにサービスをエクスポーズできる API の構築が本質的に重要です。ただし、単に API を作成するだけでは十分ではありません。API と API プログラムの市場への投入が成功するかどうかは、デベロッパーに働きかけてそれらを実際に使ってもらえるかどうかにかかっています。社内や外部のさまざまなデベロッパー コミュニティにおいて、API の採用や利用をデベロッパーに促すうえで決め手となるのが、デベロッパー ポータルです。

企業が取り組むデベロッパー エクスペリエンスの構築を支援するため、私たちはこのほど、Apigee Developer Portal にいくつかの改良を加えました。このポータルは、Google Cloud の Apigee プラットフォームで管理される API を使用するデベロッパーと管理者を対象にしており、API プロバイダーが彼らに対してシームレスなオンボーディングを行うのに役立つ包括的でカスタマイズ可能なソリューションを提供します。同ポータルの今回のアップデートに含まれる内容は以下のとおりです。
  • SmartDocs API リファレンス ドキュメントの新バージョン
  • 改良されたテーマ エディタと再設計されたデフォルト ポータル テーマ
  • デベロッパー アカウント管理の向上

SmartDocs

Apigee の SmartDocs はデベロッパー向けの見やすい API リファレンス ドキュメントを自動的に生成しますが、今回のアップデートで、このドキュメントが新たに 3 ペイン表示になりました。左ペインでは API ドキュメントのさまざまな領域をナビゲートでき、中央ペインは特定のオペレーションの詳細なドキュメントを提供し、右ペインではドキュメントから API リクエストを直接作成できます。右ペインには、API リクエストの詳細を確認する際に便利な “expand” ボタンも用意されています。

ドキュメントは OpenAPI 仕様に基づいて生成され、同仕様の Versions 2.0 と 3.0.x をサポートします。OpenAPI 仕様で定義されているすべてのオペレーションごとにそれぞれ専用のページが設けられているため、ユーザーはドキュメントの特定の領域をシェアしたり、それらについて議論したりすることが簡単にできます。API チームも、ユーザーに必要なコンテンツへのディープリンクを容易に設定できます。

テーマ エディタ

SmartDocs とともに、デフォルト テーマについても、Google の Material Design ツールキットを使って再設計されました。テーマ エディタ(ポータル テーマの作成に使用する統合ツール)は新たに SCSSAngular Material Themes をサポートし、これによって変数やルールなどの強力な機能が導入されました。


アカウント管理

Apigee Developer Portal の最新リリースでは、デベロッパーによるアカウントの作成と管理の方法が改良され、デベロッパー ポータルのユーザーを管理するための新しいビューも管理者に提供されるようになりました。API プロバイダーは、API ポータル管理インターフェースのユーザー リストを使って、すべての登録済みユーザー アカウントの表示や管理を行ったり、新しいユーザー アカウントの自動承認または手動承認を設定したりすることができます。また、この新しい管理ビューを介して、すべての登録済みユーザー アカウントの詳細を確認したり、カスタム アカウント登録フィールドを表示したり、ユーザー アカウントの承認やブロック、削除を行ったりすることも可能です。

今すぐ始めましょう

優れたデベロッパー エクスペリエンスを構築する方法の詳細については、Apigee の eBook『Creating World-Class Developer Experiences』をご覧ください。

すでに Apigee Edge クラウドをご利用のお客様は、最新のドキュメントをご覧のうえ、新しい Apigee Developer Portal をお使いください。最新ドキュメントには、機能の包括的な概要やガイド付きのチュートリアル、FAQ などが記載されています。

Apigee Edge をまだご利用でない方は、こちらから無料でお試しになれます。

- By Marsh Gardiner, Product Manager, Apigee

※この投稿は米国時間 2019 年 2 月 1 日に Google Cloud blog に投稿されたものの抄訳です。

アプリケーション開発の潮流がインフラストラクチャ管理からサーバーレスへと移りつつある中、私たちはサーバーレスの NoSQL ドキュメント データベースである Cloud Firestore の一般提供を開始しました。データベースのロケーションとして従来の 3 つに 10 の新ロケーションを追加したほか、リージョン インスタンスの料金を大幅に値下げし、Stackdriver と連携したモニタリングにも対応しています。

Cloud Firestore は、ウェブ、モバイル、IoT の各アプリケーションでデータの格納や同期、クエリを簡単に行えるようにするフルマネージドのクラウドネイティブ データベースです。ライブ同期、オフライン サポート、数百ものドキュメントとコレクション全体にわたる ACID トランザクションにより、優れたデベロッパー エクスペリエンスを提供し、アプリケーション開発を簡素化することに重点を置いています。

Cloud Firestore は Google Cloud Platform(GCP)と Firebase(Google のモバイル開発プラットフォーム)の両方と統合されています。その詳細はこちらをご覧ください。データベースのセキュリティ ルールが柔軟で、リアルタイム処理にも対応し、インフラストラクチャを完全な形で自動スケーリングする Cloud Firestore を使用すれば、すぐに本番環境に移行できるアプリケーションを構築できます。

しかも、Cloud Firestore が提供するのはデータベースのコア機能だけではありません。Cloud Firestore は、セキュリティと承認、インフラストラクチャ、エッジ データ ストレージ、同期処理を提供する完全なデータ バックエンドとして設計されています。アプリケーションとそのデータのセキュリティ確保を目的に、IAM と Firebase Auth も組み込まれています。また、Cloud Functions、Cloud Storage、Firebase SDK との密接な統合により、エンドツーエンドのサーバーレス アプリケーションをシンプルかつスピーディに開発できます。データの強力な分析や後処理、機械学習のためにデータを BigQuery にエクスポートすることも簡単です。

Cloud Firestore を使って開発されたアプリケーションは、ネットワークのエッジでオンラインとオフラインをシームレスに切り替えることができます。これは、コードの簡素化とエラーの削減に役立ちます。Cloud Firestore を導入すれば、インフラストラクチャのセットアップやメンテナンスの必要なしに、リッチなユーザー エクスペリエンスを提供しながら百万以上のクライアントにデータ更新をプッシュできます。

Cloud Firestore の強整合性保証には、コードの複雑化を抑え、バグを削減する効果があります。エンタープライズ級のセキュリティが組み込まれているため、クライアント側のアプリケーションが直接データベースとやり取りすることも可能です。他の多くの NoSQL データベースとは異なり、Cloud Firestore は一度のトランザクションで 500 までのドキュメントとコレクションを更新でき、しかもワークロードに合わせて自動スケーリングを行います。

Cloud Firestore の新トピック

  • リージョン インスタンスの新料金 : この新料金は、ほとんどのリージョン インスタンスで 2019 年 3 月から有効になり、マルチリージョン インスタンスの料金よりも 50 % 安くなります。
    • リージョン インスタンス内のデータは、同一リージョンにおける複数のゾーン間でレプリケートされます。これは、コストと書き込みレイテンシを低く抑えた形で最適化するためです。データベースの可用性と耐久性を最大限に引き上げたい場合は、マルチリージョン インスタンスの使用をお勧めします。
  • SLA の適用 : SLA が適用されるようになりました。マルチリージョン インスタンスで 99.999 %、リージョン インスタンスで 99.99 % の可用性が保証されます。
  • ロケーションの新設 : Cloud Firestore のロケーションが 10 か所新設されました。
    • マルチリージョン
      • ヨーロッパ(eur3)
    • 北アメリカ(リージョン)
      • ロサンゼルス(us-west2)
      • モントリオール(northamerica-northeast1)
      • 北バージニア(us-east4)
    • 南アメリカ(リージョン)
      • サンパウロ(southamerica-east1)
    • ヨーロッパ(リージョン)
      • ロンドン(europe-west2)
    • アジア(リージョン)
      • ムンバイ(asia-south1)
      • 香港(asia-east2)
      • 東京(asia-northeast1)
    • オーストラリア(リージョン)
      • シドニー(australia-southeast1)
Cloud Firestore は 13 のロケーションで使用できます

  • Stackdriver 連携(ベータ): Cloud Firestore での読み込み、書き込み、削除の各操作を Stackdriver でほぼリアルタイムにモニタリングできるようになりました。
  • 近く提供されるその他の機能 : コレクションの境界を越えた形でのドキュメントへのクエリ、トランザクションを必要としないデータベース値のインクリメントなど、デベロッパー コミュニティから強い要望が寄せられている機能の開発を進めています。

Cloud Datastore の次の世代では、すべての API とクライアント ライブラリが Cloud Firestore と互換になります。既存の Cloud Datastore ユーザーは 2019 年の後半に、Cloud Firestore に自動的にライブ アップグレードされます。詳細はこちらをご覧ください。

業界の違いを超えた柔軟性とスケーラビリティ

Cloud Firestore は、メディア、IoT、運輸、デジタル広告、不動産、その他多くの業界で、企業によるアプリケーション構築の方法を変えつつあります。これらのワークロードの共通テーマは、接続が失われたときでも使用できるモバイル サポート、膨大なユーザーに対応できるスケーラビリティ、プロトタイプから本番へのスピーディな移行です。以下では、Cloud Firestore のお客様からお聞きした話をいくつか紹介しましょう。

チャンスを逃さない開発

自動車、バイク、スクーターをシェアして使用するオンデマンド モビリティという競争の激しい世界では、ユーザー エクスペリエンスの差別化や迅速なイテレーション、スケーリングが必要不可欠であり、それを実現したときの成果は絶大です。Skip は、そうしたスピーディなリリースが大きな意味を持つスクーターのシェアリング システムを提供しています。同社の共同設立者で CTO の Mike Wadhera 氏は、「Cloud Firestore のおかげで、当社のエンジニアリングと製品チームは、Google レベルのインフラストラクチャを利用しながらスタートアップ レベルの速さで製品をリリースできるようになりました。Firebase への継続的な投資と、広範な GCP プラットフォームに満足しています」と述べています。

別の Cloud Firestore ユーザーである IT コンサルタント会社の The Nerdery は、高品質のシステムを短期間で供給することに加えて、既存のサードパーティ製データソースを統合する必要に迫られることがよくあります。しかし、開発するすべてのクライアント アプリケーションのために複雑でコストのかかるインフラストラクチャをいちいち構築、解体しているわけにはいきません。同社の主任ソフトウェア アーキテクトである Jansen Price 氏は、Cloud Firestore を導入した理由について次のように述べています。「Cloud Firestore は、私たちが作ったウェブとモバイルのアプリケーションにぴったりでした。何しろ、4 万人以上のエンドユーザーにリアルタイムでデータ更新を通知し続けるようなソリューションが必要だったのです。Cloud Firestore は、信頼性とスピードに加え、リアルタイム処理に秀でており、Google Cloud Next カンファレンスに向けてすばらしい製品を作ることができました。」

信頼性の高い情報提供

インシデント管理会社の Now IMS は、需要の増大によってモバイル通信が寸断されるような混雑した場所で人々の安全を守るためにリアルタイム データを活用しています。共同設立者の John Rodkey 氏は、「インシデント管理を扱う以上、私たちのお客様にとってリアルタイム処理とオフライン機能は最重要課題です」と述べたうえで、そうした機能を Cloud Firestore と Firebase JavaScript SDK がすぐに提供できることを高く評価しています。「Google Cloud 上で動作するこの 100 % サーバーレスのアーキテクチャにより、お客様のニーズに合わせてスピーディにアプリケーションを開発することに専念できるようになりました。以前のクラウドのようにインフラストラクチャやサーバー管理について心配する必要はもはやありません。」(Rodkey 氏)

どのようなアプリケーションであっても、更新ボタンのクリックなしに最新情報が得られることをユーザーは望んでいます。QuintoAndar のモバイル アプリケーションは、ブラジルの借主と大家を結び、アパート賃貸契約の締結を円滑化しています。「絶えず変化する情報をお客様に提供できることが、このアプリケーションの優れた点です。Cloud Firestore のおかげで新たなインフラストラクチャが不要になり、ビジネスの中心的な課題に専念できるようになりました。」(QuintoAndar のエンジニアリング マネージャー、Guilherme Salerno 氏)

リアルタイムできびきびと反応するアプリ

著名な新聞の発行元でメディア企業でもある Telegraph は、Cloud Firestore を使用して、登録ユーザーがコンテンツを簡単に見つけて読めるようにしています。同社は、数百万もの同時アクセスに耐えられるデータ管理基盤の専門知識を得ることよりも、ユーザー エクスペリエンスの向上に力を注ぎたいと考えていました。ソリューション アーキテクトの Alex Mansfield-Scaddan 氏は、「Cloud Firestore を使用すれば、パーソナライズされたニュース フィードをリアルタイムで作成し、そのユーザーのすべてのデバイスでコンテンツの同期をとることができます。当社のエンジニアリング チームは、リアルタイム データベースとインフラストラクチャのエキスパートになるのではなく、読者が気持ちよくサイトを使えるようにすることに専念しました」と述べています。

大西洋を挟んだ対岸では、New York Times が 2018 年の冬季オリンピック開幕を前に、Cloud Firestore を使用したリアルタイム更新のプッシュ通知機能をモバイル アプリケーションの The Times に追加しました。この機能自体は以前から備わっていましたが、Cloud Firestore の導入前はスケーリングに難点がありました。それぞれの読者のアクセス履歴を追跡し、適切な種目や試合のコンテンツを配信することが求められましたが、Cloud Firestore の導入により、動的にクエリを発行して、更新情報をリアルタイムで読者に送れるようになりました。従来よりもターゲットを絞り込んだコンテンツをすばやく送れるようになったのです。

IoT デバイスのための強力なエッジ ストレージ

アスリートの運動能力の計測技術を提供する Hawkin Dynamics は、プレベータ時代から Cloud Firestore のアーリー アドプターです。同社の圧力パッドは選手の身体能力を計測して管理することができ、多くのプロスポーツ チームで使用されています。ペースが速く、しかも大金が動くプロスポーツの世界では、選手はデバイスの接続や結果の計算をのんびりと待つようなことはしません。Wi-Fi が一時的に落ちていても、すぐに結果を知りたいと考えます。そこで Hawkin Dynamics では、下図のようなダッシュボードを使用して、選手にデータをリアルタイムで提供しています。

同社 CTO の Chris Wales 氏は、「当社の重要なミッションの 1 つは、監督やコーチが、選手に関する詳細な情報を得たうえで決断を下せるようにすることです。リアルタイム更新により、監督やコーチは、選手のトレーニングを調整するために必要なデータを随時入手することができます」としたうえで、Cloud Firestore の優位性について次のように述べています。「Cloud Firestore の強力なクエリ機能のおかげで、トレーニング プログラムの全体的な有効性を評価するために必要な情報についてもお客様に提供できるようになりました。Cloud Functions や他の Firebase 製品と緊密に統合されているので、私たちは絶えず製品を改良し、お客様のニーズに応えることができます。変化が激しい業界で常にリードを保っていられるのは、Cloud Firestore によってアプリケーションを柔軟に拡張できるからです。」


Cloud Firestore をお試しください

Cloud Firestore の導入により、リアルタイム データ処理とデータの同期が簡素化され、サーバーサイドのコードがなくなり、柔軟でありながらセキュアなデータベース認証ルールを設けることができるようになりました。お客様からは、開発における最もタイムリーな課題を解決できたとの評価を数多くいただいています。このことは、最新のユーザー エクスペリエンスを提供しつつ、より良い製品のスピーディな開発に向けてさまざまな選択肢を模索している現在のクラウド アプリケーション市場の状況を反映しています。Stack Overflow の質問数を示す次のグラフにも、こうしたトレンドの一端が現れています。これを見ると、クラウド データベースの中で Cloud Firestore がホットなトピックになっていることがわかります。

Source : StackExchange

ベータ リリース以来、構築された Cloud Firestore データベースは 100 万近くに上っています。このプラットフォームは、数キロバイトから数ペタバイトまでのさまざまなデータベースに対応できるように設計されています。Cloud Firestore 上では、1 つのアプリケーションだけでも毎秒百万以上のリアルタイム更新をユーザーに送信しています。とはいえ、こうしたアプリケーションはほんの始まりにすぎません。サーバーレス アプリケーション開発について詳しく学びたい方は Global Digital Conference のアーカイブをご覧ください。

皆さんからのご意見、ご感想をお待ちしています。皆さんが開発されたシステムのことも、ぜひお聞かせください。皆さんのアプリケーションで今すぐ Cloud Firestore をお試しください。

- By Amit Ganesh, VP Engineering and Dan McGrath, Product Manager

※この投稿は米国時間 2019 年 2 月 21 日に Google Cloud blog に投稿されたものの抄訳です。

ハイブリッド クラウドの採用を検討したことがある方なら、通常 1 つのクラウド ベンダーを選定し、新しいハードウェアを購入し、既存のオンプレミス環境の統合という難題に挑むことだとお考えでしょう。私たち Google Cloud のアプローチは違います。ソフトウェア ベースのハイブリッド プロダクトを提供し、Kubernetes と Istio のパワーを活用してオンプレミスのインフラストラクチャに Google Cloud のサービスを導入するのです。つまり、あなたがいる場所にクラウドがやってくるというわけです。

私たちは昨年の Google Cloud Next で Cloud Services Platform(CSP)のビジョンを発表しました。そしてこの度、その CSP がベータ版としてご利用いただけるようになりましたことを発表いたします。CSP はオンプレミスとクラウドの両方において、サービスの構築、実行、管理をシンプルにする新しいプラットフォームです。オープンな API で構成していて、コンプライアンスに適合した、より着実なアプローチになっています。また、CSP は自社のペースでアプリケーションをモダナイズする自由をもたらし、イノベーションを加速させ、運用のセキュリティとガバナンスを向上させます。すでに私たちのお客様は、CSP を活用し、自社のデータセンターで稼働しているアプリケーションのモダナイゼーションに取り組んでいます。今後何年にもわたり CSP はエンタープライズ アプリケーションのデプロイ プラットフォームであり続けると、私たちは確信しています。

GKE On-Prem による適切な場所でのモダナイゼーション

多くの皆さんにとって、ここでのモダナイゼーションは、クラウドネイティブなツールと開発スタイルを導入しつつ、既存のオンプレミス環境とクラウド インフラストラクチャの舵取りを行うことを意味します。

CSP は、高度なセキュリティと自動化を備えた業界トップクラスのマネージド Kubernetes サービスである Google Kubernetes Engine(GKE)をベースにしています。また、CSP には、リモート ライフサイクル管理によってオンプレミス クラスタを常の状態かつ安全に保つマネージド Kubernetes サービス、GKE On-Prem も含まれます。GKE On-Prem は、Google が有する Kubernetes 関連の専門知識と Kubernetes の豊かなエコシステムをデータセンターに提供し、既存のハードウェアで稼働するので時間とコストを節約できます。コードは一度書けばクラウドかオンプレミスにデプロイするだけで済み、そのためのプラットフォームは環境全体で統一されています。しかも、CSP は既存のネットワーキング、ストレージ、ID 管理の統合が可能なため、十分に準備を整えてからクラウドに移行できます。

セキュリティとコンプライアンスを自動化する CSP Config Management

ハイブリッド環境では、セキュリティとコンプライアンスを一元的なポリシーに適合させることは容易ではありません。開発スピードを損なうことなく、アプリケーション全体にわたって制御を適切に行いながら、セキュリティ ポリシーとコンプライアンス ルールを規模を拡大して適用できるようにする必要があるためです。

今回新たに導入した CSP Config Management を利用すれば、“Single Source of Truth”(信頼できる唯一の情報源)を基に、ロール ベースのアクセス制御とリソースのクォータを設定、強制して名前空間を作るマルチクラスタ ポリシーを作成できます。また、オンプレミスかクラウドかを問わず、すべてのクラスタに統一構成をすばやくデプロイすることも可能です。CSP Config Management は、CSP 環境を自動的にモニタリングして、望ましい状態からの逸脱を招く変更を検出するとともに、未承認の変更の阻止や、想定外の変更に対するアラートを行い、ポリシーの適用、セキュリティ、管理、モニタリングを簡単かつ普遍的なものにします。

それだけでなく、CSP は Istio ともうまく連携します。サービスの手前にプロキシを追加すれば、それがポリシーを徹底させるためのスケーラブルな基盤となり、サービスが信頼を確立するのを助け、コードの書き換えを必要とせずにトラフィックを暗号化します。

一度構築すれば、場所を問わず管理やデプロイが可能に

私たちがクラウドのメリットをオンプレミスのシステムにもたらすことで、環境全体にわたって一貫したエクスペリエンスを実現すれば、お客様の運用チームは作業効率が大幅に向上し、よりイノベーションに重点を置けるようになります。

CSP は、サービスをどこでも実行できるようにするだけでなく、環境全体で何が起きているのかを知るために必要な可視性も提供します。Stackdriver Monitoring と Istio のポリシー管理機能との組み合わせは、オンプレミスとクラウドの両方にまたがる単一の管理コンソールを可能にします。また GCP Marketplace を利用すると、オープンソースまたは商用のさまざまなエンタープライズ Kubernetes アプリケーションを構築済みのデプロイ テンプレートから構築でき、ライセンス契約をシンプルかつ一括請求にできます。この一貫した管理コンソールにより、よりよい DevOps を実践できるようになる一方で、SRE にフォーカスしたのモニタリング ツールを利用すればサービスレベル通信の可視性が向上します。

CSP : より生産的な組織へ

CSP は、IT チーム全体の作業効率を高めるアドオン ツールによって、組織の生産性向上を可能にします。IT 運用部門にとって、複数の環境にまたがるアプリケーションとサービスを統一的に管理するプラットフォームは大きなメリットとなります。一方、開発部門は、コンテナとマイクロサービスをベースとするスケーラブルで効率的なアプリケーションをセキュアに構築できる基盤が手に入ります。さらに、セキュリティ部門では、ソフトウェア サプライチェーンの安全を保障し、実行時セキュリティを向上させる統一的なツール セットを得ることができます。私たちは、CSP によるシステムのモダナイゼーションとハイブリッドの実現という目標に向け、お客様と密接に協力しています。

米国最大の銀行の 1 つである KeyBank は、Kubernetes と Istio のメリットを自行のデータセンターに取り入れるために CSP を選択しました。

「Kubernetes と Istio を作ったのは Google であり、それゆえ、コンテナ化されたアプリケーションをデータセンターに導入するときのパートナーは彼ら以外にありえませんでした。ひと言で言えば、Cloud Services Platform は、私たちが必要とするセキュリティ、欲しいと思うポータビリティ、開発者が期待するする生産性を与えてくれます。」(KeyBank の CTO、Keith Silvestri 氏)

一方、Arctiq のようなパートナー企業は、顧客のシステムのスピーディなモダナイゼーションとイノベーションのために CSP を活用しています。

「一部の大手顧客のアプリケーションを共同でモダナイズするために CSP を使っています。規制のある業種のお客様や政府機関の場合、既存のデータセンターでアプリケーションを実行し続けながらクラウドのメリットも同時に多く手に入れられるようにすることで、組織内のコンプライアンスや規制の要件を従来と同様に満たすことが可能となり、リスクが軽減されます。CSP は、機密性の高いワークロードについては GKE On-Prem でオンプレミスに残し、その他の戦略的なアプリケーションはクラウドの GKE で運用するという柔軟性を与えてくれます。」(Arctiq のパートナー、Kyle Bassett 氏)

CSP は、ビルド、デプロイ、モニタリングの各ツールと連携して開発スピードを高める最新の DevOps 環境の提供という、私たちのハイブリッド戦略の根幹を担うプロダクトです。CSP のビジョンを詳しく知りたい方は、Eric Brewer と Jennifer Lin が執筆したホワイトペーパー『Application Modernization and the Decoupling of Infrastructure, Services and Teams』(英語のみ)をご覧ください。

- By Eyal Manor, Vice President, Google Cloud


2018 年 10 月で 10 周年を迎えた、国内モバイルゲーム サービスの雄、コロプラ。現在、137 タイトルほどのゲームを提供しているという同社が、昨年夏からサービスのバックエンドを Google Cloud Platform(GCP)に移行しています。そこにはどのような狙いがあるのでしょうか。Kubernetes Engine(GKE)や、Cloud Spanner などの活用法についてもお伺いしてきました。



利用している Google Cloud Platform サービス
Google Kubernetes EngineCloud SpannerGoogle Cloud StorageGoogle Cloud Load BalancingGoogle BigQueryGoogle StackdriverStackdriver Error ReportingContainer Registry など

写真左から

  • 取締役 CCO クリエイティブ本部長 菅井 健太氏
  • クリエイティブ本部 第1エンジニアリング部 第4グループ  粟田 大樹氏
  • 業務推進部 インフラグループ 第2チーム リーダー 邵 正氏
  • 業務推進部 インフラグループ マネージャー 實方 和幸氏
  • 業務推進部 インフラグループ 第2チーム  奥村 開里氏

株式会社コロプラ

創業社長である馬場 功淳氏が、大手ゲーム開発会社在職中に立ち上げた、携帯電話向け位置情報ゲーム『コロニーな生活』事業を法人化する形で 2008 年に創業。2011 年からスマートフォンゲーム開発にも進出し、現在は『クイズRPG 魔法使いと黒猫のウィズ』(2013 年~)、『白猫プロジェクト』(2014 年~)など、多くのヒットタイトルを擁する。従業員数はグループ全体で 1,283 名(2018 年 9 月末時点)。約 7 割がクリエイター職であり、そのうち、約 250 名がエンジニア職となる。

既存ゲームタイトルすべてを GCP へ移行させ、2~3 割のコスト減に成功

ゲームに限らず、多くのウェブ サービスにおいて、クラウド プラットフォームの移行(乗り換え)には絶大な負担がかかります。24 時間絶え間なく、大量のアクセスを高速にさばかねばならないモバイルゲーム サービスではなおさらです。そのため、多くの場合、既存タイトルはそのままにしておき、新規タイトルから新しいプラットフォームを採用していくというのが "無難" なやり方とされてきました。

しかし、そんな中、コロプラはあえて、既存タイトルすべての GCP 移行を決定。その理由について、同社インフラグループ マネージャーの實方(じつかた)さんは次のように説明してくださいました。

「移行した最大の理由はコストです。それまで使っていたパブリック クラウドから、サービスを GCP に移管するだけで、標準料金ベースで 2~3 割のコスト減が期待できたため、すべてのタイトルを GCP に移行させることにしました。2017 年 9 月から切り替えを開始し、2018 年 11 月時点で、すべてのタイトルの移行が完了しています。もちろん、大変な作業だとは分かっていたのですが、実はその数年前にオンプレミス環境からパブリック クラウドへの大規模移行を経験していたこと、普段からデータベースの切り替えなどをカジュアルにやっていたことなどもあり、一応の手法は確立していました。インフラ エンジニアもサーバー エンジニアも勘所を掴んでいて、社内にナレッジが蓄積していたんです。」(實方さん)

「実は数年前に、既存クラウド サービスと GCP のマルチ クラウド化を検討したことがありました。分散させることで可用性を高めようという狙いがあったのですが、オペレーションコスト、管理コストなどを考えると分散させる方がリスクが大きく、我々に合わないという結論に達しています。今回、GCP に一気に寄せてしまおうと考えたのもそれが理由の一つですね。」(菅井さん)

特筆すべきは、この移行作業を、ゲームサーバーを止めることなく行ったこと。システムの大規模改変では珍しくない長時間メンテナンスどころか、サービスの瞬断すらなかったというのだから驚かされます。

「コロプラは、ユーザーさまがいつでも好きなときにゲームを楽しめるよう、ノーメンテナンスを運用ポリシーとして掲げています。今回も、そこで培ったノウハウが役立ちました。」(菅井さん)


なお、移行に際しては、事前に GCP 上にテスト環境を構築してパフォーマンス テストを実施し、その処理能力などまったく問題ないことが判明。安心して進めることができ、また 2016 年に GCP 東京リージョンができていたことも決定を後押ししたそうです。

「移行開始から 1 年以上が経過しましたが、全体的に見て、コストは想定通りに削減できていると評価しています。また、移行開始後にスタートした新タイトルでは、Google 自慢のマネージド サービスを積極的に利用。より一層のコスト減ができました。」(實方さん)

「今後はさらにコストを削減していきたいですね。」(菅井さん)

GKE と Cloud Spanner が、モバイルゲーム サービス運用を「革命的」に改善

既存タイトルの GCP 移行は、コロプラの GCP 活用において、言わば序章にすぎません。それが無事完了した現在は、さらなる GCP 活用を企図した第 2 章がスタートしています。ここでは主に、2018 年の夏以降にスタートした新規タイトルへ GKE と Cloud Spanner を活用しているそうです。

「コロプラでは少ない人数で運用を行っており、一人ひとりが複数のシステムをメンテナンスしていました。実はここに限界が見えてきていて……今回の GCP 移行では、そこも解決したいという考えがありました。具体的には Kubernetes の導入ですね。監視とか、オートスケールとか、セルフヒール(自動修復)といった機能を活用することで、運用コスト、サーバーコストを減らすことができるだろう、と。そして、Kubernetes と言えば、Google がリードしているプロダクト。GKE なら、マスターノードがマネージドで利用することができます。」(邵さん)


こうした見積りのもと、2018 年 10 月にスタートした新作『バクレツモンスター』は当初より GCP 上でサービスを提供。「GKE のおかげで、サーバーコストは 2~3 割、人的コストは半分くらいになっていると実感しています。」(奥村さん)とのことです。

「『バクレツモンスター』では、 PvP(Player versus Player:対戦プレイ)サーバー運用にも GKE を活用しています。これまでは、アクセスするユーザーさまが増えると新しいサーバーを追加し、都度 IP を手動で登録・管理していたのですが、GKE 導入後は、完全に自動増減できるようになりました。また、そのおかげで過剰な準備をしておく必要がなくなり、さらなる費用減にも繋がっています。」(邵さん)


そして、Cloud Spanner もインフラチームの負荷を下げることに大きな貢献を果たしているそうです。


© 2018-2019 COLOPL, Inc.


「スマートフォン ゲームでは堅牢なデータベース サービスが必要不可欠です。従来は、自分たちでサーバーを立ち上げ、そこにデータベース ソフトをインストールして……ということをやっていたのですが、そのやり方だと、サーバー自体に障害が発生した時にデータベースも落ちて、ユーザーさまがゲームを遊べなくなってしまい、深夜でも緊急対応が必要になるといった問題がありました。Cloud Spanner の導入でそういった問題はほぼなくなっています。少なくとも、Cloud Spanner が落ちたことは今まで一度もありません。」(粟田さん)


Cloud Spanner は 2018 年 8 月にリリースされた女性向けゲーム『DREAM!ing‏』で初採用。もちろん、同年 10 月リリースの『バクレツモンスター』でも利用されています。

「基本的には、今後のすべてのサービスに Cloud Spanner を導入していきたいですね。Cloud Spanner の最も魅力的な特性は性能を簡単に上下できること。従来方式のデータベース環境は規模を大きくするのも小さくするのも大変で、都度、インフラ エンジニアが集まって対応せねばならないなどといった問題がありました。結果、規模を見誤ると、リリース時や大型イベント時のアクセスをさばききれないという事故の原因になっていました。その点、Cloud Spanner ではゲームを止めることなく、オンラインで性能を調整可能。これは、革命的なことだと考えています。」(粟田さん)


「コロプラでは不測の事態に備えて、いざという時のデータベース環境を別途用意しておき、問題が起きた際は、サービスを一時停止させることなく、そちらに切り替えていくという備えをしているのですが、Cloud Spanner 導入後はそうした準備が不用に。これによってサーバーコストはおよそ半分に。人的コストもほとんどゼロになりました。」(實方さん)

「Cloud Spanner なら、サービス開始時のピークが過ぎたら、半分とか 3 分の 1 とかのインスタンス数に変更できます。これは非常にありがたいですね。」(奥村さん)


また、こうした取り組みによって、お客さまの満足度も向上。ある作品では GCP への切り替え後、そうとは知らないユーザーから「レスポンスが速くなったのではないか」という声が上がっているそうです。

「今後は、Google App Engineや、Cloud Functions などを駆使して、さらにマネージド化を進めていきたいですね。そうすることによってエンジニアがゲーム開発に集中できるようにしていきたいと考えています。」(奥村さん)

株式会社コロプラの導入事例 PDF はこちらをご覧ください。
その他の導入事例はこちらをご覧ください。

※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。

このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering(SRE)は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。

SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、SRE の構築に向けてスタートを切り、SRE プラクティスを実行に移すための具体的なヒントを提供します(本稿では、ワークブック内の章に対応する本稿での記述箇所にリンクを付加しています)。

私たちはよく、SRE の実施とは実際にどういうことなのかと尋ねられます。これは、お客様がそれぞれの SRE プラクティス を築き上げていくうえで、達成度の定量化に苦労されているからでしょう。この問題に対する単純で標準的な答えはありませんが、本稿では、初歩的なものから順に達成度を測るためのチェック リストを示していきます(決して網羅的なものではありませんが)。このチェック リストは、高信頼性サービスの担当部門が SRE モデルに向かってチームを変えていこうとするときに役立ちます。どのチェック リストも項目は時系列順に並べてありますが、実際のニーズや優先順位がチームによって異なることは私たちも認識しています。

経験豊富な SRE チームに属する方にとっては、このチェック リストは業界ベンチマークの 1 つとして役に立つかもしれません。他の人たちも自身のチェック リストをぜひ公開してください。もちろん、SRE は厳密な科学ではなく、実現過程でさまざまな難問にぶつかるでしょう。各項目の 100 % 達成には至らないかもしれません。それでも、継続していくことが SRE にとって大切だということを、私たちは Google での経験から知っています。

SRE の基本

次の 3 つは SRE の基本原則ですが、本番システムに対して責任を負うチームであれば、名前がどうであれ、SRE チームを作る前から、あるいは SRE チームへの転換と並行して、広く採用しているプラクティスでもあります。


初級者チーム

Google の SRE チームは、全部ではなくてもそのほとんどが、次のプラクティスと特長を確立しています。チームが置かれた環境にこれらの実現を阻むもっともな理由がないかぎり、私たちはこれらを、優れた SRE チームの基礎だと考えています。


次の項目も、発足したばかりの SRE チームで一般的になっているものです。こういうものがなければ、チームが不健全で持続可能性に問題がある兆候かもしれません。


中級者チーム

以下の項目は経験豊富なチームで一般的に見られるもので、チームがサービスの効率的な管理に積極的に取り組んでいることを示しています。


上級者チーム

次の項目は特にスキルの高いチームに見られるものですが、複数または全社の SRE チームがより広範な憲章を共有することで実現できる場合もあります。


以下は、望ましい SRE の特長でありながら、実際にはほとんどの企業が実現できていないものです。


次に何をすべきか

以上のチェック リストに目を通したら、次のステップは、その内容が自社のニーズに合うかどうかを考えることです。

まだ SRE チームが存在せず、初級者チーム向けチェック リストの多くが未達なら、冒頭で紹介した SRE ワークブックを最初の章から順に読むことを強くお勧めします。自社が Google Cloud Platform(GCP)のユーザーで、CRE の関与を希望される場合は、アカウント マネージャーに連絡してこのプログラムに応募してください。ただし、SRE はさまざまなインフラストラクチャに適用できるメソドロジーであり、この一連のエンジニアリング手法を用いるうえで Google Cloud の使用は前提条件でないということを、はっきりさせておきたいと思います。

また、人材採用の停滞などを解決するベスト プラクティスを共有するため、既存のカンファレンスに出席したり、他社とのサミットを組織したりすることもお勧めします。

変化の激しさゆえに、上級者チーム向けチェック リストの達成に苦労しているチームもよく見かけます。システム変更や人事異動が上達の遅延要因になるかもしれません。チームが初級者レベルの段階に逆戻りするなどの問題を避けるため、Google の SRE リーダーたちは、6 か月ごとにそれぞれのチームの主要指標をチェックしています。この場合、一部の項目はすでに標準になっているので、チェック範囲は上記のチェック リストよりも狭くなっています。

すでにお気づきかもしれませんが、本稿の中心的な問いに答えるということは、チームの影響力と健全性、そして何よりも大切なことですが、実際の仕事のしかたを評価するということです。結局のところ、最初の SRE 本で書いたように、自動化できないプロセスやソリューションを作っているなら、システムを維持するために人員を確保し続けなければなりません。人間がいなければ仕事がまわらないのであれば、人間の血と汗と涙をマシンに注ぎ込んでください。

だからこそ、あなたはもう SRE チームを設けているのでしょう。そのチームは効果的ですか? スケーラブルですか? 人々は満足していますか? SRE チームのスキルがどの程度であっても、チームの仕事と会社のサービスにはまだまだ発展、成長、強化の余地があるはずです。SRE チームの立ち上げ方をもっと詳しく学びたい方はこちらを参照してください。

本稿に力を貸してくれた多くの人々、特に Adrian Hilton、Alec Warner、David Ferguson、Eric Harvieux、Matt Brown、Myk Taylor、Stephen Thorne、Todd Underwood、Vivek Rau の各氏に感謝いたします。

- By Gustavo Franco, Customer Reliability Engineer
Share on Twitter Share on Facebook

2019 年 2 月 14 日放送 Google Cloud でつくるハイブリッドクラウド


番組で説明した資料はこちらで公開しています。

[Cloud OnAir] Google Cloud でつくるハイブリッドクラウド 2019年2月14日 放送 from Google Cloud Platform - Japan

Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
Share on Twitter Share on Facebook


ブローカ サービスを実装すれば、業務の遂行に必要なサービスに集中できるようになります。サービスの構築方法や実行環境のインフラストラクチャについてあれこれ悩む必要はありません。

Open Service Broker は、アプリケーションにネイティブに組み込めるさまざまな GCP サービス(ストレージ、ビッグデータ、機械学習、モニタリング、デバッギングなど)へのアクセスを提供します。アプリケーションが利用できるサービスの範囲をさらに広げるため、Open Service Broker には今後も多くの GCP サービスが対応する予定です。

私たちは、Google Cloud を SAP アプリケーションの実行に最も適した場所にしたいと考えています。これからの数か月間、引き続き皆さんのご意見を伺いながら、より多くのアップデートを提供していきます。なお、GCP 上の SAP ソリューションの詳細については、こちらのサイトで学ぶことができます。

- By Jiri Vondra, Solutions Architect, Cloud Partner Engineering
Share on Twitter Share on Facebook


利用している Google Cloud Platform サービス

Google Kubernetes Engine, Stackdriver Debugger, Stackdriver Monitoring, Google BigQuery, Google Cloud Storage, Cloud SQL, Google Cloud Load Balancing など

AnyPay株式会社

取締役 CTO 中村 智浩氏
AnyPay株式会社は、2016 年6月に創業されたスタートアップ企業。「テクノロジーに包まれた社会を実現する」をミッションに、決済サービス『paymo biz』やブロックチェーン関連事業、投資事業を展開しています。

『paymo biz』をクレジットカード業界のセキュリティ標準「PCI-DSS」に対応するために Google Kubernetes Engine を中心とした様々な GCP プロダクトを採用。セキュアにかつ低コストでのカード処理システム構築の実現を可能とした背景や、導入効果について同社 取締役 CTO 中村 智浩さんにお話をお伺いしたインタビュー動画をご覧ください。
Share on Twitter Share on Facebook

2019年1月31日放送 Google Cloud とつなぐ色々な方法
〜 つなぐ方法をゼロからご紹介します〜


番組で説明した資料はこちらで公開しています。
[Cloud OnAir] Google Cloud とつなぐ色々な方法 〜 つなぐ方法をゼロからご紹介します〜 2019年1月31日 放送 from Google Cloud Platform - Japan

Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
Share on Twitter Share on Facebook

製造業、建設・工事業の世界で知らない人はいない、事業者向け間接資材のオンライン通販サイト「モノタロウ」を運営する株式会社MonotaRO は、自ら「データドリブン カンパニー」であることを掲げ、数々の先進的な取り組みを行ってきました。BigQuery を活用したデータ分析基盤の構築もその一例。総計 100 億レコードものデータを保有する同社が、それをどのように活用し、業務改善を果たしてきたか、聞いてきました。

利用している Google Cloud Platform サービス

BigQueryGoogle Cloud Storage、など


株式会社MonotaRO

事業者向け間接資材のオンライン通販サイト「モノタロウ」を運営する E コマース企業。2000 年 10 月に住友商事と米国グレンジャー社の出資により設立され、わずか 5 年弱で登録事業所数 10 万件を突破。2018 年 9 月末時点で、登録ユーザー数約 308 万人、取り扱い商品点数は 1,700 万点。現在は中国市場にも進出しているほか、大企業向け間接資材(MRO)集中購買サービスも展開中。

写真左から


オンプレミス環境から BigQuery への移行で膨大なデータを取り扱えるように

「データ ドリブンカンパニー」であることを掲げ、早い時期からデータを活用したデジタル マーケティングを実施してきた株式会社MonotaRO。同社が掲げるデータ  ドリブンカンパニーの条件は、データに基づいた意思決定を支える経営と文化、データに基づいた意思決定を支えるデータ分析力、データに基づいた意思決定を支えるデータ基盤、だと言います。

そんな MonotaRO が、2017 年に「データ基盤」を BigQuery に移行させた背景について、同社執行役データマーケティング部門 部門長である久保 征人さんにお話をお伺いしました。

「我々が使っていたデータ分析基盤は、2008 年に構築したもので、オンプレミスという制約もあり、大量のデータを入れることが難しくなっていました。それに対し、現在、我が社は 3 年で売り上げを 2 倍に伸ばすという急成長の最中にあります。結果、受注データ、発注データ、商品データといった、最低限のごく限られたデータですら膨大になり、従来のデータ分析基盤では取り扱えないようになっていました。たとえば、月次のバッチ処理などが 24 時間で終わらないようになっていたのです。また、社内からはウェブログや広告の出稿ログなどをマーケティングに活用したいという声もあがっており、データ分析基盤の刷新は最重要課題となっていました。」(久保さん)


こうした問題や新たなニーズを踏まえ、MonotaRO はクラウド ベースのデータ ウェアハウス サービスを複数検討。大量のデータを高速に取り扱うことができ、シンプルで、より多くのユーザーが操作できることから、BigQuery の採用を決定しました。

「BigQuery の導入効果は大きく 3 つあります。1 つ目は、総計 100 億レコードにも及ぶ、社内のありとあらゆるデータを BigQuery に集約できたこと。これにより、たとえばウェブログと受注データを紐付けて分析するなどといった新しい試みを実施できるようになりました。2 つ目のメリットは、BigQuery が極めて高速なため、今までは丸一日かかっていたような処理が数十分で終わるようになったこと。これにより、従来は月に 1 度だけ実行していたような重いバッチ処理をデイリーで走らせられるようになり、精度の高い情報に基づいた改善を行えるようになりました。3 つ目は、こうしたメリットを受けて、BigQuery を使いデータ分析をしたいというメンバーが増えたということです。」(久保さん)

BigQuery 導入後には、扱えるデータ量が 10 倍に、そこからほぼ自動で生み出される分析レポートの数も 10 倍に、そして、データ分析を行うメンバーの数が 4 倍にもなったそうです。

「社内でデータ分析を行うメンバーの数が 4 倍になったという成果は、他と比べて一見地味に見えますが、最も注目すべき大きな成果かもしれません。これまでは、自分で SQL を書きデータ分析を行える非 IT エンジニア メンバー(アナリスト)は 10 名程度しかおらず、データ分析を依頼する際には、その限られたアナリストに分析を依頼する必要がありました。しかし、非 IT エンジニアでもデータ ポータル(旧名称:Data Studio) などのツールを使うことでデータ分析・可視化を行える BigQuery の導入後は、その人数が約 40 名(=4 倍)に増大。従来は 2 時間前後必要だった数億レコードを対象としたデータ分析が BigQuery なら 2、3 分で終了することもあり、スピード感をもってデータ分析を行えるようになりました。その結果、従来基盤では毎月 30 程度だった分析レポートの数が、300 レポート / 月にまで増大しています。データドリブンな PDCA が想定以上に、我々の業務改善を加速させているように感じています。」(久保さん)


まずは “ニア リアルタイム” 同期を実現。今後はリアルタイム同期の実現へ

予想以上の大成功となった BigQuery へのデータ分析基盤移行ですが、もちろん、その道のりは平坦なものではありませんでした。移行作業を担当した、同社データマーケティング部門 データ基盤グループ グループ長 香川 和哉さんは、その当時を次のように振り返ります。

「先ほど、久保が BigQuery には社内のありとあらゆるデータを集約させたと言いましたが、実際にそれをどう実現するのかが悩みどころでした。結論を言うと、基幹システム上で動いている MySQL の変更履歴を自動的に BigQuery に連携させ、マスターと全く同じレプリカを作るという方法を採りました。現在は移行まで 2、3 分程度かかる “ニア リアルタイム” ですが、この方法であればほぼリアルタイムで移行することも可能です。様々な制約のなか最も無理なく移行させられる方法だと判断しました。なお、ウェブログについては、アナリティクス 360 の自動エクスポート機能を使うことで、BigQuery にデータを取り込んでいます。」(香川さん)


結果として、移行にかかった期間は、ウェブ ログデータの同期に担当者 2 名で約 3 か月、基幹システム DB との同期システム構築に担当者 1.5 名で約 6 か月で完了。現在の MonotaRO の急成長を妨げることなく、クイックな移行を実現しました。

「現在は “ニア リアルタイム” な部分を “リアルタイム” にしていく取り組みを計画中です。Cloud Pub/Sub や、Cloud Dataflow を活用していくことで実現できると考えています。データをマージしたり、バッチ処理するところでは、Cloud Composer を使う予定です。リアルタイムにこだわる理由は、やはりいくつかリアルタイムでなければ困る業務があるからですね。プロモーションへの活用などが代表例ですが、ユニークな使い方では、IT エンジニアがシステムの稼働状況を確認・検証するのにリアルタイムなデータがあると便利というものもあります。」(香川さん)

そして最終的には、今よりもさらに多くのメンバーがデータ分析基盤を活用していけるようにしていきたいとのこと。具体的には顧客との全タッチポイントで、データに基づいたパーソナライゼーションを実現するための基盤構築をしていきたいと、久保さんは言います。

「たとえば、GCP のデータ基盤の上にリアルタイムの機械学習基盤を作ることで、お客様との全タッチポイントで、データに基づいたリアルタイムなパーソナライゼーションを実現しようとしています。分かりやすい例ですと、商品のレコメンデーションなどにおける活用ですね。当社はこういった高度なチャレンジも、GCP 上で引き続き行っていきたいと考えています。」(久保さん)


株式会社MonotaROの導入事例 PDF はこちらをご覧ください。
その他の導入事例はこちらをご覧ください。
Share on Twitter Share on Facebook



広告効果の向上や、店舗誘導の効率アップにはプライベート DMP の導入が効果的です。株式会社LIXIL は、それを、BigQuery をフル活用することで実現。BigQuery やアナリティクス 360 などの Google プロダクトに、レコメンド エンジンなどの外部サービスを見事に連携させ、理想的なデータ分析基盤の構築に成功しました。その鍵となる工夫などを、同社エンジニア、栗本さんが語ります。

利用している Google Cloud Platform サービス

BigQueryBigQuery ML(ベータ版)Cloud Datalab など


株式会社LIXIL

株式会社LIXIL は、住生活グループ(現・LIXILグループ)の事業子会社を統合するかたちで 2011 年 4 月に設立(「トステム」「INAX」「新日軽」「サンウエーブ」「TOEX」はブランド名として存続)。建材・設備機器の製造、販売を行う B to B to C 企業で、その年間売り上げはグループ全体で約 1.7 兆円。建築材料・住宅設備機器では、業界最大手の企業の一つとなります。従業員数はグループ全体で 61,140 人(2018 年 3 月末時点)。

写真


ひと手間かけて BigQuery 上のユーザー識別子を統一し、分析精度を向上

建築材料から、玄関・窓まわり、水まわり設備まで、家づくりにおいて、今やなくてはならない存在となっている株式会社LIXIL。その Web サイトには月間約 200 万人もの人々が訪れます。

「お客さまが LIXIL の Web サイトにやってくる理由はそれぞれ大きく異なります。Web 上でキッチンやトイレなどの LIXIL 商品の性能や機能を調べたい方、近くのショールームで実際の商品に触ってみたい方、見積りを取りたい方、商品を設置する工務店を探したい方といった具合です。そのため、Web サイトにはお客さま一人ひとりの状況に合わせて、適切なタイミングで、最適なコンテンツに誘導する必要があります。これらの課題を解決するために、我々は BigQuery を中心としたプライベート DMP(Data Management Platform)の構築を行いました。」(栗本さん)


BigQuery を中心としたプライベート DMP 構成イメージ



LIXIL のプライベート DMP の構成は上図の通り。ここでポイントとなるのが、アナリティクス 360 の BigQuery エクスポート機能を使って BigQuery に蓄積されたアクセスログに “とある工夫” を施すことだったと栗本さんは言います。

「アナリティクス 360 から、BigQuery へのエクスポート時、アクセスログの中の『clientId』が、これをハッシュ化した『fullVisitorId』に変更されます。そのままだとアナリティクス 360 と BigQuery で共通の ID を使った分析ができなくなってしまうため、アナリティクス 360 のカスタム ディメンションに『clientId』を保存することで、この問題を解決しているのです。同時に、レコメンド エンジンにもアナリティクス 360 の『clientId』を連携。これによって、3 つのサービス全てで、『clientId』を共通のユーザー識別子として利用できるようにしています。」(栗本さん)

またお客さまのリアルなショールーム来館については、店頭で実施するアンケート システムとアナリティクス 360 を連携させることで、こちらも『clientId』と紐付け。これによって、Web 上での行動・閲覧履歴だけでなく、実際の行動も加えた分析をできるようにしています。

「実際の運用に際しては、蓄積されたアクセスログをデータ アナリストが、BigQuery ML や、Cloud Datalab といったツールを使って分析し、『clientId』に対して『キッチン ユーザー』『トイレ ユーザー』『リフォーム ユーザー』というような属性を付与します。これをユーザー リストとしてまとめて、広告管理者やウェブ担当者が利用。それぞれの属性に合わせた最適な広告配信などを行うことにより、無差別に同じコンテンツを展開するのと比べて、コンバージョン レートや集客効率を高めることができました。」(栗本さん)

開発のしやすさだけでなく、未経験者がすぐに使いこなせる敷居の低さも GCP の魅力

BigQuery の導入効果について、栗本さんは次のように語ります。

「まずはコストですね。BigQuery では従量課金制を選択しているので、初期投資を最小限に抑えることができます。その後、必要に応じて規模を拡大していけることも大きなメリット。API や SDK(Software Development Kit)がとても充実しており、必要に応じて外部サービスと連携させやすい点も気に入っています。そして何より速度ですね。何十 、何百 GB などの大きなデータにクエリを投げた際のレスポンスが抜群に速いなと実感しています。」(栗本さん)


加えて、エンジニアでなくとも、データ ポータル(旧名称:Data Studio)など BI ツールを使うことですぐに、データの分析・ビジュアライズができるようになることも評価しているとのこと。

「データ ポータルでは日々のパフォーマンスを可視化したレポート作成を自動化したりするのに使っています。他の BI ツールと比べて操作がかなり直観的なので、初心者でもすぐに使えるようになるのも大きな魅力です。実際、弊社でも、新卒で入ってきた未経験の新入社員が半年くらいで、ばりばりと使いこなしています。」(栗本さん)

こうしてひとまずの完成を見た、LIXIL のプライベート DMP ですが、栗本さん曰く「随時拡張していくので、本当の意味で “完成” することはないだろう。」とのことです。

「現在は、Cloud Bigtable のようなパフォーマンスが良く、スケールに優れたプロダクトを使って、弊社の商品を全個体識別できるデータベースを作成中です。また、今後は、AutoML Vision を使った、商品の画像認識も実現したいと考えています。我々の取り扱い商品の中にはサッシなど、ぱっと見で型番特定が難しいものが多いのですが、これを写真で判断できるようになったら、お客さまにとっても、工務店さんにとっても便利だな、と。」(栗本さん)


株式会社LIXILの導入事例 PDF はこちらをご覧ください。
その他の導入事例はこちらをご覧ください。
Share on Twitter Share on Facebook

※この投稿は米国時間 2019 年 1 月 16 日に Google Cloud blog に投稿されたものの抄訳です。

企業が TB(テラバイト)クラスの複雑なデータを収集する際は、それらを保存し、その情報の意味を的確に理解するツールが必要になります。そのため私たちは、大規模データセットを扱うデータ アナリストを支援する BigQuery を開発しました。とはいえ、誰もがデータの専門家というわけではありません。私たちの場合も、多くはスプレッドシートを使ってアドホック分析を行っています。

データ アナリティクス業務の担当ではない従業員でも販売データの分析といったクエリを簡単に実行できるよう、私たちは BigQuery と Google スプレッドシートのパワーを組み合わせることにしました。それを可能にするのが BigQuery 向けのデータ コネクタであり、G Suite Business、Enterprise、Education の各エディションをご利用のお客様向けとして、今後数週間以内に提供が開始される予定です。

BigQuery データ コネクタを使用すると、BigQuery の大規模データセットを Google スプレッドシート内で分析、共有できるようになります。BigQuery の最大 1 万行のデータを、(データ アナリストに教えてもらったシンプルな SQL 文を使用して)Google スプレッドシートに接続し、スプレッドシートの「データ探索」機能を使用するか、グラフピボット テーブルを作成することで、それらのデータを分析できます。通常の場合と同様に共有権限を管理し、データの閲覧や編集、共有を制限することも可能です。Google スプレッドシートでの「編集」アクセスや BigQuery テーブルへの「閲覧」アクセスが可能なユーザーは、データセットを更新できます。

このデータ コネクタを使用して以下を行うこともできます。

Yahoo! のデータ アナリストは、このデータ コネクタをワークフローの簡素化に役立てています。Verizon Media のエンジニアリング ディレクターである Nikhil Mishra 氏は、「私たちのアナリストは BigQuery データ コネクタを使用することで、Google スプレッドシートにデータを取り込む手順を大幅に減らし、作業時間とミスを削減しています」と述べています。

一歩進んだ使い方

Google スプレッドシートでの分析が最も有効なのは、データが最新の場合です。今後数週間以内に、Apps Scriptマクロ レコーダーのようなツールを使って、接続した BigQuery データの自動更新をスケジューリングできるようになります。たとえば、1 日の初めにコンピュータの電源を入れると、最新のデータが整い、分析が可能な状態になるように Google スプレッドシートのデータが自動的に更新されます。Google スプレッドシートでのマクロの記録や実行の方法について興味がある方は、G Suite のこちらのブログ記事をご覧ください。

- By Daniel Gundrum, Product Manager, G Suite
Share on Twitter Share on Facebook


利用している Google Cloud Platform サービス
Cloud Vision API, TensorFlow

株式会社 trippiece
trippiece は 2011 年の創業以来、旅行 × インターネット領域でサービスの企画・開発を行っている企業です。みんなで旅に出かける旅行サービス「trippiece <トリッピース>」、旅行おでかけメディア「RETRIP <リトリップ>」を運営しています。

ソックリトリップの狙い
日本の知られざる魅力をより多くの人にもっと知ってもらいたい、ソックリトリップはこの想いを実現するために企画されました。2020 年を目前に控え日本への注目が高まる中、「私たち日本人は日本の魅力をよく知らないのでは?」ということが企画の出発点でした。しかし日本人は絶景が大好き。その力はウユニ塩湖のような地球の裏側へ足を運ばせてしまうほどのものです。そこで、世界中の絶景を、日本の魅力を発見する手助けになるコンテンツと見立てて、サービスを作り上げました。もしソックリな場所が見つかれば素敵ですし、見つからなくても「ここもいいじゃん!」と思ってもらえるよう様々な工夫をこらしました。このサービスを通じて日本の魅力をもっと発信していきたいと考えています。」(久野さん)

Google Cloud AI を活用して世界の絶景画像から国内の絶景ポイントをレコメンドする仕組み

ソックリトリップでは、Google Cloud AI のサービスである Cloud Vision API と、TensorFlow を活用することで、世界の絶景画像から国内の絶景画像 (と絶景ポイント) を発見する機能を実現しました (下図) 。

レコメンド例


ソックリトリップにより提案された絶景ポイント

ソックリトリップでは Cloud Vision API で検出された上位 10 個のラベル情報 (以下、ラベル情報) と、Keras ベースの学習済み機械学習モデルである VGG-16 の全結合層の出力結果 (以下、分散表現) を組み合わせることで、世界の絶景画像と似ている国内の絶景画像を抽出します。

Cloud Vision API のラベル情報を活用した類似度計測

Cloud Vision API のラベル検出機能を使うことで、画像内の物体についての情報を、幅広いカテゴリに渡って抽出することができます。例えば、Cloud Vision API のトップページにあるサンプルに画像を入力すると下記のラベル検出結果を、信頼度スコアと共に取得することができます。ソックリトリップでは、信頼度スコアが高い上位 10 件のラベル情報の重複数を、入力画像 (世界の絶景画像) と出力画像の候補 (国内の絶景画像群) の間で比較し、重複しているラベルの数が多いほど、入力画像と出力画像の類似度が高いとみなします。


VGG-16 の埋め込み表現を活用した類似度計測

VGG-16 は画像認識に特化した、畳込みニューラルネットワーク (CNN) ベース の機械学習モデルです。ソックリトリップでは Keras ベースの学習済みの VGG-16 モデルを利用し、入力画像から VGG-16 モデルの全結合層のベクトル (注: 本記事では埋め込み表現と呼びます) を抽出しています。この埋め込み表現にはラベル検出に有効な特徴が埋め込まれています。

この埋め込み表現の面白いところは、埋め込み表現の中に機械学習モデルが内部的に利用している特徴が埋め込まれていること、そして埋め込み表現同士の距離を数値的に計測可能であることです。VGG-16 はラベル認識のための機械学習モデルであるため、埋め込み表現に埋め込まれている特徴は、ラベルを認識するために必要な情報と解釈することができます。一方、埋め込み表現同士の距離が近いということは、両者が共通の特徴を有していることを意味しています。つまり、埋め込み表現同士の距離が近い画像は、類似した画像である可能性が高くなります。

ソックリトリップでは、上記埋め込み表現の特徴に着目し、埋め込み表現間の距離計測にコサイン距離を採用し、この距離を入力画像と出力画像の類似度とみなしています。埋め込み表現とコサイン距離、この 2 つを利用することで、人手をかけることなく画像間の類似度を効率的に計測しています。

ラベル情報と埋め込み表現を組み合わせることで国内の絶景画像を出力

ここまでソックリトリップが利用している 2 つの類似度計測手法を紹介しました。ソックリトリップでは出力画像 (国内の絶景画像) を決定するために、ラベル情報による類似度、埋め込み表現による類似度のそれぞれに対して、結果を見ながら独自に調整した重み係数をかけ合わせることで、最終的な類似度を算出しています。

今後の取り組み

「地方自治体と連携することで、各自治体が訴求したい観光スポットをオススメするなど、ソックリトリップによる地方創生の取り組みを強化していきたいと考えています。現時点では、厳選された国内の絶景画像 (約 500 枚) のいずれかが出力されているのですが、今後は地方自治体が絶景スポットの登録画像も検索対象にしたいと考えています。これを実現するためには、現状の仕組みをよりスケーラブルに改造していく必要があると考えています。」 (林さん)
「現在、埋め込み表現を抽出したり、埋め込み表現間の距離を算出するといった一連の作業を、単体のアプリケーションサーバで実現しています。 この構成では今より多くの絶景画像を検索対象とする場合にうまくスケールしません。Google Cloud にはこうしたワークロードを効率的に扱う製品がある*1 と伺っています。ソックリトリップを今より幅広く展開するときにはこうした機能をぜひとも利用したいと考えています。」 (根岸さん)

*1 例えば、埋め込み表現を抽出する部分を Cloud Machine Learning Engine を利用することで API として切り出すこと、また埋め込み表現同士の距離比較をする部分を BigQuery を活用することで、同時利用者数や、検索対象画像数が多くなってもスケールするシステムが構築できます。

株式会社博報堂 林 智彦氏、久野 祐揮氏、根岸 冬馬氏

Share on Twitter Share on Facebook


Google Cloud は、インターネットサービス業界で活躍するインフラエンジニア、サーバーアプリケーションエンジニア、テクニカルリーダーの皆様に向けて、"Google Cloud INSIDE Digital" を開催します。

業界をリードする方々や、深い専門知識をもつ Google 社員をスピーカーに迎え、注目インターネットサービスの開発の裏側や、Google Cloud Platform(GCP) を中心としたテクノロジーアップデートをお届けします。この Google Cloud INSIDE Digital をきっかけに、新しいサービスやプロダクトが生まれるような会へ、参加者の皆様と共に育てて行きたいと考えています。

今回のテーマは「ここでしか聞けない GCP 商用活用の第一歩」。注目インターネットサービスでの GCP 活用について、インフラからデータ分析までユーザー事例と共にご紹介します。

開催概要


参加申し込み:https://goo.gl/zDMmsT

上記リンクからお申し込みください。

※ 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。
※ 報道関係者のご参加はお断りさせていただきます。
※ ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。
※ お申し込み多数の場合は抽選を行います。参加いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。
Share on Twitter Share on Facebook


2011 年にリリースされ、今では、全国 47 都道府県、約 7 万台(全国のタクシー台数の約 30%)をネットワークする国内最大級のタクシー配車アプリにまで成長した『JapanTaxi』(旧 全国タクシー)。そのアプリを支えるデータ分析基盤には、2017 年冬から BigQuery が活用されています。なぜ、BigQuery が必要だったのか、同社データエンジニア 饗庭 秀一郎さんにお話いただきました。

利用している Google Cloud Platform サービス

BigQueryGoogle Cloud StorageCloud Dataflow など

JapanTaxi株式会社

1977 年に日本交通グループのシステム開発部門として発足した株式会社日交データサービスが前身(2015 年 8 月に現在の JapanTaxi株式会社に商号変更)。配車や顧客管理など、グループ内の基幹業務システム開発および運用を行う。2011 年にタクシー配車アプリ『全国タクシー』をリリース(2018 年 9 月に『JapanTaxi』に名称変更)。従業員数は 123 名(2018 年 10 月現在)。

写真


BigQuery は高速で、運用の手間がなく先進的なプロダクト

スマートフォン向けタクシー配車アプリ『JapanTaxi』は、アプリを起動しマップ上で乗りたい場所を指定すると、そこにタクシーがやってきてくれるという便利なサービス。時間を指定した予約や、クレジットカードなどによるキャッシュレス決済、多言語対応(英語・中国語・韓国語)など、タクシー利用時のユーザビリティを高める工夫が多数施されており、移動にタクシーを多用するビジネス パーソンから、国内外の旅行者まで、幅広い層の支持を集めています。

そんな JapanTaxi が、そのデータ分析基盤に BigQuery を採用したのはほぼ 1 年前。サービスを通じて得られたビッグデータを BigQuery に集約して意志決定支援のためのデータ分析を行い、さらなるユーザビリティ向上や、業務効率の改善を目指しています。

「BigQuery では、数十秒おきに送られてくるタクシーの位置情報や、アプリからの注文情報(位置情報、利用時間、ユーザー情報などが含まれる)など、JapanTaxi のサービスにまつわるさまざまなデータを取り扱っています。BigQuery を選んだのは、こうしたデータを高速に、効率的に運用できるから。前者については、特にアドホック分析時の待ち時間のストレスがなくなりましたね。従来の仕組みでは数時間待たされることもざらだったので、その分、本質的な分析の方に専念できるようになりました。もちろん、後者についても BigQuery 導入の効果は大。通常、このような大規模分散処理の仕組みを自前で運用すると、そのメンテナンスには無視できない労力が発生します。その点、フルマネージドな BigQuery ではそうした手間を考える必要がなく、少人数で運用していくことが可能です。実際我々も、私ともう 1 人のエンジニアだけでこのデータ分析基盤を運用しています。」(饗庭さん)

また、BigQuery 導入の大きな目的の 1 つとして、利用者の拡大がありました。これまでは、データ分析基盤にアクセスできるのは一部のエンジニアだけだったのですが、BigQuery への移行を機に、多くの社員にこれを開放することになりました。

「データ分析基盤では、あらゆる関連データにアクセスできるよう、散在するデータの集約と共有を行っています。データベースにアクセスするのは、主に経営層、アプリ開発部隊、そしてマーケティング部隊、セールス部隊のメンバー。それぞれの組織は、マーケティング部隊がユーザーや流入元を、セールス部隊は地域や会社を軸にと、それぞれ異なる観点で分析を行うため、素早く見たい軸で分析できるようにしています。その際、大きな進歩となったのが、経営層とセールス部隊のように、普段データベースに直接アクセスしない人たちが、BI ツール経由で BigQuery に自分でアクセスできるようにしたこと。ここでポイントになるのが「自分で」という部分。従来はこうした分析を、分析チームに依頼をして処理しており、大きなボトルネックになっていたのですが、データ分析を当人が直接やれるようにしたことで、効率アップしています。ただしこの場合、使い方を誤って大きなコストを発生させる恐れもあるので、利用状況の客観的把握は必要。具体的には、先日提供が開始された分割テーブルや、β 版のクラスタ化テーブルのような新機能を利用することで、利用者が意識することなく、パフォーマンスやコストを最適化できるようにしています。こうした新機能が次々と登場してくることも、BigQuery を選んだ理由の 1 つです。」(饗庭さん)

こうした取り組みは、利用者からとても好評。これまではデータが必要になる度に開発メンバーに依頼をしてデータ収集や編集を行っていたのですが、非エンジニア層が、それぞれツールを介してデータ分析基盤にアクセスできるようになったことで、ビジネスのスピード感が大幅に増したそうです。「たとえば、セールス部隊のメンバーが、お客先のタクシー会社で、直接その場でデータを取り出しお見せするといったことが可能になりました。これはとても大きな成果だと感じています。」(饗庭さん)


Google 得意の AI サービスでさらなるデータ活用を推し進めたい

JapanTaxi では、タクシー配車アプリらしい活用方法として、β 版の BigQuery GIS(Geographic Information System)も活用しています。その具体的な使い方についても、饗庭さんに聞いてみました。

「タクシーの位置情報や、注文データに含まれる位置情報は、後の分析で、地区ごとに修正するといった要件が出てきます。この際、タクシーが営業できるエリアは “行政区” で構成されているので、その中で集計する必要があります。しかし、“緯度・経度” の情報しかないと、そうした集計ができません。今回、そこに GIS をご提供いただいたことで、地理的座標(緯度・経度)情報さえあれば、直接 BigQuery 上でデータ集計ができます。特に取引先のタクシー会社にデータを提供するときは、営業区域を意識されることが多いので、そういった情報をすぐに取り出せるのはとても助かります。」(饗庭さん)

今後の活用方法と、そこに向けて求められる機能についてもお伺いしたところ、以下のような回答をいただきました。

「これまではアプリのログであったり、ユーザーの注文情報であったりとか、比較的構造化された、BigQuery と相性のよいデータを取り扱ってきました。しかし、今後は弊社で開発しているタクシー向けのドライブ レコーダーの映像や、非構造化データをいかに上手く取り扱っていくかが課題となっていきます。そこで役立ってくれそうなのが、Google Cloud Platform が誇る、画像認識系の AI サービス。Cloud Auto ML や、Cloud Vision API などといったサービスを活用して、ドライブ レコーダーの映像を分析し、車や構造体を抽出して、非構造化データを構造化するなどといったことを、運用コストを抑えつつ、行っていきたいと考えています。」(饗庭さん)

なお、AI サービスについては非構造化データだけでなく、従来のデータ分析にも活用していきたいとのこと。「BigQuery ML に注目しています。現在進めている施策の、一歩先の世界観として、社内の予測モデルのようなものを自律的に使えるようになっていったら、データ活用がより拡がっていくのではないかと期待しています。」(饗庭さん)


JapanTaxi株式会社の導入事例 PDF はこちらをご覧ください。
その他の導入事例はこちらをご覧ください。
Share on Twitter Share on Facebook

利用している Google Cloud Platform サービス

Cloud Vision API

Sansan株式会社


『出会いからイノベーションを生み出す』というミッションのもと、Sansan と Eight のサービスを通じて、無数の「出会い」の価値を最大化することを目指す、Sansan株式会社。(以下  Sansan)
Sansan のサービスの性質上、名刺を撮影しテキストデータ化する OCR のプロセスは非常に重要度の高い工程です。このプロセスに Cloud Vision API を採用しています。

800 万リクエスト / 日を処理する画像処理のシステムの GCP 移行を、GCP 未経験の 2 名のエンジニアが 3 週間で実現しています。また GCP への移行でコスト削減を実現するだけでなく、エンドユーザーの皆様にとって最も良い環境の提供を実現するという観点で、コアビジネスの付加価値が高いと判断いただき、GCP の採用を決定されました。

GCP 移行から導入効果についてを、同社執行役員 CTO 藤倉 成太さんとDSOC(Data Strategy & Operation Center)Development Group Leader 永井 晋平さんに語っていただいた、インタビュー動画をご覧ください。

その他の導入事例はこちらをご覧ください。
Share on Twitter Share on Facebook