Slide 1

Slide 1 text

Go x プッシュ通知 1.4 億通 per day 2019-03-27

Slide 2

Slide 2 text

• 鍋島永道 (closer) • Repro 創業初期からのメンバー • Rails, Go • Webデザイン(HTML,CSS)をしつつ ActionScript(Flash), JavaScript, PHP を経て Rails プログラマへ • 現在はほとんど Go ⾃⼰紹介

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

• 代えのきかない唯⼀のマーケティングプラットフォーム • 2014: アプリの画⾯録画を使った定性分析ツール • 2015: ユーザーの⾏動データをもとにした定量分析ツール • 2016: 分析データをもとにしたマーケティングツール • 2018: アプリにとどまらず、ウェブ領域にも進出 • 2019: 先⽇、動画機能を完全に廃⽌した Repro の紹介

Slide 5

Slide 5 text

• Repro はアプリケーション部分はモノリシックな Rails プロジェクト • フロントエンド JS からバックエンドのバッチまで • 唯⼀分離されているのが、プッシュ通知の配信基盤 (Pusher) • ユーザーのセグメンテーションは Rails で⾏う • Presto (Hive/Cassandra/MySQL) • ここら辺詳しくはこちら • https://speakerdeck.com/joker1007/architecture-evolution-in-repro Repro で Go をどのように使っているか

Slide 6

Slide 6 text

• Rails でのセグメンテーション結果をもとに、デバイスへの送信を⾏う 部分(Pusher)を Go で書いている • また、送信の状況をリアルタイムで監視する社内ツール(Watcher)も Go で作成 • 将来的にはモノリシックな rails を分割し、部分的には Go に置き換え たりする Repro で Go をどのように使っているか

Slide 7

Slide 7 text

Pusher の紹介

Slide 8

Slide 8 text

• 発射予定時刻前に、Rails でセグメンテーションした結果を redis に詰める • 発射予定時刻になったら Pusher へキューを送る • Pusher はキューをもとに、 redis から送信対象データを取り出して⼀気に 送信する • 送信後、結果を fluentd 経由で BigQuery に送信する • 送信結果をもとに開封率やコンバージョンなどの分析を⾏う 設計について

Slide 9

Slide 9 text

設計について

Slide 10

Slide 10 text

• ⼀番最初の実装は C++ だった • 最初に Go で書いた後も、2回ほど⼤きく書き換えている • redis を経由したデータのやり取りはいずれ破綻するので、別の⽅法を 検討中 設計について

Slide 11

Slide 11 text

• コンテナ化して AWS ECS で動かしている • バイナリオンリーのイメージ (FROM scratch) を作れるので、数メガバ イトで済む。 • UPX(実⾏バイナリを実⾏形式のまま圧縮する技術) で圧縮かけたり している • 現状、7台体制 運⽤について

Slide 12

Slide 12 text

ӡ༻ʹ͍ͭͯ

Slide 13

Slide 13 text

Pusher のこれまでの歴史

Slide 14

Slide 14 text

• Repro のメイン機能は動画分析 • プッシュ通知はあくまでオマケ 2015 AWS SNS

Slide 15

Slide 15 text

• C++ で実装 • 分析データをもとにしたセグメンテーションからの⼤量送信 • 実⾏頻度は低いが、⼀気に⼤量送信が必要 • 送信数に合わせて AWS Lambda を起動し、⼀気に送信する • js からバイナリを起動して動作する 2016 C++ on AWS lambda

Slide 16

Slide 16 text

• C++ のメンテナンスできない • 機能拡張を素早く⾏いたい • 最初は JS on Node で実装しようと考えていた 2017 Go へ全⾯書き換え

Slide 17

Slide 17 text

• 弊社 API を利⽤し、クライアントからの要求により個別の送信 • 常にプッシュが実⾏されている状態 • 常時稼働サーバと AWS Lambda の平⾏運⽤ • 毎回 Lambda を⽴てるより常に稼働させた⽅が効率が良い 2018 常時稼働サーバの運⽤

Slide 18

Slide 18 text

• 常時稼働サーバが増えたので Lambda で実⾏する意味が薄くなった • 新機能を設計する際はなるべくシンプルな⽅が良い 2018 AWS Lambda での実⾏を廃⽌

Slide 19

Slide 19 text

• 最近やっとチーム化した • それまでは実装者⼀⼈とレビュアは兼任で別チームの⼈員(Goが読める有志) • ただし今でも Go のエンジニアは少ない • プッシュ通知に限らず、少しずつマイクロサービス化とともに Go に置き換えて いきたい 2019 チーム作りと開発体制の整備

Slide 20

Slide 20 text

これからの Repro と Go

Slide 21

Slide 21 text

• Rails アプリケーションは依然としてあるが、マイクロサービス化が必要 • 個々の要件により必要な技術は異なるが、 Go でカバーできる範囲はある • 重要性⾼まる。 これからの Repro と Go

Slide 22

Slide 22 text

• 社内啓蒙活動 slack #club-golang これからの Repro と Go

Slide 23

Slide 23 text

• Rails と Go が書ける⼈、 Rails をやっているが Go に興味がある⼈、是⾮うちに 来て • https://repro.io/jp/company/careers/ • https://www.wantedly.com/projects/13022 これからの Repro と Go