GunosyでのKinesis Analytics利用について / AWS Solution Days 2017 -AWS DB Day-

Transcript

1. GunosyでのKinesis Analytics利⽤について
   株式会社Gunosy
   ⼩出 幸典
   

   View Slide

2. ⾃⼰紹介
   • 名前
   – ⼩出 幸典 （こいで ゆきのり）
   • 所属
   – 株式会社Gunosy
   • 好きなAWSサービス
   – OpsWorks, Lambda, Kinesisファミリー, ECS
   

   View Slide

3. 株式会社Gunosy – 「情報を世界中の⼈に最適に届ける」
   Gunosyは 情報キュレーションサービス「グノシー」と
   2016年6⽉1⽇にKDDI株式会社と共同でリリースした
   無料ニュース配信アプリ「ニュースパス」を提供する
   会社です。「情報を世界中の⼈に最適に届ける」を
   ビジョンに活動しています。
   ネット上に存在するさまざまな情報を、
   独⾃のアルゴリズムで収集、評価付けを⾏い
   ユーザーに届けます。
   情報キュレーションサービス
   「グノシー」
   600媒体以上のニュースソースをベースに、
   新たに開発した情報解析・配信技術を⽤いて⾃動的に
   選定したニュースや情報をユーザーに届けます。
   無料ニュース配信アプリ
   「ニュースパス」
   

   View Slide

4. Gunosyと機械学習・データ分析
   • Gunosyでは、様々な情報を収集し、独⾃のアルゴリズム
   で評価付けを⾏い、ユーザに届けています
   各種コンテンツ
   (記事、商品、動画)
   

   View Slide

5. Gunosyと機械学習・データ分析
   • ユーザの⾏動から、属性（年齢・性別・etc）を推定し、
   コンテンツとのマッチングを⾏っています
   各種コンテンツ
   (記事、商品、動画)
   性別
   年齢
   地域...
   カテゴリ
   著者
   地域性...
   

   View Slide

6. Gunosyと機械学習・データ分析
   • 本⽇はニュース領域での事例についてお話させて頂きます
   各種コンテンツ
   (記事、商品、動画)
   

   View Slide

7. 本⽇お話させていただく内容
   Gunosyでどのように
   Kinesis Analyticsを利⽤しているか
   

   View Slide

8. なぜストリーム処理/マイクロバッチ処理をしたいのか
   • 「情報を世界中の⼈に最適に届ける」
   – 時間(鮮度)の制約
   • 情報には「鮮度」がある
   – 頻度(量)の制約
   • ⾒せられる情報量には限りがある
   • どういった⼈に、どういった情報が適しているのか
   – 事前に「どのぐらい読まれそうか」といった推定はしているが、
   ⾄近の実績値も即座にサービスにフィードバックしたい
   – より短い時間・より少ない試⾏で、サービスに反映したい
   

   View Slide

9. 例えば
   • 記事クリックの(ニア)リアルタイム算出
   – 「⼤域的な」傾向を掴みたい
   

   View Slide

10. Gunosyでのストリーム集計の右往左往
    • 2013 mongodb Capped Collections
    • 2014 Redshift
    – fluentdのflush intervalが短すぎるとcopyが詰まってくる
    • 2015 Norikra
    – 知⾒が無さすぎて運⽤がままならず
    – 我々には早かった
    • 2016 Kinesis+Spark Streaming (on EMR)
    – ⾃由度は⾼い⼀⽅、開発コスト⾼し、サーバコスト⾼し
    – 我々にはオーバースペックだった
    

    View Slide

11. 本題
    Kinesis Analyticsの適⽤
    

    View Slide

12. ざっくりとした構成
    • 以前よりfluentdを利⽤してログ配送をしていた
    – 同じログをStreams/Firehoseに送る
    • fluent-plugin-kinesis
    • Kinesis Analyticsはまだ東京へは来ていないので、他リージョンへ
    Web servers
    (fluentd)
    Kinesis
    Firehose
    S3
    (backup)
    Kinesis
    Analytics
    Elastic Search
    Service
    summary
    log
    Mobile
    apps
    Source
    Stream
    log
    Tokyo Oregon
    Kinesis
    Firehose
    

    View Slide

13. Reference Dataの追加
    • ユーザのセグメント別の集計
    – どういったユーザが興味を⽰しているのか
    • S3にセグメント情報を配置
    • ログにセグメント情報を付加し、セグメント別に集計
    S3
    User–Data
    Reference
    Data
    Web servers
    (fluentd)
    Kinesis
    Firehose
    S3
    (backup)
    Kinesis
    Analytics
    Elastic Search
    Service
    summary
    log
    Mobile
    apps
    Source
    Stream
    log
    Kinesis
    Firehose
    

    View Slide

14. SQL例
    • ⼀度中間ストリームを作る
    – Source StreamとReference DataをJOIN
    

    View Slide

15. SQL例
    • 中間ストリームのデータを1分おきに集計して、出⼒へ
    

    View Slide

16. クエリ結果のイメージ
    • ユーザのセグメント毎に、傾向を知ることができる
    

    View Slide

17. サービスへのフィードバック（出⼒）
    • 現在のところバッチサーバからESSへ取りに⾏っている
    – ESSはIAM Roleでアクセス制御できる
    • クロスリージョンやVPCを意識しなくて良い
    – ESの集計関数が使える
    Web servers
    (fluentd)
    Kinesis
    Firehose
    S3
    (backup)
    Kinesis
    Analytics
    Elastic Search
    Service
    summary
    log
    Mobile
    apps
    Source
    Stream
    log
    Tokyo Oregon
    Kinesis
    Firehose
    Batch
    Server
    Tokyo
    

    View Slide

18. Tips
    

    View Slide

19. 東京リージョンのStreamsから他リージョンへの転送
    • クライアントから直接ログを投げ込んでいるケース
    – 余り⼿をかけてコンシューマを開発したくない
    • Lambdaも試したが、スループットの⾯で厳しかった
    Kinesis
    Streams
    log
    Mobile
    apps
    Tokyo Oregon
    Kinesis
    Streams
    ?
    

    View Slide

20. 東京リージョンのStreamsから他リージョンへの転送
    • コンシューマとしてfluentdを利⽤
    – inputプラグインで東京のStreamsから取り出し
    • outputプラグインで他リージョンのStreams/Firehoseへ転送
    • タグによるルーティングや、必要に応じて整形を実施
    Kinesis
    Streams
    Mobile
    apps
    Tokyo Oregon
    Kinesis
    Streams
    fluentd
    server
    

    View Slide

21. 利⽤していての所感
    

    View Slide

22. まとめ
    • 開発が楽になった
    – IAMの設定は⼤変だが省⼒化できる
    – クエリだけ集中して考えれば良い
    • 運⽤も楽になった
    – フルマネージド
    – 但し、前後(Streams/Firehose)の流量には注意
    • サーバコストも安くなった
    – ※もちろん、ケース次第です
    → トータルコストの削減+デリバリの短縮へ
    

    View Slide

23. 宣伝
    • エンジニアブログやっています
    http://data.gunosy.io/
    http://tech.gunosy.io/
    

    View Slide

24. 終わりに
    • ご清聴ありがとうございました
    

    View Slide