ゲーム開発者からMaaS開発者へゲーム開発のノウハウを活かして移動体情報配信システムを作ってみた [DeNA TechCon 2019]

1. #denatechcon #denatechcon ゲーム開発者からMaaS開発者へ〜ゲーム開発のノウハウを活かして『移動体情報配信システム』を作ってみた惠良和隆(@erakazu) オートモーティブ事業本部モビリティインテリジェンス開発部

2. #denatechcon 質問

3. #denatechcon どんな業務に携わっていますか？ A) ゲーム開発 B) インターネットサービス開発 C) インフラ担当 D) 自動車関連サービス開発 E) 上記以外

4. #denatechcon 自己紹介 • 2002年4月〜2013年9月：コンシューマゲーム開発 • 2013年10月〜2018年6月：モバイルゲーム開発 • 2018年7月：オートモーティブ事業本部に異動。サーバー開発・保守、地図データ整備を担当 • 最近は、移動体情報配信システムを始め、複数のシステム開発を担当

5. #denatechcon MaaSとは？

6. #denatechcon MaaSとは？ • Mobility as a Service • ≠Metal as a Service • ICT を活用して交通をクラウド化し、公共交通か否か、またその運営主体にかかわらず、マイカー以外のすべての交通手段によるモビリティ（移動）を 1 つのサービスとしてとらえ、シームレスにつなぐ新たな「移動」の概念である (国土交通省PRI Reviewより)

7. #denatechcon MaaSのポイント • 各公共交通サービスのIT化 • 様々な交通サービスを跨いで横断的に活用する • マイカー以外の、より自由な移動を実現する

8. #denatechcon DeNAにおけるMaaS • MOV • タクシーのIT化 • 配車システム、AIを活用した推奨経路案内など • Easy Ride • 日産自動車と開発中の無人運転車両を活用した交通サービス

9. #denatechcon 交通のIT化における重要ポイント • 車輛の状態の把握 • 現在位置 • 利用状況 • 運行状況 • MOVでは • 車輛の情報を数秒間隔で収集 • 収集された情報を元に、配車可能な車輛の把握を行う

10. #denatechcon 車輛情報はサービスの根幹 • リアルタイム情報 • 配車や現在の状況把握に必須 • エンドユーザーに状況を伝えるためにも、低遅延な情報伝達が求められる • 履歴情報 • 過去の状況を確認するために必須 • カスタマーサポート • 分析 • システムの動作検証などにも活用可能

11. #denatechcon 車輛情報を活用するために • リアルタイム情報と履歴情報のどちらも簡単に利用出来ることが重要 • ログに貯めているけどすぐに使えないのでは意味がない • 位置情報は個人情報にあたる • 例：お客様が乗車されているタクシーの位置情報が他のお客様に見えてはならない • 外部に公開しないとしても取り扱いには配慮が必要 • アクセス権コントロール • ファイルとして情報を扱わない

12. #denatechcon 移動体情報配信システム

13. #denatechcon コンセプト • 移動体＝車輛＋人 • データソースの種類に関係なく、統一された仕組みで移動体の情報をストリーム配信する • 適切なアクセス権コントロール • 移動体・データ受信者の増加に対応できる、十分なスケーラビリティを持つ • 必要な範囲の情報に限定して受信する

14. #denatechcon コンセプト • 移動体＝車輛＋人 • データソースの種類に関係なく、統一された仕組みで移動体の情報をストリーム配信する • 適切なアクセス権コントロール • 移動体・データ受信者の増加に対応できる、十分なスケーラビリティを持つ • 必要な範囲の情報に限定して受信する

15. #denatechcon これって・・・ MMORPGのLocationServer と同じじゃね？

16. #denatechcon Location Serverって？ • ユーザーキャラやNPCの位置情報を配信する • 広いゲームワールドに点在するユーザーやNPC の情報で必要となるものは極僅か • ユーザーの周囲の情報に限定して受信する

17. #denatechcon 周囲の情報に限定した受信とは 1Km 1Km 自プレイヤーキャラ他プレイヤーキャラ NPC

18. #denatechcon 周囲の情報に限定した受信とは自プレイヤーキャラを中心とした 4x4メッシュの範囲が必要な情報なので、この範囲のデータだけを受信する自プレイヤーキャラ他プレイヤーキャラ NPC 1Km 1Km

19. #denatechcon Location Serverって？ • ユーザーキャラやNPCの位置情報を配信する • 広いゲームワールドに点在するユーザーやNPC の情報で必要となるものは極僅か • ユーザーの周囲の情報に限定して受信するサーバー負荷やネットワーク帯域を抑制しつつ、ゲーム体験を損ねないようにしている

20. #denatechcon ゲーム開発経験による気付き • ユーザーにとって必要な情報に限定したデータ配信は、サーバー負荷とネットワーク帯域、さらにはクライアント側の負荷を低減する上で重要 • 移動体情報配信システムにおいても同様で、必要な範囲の情報に限定して受信する機能を持たせることでシステム全体の負荷を抑制できる

21. #denatechcon 移動体情報配信システムのアーキテクチャ

22. #denatechcon 技術要素 • gRPC Stream API • Google Cloud Endpoints for gRPC • Envoy • Redis Pub/Sub • Kubernetes • Google Cloud Pub/Sub • Amazon Kinesis Data Streams

23. #denatechcon gRPC Stream API • RPCフレームワーク • 様々な言語をサポート • 以下のRPCライフサイクルに対応 • Unary RPC • Server Streaming RPC • Client Streaming RPC • Bidirectional Streaming RPC • gRPC-Webの利用を考える場合 • Unary RPC • Server Streaming RPC 移動体情報配信システムはgRPC-Webの利用も想定

24. #denatechcon Google Cloud Endpoints for gRPC • gRPCに対応したAPI管理サービス • Extensible Service Proxy(ESP)が API認証の仕組みを提供 • ユーザー認証：Firebase、Auth0、Google IDトークン • サービス間認証：サービスアカウント • ESPはnginxベースのProxy • SSL Termination • HTTP/JSONリクエストをgRPCに変換する機能 (ただし、Unary RPCのみ)

25. #denatechcon Envoy • Lyftが開発したSidecar Proxy • Load Balancing • Retry • Circuit Breaking • Rate Limiting • …etc • SSL Termination • gRPC-WebのためのProxyとして利用 • 現在、gRPC-Webを利用するためにはEnvoyのようなProxyが必須

26. #denatechcon Redis Pub/Sub • Redisが持つPub/Sub機能 • レプリケーションやクラスタ構成があっても Publishされたメッセージが適切にSubscriber に届く • パターンマッチによるSubscribeをサポート • Glob形式のパターンにマッチするすべてのチャンネルのメッセージを受信可能 • hoge1, hoge2, hoge3 -> hoge? or hoge[1-3] or hoge*

27. #denatechcon Kubernetes • コンテナオーケストレーションエンジン • Infrastructure as a Code • オートスケールほか多くの機能 • パブリッククラウド上でもマネージドサービスが提供されている • GKE（Google Kubernetes Engine） • EKS（Amazon Elastic Container Service for Kubernetes） • AKS（Azure Kubernetes Service）

28. #denatechcon Google Cloud Pub/Sub • GCPで提供されるPub/Sub • 大規模なメッセージングに耐えられるスケーラビリティ • MOVでは、AWS IoTで収集した車輛情報を Cloud Pub/Subを経由してBigQueryに蓄積している • ただし、メッセージの遅延、順序の入れ替わり、複製などが発生することを考慮する必要あり

29. #denatechcon Amazon Kinesis Data Streams • AWSの提供するリアルタイムデータストリーミングサービス • スケーラブル • 高いリアルタイム性能 • 収集されたデータを70〜200msec以内に利用可能 • オートスケールしない • リアルタイムデータを利用したい場合のデータソースとして適している

30. #denatechcon 移動体情報配信システムの構成 Publisher (gRPC Client) Subscriber (gRPC Client) PublishService (gRPC Service) PublisherManageService (gRPC Service) SubscribeService (gRPC Service) Redis Pub/Sub Server Process BigQuery Cloud Pub/Sub 各種データソース

31. #denatechcon 移動体情報配信システムの構成 Publisher (gRPC Client) Subscriber (gRPC Client) PublisherManageService (gRPC Service) SubscribeService (gRPC Service) Redis Pub/Sub Server Process BigQuery Cloud Pub/Sub 各種データソース PublishService (gRPC Service) Publish用APIのみを提供する

32. #denatechcon 移動体情報配信システムの構成 Publisher (gRPC Client) Subscriber (gRPC Client) PublishService (gRPC Service) SubscribeService (gRPC Service) Redis Pub/Sub Server Process PublisherManageService (gRPC Service) BigQuery Cloud Pub/Sub 各種データソース外部データソースからデータを取得し、 Publish＆SubscribeするAPIを提供

33. #denatechcon 移動体情報配信システムの構成 Publisher (gRPC Client) Subscriber (gRPC Client) PublishService (gRPC Service) PublisherManageService (gRPC Service) Redis Pub/Sub Server Process BigQuery Cloud Pub/Sub 各種データソース SubscribeService (gRPC Service) SubscribeするAPIを提供

34. #denatechcon 移動体情報配信システムの構成 Publisher (gRPC Client) Subscriber (gRPC Client) PublishService (gRPC Service) PublisherManageService (gRPC Service) SubscribeService (gRPC Service) Server Process BigQuery Cloud Pub/Sub 各種データソース Redis Pub/Sub Redis Pub/Subは、各gRPC Service を繋ぐ役割＋範囲指定データ取得

35. #denatechcon Redis Pub/Subによる範囲指定データ取得 • 位置情報から8分の1地域メッシュコードを算出 (35.659008, 139.703499) → 53393596121

36. #denatechcon 地域メッシュコードとは？ • 地域メッシュ • 統計に利用するために、緯度・経度に基づいて地域を隙間なく網の目（メッシュ）の区域に分けたもの • 標準地域メッシュでは、第１次〜第３次まで定められている • さらに細分化した分割地域メッシュもある • 地域メッシュコード • 地域メッシュを識別するためのコード

37. #denatechcon ①第１次地域区画およそ 80km 四方東京度 40 分経度１度５３３９総務省統計局地域メッシュの区分図より抜粋

38. #denatechcon 1 ②第２次地域区画足立区　　　　江戸川区　　　葛飾区　　　　江東区　　　　北区　　　　　区　　　　　　　　　　　　　墨田区　　　　　　　　文京区　　　　千代田区　　　台東区　　　　荒川区　　　　中央区　　　　およそ 10km 四方第 1 次地域区画を 64 分割 (縦横それぞれ８等分) した区画５３３９-４６総務省統計局地域メッシュの区分図より抜粋

39. #denatechcon 千代田皇居外苑隼町丸の内永田町１丁目丸の霞が関２丁目霞が関１丁目日比谷公園有楽町１丁目有楽町２霞が関３丁目内幸町１丁目内幸町２丁目銀銀座目虎ノ門１丁目西新橋１丁目虎ノ門２丁目銀座新橋１丁目新橋２丁目 ③第３次地域区画＝基準地域メッシュ第 2 次地域区画を 100 分割 (縦横それぞれ 10 等分) した区画５３３９-４６-００およそ１ｋｍ四方（東京都の場合:縦 0.925km,横 1.132km）足立区　　　　江戸川区　　　葛飾区　　　　江東区　　　　北区　　　　　区　　　　　　　　　　　　　墨田区　　　　　　　　文京区　　　　千代田区　　　台東区　　　　荒川区　　　　中央区　　　　総務省統計局地域メッシュの区分図より抜粋

40. #denatechcon Redis Pub/Subによる範囲指定データ取得 • 位置情報から8分の1地域メッシュコードを算出 (35.659008, 139.703499) → 53393596121 5339 35 96 1 2 1 1次メッシュ 1/2 1/4 1/8 2次メッシュ 3次メッシュ

41. #denatechcon Redis Pub/Subによる範囲指定データ取得 • 位置情報から8分の1地域メッシュコードを算出 (35.659008, 139.703499) → 53393596121 • チャンネル名に含める ${カテゴリ名}/${メッシュコード}/${移動体ID} • PSubscribeで絞り込む • 3次メッシュの特定範囲を指定する場合 Pattern： ${カテゴリ名}/533935[4-9][6-9]* • 特定移動体を指定する場合 Pattern： ${カテゴリ名}/???????????/100

42. #denatechcon アクセス権コントロールについて • gRPC APIの認証は、Cloud Endpointsで • Google ID Tokenでユーザーアカウントを認証 • 認可は個別に実装する必要あり • JWTからアカウント情報を参照し、アクセス権を持つユーザーかどうかを判定 • G Suite Admin SDKのDirectory APIを使えるのであれば、特定の Googleグループメンバーかどうか判定 • ホワイトリストと突き合わせる

43. #denatechcon Cloud IAPじゃだめなの？ • Cloud Identity-Aware Proxy • アプリケーションへのアクセスを保護する • GKEで利用する場合は、Ingressを使うことで対応する • Googleグループに対してアクセス権を設定可能 • gRPCに対応できていない • gRPC-WebであってもServer Streaming RPCを使うと生じる不具合があって使えない

44. #denatechcon Kubernetesの構成 ESP gRPC Server Envoy ESP Redis gRPC Server Pod Pod Pod gRPC用Service gRPC-Web用Service LoadBalancer LoadBalancer ClusterIP Redis用Service

45. #denatechcon 全体構成 Car AWS Cloud Kubernetes cluster pod pod pod gRPC Service Cloud Load Balancing gRPC-Web Service Cloud Load Balancing ESP Container Engine Cloud Endpoints Envoy Container Engine ESP Container Engine gRPC Server Container Engine gRPC Server Container Engine Redis Container Engine Cloud Endpoints MOVの車輛情報収集システム移動体情報配信システム

46. #denatechcon スケーラビリティについて • システムの主要コンポーネントにDBが存在しないため、Disk I/Oネックになることが無い • 純粋な計算量やネットワーク帯域によって性能が決まる • gRPC Serverは負荷に応じてスケールアウト可能 • APIに持たせる機能に応じて適宜バランシングできる • Redisはクラスタ構成とすることでスケールアウト可能 • ノードの負荷は、メッセージ量とそのノードに接続したRedis ClientのPSubscribe数に比例する • 各ノードがすべてのメッセージを処理するため、メッセージの総量が増えてくると限界が来る（計算量／トラフィック） • 計算量の限界に到達：Redisが処理するパターンマッチをSubscribeService側で処理する • トラフィックの限界に到達：地域ごとにクラスタを分けるなど、Publishの段階で枝刈りする

47. #denatechcon 応用例

48. #denatechcon 運営・開発用ツール • 運行管理のために現在状態を把握 • 配車最適化 • 履歴情報を使った検証 • カスタマーサポート • 不具合検証のために過去の状況を再現

49. #denatechcon ユーザーアプリ向け情報配信 • 現在の車輛の位置をユーザーに配信 • 配車可能な車輛に限定して配信 • ユーザーの周囲の車輛のみ受信

50. #denatechcon demo

51. #denatechcon システム構成 Kubernetes cluster pod pod pod gRPC Service Cloud Load Balancing gRPC-Web Service Cloud Load Balancing ESP Container Engine Cloud Endpoints Envoy Container Engine ESP Container Engine gRPC Server Container Engine gRPC Server Container Engine Redis Container Engine Cloud Endpoints 移動体情報配信システムシミュレータログ再生プログラム (gRPC Client) Webアプリとして構成されたViewer (gRPC-Web Client)

52. #denatechcon

53. #denatechcon 性能 • 今回のdemo • データソース : シミュレータログ再生プログラム • データ受信側：ブラウザ上のViewerアプリ • 遅延時間：1秒未満（だいたい100msec以下） • 稼働中のシステム • データソース：MOVのタクシー車輛 • データ受信側：ブラウザ上のViewerアプリ、需要予測システムなど • 遅延時間：1〜2秒

54. #denatechcon まとめ • gRPCとRedisを利用した移動体情報配信システムを構築した • 常時接続型のAPIはゲームではよく利用されるものであり、ゲーム開発経験を生かしてシステム開発出来た • 範囲指定での受信 • スケーラビリティの担保 • ロードバランシング • 切断検知など • 異なる事業ドメインであっても、身につけた技術や経験は役に立つ

55. #denatechcon #denatechcon

ゲーム開発者からMaaS開発者へ ゲーム開発のノウハウを活かして 移動体情報配信システムを作ってみた [DeNA TechCon 2019]

DeNA