マルチプロダクト戦略におけるデータ分析プロダクトのアーキテクチャ/登壇資料（三木拓史）

by Hacobu

Slide 1

Slide 1 text

Confidential マルチプロダクト戦略におけるデータ分析プロダクトのアーキテクチャアーキテクチャ Conference 2024 2024年11月26日テクノロジー本部CTO室三木拓史

Slide 2

Slide 2 text

Copyright Hacobu, Inc. 2 自己紹介 • テクノロジー本部 CTO室室長三木拓史 • Hacobuでの活動 ‒ 動態管理サービス MOVO Fleet のフルリプレースをリード ‒ データ基盤立ち上げ ‒ 配送案件管理サービスMOVO Vista プロダクトエンジニア ‒ CTO室として共通プラットフォーム、データ基盤、PoC開発

Slide 3

Slide 3 text

会社紹介

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright Hacobu, Inc. 8 物流DXツール MOVO（ムーボ）自社および外部のアプリケーションの利用を通じて、企業や業界の枠を超えて物流情報を同じ規格でデジタルにやりとりできるプラットフォームとなり、蓄積されたビッグデータで「運ぶを最適化する」ことを目指しています工場/出荷元物流拠点納品先自社アプリケーション外部アプリケーション ERP S/4 Hana WMS、WCS 配車システム物流情報プラットフォーム共通認証共通機能群共通マスタ共通トランザクション TMS、SCPなど、その他各社のシステム日野コネクト東京海上法人ドライブエージェント API API API API API 配送案件管理トラック予約受付動態管理スマホアプリ

Slide 9

Slide 9 text

物流領域の課題

Slide 10

Slide 10 text

Copyright Hacobu, Inc. 10 事業・プロダクトについて、物流領域の課題物流プロセスには様々なプレーヤーが存在しています。事業内容・規模が異なるプレーヤー間で物を運ぶための情報がアナログにやり取りされています。企業間物流の一例

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright Hacobu, Inc. 12 Hacobuが取り組む課題消極的な意思決定により非効率・高コストな世界となるいつ荷積みできるのかいつ届くのかいつ誰が荷積みにくるのかいつ荷積みできるのかいつ届くのかいつ誰が荷積みにくるのか電話して確認しよう多めに発注しよう早めに到着しよう

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Copyright Hacobu, Inc. 14 事業・プロダクトについて、物流領域の課題個社最適の影響で全体最適化が進んでいない物流領域に対し、 MOVOは複数プロダクトを展開し、各局面の課題に対してアプローチしています。配車受発注・管理サービス

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Copyright Hacobu, Inc. 22 事業・プロダクトについて、物流領域の課題個社最適の影響で全体最適化が進んでいない物流領域に対し、 MOVOは複数プロダクトを展開し、各局面の課題に対してアプローチしています。配車受発注・管理サービス

Slide 23

Slide 23 text

Copyright Hacobu, Inc. 23 物流ビッグデータラボ物流ビッグデータラボは、企業間で物流データを共有し、個社や業界の垣根を超えて物流の社会課題解決および共同輸配送の実現を目指します。 ①企業間での物流ビッグデータの共有と分析による共同輸配送の実現 ②物流効率化に向けた「データドリブン・ロジスティクス」の普及 ③モノが運べない事態になることを回避し、社会貢献につなげる https://hacobu.jp/news/11381/

Slide 24

Slide 24 text

マルチプロダクト戦略におけるデータ分析プロダクトのアーキテクチャ

Slide 25

Slide 25 text

全体像

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Copyright Hacobu, Inc. 27 実現したい最適化 Berth 車両移動のFromTo 例: 東京 -> 大阪 Fleet 車両移動の軌跡データ例:大阪 -> 名古屋 -> 神奈川 -> 東京 X-Data 車両移動を組み合わせて最適化例: 「東京 -> 大阪」と「大阪 -> 名古屋 -> 神奈川 -> 東京」を組み合わせる

Slide 28

Slide 28 text

Copyright Hacobu, Inc. 28 全体アーキテクチャコンテナ監視 CI/CD ・・・基盤認証通知共通マスタ・・・共通機能群(マイクロサービス) プロダクトの MS群プロダクトの MS群プロダクトの MS群プロダクトの MS群プロダクトプラットフォーム

Slide 29

Slide 29 text

Copyright Hacobu, Inc. 29 全体アーキテクチャ FleetやBerth等のプロダクトデータやプロダクトプラットフォームの共通マスタを利用してデータ分析を行えるプロダクトプラットフォーム Fleet Berth X-Data

Slide 30

Slide 30 text

Copyright Hacobu, Inc. 30 データ基盤 • AWS上で稼働しているプロダクトのデータをGoogle Cloudへ転送しデータ基盤として活用 • プロダクトへ影響を与えることなく分析を行える • 複数プロダクト(DB)にまたがって分析を行いたい時にはRDS -> BigQuery へ転送しておくと便利 • データ分析プロダクトのPoC実装を行いやすい環境

Slide 31

Slide 31 text

前半 ~ 動態管理サービスFleetの話

Slide 32

Slide 32 text

Copyright Hacobu, Inc. 32 Fleet • IoTデバイスにより位置情報を蓄積していく • ジオフェンス機能によりある地点への立ち寄りを自動で記録 ‒ 例) 大阪 -> 名古屋 -> 神奈川 -> 東京 • 月間で17億程度の位置情報を処理している • 位置情報処理の話

Slide 33

Slide 33 text

Slide 34

Slide 34 text

概要と位置情報の保存

Slide 35

Slide 35 text

Copyright Hacobu, Inc. 35 lambdaでやっていることの概要 • 大きく4つの処理を行なってる • 位置情報の保存(dynamoDBへのinsert) • ジオフェンスの判定と継続時間の計算 • 他2つ • それぞれの処理に対してlambda が1種類 • 1つのシャードに対して拡張ファンアウトにより4種類のlambdaがそれぞれデータ処理 • 現状12本のシャードで運用 ... ... ... ... 4種類のlambda Kinesisシャードを 12本用意 ...

Slide 36

Slide 36 text

Copyright Hacobu, Inc. 36 位置情報の保存 • デバイスが5sに一度、位置情報をuploadする ‒ 三菱食品様を例にすると ‒ 3500台が5sにリクエストを飛ばしてくる ‒ 1日8時間稼働で2000万リクエスト • 外部システムとのデータ連携も • Kinesisでバッファ ‒ Lambda側で障害があってもkinesisに貯めておけるのでデータロストだけは避けることができる ‒ 何度か助けられた • DynamoDBに保存

Slide 37

Slide 37 text

Copyright Hacobu, Inc. 37 軌跡の活用 • 位置情報はDynamoDBに保存している • ある車両を指定し、時間幅を指定した位置情報のまとまり(=軌跡)を取得してブラウザに表示したりする • 1車両あたり90日間50万レコードがいつでも参照される可能性がある • 車両IDがパーティションキー • 時刻がソートキー

Slide 38

Slide 38 text

ジオフェンス処理

Slide 39

Slide 39 text

Copyright Hacobu, Inc. 39 Wikipedia での解説ジオフェンシング（英： Geofencing）とは実世界の地理に対応した仮想的な境界線で囲まれたエリアへの出入りや一定時間以上の滞在をトリガーにアクションを行う技術である。主にセキュリティや広告、通知を用いたサービスに用いられている。 https://ja.wikipedia.org/wiki/ジオフェンシング

Slide 40

Slide 40 text

Copyright Hacobu, Inc. 40 ジオフェンス • ある地点を中心にして、半径R[m]の範囲に、基準時間以上滞在している場合にそれを記録する ‒ 地点 x 進入時間 x 退出時間が実績になる • 車両ごとに時系列順で処理を行う必要がある進入時間退出時間滞在時間

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Copyright Hacobu, Inc. 42 ジオフェンス処理のフロー進入時間退出時間滞在時間地点外地点内基準時間未満実績生成退出 1.進入 5.退出 3.基準時間経過後進入判定を記録 4.退出時間を記録 2.進入時間を記録基準未満で退出

Slide 43

Slide 43 text

Copyright Hacobu, Inc. 43 ジオフェンス処理のシステム構成 • 「車両ごとに」 ‒ 車両IDをキーにしてkinesisシャードへ分配 ‒ シャードごとにジオフェンス処理を行うlambda は1つ • 同一の車両に関するレコードは常に同一のlambdaが処理する ... ... ... ... ... ある車両Aに関するデータは常にここを通る

Slide 44

Slide 44 text

Copyright Hacobu, Inc. 44 ジオフェンス処理 - job編 - • 3の処理は進入時間からの経過時間で記録したい • トラックのエンジンが切られるなどして、位置情報のuploadが止まることがある • 位置情報のuploadが止まっても、一定以上の滞在時間が経過したら実績を作りたい地点外地点内基準時間未満実績生成退出 1.進入 5.退出 3.基準時間経過後進入判定を記録 4.退出時間を記録 2.進入時間を記録基準未満で退出ここの処理を、位置情報 uploadというイベントがなくても実行したい

Slide 45

Slide 45 text

Slide 46

Slide 46 text

性能改善

Slide 47

Slide 47 text

Copyright Hacobu, Inc. 47 lambdaの性能改善 • Lambdaの処理に時間がかかるようになり、kinesisにデータがたまるようになってきてしまった ‒ 画面への反映が遅れたり、遅延判定ができなかったり ‒ とはいえ地点情報がロストしないのはkinesisを使って良かったところ • 役割の分離 && シャード分割 ‒ 地点情報の保存、ジオフェンス処理、その他2つを分離した ‒ Kinesisからファンアウトしてそれぞれlambdaを実行 ‒ シャードを分割し並列に実行することで性能改善を図った ... ... ... ... ...

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Copyright Hacobu, Inc. 49 まとめ • トラック毎にデータが流れる経路を固定することで正しくデータ処理 • lambdaの役割分割とkinesisシャード分割で並列処理 • オンライン処理では実現できない要件にマイクロバッチで対応外部連携先 ... ... ... ... ...

Slide 50

Slide 50 text

後半 ~ データ分析プロダクトX-Dataの話

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Copyright Hacobu, Inc. 54 実現したい最適化 Berth 車両移動のFromTo 例: 東京 -> 大阪 Fleet 車両移動の軌跡データ例:大阪 -> 名古屋 -> 神奈川 -> 東京 X-Data 車両移動を組み合わせて最適化例: 「東京 -> 大阪」と「大阪 -> 名古屋 -> 神奈川 -> 東京」を組み合わせる

Slide 55

Slide 55 text

Copyright Hacobu, Inc. 55 運行 Fleet のデータを地点に立ち寄った実績の列秋葉原駅 26日10時東京駅 26日11時浜松町駅 26日12時秋葉原駅 27日10時東京駅 27日11時浜松町駅 27日12時大雑把には1日ごとに 1運行を切り出したい現実的には、、 - 運送会社によって稼働している時間が色々(夜間が中心の場合もある - 「実績が取れる = Fleetで設定している」ということ。設定もれや、どこまで設定するか (車庫とか)は場合による - 「地点に立ち寄った」ということしか分からないので、どこで運行が開始したか(切れ目はどこか)を判定する必要がある

Slide 56

Slide 56 text

Copyright Hacobu, Inc. 56 コース • 運行をさらにグルーピングしたもの ‒ 運行: ある日の秋葉原駅->東京駅->浜松町駅という実績 ‒ コース: 山手線外回り • 日毎に考えても効果が薄いので最適化はコース単位で考えていきたい ‒ 月に21日稼働しているコースAと25日稼働しているコースBを統合して車両一台で配送できると嬉しい • コースを定義している会社は少ない(マスタ登録している所はもっと少ない) • 定義まではしてなくとも現場の感覚がある場合はあるが、配送先の列として定義されてたり、車両は関係あったりなかったり • プロダクト独自のコースを定義し、分析する

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Copyright Hacobu, Inc. 58 会社を横断した分析 • 物流が競争領域ではない場合は、競合でも物流は協力することもある • 会社でデータを出し合って分析し、共同配送に繋げたい • 出したくないデータももちろんある • プロジェクトを作り、データ提供ルールを設定し、閲覧権限をつけて互いに分析できる環境を用意できるようにプロジェクト利用会社利用会社共有DB ダッシュボード特定の部門・期間のデータのみ提供

Slide 59

Slide 59 text

Copyright Hacobu, Inc. 59 プロダクトやシステムを横断した分析プロジェクト利用会社共有DB • 各プロダクトからデータを取り込み、外部システムからもデータ入力する • 当然それぞれのプロダクトやシステムでは各々で最適なデータを持っている • そんなデータを全部横断して分析する利用会社利用会社利用会社 X-Data Fleet Berth 利用会社利用会社利用会社外部システムからCSV入力

Slide 60

Slide 60 text

Copyright Hacobu, Inc. 60 分析データの生成 • データ基盤ではよくある感じの構成 • ETLタスクのようなものをそれぞれ実行し、最終成果物として分析に最適化されたテーブルが出来上がる • 現状ではバッチのたびに全データを洗い替えている外部システム Berth Fleet データウェアハウスデータマートデータレイク

Slide 61

Slide 61 text

Copyright Hacobu, Inc. 61 PoCフェーズ • データ基盤上のデータを使って分析・実装 ‒ 本番DBとは独立しているので影響を与えない ‒ 既に稼働しているのでいきなりデータを分析する所から開始できた • Dataform でバッチを実装 • IAP, cloud run で実装し、顧客に使ってもらってFBをもらい改善していく Berth Fleet AWS / RDS Google Cloud / BigQuery Fleet dataset Berth dataset X-Data dataset Dataform

Slide 62

Slide 62 text

Copyright Hacobu, Inc. 62 本番システム構成 1. 各々の本番DBからS3へ export プロダクト X-Data 2. Athena でクエリ 3. 結果を読み込み 4. 変換 5. X-Data のDBへ投入 6. DB上での変換クエリ

Slide 63

Slide 63 text

バッチの改善

Slide 64

Slide 64 text

Copyright Hacobu, Inc. 64 バッチ改善1 1. 各々の本番DBからS3へ export プロダクト X-Data 2. Athena でクエリ 3. 結果を読み込み 4. 変換 5. X-Data のDBへ投入 6. DB上での変換クエリ Before: Athena で全件取得し、一旦メモリにのせ変換してDB投入 After: Athena からちょっとずつ取得し、2~5をストリーム処理

Slide 65

Slide 65 text

Copyright Hacobu, Inc. 65 運行とコース Fleet のデータを地点に立ち寄った実績の列秋葉原駅 26日10時東京駅 26日11時浜松町駅 26日12時秋葉原駅 27日10時東京駅 27日11時浜松町駅 27日12時 1運行を切り出すコースにまとめる(山手線外回り)

Slide 66

Slide 66 text

Copyright Hacobu, Inc. 66 バッチ改善1 • Athenaによりジオフェンス実績をロードし、運行へのグルーピングする処理 • ジオフェンス実績のロードは並列に実行しても大丈夫なので月単位で並列実行 • 月の中では日時で並び替えし、前から見ていって運行にグルーピングしていく • 「前から見ていく」という性質とAthenaの「結果の取得は1000件ずつ」という仕様を組み合わせて、golang のgoroutine & channel でストリーム処理する • 結果としてデータ全件をメモリにのせずに処理できるようになった goroutine 1000件ずつ前から取得運行へ変換

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Copyright Hacobu, Inc. 68 バッチ改善2 Before: できるだけSQLで処理する After: Golang で変換と同時に一部前処理を行い、SQLの処理をシンプルにする地点時刻運行フラグ秋葉原駅 11/26 10:00 1 東京駅 11/26 10:30 1 新橋駅 11/26 11:00 1 1 浜松町駅 11/26 12:00 1 1 秋葉原駅 11/27 10:00 2 東京駅 11/27 11:00 2 浜松町駅 11/27 12:00 2 1 「ひとつの運行の中で東京駅より後ろの地点」のようなフラグを作りたかった。SQLでもできるけど、、 4の変換タスクはGolang で書いていて、地点データも運行データもある -> この時点でフラグ立ててしまう

Slide 69

Slide 69 text

全体まとめ

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Copyright Hacobu, Inc. 71 全体アーキテクチャ FleetやBerth等のプロダクトデータやプロダクトプラットフォームの共通マスタを利用してデータ分析を行えるプロダクトプラットフォーム Fleet Berth X-Data

Slide 72

Slide 72 text

Copyright Hacobu, Inc. 72 Fleetまとめ • トラック毎にデータが流れる経路を固定することで正しくデータ処理 • lambdaの役割分割とkinesisシャード分割で並列処理 • オンライン処理では実現できない要件にマイクロバッチで対応外部連携先 ... ... ... ... ...

Slide 73

Slide 73 text

Copyright Hacobu, Inc. 73 分析データの生成 • データ基盤ではよくある感じの構成 • ETLタスクのようなものをそれぞれ実行し、最終成果物として分析に最適化されたテーブルが出来上がる • 現状ではバッチのたびに全データを洗い替えている外部システム Berth Fleet データウェアハウスデータマートデータレイク

Slide 74

Slide 74 text

Copyright Hacobu, Inc. 74 まとめ • プロダクト・プラットフォームとそこで動くMOVOシリーズ。MOVOが現場の課題解決する中で生成されたデータを分析してさらなる効果を生み出す • Fleet は処理するデータ量が多く、要望に答えるために様々な工夫をしている • 各々のプロダクトで生み出されたデータを統一的に分析できる形にまとめて利用 Backend / Frontend / EM / QA 積極採用中です！ https://career.hacobu.jp/

Slide 75

Slide 75 text

No content