GO TechTalk #19 タクシーアプリ『GO』事業成長を支えるデータ分析基盤の継続的改善！

© GO Inc.
GO TechTalk #19
タクシーアプリ『GO』
事業成長を支えるデータ分析基盤
の継続的改善！
2023/5/31

View Slide

© GO Inc.
・タクシーアプリ『GO』のデータ基盤の全体像（鈴木）
・車両位置情報データの圧縮による
Cloud Pub/Subのコスト削減（牧瀬）
・AWS Aurora S3 Export を利用した、負荷をかけない GCP BigQuery へのデータ連携 (伊田)
・到着予想時間（ETA）サービスの特徴量のニアリアルタイム化（鈴木）
目次

View Slide

タクシーアプリ『GO』の
データ基盤の全体像
2023.05.31
GO株式会社

View Slide

© GO Inc. 4
自己紹介
GO株式会社
MLOpsエンジニア / 鈴木隆史
複数の機械学習サービスの基盤やパイプラインの設計開発
を担当
最近はゼルダにハマり中

View Slide

© GO Inc. 5
タクシーアプリ『GO』
乗る位置を指定到着まで待つ乗る！
支払いはキャッシュレスで
素早く降車
※アプリ上での決済の他、
　車内での現金決済にも対応

View Slide

© GO Inc.
主要な『GO』分析データ基盤
6
GO動態ログ
GOイベントログ
（ユーザアプリ）
GCP DBログ
（Cloud SQL）
AWS DBログ
（Aurora）
外部データ
(地図・天気など)
データソースデータパイプライン BigQuery
RAWデータ
データマート
データ活用
BI・プロダクト分析
バッチ同期
ストリーミング (CDC)
バッチ同期 (S3 -> GCS)
バッチ同期
(BQ federated query)
ストリーミング挿入
(Pub/Sub, Dataflow)
(Pub/Sub, Dataflow)
加工パイプライン
(Dataform)
タクシー会社向け
GOヘルプデスク
GO施策運用
・・
緑の枠が主なチームの担当領域
(Dataform)
データウェアハウス
AIサービス

View Slide

© GO Inc.
主要な『GO』分析データ基盤
7
今回話すコンテンツ
GO動態ログ
GOイベントログ
（ユーザアプリ）
GCP DBログ
（Cloud SQL）
AWS DBログ
（Aurora）
外部データ
(地図・天気など)
データソースデータパイプライン BigQuery
RAWデータ
データマート
データ活用
BI・プロダクト分析
バッチ同期
ストリーミング (CDC)
バッチ同期 (S3 -> GCS)
バッチ同期
(BQ federated query)
(Pub/Sub, Dataflow)
(Pub/Sub, Dataflow)
(Dataform)
タクシー会社向け
GOヘルプデスク
GO施策運用
(Dataform)
データウェアハウス
AIサービス
・・
車両位置情報データの圧縮による
Cloud Pub/Subのコスト削減（牧瀬）
AWS Aurora S3 Export を利用した
負荷をかけない
GCP BigQuery へのデータ連携 (伊田)
到着予想時間（ETA）サービスの
特徴量のニアリアルタイム化（鈴木）

View Slide

車両位置情報データの圧縮による
Cloud Pub/Subのコスト削減
2023.05.31
牧瀬芳太郎
GO株式会社

View Slide

© GO Inc. 9
自己紹介
GO株式会社
ソフトウェアエンジニア / 牧瀬芳太郎
タクシーアプリ『GO』データ基盤開発・運用などを担当
Go言語でバックエンド開発もしています
最近はゼルダの伝説ToKをプレイしていますが、寄り道しすぎてクリ
アに3ヶ月くらいかかりそう

View Slide

© GO Inc. 10
車両位置情報の収集
▪ アクティブ車両台数: 数万台
▪ 車両から送られる情報: GPS位置、方角、速度、メーター情報、etc.
＝動態(車両動態)
▪ 約9億レコード/日
何に使われる？
▪ 配車
▪ 機械学習を使ったサービス
▪ 到着時間予測 (DeNA TechCon 2022 にて紹介)
▪ お客様探索ナビ (MoT TechTalk #10 にて紹介)
▪ AI予約
▪ etc.
▪ サービス改善のための分析

View Slide

© GO Inc. 11
『GO』アプリ動態パイプラインの全体図
MoT TechTalk #7 技術書典頒布
のタクシーアプリ『GO』アーキ
テクチャ図録を一挙解説
にて紹介
今回の話

View Slide

© GO Inc. 12
『GO』アプリデータ基盤のコスト
▪ BigQuery についで Pub/Sub, Dataﬂow のコストが大きい
▪ その中でも車両動態が多くを占める
▪ データ流量に応じてかかるコストがあり、流量が多いためコス
トが高くなっている
▪ 提携タクシーの増加に伴い、動態の流量は徐々に増加

View Slide

© GO Inc.
▪
Pub/Sub 経由で BigQuery に投入
▪
Pub/Sub のペイロードは動態 1レコードの JSON
13
従来構成 (MoT TechTalk #12 にて紹介)
ここの流量を減らしたい！

View Slide

© GO Inc.
▪
Pub/Sub のペイロードを Protobuf + Zstandard に変更
14
新構成

View Slide

© GO Inc. 15
新構成
Protobuf スキーマ ※実際より簡略化
// 車両動態
message AnalyticalThing {
uint32 car_id = 1; // 車両ID
double raw_lat = 2; // GPS緯度
double raw_lon = 3; // GPS経度
double speed = 4; // 速度
Status.MeterStatus meter_status = 5; // メーター状態
google.protobuf.Timestamp sampled_at = 6; // 取得日時
.....
}

View Slide

© GO Inc. 16
技術選定理由　データ形式
Protocol Buﬀersを採用
▪ Google社製のシリアライゼーションフォーマット
▪ 動態配信システムから来るデータが元々 Protobuf 形式なので、そのまま流
せば処理コストが少ない
▪ 後段で圧縮するとしても、JSON より Protobuf を圧縮する方が最終的なサ
イズが小さくなる
他に検討に上がった選択肢
▪ Parquet, Avro 等
→ 動態配信システムから来るデータが元々 Protobuf 形式なので、わざわざ
変換するのは余計な処理が増えるだけなので不採用
仮に動態配信システムから来るデータが Parquet や Avro 形式であったなら
採用していた

View Slide

© GO Inc. 17
技術選定理由　圧縮アルゴリズム
Zstandardを採用
▪ Meta(Facebook)社製の可逆圧縮アルゴリズム
▪ リアルタイム処理性能を重視しており、GZIP と同程度の圧縮率で、よ
り高速
▪ JSON を Protobuf にするだけだとデータサイズ削減量が少ないため利用
▪ 複数レコードをまとめて圧縮する。1台の車両からの動態データをある程度
まとめて送ってもらっているため、似たようなレコードが多く効率的に圧縮
できる
他に検討に上がった選択肢
▪ GZIP
→ やや古いアルゴリズム。最近は同程度の圧縮率で、より高速なものがある

View Slide

© GO Inc. 18
Protobuf のレコードをまとめるときの工夫
課題
▪ Protobuf のレコードは可変長のバイナリ
データ
▪ レコード自体には区切りとなる情報がない
工夫
▪ レコードの長さを先頭に付与して連結する
▪ トータルのレコード件数がいくつであって
も、単にバッファ or ファイルの後ろに追
記していけば良いため、ストリーミング処
理と相性が良い

View Slide

© GO Inc. 19
実装
Pub/Sub に投げる側: Go言語で書かれた内製ワーカー
▪ 今までは Protobuf を JSON に変換していたが、Protobuf のまま複数レ
コードまとめて圧縮し publish するように変更
▪ 圧縮処理は並列動作するように実装
Pub/Sub から読み出す側: Dataﬂow
▪ Mercari Dataﬂow Template を参考に独自にフレームワークの実装を行い、
YAML 記述により様々な Beam API を呼び出せるようにし、柔軟にパイプラ
イン定義ができるようにしている
▪ 今回追加: Protobufデコード処理、ZStandard展開処理
▪ フレームワークさえ修正すれば、各ジョブ定義自体はYAMLの書き換えだけ
で済む。YAMLの修正例は次ページにて説明

View Slide

© GO Inc. 20
実装: ジョブ定義YAMLの修正例
--- laplace-vehicle-analytics-log-collector.yaml 2023-05-11 17:08:20
+++ laplace-vehicle-analytics-v2-log-collector.yaml 2023-03-13 12:13:31
@@ -2,10 +2,13 @@
- name: pubsub
module: pubsub
parameters:
- subscription: "projects/my-project/subscriptions/laplace-vehicle-analytics-subscription"
- format: string
+ subscription: "projects/my-project/subscriptions/laplace-vehicle-analytics-v2-subscription"
+ format: pbpack
+ compression: ZSTD
transforms:
- - name: parsejson
- module: parsejson
+ - name: parseprotobuf
+ module: parseprotobuf
input: pubsub
parameters:
+ descriptorFile: ../proto/laplace/common.pb
+ messageName: laplace.AnalyticalThing
.....

View Slide

© GO Inc. 21
成果
▪
高いデータ圧縮率
▪ 約1/15 (JSON→Protobuf で 1/3、ZStandard でさらに 1/5)
▪
コスト削減
▪ 動態の Pub/Sub, Dataﬂow 流量コスト: 93% 削減
▪ データ基盤全体のコスト: 10% 削減
▪
エンコード/デコードの処理が高速化
▪ 2,000 レコードの処理が 43ms → 18ms (エンコード側)
▪ CPU負荷が低い＝マシンスペックが低く抑えられる

View Slide

© GO Inc. 22
まとめと所感
まとめ
▪ 車両動態を Pub/Sub に流すフォーマットを
JSON → Protobuf+Zstandard に変更することにより
データ量を 1/15 にし、大幅なコスト削減を達成
所感
▪ Pub/Sub は流量が多いとコストがかさみやすい
▪ (最近は BigQuery Subscriptions もあるが) あえて Dataﬂow を利用
しデータ圧縮を行うことで流量を削減し、コストを抑えられるケース
がある

View Slide

AWS Aurora S3 Export を利用した、
負荷をかけない GCP BigQuery へのデータ連携
2023.05.31
伊田正寿
GO株式会社

View Slide

© GO Inc.
GO株式会社
データエンジニア／伊田正寿
家庭菜園でプチトマトを作りたく調査中
24
自己紹介
プロフィール写真
正方形にトリミングした写
真を「図形に合わせてトリ
ミング」で円形にすると真
円になる

View Slide

© GO Inc.
AWS Aurora から GCP BigQuery へのデータ連携のシステム構成
● 試しに CDC (Change Data Capture) を試しに導入した
● プライベートサブネットにある DB に穴を開けられない制約があるため内部からプッシュする方式とした
● 詳細は Tech Talk Vol.12 参照
25
背景
復元した
テーブル
復元した
テーブル
更新ログ
(JSON)
CDC
ツール
更新
ログ
格納
サービスDB
テーブルN
テーブルN
テーブル
テーブル
復元処理
GCP 分析環境
AWS サービスDB
BigQuery BigQuery
Aurora MySQL
BIN
ログ
ワークフローエンジン
Cloud
Pub/Sub
分散
キュー
Cloud
Dataflow
GKE
Cloud Composer

View Slide

© GO Inc. 26
課題
● 本方式によるデータ同期は運用負荷が高い
○ 障害発生時の復旧手順が複雑
■ 詳細は Tech Talk Vol.12 参照
○ テーブルリネーム・カラムリネームが行われると、更新ログからレプ
リカを再現できない (別途対応が必要)
○ GCP だけでなく AWS 側での構築、運用も発生する
このことから運用負荷が下がる方法がないか検討を開始した

View Slide

© GO Inc.
● 方針
○
要件は下記に限定する
■ 更新頻度は日次
○
ゴール
■ CDC 方式より運用負荷が下がること
○
撤退条件
■ CDC 方式より運用負荷が下がらない時
○
運用負荷が下がるとは
■ 障害復旧がシンプルにできること
■ スキーマ変更に対して簡単に追従できること
■ 他の運用との兼ね合いで GCP Cloud Composer 起点でジョブ実行
やエラー対応ができること
■ GCP と AWS にまたがる開発となるが、作り込みは GCP 側に寄せ
られること
27
方式の検討

View Slide

© GO Inc. 28
方式の検討 (1/2)
パイプライン
サービスDB
テーブルN
テーブルN
テーブル各種変換処理
GCP 分析環境
AWS サービスDB
日次
BigQuery
Aurora
MySQL / Postgresql
GKE
Cloud Composer
データ
S3
データ
GCS
復元した
テーブル
レプリカ
テーブル
復元した
テーブル
レプリカ
テーブル
BigQuery
???
抽出処理
S3 にデータを抽出できれば後工程の構築は知見があるため、
プライベートサブネットにある DB からどうやってデータを S3 に抽出するか検討した

View Slide

© GO Inc.
案処理方法メリットデメリット
1. Aurora S3
Export
Aurora S3 Export 機能(※)を用いて、DB
の全データを S3 に抽出する
DB に負荷をかけ
ない
前処理を挟めない。
データ量に対してコストが
掛かる。
2. Redshift 経由
(Athena 経由でも可)
Redshift を用意し、Redshift から Aurora
に Federated Query で問い合わせて S3
に抽出する
(Redshift Data API で SQL を発行)
SQLで前処理を
挟める
構成が複雑で、トラブル
シュートが大変。
Redshift はクラスタ or サー
バーレスなどの選定も必要
3. スクラッチ実装 EC2 / ECS / Fargate / EKS / Glue など
を用いてスクラッチ開発して、 Aurora
から S3 に抽出する
自由度が高い開発コストが掛かる
29
方式の検討 (2/2)
プライベートサブネットにある DB に外から穴を開けずに S3 に出力する方法
※)2022年10月に直接S3に出力できるようになった
採用

View Slide

© GO Inc. 30
実験
● 実験対象の方式
○
Aurora S3 Export
● 観点
○
日次処理を2時間程度に収められるか
■ 0〜1時に処理起動、5〜6時にレポート配信。1回のリトライを考慮
して1回の処理時間を2時間程度に収めたい
○
2時間の処理時間に収まるデータ量はいくらが限界か
○
コストが許容範囲内か
● 実験対象のDB
○
Large DB
■ Aurora スナップショットのサイズ約500GB
○
Medium DB
■ Aurora スナップショットのサイズ約100GB

View Slide

© GO Inc. 31
実験
● 実験結果
Large DB (約500GB) Medium DB (約100GB)
合計 31分 21分20秒
データ抽出
Aurora to S3
25分
(500GB → 74GB)
※ gz.parquet に圧縮
20分
(100GB → 12GB)
(内訳) DB Clone 17分 16分
(内訳) S3 Export 8分 4分
データ転送
S3(Tokyo) to GCS(US)
3分 40秒
データ取込
GCS to BigQuery
3分 40秒

View Slide

© GO Inc.
● 考察
○
Large DB の全体の処理時間約30分のうち、8割がデータ抽出、1割がデー
タ転送、1割がデータ取込となっている (Medium DB に至ってはデータ抽
出に9割を占める)
○
Medium DB に対してサイズが約5倍の Large DB になっても、処理時間が
単純に5倍になるわけではない
○
その理由は、データ抽出はサイズによって処理時間が変動するが、DB ク
ローンはサイズに関わらず一定の時間であるため (変動時間+固定時間で
構成されているから)
■ DB クローンについては次のページで詳細を説明
32
実験の考察

View Slide

© GO Inc.
● Aurora S3 Exportにおいて、DB のクローンはデータ量に関わらず一定
時間で完了する理由の考察
33
実験の考察
●
Aurora はコンピューティングとストレージが分離
している。
●
DB のクローンはコンピューティング部分のコ
ピーであり、データの移動は発生しない。
●
以上のことから DB のクローンはサイズに関わら
ず、どの DB でも一定時間掛かると考えられる
AWS の資料から引用
(https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20A
urora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%
AF%E3%83%81%E3%83%A3%E6%A6%82%E8%A6%81.pdf)

View Slide

© GO Inc. 34
コスト
Large DB Medium DB
合計 $14.2 $2.7
S3 Export 料金 $5.70 $1.33
S3 転出料金 $8.44 $1.33
S3 → GCS 転送料金
(GCS Storage Transfer Service)
$0.00 $0.00
GCS 書き込み料金 $0.06 $0.03
● 1回の処理コストもリーズナブル

View Slide

© GO Inc.
Aurora S3 Export 方式について
以下の理由から Aurora S3 Export 方式を採用した
● 制約を満たしているか？
○ Aurora S3 Export はプライベートサブネットにある DB に外から穴を開けずに実行可能
○ 実験の結果、処理時間、コストともに許容範囲内であることが確認できた
■ 変動部分の処理時間が500GBでも10分程度で完了していることから、単純計算で6TBで処
理時間が2時間程度となり、十分に余裕があると判断
■ コストはDBのサイズが500GBでも月数万のコストのため許容範囲内と判断
● 課題を解決しているか？＝運用負荷が高くないか
○ 障害発生時も全件抽出方式のため頭からリトライするだけ済む
○ スキーマ変更時も全件抽出による洗い替えができるので特別な考慮をしなくて済む
○ GCP 側から API を実行できるため、実装を GCP 側に寄せることができ、保守の範囲が広がらな
いで済む
35
実験の結果から

View Slide

© GO Inc.
● コンポーネント一覧
○
■ Cloud Composer (Airﬂow) (マネージドサービス)
○
コンテナ実行環境
■ GKE (マネージドサービス)
Aurora
36
変更後のアーキテクチャ
パイプライン
サービスDB
テーブルN
テーブルN
テーブル
コンテナ
実行環境
GCP 分析環境
AWS サービスDB
BigQuery
GKE
Cloud Composer
データ
S3
データ
GCS
復元した
テーブル
レプリカ
テーブル
復元した
テーブル
レプリカ
テーブル
BigQuery
クローン
クローンDB
テーブルN
テーブルN
テーブル
エクスポート
Aurora S3 Export
抽出リクエスト
(アウトバウンド通信のIP固定)
転送
リクエスト
取込
リクエスト
○
データ抽出
■ Aurora S3 Export (マネージドサービス)
○
データ転送
■ GCS Storage Transfer Service (マネージドサービス)
○
データ取込
■ BigQuery Load Job (マネージドサービス)
変換リクエスト

View Slide

© GO Inc. 37
本番運用した結果
● 同期対象のDB数
○
11個のDB (2023年5月現在)
■ 本番環境 5個
■ QA環境 5個
■ 開発環境 1個
● 障害発生件数
○
期間: 2023年1月〜2023年5月現在
○
件数: 0
○
考察: CDC より仕組みがシンプルであるため障害になりにくいと推察している
■ 全件抽出方式というシンプルなパイプラインのため
■ 大半がマネージドサービスで構成されており障害になりづらいため
■ 経験上、DB に負荷が掛かる時にデータ連携は失敗しやすいが、この方式はDBに
負荷を掛けないため
● 問題点
○
S3 Export の並列実行数の上限が5となっており、同期対象の DB が増えた
時に実行順序の考慮が必要になる

View Slide

© GO Inc.
● 背景
○ 試しに CDC (Change Data Capture) を試験導入した
○ プライベートサブネットにある DB に穴を開けられない制約があるため内部からプッシュする方式だった
● 課題
○ 障害復旧の手順が複雑
○ テーブルやカラムがリネームされると破綻する
○ GCP だけでなく AWS 側での構築、運用も発生する
● 検討および実験
○ プライベートサブネットにある DB に穴を開けず、CDC方式より運用が楽なものに置き換える
■ 案1 Aurora S3 Export
■ 案2 Redshift (Federated Query & Redshift Data API)
■ 案3 スクラッチ実装 (EC2/ ECS / Fargate / EKS / Glue など)
○ 机上では案1が有力だったため課題がないかどうか実験した
○ 実験により問題がないことを確認し、コストも許容範囲内のため本実装を進めた
● 本番運用した結果
○ CDC 方式より安定し、運用負荷が下がった
38
まとめ

View Slide

到着予想時間（ETA）サービスの
特徴量のニアリアルタイム化
- Feature Storeの技術選定 -
2023.05.31
鈴木隆史
GO株式会社

View Slide

© GO Inc. 40
自己紹介
GO株式会社
MLOpsエンジニア / 鈴木隆史
複数の機械学習サービスの基盤やパイプラインの設計開発
を担当
最近はゼルダにハマり中

View Slide

© GO Inc. 42
ETA精度は事業影響度が大きい
● 『GO』アプリのコア機能（配車依頼、予約機能など）として利用している
● アプリで表示している到着時間よりも遅着・早着の場合
○ UXの悪化、キャンセル率の増加
○ 特に大幅な遅着時のネガティブ体験
● 遠方の車両を向かわせてしまった場合
○ 迎車時間が長くなることによる機会損失
到着予想時間（ETA）の精度の重要性

View Slide

© GO Inc.
アルゴリズム側の改善
● 経路探索 + MLモデルのハイブリッド構成へ変更（参考：
DeNA TechCon 2022 - あと何分？タク
シーアプリ『GO』到着予測AIの社会実装まで -）
● 通り過ぎ問題への対策（参考：GO Tech Blog - ETA(到着予想時間)の重要性と「通り過ぎ問題」へ
の対策 -）
システム側の改善
● リアルタイムな需要供給・道路状況の反映
○ 降雪などの突発的なイベントでの精度低下の改善
44
到着予想時間（ETA）の精度向上に向けた取り組み
本日話すテーマ
課題
ニアリアルタイム（30分ごと）に更新されるデータを用いて
機械学習モデルを更新する仕組みがない

View Slide

© GO Inc.
従来ETA APIのコンポーネント
45
ユーザー
時刻・
地理情報・
乗務員情報
などの入力値
お客様・
ドライバー
位置情報
の入力値
経路探索
エンジン
経路探索結果
の特徴量
ETA
推論モデル
Amazon EKS
特徴量変換
時刻・乗務員
などの
様々な特徴量
地図データ
S3
地理統計値
乗務員情報
などの特徴量
数ヶ月ごと
の更新
Cloud Composer
1日ごと
の更新
処理
リクエスト
パラメータ
データ
凡例

View Slide

© GO Inc.
従来ETA APIのシステム構成
46
地図データ
地理統計値
乗務員情報
などの特徴量
数ヶ月ごと
の更新
1日ごと
の更新
ワーカープロセス A
グローバル変数
ワーカープロセス B
ワーカープロセス C
…
…
Cloud Composer
Amazon EKS
S3
● REST APIのPodが起動する際に、各プロセスのグローバル変数にデータをロードしている
…

View Slide

© GO Inc.
従来APIシステム構成に30分更新の天気情報を追加しようとすると
47
地図データ
地理統計値
乗務員情報
などの特徴量
天気情報
などの特徴量
数ヶ月ごと
の更新
1日ごと
の更新
…
30分ごと
の更新
Cloud Composer
S3
● 30分ごとに新しい特徴量データをロードするには、再デプロイが必要なため現実的でない
30分単位でデータ更新したいが、
Podを再デプロイしないと
グローバル変数が再読込されない
…
各プロセスごとにメモリ
が割り当てられるため、
あるプロセスのグローバ
ル変数を更新しても他プ
ロセスには反映されない
…
Amazon EKS

View Slide

© GO Inc. 49
解決案の候補
実装方式サービング方式メリットデメリット
Vertex AI
Feature Store
の利用
オンラインサービング
(少量の最新データを取得 )
* 低レイテンシ/低メモリ
* 複数データソース
(BigQuery/GCS)に対して統一
したI/Fで取得可能
* コンピュートコスト大
* バッチ処理と比較して高い
バッチサービング
(大量の定期更新データを取得
)
* 統一I/F
* サーバーキャッシュに乗せるこ
とで低レイテンシ
* 高メモリ
* リアルタイムデータの参照
ができない
独自実装オンラインサービング
(Redis開発想定)
* 低レイテンシ/低メモリ * コンピュートコスト大
)
(データ取得プロセス開発想定
)
* サーバーキャッシュに乗せること
で低レイテンシ
* 使用メモリ次第で低コスト
* 現状の実装ベース
* リアルタイムデータの参照
ができない
* 高メモリ

View Slide

© GO Inc. 50
解決案の実験結果
実装方式サービング方式レイテンシ使用メモリコンピュートコスト
Vertex AI
Feature Store
の利用
オンラインサービング
100-200 msec 数KB 1ノードあたり$700/month
)
1-3 msec
(サーバーキャッシュ利用時 )
数1000 msec
(通常参照時)
数10MB 軽微なストレージ料金
独自実装オンラインサービング
(Redis開発想定)
5-10 msec 数KB M1(4GB) Standardの場合
$200/month
)
(データ取得プロセス開発想定
)
1-3 msec
(サーバーキャッシュ利用時 )
100-200 msec
(通常参照時)
数10MB Podに割り当てられたリ
ソースの余剰部分で賄え
る

View Slide

© GO Inc.
今回は下記の理由でバッチサービングの独自実装を採用した
● 既に特徴量はBigQueryで集約管理しているため、I/F共通化の恩恵が小さいこと
● 特徴量データサイズが小さく、サーバーキャッシュに乗り切ること
○ サーバーキャッシュに乗れば、通信オーバーヘッドがない分オンラインサービング
よりも高速に動作すること
● 利用する特徴量は30分単位で更新できればよく、バッチサービングで要件を満たせる
こと
● 現在の実装ベースのまま開発できること
51
バッチサービング独自実装の選定理由

View Slide

© GO Inc.
サービングプロセスの新構成
53
地図データ
地理統計値
乗務員情報
などの特徴量
天気情報
などの特徴量
数ヶ月ごと
の更新
1日ごと
の更新
ワーカープロセスA
ワーカープロセスB
ワーカープロセスC
…
…
…
30分ごと
の更新
Cloud Composer
サービング
プロセス
データ参照
スレッド
ユーザー
S3
ワーカープロセスA
ワーカープロセスB
ワーカープロセスC
サービング
プロセス
データ参照
スレッド
Amazon EKS
…

View Slide

© GO Inc.
特徴量のバージョン管理
● データの後方互換性がなくなるタイミングでデータファイルのバージョンを変更し、モデルではデー
タバージョンを指定して処理することで、新旧両方のデータを扱える
○ 例）features/1.1.0/realtime.csv.gz -> features/1.2.0/realtime.csv.gz
○ モデルによって違うバージョンの特徴量を利用することが可能
○ 後方互換性がない更新が入っても、既存のパイプラインはエラーにならない
● バージョン更新時のデプロイ順番には注意
○ 1. Cloud Composerで新しい特徴量データのデプロイ
○ 2. APIで利用する特徴量バージョンの更新
○ この手順を踏むことで
データフォーマット変更時のエラーを回避
56
運用上の考慮点

View Slide

© GO Inc.
今回のニアリアルタイム特徴量の提供には、バッチサービング独自実装を採用
● オンラインサービングやFeature Storeを利用するメリットが小さかったため見送り
● オンラインサービングと比較して低レイテンシで特徴量を提供可能
● 複数プロセスを起動するAPIでは、サービングプロセスを利用して各プロセスでデータを共有
● 定期的なデータ更新スレッドを利用して、データの再読み込み
特徴量管理の工夫
● バージョン管理を導入することで、モデルごとに違うバージョンの特徴量を利用可能
57
まとめ

View Slide

GO TechTalk #19 タクシーアプリ『GO』事業成長を支えるデータ分析基盤の継続的改善！

GO TechTalk #19 タクシーアプリ『GO』事業成長を支えるデータ分析基盤の継続的改善！

GO Inc. dev

More Decks by GO Inc. dev

Other Decks in Technology

Featured

Transcript