Upcoming SlideShare
ゲーム開発者から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
Be the first to comment