gunosyでのkinesis analytics利⽤について - …...2017/07/05 · 紹介 • 名前 –...
TRANSCRIPT
GunosyでのKinesis Analytics利⽤について
株式会社Gunosy⼩出 幸典
⾃⼰紹介
• 名前– ⼩出 幸典 （こいで ゆきのり）
• 所属– 株式会社Gunosy
• 好きなAWSサービス– OpsWorks, Lambda, Kinesisファミリー, ECS
株式会社Gunosy – 「情報を世界中の⼈に最適に届ける」
Gunosyは 情報キュレーションサービス「グノシー」と
2016年6⽉1⽇にKDDI株式会社と共同でリリースした無料ニュース配信アプリ「ニュースパス」を提供する
会社です。「情報を世界中の⼈に最適に届ける」を
ビジョンに活動しています。
ネット上に存在するさまざまな情報を、独⾃のアルゴリズムで収集、評価付けを⾏いユーザーに届けます。
情報キュレーションサービス
「グノシー」
600媒体以上のニュースソースをベースに、新たに開発した情報解析・配信技術を⽤いて⾃動的に選定したニュースや情報をユーザーに届けます。
無料ニュース配信アプリ
「ニュースパス」
Gunosyと機械学習・データ分析
• Gunosyでは、様々な情報を収集し、独⾃のアルゴリズムで評価付けを⾏い、ユーザに届けています
各種コンテンツ(記事、商品、動画)
Gunosyと機械学習・データ分析
• ユーザの⾏動から、属性（年齢・性別・etc）を推定し、コンテンツとのマッチングを⾏っています
各種コンテンツ(記事、商品、動画)
性別年齢地域...
カテゴリ著者地域性...
Gunosyと機械学習・データ分析
• 本⽇はニュース領域での事例についてお話させて頂きます
各種コンテンツ(記事、商品、動画)
本⽇お話させていただく内容
GunosyでどのようにKinesis Analyticsを利⽤しているか
なぜストリーム処理/マイクロバッチ処理をしたいのか
• 「情報を世界中の⼈に最適に届ける」– 時間(鮮度)の制約
• 情報には「鮮度」がある– 頻度(量)の制約
• ⾒せられる情報量には限りがある
• どういった⼈に、どういった情報が適しているのか– 事前に「どのぐらい読まれそうか」といった推定はしているが、
⾄近の実績値も即座にサービスにフィードバックしたい– より短い時間・より少ない試⾏で、サービスに反映したい
例えば
• 記事クリックの(ニア)リアルタイム算出– 「⼤域的な」傾向を掴みたい
Gunosyでのストリーム集計の右往左往
• 2013 mongodb Capped Collections• 2014 Redshift
– fluentdのflush intervalが短すぎるとcopyが詰まってくる• 2015 Norikra
– 知⾒が無さすぎて運⽤がままならず– 我々には早かった
• 2016 Kinesis+Spark Streaming (on EMR)– ⾃由度は⾼い⼀⽅、開発コスト⾼し、サーバコスト⾼し– 我々にはオーバースペックだった
本題
Kinesis Analyticsの適⽤
ざっくりとした構成
• 以前よりfluentdを利⽤してログ配送をしていた– 同じログをStreams/Firehoseに送る
• fluent-plugin-kinesis• Kinesis Analyticsはまだ東京へは来ていないので、他リージョンへ
Web servers (fluentd)
Kinesis Firehose
S3(backup)
Kinesis Analytics
Elastic Search Service
summary
logMobileapps
Source Stream
log
Tokyo Oregon
Kinesis Firehose
Reference Dataの追加
• ユーザのセグメント別の集計– どういったユーザが興味を⽰しているのか
• S3にセグメント情報を配置• ログにセグメント情報を付加し、セグメント別に集計
S3User–Data
Reference Data
Web servers (fluentd)
Kinesis Firehose
S3(backup)
Kinesis Analytics
Elastic Search Service
summary
logMobileapps
Source Stream
log
Kinesis Firehose
SQL例
• ⼀度中間ストリームを作る– Source StreamとReference DataをJOIN
SQL例
• 中間ストリームのデータを1分おきに集計して、出⼒へ
クエリ結果のイメージ
• ユーザのセグメント毎に、傾向を知ることができる
サービスへのフィードバック（出⼒）
• 現在のところバッチサーバからESSへ取りに⾏っている– ESSはIAM Roleでアクセス制御できる
• クロスリージョンやVPCを意識しなくて良い– ESの集計関数が使える
Web servers (fluentd)
Kinesis Firehose
S3(backup)
Kinesis Analytics
Elastic Search Service
summary
logMobileapps
Source Stream
log
Tokyo Oregon
Kinesis Firehose
BatchServer
Tokyo
Tips
東京リージョンのStreamsから他リージョンへの転送
• クライアントから直接ログを投げ込んでいるケース– 余り⼿をかけてコンシューマを開発したくない
• Lambdaも試したが、スループットの⾯で厳しかった
Kinesis Streams
logMobileapps
Tokyo Oregon
Kinesis Streams
?
東京リージョンのStreamsから他リージョンへの転送
• コンシューマとしてfluentdを利⽤– inputプラグインで東京のStreamsから取り出し
• outputプラグインで他リージョンのStreams/Firehoseへ転送• タグによるルーティングや、必要に応じて整形を実施
Kinesis Streams
Mobileapps
Tokyo Oregon
Kinesis Streams
fluentdserver
利⽤していての所感
まとめ
• 開発が楽になった– IAMの設定は⼤変だが省⼒化できる– クエリだけ集中して考えれば良い
• 運⽤も楽になった– フルマネージド– 但し、前後(Streams/Firehose)の流量には注意
• サーバコストも安くなった– ※もちろん、ケース次第です
→ トータルコストの削減+デリバリの短縮へ
宣伝
• エンジニアブログやっています
http://data.gunosy.io/
http://tech.gunosy.io/
終わりに
• ご清聴ありがとうございました