Fleet Engine と Fleet Events リファレンス ソリューションを使用して、ほぼリアルタイムのイベントを生成

地上で稼働しているフリートからのほぼリアルタイムの信号は、さまざまな点でビジネスに役立ちます。たとえば、企業はこれらの機能を使用して次のことができます。

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

このドキュメントでは、デベロッパーが 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 サービスを示しています。

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

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（*）
    • サーバーレス。スケーリング制御でスケールアップ、スケールダウンを行い、コストを管理
    • Fleet Engine 関連の API 用のクライアント ライブラリを利用できることから、実装の容易さに寄与するプログラミング言語として Java が採用されている
  • ステートストアとしての 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 トピックに転送するために使用されます。
  • フリート イベント クラウド関数のデプロイ: サンプル関数コードのデプロイが含まれており、プロジェクト間の安全な統合に必要な権限設定の自動化も処理されます。
  • リファレンス ソリューション全体のデプロイ: 前の 2 つのモジュールを呼び出し、ソリューション全体をラップします。

セキュリティ

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

次のアクション

これで、フリート イベント リファレンス ソリューションにアクセスして詳細を確認できるようになりました。使用を開始するには、GitHub にアクセスしてください。

付録

要件を収集する

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

まず、ほぼリアルタイムのイベントを使用する理由、または使用する必要がある理由を詳しく把握します。ニーズを明確化するのに役立つ質問をいくつかご紹介します。

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

デザインの原則

なんらかの思考プロセスに従うことは、常に有益です。これにより、特に選択肢が多い場合に、一貫した設計上の決定を行うことができます。

  • デフォルトはシンプルなオプションです。
  • デフォルトで価値創出までの時間が短くなる。少ないコードで、習得が容易。
  • レイテンシとパフォーマンスについては、最大限の最適化ではなく、設定した基準を満たすことを目指します。また、複雑さが増す場合が多いため、極端な最適化は避けてください。
  • 費用についても同様です。費用を抑える。高価値だが比較的高価なサービスを利用できる状態になっていない場合があります。
  • 試験運用フェーズでは、スケールダウンがスケールアップと同じくらい重要になることがあります。上限のあるスケールアップとスケールダウン（理想的にはゼロへのスケールダウン）が可能なプラットフォームについて検討し、何もしないときに費用が発生しないようにします。常時稼働のインフラストラクチャによる高パフォーマンスは、そのニーズに確信を持てる段階から検討できます。
  • 後でどこで作業を進めるかを特定できるように、観察と測定を行います。
  • サービスを疎結合にする。後で 1 つずつ入れ替えるのが簡単になります。
  • 最後に、セキュリティをゆるめることはできません。パブリック クラウド環境で実行されるサービスとして、システムへのセキュリティで保護されていないドアは存在できません。

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

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

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

これはすべてを網羅したリストではなく、概要です。ここでは、それぞれの理解を深めるために特におすすめの読み取り方法を紹介します。

協力者

このドキュメントは Google が管理します。最初に書いたのは以下の寄稿者です。

主任執筆者:

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