Unity の BigQuery 導入事例 - ペタバイト規模のデータ分析に対応する仕組みと、レポート作成や機械学習への活用

※この投稿は米国時間 2020 年 6 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回は、ゲーム、アーキテクチャ、映画などの産業向けに開発プラットフォームを提供している Unity Technologies にお話を伺います。エンジニアリングおよびデータ担当ディレクターを務める Sampsa Jaatinen 氏が、最新型テクノロジーの導入をテーマに、どの業界の意思決定者にとっても役立つ貴重なノウハウを公開しています。

Unity Technologies は、リアルタイム 3D（RT3D）コンテンツの作成、運用を行うための世界最先端のプラットフォームを提供しています。1 か月に数十億ものエンドポイントとやり取りするサービスをはじめとして、社内の財務運営、カスタマー サクセス、マーケティングなどの部門向けの外部サービスも構築、運用しています。こうしたサービスやシステムはすべて、当社のビジネスやサービスを理解し、運営していくうえで欠かせない情報を生み出しています。当社では、これらのデータを詳しく把握し、最大限まで可能性を引き出すために、データを分断化していたサイロを取り払い、多数のデータソースを 1 つに統合することにしました - そうすることによって、データを効率的に管理、提供することが可能となります。

データサービスの一元化

障害や思わぬ事態が発生したときでもビジネス運営やサービス提供を継続して行うためには、データ プラットフォームが肝となります。Google Cloud への移行前、当社では目的別に複数のソリューションを採用していました。たとえば、機械学習データセット用のソリューション、エンタープライズ データ用のデータ ウェアハウス、ストリーミング データからのレポート生成ソリューションといった具合です。そうした状況の中に無駄を省く可能性を見出し、1 つのデータソースからすべてのニーズに対応しようと考えたのです。

私たちが目指したのは、チームや部門が別々にサイロを築いていた状況から脱却し、専任チームが 1 つのソリューション セットを構築して、データサービスを一元化することでした。一元化したデータサービスは、いったん構築してしまえば、後は多目的に使用できます。一元化することによって、コンプライアンスやプライバシーの観点からも環境を理解、管理するのが容易になります。

もちろん、一元化にはそれ特有の課題があります。たとえば、社内のあらゆるサービスを 1 つの中央サービスに統合し、その担当チームが「ゲートキーパー」として他の部門のためにいちいち鍵を開けなければならないとすると、次第に、その中央サービスのところで業務が滞るようになってくるでしょう。こうした状況を回避するために、たとえば、顧客担当チームが専用ツールを使って独自にサービスを運用できる環境を構築するといった戦略が必要となります。

つまり、社員が各自でデータを管理し、開発スケジュールを立てられるような使いやすい仕組みが求められます。それと同時に、データのプライバシーやアクセスの観点から、高い基準および安全な手順を維持する必要があります。基盤テクノロジーの選定にあたっては、こうした大前提に加えて、当社で必要な特定の機能を持ち合わせているかどうかを重視しました。さらに、こうした基盤の上に、ビジネスや機械学習の要件にデータを結びつけるという当社の最重要課題に十分に対応するソリューションを構築する必要がありました。

BigQuery を選んだ理由

こうした理由から 2 年ほど前に、それまで使用していたクラウド サービスから Google Cloud にインフラストラクチャ全体を移行することに決め、BigQuery を分析システムの基盤として採用しました。このときに特に重視したのは、スケーラビリティ、多様な入力形式および用途への対応、当社に最適な費用対効果、そして、強力なセキュリティおよびプライバシー保護機能です。

Unity が処理するデータは膨大な量です。1 か月に 30 億回以上もアプリがダウンロードされ、世界中のゲームの約 50% で採用されている Unity は（ゲーム機、モバイル、パソコンのゲームを合わせた平均値）、世界でも最大規模の広告ネットワークを運営しています。また、世界中で数十億のゲーム プレーヤーをサポートしています。当社のシステムは、当社が運営するサービスから毎日数十億ものイベントを取り込み、処理しています。さらに、CRM など、運営に必要な外部のエンタープライズ サービスからデータを取り込み、社内の膨大なストリーミング データセットと組み合わせて提供する必要もあります。そのため、1 日に数十億件のイベントを処理できるデータ プラットフォームが欠かせません。それに加えて、1 か月あたりペタバイト規模のデータを取り込み、社内の関係者がそこから分析データを取得できるような仕組みを作り、ビジネス上の重要な決断に役立ててもらう必要があります。

収集、格納したデータは、社内のさまざまなチームで分析に使用されます。たとえば、プロダクト マネージャーは、機能やサービスがどのように使用されているかを理解し、次期リリースの開発に役立てています。マーケティング部門では、データから市場動向を把握し、既存の顧客や見込み顧客をどのように取り込んでいけばいいのかを検討しています。さらに、財務部門、ビジネス開発部門、ビジネス運営部門、カスタマー サクセス担当者、アカウント担当者など、それぞれ異なる立場の意思決定者が、現状を理解して今後のチャンスを探るため、各業務に特化した情報を必要としています。ソリューションの選定にあたっては、Unity の厳格なセキュリティおよびプライバシーの規範を守れるかどうか、という点も重視しました。当社では、社員によるデータセットへのアクセスを厳しく制限しています。データを匿名化、暗号化できるという点は非常に重要で、絶対に外すことのできない条件でした。  

さらに、Unity の各種サービスの心臓部ともいえる機械学習をサポートしているかどうかという点も考慮しました。機械学習では、サービスでデータを生成してから、読み取り、最適な動作に向けて調整するという、高速で閉じたデータのフィードバック ループが必要となります。たとえば、Unity の各種トレーニング教材の中からユーザーに関連するものをおすすめするといった便利な機能が、機械学習の活用例です。私たちが求めていたのは、こうした処理を簡単に行えるデータ プラットフォームでした。  

BigQuery への移行

移行作業は、通常のリフト＆シフト方式で開始しましたが、その過程で、テーブル スキーマ、ETL ジョブ、クエリを慎重に調整する必要がありました。非常に複雑なエンジニアリング プロジェクトであり、全体で 6 か月弱かかりました。特に複雑だったのは、GDPR ポリシーに準拠するための要件を満たさなければならなかった点と、それまで分散していたデータベースやツールを 1 つのデータ プラットフォームにまとめる点でした。

この移行作業を通じて私たちが学んだ教訓は、厳しい分析要件を持つ他の企業にとっても有益であると思いますので、ここでいくつかご紹介したいと思います。

移行に関する考慮事項

BigQuery では、スキーマを固定する必要があり、これが利点となるときも、そうでないときもあります（他のサービスと異なります）。スキーマを固定すると、アプリケーションからイベントを書き込む際の自由度が低くなり、デベロッパーは厳格な規範に従う必要があります。一方で、間違いのある入力レコードによってデータが壊される恐れがないため、ダウンストリームのオペレーションが安全になるという利点があります。

こうした背景から、スキーマ管理システムを構築する必要がありました。これにより、データを生成、格納、処理する必要がある社内のチームが、スキーマの作成や変更を行ったり、スキーマの不一致によってターゲット テーブルに到達できなったデータを処理し直したりできます。このようなデータ取り込み機能を導入するにあたって、スキーマを適用してセキュリティを確保することと、担当者が自らスキーマを柔軟に管理できるようにすることが不可欠でした。  

そのほかに考慮したのは、データ プラットフォームの柔軟性です。当社では、取り込んだデータをまとめて、レポート生成や分析を簡単に行えるようにすることや、誰でも簡単に使いこなせるデータ処理ツールセットを提供して、各自が必要に応じて新しいデータセットを作成したり、データの結合やサンプリングを行ったりできるようにすることを目指しています。その点、BigQuery は柔軟性とスケーラビリティを兼ね備えており、データセットや、イベント単位のデータに自由にアクセスして、レポート作成や、分析、機械学習などの目的に使用することが可能です。  

複雑な分析システムにおいて把握しておくべき重要な点は、誰がどう使用するかということです。たとえば、単純なダッシュボードのみを必要とする社員にとっては、データポータルなどのプロダクトと BigQuery の統合により、そのようなダッシュボードの利用が容易になります。一方、高度なレポート作成機能や、複雑なダッシュボードの作成機能を必要とするユーザーにとっては、Looker が適しています。

機械学習がサポートされているかどうかという点も、当社にとって重要なポイントでした。機械学習にもさまざまな用途があり、たとえば、手軽にループを作成したいようなときは、BigQuery の格納データに対して AutoML や BigQuery ML を使用するのが便利です。一方、本番環境向けに細かな調整が必要なケースでは、BigQuery の格納データを取り込み可能な Kubeflow ベースのソリューションを構築して対応しました。

分析インフラストラクチャをモダナイズするための次のステップ

Unity では、世界規模の分析インフラストラクチャを導入し、1 日に数十億件のイベントからペタバイト規模のデータを取り込むことを可能にしました。今では、こうしたデータを社内の主要な関係者に数時間で提供できます。サイロ状態だった以前のデータ ソリューションを 1 つに統合したことで、社内プロセスが改善したのはもちろん、レポート作成を運用化したり、多数のリクエストに迅速に対応したりすることが可能となりました。多様なデータを 1 つのシステムに取り込み、その 1 つのデータソースからあらゆる用途に対応できるようにしたこと、特に、その統合に BigQuery を採用したことによって、スケーラビリティ、柔軟性の両方に優れたマネージド サービスを実現し、無駄を最小化することができました。

Unity の機械学習への取り組みについて詳しくは、こちらをご覧ください。当社では現在、ML 関連の人材を募集しております。当社のエンジニアやサイエンス チームの一員として、こうしたやりがいのあるテーマに取り組むことにご興味がおありでしたら、ぜひ募集中の ML 関連の役職をご覧ください。