BigQueryで解決した2つの困り事

第1部の最後の登壇は、Aimingの芝尾さんです。

芝尾幸一郎（しばお・こういちろう）／株式会社Aiming リードソフトウェアエンジニア。大分県出身。熊本大学卒。ドワンゴ、セガなどでの勤務を経て、2013年よりAimingへ入社。著書に『ゲーム開発が変わる！Google Cloud Platform 実践インフラ構築』がある。

主にMMOゲームを開発するAimingに勤める芝尾さんは、データ分析における困り事として「大量に入ってくるデータを取り回す煩雑さ」と、基盤を構築した後に「エンジニアがSQL書きに忙殺される」の2点を挙げます。芝尾さんから共有されるのは、この2点を「BigQuery」を導入して解決した事例です。

まず、ひとつめの「大量に入ってくるデータを取り回す煩雑さ」をなぜ「BigQuery」で解決できるのかといえば、「BigQuery」には次のような特徴があるからです。

• 保存できるレコード数に上限はない
• 集計レスポンスが早い
• レコード数が増えても集計レスポンスが早い

「BigQuery」の最大の特徴とも言える集計レスポンスがの速さは、数千個のCPUコアで分散処理を行うことで実現します。「これは例え思いついたとしても、Googleでしか実行できない手法ともいえる」と芝尾さんは説明します。

続いて芝尾さんは自身が経験したデータ分析基盤構築の経験を共有します。まず「データ分析基盤に期待する要件」として、芝尾さんが挙げたのが次の6点。

• データがいくらでも入る
• 生データから直接集計
• 再集計が楽
• 集計が早い
• 試行錯誤しやすい
• 導入しやすい

芝尾さんはこれまでに経験した「MySQL」「Hadoop」/「Hive」「BigQuery」を使ったデータ分析基盤において、上記のポイントをどのくらいクリアできたかを順番に紹介していきます。

まずは、2011年から2013年に経験した「MySQL」でのデータ分析基盤。「MySQL」では、数万のデータであれば問題ないものの、数億件を越えるデータの規模になると、集計にとても時間がかかってしまいます。

そこで、芝尾さんは生データ集計ではなく、ログを集約して保存した中間テーブルを利用する方式を採用。しかし、この方法ではログの遅延などイレギュラーに弱いという弱点も。事前に期待した6点の要件を満たせているかどうかを振り返ると下記の結果となりました。

• データがいくらでも入る → ✕
• 生データから直接集計 → ✕
• 再集計が楽 → ✕
• 集計が早い → ✕
• 試行錯誤しやすい → ✕
• 導入しやすい → ◯

「MySQL」を使ったデータ分析基盤はあまり上手くいかなかったため、芝尾さんは別の分析基盤の構築を始めます。それが2013年から2015年に経験した「Hadoop」と「Hive」を使ったデータ分析基盤です。

数億件のデータでも並列処理の実行が可能なこの「Hadoop」を使った基盤では、「MySQL」の基盤とは異なり、生ログから直接集計を行うようにアーキテクチャーを変更しました。「Hadoop」を導入することで数億件のデータも集計できるようになり、「SQL」は過去分も集計するようにしたために、ログの遅延が起こっても問題なく対応できるようになったと芝尾さんはメリットを語ります。

しかし、「SQL」の実行には数分かかるため何度も実行することが難しく、また数分の時間がかかるために事前集計が必要になるというという不満は以前として残されました。「Hadoop」と「Hive」による基盤においては、期待する要望に関しては次のような結果となりました。

• データがいくらでも入る → ◯
• 生データから直接集計 → ◯
• 再集計が楽 → △
• 集計が早い → ✕
• 試行錯誤しやすい → ✕
• 導入しやすい → ✕

そして、2015年から現在まで利用しているのが「BigQuery」を使った分析基盤です。これまでのデータ基盤では、集計に時間が掛かってしまうために、中間テーブルや事前集計が必要でした。しかし、「BigQuery」を使った基盤では集計のスピードが速いため、何も考えずに全ての期間の全てのレコードをその都度集計することが可能です。冪等性を意識して、送信エラーが起こっても、再送信さえすれば直るように設計しています。

実際の運営にあたっては、集計した結果をDBでキャッシュ化したり、基本的なAPIを毎朝事前集計したりしていますが、基本的には極めてシンプルに構成できるようになりました。このように「BigQuery」を導入した結果、数億件の生ログも数秒で集計できるように達成し、「大量に入ってくるデータを取り回すのが煩雑である」という困りごとを解決できました。

もうひとつの困りごとは「エンジニアがSQL書きに忙殺される」ことです。これまではビジネスサイドの担当者が「SQL」を書けないために、エンジニアの負担になっているという状況にありました。これは本番環境に影響がでたり、本番DBを消してしまったりすることを避けるためでもありますが、芝尾さんは「エンジニアではなくビジネスサイドの人間がSQLを書いたほうがいい」と主張します。

それは、エンジニアの負担を軽減するためだけではありません。そもそもデータに興味があるのはビジネスサイドの人間であり、提出するレポートを作成する前の試行錯誤も知見とすべきだからです。例えば、「この結果は自明だ」とわかることも大切な知見です。

「BigQuery」で集計を行う際には、ビジネスサイドには参照権限のみ付与することが可能です。これによりビジネスサイドにも安心して「SQL」を書いてもらえるようになりました。

最後に芝尾さんは「データ分析の担当者の役割は、基盤を構築することだけではありません。社内にデータ分析の文化を育むことも重要な仕事です」と語ります。実際に芝尾さんはレベル別に「SQL」を教える講座を開催したり、データ分析学習の電子雑誌を隔月で発行したりするなどの取り組みを行っているとまとめました。

第1部の講演は以上です。第2部のレポートはこちら！

＞＞ クラウド技術最前線！【第2部】AWSの最先端クラウド技術と導入事例