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

アーキテクチャ Conference 2024
2024年11月26日（火）
https://architecture-con.findy-tools.io/

Transcript

1. Confidential マルチプロダクト戦略におけるデータ 分析プロダクトのアーキテクチャ アーキテクチャ Conference 2024 2024年11月26日 テクノロジー本部CTO室 三木拓史
2. Copyright Hacobu, Inc. 2 自己紹介 • テクノロジー本部 CTO室 室長 三木 拓史 • Hacobuでの活動 ‒ 動態管理サービス MOVO Fleet のフルリプレースをリード ‒ データ基盤立ち上げ ‒ 配送案件管理サービスMOVO Vista プロダクトエンジニア ‒ CTO室として共通プラットフォーム、データ基盤、PoC開発
3. 会社紹介
4. Copyright Hacobu, Inc. 4 Hacobu概要 ミッション：運ぶを最適化する 2015年6月 約150名 約46億円 創業 従業員数 累計資金調達額
5. Copyright Hacobu, Inc. 5 Hacobuの事業
6. Copyright Hacobu, Inc. 6 成長へのロードマップ
7. Copyright Hacobu, Inc. 7 事業・プロダクトについて、物流業界の課題 「運ぶを最適化する」ため、テクノロジー本部は複数のプロダクトを開発しています
8. Copyright Hacobu, Inc. 8 物流DXツール MOVO（ムーボ） 自社および外部のアプリケーションの利用を通じて、企業や業界の枠を超えて物 流情報を同じ規格でデジタルにやりとりできるプラットフォームとなり、蓄積さ れたビッグデータで「運ぶを最適化する」ことを目指しています 工場/出荷元 物流拠点 納品先 自社アプリケーション 外部アプリケーション ERP S/4 Hana WMS、WCS 配車システム 物流情報プラットフォーム 共通認証 共通機能群 共通マスタ 共通トランザクション TMS、SCPなど、 その他各社の システム 日野コネクト 東京海上 法人ドライブエージェント API API API API API 配送案件管理 トラック予約受付 動態管理 スマホアプリ
9. 物流領域の課題
10. Copyright Hacobu, Inc. 10 事業・プロダクトについて、物流領域の課題 物流プロセスには様々なプレーヤーが存在しています。 事業内容・規模が異なるプレーヤー間で物を運ぶための情報がアナログにやり取 りされています。 企業間物流の一例
11. Copyright Hacobu, Inc. 11 Hacobuが取り組む課題 アナログ（電話/FAX）なやりとりのため状況がわからない いつ荷積みできるのか いつ届くのか いつ誰が 荷積みにくるのか
12. Copyright Hacobu, Inc. 12 Hacobuが取り組む課題 消極的な意思決定により非効率・高コストな世界となる いつ荷積みできる のか いつ届くのか いつ誰が 荷積みにくるのか いつ荷積みできる のか いつ届くのか いつ誰が 荷積みにくるのか 電話して確認しよう 多めに発注しよう 早めに到着しよう
13. Copyright Hacobu, Inc. 13 Hacobuが取り組む課題 データが共有できないので、全体最適とならない 部分 最適 部分 最適 部分 最適 部分 最適
14. Copyright Hacobu, Inc. 14 事業・プロダクトについて、物流領域の課題 個社最適の影響で全体最適化が進んでいない物流領域に対し、 MOVOは複数プロダクトを展開し、各局面の課題に対してアプローチしています。 配車受発注・管理サービス
15. Copyright Hacobu, Inc. 15
16. Copyright Hacobu, Inc. 16 トラック予約受付サービス 「MOVO Berth」 バース予約 と 入退場受付
17. Copyright Hacobu, Inc. 17 トラック予約受付サービス 「MOVO Berth」
18. Copyright Hacobu, Inc. 18
19. Copyright Hacobu, Inc. 19 動態管理サービス 「MOVO Fleet」 通信型GPSトラッカーで車両の位置情報や予実を管理
20. Copyright Hacobu, Inc. 20 導入事例：三菱食品様 全国3,500台にMOVO Fleetを導入し、最適な配送網の構築に取り組まれている https://hacobu.jp/news/5903/
21. Copyright Hacobu, Inc. 21 三菱ふそう様の「Truckonnect®」と車両データの連携を開始 https://hacobu.jp/news/10145/
22. Copyright Hacobu, Inc. 22 事業・プロダクトについて、物流領域の課題 個社最適の影響で全体最適化が進んでいない物流領域に対し、 MOVOは複数プロダクトを展開し、各局面の課題に対してアプローチしています。 配車受発注・管理サービス
23. Copyright Hacobu, Inc. 23 物流ビッグデータラボ 物流ビッグデータラボは、企業間で物流データを共有し、個社や業界の垣根を超 えて物流の社会課題解決および共同輸配送の実現を目指します。 ①企業間での物流ビッグデータの共有と分析による共同輸配送の実現 ②物流効率化に向けた「データドリブン・ロジスティクス」の普及 ③モノが運べない事態になることを回避し、社会貢献につなげる https://hacobu.jp/news/11381/
24. マルチプロダクト戦略における データ分析プロダクトのアーキテクチャ
25. 全体像
26. Copyright Hacobu, Inc. 26 物流情報プラットフォームのデータ分析プロダクト(X-Data) 物流課題の解決 -> 情報のデジタルな蓄積 輸配送の合理化
27. Copyright Hacobu, Inc. 27 実現したい最適化 Berth 車両移動のFromTo 例: 東京 -> 大阪 Fleet 車両移動の軌跡データ 例:大阪 -> 名古屋 -> 神奈川 -> 東京 X-Data 車両移動を組み合わせて最適化 例: 「東京 -> 大阪」 と 「大阪 -> 名古屋 -> 神奈川 -> 東京」 を組み合わせる
28. Copyright Hacobu, Inc. 28 全体アーキテクチャ コンテナ 監視 CI/CD ・・・ 基盤 認証 通知 共通マスタ ・・・ 共通機能群(マイクロサービス) プロダクトの MS群 プロダクトの MS群 プロダクトの MS群 プロダクトの MS群 プロダクト プラットフォーム
29. Copyright Hacobu, Inc. 29 全体アーキテクチャ FleetやBerth等のプロダクトデータやプロダクトプラットフォームの 共通マスタを利用してデータ分析を行える プロダクトプラットフォーム Fleet Berth X-Data
30. Copyright Hacobu, Inc. 30 データ基盤 • AWS上で稼働しているプロダクトのデータをGoogle Cloudへ転送しデータ 基盤として活用 • プロダクトへ影響を与えることなく分析を行える • 複数プロダクト(DB)にまたがって分析を行いたい時にはRDS -> BigQuery へ転送しておくと便利 • データ分析プロダクトのPoC実装を行いやすい環境
31. 前半 ~ 動態管理サービスFleetの話
32. Copyright Hacobu, Inc. 32 Fleet • IoTデバイスにより位置情報を蓄積していく • ジオフェンス機能によりある地点への立ち寄りを自動で記録 ‒ 例) 大阪 -> 名古屋 -> 神奈川 -> 東京 • 月間で17億程度の位置情報を処理している • 位置情報処理の話
33. Copyright Hacobu, Inc. 33 位置情報に関わるアーキテクチャの図 外部連携先 ... ... ... ... ...
34. 概要と位置情報の保存
35. Copyright Hacobu, Inc. 35 lambdaでやっていることの概要 • 大きく4つの処理を行なってる • 位置情報の保存(dynamoDBへのinsert) • ジオフェンスの判定と継続時間の計算 • 他2つ • それぞれの処理に対してlambda が1種類 • 1つのシャードに対して拡張ファンアウトに より4種類のlambdaがそれぞれデータ処理 • 現状12本のシャードで運用 ... ... ... ... 4種類のlambda Kinesisシャードを 12本用意 ...
36. Copyright Hacobu, Inc. 36 位置情報の保存 • デバイスが5sに一度、位置情報をuploadする ‒ 三菱食品様を例にすると ‒ 3500台が5sにリクエストを飛ばしてくる ‒ 1日8時間稼働で2000万リクエスト • 外部システムとのデータ連携も • Kinesisでバッファ ‒ Lambda側で障害があってもkinesisに貯めておけるので データロストだけは避けることができる ‒ 何度か助けられた • DynamoDBに保存
37. Copyright Hacobu, Inc. 37 軌跡の活用 • 位置情報はDynamoDBに保存している • ある車両を指定し、時間幅を指定した位置情報のまとまり(=軌跡)を取得して ブラウザに表示したりする • 1車両あたり90日間50万レコードがいつでも参照される可能性がある • 車両IDがパーティションキー • 時刻がソートキー
38. ジオフェンス処理
39. Copyright Hacobu, Inc. 39 Wikipedia での解説 ジオフェンシング（英： Geofencing）とは実世界の地理に対応した仮想的な境 界線で囲まれたエリアへの出入りや一定時間以上の滞在をトリガーにアクション を行う技術である。 主にセキュリティや広告、通知を用いたサービスに用いられ ている。 https://ja.wikipedia.org/wiki/ジオフェンシング
40. Copyright Hacobu, Inc. 40 ジオフェンス • ある地点を中心にして、半径R[m]の範囲に、基準時間以上滞在している場合 にそれを記録する ‒ 地点 x 進入時間 x 退出時間が実績になる • 車両ごとに時系列順で処理を行う必要がある 進入時間 退出時間 滞在時間
41. Copyright Hacobu, Inc. 41 ジオフェンス 最近多角形にも対応した https://hacobu.jp/news/12524/
42. Copyright Hacobu, Inc. 42 ジオフェンス処理のフロー 進入時間 退出時間 滞在時間 地点外 地点内 基準時 間未満 実績生成 退出 1.進入 5.退出 3.基準時間経過後 進入判定を記録 4.退出時間 を記録 2.進入時間を記録 基準未満で 退出
43. Copyright Hacobu, Inc. 43 ジオフェンス処理のシステム構成 • 「車両ごとに」 ‒ 車両IDをキーにしてkinesisシャードへ分配 ‒ シャードごとにジオフェンス処理を行うlambda は1つ • 同一の車両に関するレコードは常に同一のlambdaが処理する ... ... ... ... ... ある車両Aに 関するデータ は常にここを 通る
44. Copyright Hacobu, Inc. 44 ジオフェンス処理 - job編 - • 3の処理は進入時間からの経過時間で記録したい • トラックのエンジンが切られるなどして、位置情報のuploadが止まることがある • 位置情報のuploadが止まっても、一定以上の滞在時間が経過したら実績を作りた い 地点外 地点内 基準時間 未満 実績生成 退出 1.進入 5.退出 3.基準時間経過後 進入判定を記録 4.退出時間 を記録 2.進入時間を記 録 基準未満で退出 ここの処理を、位置情報 uploadというイベントがなく ても実行したい
45. Copyright Hacobu, Inc. 45 ジオフェンス処理 - job編 - ... ... ... ... ... データが流れない マイクロバッチで データ監視&補正
46. 性能改善
47. Copyright Hacobu, Inc. 47 lambdaの性能改善 • Lambdaの処理に時間がかかるようになり、kinesisにデータがたまるように なってきてしまった ‒ 画面への反映が遅れたり、遅延判定ができなかったり ‒ とはいえ地点情報がロストしないのはkinesisを使って良かったところ • 役割の分離 && シャード分割 ‒ 地点情報の保存、ジオフェンス処理、その他2つを分離した ‒ Kinesisからファンアウトしてそれぞれlambdaを実行 ‒ シャードを分割し並列に実行することで性能改善を図った ... ... ... ... ...
48. Copyright Hacobu, Inc. 48 lambdaの性能改善 結局のところ、当時はDBでインデックスを追加するのが一番効いた
49. Copyright Hacobu, Inc. 49 まとめ • トラック毎にデータが流れる経路を固定することで正しくデータ処理 • lambdaの役割分割とkinesisシャード分割で並列処理 • オンライン処理では実現できない要件にマイクロバッチで対応 外部連携先 ... ... ... ... ...
50. 後半 ~ データ分析プロダクトX-Dataの話
51. Copyright Hacobu, Inc. 51 共同輸配送支援サービス 「MOVO X-Data」
52. Copyright Hacobu, Inc. 52 共同輸配送支援サービス 「MOVO X-Data」
53. Copyright Hacobu, Inc. 53 共同輸配送支援サービス 「MOVO X-Data」
54. Copyright Hacobu, Inc. 54 実現したい最適化 Berth 車両移動のFromTo 例: 東京 -> 大阪 Fleet 車両移動の軌跡データ 例:大阪 -> 名古屋 -> 神奈川 -> 東京 X-Data 車両移動を組み合わせて最適化 例: 「東京 -> 大阪」 と 「大阪 -> 名古屋 -> 神奈川 -> 東京」 を組み合わせる
55. Copyright Hacobu, Inc. 55 運行 Fleet のデータを地点に立ち寄った実績の列 秋葉原駅 26日10時 東京駅 26日11時 浜松町駅 26日12時 秋葉原駅 27日10時 東京駅 27日11時 浜松町駅 27日12時 大雑把には1日ごとに 1運行を切り出したい 現実的には、、 - 運送会社によって稼働している時間が色々(夜間が中心の場合もある - 「実績が取れる = Fleetで設定している」ということ。設定もれや、どこまで設定するか (車庫とか)は場合による - 「地点に立ち寄った」ということしか分からないので、どこで運行が開始したか(切れ目 はどこか)を判定する必要がある
56. Copyright Hacobu, Inc. 56 コース • 運行をさらにグルーピングしたもの ‒ 運行: ある日の秋葉原駅->東京駅->浜松町駅という実績 ‒ コース: 山手線外回り • 日毎に考えても効果が薄いので最適化はコース単位で考えていきたい ‒ 月に21日稼働しているコースAと25日稼働しているコースBを統合して車両一台で配送 できると嬉しい • コースを定義している会社は少ない(マスタ登録している所はもっと少ない) • 定義まではしてなくとも現場の感覚がある場合はあるが、配送先の列として定 義されてたり、車両は関係あったりなかったり • プロダクト独自のコースを定義し、分析する
57. Copyright Hacobu, Inc. 57 短稼働コースの統合 午前中に稼働してるコースと午後に稼働してるコース、現状は別のトラックが 担ってるけど一台で実行できないか? 時間的に可能か 空間的に可能か
58. Copyright Hacobu, Inc. 58 会社を横断した分析 • 物流が競争領域ではない場合は、競合でも物流は協力することもある • 会社でデータを出し合って分析し、共同配送に繋げたい • 出したくないデータももちろんある • プロジェクトを作り、データ提供ルールを設定し、閲覧権限をつけて互いに分析 できる環境を用意できるように プロジェクト 利用会社 利用会社 共有DB ダッシュボード 特定の部門・ 期間のデータ のみ提供
59. Copyright Hacobu, Inc. 59 プロダクトやシステムを横断した分析 プロジェクト 利用会社 共有DB • 各プロダクトからデータを取り込み、外部システムからもデータ入力する • 当然それぞれのプロダクトやシステムでは各々で最適なデータを持っている • そんなデータを全部横断して分析する 利用会社 利用会社 利用会社 X-Data Fleet Berth 利用会社 利用会社 利用会社 外部システムからCSV入力
60. Copyright Hacobu, Inc. 60 分析データの生成 • データ基盤ではよくある感じの構成 • ETLタスクのようなものをそれぞれ実行し、最終成果物として分析に最適化さ れたテーブルが出来上がる • 現状ではバッチのたびに全データを洗い替えている 外部システム Berth Fleet データ ウェアハウス データマート データレイク
61. 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
62. Copyright Hacobu, Inc. 62 本番システム構成 1. 各々の本番DBからS3へ export プロダクト X-Data 2. Athena でクエリ 3. 結果を読み込み 4. 変換 5. X-Data のDBへ投入 6. DB上での変換クエリ
63. バッチの改善
64. 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をストリーム処理
65. Copyright Hacobu, Inc. 65 運行とコース Fleet のデータを地点に立ち寄った実績の列 秋葉原駅 26日10時 東京駅 26日11時 浜松町駅 26日12時 秋葉原駅 27日10時 東京駅 27日11時 浜松町駅 27日12時 1運行を切り出す コースにまとめる(山手線外回り)
66. Copyright Hacobu, Inc. 66 バッチ改善1 • Athenaによりジオフェンス実績をロードし、運行へのグルーピングする処理 • ジオフェンス実績のロードは並列に実行しても大丈夫なので月単位で並列実行 • 月の中では日時で並び替えし、前から見ていって運行にグルーピングしていく • 「前から見ていく」という性質とAthenaの「結果の取得は1000件ずつ」と いう仕様を組み合わせて、golang のgoroutine & channel でストリーム処 理する • 結果としてデータ全件をメモリにのせずに処理できるようになった goroutine 1000件ずつ前から取得 運行へ変換
67. Copyright Hacobu, Inc. 67 Athenaからデータ取得し、運行 に変換してchannelに入れる 並列に変換した結果が溜まっていくchannel 溜まった変換結果を適当なチャンク サイズにまとめてDBに入れる
68. 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 で書いていて、地点 データも運行データもある -> この時点でフラ グ立ててしまう
69. 全体まとめ
70. Copyright Hacobu, Inc. 70 物流情報プラットフォームのデータ分析プロダクト(X-Data) 物流課題の解決 -> 情報のデジタルな蓄積 輸配送の合理化
71. Copyright Hacobu, Inc. 71 全体アーキテクチャ FleetやBerth等のプロダクトデータやプロダクトプラットフォームの 共通マスタを利用してデータ分析を行える プロダクトプラットフォーム Fleet Berth X-Data
72. Copyright Hacobu, Inc. 72 Fleetまとめ • トラック毎にデータが流れる経路を固定することで正しくデータ処理 • lambdaの役割分割とkinesisシャード分割で並列処理 • オンライン処理では実現できない要件にマイクロバッチで対応 外部連携先 ... ... ... ... ...
73. Copyright Hacobu, Inc. 73 分析データの生成 • データ基盤ではよくある感じの構成 • ETLタスクのようなものをそれぞれ実行し、最終成果物として分析に最適化さ れたテーブルが出来上がる • 現状ではバッチのたびに全データを洗い替えている 外部システム Berth Fleet データ ウェアハウス データマート データレイク
74. Copyright Hacobu, Inc. 74 まとめ • プロダクト・プラットフォームとそこで動くMOVOシリーズ。MOVOが現場の 課題解決する中で生成されたデータを分析してさらなる効果を生み出す • Fleet は処理するデータ量が多く、要望に答えるために様々な工夫をしている • 各々のプロダクトで生み出されたデータを統一的に分析できる形にまとめて利用 Backend / Frontend / EM / QA 積極採用中です！ https://career.hacobu.jp/