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

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

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

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

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

© 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サービス

© 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）サービスの 特徴量のニアリアルタイム化（鈴木）

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

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

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

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

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

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

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

© 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; // 取得日時 ..... }

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

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

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

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

© 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 .....

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

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

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

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

© 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

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

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

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

© 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に出力できるようになった 採用

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

© 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秒

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

© 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)

© 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回の処理コストもリーズナブル

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

© GO Inc. ● コンポーネント一覧 ○ ワークフローエンジン ■ Cloud Composer (Airflow) (マネージドサービス) ○ コンテナ実行環境 ■ 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 (マネージドサービス) 変換リクエスト

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

© 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 まとめ

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

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

© GO Inc. 到着予想時間（Estimated Time of Arrival） 到着予想時間（ETA）とは 41

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

© GO Inc. 43 現状と課題

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

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

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

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

© GO Inc. 48 解決策の検討

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

© 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に割り当てられたリ ソースの余剰部分で賄え る

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

© GO Inc. 52 解決策の実現

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

© GO Inc. 54 サービングプロセスの実装例 multiprocessing.Managerを利用すると 複数プロセス間でデータを共有できる

© GO Inc. 55 データ更新スレッドの実装例 定期的なデータ再読込の バックグラウンドスレッドの追加 5分ごとにVolumeを再読込

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

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

文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.