GREE Tech Talk #03への参加報告

こんにちは、SSTDの高橋です。 昨日行われたGREE Tech Talk #03に参加しましたので、その内容の報告をさせて頂きます。 今回のGREE Tech Talkのテーマは、サービスづくりにおけるデータの活用でした。 ハッシュタグはこちら(#greetech03)。 下の写真は、GREEさんから頂いたジェンガです。

    当日のプログラム
  1. 『開会の挨拶』藤本 真樹(グリー株式会社)
  2. 『GREEプラットフォームにおけるビッグデータの活用』橋本 泰一(グリー株式会社 開発本部)
  3. 『アドテクノロジー業界でのデータ活用』奥野 晃裕(株式会社スケールアウト)
  4. 『データ駆動開発@トレジャーデータ』小林 隆(トレジャーデータ株式会社)
  5. 『GREEインフラでのデータ取得と使い方』田中 祥平(いわなちゃん)(グリー株式会社)
  6. 『ビッグデータを楽しむためのシステム技術と大学での最先端な試み』合田 和生(東京大学 生産技術研究所 特任准教授)


1. 開会の挨拶

藤本 真樹(グリー株式会社)

藤本さんはゲストスピーカの皆さんを楽しく分かり易く紹介して下さいました。

  1. 今回のテーマは、サービスにおけるデータ活用なので、データサイエンティストが重要です。なので、データサイエンティスト養成読本を読みましょう。
  2. →fluentdの項目はスケールアウトの奥野さんが書かれています。
  3. しかし、データを活用するためには、データを格納するストレージが重要です。ストレージと言ったら、Cassandraですよね。
  4. →オライリーのCassandra本はTreasureDataの小林さんが訳されています。
  5. そして、データをやり取りするためのネットワークも重要ですね。
  6. →よくわかるストレージネットワーキングを合田さんが書かれています。


2. GREEプラットフォームにビッグデータの活用

橋本 泰一(グリー株式会社 開発本部)

発表内容は、GREEのユーザの分析した事例紹介でした。

    <GREEのユーザについての簡易紹介>
  • GREEの国内ユーザ数:4500万人
  • 男女比:男性54%
  • 10,20,30,40代の比率:同程度(20%~30%)
上記ユーザから得られるデータの利用目的として、ユーザがよりGREEのサービスを楽しんでもらう方法を探すことにある。 そのために、ユーザ情報、アクセス情報を中心にデータ分析を行っている。

    <活用事例の紹介>
  1. ユーザやアプリのネットワーク分析
  2. メールによる情報発信の最適化

活用事例1. ユーザやアプリのネットワーク分析

分析目的:ユーザが並行して利用しているアプリは何か?

GREEユーザは、アプリを2,3個のアプリを併用している。 そこで、GREEアプリの中で、一緒に利用しているアプリ、一緒に利用しないアプリを調査する。

まず、ユーザが利用しているアプリ同士をネットワークで繋ぐことで、アプリネットワークを作成する。 このアプリネットワークは下記のように作られる。

  • アプリ間のネットワークの距離が短い=多くのユーザが二つのアプリを一緒に利用
  • アプリ間のネットワークの距離が長い=多くのユーザが二つのアプリを一緒に非利用
作成したアプリネットワークを可視化することにより、アプリネットワークがいくつかの大きなアプリネットワークに分かれていることが確認できた。 更に、上記の条件に加えて、各アプリにアプリのカテゴリ情報を追加することで、大きなアプリネットワークがどのアプリのカテゴリに属しているかも視覚化できた。 その他にも、複数の大きなアプリネットワーク同士を繋ぐハブアプリも分かるようになった。

ハブアプリとしては、育成アプリのクリノッペがある。 上記のように視覚化した際に、クリノッペがカードRPGと恋愛ゲームの二つのネットワークをつなぐアプリとなっていることを発見したとのこと。 この発見の後の施策については、話せないそうです。残念。

活用事例2. メールによる情報発信の最適化

分析目的:ユーザの目の止まるタイミングでメールを配信したい

メール配信をしても、様々なメールに埋もれてユーザに読まれないで終わってしまう。 そのため、ユーザがGREEにアクセスするタイミングに合わせて配信したいというニーズがある。 ただし、一度に配信するコストは最小にする必要あり。

そこで、ユーザに対してアクセス頻度が高い時間帯にメールを行う。そのために、アクセスログからユーザをクラスタリングし、メール配信の最適化を行った。また、メール配信の効果を測定することは難しいので、効果予測を行った。その結果、約90%のユーザに対して、アクセス頻度が5番目までの時間帯にメール配信ができるようになった。

ビッグデータ分析のポイントとして、データのサンプリングをする必要がなくなり、推測された傾向ではなく、真の傾向が明らかになることが考えられる。 しかし、分析対象期間を1時間~1日、1週間~2週間、1年間など、それぞれの期間で見るべきデータが異なるので、単一の分析基盤ではなく、複数の分析基盤で対応することが必要だそうです。


3. アドテクノロジー業界でのデータ活用

奥野 晃裕(株式会社スケールアウト)

以下の3点について紹介されました。

  1. アドテクノロジーについて
  2. 集計システムの紹介
  3. システム構築のポイント

1. アドテクノロジーについて

アドテクノロジーの基礎知識の説明もありましたが、ここでは割愛します。 ポイントとしては、ディスプレイ広告の対象が、どこに広告を配信するかではなく、誰に広告を配信するかに変化したことにある。 この変化により、ユーザの情報を一元管理するためのDMP(Data Management Platform)が生まれた。

2. 集計システムの紹介

スケールアウトさんでは、ユーザの情報を得るための計測タグやbeaconなどをngixのアドサーバによって集約し、ユーザIDによってアドサーバ群にルーティングする構成になっている。このシステムで、1日20億レコード、ピーク時には秒間3000レコード、トータルで400TB(レプリケーション含む)を処理している。

処理基盤として社内システムであるTasks、それにHadoopの二つで処理を回している。 Tasksとは、単純集計をリアルタイムで出力するためのシステムです。単純集計処理をローテーションで行い、中間集計を大量に作成し、中間集計を元に管理画面でレポートを作成してお客さんに提供するという流れになっている。 アドサーバでTasksに処理させることで、データの移動が発生しないといったメリットがある。ただし、Joinなどの重い処理はできない。

Hadoop(hive/pig)では、アドホックにデータ分析をしたい場合や、ユーザをまたぐ処理、事前に処理時間が分からない処理に対して用いるとのこと。

リアルタイム系とアドホック系の処理とでシステムを分けているところが集計システムのポイントの一つ。

3. システム構築のポイント

システム構築の前提条件として、集計漏れ/数値ずれは許容できない。 集計結果はユーザに渡す商品であり、特にコンバージョンは数が少ないので、漏れは致命的になってしまう。

そこで、エラー/バグは起きるものとして以下の点に注意してシステム構築を行うことを推奨する。

  • 検証性⇒早く気付くため
    • 結果が検証可能であること→再現可能にする、処理系統をシンプルにする
    • 二系統での監視→HadoopとTasksで同一の値になるかどうか
  • 再実行性⇒早く調べるため
    • どの時間帯でも再実行できる→どの中間状態からでも再実行可能、実行同士が影響しない、そのためには、不変な中間結果を積み上げていくのが良いのではないかな。
    •  
    • 一括のクエリで書くのではなく、複数にわざと分けて実行させる。
  • リカバリ性⇒早く直すため
    • エラー修正時の輻輳を避ける→処理時間タイムスロットの1/3を目安に

今後の目標は、処理基盤として、ストリーミング・リアルタイム処理や低レイテンシクエリ、fluentdを実装したい。 データ解析として、bidの最適化や広告出稿の改善によるユーザ拡張、BI環境の整備を行いたい。 最後に、この処理基盤をたった3人で回しているので、絶賛社員募集中とのこと。(たった3人ですごい…)

ちなみに発表の冒頭で紹介があった日本のディスプレイ広告領域のカオスマップはこちら。


4. データ駆動開発@トレジャーデータ

小林 隆(トレジャーデータ株式会社)

OSSとして、huahinを公開しているそうです。TreasureDataのエンジニアは8/25名だそうです。

発表の見所は、Impala on TreasureDataのデモです。 TableauからTreasureDataにつないで、データの取得をしているところを見せて頂きましたが、相当速いですね。 まだ、社内ベータだそうですが、リリースに期待です。

TreasureDataのサービスについての説明です。概要についてはTreasureDataさんのSlideShareをチェックして頂ければと思います。 TreasureDataと他サービスとの違いの例として、Redshiftとの比較をされていました。 RedshiftはDBを利用しているのでスキーマを決める必要があるが、TreasureDataは決めずに取り込み、取り出す時にスキーマを決めればよいという点が異なる。その他に、TreasureDataには現在1兆レコードが格納されているとのこと。

TreausureDataでは、サービス監視にlibratoを利用している。 libratoについては、TreasureDataの中川さんのブログで詳しく説明されています。このlibratoに対して、fluentdでhadoopの状態やジョブの状態等を吐き出し、監視している。

TreasureDataさんがslideshareに公開している最新のスライドを掲載させて頂きます。


5. GREEインフラでのデータ取得と使い方

田中 祥平(いわなちゃん)(グリー株式会社)

インフラ監視についての発表でした。 GREEのインフラ監視システムについては、こちらのGREEエンジニアブログにて紹介されています。 従来のインフラ監視は、人出で行われることが主であり、アラートが発生してから対応することやエキスパートによる障害の未然防止などに頼ってしまうという問題があった。

まず、理想の監視とは、エキスパートでなくてもわかる障害発生の指標など共通の言語を作ることや、障害発生の危険値の閾値を提示しなくても教えてくれることである。そこでGREEでは、sysloadという指標を作った。これ一つで完全に障害を防げれるわけではないが、障害防止のためにエンジニア以外と話す時でも、共通の指標を使うことで話が少しスムーズに通るようになった。

real user monitoringを現在開発している。 これは、レスポンスタイム≠ユーザの表示時間なので、サービス側に測定用Javascriptを埋め込んでもらうことで、何に時間がかかったかを測定している。 これにより、サーバ側の処理よりもユーザ側のレンダリングに時間がかかっている可能性も高いので、ユーザ側の問題を発見することができる。

上記の他に田中さんがGREEに入社してから行ったこととして、GREEの配信システムをVarnish Cacheに置き換える仕事していたそうです。そのVarnishについての田中さんのブログ記事とスライドも掲載させて頂きます。


6. ビッグデータを楽しむためのシステム技術と大学での最先端な試み

合田和生(東京大学 生産技術研究所 特任准教授)

こちらの発表のポイントは、ビッグデータを処理するためには、ストレージをいかに賢くするかについてです。 発表中で紹介されたストレージについてのスライドは、こちら

データセンサの技術トレンドは、トランジスタの数は増えており、ディスクの大容量化も続くが、高速化は停滞している。 そのため、データへのアクセスはどんどん辛くなってきており、データセンタの投資は、データの器であるストレージへの投資の割合が増えている。 こうした背景から、ビッグデータ時代のシステム技術は、演算思考からデータ入出力指向へと変遷している。

ストレージシステムは、ビッグデータの賢い器になる。サーバを中心に考えるのではなく、ディスクを中心に考える。 つまり、巨大なストレージにサーバをたくさんくっつける。ストレージは、read/write以上のデータ管理システムになっている。

データベースエンジンは、ビッグデータを縦横無尽に触れる。 現在開発中の新型データベースエンジンの対象領域は、アウトオブオーダ型実行方式(従来の索引方式やハッシュクラスタリング方式の中間)。 アウトオブオーダ型実行方式は、IO駆動型実行エンジンであり、大量の非同期IOを発行する。そのため、中程度の選択率クエリにおいて大幅な性能向上が達成できる。しかし、非同期のため実行する度に順序が変わってしまう可能性もあるが、それはある程度許容してあげる。 このエンジンによって、128台のストレージを1つのクエリで使い切ることができる。

現在は、研究成果を市場へ出していて、日立さんが製品化しているそうです。その製品はDaTa SuperExpressかと思います。


DaTa SuperExpressのシステム構成(日立の発表資料より引用)

この日帰宅後にテレビをつけると、NHKで震災ビッグデータの番組を放送していました。 その中で、震災に関連するTwitterのつぶやきを肯定的な意見と否定的な意見のネットワークに分類するという話をしていました。 まさに、GREEの橋本さんのアプリネットワークの内容と同様でした。

放送の中では、否定的なつぶやきのネットワークには、オピニオンリーダというネットワークの中心となる人物がおり、そのオピニオンリーダのつぶやきがリツイートされるなどして、ネットワークに波及していく様子を伝えていました。

またそこで終わらず、この放送ではその否定的なつぶやきのオピニオンリーダの中には、だんだんと肯定的なつぶやきのネットワークに近づいている人もおり、そのオピニオンリーダにスポットを当てて調査していました。 その調査の結果は、このオピニオンリーダが、ある時、実際に福島県にいき、福島の食品を食べたりしたことによって意見が変化したことが原因だったそうです。

このように、データ全体を漠然とみるだけでなく、データの中から変化や異常を発見し、ドリルダウンをしていくことで、更なる知見が得ることが重要ですね。また、その知見から次に何をどうするのかまで提案できるようになることが重要だと思います。

以上で終わります。またどこかのイベントでお会いしましょう。

執筆:髙橋@SSTD