GunosyでのKinesis Analytics利⽤について株式会社Gunosy⼩出 幸典
View Slide
⾃⼰紹介• 名前– ⼩出 幸典 (こいで ゆきのり)• 所属– 株式会社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)KinesisFirehoseS3(backup)KinesisAnalyticsElastic SearchServicesummarylogMobileappsSourceStreamlogTokyo OregonKinesisFirehose
Reference Dataの追加• ユーザのセグメント別の集計– どういったユーザが興味を⽰しているのか• S3にセグメント情報を配置• ログにセグメント情報を付加し、セグメント別に集計S3User–DataReferenceDataWeb servers(fluentd)KinesisFirehoseS3(backup)KinesisAnalyticsElastic SearchServicesummarylogMobileappsSourceStreamlogKinesisFirehose
SQL例• ⼀度中間ストリームを作る– Source StreamとReference DataをJOIN
SQL例• 中間ストリームのデータを1分おきに集計して、出⼒へ
クエリ結果のイメージ• ユーザのセグメント毎に、傾向を知ることができる
サービスへのフィードバック(出⼒)• 現在のところバッチサーバからESSへ取りに⾏っている– ESSはIAM Roleでアクセス制御できる• クロスリージョンやVPCを意識しなくて良い– ESの集計関数が使えるWeb servers(fluentd)KinesisFirehoseS3(backup)KinesisAnalyticsElastic SearchServicesummarylogMobileappsSourceStreamlogTokyo OregonKinesisFirehoseBatchServerTokyo
Tips
東京リージョンのStreamsから他リージョンへの転送• クライアントから直接ログを投げ込んでいるケース– 余り⼿をかけてコンシューマを開発したくない• Lambdaも試したが、スループットの⾯で厳しかったKinesisStreamslogMobileappsTokyo OregonKinesisStreams?
東京リージョンのStreamsから他リージョンへの転送• コンシューマとしてfluentdを利⽤– inputプラグインで東京のStreamsから取り出し• outputプラグインで他リージョンのStreams/Firehoseへ転送• タグによるルーティングや、必要に応じて整形を実施KinesisStreamsMobileappsTokyo OregonKinesisStreamsfluentdserver
利⽤していての所感
まとめ• 開発が楽になった– IAMの設定は⼤変だが省⼒化できる– クエリだけ集中して考えれば良い• 運⽤も楽になった– フルマネージド– 但し、前後(Streams/Firehose)の流量には注意• サーバコストも安くなった– ※もちろん、ケース次第です→ トータルコストの削減+デリバリの短縮へ
宣伝• エンジニアブログやっていますhttp://data.gunosy.io/http://tech.gunosy.io/
終わりに• ご清聴ありがとうございました