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% の完了時に中間ステータスを出力するとします。
  • 順序付け : イベントは、生成された順序でシステムに届くとは限りません。特に、モバイル ネットワークを介した通信が遅延や複雑なルーティング パスを追加するユースケースに適しています。「イベント時間」（イベントが実際に発生した時刻）と「処理時間」（イベントがシステムに到達した時刻）の違いを認識し、それに応じてイベントを処理する必要があります。通常は、イベントを「イベント時間」に基づいて処理します。
  • メッセージ配信 - 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