GunosyでのKinesis Analytics利用について / BigData JAWS 6 Kinesis Analytics

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. 宣伝：データ分析ブログやっています
   http://data.gunosy.io/
   

   View Slide

5. 本⽇お話させていただく内容
   Gunosyでどういった感じで
   Kinesis Analyticsを利⽤しているか
   

   View Slide

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

   View Slide

7. 例えば
   • 記事クリックの(ニア)リアルタイム算出
   – 「⼤域的な」傾向はわかる
   

   View Slide

8. 例えば
   • 「⼤域的な」!= 全てのユーザ
   – それぞれどういった⼈に適しているのか
   

   View Slide

9. Gunosyでの右往左往
   • 2013 mongodb+マイクロバッチで頑張っていた
   • 2014 Redshift+マイクロバッチで頑張っていた
   – fluentdのflush intervalが短すぎるとcopyが詰まる
   – クエリ投げすぎても詰まる余り⾼頻度にできない
   • 2015 Norikraで頑張っていた
   – 度々⽌まるが知⾒無さすぎ→監視も復旧⾃動化もままならず
   – 我々には早かった
   • 2016 Spark Streamingで頑張っていた
   – ⾃由度⾼いけど開発コスト⾼し、インフラコスト⾼し
   – 我々にはオーバースペックだった
   本⽇は割愛
   

   View Slide

10. 本題
    Kinesis Analyticsを利⽤してみた
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

15. クエリ結果のイメージ
    • （再掲）
    

    View Slide

16. サービスへのフィードバック（出⼒）
    • 現在のところバッチサーバからESSへ取りに⾏っている
    – 突如ストリーム感が無くなったのは内緒
    • ESSはIAM Roleでアクセス制御できる（VPCを考えなくて良い）
    • ESの集計関数が使える
    Web servers
    (fluentd)
    Kinesis
    Firehose
    S3
    (backup)
    Kinesis
    Analytics
    Elasticsearch
    Service
    summary
    log
    Mobile
    apps
    Source
    Stream
    log
    Tokyo Oregon
    Kinesis
    Firehose
    Batch
    Server
    Tokyo
    

    View Slide

17. 苦労/⼯夫したところなど
    

    View Slide

18. 東京リージョンのStreamsから他リージョンへの転送
    • クライアントから直接ログを投げ込んでるケース
    – コンシューマ書きたくない
    • Lambdaで頑張ろうと思ったけどスループット厳しかった
    Kinesis
    Streams
    log
    Mobile
    apps
    Tokyo Oregon
    Kinesis
    Streams
    ?
    

    View Slide

19. 東京リージョンのStreamsから他リージョンへの転送
    • コンシューマとしてfluentdを利⽤
    – inputプラグインで東京のStreamsから取り出し
    • outputプラグインで他リージョンのStreams/Firehoseへ転送
    • ついでにタグルーティングも
    Kinesis
    Streams
    Mobile
    apps
    Tokyo Oregon
    Kinesis
    Streams
    fluentd
    server
    

    View Slide

20. 利⽤していての所感
    

    View Slide

21. こうなると嬉しい
    • Source Stream
    – 1つのApplicationで複数のStreamを読み込めると嬉しい
    • 同じログを何度も別のStreamに書くのは冗⻑感がある
    fluent
    server
    Tag: A+B Application
    1
    Tag: A+C Application
    2
    Tag: B+C Application
    3
    fluent
    server
    Tag: A Application
    1
    Tag: B Application
    2
    Tag: C Application
    3
    

    View Slide

22. こうなると嬉しい
    • Reference Data
    – Console上で追加できると嬉しい
    – Console上で⾒えると嬉しい（サンプルだけでも良いので…）
    

    View Slide

23. まとめ
    • 開発が楽
    – ほとんどConfig芸（IAMは⼤変）
    – クエリだけ集中して考えられる
    • 運⽤も楽
    – フルマネージド
    – 前後(Streams/Firehose)の流量は注意
    • コストも安い
    – （ケース次第ですが）
    

    View Slide

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

    View Slide