食品配達アプリのためのリアルタイムドライバー追跡システムの設計

ハイレベルデザイン 3つの主要なパス（ドライバーの取り込み、リアルタイムのファンアウト、クエリ/ストレージ）を備えたイベント駆動型のリアルタイム追跡プラットフォームを構築します。ドライバーはGPSの更新を継続的に公開します。バックエンドはそれらを検証および強化し、ドライバーの最新の位置を更新し、ドライバーをアクティブな配信注文にマッピングし、その注文を追跡している顧客にのみ更新をプッシュします。 1.ドライバーのモバイルからバックエンドへ 各ドライバーアプリは軽量のロケーションパブリッシャーを実行します。 - GPS座標を数秒ごと（アクティブな配信中は約2〜5秒ごと、アイドル時はそれ以下）に収集します。 - driver_id、現在のorder_id（割り当てられている場合）、緯度、経度、速度、進行方向、タイムスタンプ、アプリのバージョン、バッテリー/ネットワークのヒント、シーケンス番号を含めます。 - クライアント側のスロットリングと移動ベースのフィルタリングを適用して、アプリが変更されていない位置の送信を回避するようにします。 - 接続不良時には更新をバッチ処理または集約し、再接続時に最新のものを最初に送信します。 ドライバーからバックエンドへの推奨プロトコル： - HTTPSによる定期的な位置情報のアップロードは、最もシンプルで堅牢な選択肢です。 - Location Ingest APIへの小さなPOSTリクエストを使用します。 - 非常に高い効率のため、モバイルサポートと運用成熟度が利用可能な場合は、gRPCストリーミングも強力なオプションです。 実践的な選択： - HTTPSから開始します。これはモバイルネットワーク、プロキシ、既存のAPIゲートウェイでうまく機能するためです。 - 圧縮、コンパクトなペイロード、適応的な送信頻度、リージョナルエッジエンドポイントで最適化します。 取り込みフロー： - ドライバーアプリ - APIゲートウェイまたはロードバランサー - 認証とレート制限 - Location Ingest Service - 非同期処理のためのメッセージブローカー 2.バックエンドサービス コアサービス - APIゲートウェイ：TLSを終端し、ドライバーと顧客を認証し、レート制限を適用します。 - Location Ingest Service：ペイロードを検証し、古いまたは重複した更新をドロップし、イベントにタイムスタンプを付け、ブローカーに発行します。 - Message Broker：Kafka、Pulsar、またはKinesis（耐久性の高い高スループットイベントストリーミング用）。 - Driver State Service：位置イベントを消費し、RedisやDynamoDBのような高速ストアで最新のドライバー状態を維持します。 - Order Tracking Service：driver_idをアクティブなorder_idと顧客のサブスクリプションチャネルにマッピングします。 - Realtime Fanout Service：正しい顧客接続に位置更新をプッシュします。 - Order Service：注文のライフサイクル、割り当て、ステータスの変更、レストランでの受け取り、配達完了のソースオブトゥルース。 - ETA Service：最新の交通状況を考慮したルートとドライバーの動きを使用して、オプションでETAを再計算します。 - Historical Storage Service：デバッグ、分析、紛争解決、MLのために位置履歴を保存します。 - Monitoring and Alerting：レイテンシ、ドロップしたメッセージ、古いドライバーの位置、リージョナル障害を追跡します。 処理パイプライン - ドライバーが位置更新を送信します。 - Ingest serviceが認証、スキーマ、タイムスタンプの鮮度、および妥当性を検証します。 - イベントがブローカーに書き込まれます。 - Driver Stateコンシューマーがdriver_idをキーとする最新の位置キャッシュを更新します。 - Order Trackingコンシューマーが、ドライバーが現在アクティブな注文に割り当てられているかどうかを確認します。 - 該当する場合、顧客スコープの追跡イベントを発行します。 - Realtime Fanoutがサブスクライブしている顧客アプリに更新を送信します。 - Historicalコンシューマーがイベントを長期ストレージに保存します。 3.リアルタイム更新を受信する顧客モバイル 推奨パターン： - 顧客アプリは、注文追跡画面に入った後、WebSocket接続を開きます。 - アプリは認証され、order_idのような単一の注文追跡チャネルにサブスクライブします。 - バックエンドは、顧客がその注文を表示する権限があることを検証します。 - Fanout serviceはその注文の更新のみを送信します。 - 初回接続時、アプリはスナップショット（最新のドライバー位置、注文ステータス、ETA、最終更新時間）を受信します。 - その後、ほぼリアルタイムで増分更新を受信します。 フォールバック： - WebSocketがブロックされたり不安定な場合は、Server-Sent Eventsまたはショートポーリングをフォールバックとして使用します。 - バックグラウンドのアプリでは、継続的な追跡ではなく、主要なマイルストーンに対してのみプッシュ通知を使用します。 4.プロトコルの選択と正当化 ドライバーからバックエンドへ：HTTPS POST - モバイルネットワークでの強力な互換性。 - リトライ、認証、オブザーバビリティ、ゲートウェイ統合が容易。 - 更新が適切にスロットリングされていれば、50,000アクティブドライバーで十分です。 - MQTTよりも運用上の複雑さが少ない。 顧客からバックエンドへ：WebSockets - サーバーからクライアントへのリアルタイム更新に最適。 - 200,000人の顧客からの無駄なポーリングを回避します。 - 低レイテンシで、多数の小さなプッシュメッセージに効率的。 - 顧客は通常1つの注文を追跡するため、サブスクリプションロジックはシンプルです。 ブローカー内部通信：Kafkaまたは類似のもの - 取り込みとファンアウトおよびストレージを分離します。 - スパイク、リプレイ、複数のダウンストリームコンシューマーを処理します。 - 水平スケーリングのためにパーティションをサポートします。 顧客のポーリングが推奨されない理由： - 200,000人のアクティブな顧客がいる場合、頻繁なポーリングは、位置が変わっていない場合でも、大量の不要なQPSを発生させます。 - レイテンシが高く、バッテリー/ネットワーク効率が低下します。 MQTTのエンドツーエンドが推奨されない理由： - モバイルテレメトリには技術的に適していますが、クライアントとブローカーの複雑さが増し、組織がすでにMQTTを大規模に運用している場合を除き、不要な場合があります。 - このユースケースでは、HTTPSとWebSocketsの方がシンプルで、通常は十分です。 5.データモデル A.ドライバーの最新位置 目的：リアルタイム読み取りのためのホットステート フィールド： - driver_id - lat - lng - geohashまたは空間インデックスキー - speed - heading - accuracy_meters - recorded_at（デバイスから） - received_at（サーバーから） - sequence_number - active_order_id（nullable） - status（idle、heading_to_restaurant、waiting、delivering、offlineなど） ストア： - 超高速な最新ステート読み取りとpub/subメタデータのためのRedis、または耐久性のあるスケーラブルなキーバリューストアのためのDynamoDB/Cassandra。 - TTLは古いエントリに適用できます。 キー例： - driver_idをパーティションキーとして使用 B.ドライバーの位置履歴 目的：分析とリプレイ フィールド： - driver_id - timestamp - lat - lng - speed - heading - active_order_id ストア： - 時系列に適したストレージ、ストリームシンク経由のオブジェクトストレージ、またはワイドカラムデータベース。 - 生のポイントには短い保持期間、要約されたトレースには長い保持期間を設定できます。 C.注文追跡モデル フィールド： - order_id - customer_id - driver_id - restaurant_id - status（placed、preparing、driver_assigned、picked_up、en_route、delivered、cancelledなど） - pickup_location - dropoff_location - latest_driver_lat - latest_driver_lng - latest_driver_timestamp - eta_seconds - tracking_visibility（boolean） - assigned_at、picked_up_at、delivered_at ストア： - リレーショナルDBまたは分散トランザクションストアでのプライマリ注文レコード。 - 低レイテンシ読み取りのためにRedisまたはDynamoDBでの頻繁に変更される追跡プロジェクション。 D.サブスクリプション/セッションモデル フィールド： - connection_id - customer_id - order_id - connected_at - last_heartbeat_at - region ストア： - Redisのようなインメモリストア、またはマネージドWebSocketゲートウェイ接続レジストリ。 6.ピークロードのスケーリング戦略 トラフィック推定 50,000人のアクティブドライバーが平均5秒ごとに更新を送信する場合： - ピーク時には約10,000の位置更新/秒。 アクティブな配信のバースト中に2秒ごとに更新する場合： - 約25,000更新/秒。 これは、パーティション化されたイベント駆動型システムの範囲内に十分に収まります。 スケーリングアプローチ A.ステートレス水平スケーリング - ロードバランサーの後ろでAPIゲートウェイ、Ingest Service、Fanout Serviceを水平にスケーリングします。 - リクエスト処理はステートレスに保ちます。セッションとサブスクリプションのメタデータは共有高速ストレージに保存します。 B.パーティション化されたイベントストリーミング - driver_idで位置イベントをパーティション化し、ドライバーごとの順序を保持します。 - パーティションとコンシューマーインスタンスを追加してコンシューマーをスケーリングします。 - ドライバーの状態、顧客のファンアウト、ETA、ストレージのために別々のコンシューマーグループを使用します。 C.高速ホットステートストレージ - 最新の位置と注文追跡プロジェクションにはRedisクラスターなどを使用します。 - キャッシュには現在の状態のみを保持します。ソースオブトゥルースと履歴には耐久性のあるシステムを使用します。 - 古いドライバーにはTTLとエビクションを使用します。 D.リージョンベースのデプロイメント - 複数の地理的リージョンにデプロイします。 - レイテンシを削減するために、ドライバーを最寄りのリージョンにルーティングします。 - 可能な場合は、注文と同じリージョンに顧客追跡を維持します。 - グローバルなすべての生イベントではなく、必要なメタデータに対してのみリージョン間レプリケーションを使用します。 E.バックプレッシャーと劣化 - システムが過負荷になった場合、更新を統合し、短い時間ウィンドウあたり最新のドライバー位置のみを発行します。 - 移動の遅いまたは停止しているドライバーの更新頻度を動的に減らします。 - アイドルドライバーのテレメトリよりも、アクティブに追跡されている注文を優先します。 - パイプラインで明らかに古い、置き換えられたイベントをドロップします。 F.効率的なファンアウト - 広範な地理的サブスクリプションではなく、注文に関連付けられた顧客にのみプッシュします。 - デルタまたはコンパクトなペイロードを送信します。 - バックエンドがより頻繁に受信しても、顧客アプリで視覚的に有用な、例えば最大1〜2秒の更新頻度に制限します。 G.信頼性 - ブローカーで少なくとも1回の配信を使用し、冪等なコンシューマーを使用します。 - driver_idとシーケンス番号またはタイムスタンプで重複排除します。 - ハートビートで切断された顧客とオフラインのドライバーを検出します。 - 再接続した顧客がすぐに回復できるように、最後に知られているスナップショットを永続化します。 H.オブザーバビリティ 追跡するもの： - ingest QPS - ドライバー送信から顧客受信までのエンドツーエンドレイテンシ - 古い位置の割合 - websocket接続数 - ファンアウトの失敗と再接続 - リージョンごとのブローカーラグ - キャッシュヒット率 推奨されるエンドツーエンドアーキテクチャ - ドライバーアプリはHTTPSの位置更新を送信します。 - グローバルロードバランサーが最寄りのリージョンにルーティングします。 - APIゲートウェイが認証とレート制限を行います。 - Location Ingest Serviceが検証し、Kafkaに発行します。 - Driver State ServiceがRedisまたはDynamoDBで最新の位置を更新します。 - Order Tracking Serviceがアクティブな注文割り当てと結合し、追跡ペイロードを計算します。 - Realtime Fanout ServiceがWebSocket経由でサブスクライブしている顧客に送信します。 - Order Serviceがライフサイクル遷移を管理します。 - Historical sinkが長期ストレージに生イベントを保存します。 - ETA Serviceが顧客アプリに表示されるETAを定期的に更新します。 主要な設計上の決定の要約 - 堅牢なモバイル取り込みのために、ドライバーからはHTTPSを使用します。 - 低レイテンシのターゲットプッシュのために、顧客からはWebSocketsを使用します。 - 取り込み、状態更新、ファンアウト、ストレージを分離するためにブローカーを使用します。 - 最新の状態は高速キーバリューストアに、履歴トレースは個別に保存します。 - パーティショニング、リージョン化、キャッシング、適応的スロットリングで水平にスケーリングします。 この設計は、低レイテンシ、ターゲットを絞ったリアルタイム更新、運用上のシンプルさを提供し、ピーク需要時に数万人のドライバーと数十万人の追跡顧客をサポートするのに十分なヘッドルームを備えています。

# リアルタイムドライバー追跡システムアーキテクチャ ## 1. ドライバー位置データ収集 ドライバーのモバイルデバイスは、定期的な間隔（アクティブな配送中は5〜10秒ごと）で位置情報を送信します。モバイルSDKは以下の処理を行います。 - タイムスタンプと精度メトリクスとともにGPS座標をキャプチャする - ネットワークの中断に対処するため、更新情報をローカルにバッファリングする - HTTPS POSTリクエスト経由で、バッチ処理された位置データを専用のLocation Ingestion APIに送信する - 失敗したリクエストに対して指数バックオフを実装する - ドライバーが静止している場合は、帯域幅を節約するために頻度を減らす ## 2. バックエンドサービスアーキテクチャ **Location Ingestion Service:** - ドライバーからの位置情報の更新を受信する - データを検証し、基本的なフィルタリングを実行する - メッセージキュー（Kafka/RabbitMQ）にイベントを発行する - モバイルクライアントに応答を返す - ロードバランサーによる水平スケーリング **Location Processing Service:** - メッセージキューから位置イベントを消費する - キャッシュ（Redis）でドライバーの位置を更新する - 時系列データベース（InfluxDB/TimescaleDB）に位置履歴を保存する - ETAとルート最適化を計算する - 通知サービスに位置情報の更新を発行する **Order Service:** - 注文の状態とドライバーの割り当てを管理する - キャッシュから現在のドライバーの位置を照会する - 注文ライフサイクルイベントを追跡する **Notification Service:** - 位置情報更新イベントを購読する - どの顧客が更新を必要とするかを判断する（アクティブな注文に基づく） - WebSocketまたはプッシュ通知経由で顧客に更新をプッシュする ## 3. 顧客位置情報更新の配信 顧客は以下の方法でリアルタイム更新を受信します。 - **WebSocket接続:** アクティブな追跡のための永続的な双方向接続 - **フォールバックメカニズム:** WebSocketを維持できないクライアント向けのHTTPロングポーリング - **プッシュ通知:** バックグラウンド追跡のための定期的な更新（30〜60秒ごと） 顧客が追跡を開いた場合： 1. モバイルアプリがLocation Streaming ServiceへのWebSocket接続を確立する 2. クライアントが注文IDを送信し、ドライバーの位置ストリームを購読する 3. サーバーが顧客と注文の関係を検証する 4. サーバーが割り当てられたドライバーの位置情報の更新をストリーミングする 5. 位置が大幅に変更された場合（ジオフェンシング）のみ更新を送信する ## 4. 通信プロトコル選定 **プライマリ：WebSocket** - 根拠：永続的な接続により、最小限の遅延（100〜500ms）で真のリアルタイム更新が可能になる - 双方向通信により、顧客はオンデマンドで更新をリクエストできる - ポーリングと比較してサーバー負荷を削減する - 高頻度の更新に効率的 **セカンダリ：MQTT（ドライバーからバックエンドへ）** - モバイルデバイスに最適化された軽量プロトコル - 組み込みのQoSレベルが配信の信頼性を保証する - 自動再接続処理 - ドライバーデバイスのバッテリー消費を削減する **フォールバック：HTTPロングポーリング** - WebSocketの制限があるクライアント向け - サーバーは新しいデータが利用可能になるまでリクエストを保持する - リソース枯渇を防ぐため、30秒後にタイムアウトする ## 5. データモデル **ドライバー位置（キャッシュ - Redis）:** ``` Key: driver:{driver_id} Value: { driver_id: string, latitude: float, longitude: float, timestamp: unix_timestamp, accuracy: float, speed: float, heading: float, active_order_id: string } TTL: 5 minutes ``` **位置履歴（時系列DB）:** ``` Table: driver_locations Columns: - driver_id (indexed) - latitude - longitude - timestamp (indexed) - accuracy - order_id (indexed) Retention: 90 days ``` **注文情報（プライマリDB - PostgreSQL）:** ``` Table: orders Columns: - order_id (primary key) - customer_id (indexed) - driver_id (indexed) - restaurant_id - status (enum: pending, confirmed, picked_up, in_transit, delivered) - pickup_location (lat, lng) - delivery_location (lat, lng) - created_at - estimated_delivery_time - actual_delivery_time ``` **アクティブな購読（キャッシュ - Redis）:** ``` Key: subscriptions:{order_id} Value: Set of {customer_connection_id} TTL: Order completion + 1 hour ``` ## 6. スケーリング戦略 **水平スケーリング:** - Location Ingestion: ロードバランサーの後ろに複数のインスタンスをデプロイする（目標：p99レイテンシ < 100ms） - Location Processing: パーティションあたりドライバーの戦略を持つKafkaコンシューマーグループ - WebSocketサーバー：Redisを使用したステッキセッション（接続状態用） - データベース：位置情報のクエリ用にリードレプリカ、プライマリに書き込み **キャッシング戦略:** - ドライバー位置用のRedisクラスター（インメモリ、<10msアクセス） - キャッシュウォーミング：サービス起動時にアクティブなドライバー位置情報をプリロードする - 近接クエリ用のRedisにおけるジオスペーシャルインデックス **データベース最適化:** - 位置履歴用の時系列データベース（時間範囲クエリに最適化） - 位置履歴テーブルの日付ごとのパーティショニング - （driver_id, timestamp）および（order_id, timestamp）のインデックス - 90日後に古いデータをコールドストレージにアーカイブする **メッセージキューチューニング:** - 位置イベント用の100以上のパーティションを持つKafka - サービスタイプごとのコンシューマーグループ - バッチ処理：1000メッセージまたは5秒ウィンドウ **ピーク負荷処理（ドライバー5万人、顧客20万人）:** - 予想される位置情報更新：50,000ドライバー × 1更新/10秒 = 5,000更新/秒 - 予想されるWebSocket接続：20万人（アクティブ追跡が30%と仮定 = 6万人同時接続） - 取り込み能力：インスタンスあたり10,000+更新/秒（3〜5インスタンス） - WebSocketサーバー：60,000接続 ÷ 10,000/サーバー = 6〜8サーバー - メッセージキューのスループット：10,000+メッセージ/秒 **監視とアラート:** - 位置情報更新のp50、p95、p99レイテンシを追跡する - キューの深さとコンシューマーラグを監視する - WebSocket接続障害のアラート - データベースクエリパフォーマンスの追跡 - カスケード障害防止のためのサーキットブレーカーを実装する **コスト最適化:** - 静的アセットにCDNを使用する - ドライバーの速度に基づいた位置情報更新のスロットリングを実装する - 転送中の位置データを圧縮する - オフピーク時の非クリティカルサービスにスポットインスタンスを使用する