NearMe Tech Blog

NearMeの技術ブログです

配車サービスのマルチテナント化について

f:id:nearme-jp:20210508115626p:plain

配車サービスを開発するにあたって、初めから取り入れようと思ったのがマルチテナント化です。 マルチテナント化とは、多くのSaaSサービスで見られるように、一つのアーキテクチャで複数の企業が個別にサービスを利用できるようにすることです。 結果としてこの機能は、配車固有の事情と相まって、事業展開に重要な役割を果たしてきました。 ここではその導入背景やアーキテクチャなどについて説明します。

背景

海外の配車サービスだと、個人のドライバーがユーザーの注文を直接受けるというのが多くあります。 一方、日本では、規制もあり、個人のドライバーというよりは、地域ごとのタクシー・ハイヤーの運行会社に所属しているドライバーが注文を受けるのが一般的です。

注文は、直接配車アプリに通達されることもあれば、運行会社を経由することもあります。 運行会社は、そこで配車可否確認やドライバーの指示をしたり、運行スケジュールを組んだりします。 個別に配車システムを持っている場合もあります。

各運行会社とどこまで密に連携するか、というところがマルチテナント化の判断ポイントです。 運行会社ごとに配車システムを提供できるようなマルチテナント化です。 連携を疎結合にして、個々のドライバーとユーザーとのマッチングに限定すれば必ずしもマルチテナント化は必要ありません。 しかし、事前予約含めた全体の運行スケジュールを考慮するといったマッチングの全体最適をするには、 マルチテナント化して内部に踏み込む必要があります。

結局、NearMeでは、事前予約型の空港送迎の相乗りサービスの検討において、 各運行会社と密に連携することでより深く最適化を行えると感じたのでマルチテナント化を採用しました。 ただし、既存の配車システムを丸々置き換えるつもりはなく、マッチングの最適化のための機能にフォーカスして開発しています。

アーキテクチャ

基本構造

マルチテナントの設計にあたって、参考にしようと思ったのはGithubです。 データ構造が汎用的で、権限まわりが簡潔で扱いやすいというのが理由です。

Githubでは、「リポジトリ」というリソースと、そのリソースに対して、「組織」、「メンバー」、「チーム」に基づいた権限管理が行われます。 個人利用と組織利用がありますが後者の場合は、ざっと説明すると次のようになります。

  • 1つのリポジトリは1つの組織に紐付く
  • 1つの組織は複数のリポジトリを持つ
  • 1人のメンバーは複数の組織に所属する
  • 1つの組織に複数のメンバーが所属する
  • 各メンバーはその組織のオーナーかそうでないかが選択できる
  • オーナーはその組織が持つリポジトリに対してあらゆる操作が行える
  • オーナーでないメンバーはチームによって権限を管理する
  • 1つのチームは1つの組織に紐付く
  • 1つの組織は複数のチームを持つ
  • 各チームには複数のメンバーが所属する
  • チーム単位で、どのリポジトリにどういった権限を付与する(読み取り専用など)

これを配車サービスに置き換えて考えてみると、リポジトリというのが、地域固有の配車サービスに対応できます。例えば、「羽田空港送迎」、「成田空港送迎」、「〇〇スクール送迎」などがそれぞれ個別のリポジトリに対応します。組織に対応するのが、各運行会社です。メンバーは運行オペレータになります。そして、各メンバーがどのサービスに対してどの役割があるかというのを、チームにて設定します。

このようなデータ構造が実際のフローでどのように関わっているかを見てみます。例えば、「羽田空港送迎」に注文が入ると、注文は「羽田空港送迎」というサービスに紐づきます。料金は「羽田空港送迎」のサービスの設定に基づいて決まります。対応エリアかどうかもそのサービスの設定に基づいて判断されます。その後、「羽田空港送迎」を所有する組織のメンバーが注文に対応します。ルート情報や運行スケジュールに基づいて配車可否を判断し、配車可能の場合、組織に登録されている車両を割り当てます。これらのオペレーションの権限はチームごとに与えられます。

f:id:nearme-jp:20210508232042p:plain

組織間連携

上記の基本構造で表現しきれないものとして、あるサービスで複数の運行会社が参加して注文を取るといった組織間連携が必要な機能があります。 ここで参考にしたのが、例えば、AWSのクロスアカウントでのリソース共有 のような仕組みです。 今回の場合、サービスごとに他組織に共有するという形で実現しました。 例えば、「羽田空港送迎」というサービスに入った注文を、そのサービスを所有する組織Aだけでなく、別の組織Bが取れるように、そのサービスにおいて組織Bを共有します。

f:id:nearme-jp:20210508233139p:plain

終わりに

現時点で、マルチテナント対応の基本的な配車システムはできてきました。 今後の展望として、組織間だけでなく個別のサービス間でも連携して、より緻密な運行の実現を探りたいと思っています。 また、Slackのようなイメージで、メンバー向けのリアルタイムな仕組みも取り入れていきたいです。 さらに、近い将来自動運転が当たり前になった世界でも通用できるように準備しておきたいところです。

最後になりますが、NearMeではエンジニアを募集しています! まだまだ多くの可能性が潜んでいる領域です。興味を持った方はぜひ応募いただければと思います。

Author: Kenji Hosoda

このエントリーをはてなブックマークに追加