Proyectos de Infraestructura: Perspectivas Clave sobre Mejores Acciones, Gamificación y Más

El orador discute los proyectos clave en los que ha estado involucrado, enfatizando la importancia de Insight y la necesidad de una transición fluida. Destacan la importancia de Better Actions y Gamification como los proyectos principales que requieren atención debido a sus extensas demandas de infraestructura y niveles de estrés.

Better Actions está experimentando actualmente un alto tráfico, con algunos componentes manejando hasta 8 solicitudes por segundo. Esto requiere una cuidadosa consideración de las estrategias de implementación, como las implementaciones Canary, para gestionar la naturaleza crítica de los cambios en este proyecto.

La gamificación, aunque tiene un tráfico ligeramente menor que Better Actions, aún requiere atención debido a sus conexiones de base de datos. De manera similar, el proyecto de Causas y Donaciones también implica interacciones con bases de datos, lo que hace esencial gestionar estas conexiones de manera efectiva a pesar de los niveles de tráfico más bajos.

El orador señala que los proyectos discutidos representan aproximadamente el 90% de la infraestructura delineada en la plantilla GCP proporcionada. Enfatizan la importancia de comprender la configuración de la infraestructura, incluyendo el bucket de estado, el dominio para certificados y los pasos de implementación, que son cruciales para replicar la infraestructura en los proyectos.

El orador menciona que la plantilla de GCP actualizada es fundamental para todos los proyectos, con un enfoque en la simplicidad y claridad en el despliegue. Destacan la presencia de un balanceador de carga, Cloud Armor para producción y Cloud Run como componentes integrales de la infraestructura, asegurando que todo el tráfico de internet se gestione adecuadamente.

Cada proyecto tiene su propia conexión a internet, independiente del proyecto de la Plataforma, que sirve meramente como un punto de encuentro para estos proyectos. Alrededor del 10% de los proyectos no dependen completamente de esta infraestructura, utilizando bases de datos alternativas como ATO, SQL o Postgres, siendo WAPSAR la única excepción.

El módulo de Cloud Armor, recientemente añadido, fue desarrollado para mejorar la seguridad. Ha sido probado con los equipos de Playhouse y Autenticación, sin mostrar más problemas. Las preocupaciones anteriores incluían inyecciones SQL y problemas con el contenido del cuerpo, que se resolvieron con modificaciones menores. Este módulo WAF está destinado para uso en producción, y su efectividad será evaluada en otros entornos.

El módulo Audilux, también disponible en GitHub, crea un conjunto de datos en BigQuery llamado Audilux. Permite la sección Audilux de GCP, modifica la Configuración Predeterminada y añade capacidades de Escritura de Datos. Esto asegura que los cambios en GCP se registren en Stackdriver, preservando los datos más allá del período de retención predeterminado de 30 días. El módulo es crucial para entornos de producción para rastrear cambios en GCP.

Todos los proyectos basados en la misma plantilla utilizan la misma configuración, incluido el módulo WAF. El WAF es fácil de usar, requiriendo solo el nombre del WAF existente y ajustes en los servicios de backend. La configuración incluye cuatro reglas: una para permitir solicitudes y tres específicas para Cloud Armor, que deben ser probadas y ajustadas según la sensibilidad para garantizar un funcionamiento adecuado.

En cuanto a Cloud Run, se aclaró que el 99% de los proyectos no están en BPC, con la excepción del proyecto Marketplace, que se estableció en BPC debido a que un proveedor requería una dirección IP saliente específica para la lista blanca. Se configuró un bastión para facilitar esta conexión.

La discusión comienza con la necesidad de conectar Cloud Run a una VPC (Nube Privada Virtual) para proyectos como Hackmetrics. Esta conexión requiere un recurso específico, un conector para los salones, que opera máquinas virtuales gestionadas por Google. El orador señala que este es el único proyecto que utiliza una VPC a nivel de Cloud Run, aunque luego se corrige para incluir proyectos con instancias de bases de datos, mencionando específicamente Gamificación y Causas, que también requieren una VPC debido a sus conexiones de base de datos.

La conversación se centra en las bases de datos SQL utilizadas en la Gamificación, que también requieren una VPC para sus conexiones. El hablante explica que todos los proyectos con conexiones a bases de datos o requisitos específicos de VPC, como Marketplace, tienen un bastión que generalmente se mantiene apagado para ahorrar costos, programado para operar de 8 AM a 7 PM.

El orador menciona la infraestructura Serverless (SLS) para el Marketplace, destacando la necesidad de dos VPCs: una normal y una con un conector, para fines de prueba. Sin embargo, parece que la infraestructura ya no está en uso activo, ya que ha sido configurada pero no utilizada más.

Surge una pregunta sobre si los proyectos que se conectan a la base de datos utilizan algún proxy o agrupamiento de conexiones, específicamente en relación con Cloud Run. El hablante reconoce que se utiliza un conector a nivel de código para gestionar las conexiones, pero no está seguro de si Google proporciona un proxy para bases de datos SQL para manejar el agrupamiento de conexiones.

El hablante expresa incertidumbre sobre la existencia de un proxy de agrupamiento de conexiones para las bases de datos SQL de Google Cloud Platform, señalando que rara vez han utilizado bases de datos en sus proyectos. Mencionan que, por lo general, solo se utiliza el conector y la red asociada, sin ninguna funcionalidad adicional como la que se encuentra en el RDS Proxy de AWS.

La discusión se centra en Alloy DB, que parece estar disponible para gestionar conexiones en un entorno sin servidor. El orador señala que es una adición reciente y actualmente está en Disponibilidad General (GA). Exploran la opción de crear un clúster en Alloy DB, lo que debería permitir la gestión de conexiones.

La conversación incluye preguntas sobre los costos mensuales asociados con su base de datos actual. El hablante estima que el costo es de alrededor de $50 por mes para una configuración con 2 CPUs y 8 GB de memoria. También mencionan un mes anterior en el que los costos fueron significativamente más altos, alrededor de $400, para una instancia de producción, indicando que los gastos pueden variar mucho dependiendo del uso.

El hablante reflexiona sobre el uso de dos instancias en su configuración, cuestionando la necesidad de la segunda instancia, que tiene menos tráfico pero aún genera consultas. Expresan interés en comprender las razones detrás de su uso, sugiriendo que se justifica una investigación más profunda sobre el rendimiento y la necesidad de la instancia.

La discusión comienza con preocupaciones sobre la escalabilidad de la base de datos, particularmente en lo que respecta a la separación de las consultas de lectura y escritura. Se señala que solo el proyecto de Gamificación tiene dos instancias, mientras que otros operan en una sola instancia, lo que genera preocupaciones sobre cómo esta configuración manejará una carga aumentada. El orador recuerda que durante las migraciones, el proceso fue manual, lo que indica la necesidad de priorizar la mejora de la gestión de la base de datos.

La conversación se centra en la gestión de actualizaciones, destacando que se produjo un reinicio forzado durante una actualización significativa, en contraste con las actualizaciones menores que no causan tiempo de inactividad. El hablante compara esto con las prácticas de AWS, donde se implementa un cambio por fallo para evitar el tiempo de inactividad durante las actualizaciones, sugiriendo que este método debería ser documentado para pruebas futuras.

El orador identifica proyectos críticos, enfatizando el proyecto global mencionado por Felipe, que se dirige a dominios más pequeños, y el proyecto de fachada que actúa como un intermediario entre GCP y Amazon. Hay incertidumbre sobre la longevidad del proyecto de fachada, con indicios de que podría ser descontinuado, lo que podría afectar las comunicaciones entre los servicios en la nube.

Al discutir el proyecto de la fachada, el orador busca claridad sobre las rutas que se envían como proxy. Se explica que la fachada opera a nivel del balanceador de carga, dirigiendo el tráfico a la aplicación. Se destaca la necesidad de monitorear los registros, especialmente ya que se espera que el sistema central sea desmantelado pronto, lo que requiere entender las solicitudes que se le están haciendo.

La conversación profundiza en los detalles de las solicitudes de API, particularmente si las comunicaciones están dirigidas hacia Django u otras URL. El hablante confirma que se están realizando solicitudes a core.gobetterflight.com y api.gobetterflight.com, pero hay incertidumbre sobre la visibilidad de las solicitudes salientes desde la fachada, lo que indica la necesidad de una mayor investigación sobre el flujo de tráfico.

La discusión concluye con una verificación de los servicios en uso, confirmando que todas las interacciones son basadas en API. El hablante expresa satisfacción con la configuración actual, señalando que está bien informado sobre los servicios que se están utilizando, aunque se menciona un nuevo servicio web que le resulta desconocido, lo que indica desarrollos en curso en el panorama del proyecto.

El proyecto de la Plataforma sirve como un punto de encuentro crítico para todos los dominios. Hay preocupaciones sobre el uso de Terraform, que parece haber sido utilizado solo hasta principios de año. El orador ha intentado actualizar Terraform de forma independiente, con el objetivo de organizar la infraestructura, pero ha tenido dificultades para encontrar el tiempo para completar esta tarea. Enfatizan la necesidad de versionar las numerosas rutas asociadas con el proyecto, señalando que muchas rutas no están documentadas en el sistema actual.

El proyecto de Autenticación es crucial ya que gestiona los procesos de inicio de sesión, incluyendo un camino hacia la interfaz de inicio de sesión. Cuenta con una Aplicación Web Progresiva (PWA) o página web que permite el registro de usuarios, potencialmente vinculada a una Red de Entrega de Contenidos (CDN). El orador destaca la importancia de este proyecto debido a su manejo de registros de autenticación, incluyendo registros y accesos sin contraseña, y menciona la necesidad de métricas relacionadas con las sesiones de usuario.

El orador discute las prácticas estándar para CloudRamp, que incluyen mantener una versión pública y una interna. La CloudRamp pública generalmente maneja todas las solicitudes GET, mientras que la versión interna gestiona las solicitudes POST, PUT, PATCH y DELETE. Esta separación tiene como objetivo optimizar la gestión del tráfico y mantener una estructura clara dentro del repositorio, que es un monorepo que contiene bibliotecas de dominio. El orador señala que este estándar se ha mantenido de manera consistente, asegurando claridad en el despliegue de la infraestructura.

A medida que la reunión se acerca a su fin, el orador expresa el deseo de discutir algunos aspectos de codificación, pero sugiere programar otra sesión para abordar estos temas en detalle. Indican que hay asuntos importantes relacionados con el código que deben tratarse, enfatizando la necesidad de una discusión adicional.