皆さんは弊社の「全国タクシー」や「Google Maps」でタクシーの現在位置が表示されることはご存知でしょうか。これは現時点の「空車」状態のタクシーの位置情報が表示されています。全国タクシーのシステムはタクシーから位置情報を含めた様々な情報(メーターの状態、移動速度、向きなど)を受け取っています。これらのタクシーの動向に関係する様々な情報をまとめて「動態情報」と呼んでいます。
動態情報は、お客様から注文を受けてタクシーを手配する「配車」に大きく関わってきます。全国タクシーアプリで注文をすると、最寄りのタクシーを検索するのですが、その時にこの動態情報を利用するわけです。しかしながら、この動態情報と配車の間にはまだまだ課題もあります。全国タクシーをご利用いただいているお客様の中にはこのような経験をされた方もいらっしゃると思います。
これらの原因は色々考えられるのですが、動態情報の「鮮度」も大きな要因のひとつです。特に「待ち時間が長い」理由は、動態のタイムラグがあるために本当に最適な車を見つけられないこともあるのが実情です。
このような課題を解決するべく、IoTグループでは動態の鮮度を向上させるためのシステムを開発していて、少しだけ紹介したいと思います。
動態情報の鮮度を上げるためには大きく2つの要素が必要です。
また、動態データは配車だけでなくデータ分析など他の目的でも利用される価値のあるデータです。したがって
も重要なポイントにあげました。
これらを意識しながら現在の課題と照らし合わせて設計・開発しています。
開発中の動態システムの構成は以下のような構成になっています。
AWSの複数のサービスを利用しています。この構成の中核とも言える部分が「Kinesis Data Streams(以下、Kinesis)」です。Kinesisはハイパフォーマンスなストリーミングサービスで、大量のデータを高速で入出力するのに適しています。さらにこのKinesisの個人的に一番嬉しいポイントは、「データを受信する部分と処理する部分を完全に分離できる」ところです。上の図で言うと、青枠(受信部)と赤枠(処理部)です。今でこそ結構当たり前な考え方かもしれないですが、オンプレ出身の私にとっては簡単にできすぎて結構な衝撃でした。もちろん、データの形式など考慮しないといけない部分はあるのですが、受信部と処理部を別々に開発できる点は非常に魅力的です。分離できるということは、あとから処理部を追加することもできます。上の図でいうと、Lambdaを新しく追加するだけで、他の処理を追加することができます。Kinesis自体が可用性の高いシステムなので、処理が追加されることによるパフォーマンス劣化もそれほど意識する必要がありません。(図では左から右へデータの流れとして矢印を書いていますが、実際はデータ処理部のLambdaがKinesisに対してデータを取りに行くイメージです。)
まずとりかかったのは受信部の開発です。動態を受信してKinesisに送信するサーバーを構築し、タクシー車内に取り付ける端末に動態情報を送信する機能の開発を行いました。端末とKinesisの間にサーバーを設けたのは、
ことが理由です。
端末とサーバーはWebソケットで常に接続されている状態にして、動態のタイムラグが可能な限り短くなるようにしました。
この端末はすでにいくつかのタクシー会社様にご利用いただいており、順調に稼働中です。
2の処理部分については目下開発中で、現在の処理部は従来の動態システムに連携するようになっています。
また、これらのサーバーやLambdaはパフォーマンス面も考慮してGo言語で開発しています。(以前はLambdaをPythonで開発していたのですが、Goに切り替えたことでコストパフォーマンスを劇的に上げることができました。)
他にも、お客様とタクシーのよりよいマッチングのための配車ロジックの改善や、お客様と乗務員さんが直接コミュニケーションを取れる仕組みの開発などに取り組んでいます。
JapanTaxiでは、ITの力で「移動で人を幸せに」できるサービスの開発に日々取り組んでいます。メンバーも積極的に募集しているので、興味のある方は一緒に仕事をしてみませんか?
Mobility Technologies では共に日本のモビリティを進化させていくエンジニアを募集しています。話を聞いてみたいという方は、是非 募集ページ からご相談ください!