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

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

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

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

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

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

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

フリート イベント リファレンス ソリューションは、モビリティのお客様とパートナーが 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（*）
    • サーバーレス。スケーリング制御でスケールアップとスケールダウンを行い、費用を管理する
    • Fleet Engine 関連の API 用のクライアント ライブラリが利用可能であるため、実装が容易になるプログラミング言語として Java
  • 状態ストアとしての Cloud Firestore
    • サーバーレス Key-Value ストア
  • 上流コンポーネントと下流コンポーネントの統合ポイントとしての Cloud Pub/Sub
    • 疎結合のニア リアルタイム統合

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

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

デプロイ

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

Terraform モジュール

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

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

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

セキュリティ

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

次のアクション

これで、フリート イベント リファレンス ソリューションにアクセスして、さらに詳しく調べることができます。開始するには、GitHub にアクセスしてください。

付録

要件を収集する

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

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

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

設計の原則

常に、従うべき思考プロセスがあると便利です。これにより、特にさまざまなオプションから選択する場合に、一貫性のある設計上の決定を下すことができます。

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

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

イベントベースまたはストリーミングの経験が浅い場合は、知っておくべき重要なコンセプトがあります。その一部はバッチ処理とは大きく異なります。

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

これはすべてを網羅したリストではなく、概要です。各サービスについてさらに理解を深めるために、以下のドキュメントを読むことを強くおすすめします。

寄稿者

このドキュメントは Google が管理しています。このコンテンツは、以下の投稿者が作成しました。

主な著者:

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