Cualquier tipo de aplicación de negocio necesita contar con elementos como servidores, redes y almacenamiento. Tradicionalmente, estos negocios tendían a construir data centers privados, lo cual afectaba directamente al CapEx dedicado a recursos físicos. Esto, además, conllevaba un incremento en el OpEx relativo a mantener esos activos así como en los equipos destinados a la supervisión de los mismos.
La nube pública elimina, a priori, esa necesidad de inversión en data centers y equipos de mantenimiento y permite a las empresas a centrarse en lo que realmente importa: su negocio.
Los principales proveedores de nube pública, como Google, Amazon Web Services o Microsoft, trabajan de forma continua en mejorar sus servicios y en añadir más a sus correspondientes portfolios allí donde están disponibles.
Regiones y zonas
Estos servicios cloud están generalmente disponibles en distintas localizaciones de Norte América, América del Sur, Europa, Asia y Australia. Estas localizaciones están divididas en regiones y zonas (los términos pueden variar entre proveedores). Los usuarios finales de la nube pública eligen dónde quieren crear y desplegar sus aplicaciones acorde a unos criterios de disponibilidad, latencia y fiabilidad.
Para entendernos mejor: las regiones son áreas geográficas independientes compuestas por varias zonas, y las zonas son áreas de despliegue para un recurso cloud dentro de esa región.
Cuando hablamos de requerimientos de negocio es común encontrar entre ellos elementos o términos como alta disponibilidad requerida, máxima eficiencia o acceso global.
Para poder cumplir todos estos requisitos y desplegar aplicaciones tolerantes a fallos, los usuarios de nube pública deberán tener en cuenta una arquitectura multi-zona que permita cumplir las expectativas de alta disponibilidad en el ámbito de una región. Además, si nuestra solución tuviera que alcanzar criterios de acceso global, las soluciones multi-regionales se hacen indispensables.
Diseñar y poner en funcionamiento arquitecturas multi-regionales puede ser un gran reto incluso si los ingenieros de nube pública basan el sistema final de forma completa en servicios cloud. Algunos términos como replicación, resiliencia o contingencias ante desastres, son condiciones difíciles de conseguir y, en muchas ocasiones, estas empresas acaban necesitando ejercicios equipos enteros de ingeniería para poder acometerlo.
¿Por qué debemos pensar en Serverless?
Serverless es un paso más allá en la dirección de no-operaciones. Esto no quiere decir que el software que nosotros desplegamos en la nube no conlleve una asiganción de recursos computacionales. En pocas palabras quiere decir que el proveedor cloud lo administra por nosotros.
Casi cualquier área de servicios de los proveedores cloud cuenta con opciones Serverless (bases de datos gestionadas, servicios de red, plataformas de integración continua, etc).
Concretamente, Google Cloud nos ofrece lo último en servicios Serverless que nos permitirán construir aplicaciones globales con confianza.
Solution Design
Vamos a diseñar una solución de una aplicación cuyos usuarios están físicamente localizados en tres grandes regiones: California (US), Alemania (EU), e India (Asia). Además, queremos tener requerimientos de mínima latencia para las aplicaciones y, en todo caso, deben estar disponibles incluso si una región completa de nube pública no responde.
Una VPC (Virtual Private Cloud) será la base de nuestro sistema. Estas VPCs son globales en Google Cloud, esto quiere decir que elementos de computación separados físicamente estarán mutuamente disponibles siempre y cuando compartan esta VPC global. Esta es una gran diferencia en la jerarquía de recursos y redes comparando con otros proveedores donde las VPCs suelen crearse en ámbitos de región.
Una única VPC de Google Cloud estará disponible en múltiples regiones sin necesidad de comunicaciones a través de Internet Público. En escenarios con recursos on-premise, esta misma VPC nos bastaría para conectar elementos en distintas regiones y no tenemos la necesidad de crear redes o conexiones ad-hoc en cada una de ellas.
Para desplegar nuestras aplicaciones hemos elegido GKE (Google Kubernetes Engine) como tecnología de computación. Gracias a GKE no sólo cubrimos requerimientos de replicación multi-zona y multi-región si no que llegamos también a requisitos de alta disponibilidad.
Por último, haremos uso también del Balanceador de Carga HTTP(S) que nos permitirá enrutar tráfico al recurso de computación más próximo gracias al Premium Network Tier.
Creando la VPC Global
Primero crearemos la VPC en Custom Mode con subred en cada región (us-west2, eu-west3 y asia-south1).
Importante que comprobemos cómo funcionan las reglas firewall en este escenario. Por defecto las Custom Mode VPC no crean ninguna regla específica más allá de un par de reglas implícitas.
Creando los Clusters GKE
Los clusters GKE pueden ser desplegados en configuración local o regional. En este caso necesitamos una duplicidad de recursos inter zonal por lo que el tipo de cluster tiene que ser de tipo regional. Con este setup indicado de 5 nodos por pool y cluster regional, crearemos un total de 15 nodos por cluster, 5 por zona.
Debemos habilitar la opción de Load Balancing en todos los clusters GKE para que los controladores de Ingress se añadan a cada cluster.
Creando un Balancerador de Carga HTTP(S)
El Balanceador de Carga Global HTTP(S) provee balanceamiento para peticiones HTTP(S) que se dirigen a nuestras instancias. Al ser un Balanceador de tipo Global es necesario hacer uso del acceso Premium de Red de Google Cloud Platform.
Este acceso Premium a nivel de red enruta tráfico directamente sobre la red de Google. Esta red está formada por una inmensa red de fibra óptica privada y más de 100 Puntos de Presencia alrededor del mundo.
Network Premium Tier
Con este tipo de acceso de red, las peticiones dirigidas a nuestros servidores entrarán en la red de Google en el Punto de Presencia más cercano.
HTTP(S) L7 Global Load Balancer
Con el Balanceador de Carga Global podemos establecer políticas de redirección a nivel de URL. Las peticiones irán siempre destinadas al grupo de instancias que se encuentre más cerca del usuario siempre y cuando ese grupo de instancias tenga capacidad suficiente para tratar la petición. Si ese grupo más cercano no cumple el requerimiento de capacidad establecido, la petición viajará al siguiente grupo de instancias por proximidad y capacidad.
Llegados a este punto, hemos creado la VPC y las subredes necesarias para establecer la base de nuestros despliegues de infraestructura. Además, hemos creado clusters de ámbito regional en las tres regiones de alcance. Hemos comprobado el nivel de acceso necesario y configurado un Balanceador de Carga HTTP(S) a nivel global.
En este contexto, los backends services necesarios para un Balanceador de Carga de GCP son equiparables a servicios de Kubernetes. Estos servicios son abstractos y apuntan a entidades denominadas Pods que corren nuestras aplicaciones en cada cluster. Además, estos servicios deben tener una configuración de tipo NodePort y exponer en el mismo puerto para cada cluster.
Finalmente, con esta configuración nuestro Balanceador de Carga Global HTTP(S) tendrá la capacidad de según la ruta, proximidad y capacidad dirigir nuestras peticiones a un cluster o a otro.
Paso Extra 1 – Cloud CDN y buckets como servicios
El Balanceador de Carga nos permite no solo crear backends como grupos de instancias (o clusters en este contexto) si no que podemos definir rutas a nivel de configuración que apunten directamente a un Bucket de almacenamiento de archivos binarios.
Paso Extra 2 – Protegiendo la infraestructura de ataques maliciosos DDoS
El servicio Cloud Armor nos provee de una defensa contra ataques de tipo de Denegación de Servicio (DDoS) haciendo uso de la infraestructura global de Google Cloud.
Con Cloud Armor, podemos definir una lista de valores de IPs la cual queremos bloquear y defendernos a nivel de red. Gracias a este servicio nuestra estructura final nunca será alcanzada desde estas fuentes externas de ataques maliciosos.
—–
En este artículo hemos repasado cómo, de una manera sencilla, podemos crear redes globales y desplegar infraestructura a nivel regional y global en la nube pública de Google. Además, gracias al acceso de red Premium y el Balanceador de Carga HTTP(S) podemos construir aplicaciones globales, replicadas y de alta disponibilidad haciendo uso de servicios Serverless.
¿Interesado/a en Google Cloud? Atento/a a nuevos posts en el blog de Keepler porque seguiremos compartiendo artículos muy interesantes sobre GCP.
Referencias:
Imagen: unsplash | @topfivebuzztravelmagazine
Deja un comentario