Amazon Web Services ブログ

ラストマイルを実現：AWSによる革新的な即時配送ソリューション

はじめに

配送プロセスの最後の段階を「ラストマイル」と呼ぶのは、サプライチェーンや物流業界では一般的であり、宅配業者が担当します。ラストマイルの配送としては、例えば準備ができた食品をできるだけ速やかに配送する必要がある「即時配送」があり、他にもECサイトで購入した商品の「当日配送」や「多日配送」も含まれます。

ラストマイルは、配送の中で最も複雑でコストのかかる部分です。宅配業者は、ビジネス、物流、技術的な多数の複雑な問題を同時に解決する必要があります。

  • 対応可能なドライバーの位置を監視する。
  • ルートと車両の空きスペースに基づいて、ドライバーに最適な配車を割り当てる。
  • ドライバーの移動距離を最小限に抑えることで、コストを抑える。
  • 顧客の待ち時間をできるだけ短くする。
  • その他の特定のビジネスルールを遵守する。

COVID-19パンデミックの世界的な流行は、消費者の行動を大きく変えました。オンラインショッピングの需要が急増し、食品や日用品の宅配サービスも大幅に伸びています。アナリストはこの傾向が続くと予測しています。（ただし、流行が収束した後は、少しずつ店舗での買い物に回帰する人も出てくるでしょう。）

配送業務やラストマイル物流サービスの開始を計画しているお客様からのよくある質問に対応するため、AWS ASEAN (東南アジア諸国連合) のプロトタイピングチームはオープンソースのコンテンツを公開しました。これにより、企業は簡単に独自のラストマイル機能を構築できると同時に、即時配送と当日配送といったニーズに対応できます。IoT、サーバーレス、機械学習、地理空間技術を活用するとともに、イベント駆動型アーキテクチャも採用しています。

これはブログシリーズの第1部です。ここでは即時配送に焦点を当て、この新機能の詳細や仕組み、既存の環境への統合方法について説明しています。第2部では当日配送について説明する予定です。

機能的アーキテクチャ

AWS 即時配送機能は、大まかに言うと、以下の機能的アーキテクチャ図 (図 1) に示すように 2 つの主要部分で構成されています。

  • 位置の追跡。このモジュールにより、数万人のドライバーの現在地をほぼリアルタイムで追跡し、検索することができます。単純な位置検索や、より複雑な区域内のドライバー検索が可能です。設計上の重要なポイントは、ドライバーの位置特定までのレイテンシと、システムが同時に追跡できるドライバー数のスループットの2点です。
  • 注文の発送。このモジュールは、ドライバーに効率的に注文を割り当てるために使用されます。即時配送と当日配送の2つのサブモジュールがあり、まず即時配送についてこの記事で紹介します。配送事業は運用コストが高く、特に配送車両の管理が主な費用となります。そのため、注文とドライバーを適切にマッチングするシステムは、収益性と事業の持続可能性に大きな影響を与えます。このソリューションでは事前に定義された最適化手法を利用していますが、これらは会社のデータやビジネス要件に応じて容易に変更可能です。

図1.機能的アーキテクチャ

高度な技術アーキテクチャ

図2.高度な技術アーキテクチャ

図2 に示すアーキテクチャは、イベント駆動型のサーバーレスシステムを示しています。イベントバスとしてAmazon EventBridgeを活用しており、お客様のアプリケーションやソフトウェア、AWSサービスから発生したイベントを取り込んで大規模なイベント駆動型アプリケーションを構築できるようになっています。このコンポーネントがシステムの中核を担っており、すべての注文とステータス更新をシステムが処理します。また、ビジネスルールに基づいて特定のエンドポイントへメッセージを転送することも可能です。

システムのコアモジュールは2つです。

  • 位置の追跡
  • 注文の発送

位置追跡サービス

このサービスは、位置情報が中心的な役割を果たすすべてのタスクを管理するのに役立ちます。

  • ドライバーの位置をGPSで追跡
  • 位置情報の検索
  • ジオフェンシング

AWS IoT Coreサービスを高速メッセージブローカーとして利用し、ドライバーアプリと顧客アプリの間でメッセージを安全に送受信できます。MQTTプロトコルをサポートしており、MQTTプロトコルはHTTPと比較して同じ量の情報を少ないデータ量で送信できます。このユースケースでは、ドライバーアプリが位置データをAWS IoT Coreに継続的に送信し、そのデータパケットをリアルタイムストリーミングデータ収集・処理・分析サービスのAmazon Kinesisに転送します。そこから位置追跡サービスにインデックス化されます。データは、基本的な取り込みを使用して取り込まれます。基本的な取り込みは、AWS IoTルールに従ってデバイスデータを対象サービスに安全に送信でき、メッセージングコストが発生しません。

位置追跡サービスは、Redis 互換の高速・耐久性のインメモリデータベースであるAmazon MemoryDB for Redisと、OpenSearchのクラスターをAWS上で簡単にデプロイ・運用・スケーリングできるAmazon OpenSearch Service を組み合わせたものです。前者は「半径或いは矩形内の全ドライバーを追跡する」ようなシンプルなクエリを、後者は「ポリゴン内の全ドライバーを追跡する」ような複雑なクエリをそれぞれサポートしています。

ドライバーアプリは、AWS IoT Coreを通じて Amazon Eventbridge とステータス更新を送受信しています。一方で、Amazon API Gateway は、さまざまな規模でのAPIの作成、保守、保護に役立つとともに、Amazon MemoryDB for Redisおよび位置追跡サービスのOpenSearchクラスタから位置情報を問い合わせるためのAPIを提供しています。

ジオフェンシング

ドライバーに注文が割り当てられると、注文管理システムがEventBridgeにメッセージを送信します。位置追跡サービスがそのメッセージを受信し、割り当てられたドライバーの位置を追跡し始めます。MemoryDB for Redisを利用した位置情報制御により、ドライバーが目的地の近くに来た時点でEventBridgeに通知が送信されます。その情報は顧客や関連会社に共有されます。

図3.ジオフェンシングアーキテクチャ

その他の考慮事項

ドライバーを継続的に追跡すると、モバイルバッテリーが急速に消耗する可能性があります。ただし、ドライバーを頻繁に追跡しないと、ドライバーがどのルートをたどったのか、特定の瞬間にどこにいるのかを正確に知ることが難しくなります。また、割り当てエラーにつながる可能性もあります。たとえば、ドライバーが特定のピックアップポイントの近くにいて、ロケーションが更新されていないためにそのピックアップポイントから注文を受け取れない場合などです。

ドライバーの位置を常に追跡すると、モバイルバッテリーの消耗が速くなる可能性があります。 しかし、頻繁に追跡しないと、ドライバーが実際にどのルートを通ったのか、ある瞬間にどこにいたのかを正確に把握することが難しくなります。 また、注文の割り当てミスにもつながりかねません。例えば、ドライバーが特定の地点の近くにいるにも関わらず、位置情報が更新されていないために、その地点からを注文を受け取れないといったケースです。

このシステムは、ドライバーの位置を見失うことなく、バッテリーの消費を抑えるため、次の2つの方法を採用しています。

  • アクティブモードとパッシブモードで、ドライバーの位置を追跡するために使用する周波数を変更しています。これらのモードはさまざまな周波数をオンにしてGPS位置情報を取得し、データをクラウドに送信しています。
  • 位置情報の取得の頻度とクラウドへの送信頻度を分けています。GPS位置情報の取得頻度は上げていますが、クラウドへの送信頻度は下げています。

これらのアプローチは設定を変更することができます。ユーザーがアプリをデバイス上で起動した際、最新の構成が取得されます。既にアプリを実行しているデバイスで設定を変更した場合、ほぼリアルタイムでその変更が適用されます。

この図は、システムのフローを示しています。このシステムを使うと、アプリケーションに他の設定をプッシュすることもできます(例:A/Bテストを行う)。

図4.グローバルモバイルアプリ設定

注文管理： ルールエンジンと注文配分

注文管理モジュールは、ドライバーや配送場所、利用可能な時間帯、業務ルールなど、さまざまな制約を考慮しつつ、注文を一元管理してドライバーへ配送依頼を行うのに役立ちます。このモジュールは以下の2つのコア要素から構成されています。

  • 注文オーケストレーターと、地域ごとに業務ルールを適用するためのプロバイダールールエンジン
  • 配送プロバイダー

注文オーケストレーターとプロバイダールールエンジン

企業がラストマイル配送を含むビジネスを立ち上げる際、自社配送車両を構築するか、APIを利用してサードパーティの配送車両(複数可)を利用するかを選択できます。このシステムにより、注文を国内外の配送車両に分散させ、地域ごとに配分比率を設定できます。例えば、エリアA1では1社の配送業者(外部プロバイダーPr1)のみを利用する場合がありますが、エリアA2では、外部プロバイダーPr2とPr3の間で注文を分散する場合があります。この配分は、プロバイダールールエンジンを利用して実施されます。

このプロトタイプは、外部プロバイダーが使える様々な実装に対応できるよう、Webhook プロバイダーとポーリングプロバイダーの2つの通信技術をサポートしています。

プロバイダールールエンジン

プロバイダルールエンジンの実装は、ほとんどの利用シーンではシンプルですが、システムは拡張性と設定のしやすさを考慮して設計されています。 本番運用移行時には、お客様は独自の業務ルールを実装し、特定の分野でどのプロバイダーを選択するかを決定する必要があります。 追加の業務ルールへの対応や、新しい優先順位の定義、新しいオペレータを追加するなど、システムをカスタマイズすることができます。

図5.プロバイダールールエンジンによって選択される複数のプロバイダー (内部プロバイダーと外部プロバイダー) の例

人口地域

都市や町の特定の地域には、配送業者に関する独自のルールが設定されている場合があります。 例えば、「A1地域」と指定されたエリア内では、配送にその地域専属の配送車両しか利用できないことになっています。 一方で、「A2地域」と呼ばれる別の地域では、2社の外部プロバイダー間で注文を配分できるというルールになっています。

人口地域のリストは、フルマネージド型のサーバーレス key-value NoSQLデータベースであるAmazon DynamoDBに保存され、プロバイダールールエンジンの設定は、それぞれの人口地域を示す同じテーブルに保存されます。レストランや食料品店などの店舗を登録するたびに、その場所がどの人口地域に属するかを示すタグが付与されます。

図6.地域ごとに異なるルール（例：地域ごとに異なる外部プロバイダー）

配送システム

即時配送システムについて詳しく見てみましょう。

図7.即時配送プロバイダー

このモジュールは、次の3つのプロセスを管理しています。

  • まず、注文処理用のリクエストハンドラーが注文を受け取り、各注文にステータスを割り当てます。
  • 次に、ジオクラスタリングマネージャーが注文をグループ化し、位置関係に基づいてクラスターを形成します。
  • 最後に、発送オーケストレーターは発送エンジンを起動してこれらのクラスタを分析し、事業者の定める制約を考慮してドライバーへの注文割り当てを決定します。

ジオクラスタリング

デフォルト設定では、即時配送プロバイダーは他のプロバイダーと同じインターフェースを公開しています。注文オーケストレーターサービスは、Amazon API Gatewayのエンドポイントに対してHTTPリクエストを送信することで、これらのプロバイダーを呼び出します。プロバイダーはAmazon Kinesisを使用して注文をバッチ処理することができ、これにより一括で処理することが可能です。グループのサイズはビジネスニーズに応じて設定できます。ただし、グループサイズを大きくすると、クラスターが大きくなり、最適なソリューションの生成に時間がかかる可能性がある点に注意が必要です。

グループからの注文を処理する前に、ジオクラスタリングマネージャーは事前最適化の手順を実行します。このコンポーネントは、分散アプリケーションのビジュアルワークフローである AWS Step Functions を使用して実装され、ピックアップ地点が近い注文をクラスター化します。これにより、発送エンジンが利用可能な運転手を探す複雑な検索を行う必要がなくなるため、発送が最適かつスピーディーに行われるようになります。

発送オーケストレーターは、AWS Step Functionsを使用して実装されています。 ジオクラスタリングマネージャーによって作成されたすべてのジオクラスターに対して、発送オーケストレーターが実行されます。 発送オーケストレーターは、クラスターごとに配車を最適化し(コストを最小限に抑える)配車エンジンを起動します。ドライバーが選ばれると、発送オーケストレーターはAWS IoT Coreを通じてメッセージでドライバーに通知します。 ドライバーは配車を承諾または拒否できます。ドライバーが配車を拒否した場合、その配車はKinesisを使用してバッチに戻されます。 配車の状況は注文状況ストアで管理されています。

図8.ジオクラスタリングの例 (ソース：GraphHopper)

発送エンジンによる制約解決

発送エンジンは、即日配送や当日配送などの配送ドメインに関連する最適化問題を解決するために使用されるカスタムアプリケーションです。プロトタイプでは、オープンソースのAIベースの最適化ソルバー「OptaPlanner」を利用して、こうした配送ドメインをモデル化し実装しています。技術的な詳細についてさらに学びたい場合は、関連するブログとドキュメントを参考にすることをお勧めします。

制約の解決には、様々なレベルの制約(ハード、ミディアム、ソフトなど)と、最大化するスコア関数や最小化するコスト関数を定義できます。OptaPlanner ドキュメントには、問題領域を適切にモデル化するために必要な全ての情報が記載されています。ドライバーを注文に割り当てる方法はたくさんあります。ソフトウェアは割り当てごとにスコアを計算し、最もスコアの高い割り当てを提供する必要があります。OptaPlannerは、最適な結果を得るために必要な計算量を削減するスマートな手法です。最良の制約解決アプローチは、システムが競合する優先順位に対応できるかどうかを検証します。例えば、注文をドライバー間で均等に分配するか、評価の高いドライバーに優先して割り当てるかなどです。

即時配送ソリューションを最適化する際の推奨事項は以下の通りです。

  1. 注文はできる限り対応可能なドライバーに均等に割り振る。空いているドライバーがいる場合は1人に注文を集中させるのではなく、そのドライバーに新規注文を割り当てる。
  2. ピックアップ場所(レストランなど)からの距離が近いドライバーを優先的に選択する。(お客様が評価の高いドライバーや近隣の注文をまとめるなど、異なる判断基準を設定できることに留意する。)

使用されている地理空間技術に関するクイックノート：GraphHopperの役割

このシステムは、オープンソースのGraphHopperをルーティングエンジンとして利用しています。 位置追跡サービスでは、Amazon MemoryDB for Redisによる簡易な地理空間クエリと、Amazon OpenSearch Serviceによる複雑なポリゴン地理空間クエリの両方をサポートしています。 GraphHopperを使ってピックアップ地点周辺の等時線を取得し、その結果を利用してAmazon OpenSearchでポリゴン内のドライバーを検索するクエリを実行することができます。 それらの結果をキャッシュしておき、後で地理空間クエリに再利用することも可能です。

図9.等時線：車で10分または20分以内にどこまで行けますか？(ソース：GraphHopper)

シミュレータ

プロトタイプを大規模にテストするため、シミュレータが含まれています。プロトタイプはイベント駆動型のバックエンドシステムとして設計されているので、シミュレータは関連するイベント(ドライバーの位置情報更新、注文、注文割り当て、承認/拒否メッセージなど)を生成します。

シミュレータは、内部プロバイダと外部プロバイダの間で注文が適切に配分されているか、システムが指定された負荷を処理できるかどうかを判断するのに役立ちます。

シミュレーターを使用することで、ドライバー、店舗や倉庫などの出発地、顧客などの目的地といった、様々な関係者の動きを模倣することができます。これらのエンティティは、Amazon Elastic Container Service(Amazon ECS)のコンテナを利用してシミュレートされます。これによって組織は、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングすることが可能となります。各コンテナは、それぞれの関係者の複数の行動をシミュレートできます。コンテナのサイズにもよりますが、1つのコンテナ当たり最大10個以上の行動をシミュレートできます。

  • ドライバーコンテナは、ドライバーの動き(移動、注文の受け入れ/拒否、ピックアップ/配送)をシミュレートします。コンテナはクラウドからのメッセージを IoT トピック を通じて受信し、メッセージを受け取るとドライバーは割り当てを承認/拒否して配送をシミュレートし、ステータスの更新を別の IoT トピックに送信します。また、ドライバーは位置情報を定期的に送信することで、位置追跡モジュールによるデータの取り込みとインデックス作成をトリガーします。位置追跡モジュールは、ドライバーが乗車地点または降車地点に近づいたときにジオフェンシングイベントを送信する役割も果たしています。
  • オリジンコンテナはIoTトピックから注文を受け取り、受け入れるか拒否するかを決定します。Web UIから拒否率を設定でき、自動的に拒否される注文の割合が決まります。
  • 宛先コンテナは、ランダムなオリジンを選択し、Web UIからシステムに注文を送信するロジックを提供します。このコンテナには、入力ファイルに基づいて既存のイベントを再生するオプションもあります。これにより、通常日のデータ分布(低負荷、中負荷、高負荷のピーク)を使用して、システムの反応を確認しながら、特定の負荷テストシナリオをシミュレートできます。イベントは、受注の時間間隔に基づいて、それらが表示される順序で再生されます。

図11.シンプルなシミュレーターアーキテクチャ

図12.シミュレーター UI

図13.シミュレータダッシュボード

負荷能力

プロトタイプは、5万人のドライバーの位置をリアルタイムで追跡し、5分間に5千件の配送注文を処理するようテストされています。これは1日当たり数十万件の注文量に相当します。システムは水平スケール可能で、この注文量を更に上回る規模にも対応できるよう設計されています。

個々のサービスのスケーリング

  • 次のようなサーバーレスコンポーネントがあります。
    • AWS IoT Core
    • AWS Lambda：サーバーやクラスターについて考えることなくコードを実行できます。
    • Amazon EventBridge
    • AWS Step Functions：分散アプリケーションの視覚的なワークフローを提供します。
    • Amazon Kinesis Data Streams ：あらゆる規模のデータストリームを簡単にキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。

需要に応じて自動的にスケーリングします(AWS アカウントの上限を超えないよう注意が必要です)。

  • Amazon MemoryDB for Redis、Amazon OpenSearch、Amazon ECS でスケーリングする場合は、あらかじめ計画を立てる必要があります。これらのサービスは、水平スケールと垂直スケールの両方が可能です。

顧客のフロントエンドとバックエンドとの統合

Amazon EventBridgeに実装されているグローバルイベントハブを利用することで、顧客システムやサードパーティシステムとの統合が容易になります。外部システムとの疎結合した連携が可能になるのです。 具体的には、イベントをグローバルイベントハブに公開し、イベント発生時の応答や更新状況をイベントハブを通じて確認できるようにします。このイベント駆動型アーキテクチャにより疎結合なアーキテクチャを実現できます。

注文発送サービスと位置追跡サービスはグローバルイベントハブを監視し、イベントをグローバルイベントハブに公開します。

例えば

  1. 注文発送サービスは、注文割り当ての詳細をグローバルイベントハブに公開し、ドライバーや位置サービスなどの関係者や機能コンポーネントに伝達しています。
  2. 位置追跡サービスの位置特定機能は、位置情報をグローバルイベントハブに公開しています。

また、注文発送サービスは、位置追跡サービスと直接連携して、指定区域内のドライバーなどのデータをリアルタイムで取得しています。これは注文発送に要求される速報性を確保するためです。

ドライバーアプリおよび顧客アプリにおけるパブリックエンドポイント

  1. ドライバーアプリは、MQTT プロトコルを使って AWS IoT Core 経由でクラウドと連携を行います。
  2. 顧客アプリは、HTTP プロトコルを使って AWS API Gateway で経由でクラウドと連携を行います。

図14.イベント伝播による統合

結論

即時配送のラストマイル配送ソリューションは、お客様の不要な労力を減らし、データ主導のイノベーションに注力できるよう支援します。システムの大部分はサーバーレスですが、その他の部分はマネージドサービスで構成されているので、メンテナンスと運用がしやすくなっています。ほとんどの部分が自動的にスケールするため、運用コストが比較的低く抑えられます。このシステムは、設定可能なルールエンジンと最適化エンジンを通じて革新を促進することができます。また、多くの配送業者がサードパーティの車両を利用している実状も考慮されています。

さらに、システムは、ラストマイル配送の課題を解決するために、さまざまな AWS サービスを効果的に使用する方法を示しています。これらのサービスには、AWS IoT Core、Amazon Kinesis、AWS Lambda、AWS Step Functions、Amazon API Gateway、Amazon MemoryDB for Redis、Amazon OpenSearch Service、Amazon ECS などが含まれます。

次回のブログ記事では、当日配送用の AWS ベースのラストマイル配送ソリューションについて詳しく見ていきます。

免責事項

このソフトウェアはAmazon Software License (ASL)に基づいて共有されているため、AWSはいかなる責任も負いません。システム設計ではAWS Well-Architected の原則に沿って、パフォーマンス、信頼性、コスト効率、持続可能性を考慮しています。実運用を開始する前に、十分な注意とテストを推奨します。

翻訳はソリューションアーキテクト 駒野 達也 が担当しました。原文は こちら です。