• 株式会社スマートエデュケーション
  • CTO
  • 谷川 裕之

アプリ50本分のアクセスログも一元管理! BigQueryは「最強」のデータ解析サービス

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

今回のソリューション:【GoogleBigQuery/グーグルビッグクエリ】

Webサービスやネイティブアプリの運用者を常に悩ませてきたのが、アクセスログの管理・解析の手法だ。これまで様々なデータベースが世の中に登場してきたが、共通して言えたのは、データ量が増えれば増えるほど解析スピードが鈍化するということだった。

それに対処するためサーバーに高額な投資かけると、結果的に管理コストが膨らむことも課題であった。

そこに革命を起こしたのが、 Google Cloud Platform が提供するビッグデータ解析サービス「Google BigQuery(以下、BigQuery)」だ。BigQueryを使うと、数テラバイトのデータに対しても僅か数秒で SQLクエリを実行することができる。

とにかく高速で、しかも安い。Googleの革命的な大量データ分析用テクノロジーを存分に活かしたサービスだ。

「おやこでスマほん」や「おやこでリズムえほん」といった、親子で遊べる乳幼児や子ども向けの教育・知育アプリを提供している株式会社スマートエデュケーション。同社では現在50本以上のアプリを運用し、その累計ダウンロード数は1,500万を突破した。

そして、そのアクセスログをすべて管理しているのがBigQueryだ。同サービスの高速パフォーマンスを活かし、Google スプレッドシートとの合わせ技で様々な指標がリアルタイムに可視化される仕組みを構築している。

同社でCTOを務める谷川 裕之さんに、「最強」と語るBigQueryについて、詳しいお話を伺った。

夢を見て大企業を飛び出し、最初は後悔するも… 

弊社は2011年に5人で設立した会社なのですが、私は最初、フリーのエンジニアとして協力していました。現在はCTOを務めています。

新卒で就職するときはいわゆる「SE大量採用」の時代で、比較的大きな会社にシステムエンジニアとして就職し、製造関連の業務システムの開発などに関わりました。

ただ個人的にはInstgramのようなWebサービスが大好きで、toCのビジネスにどうしても関わりたくなってきたんです。そこで28歳の時に思い切って、とあるWeb系のベンチャーに転職しました。

その時はただ夢を抱いて飛び出したのですが、そうしたら、その会社が超ブラックで(笑)。入社した初日から徹夜だったんですよ。全然終わらなくて、帰れない。衝撃でしたね。

それまでは変な話、ただ1日座っていれば良かったというか、担当の画面をコーディングしたらそれで終わり。

でもベンチャーの場合は全て自分でする必要がありますし、仕様書もないまま口頭ベースで仕事がどんどん進んでいく。最初のうちは技術もそこまでなく、働きながら学んでいったので本当に大変でした。

その後、フリーランスとして活動していく中でスマートエデュケーションの創業メンバーに出会いました。一緒に創業することを決めた理由は、他にはない「専業で子ども向けのサービスを作る」というビジネスに面白さとオリジナリティーを感じたからです。

もともと世界を目指したいという気持ちがあったのですが、この領域であればそれが可能なのではないかと思ったことも大きかったです。

新領域での挑戦には参考指標がなく、試行錯誤しながらKPI設定

これまで50本近くのアプリをリリースしてきましたが、そのアクセス解析に関しては、手探りでいろいろ試行錯誤してきました。

そもそも世の中になかったサービスを作っていったので、参考にすべき数値も分からなくて。

教育というカテゴリー全体の規模感の中で、どのくらいであれば良いのか悪いのか、判断できなかったですね。アプリを20個以上運用するようになってようやく、アプリ同士の比較からある程度基準が見えてきたという感じです。

弊社のアプリは、寿命が長いことがひとつの特徴かなと思います。2、3年のレンジで長く使ってくださるユーザーの方も多くて、一番最初にリリースしたアプリもまだ運用しています。

古い技術が使われてしまっているので、エンジニア的にはちょっと嫌なんですけれども(笑)。でもありがたいことですよね。

新しいアプリをリリースすればするだけ総アクセスログの量が増えていくという状態になるので、それに合わせてデータベースの設計やデータ解析の仕組みも何度も見直してきたという背景があります。

SQLが3時間返ってこない… 想定外の膨大なログ管理に苦しむ

実は今回のBigQueryの導入は、データベースに関して4度目の作り直しなんです。最初はログを単純にデータベースに乗せて、バッチ処理をかけて、サマリーの数値を管理画面で見るような形にしていました。

その後はレコード単位のinsertやupdateをMongoDBで受けて、Redshiftにデータをエクスポートするような仕組みを作ったり。

基本的なKPIは毎朝メールで通知されるようにして、それとは別に欲しい数字がある時には各自でクエリを叩いて取ってきていました。弊社のビジネスサイドのメンバーって元SEの人が多くて、SQLが書けちゃうんですよ。

どうして4回も作り直すはめになったのかというと、そもそもこんなにアプリの数が増えることを想定していなかったんですね。数が増えれば増えるほど、データ取得に時間がかかるようになって…。「SQL投げて3時間くらい返ってこない…」みたいな事態が起こるようになってしまいました。

データベースのパフォーマンスが悪すぎて、皆ちょっと諦めムードというか。集計に時間もかかるし、このデータ本当に正しいのかな? って。しかも集計エラーのような問題がしょっちゅう起こるので、その度にエンジニアが調べたり、改修したり…。

アプリ開発と並行してそれに対応するのは、結構きつかったですね。そこで、もう一度思い切って作り直そうということで、2015年の2月にBigQueryを導入しました。

BigQueryとスプレッドシートで、あらゆる指標を可視化!

BigQueryを選定した理由としては、スケーラビリティの高さ、処理スピードです。以前は僕たち、生ログから中間ログをいくつか作ってデータベースを構築していたんです。

でもBigQueryであれば、生ログから直結してダイナミックにさばいてくれるんですよね。ポンと投げたら、すぐに返ってくる。

簡単なクエリだったら数秒ですね。速いし正確だし、問題が起こりにくい。以前は何かあったら中間部分も全部、直していたんですよね。それがなくなって、エンジニアがほぼ何もメンテナンスしなくていいようになりました。

このパフォーマンスの速さを活かして、今はBigQueryとGoogleスプレッドシートと組み合わせて、様々な数値を可視化しています。この仕組みは、Google Apps Scriptを使って構築しました。

####▼スプレッドシートにあらゆる指標がグラフとして可視化される

アプリ名を指定して、デイリーやマンスリーといった集計単位、期間、欲しい指標を選べば、すぐにスプレッド上にグラフが出てきます。MAU、DAU、アクティブ率など様々な指標を用意していて、ビジネスサイドで必要な情報はほぼ網羅できている状態です。

より複合的な条件の元で数字を出したい時だけ、BigQueryに直接SQLライクのクエリを叩いているイメージです。

データ周りのエンジニア工数はほぼゼロに!

この仕組みを構築するのには、通常業務との平行作業で12週かかりました。これだけ時間がかかったのは、まずはBigQueryを調べるところから始めたことと、それまであちこちに散らばっていたデータをまとめるのに手間がかかったということもあります。

でも結果的に、データ周りにかかるエンジニア工数は劇的に削減できました。エンジニアはほぼ、何もしなくて良くなったんです。だから開発工数をかけただけのことはありましたね。

世の中にアクセス解析のツールは数多くあると思うのですが、スプレッドシートもけっこういいですよ。何より自分たちの好きなようにカスタマイズできるのが利点ですね。外部の協力会社さんだったり、数字を全部見せられない方もいるじゃないですか。そういった場合には集計シートを分ければいいので、手間もかかりません。

コストを下げてパフォーマンスを上げる 「最強」のBigQuery

コスト面でも大きなメリットがありました。というのも、以前はパフォーマンスを出すために結構いいデータベースにサーバーを乗せていて、そこにかなりお金がかかっていて。

でもBigQueryであればそのサーバーコストは不要なので、率直に言うと全体的なコストで10分の1ほどになりました。

BigQueryは、本当にGoogleさんの持っている中でも最強のサービスだと思いますね!本当に、これ以上スケールできるものは他にはありません。

弊社では今、大体50本分のアプリプラットフォームのアクセスログを入れていますが、これだけ突っ込んでもレスポンス速度は変わらない。すごすぎます(笑)。

とにかく大きいデータを持っていてその扱いに困っている、という会社さんにはBigQueryは本当にオススメですね。クエリの保存もできるので、弊社のようにスプレッドシートまで準備しなくても、必要指標の定期的な集計も簡単です。かなり複雑なクエリでもすぐに返ってきますしね。

弊社のメンバーでも「どうやってやったんだろう…」って思うような長いSQLライクなクエリを書いて、継続率をパッと出している人とか、いますよ。そこは比較的自由にできるので、そういった意味でも使い勝手がいいなと。

今後はサービス改善のための細かいログも集計していきたい

これまではビジネスサイド寄りの指標しか取っていないのですが、今後はもっとサービスの改善に活かせるような細かい数値を見られるようにしていきたいです。

例えばボタンにコンバージョンログを仕込んでおけば、それを押した人がどのようにページ遷移しているかといった情報もスプレッドシートに集約できるので。

アプリがどのように使われているのか、もっと細かく知りたいと思っています。ユーザーが子どもだということもあって、まだはっきりと分からない部分も多いんですよ。

BigQueryとスプレッドシートを組み合わせることで、本当になんでもできてしまいます。現場からも色々な要望をもらっているので、引き続きこの仕組みをブラッシュアップさせていきたいと思っています。(了)

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet