地上で運用されているフリートからのほぼリアルタイムのシグナルは、さまざまな方法でビジネスに役立ちます。たとえば、次のような用途に使用できます。
- フリートのパフォーマンスをモニタリングし、潜在的な問題を早期に特定する
- 正確な ETA と追跡情報を提供して、カスタマー サービスを改善する
- 非効率な部分を特定して対処することで、コストを削減する
- 運転手の行動をモニタリングし、潜在的な危険を特定することで、安全性を向上させる
- 運転手のルートとスケジュールを最適化して、効率を向上させる
- 車両の位置とサービス時間を追跡して、規制を遵守する
このドキュメントでは、デベロッパーが Google Maps Platform の「モビリティ サービス」（「ラスト ワンマイル フリート ソリューション」（LMFS）または「オンデマンド配車と配達 ソリューション」（ODRD））からのシグナルを、実用的なカスタム イベントに変換する方法について説明します。GitHub で入手できる フリート イベント リファレンス ソリューション の主要なコンセプトと設計上の決定事項についても説明します。
このドキュメントは、次のユーザーを対象としています。
- Google Maps Platform の「モビリティ サービス」 とそのコア コンポーネントの 1 つである「Fleet Engine」に精通しているアーキテクト。「モビリティ サービス」を初めて使用する場合は、ニーズに応じて、ラスト ワンマイル フリート ソリューション または オンデマンド配車と配達 ソリューションについて理解することをおすすめします。
- Google Cloud に精通しているアーキテクト。Google Cloud を初めて使用する場合は、 「Google Cloud でストリーミング データ パイプラインを構築する」 を事前に読むことをおすすめします。
- 他の環境やソフトウェア スタックをターゲットにしている場合は、Fleet Engine の統合ポイントと重要な考慮事項を理解することに重点を置いてください。これらは引き続き適用できます。
- フリートからのイベントの生成方法と利用方法に関心がある方。
フリート イベント リファレンス ソリューションの概要
フリート イベント リファレンス ソリューションは、モビリティのお客様とパートナーが 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 へのルーティングが最適であり、コーディングなしでログをイベント ストリームに変換できます。
- ロギング | フリート パフォーマンス （LMFS ユーザー向け）
- ロギング | 移動と注文 の進捗状況 （ODRD ユーザー向け）
- Pub/Sub に転送されたログを表示する : ロギング → 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）ツールとして広く採用されています。
- 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 トピックにルーティングするために使用されます。
- Fleet Events Cloud Functions のデプロイ: サンプル関数 のコード デプロイが含まれており、安全なクロスプロジェクト統合に必要な権限設定の自動化も処理します。
- リファレンス ソリューション全体のデプロイ: 前の 2 つのモジュールを呼び出し、 ソリューション全体をラップします。
セキュリティ
IAM は、最小権限の原則と、サービス アカウントの権限借用などの Google Cloud のセキュリティに関するベスト プラクティスを適用するために採用されています。Google Cloud がセキュリティの制御を強化するために提供している機能について詳しくは、次の記事をご覧ください。
次の対策
これで、フリート イベント リファレンス ソリューション にアクセスしてさらに詳しく調べることができます。 GitHub にアクセスして開始してください。
付録
要件を収集する
プロセスの早い段階で要件を収集することをおすすめします。
まず、ほぼリアルタイムのイベントを使用することに関心がある理由や、使用する必要がある理由の詳細を把握します。ニーズを明確にするために、次の質問を参考にしてください。
- イベント ストリームを役立てるには、どのような情報が必要ですか？
- 結果は、Google サービスでキャプチャまたは生成されたデータのみから導き出すことができますか？それとも、統合された外部システムでデータ拡充が必要ですか？必要な場合は、どのようなシステムで、どのような統合インターフェースを提供していますか？
- ビジネスとして測定したい指標は何ですか？どのように定義されていますか？
- イベント間で指標を計算する必要がある場合、どのような集計が必要ですか？論理的な手順をレイアウトしてみてください。（例: ピーク時間中にフリートのサブセットの SLO と ETA/ATA を比較して、リソース制約下でのパフォーマンスを計算します。
- イベントベースのモデルに関心があるのはなぜですか？バッチ処理ではなく？これは、レイテンシの短縮（アクションまでの時間）のためですか、それとも疎結合の統合（アジリティ）のためですか？
- レイテンシが短い場合は、「短い」を定義します。分？秒？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、ソリューション エンジニア