はじめに NearMeの相乗りサービスの特徴として、事前予約の注文が入るたびに相乗りの最適化を行っているという点があげられます。 これは、特定の時間で締め切りして一気に相乗りを決めるという素朴な方法に比べると、 相乗り状況が事前に把握できることで配車手配しやすくなったり、直前まで最適化できたりするといったメリットがあります（参考１、参考２）。 一方で、最適化の観点では、注文のたびに最適化しようとすると計算リソースが限られてしまうので、妥協した解に留まる可能性あります。 特に、現実装では計算量を減らすため、入ってきた注文に対して時間的・空間的に近しい注文同士で再計算していますが、 その場合、部分部分、瞬間瞬間で最適化できても、刻々と注文が入ってくる中で、その部分的な解が"陳腐化"していきます。 全体の注文数が限られている状況ではそれでも満足な解は得られていたのですが、注文数が増えるにつれて、
Introduction Infrastructure as Code (IaC) has revolutionized how organizations manage their cloud infrastructure, and at NearMe, our journey led us to choose Pulumi as our primary IaC tool. This article explores how Pulumi's unique approach to infrastructure management has transformed our Platform Engineering practices, enhanced developer productivity, and improved our infrastructure reliability.
これが俺の”自分戦略” プロセスを楽しんでいこう！ - Developers CAREER Boost 2024
1 SWAP*に興味をもった経緯 • VRPにおける近傍操作のアルゴリズムの⼀つ • いくつかのアクティブなVRPのライブラリで取り⼊れられている ◦ https://github.com/VROOM-Project/vroom ☆1.3k ◦ https://github.com/reinterpretcat/vrp ☆329 ◦ https://github.com/PyVRP/PyVRP ☆229 • ⽐較的最近提案されている ◦ 2020年にarxivで提案 ▪ https://arxiv.org/abs/2012.10384 ◦ 2022年にComputers & Operations Researchに掲載 ▪ https://www.sciencedirect.com/science/article/abs/pii/S030505482100349X • 計算時間が愚直な実装
Online-Dokumentation, die hilft: Strukturen, Prozesse, Tools
はじめに 先日、空港送迎のシェア乗りサービスの空席を埋めるための時刻表機能をリリースしました。 構想は昔からあったのですが、ようやく開発を進めて世に出すことができました。 ここではその機能概要やシステムについて説明します。 時刻表について NearMeではユーザー同士がタクシー/シャトルの車両をシェアして乗車するサービスを構築してきました（※同じシェアですが、昨今、ドライバー不足で議論されている"ライドシェア"は一般ドライバーと乗客のマッチングによるもので、それとは異なります）。 特に、空港送迎のような事前に予約するシナリオにおいて運行効率を高める機能を作ってきました。 ユーザー同士のマッチングを最適化したり(参考、参考)、 車両と運行のマッチングも最適化して密な運行セットを作ったりしました(参考)。 また、既にある運行の空席を埋める施策として、時間をずらしたら乗れるというレコメンド機能も
「Startup Day 2023」は日本中のAWSを利用するStartupが、AWSの知見を披露するHubとなる1日です。2023年はサブテーマに「スタートアップ冬の時代を共に乗り越える」を掲げて、スタートアップが面しているこの逆境をどうやって跳ね除け、成長につなげていけるかを共有します。ここで、株式会社NearMe（以下、ニアミー）の細田氏が登壇。まずは、ニアミーが提供しているサービスの仕組みについて話します。 ニアミーについて細田謙二氏：ニアミーの細田です。よろしくお願いします。今日は、「交通の最適化で強化学習を使い始めた話」というところで。強化学習というと、みなさんもそうだし私もそうなのですが、「ちょっと難しそう」「使い勝手が悪そう」みたいなイメージがあって。 実際にそういう部分はあるのですが、いろいろ調査をして、最新の技術などをいろいろキャッチアップすると、「案外ワンチャンありか
はじめに NearMeエンジニアの柿野上 拓真です。私は今年４月に新卒としてNearMeに入社いたしました。担当領域としては、主にデータサイエンスやMLOps、新規機能のPOCを担当しています。本記事では、私が設計・実装している自動配車システムの概要および今後の展望として深層強化学習の導入について解説します。 NearMeでは事前予約で注文を集めて、時間的・距離的に近い注文同士をAIによって自動的にマッチング（相乗り）させて乗車人数 / 移動距離を最大化しています。マッチングした注文の集合、あるいは、マッチングしなかった単独の注文をトリップと呼んでいます。車両へのアサイン（トリップに対して運行する車両を紐づけること）はトリップ単位で行います。自動配車システムでは、トリップを最適な車両にアサインし、効率的な運行計画を作成することを目標にしています。 本記事では、自動配車システムを理解して頂く
27 参考文献 Dmitry Kalashnikov, Alex Irpan, Peter Pastor, Julian Ibarz, Alexander Herzog, Eric Jang, Deirdre Quillen, Ethan Holly, Mrinal Kalakrishnan, Vincent Vanhoucke, et al. Qt-opt: Scalable deep rein-forcement learning for vision-based robotic manipulation. arXiv preprint arXiv:1806.10293, 2018. Barret Zoph and Quoc Le. Neural architecture search with reinforcement learning. In International Conf
はじめに 技術ブログのネタとして、JsonLogicを利用した柔軟なシステムカスタマイズについて考えてはいたのですが、もう一捻り欲しいなというところで、最近話題のChatGPTと組み合わせたらどうだろうと思い試してみたところ、思いのほかいい感じの結果が得られたので、タイトルを改めて書いてみました。 JsonLogicについて JsonLogicは汎用的なルールエンジンで、現在、NearMeのサービスにおいて複雑な料金計算等で利用しています。例えば、ユーザーに提示する料金は、需給のバランスを整えるために、時間帯や配車までの時間等で金額を調整することがあります。また、配車コストを算出するために、タクシー会社と契約する料金表があるのですが、これも、エリアや人数(大人、子供)、荷物の数、時間などの変数が複雑に絡んだものがあります。これらを計算するために、一つはハードコーディングして解決するという手
はじめに NearMeでは最近、相乗り配車サービスのための外部向けAPIプラットフォームを構築しました。 これにより、他アプリからシームレスに注文したり、Lineミニアプリのような新しいチャネルのUIを独自に構築することを可能にしました。 その設計においては様々な考慮が必要でしたので、ここにまとめたいと思います。 提供方法 APIを利用するにはまず、外部連携先の"組織"を作成し、登録した"組織"で「〇〇 地域シャトル」「〇〇スクール送迎」などの"サービス"を作成します。これにより、ユーザー管理、車両管理、注文管理などが管理画面から利用できるようになります。マルチテナント方式なので専用の"サービス"が構築されます。 次に、API連携に関する基本情報を格納する"アプリケーション"という項目を作成します。 認証情報やWebhookのURLなどもここで設定します。 この"アプリケーション"のIDが
はじめに 今回は、NearMeにおけるCIの仕組みについて説明します。 CIとは、Continuous Integration(継続的インテグレーション)の略で、 コード変更の度にビルドとテストを自動で実行するプラクティスを指します(参考)。 NearMeではCIを実現する方法として、Kubernetes(k8s)上に動作するArgoを利用しました。 k8sはコンテナ化されたアプリケーションを管理するためのオープンソースのシステムです。 Argoはk8s上でCIやCD(Continuous delivery)を実現するツール群です。 一般に、CI構築では外部サービスを利用することも多いですが、 他システムの障害や料金に依存せずCIを管理したかったのと、 既にk8sを中心にシステムを構築していたので、 多少の煩雑さはありつつも自前で構築しました。 システム構成 CIシステムはイベントの処理を
はじめに 配車サービスの注文処理はECサイトのそれと似ています。 ECサイトでは商品を検索し、カートに入れて、注文します。 このとき、在庫が確保できていれば注文できます。 もしくは、後から在庫確保または在庫切れの通知が届く場合もあります。 その後、配送手配が行われ、お届け日などが通知されます。 配車サービスでは、商品に対応するのが、出発地と目的地を結ぶ移動手段になります。 在庫確保の流れはドライバーの予定を押さえる形になります。 このとき配車確定まで時間がかかる場合もあります。 その後、配車手配が行われ、ピックアップ時刻などが通知されます。 今回は、NearMeの相乗りサービスにおける注文処理について説明します。 当サービスでは事前予約で注文を貯めつつ、注文が入る度に最適な相乗りの組み合わせを計算して配車確定を逐次的に行えるようにしています。 このような相乗りにおいてどのようなパタンが発生
はじめに NearMeでは相乗りシャトルのサービスを展開していますが、その配車ルーティングを実装してきて気づいた点があります。 クラウドの基盤技術である"コンテナオーケストレーション"と似た構造がある点です。 コンテナオーケストレーションは、コンピューティング環境で動くアプリケーションをコンテナと呼ばれる単位で管理し、コンピューティングリソースを適切に割り当て、協調的に動作させる技術です。 コンテナオーケストレーションを実現する代表的なツールとしてKubernetes(クーバネティス、以降k8sと略します)があり、ここでは特にk8sと配車ルーティングとのアナロジーについて考えてみます。 構成要素 k8sでは、コンテナ・ポッド・ノードという階層的な構成要素があります。コンテナは単独のアプリケーションを動かす実行環境です。ポッドは、複数の密接に関連したコンテナをまとめたものです。コンテナはその
はじめに 今回は、事前予約型の乗車サービスにおける乗車需要を時系列解析を用いて予測します。ポイントとなるのが、注文日時と乗車日時の間に数日間のラグがあることです。典型的には、過去の乗車実績の時系列の変動から未来のそれを予測します。事前予約型ではさらに、事前に注文された乗車予定のデータを加味することが効果的であると考えられます。ここでは、シミュレーションによって事前予約型の注文のトイデータを作成し、事前予約を加味した時系列モデルを構築し検証します。また、同じモデルで実際のデータでの検証結果の概要も示します。 時系列解析を行うにあたっては、DartsというPythonのライブラリを利用しました。統計的手法や機械学習含め多数の時系列解析の予測モデルが備え付きで利用できます。そして、時系列データに対する様々な操作、モデルの構築・検証などが、統一的なAPIを通して利用できます（参考１、参考２）。コー
今回はRustという注目のプログラミング言語を用いて、OpenStreetMapというオープンな地理情報データを触ってみます。 背景 Rustに注目した背景としては、大規模かつ複雑な交通データに対して解像度をもっと上げた課題解決が必要になってきたからです。NearMeのシステムは現状、メインはTypeScriptで書いていて、最適化アルゴリズムに関連する部分をPythonで書いています。スタートアップとして、初動としてはこの構成でよかったと思いますが、更なるチューニングを求めて検討したのがRustです。 Rustの特徴としては、C/C++並の高速な処理速度、安全で効率的なメモリ管理、生産性を高める様々な機能があげられます。Pythonでも、定型の低レイヤーの処理をC/C++で行わせて、高レイヤーの処理をPythonで書くという形で、パフォーマンスと生産性を両立させることができますが、課題に
NearMeの相乗りシャトルは、タクシーとバスの中間となる第三の選択肢としての交通手段を提供します。 タクシーはユーザーの利便性は高いですが、少人数しか運べないので配車効率は低く、料金は高いです。 一方、バスはその逆です。 今回は、相乗りシャトルで用いる主なパラメタについて説明し、一方の極限ではタクシーに、もう一方ではバスに還元できること、そして、それらを"なめらかに"繋げることができることを示したいと思います。 許容迂回係数 許容迂回係数は、単独の場合の乗車時間の何倍まで、相乗りによって迂回して乗車時間が伸びることを許せるかという値です。 例えば、東京駅→羽田空港の注文があり、単独で行く場合30分かかるとします。 ここで、許容迂回係数が1.5とすると、30分x1.5で45分まで迂回が許されます。 このとき、六本木→羽田空港の注文と相乗りすると、東京駅→六本木→羽田空港というルートになり、
配車のルーティングにおいて、最適化のアルゴリズムはコアとなる機能ですが、 これに相対して開発する必要があるのが、データベースを絡めた永続的な状態管理です。 事前予約型の空港送迎の相乗りサービスでは、注文が入る度に逐次的にルーティングを行なっていて、注文全体で時系列に変化する"ルーティングの状態"があります。 ここではその状態管理についてアーキテクチャを交えて解説します。 サービス構成 NearMeで構築している配車ルーティングは次の二つのサービスに分かれて処理されています。 一つは、ルーティングサービスで、最適化のアルゴリズムを提供します。データベースとは直接はやり取りせず、永続的な状態を持たずに、入力を受け取って出力を返します。ただし、地点間の最短経路の移動時間を取得するために地図サービスとは連携しています。 もう一つは乗車サービスです。これはデータベースとやり取りして、乗車の諸々の状態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
