タクシー車両の位置状態情報を支えるシステムのインフラ構成

GO TechTalk #32 タクシーアプリ『GO』の最強SREチーム で発表した資料です。

■ YouTube
https://www.youtube.com/watch?v=JKqmWhSqusg
■ connpass
https://jtx.connpass.com/event/379672/

Transcript

1. タクシー車両の位置状態情報を支えるシステムの インフラ構成 廣近 理希 1
2. © GO Inc. 自己紹介 GO株式会社 技術戦略部 SRE / 廣近 理希 前職・前々職にてオンプレ /クラウド両方のインフラの設計から運用までの業務を経験 2019年にGO株式会社入社 SREグループにてインフラ業務全般に従事 趣味: 音楽(観る/演る),映画,海外ドラマ,お笑い,etc… 2
3. © GO Inc. タクシーの位置状態情報 3
4. © GO Inc. タクシーの位置状態情報とは 簡単に言うと... 『GO』アプリで動いてるタクシー車両 の元となっている情報 配車サービス上では、あくまで位置状態情報の一部を利用 位置状態情報が持っているもの一例 ・緯度経度 ・方角 ・今どんな状態？(空車or迎車or賃走or貸切...) ・少し前にどこにいた？(少し前の緯度経度) ・道路は？(高速or一般道) ・タクシー車両orライドシェア車両 ・乗務員さんが使ってる端末の情報 　・・・ これらの位置状態情報データを稼働している車両台数分、 今回紹介するシステムが扱っています 位置状態情報 位置状態情報 この 位置状態情報のことを通称、 動態と呼んでいます 4
5. © GO Inc. タクシーの動態の利用用途 配車 データ解析 サービス連携 タクシーアプリ『GO』 『GO BUSINESS』 etc… 到達予定時刻(ETA)の誤差低減 AI配車のプロダクト改善 etc… 地図アプリ連携 提携タクシー事業者の配車センター連携 etc… GOが提供するサービスにとって重要な情報 5
6. © GO Inc. システム構成の説明 6
7. © GO Inc. システムの全体構成の概略 タクシー ライドシェア車両 動態情報を扱うシステムたち ・大きくPublisher, Redis Pub/Sub, Subscriber 3つのコンポーネント ・非同期かつ疎結合なアーキテクチャにすることで、膨大な量のデータに対してそれぞれ独立したリクエ スト要件と処理に特化 ・PublisherとSubscriberはGKE上にある弊社の共通インフラ基盤上にて構築 車両 Subscriber Publisher Redis Pub/Sub 共通インフラ基盤(GKE) 7
8. © GO Inc. Publisher Publisher 実際にデータをやりとりするのは乗務員が操作する端末(タブ レットやスマートフォン) gRPC client streaming 端末固有の情報を含んだ認証情報で検証し、 gPRC streamingコネクションを生成 逆ジオコーディング処理： 位置情報に対して、 住所や地名情報を追加 逆ジオコーディング 他 認 証 Redis Pub/Sub Publisher 8
9. © GO Inc. Publisher Publisher gRPC client streaming 認 証 Redis Pub/Sub Publisher stream内で数秒間隔ごとに動態情報を送信 一定時間経過で端末側が切断・再接続 9 逆ジオコーディング 他 一時的なネットワーク断 →端末側が検知し新たに再接続 ⚠サービス的には数秒間隔の動態うちの一時的な欠落としてある程度許容する
10. © GO Inc. Redis Pub / Sub ・Memorystore for Redis利用 ・物理的に冗長化 ・CPU負荷は、主にpublish回数とSubscriber数(と動態サイズ)が関係 (送られてきた1つの動態を複数Subscriberに送る処理が動態件数分行われるため) Publisherから送られる 全ての動態が流される Publisher Publisher C B A C A B channel 1 Redis Pub/Sub Subscriber Subscriber A B C A B C 全Publisher,Subscriber同じchannelに接続 10
11. © GO Inc. Subscriber 分析用サービス タクシー事業者連携サービス 地図連携サービス stream内で動態が送られてくる 一定時間経過で各クライアント側が切断・再接続 クライアント群 チャンネルに接続した時点から 動態情報をsubscribe開始 Redis Pub/Sub Subscriber Subscriber Subscriber gRPC server streaming streamで動態を受け続けるのではなく 今時点の動態情報を欲しい範囲に絞って取得したいケースも 11
12. © GO Inc. クライアントの１つ：半径近傍検索サービス Subscriber Redis Pub/Sub 配車関連 サービス 半径近傍検索サービス gRPC streaming 緯度,経度,半径 動態 オンメモリで直近数十秒程度の動態のみ保持 保持期間(数十秒程度)を過ぎたデータは破棄 REST / gRPC(unary) 12 緯度経度とそのポイントからの半径距離を指定したAPIリクエストを受け付け、 その範囲内にある動態情報を返却するサービス
13. © GO Inc. 運用してみて 13
14. © GO Inc. 相当数のトラフィックでも安定的に動いてくれています 相当数(件数非公開)のトラフィック publish件数(rps) CPU MEM CPU使用率は主にpublish数に依存: Subscriberのpodのスケールが少ないため メモリ使用量はpublish数に比例しない： Redis Pub/Sub はメッセージを保持し続けないので、 メモリ使用量が線形に膨れ上がることがなく、 使用量をあまり気にかけなくていい点で管理が楽 この時のRedis負荷傾向は...? 14
15. © GO Inc. 過去のトラブル案件例 事例：本システム入れ替えの設定作業時、誤ってSubscriberのCPU割り当て&台数を低く設定する => Subscriberが多数スケールし、Redis CPUが100%に張り付く 対応：Subscriberのリソース設定の修正・Subscriberのpod数の上限を決めておきアラート設定 事例：新たに動態を使いたいサービスがSubscriberにつなぐ => Subscriberからの全動態を受けきれず、クライアント側でメモリリークが発生する 対応：クライアント側での一時処理の簡素化・高速化を依頼 事例：Publisherの通信経路設定にミスがあり、Redis Pub/Subに書き込めない => Publisherがキューを溜め込んでしまいOOMが発生する 対応：通信経路設定修正・Publisherがpublishできない時にメモリに貯めないようにする改修 15
16. © GO Inc. 残課題１：端末とPublisherのコネクション保持の運用負荷 課題 • (再接続の仕様はあるものの)繋ぎ続けるgRPC streamingの通信（特にグローバルを通る経路）の担保が難しい • streamingのコネクションを張り続けること自体、スケーリングのしづらさからシステムの安定性低下に 背景 • 設計当初gRPC streaming接続を利用していたのは、重たい認証オーバヘッドを最小限にすることが主な理由 対応方針 • オーバーヘッドの少ない認証方法を検討・採用し都度認証にすることで常駐コネクション(streaming)の脱却をはかる 認 証 Publisher Redis Pub/Sub gRPC client streaming 16
17. © GO Inc. 課題 • 流れてくる膨大な全動態情報をstreamingで受け付けて一時処理を加え続けることがクライアントにとって負担に 対応方針 • 各クライアントは受け取った全ての動態が必要なわけではないため、以下を検討 ◦ 動態データの中身の精査 ◦ クライアントにあわせたPub/Subチャンネルの分離 ◦ 各クライアント専用のSubscriberを作成 • ただし、Subscriberの専用性と汎用性とのバランスは考える必要あり 残課題２：全ての動態をクライアントが処理しなければならない Publisher Publisher channel 1 Redis Pub/Sub Subscriber 全動態を処理し続ける必要 クライアント 17
18. © GO Inc. まとめ GOが扱っているタクシー車両の位置状態情報の集約管理システムをコンポーネントごとに分けてご紹介しました。 ・Redis Pub / Sub への処理に特化したPublisherとSubscriberを用意して動態を受け渡す ・Publisher,Subscriberを使う端末やサービスはgRPC streamingで繋ぎ込み、定期的な再接続を行う ・Subscriberの先に直近の動態情報に特化したサービスを作成し提供 ・扱っているデータ量も多いが比較的安定的に稼働 Publisher gRPC client streaming 逆ジオコーディング 認 証 Redis Pub/Sub Publisher 分析用サービス タクシー事業者連携サービス 地図連携サービス Subscriber Subscriber Subscriber gRPC server streaming 配車関連 サービス 半径近傍検索サービス REST/gRPC(unary) Subscriber 18
19. © GO Inc. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください 19