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

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

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

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

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

このドキュメントを読み終えるまでに、ストリーミング システムの 重要な要素と考慮事項の基礎を理解し、フリート イベント リファレンス ソリューションを構成する Google Maps Platform と Google Cloud の ビルディング ブロックを理解できるようになります。

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

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

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

  • タスクの到着予定時刻の変更
  • タスクの到着予定時刻の相対的な変更
  • タスクの到着までの残り時間
  • タスクの到着までの残り距離
  • 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 に公開され、ダウンストリームで使用されます。

処理

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

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

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

デプロイ

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

  • Google Cloud Platform プロバイダ: 「Google Cloud Platform プロバイダ」でサポートされているリソースのドキュメント
  • Terraform の使用に関するベスト プラクティス: Google Cloud での最適な導入方法に関する豊富なガイダンス
  • Terraform Registry: Google とコミュニティでサポートされている追加のモジュール

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 つずつ処理するのではなく、タイムライン上のイベントを計算の単位として、より小さな「ウィンドウ」にグループ化することがよくあります。「固定ウィンドウ（例: 毎日のカレンダー）」、「スライディング ウィンドウ（過去 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、ソリューション エンジニア