はじめに 技術ブログのネタとして、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では、コンテナ・ポッド・ノードという階層的な構成要素があります。コンテナは単独のアプリケーションを動かす実行環境です。ポッドは、複数の密接に関連したコンテナをまとめたものです。コンテナはその