Eventos en tiempo real de Fleet Engine

Los indicadores casi en tiempo real de la flota que opera en el terreno son útiles para las empresas de varias maneras. Por ejemplo, las empresas pueden usarlas para lo siguiente:

  • Supervisar el rendimiento de su flota y detectar posibles problemas de forma temprana
  • Mejorar la atención al cliente proporcionando información de seguimiento y horas estimadas de llegada precisas
  • Reduce los costos identificando y abordando las ineficiencias
  • Mejorar la seguridad supervisando el comportamiento de los conductores y detectando posibles peligros
  • Optimiza las rutas y los horarios de los conductores para mejorar la eficiencia
  • Cumple con las reglamentaciones haciendo un seguimiento de la ubicación de los vehículos y las horas de servicio

En este documento, se ilustra cómo los desarrolladores pueden convertir los indicadores de los "servicios de movilidad" de Google Maps Platform ("solución de flota de última milla" [LMFS] o "solución de viajes en taxi y entregas a pedido" [ODRD]) en eventos personalizados prácticos. También se abordan los conceptos clave y las decisiones de diseño de la solución de referencia de eventos de flota disponible en GitHub.

Este documento es relevante para los siguientes roles:

Al final de este documento, deberías tener una comprensión básica de los elementos y las consideraciones clave de un sistema de transmisión, junto con los componentes básicos de Google Maps Platform y Google Cloud que conforman la solución de referencia de eventos de flota.

Descripción general de la solución de referencia de eventos de flotas

La solución de referencia de eventos de flota es una solución de código abierto que permite a los clientes y socios de movilidad generar eventos clave sobre los componentes de Fleet Engine y Google Cloud. Actualmente, la solución de referencia admite clientes que usan la solución de flota de tramo final, y próximamente se agregará compatibilidad con los viajes y las entregas on demand.

La solución genera eventos automáticamente según los cambios en datos específicos asociados con tareas o viajes. Puedes usar estos eventos para enviar notificaciones como las siguientes a las partes interesadas o activar otras acciones para tu flota.

  • Cambio en la hora estimada de llegada para la tarea
  • Cambio relativo de la hora estimada de llegada para la llegada a la tarea
  • Tiempo restante para la llegada de la tarea
  • Distancia restante hasta la llegada a la tarea
  • Cambio de estado de TaskOutcome

Cada componente de la solución de referencia se puede personalizar para que se adapte a tus necesidades empresariales.

Componentes básicos lógicos

Diagrama : En el siguiente diagrama, se muestran los componentes de alto nivel que conforman la solución de referencia de Eventos de flota.

Descripción general de los eventos de flotas y los componentes lógicos

La solución de referencia contiene los siguientes componentes:

  • Fuente del evento: Es el lugar de donde proviene el flujo de eventos original. Tanto la "solución de flota de tramo final" como la "solución de viajes y entregas on demand" se integran en Cloud Logging, lo que ayuda a convertir los registros de llamadas RPC de Fleet Engine en transmisiones de eventos disponibles para los desarrolladores. Esta es la fuente principal que se debe consumir.
  • Procesamiento: Los registros de llamadas de RPC sin procesar se convierten en eventos de cambio de estado dentro de este bloque que calcula un flujo de eventos de registro. Para detectar ese cambio, este componente requiere un almacén de estado para que los nuevos eventos entrantes se puedan comparar con los anteriores y detectar el cambio. Es posible que los eventos no siempre incluyan toda la información de interés. En esos casos, este bloque puede realizar llamadas de búsqueda a los backends según sea necesario.
    • Almacén de estado: Algunos frameworks de procesamiento proporcionan datos intermedios persistentes por sí mismos. De lo contrario, para almacenar el estado por tu cuenta, ya que estos deben ser únicos para un vehículo y un tipo de evento, un servicio de persistencia de datos de tipo K-V es una buena opción.
  • Receptor (eventos personalizados): El cambio de estado detectado debe estar disponible para cualquier aplicación o servicio que pueda beneficiarse de él. Por lo tanto, es una opción natural publicar este evento personalizado en un sistema de entrega de eventos para el consumo downstream.
  • Servicio downstream: Es el código que consume los eventos generados y realiza acciones únicas para tu caso de uso.

Selección de servicios

Cuando se trata de implementar la solución de referencia para la "solución de flota de última milla" o la "solución de viajes y entregas on demand" (disponible a fines del tercer trimestre de 2023), la selección de tecnología para "Fuente" y "Receptor" es sencilla. Por otro lado, "Procesamiento" tiene una amplia variedad de opciones. La solución de referencia eligió los siguientes servicios de Google.

Diagrama : En el siguiente diagrama, se muestra el servicio de Google Cloud para implementar la solución de referencia.

Componentes de la solución de referencia de Eventos de flota

Diseño de proyecto de Cloud

Te recomendamos que uses una implementación de varios proyectos de forma predeterminada. Esto se hace para que los consumos de Google Maps Platform y Google Cloud se puedan separar de forma clara y vincularse al acuerdo de facturación que elijas.

Origen del evento

La "Solución de red de acceso de flota" y la "Solución de viajes y entregas a pedido" escriben cargas útiles de solicitudes y respuestas a la API en Cloud Logging. Cloud Logging entrega registros a uno o más servicios de tu elección. El enrutamiento a Cloud Pub/Sub es una opción perfecta en este caso y permite convertir los registros en un flujo de eventos sin necesidad de programar.

Receptor

En Google Cloud, Cloud Pub/Sub es el sistema de entrega de mensajes casi en tiempo real que se elige. Al igual que los eventos de la fuente se entregaron a Pub/Sub, los eventos personalizados también se publican en Pub/Sub para su consumo posterior.

Procesando

Los siguientes componentes desempeñan un papel en el procesamiento de eventos. Al igual que los otros componentes básicos, los componentes de procesamiento son completamente sin servidores y escalan bien tanto hacia arriba como hacia abajo.

  • Cloud Functions como plataforma de procesamiento para la versión inicial (*)
    • Sin servidores, escala verticalmente hacia arriba y hacia abajo con controles de escalamiento para administrar los costos
    • Java como lenguaje de programación, dada la disponibilidad de bibliotecas cliente para las APIs relacionadas con Fleet Engine, que contribuyen a facilitar la implementación
  • Cloud Firestore como un almacén de estado
    • Almacén de pares clave-valor sin servidores
  • Cloud Pub/Sub como punto de integración con componentes ascendentes y descendentes
    • Integración casi en tiempo real con acoplamiento bajo

Las funciones se pueden usar tal como están con la configuración predeterminada, pero también se pueden volver a configurar. Los parámetros de configuración se establecen a través de secuencias de comandos de implementación y se documentan en detalle en los archivos README del módulo de Terraform correspondiente.

*Nota: Esta solución de referencia planea lanzar implementaciones alternativas que pueden ayudar a cumplir con diferentes requisitos.

Implementación

Para que el proceso de implementación de la solución de referencia sea repetible, personalizable, controlable con código fuente y seguro, se elige Terraform como la herramienta de automatización. Terraform es una herramienta de IaC (infraestructura como código) ampliamente adoptada con una gran compatibilidad con Google Cloud.

Módulos de Terraform

En lugar de crear un módulo de implementación de solución de referencia monolítico grande, los bloques reutilizables de automatización se implementan como módulos de Terraform que se pueden usar de forma independiente. Los módulos proporcionan una amplia variedad de variables configurables, la mayoría de las cuales tienen valores predeterminados para que puedas comenzar con rapidez, pero también tienen la flexibilidad de personalizarlas según tus necesidades y preferencias.

Módulos incluidos en la solución de referencia:

  • Configuración de registros de Fleet Engine: Automatiza los parámetros de configuración relacionados con Cloud Logging para usarlos con Fleet Engine. En la solución de referencia, se usa para enrutar los registros relacionados con Fleet Engine a un tema de Pub/Sub especificado.
  • Implementación de la función de Cloud Functions de Fleet Events: Contiene la implementación del código de la función de ejemplo y también controla la automatización de la configuración de permisos necesaria para la integración segura entre proyectos.
  • Implementación de toda la solución de referencia: Llama a los dos módulos anteriores y une toda la solución.

Seguridad

Se adopta IAM para aplicar los principios de privilegio mínimo junto con las prácticas recomendadas de seguridad de Google Cloud, como la identidad temporal como cuenta de servicio. Consulta los siguientes artículos para comprender mejor lo que ofrece Google Cloud para darte más control sobre la seguridad.

Próximas acciones

Ya puedes acceder a la solución de referencia de eventos de flota y explorarla más a fondo. Ve a GitHub para comenzar.

Apéndice

Reúne tus requisitos

Te recomendamos que recopiles tus requisitos antes en el proceso.

Primero, captura los detalles de por qué te interesa o necesitas usar eventos casi en tiempo real. Aquí tienes algunas preguntas que te ayudarán a definir tus necesidades.

  • ¿Qué información se requiere para que un flujo de eventos sea útil?
    • ¿El resultado se puede derivar únicamente de los datos capturados o producidos en los servicios de Google? ¿O se requiere el enriquecimiento de datos con sistemas externos integrados? Si es así, ¿cuáles son esos sistemas y qué interfaces de integración ofrecen?
    • ¿Cuáles son las métricas que te gustaría medir como empresa? ¿Cómo se definen?
    • Si necesitas calcular métricas en todos los eventos, ¿qué tipo de agregación se requeriría? Intenta diseñar los pasos lógicos. (p. ej., Compara la hora estimada de llegada y la hora real de llegada con los SLO en un subconjunto de la flota durante las horas pico para calcular el rendimiento con restricciones de recursos).
  • ¿Por qué te interesa un modelo basado en eventos en lugar de uno por lotes? ¿Es para una latencia más baja (tiempo de acción) o para una integración con acoplamiento bajo (agilidad)?
    • Si es para baja latencia, define "low". ¿Minutos? ¿Segundos? ¿Menos de un segundo? ¿Y qué latencia?
  • ¿Ya invertiste en una pila tecnológica y en habilidades relacionadas como equipo? Si es así, ¿cuál es y qué puntos de integración proporciona?
    • ¿Hay algún requisito que tus sistemas actuales no puedan cumplir o con el que puedan tener dificultades cuando procesen eventos provenientes de tu flota?

Principios de diseño

Siempre es útil tener un proceso de pensamiento para seguir. Esto ayuda a tomar decisiones de diseño coherentes, en especial cuando tienes una variedad de opciones para elegir.

  • Usa opciones más sencillas de forma predeterminada.
  • Se establece de forma predeterminada en un tiempo de obtención de valor más corto. Menos código, curva de aprendizaje más baja.
  • En cuanto a la latencia y el rendimiento, intenta cumplir con el estándar que estableciste, no con la optimización máxima. También evita la optimización extrema, ya que suele agregar complejidad.
  • Lo mismo ocurre con el costo. Mantén un costo razonable. Es posible que aún no estés en el estado en el que puedas comprometerte a usar servicios de alto valor, pero relativamente más caros.
  • En una fase experimental, reducir la escala verticalmente puede ser tan importante como aumentarla. Considera una plataforma que brinde flexibilidad para escalar verticalmente con un límite y, también, reducir la escala verticalmente (idealmente a cero) para que no gastes cuando no hagas nada. El alto rendimiento con infraestructura siempre activa se puede considerar más adelante en el recorrido, cuando tengas la confianza de sus necesidades.
  • Observa y mide para que, más adelante, puedas identificar en qué aspectos debes seguir trabajando.
  • Mantén los servicios con acoplamiento bajo. Esto facilita el intercambio de piezas más adelante.
  • Por último, pero no menos importante, la seguridad no puede ser laxa. Como servicio que se ejecuta en un entorno de nube pública, no puede haber puertas no seguras al sistema.

Conceptos de transmisión

Si eres relativamente nuevo en el procesamiento basado en eventos o de transmisión, hay conceptos clave que vale la pena conocer, algunos de los cuales pueden ser muy diferentes del procesamiento por lotes.

  • Escala : A diferencia del procesamiento por lotes, en el que, por lo general, tienes una buena idea de la cantidad de datos que se procesarán, en la transmisión, no puedes tenerla. Un embotellamiento en una ciudad puede generar muchos eventos de repente en un área determinada, y aun así debes poder procesarlos.
  • Creación de ventanas : En lugar de procesar los eventos uno por uno, suele ser conveniente agruparlos en una línea de tiempo en "ventanas" más pequeñas como una unidad para el procesamiento. Existen varias estrategias de renderización en ventanas, como "ventanas fijas (p. ej., cada día calendario)", "ventanas deslizantes (últimos 5 minutos)", "ventanas de sesión (durante este viaje)", entre las que debes elegir. Cuanto más larga sea la ventana, más se demorará la producción de resultados. Elige el modelo y la configuración adecuados que cumplan con tus requisitos.
  • Activación : Hay casos en los que no tienes más opción que tener ventanas relativamente más largas. Aun así, no quieres esperar hasta el final de la ventana para producir eventos, sino que prefieres emitir resultados intermedios en el medio. Este concepto se puede implementar para casos de uso en los que es valioso mostrar resultados rápidos primero y, luego, corregirlos. Imagina que emites un estado intermedio al 25%, 50% y 75% de la finalización de una entrega.
  • Orden : Los eventos no necesariamente llegan al sistema en el orden en que se generaron. En especial, para casos de uso que implican la comunicación a través de redes móviles, lo que agrega retrasos y rutas de enrutamiento complejas. Debes conocer la diferencia entre la "hora del evento" (cuando ocurrió el evento) y la "hora del proceso" (cuando el evento llegó al sistema) y controlar los eventos según corresponda. En general, te conviene procesar los eventos según la "hora del evento".
  • Entrega de mensajes: Al menos una vez frente a exactamente una vez: Las diferentes plataformas de eventos tienen diferente compatibilidad con estas opciones. Según tu caso de uso, debes considerar estrategias de reintento o de anulación de duplicación.
  • Integridad : Al igual que con el cambio de orden, existe la posibilidad de que se pierdan mensajes. Esto puede deberse al cierre de la aplicación y del dispositivo debido a la duración de la batería, daños involuntarios en el teléfono, pérdida de conectividad en un túnel o un mensaje que se recibió, pero solo fuera de un período aceptable. ¿Cómo afectaría la falta de integridad a tus resultados?

Esta no es una lista completa, sino una introducción. Estas son algunas lecturas muy recomendadas que pueden ayudarte a profundizar tu comprensión de cada uno.

Colaboradores

Google mantiene este documento. Los siguientes colaboradores lo escribieron originalmente.

Autores principales:

  • Mary Pishny | Gerente de producto, Google Maps Platform
  • Ethel Bao| Ingeniera de software, Google Maps Platform
  • Mohanad Almiski | Ingeniero de software, Google Maps Platform
  • Naoya Moritani | Ingeniero de soluciones, Google Maps Platform