Fleet Engine のリアルタイム イベント

現場で稼働しているフリートからの準リアルタイムのシグナルは、さまざまな方法でビジネスに役立ちます。たとえば、企業はこれらを使用して次のことができます。

  • フリートのパフォーマンスをモニタリングし、潜在的な問題を早期に特定する
  • 正確な到着予定時刻と追跡情報を提供して、カスタマー サービスを改善する
  • 非効率性を特定して対処することで費用を削減する
  • ドライバーの行動をモニタリングし、潜在的な危険を特定することで、安全性を向上させる
  • ドライバーのルートとスケジュールを最適化して効率を向上
  • 車両の位置とサービス時間を追跡して規制を遵守

このドキュメントでは、Google Maps Platform の「モビリティ サービス」（「ラストマイル フリート ソリューション」（LMFS）または「オンデマンドの乗車と配達のソリューション」（ODRD））からのシグナルを、デベロッパーが実用的なカスタム イベントに変換する方法について説明します。GitHub で入手できるフリート イベント リファレンス ソリューションの主なコンセプトと設計上の決定事項についても説明します。

このドキュメントは、以下に関連しています。

このドキュメントを読み終えると、ストリーミング システムの主要な要素と考慮事項、およびフリート イベント リファレンス ソリューションを構成する Google Maps Platform と Google Cloud のビルディング ブロックについて、基本的な理解が得られます。

フリート イベント リファレンス ソリューションの概要

フリート イベント リファレンス ソリューションは、モビリティのお客様とパートナーが Fleet Engine と Google Cloud コンポーネント上で重要なイベントを生成できるようにするオープンソース ソリューションです。現在、このリファレンス ソリューションは、ラスト ワンマイルのフリート ソリューションを使用しているお客様をサポートしています。オンデマンド配車と配達のサポートも今後追加される予定です。

このソリューションは、タスクまたはルートに関連付けられた特定のデータの変更に基づいてイベントを自動的に生成します。これらのイベントを使用して、関係者に次のような通知を送信したり、フリートに対して他のアクションをトリガーしたりできます。

  • タスクの到着予定時刻の変更
  • タスク到着の相対的な ETA の変更
  • タスク到着までの残り時間
  • タスクの到着までの残り距離
  • TaskOutcome のステータスの変更

リファレンス ソリューションの各コンポーネントは、ビジネスニーズに合わせてカスタマイズできます。

論理的な構成要素

図 : 次の図は、フリート イベント リファレンス ソリューションを構成するビルディング ブロックの概要を示しています。

フリート イベントの概要と論理ビルディング ブロック

このリファレンス ソリューションには、次のコンポーネントが含まれています。

  • イベントソース: 元のイベント ストリームの送信元。「ラスト ワンマイルのフリート ソリューション」と「オンデマンド配車と配達のソリューション」はどちらも Cloud Logging と統合されており、Fleet Engine RPC 呼び出しログをデベロッパーが利用できるイベント ストリームに変換できます。これが、使用するコアソースです。
  • 処理: 未加工の RPC 呼び出しログは、このブロック内で状態変更イベントに変換され、ログイベントのストリームで計算されます。このような変更を検出するには、このコンポーネントに状態ストアが必要です。これにより、新しい受信イベントを以前のイベントと比較して変更を検出できます。イベントに、関心のあるすべての情報が含まれているとは限りません。このような場合、このブロックは必要に応じてバックエンドへのルックアップ呼び出しを行うことがあります。
    • 状態ストア: 一部の処理フレームワークでは、中間データが独自に永続化されます。そうでない場合は、車両とイベントタイプに固有の状態を独自に保存するために、K-V タイプのデータ永続性サービスが適しています。
  • シンク（カスタム イベント）: 検出された状態変化は、それを利用できるすべてのアプリケーションまたはサービスで利用できるようにする必要があります。したがって、このカスタム イベントをイベント配信システムに公開して、ダウンストリームで使用するのは自然な選択です。
  • ダウンストリーム サービス: 生成されたイベントを消費し、ユースケースに固有のアクションを実行するコード。

サービスの選択

「ラスト ワンマイルのフリート ソリューション」または「オンデマンド配車と配達ソリューション」（2023 年第 3 四半期後半にリリース予定）のリファレンス ソリューションを実装する場合、「ソース」と「シンク」のテクノロジーの選択は簡単です。一方、「処理」には幅広いオプションがあります。リファレンス ソリューションでは、次の Google サービスが選択されています。

図 : 次の図は、リファレンス ソリューションを実装する Google Cloud サービスを示しています。

フリート イベント リファレンス ソリューションの構成要素

クラウド プロジェクトのレイアウト

デフォルトでマルチプロジェクト デプロイを使用することをおすすめします。これにより、Google Maps Platform と Google Cloud の使用量を明確に分離し、選択したお支払い方法に関連付けることができます。

イベントソース

ラスト ワンマイルのフリート ソリューションとオンデマンド配車と配達ソリューションは、API リクエストとレスポンスのペイロードを Cloud Logging に書き込みます。Cloud Logging は、選択した 1 つ以上のサービスにログを配信します。Cloud Pub/Sub へのルーティングは、この場合に最適な選択肢であり、コーディングなしでログをイベント ストリームに変換できます。

シンク

Google Cloud では、Cloud Pub/Sub が準リアルタイムのメッセージ配信システムとして選択されています。ソースからのイベントが Pub/Sub に配信されるのと同様に、カスタム イベントもダウンストリームで使用するために Pub/Sub にパブリッシュされます。

処理中

イベント処理では、次のコンポーネントが役割を果たします。他のビルディング ブロックと同様に、処理コンポーネントは完全にサーバーレスであり、スケールアップとスケールダウンの両方に適しています。

  • Cloud Functions: 初期リリースのコンピューティング プラットフォーム（*）
    • サーバーレス。スケーリング制御によりスケールアップとスケールダウンを行い、費用を管理
    • プログラミング言語として Java を使用。Fleet Engine 関連の API のクライアント ライブラリが利用可能であるため、実装が容易になる。
  • Cloud Firestore（状態ストアとして）
    • サーバーレス Key-Value ストア
  • Cloud Pub/Sub: アップストリーム コンポーネントとダウンストリーム コンポーネントとの統合ポイント
    • 疎結合の準リアルタイム統合

関数はデフォルト設定のまま使用できますが、再構成することもできます。構成パラメータはデプロイ スクリプトで設定され、対応する Terraform モジュールの README に詳細が記載されています。

*注: このリファレンス ソリューションでは、さまざまな要件を満たすのに役立つ代替実装をリリースする予定です。

デプロイ

リファレンス ソリューションのデプロイ プロセスを繰り返し可能、カスタマイズ可能、ソースコード制御可能、安全にするために、自動化ツールとして Terraform が選択されています。Terraform は、Google Cloud を幅広くサポートする、広く採用されている IaC（Infrastructure as Code）ツールです。

Terraform モジュール

1 つの大きなモノリシックなリファレンス ソリューション デプロイ モジュールを作成する代わりに、再利用可能な自動化ブロックが Terraform モジュールとして実装され、独立して使用できます。モジュールには、構成可能な変数が幅広く用意されています。そのほとんどにはデフォルト値が設定されているため、すぐに使い始めることができます。また、ニーズや好みに応じて柔軟にカスタマイズすることもできます。

リファレンス ソリューションに含まれるモジュール:

  • Fleet Engine のロギング構成: Fleet Engine で使用する Cloud Logging 関連の構成を自動化します。リファレンス ソリューションでは、Fleet Engine 関連のログを指定された Pub/Sub トピックに転送するために使用されます。
  • フリート イベントの Cloud Functions の関数のデプロイ: サンプル関数のコードのデプロイが含まれています。また、安全なプロジェクト間の統合に必要な権限設定の自動化も処理します。
  • リファレンス ソリューション全体のデプロイ: 前の 2 つのモジュールを呼び出し、ソリューション全体をラップします。

セキュリティ

IAM は、サービス アカウントの権限借用などの Google Cloud のセキュリティのベスト プラクティスとともに、最小権限の原則を適用するために採用されています。セキュリティをより詳細に制御するために Google Cloud が提供する機能については、次の記事をご覧ください。

次の対策

これで、フリート イベント リファレンス ソリューションにアクセスして、さらに詳しく確認する準備が整いました。GitHub にアクセスして、使い始めることができます。

付録

要件をまとめる

プロセスの早い段階で要件を収集することをおすすめします。

まず、ニアリアルタイム イベントを使用する理由や必要性について、詳細を把握します。ニーズを明確にするための質問をいくつかご紹介します。

  • イベント ストリームが有用であるために必要な情報は何ですか？
    • 結果は、Google サービスでキャプチャまたは生成されたデータのみから導出できますか？または、統合された外部システムによるデータ拡充が必要ですか？その場合、それらのシステムはどのようなもので、どのような統合インターフェースを提供していますか？
    • ビジネスとして測定したい指標は何ですか？それはどのように定義されていますか？
    • イベント間で指標を計算する必要がある場合、どのような集計が必要になりますか。論理的な手順をレイアウトしてみてください。（例: ピーク時間帯にフリートのサブセット全体で ETA/ATA と SLO を比較して、リソース制約下でのパフォーマンスを計算します。
  • バッチではなくイベントベースのモデルに関心があるのはなぜですか？これは、低レイテンシ（アクションまでの時間）のためですか、それとも疎結合の統合（アジリティ）のためですか？
    • 低レイテンシの場合は、「低」を定義します。数分？秒？1 秒未満？レイテンシはどの程度ですか？
  • チームとして技術スタックと関連スキルにすでに投資していますか？ある場合、それは何ですか？また、どのような統合ポイントを提供していますか？
    • フリートから送信されるイベントを処理する際に、現在のシステムでは満たせない、または対応が困難な要件はありますか？

設計の原則

思考プロセスをたどることは常に有益です。これにより、特にさまざまなオプションから選択できる場合に、一貫した設計上の決定を行うことができます。

  • デフォルトでシンプルなオプションを選択する。
  • 価値創出までの時間を短縮することをデフォルトにする。コードが少なく、学習曲線が緩やか。
  • レイテンシとパフォーマンスについては、最大限の最適化ではなく、設定した基準を満たすことを目指します。また、極端な最適化は複雑さが増すことが多いため、避けてください。
  • 費用についても同様です。費用を妥当な範囲に抑える。価値は高いものの、比較的費用のかかるサービスの使用を確約できる状態ではないかもしれません。
  • 試験運用フェーズでは、スケールダウンはスケールアップと同じくらい重要です。上限を設定してスケールアップし、スケールダウン（理想的にはゼロまで）できる柔軟性を備えたプラットフォームを検討してください。これにより、何もしていないときに費用が発生しなくなります。常時稼働のインフラストラクチャによる高パフォーマンスは、その必要性に確信が持てたときに、後で検討できます。
  • 観察と測定を行い、後でさらに作業が必要な箇所を特定できるようにします。
  • サービスを疎結合に保ちます。これにより、後で部品を 1 つずつ交換しやすくなります。
  • 最後になりますが、セキュリティを緩めることはできません。パブリック クラウド環境で実行されるサービスとして、システムにセキュリティで保護されていないドアを設けることはできません。

ストリーミングのコンセプト

イベントベースまたはストリーミングを初めて使用する場合は、重要なコンセプトを理解しておく必要があります。その一部はバッチ処理とは大きく異なる場合があります。

  • スケール : 通常、処理するデータの量を把握しているバッチ処理とは対照的に、ストリーミングでは把握できません。都市の交通渋滞により、特定のエリアから突然大量のイベントが発生する可能性がありますが、それでも処理できる必要があります。
  • ウィンドウ処理 : イベントを 1 つずつ処理するのではなく、タイムライン上のイベントをより小さな「ウィンドウ」にグループ化して、計算の単位とすることがよくあります。ウィンドウ処理には、「固定ウィンドウ（例: 毎日）」、「スライディング ウィンドウ（過去 5 分間）」、「セッション ウィンドウ（この旅行中）」など、さまざまな戦略があります。ウィンドウが長いほど、結果の生成に時間がかかります。要件を満たす適切なモデルと構成を選択します。
  • トリガー : 比較的長いウィンドウを使用せざるを得ない場合があります。それでも、ウィンドウの最後まで待ってイベントを生成するのではなく、中間の結果を出力したい場合があります。このコンセプトは、最初に迅速な結果を返し、後で修正することに価値があるユースケースに実装できます。配送の 25%、50%、75% の完了時に中間ステータスを出力するとします。
  • 順序 : イベントは、生成された順序でシステムに到達するとは限りません。特に、モバイル ネットワークを介した通信を伴うユースケースでは、遅延や複雑なルーティング パスが発生します。「イベント時間」（イベントが実際に発生した時間）と「処理時間」（イベントがシステムに到達した時間）の違いを認識し、それに応じてイベントを処理する必要があります。一般に、イベントは「イベント時間」に基づいて処理する必要があります。
  • メッセージ配信 - at-least-once と exactly-once: イベント プラットフォームによって、これらのサポートは異なります。ユースケースに応じて、再試行戦略または重複除去戦略を検討する必要があります。
  • 完全性 : 順序の変更と同様に、メッセージが失われる可能性があります。これは、デバイスのバッテリー駆動時間、スマートフォンへの意図しない損傷、トンネル内での接続の切断、または許容範囲外で受信したメッセージが原因で、アプリケーションとデバイスがシャットダウンしたことが原因である可能性があります。不完全なデータは、結果にどのような影響を及ぼしますか？

これは完全なリストではなく、概要です。以下に、それぞれの理解を深めるのに役立つおすすめの資料をご紹介します。

寄稿者

このドキュメントは Google が管理しています。このドキュメントは、以下のコントリビューターによって作成されました。

主な著者:

  • Mary Pishny | Google Maps Platform 担当プロダクト マネージャー
  • Ethel Bao| ソフトウェア エンジニア、Google Maps Platform
  • Mohanad Almiski | ソフトウェア エンジニア、Google Maps Platform
  • Naoya Moritani | Google Maps Platform、ソリューション エンジニア