Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GunosyでのKinesis Analytics利用について / BigData JAWS 6 Kinesis Analytics
Search
koid
April 04, 2017
Technology
1
890
GunosyでのKinesis Analytics利用について / BigData JAWS 6 Kinesis Analytics
koid
April 04, 2017
Tweet
Share
More Decks by koid
See All by koid
新しい技術の導入時に大切にしていること / IVS CTO Night 2018 LT
koid
2
7k
GunosyでのKinesis Analytics利用について / AWS Solution Days 2017 -AWS DB Day-
koid
0
220
re:Inventに行ってきました - 気になった新サービス / AWS re:Invent2016 Participants LT
koid
0
2k
AWS Lambda - ピーキーなアクセスに備える / Gunosy Beer Bash #8
koid
0
2k
AWS Lambdaで複数アカウント間でアレコレする / Gunosy Beer Bash #7
koid
1
1.9k
サーバにログインしない・させないサービス運用 / AWS Summit 2015 Devcon
koid
6
8.9k
GunosyのMicroServicesとOpsWorks / よくわかる AWS OpsWorks
koid
18
5.8k
Other Decks in Technology
See All in Technology
コミュニティサービスに「あなたへ」フィードを リリースするまでの試行錯誤
takapy
1
140
ペパボのオブザーバビリティ研修2024 説明資料
kesompochy
0
1.1k
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
ACRiルーム最新情報とAMD GPUサーバーのご紹介
anjn
0
150
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
Scaling Technical Excellence at 104: Evolution in AWS and Developer Empowerment
scotthsieh825
1
150
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1k
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
35
6.3k
How to name files
jennybc
67
96k
Pencils Down: Stop Designing & Start Developing
hursman
118
11k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.5k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
Making Projects Easy
brettharned
111
5.7k
Mobile First: as difficult as doing things right
swwweet
219
8.8k
The Invisible Customer
myddelton
117
13k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
Statistics for Hackers
jakevdp
792
220k
Fashionably flexible responsive web design (full day workshop)
malarkey
399
65k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
Transcript
GunosyでのKinesis Analytics利⽤について 株式会社Gunosy ⼩出 幸典
⾃⼰紹介 • 名前 – ⼩出 幸典 (こいで ゆきのり) • 所属
– 株式会社Gunosy • プロビジョニング・デプロイフローの共通化とか • 過剰リソース警察、コスト削減おじさん • 好きなAWSサービス – OpsWorks, Lambda, Kinesisファミリー, 最近ちょこっとECS
株式会社Gunosy – 「情報を世界中の⼈に最適に届ける」 • Gunosyは 情報キュレーションサービス「グノシー」と • 2016年6⽉1⽇にKDDI株式会社と共同でリリースした 無料ニュース配信アプリ「ニュースパス」を提供する •
会社です。「情報を世界中の⼈に最適に届ける」を ビジョンに活動しています。 ネット上に存在するさまざまな情報を、 独⾃のアルゴリズムで収集、評価付けを⾏い ユーザーに届けます。 情報キュレーションサービス 「グノシー」 600媒体以上のニュースソースをベースに、 新たに開発した情報解析・配信技術を⽤いて⾃動的に 選定したニュースや情報をユーザーに届けます。 無料ニュース配信アプリ 「ニュースパス」
宣伝:データ分析ブログやっています http://data.gunosy.io/
本⽇お話させていただく内容 Gunosyでどういった感じで Kinesis Analyticsを利⽤しているか
なぜストリーム処理/マイクロバッチ処理をしたいのか • 「情報を世界中の⼈に最適に届ける」 – 時間(鮮度)の制約 • 情報には「鮮度」がある – 頻度(量)の制約 •
⾒せられる情報量には限りがある • どういった⼈に、どういった情報が適しているのか – 事前に「誰にどのぐらい読まれるか」等の推定はしているが、⾄近 の実績値も評価に利⽤したい – より短い時間・より少ない試⾏で、実績値を集めたい
例えば • 記事クリックの(ニア)リアルタイム算出 – 「⼤域的な」傾向はわかる
例えば • 「⼤域的な」!= 全てのユーザ – それぞれどういった⼈に適しているのか
Gunosyでの右往左往 • 2013 mongodb+マイクロバッチで頑張っていた • 2014 Redshift+マイクロバッチで頑張っていた – fluentdのflush intervalが短すぎるとcopyが詰まる
– クエリ投げすぎても詰まる余り⾼頻度にできない • 2015 Norikraで頑張っていた – 度々⽌まるが知⾒無さすぎ→監視も復旧⾃動化もままならず – 我々には早かった • 2016 Spark Streamingで頑張っていた – ⾃由度⾼いけど開発コスト⾼し、インフラコスト⾼し – 我々にはオーバースペックだった 本⽇は割愛
本題 Kinesis Analyticsを利⽤してみた
ざっくりした構成(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
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
SQL例 • ⼀度中間ストリームを作る – Source StreamとReference DataをJOIN
SQL例 • 中間ストリームのデータを1分おきにサマリして、出⼒へ
クエリ結果のイメージ • (再掲)
サービスへのフィードバック(出⼒) • 現在のところバッチサーバから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
苦労/⼯夫したところなど
東京リージョンのStreamsから他リージョンへの転送 • クライアントから直接ログを投げ込んでるケース – コンシューマ書きたくない • Lambdaで頑張ろうと思ったけどスループット厳しかった Kinesis Streams log
Mobile apps Tokyo Oregon Kinesis Streams ?
東京リージョンのStreamsから他リージョンへの転送 • コンシューマとしてfluentdを利⽤ – inputプラグインで東京のStreamsから取り出し • outputプラグインで他リージョンのStreams/Firehoseへ転送 • ついでにタグルーティングも Kinesis
Streams Mobile apps Tokyo Oregon Kinesis Streams fluentd server
利⽤していての所感
こうなると嬉しい • 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
こうなると嬉しい • Reference Data – Console上で追加できると嬉しい – Console上で⾒えると嬉しい(サンプルだけでも良いので…)
まとめ • 開発が楽 – ほとんどConfig芸(IAMは⼤変) – クエリだけ集中して考えられる • 運⽤も楽 –
フルマネージド – 前後(Streams/Firehose)の流量は注意 • コストも安い – (ケース次第ですが)
終わりに • ご清聴ありがとうございました