Editor Top
|
Ve papi, un proveedor global líder de servicios de alojamiento web y registro de dominios, ha prestado servicios a más de 84 millones de dominios y 22 millones de clientes desde su establecimiento en 1997. Entre sus diversos sistemas internos, Customer Signal Platform proporciona herramientas para capturar, analizar y actuar sobre los clientes. y datos de productos para impulsar mejores resultados comerciales. Con esta plataforma, GoDaddy puede realizar un seguimiento de las visitas e interacciones de los usuarios en su sitio web y utilizar datos de eventos significativos para mejorar la experiencia del cliente y el rendimiento comercial general.
Hoy en día, Customer Signal Platform procesa 400 millones de eventos cada día. A medida que GoDaddy expande sus integraciones, pretende aumentar este número a 2 mil millones de eventos por día en un futuro cercano.
Al construir la plataforma de señal del cliente, GoDaddy tenía tres requisitos principales para la arquitectura del sistema:
- Minimizar su carga operativa.
- Escale automáticamente a medida que cambia el tráfico.
- Proporcione alta disponibilidad y asegúrese de que se capturen todas las señales de los clientes.
Autobús de eventos de Amazon EventBridge
Después de evaluar muchas opciones frente a sus requisitos, GoDaddy decidió implementar la plataforma de señal del cliente mediante Amazon EventBridge Event Bus. EventBridge Event Bus es un bus de eventos sin servidor que lo ayuda a recibir, filtrar, transformar, enrutar y entregar eventos. Debido a que EventBridge no tiene servidor, requiere una configuración mínima para comenzar y se escala automáticamente: se verificaron los dos primeros requisitos de GoDaddy.
Para cumplir con el tercer requisito, la solución necesitaba dar continuidad de negocio y asegurar que ningún evento se pierda desde que el cliente lo produce hasta que llega a la plataforma para ser analizado. EventBridge Event Bus incluye muchas funciones que ayudaron a GoDaddy a crear su aplicación teniendo en cuenta este requisito.
La característica principal que aprovechó GoDaddy fueron los terminales globales. Los puntos finales globales de EventBridge brindan una manera confiable y simple de mejorar la continuidad del negocio de las aplicaciones basadas en eventos. Esta nueva función, agregada en 2022, permite a los clientes crear una aplicación basada en eventos de múltiples regiones.
Terminales globales de EventBridge
Los puntos finales globales le permiten configurar un punto final DNS administrado en EventBridge, al que sus aplicaciones enviarán eventos. Luego, debe configurar dos buses de eventos personalizados en dos regiones distintas de AWS. Una es la región principal y la otra es la conmutación por error o la región secundaria. La conmutación por error de los eventos se decide en función del estado indicado por una verificación de estado de Amazon Route 53. Cuando la verificación de estado es correcta, los eventos se enrutan desde el punto final global al bus de eventos personalizado en la región principal. Y si la comprobación de estado no es correcta, el extremo global enviará los eventos al bus de eventos en la región secundaria.
La configuración más simple para puntos finales globales es la configuración activa/de archivo. Esta configuración proporciona continuidad de negocio y simplicidad al mismo tiempo. La configuración activa/de archivo define dos Regiones diferentes. La región principal es donde se implementa la aplicación y se llevan a cabo todos los procesos comerciales. La región de archivo es donde solo se implementa un bus personalizado y se archivan todos los eventos.
Además, existe una regla de replicación bidireccional entre los buses en Regiones separadas. En el caso normal, cuando no hay errores, cada vez que llega un evento al bus personalizado en la región principal, el evento se replica automáticamente en el bus personalizado de archivo en la región secundaria.
En caso de conmutación por error, el extremo global redirige los eventos a la región secundaria, donde se archivan para su procesamiento en otro momento.
Implementación de GoDaddy de terminales globales
GoDaddy estaba buscando una solución que minimizara su carga de operaciones y al mismo tiempo brindara continuidad comercial, y es por eso que adoptaron puntos finales globales y la configuración activa/de archivo. De esta forma, podrían tener la lógica de procesamiento de eventos en su región principal y tener una región secundaria en caso de que surja algún problema.
En su configuración, los eventos se archivan en la Región secundaria durante 30 días, luego de lo cual los eventos caducan. En el caso de una conmutación por error, como no necesitan procesar los eventos en tiempo real, los recopilan en el archivo. Si el problema se resuelve dentro de las 24 horas, el período de retención de la regla de replicación, los eventos se envían automáticamente a la región principal. Si el problema se resuelve en más de 24 horas, los eventos deben reproducirse en la región principal.
La siguiente imagen muestra cómo se ve su solución actual. Están trabajando con dos Regiones. EE. UU. Oeste (Oregón) es su región principal y es la ubicación del lago de datos, que es el consumidor principal de los eventos. EE.UU. Este (Norte de Virginia) es la región secundaria. Se están produciendo eventos en diferentes clientes; de los clientes, se envían a Amazon API Gateway. GoDaddy implementó dos puertas de enlace API en sus dos regiones. Los eventos se envían a API Gateway con la menor latencia del cliente. Para ello, utilizan el enrutamiento basado en la latencia proporcionado por Amazon Route 53. Luego, los eventos se envían a una función de AWS Lambda que valida los eventos y los reenvía al punto de enlace global de EventBridge en el nivel de DNS.
El punto de enlace global está configurado con la configuración activa/de archivo, y la conmutación por error está configurada para activarse a través de una verificación de estado de Route 53 que monitorea una alarma de Amazon CloudWatch. Esa alarma observa la métrica IngestionToInvocationStartLatency en la región principal.
IngestionToInvocationStartLatency es una métrica de nivel de servicio que expone el tiempo para procesar eventos desde el punto en que EventBridge los ingiere hasta el punto en que se realiza la primera invocación de un destino en las reglas configuradas. Esta métrica se mide en todas las reglas de su bus y proporciona una indicación del estado del servicio de EventBridge. Cualquier período prolongado de alta latencia de más de 30 segundos indica una interrupción del servicio.
Cuando el sistema está en estado normal, los eventos se reenvían desde el extremo global al bus de eventos de ingreso personalizado en la región principal. Ese bus de eventos personalizado tiene habilitada la replicación; esto significa que todos los eventos que llegan al bus se replican automáticamente en el bus de eventos de ingreso personalizado de la región secundaria.
Todos los eventos recibidos por el bus de eventos de ingreso se envían a la función de enriquecimiento. Esta función realiza una validación y autenticación básicas y enriquece los datos de eventos para asegurarse de que todos los eventos de diferentes clientes sean estándar.
Desde allí, los eventos se reenvían al bus de eventos de la plataforma de datos para ser enviados a los diferentes objetivos de los consumidores. El objetivo principal es su solución de lago de datos, que analiza todos los eventos.
¿Cuál fue el impacto?
Para GoDaddy, la continuidad del negocio es importante y las señales de sus clientes no se pierden debido a ningún problema con su plataforma. Esto les hace confiar en que pueden expandir sus plataformas de señales de clientes de 400 millones de eventos por día a 2 mil millones de eventos por día sin introducir gastos generales de operaciones adicionales.
Ahora, pueden procesar con confianza cientos de millones de eventos por día en su sistema y pueden seguir creciendo. La siguiente imagen muestra la cantidad de eventos ingeridos por puntos finales globales en un día normal.
Si bien el uso de GoDaddy del patrón activo/archivado les permite asegurarse de que nunca perderán ningún evento, ya están comenzando a ver ciertos casos de uso en los que desean minimizar cualquier retraso en el procesamiento de sus eventos, incluso cuando se producen interrupciones en el servicio. Debido a que ya están replicando sus eventos en una región secundaria, pueden implementar sus consumidores más críticos en ambas regiones y habilitar una configuración activa/activa para sus sistemas de misión crítica. La configuración activo/activo le permite procesar eventos paralelos tanto en la región principal como en la secundaria, lo que simplifica el procesamiento de eventos incluso durante las interrupciones y permite la continuidad del negocio.
La visión al crear Customer Signal Platform era alinearse con el alto nivel de confiabilidad, escalabilidad y mantenibilidad de GoDaddy y, al mismo tiempo, mantener la plataforma en autoservicio para que los desarrolladores puedan concentrarse en las necesidades comerciales. Esto llevó a GoDaddy a elegir puntos finales globales de Amazon EventBridge y tecnologías sin servidor para crear esta solución.
GoDaddy Customer Signal Platform es un excelente ejemplo de lo que permiten las tecnologías sin servidor. Al aprovechar la nube para manejar la mayor parte posible del trabajo pesado no diferenciado, GoDaddy ha reducido la complejidad operativa de configurar un bus de eventos para una estrategia de varias regiones, implementó mecanismos de conmutación por error en el caso de interrupciones regionales y aseguró que los eventos sean no se pierde al habilitar la replicación. La configuración de activos/archivos de endpoints globales mejora la disponibilidad de las aplicaciones de los clientes con la menor cantidad de cambios de configuración.
Si desea comenzar con los puntos finales globales de EventBridge, puede consultar esta charla sobre aplicaciones basadas en eventos. Para obtener una demostración funcional sobre cómo usar los puntos finales globales de EventBridge para eventos de conmutación por error, consulte este repositorio de Serverless Land.
— Marcia
