LINEセグメント配信基盤について
 株式会社ZOZOテクノロジーズ
 ECプラットフォーム部 MAアプリケーションチーム
 長澤 修平
 Copyright © ZOZO Technologies, Inc.

© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 ECプラットフォーム部
 MAアプリケーションチーム 長澤 修平
 ● 2019年4月中途入社
 ● 前職では広告代理店でBtoBのスマホアプリ用の
 マーケティングツールを開発
 ● サーバーサイドを中心に色々
 2

© ZOZO Technologies, Inc. アジェンダ
 ● LINEセグメント配信基盤とは
 ● 開発の動機
 ● 管理画面での配信予約のフロー
 ● アーキテクチャ（メッセージ配信）
 ● アーキテクチャ（配信ログ/クリックログ）
 ● アーキテクチャの要所の詳細説明
 ● 現在の課題
 ● まとめ
 3

© ZOZO Technologies, Inc. LINEセグメント配信基盤とは
 ● LINE Messaging APIを利用したメッセージ配信基盤
 ● ツール名: LINE Friendship Manager(通称LFM)
 ● LINEのZOZOTOWN公式アカウントの
 LINE友だちにメッセージを配信できる
 4

© ZOZO Technologies, Inc. 5

© ZOZO Technologies, Inc. 開発の動機
 ● LFM以前
 ○ LINE Official Account Managerという公式ツールから配信していた
 ○ セグメントを切らずにLINE友だち全員に一斉配信のみ
 ● LFM
 ○ BigQueryとの連携で社内データを活用したセグメント配信
 ○ セグメント配信によるターゲット最適化とコスト最適化
 
 6

© ZOZO Technologies, Inc. 管理画面での配信予約のフロー
 1. コンテンツ登録
 2. セグメント登録
 3. キャンペーンの予約
 
 7

© ZOZO Technologies, Inc. コンテンツ登録
 8

© ZOZO Technologies, Inc. 9

© ZOZO Technologies, Inc. 10

© ZOZO Technologies, Inc. セグメント登録
 11

© ZOZO Technologies, Inc. キャンペーン
 登録
 12

© ZOZO Technologies, Inc. アーキテクチャ（メッセージ配信）
 ①予約確認
 ②コンテンツ取得
 ③セグメント抽出
 ④メッセージpublish
 ⑤Functions起動
 ⑥重複配信確認
 ⑦APIトークン取得
 ⑧APIリクエスト
 ⑨配信ステータス更新
 
 13

© ZOZO Technologies, Inc. アーキテクチャ（配信ログ/クリックログ）
 14 ①APIリクエスト
 ②ログpublish
 ③ログ取得
 ④重複削除 & insert
 ⑤クリックログ蓄積
 ⑥ログエクスポート


© ZOZO Technologies, Inc. Pub/Sub TopicとCloud Functionsの並列化
 ● スループット向上のために10並列
 ● 300万requestで1時間を超過するぐらい
 ● LINE Messaging APIのリクエスト上限の都合でこれ以上あげる予定はない
 15

© ZOZO Technologies, Inc. Pub/Subの重複削除
 ● Cloud Pub/Subはat least onceなので2回配信されることがある
 ● メッセージ配信
 ○ 配信前にDatastoreで重複チェック
 ○ 配信成功後にDatastoreに書き込み
 ● 配信ログ
 ○ Dataflowのtemplateの「Pub/Sub Topic To BigQuery」で重複削除
 
 16

© ZOZO Technologies, Inc. 配信リトライ①
 ● Cloud Functionsで起こるエラー
 ○ Cloud Datastoreの書き込み上限1秒間1回の超過
 ■ Cloud Firestoreにアップグレードすれば解消されるが未対応
 ○ 503 Transport closed, 503 Socket closed など
 ○ LINE Messaging APIのリクエスト上限超過
 ○ そのほか原因不明のエラー
 ● Pythonのretryパッケージを使っても依然として一部が失敗する
 ● 配信失敗率 0.1~1.0%
 
 
 17

© ZOZO Technologies, Inc. 配信リトライ②
 ● BigQueryのテーブルの差分からのリトライ
 ○ 差分抽出はEXCEPT DISTINCT句
 ● 配信失敗率 0.1~1.0% ➡ ほぼ0.0001%未満（100万人中100以下）
 
 18 ①セグメントを
 　一時テーブルに保存
 ②配信
 ③配信ログ保存
 ④配信成功/失敗判定
 ⑤差分抽出
 ⑥リトライ


© ZOZO Technologies, Inc. publish中断
 ● Pub/Sub Topicへのpublish中断
 ○ publishに最大1時間前後かかる
 ○ publish中にリリースすると中断
 ○ Out Of Memoryによりpublish中のプロセスが死に、中断したこともある
 ■ 配信前のセグメント抽出でメモリ消費率が高くなるため
 
 19

© ZOZO Technologies, Inc. publish中断の解決策
 ● BigQuery ➡ Storage ➡ Dataflowバッチ ➡ Pub/Sub Topic を検討中
 20

© ZOZO Technologies, Inc. まとめ
 ● 管理画面での配信予約のフロー
 ● アーキテクチャの紹介
 ○ Pub/Sub TopicとCloud Functionsの並列化
 ○ Pub/Subの重複削除
 ○ Cloud Functionsのリトライ
 21

No content