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

地上で運用されているフリートからのほぼリアルタイムのシグナルは、ビジネスにさまざまな形で役立ちます。たとえば、企業は次のような用途に使用できます。

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

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

このドキュメントは、次のユーザーを対象としています。

このドキュメントの最後まで読めば、ストリーミング システムの主要要素と考慮事項の基本を理解し、フリート イベントのリファレンス ソリューションを構成する Google Maps Platform と Google Cloud の構築ブロックを理解できるようになります。

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

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

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

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

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

論理構成要素

図 : 次の図は、フリート イベントのリファレンス ソリューションを構成する主な構成要素を示しています。

Fleet Events の概要と論理的な構成要素

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

  • イベントソース: 元のイベント ストリームの取得元。「ラスト ワンマイルのフリート ソリューション」と「オンデマンド配車と配達ソリューション」のどちらも、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 (*)
    • サーバーレス、スケーリング制御でスケールアップ / ダウンして費用を管理
    • プログラミング言語として 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 トピックに転送するために使用されます。
  • Fleet Events Cloud Functions のデプロイ: サンプル関数コードのデプロイが含まれており、安全なプロジェクト間の統合に必要な権限設定の自動化も処理します。
  • リファレンス ソリューション全体のデプロイ: 前の 2 つのモジュールを呼び出し、ソリューション全体をラップします。

セキュリティ

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

次のアクション

これで、フリート イベント リファレンス ソリューションにアクセスして詳細を確認する準備が整いました。GitHub にアクセスして、利用を開始してください。

付録

要件を収集する

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

まず、ニアリアルタイム イベントに関心がある理由や、ニアリアルタイム イベントを使用する必要がある理由を詳しく把握します。ニーズを明確にするために、以下のような質問をしてみてください。

  • イベント ストリームを有用にするには、どのような情報が必要ですか？
    • 結果は、Google サービスでキャプチャまたは生成されたデータのみから導き出せますか？統合された外部システムによるデータ拡充は必要ですか？ある場合は、それらのシステムと、提供されている統合インターフェースを教えてください。
    • ビジネスとして測定したい指標は何ですか？どのように定義されていますか？
    • イベント全体で指標を計算する必要がある場合、どのような集計が必要になりますか？論理的な手順を整理してみてください。（例: ピーク時にフリートのサブセクション全体の ETA/ATA を SLO と比較し、リソースの制約の下でパフォーマンスを計算します）。
  • バッチではなくイベントベースのモデルに興味をお持ちなのはなぜですか？低レイテンシ（アクションまでの時間）を重視するか、疎結合のインテグレーション（アジリティ）を重視するか？
    • 低レイテンシの場合は「low」を定義します。分秒単位ですか？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