Resumen de los Servicios de Pago e Infraestructura en Ripley

La sesión tiene como objetivo proporcionar una visión general de todo el proyecto y los servicios ofrecidos a Ripley, asegurando que los participantes tengan el contexto y la información necesarios para comprender su posición actual.

El servicio proporcionado a Ripley se originó en una subsidiaria de Gunder llamada JPEG, dirigida por Paul, quien continúa supervisando JPEG. Este ecosistema se desarrolló como un servicio de Marca Blanca, diseñado para atender a cualquier entidad que necesite una aplicación de pago, que Ripley adoptó en ese momento.

El motor de pagos y el Soft Token se integraron en la aplicación Check de Ripley, mientras que JPEG también tenía su propia aplicación de pagos. La integración permitió la continuación de la oferta de servicios a otras empresas, incluyendo Betaflight, si era necesario.

Actualmente, el motor de cuentas se utiliza principalmente dentro de la aplicación Checksum, centrándose en la gestión de saldos. Esto destaca la relevancia continua del motor en la gestión de transacciones financieras.

La infraestructura está en gran parte alojada en Google Cloud Platform (GCP), con partes gestionadas tanto por el proveedor de servicios como por Ripley. Ripley opera sus propios motores de manera independiente, lo que indica una estructura operativa colaborativa pero distinta.

La base de código de la aplicación es compartida, con diferencias menores gestionadas a través de ramas. Paul es actualmente el único desarrollador que realiza cambios en el repositorio, asegurando continuidad y experiencia en el proyecto.

En producción, hay dos proyectos principales de GCP: el Motor de Pagos (identificado por el ID PayPay) y el Motor de Cuentas de Cheque. El Motor de Pagos gestiona tanto el procesamiento de pagos como las funcionalidades de Soft Token, cruciales para la gestión de transacciones.

El Motor de Pagos es responsable de registrar todas las transacciones de pago en la base de datos, incluyendo el registro de Puntos de Venta (POS) para Cheque. Este sistema es esencial para gestionar los procesos de pago en Ripley, como los de sus locales minoristas.

El motor de Soft Token facilita el registro de dispositivos para la autorización de pagos seguros. Permite a los usuarios registrar sus dispositivos, como aquellos vinculados a Banco de Chile o Falabella, como dispositivos de confianza. Este proceso implica almacenar un valor específico en el dispositivo durante el registro, que se utiliza para validar transacciones, asegurando que los pagos provengan del dispositivo registrado y no de fuentes no autorizadas.

El motor de Soft Token es el único conectado a una base de datos MySQL y forma parte de un proyecto de pago en Google Cloud Platform (GCP). Otro proyecto, también en GCP, gestiona los datos de las cuentas, incluidos los saldos de los usuarios. Ambos proyectos están actualmente desplegados utilizando Cloud Run, con el motor de pagos que aún utiliza algunas Cloud Functions. El motor de cuentas es crítico debido a su mayor tráfico e integración con la nueva aplicación BTF, FlexSense, lo que lo convierte en un repositorio vital para las operaciones.

La seguridad de las aplicaciones, incluyendo Betaflix y FlexWin, no ha sido revisada de manera continua por Hackmetrics, enfocándose en cambio en Betaflix. Sin embargo, ha habido solicitudes de evidencia relacionada con el cumplimiento de la norma ISO, siendo la última solicitud el año pasado cuando se ejecutó un Plan de Recuperación ante Desastres (DRP). Aunque hubo una iniciativa para repetir este proceso este año, no avanzó más allá de las comunicaciones iniciales. El equipo coordina con Pau para proporcionar evidencia anual de cumplimiento.

El proyecto de la API JPEG existe dentro del marco de GCP, pero no ha sido gestionado activamente por el hablante. Sirve para sincronizar contactos con una aplicación. Históricamente, ha habido riesgos mínimos asociados con esta aplicación, con solo mejoras menores realizadas a lo largo del tiempo. El hablante señala que en ocasiones se han implementado cambios, pero en general, el proyecto no ha requerido una supervisión significativa.

La discusión destaca que hace más de tres años no había problemas significativos con la gestión del tráfico durante días de alta demanda como el Black Friday. Actualmente, Petaflight experimenta más tráfico que antes, lo que indica una escalabilidad exitosa de sus sistemas sin necesidad de escalar la base de datos u otros ajustes.

Se enfatiza la integración con Google Cloud Platform (GCP), señalando que hay varios proyectos y servicios que interactúan entre sí. El orador menciona que hay un diagrama bien elaborado que ilustra la comunicación entre diferentes servicios, incluyendo el acceso a cuentas y las interconexiones entre sus sistemas.

Se discute un servicio de reconocimiento facial establecido a través de Amazon hace cinco años. Este servicio requiere que los usuarios suban una foto de su identificación y un selfie para la verificación. Una vez validado, genera un registro en el motor SoftToken, haciéndolo disponible para su uso. El proceso incluye la verificación de números de identificación y otros datos personales.

El sistema de procesamiento de pagos está delineado, mencionando que Ripley gestiona los pagos a varios proveedores. Se discute si se realizan pagos por ciertos servicios, con un enfoque en el proceso de facturación. Se señala que Paul maneja el pago de las facturas, y el equipo confía en él para asuntos financieros, lo que indica una falta de participación directa de su parte.

El orador aclara que la cuenta de Amazon es pagada por su equipo utilizando una tarjeta NAI, con costos mínimos debido a los servicios en funcionamiento, como Reconocimiento y Route 53. Esto indica un enfoque estructurado para gestionar los gastos de servicios en la nube.

Surge una consulta sobre el dominio HayPay, con incertidumbre acerca de sus responsabilidades de alojamiento y pago. La discusión revela una falta de claridad sobre si el dominio es gestionado dentro de GCP o por otra entidad, destacando la necesidad de una mayor investigación sobre la gestión del dominio y los costos asociados.

El orador presenta una visión general de la estructura del proyecto, señalando que el entorno de Producción está más organizado en comparación con Staging y Desarrollo. Se hace un punto significativo sobre el motor SoftToken que se encuentra en un proyecto separado llamado JPEG POC, que no se migró a su propio proyecto debido a las limitaciones de crecimiento durante su configuración inicial. Este motor SoftToken se comparte entre Staging y Desarrollo, utilizando las mismas instancias de CloudRAM y base de datos.

La discusión comienza con un enfoque en el proyecto de Philips, señalando que el motor para cuentas es parte de su propio proyecto. Se observan diferencias menores en los entornos de Stain y Desarrollo, particularmente durante la creación de entornos que conducen a Producción. Debido a consideraciones de costo, JPEG era inicialmente pequeño, lo que resultó en la decisión de crear un solo balanceador de carga para todos los proyectos en lugar de múltiples.

El equilibrador de carga en el proyecto Accounts Engine es responsable de redirigir el tráfico a varios entornos. Por ejemplo, el entorno Stain tiene una regla específica que utiliza su certificado, dirigiendo el tráfico a una máquina virtual que ejecuta Nginx, que luego redirige al respectivo proyecto CloudRAM. Una configuración similar existe para el entorno de Desarrollo, enfatizando la importancia del proyecto de Producción debido a su papel en la redirección a otros entornos.

El orador destaca que la infraestructura se estableció rápidamente debido a los recursos limitados en JPEG, lo que dificultó la implementación de las mejores prácticas. A pesar de estos desafíos, la configuración se ha mantenido estable sin que se hayan reportado fallos significativos desde su inicio.

Surge una pregunta sobre el mantenimiento de las máquinas virtuales de Nginx, específicamente sobre cómo se gestionan las vulnerabilidades y las actualizaciones. El orador aclara que, si bien Google Cloud Platform (GCP) se encarga de los cambios de hardware, las actualizaciones de software, incluidas las correcciones de seguridad para el sistema operativo y la biblioteca Lua de Nginx, se gestionan internamente.

La conversación se desplaza al motor de pagos, que también utiliza Nginx para sus operaciones. El hablante señala que hay un balanceador de carga para el motor de pagos que dirige el tráfico a varios entornos, similar al Motor de Cuentas. El motor de pagos tiene dos tipos de certificados: uno para desarrollo y otro para producción, con reglas específicas para manejar solicitudes según incluyan o no un componente de App E-Commerce.

El ponente explica que el balanceador de carga de Google inicialmente carecía de la capacidad para reescribir rutas, lo que llevó a la implementación de reglas de enrutamiento personalizadas dentro de la configuración de Nginx. Esta personalización permite modificaciones específicas de la ruta cuando se realizan solicitudes a diferentes entornos, asegurando que ciertas solicitudes se dirijan adecuadamente, particularmente para la funcionalidad de la App E-Commerce.

La discusión destaca un detalle específico de configuración de Nginx respecto al PATH para los Cargos dirigidos a la Infra de Check. Se señala que esta es la única excepción, ya que todas las demás configuraciones conducen al mismo proyecto de GCP y GatePay. Es importante destacar que la configuración de Nginx no incluye una regla para Appy Commerce, lo cual es crucial para entender los requisitos de implementación.

El orador enfatiza la importancia de entender la configuración de Nginx, particularmente para las implementaciones de Appy Commerce. Es crucial que si se realizan cambios en Nginx, la configuración de Appy Commerce debe ser desplegada para asegurar que la regla de Cargos se aplique correctamente.

El orador proporciona una visión general de varios repositorios relacionados con motores de pago, incluyendo el Payacons Nginx, que también se utiliza para Flexident y la aplicación B4. Además, se menciona el motor COAS, nombrado en honor a Kunder OAuth, indicando su estado de archivo. Tanto los motores de pago como de cuentas se desarrollan utilizando JavaScript o TypeScript, mientras que el motor COAS está construido con Golang.

La discusión pasa a la infraestructura en la nube, señalando que todos los sistemas se implementan utilizando Cloud Functions o Cloud Run, sin involucrar Kubernetes. Esto simplifica el proceso de implementación, aunque mantener un Plan de Recuperación ante Desastres (DRP) con esta infraestructura sigue siendo una consideración. El orador aclara que se utilizan los mismos tres repositorios tanto para Check como para Betaflight, siendo este último actualmente solo utilizado por el motor de cuentas.

El orador se dirige a la infraestructura multi-región de Cloud Run, indicando que el motor de cuentas para Check experimenta un tráfico mínimo, promediando alrededor de una solicitud por segundo, mientras que Betaflight maneja más. Es crucial gestionar la configuración de URL personalizadas en Nginx para prevenir interrupciones, ya que algunos redireccionamientos apuntan directamente a estas URL. El orador menciona que se han añadido ciertas configuraciones, como las verificaciones de salud, para garantizar un manejo adecuado del tráfico.

Se discute la importancia de las verificaciones de salud, específicamente los mecanismos de prueba de estado y prueba de vivacidad. La prueba de estado indica cuándo un contenedor está listo para recibir tráfico, mientras que la prueba de vivacidad confirma que el motor está operativo. Estas verificaciones son vitales para prevenir problemas como los errores 502 y 504, que han ocurrido esporádicamente en Betaflight. El orador explica que GCP realiza la gestión interna de Cloud Run, lo que puede llevar a problemas de ingreso de tráfico si no se monitorea adecuadamente.

La discusión destaca la importancia de configurar Cloud Run para prevenir problemas como errores 502 o 504. Se enfatiza la necesidad de que los equipos implementen verificaciones de salud y creen puntos finales de prueba para asegurar un funcionamiento adecuado. El orador insiste en la necesidad de estas configuraciones, particularmente en Google Cloud Platform (GCP), para evitar problemas de tiempo de espera y mantener la fiabilidad del servicio.

El orador señala que algunos despliegues de Cloud Run datan de 2021 y fueron gestionados por personas que ya no están en la empresa. Se mencionan repositorios específicos relacionados con motores de cuentas, que pueden seguir utilizando protocolos obsoletos. Se recuerda un incidente pasado en el que se eliminó un endpoint, lo que llevó a fallos en el servicio, subrayando la necesidad de una gestión cuidadosa de estos servicios.

La conversación se centra en la gestión de proxies NGINX, enfatizando la importancia de mapear los servicios correctamente para evitar interrupciones. El orador advierte sobre la eliminación apresurada de configuraciones sin comprender sus implicaciones, particularmente en relación con los motores de pago, que están completamente integrados con Cloud Run en lugar de máquinas virtuales tradicionales.

El orador discute la razón detrás de implementar servicios en Cloud Run en lugar de máquinas virtuales, particularmente para la planificación de recuperación ante desastres (DRP). Explican que en caso de una falla, el tráfico puede ser redirigido a Cloud Run sin problemas, asegurando la continuidad de la operación. Aunque estos servicios nunca se utilizaron, no generan costos ya que no reciben tráfico.

El orador reflexiona sobre el estado de la infraestructura, señalando que, aunque los entornos de desarrollo y de pruebas están algo desorganizados, la producción es más ordenada. Aseguran que durante eventos de alto tráfico, como un Ciberday, la infraestructura está diseñada para escalar automáticamente. Además, las configuraciones de verificación de salud en GCP reiniciarán las instancias si las solicitudes fallan, minimizando la necesidad de intervención manual.