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

Transcript

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

2. ⾃⼰紹介 • 名前 – ⼩出 幸典 （こいで ゆきのり） • 所属

   – 株式会社Gunosy • プロビジョニング・デプロイフローの共通化とか • 過剰リソース警察、コスト削減おじさん • 好きなAWSサービス – OpsWorks, Lambda, Kinesisファミリー, 最近ちょこっとECS

3. 株式会社Gunosy – 「情報を世界中の⼈に最適に届ける」 • Gunosyは 情報キュレーションサービス「グノシー」と • 2016年6⽉1⽇にKDDI株式会社と共同でリリースした 無料ニュース配信アプリ「ニュースパス」を提供する •

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

4. 宣伝：データ分析ブログやっています http://data.gunosy.io/

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

6. なぜストリーム処理/マイクロバッチ処理をしたいのか • 「情報を世界中の⼈に最適に届ける」 – 時間(鮮度)の制約 • 情報には「鮮度」がある – 頻度(量)の制約 •

   ⾒せられる情報量には限りがある • どういった⼈に、どういった情報が適しているのか – 事前に「誰にどのぐらい読まれるか」等の推定はしているが、⾄近 の実績値も評価に利⽤したい – より短い時間・より少ない試⾏で、実績値を集めたい

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

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

9. Gunosyでの右往左往 • 2013 mongodb+マイクロバッチで頑張っていた • 2014 Redshift+マイクロバッチで頑張っていた – fluentdのflush intervalが短すぎるとcopyが詰まる

   – クエリ投げすぎても詰まる余り⾼頻度にできない • 2015 Norikraで頑張っていた – 度々⽌まるが知⾒無さすぎ→監視も復旧⾃動化もままならず – 我々には早かった • 2016 Spark Streamingで頑張っていた – ⾃由度⾼いけど開発コスト⾼し、インフラコスト⾼し – 我々にはオーバースペックだった 本⽇は割愛

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

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

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

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

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

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

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

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

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

    Mobile apps Tokyo Oregon Kinesis Streams ?

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

    Streams Mobile apps Tokyo Oregon Kinesis Streams fluentd server

20. 利⽤していての所感

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

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

23. まとめ • 開発が楽 – ほとんどConfig芸（IAMは⼤変） – クエリだけ集中して考えられる • 運⽤も楽 –

    フルマネージド – 前後(Streams/Firehose)の流量は注意 • コストも安い – （ケース次第ですが）

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