Prácticas recomendadas para la selección de regiones de Compute Engine

En este artículo, se describen los criterios que se deben tener en cuenta a la hora de elegir qué regiones de Google Cloud usar para los recursos de Compute Engine, una decisión que suelen tomar los arquitectos de nube o la administración de ingeniería. El enfoque principal de este documento es el aspecto de la latencia del proceso de selección y está destinado a las apps a las que acceden los consumidores, como apps y juegos web o móviles, pero varios de los conceptos se pueden aplicar a otros casos prácticos.

Google ofrece regiones múltiples por todo el mundo para que implementes tus recursos de Compute Engine. Varios factores cumplen una función en la elección de sus regiones:

  • Restricciones específicas de la región
  • Latencia del usuario por región
  • Requisitos de la latencia de tu app
  • Cantidad de control sobre la latencia
  • Equilibrio entre latencia baja y simplicidad

Terminología

región
Un área geográfica independiente donde puedes ejecutar tus recursos. Cada región consta de zonas, en general, de al menos tres zonas.
zona
Un área de implementación para los recursos de Google Cloud dentro de una región. Ubicar recursos en diferentes zonas de una región reduce el riesgo de interrupciones en la infraestructura que afectan a todos los recursos de forma simultánea.
recursos de Compute Engine
Los recursos en Compute Engine, como las instancias de máquina virtual, se implementan en una zona dentro de una región. Otros productos, como Google Kubernetes Engine y Dataflow, usan recursos de Compute Engine y, por lo tanto, se pueden implementar en las mismas regiones o zonas.
tiempo de ida y vuelta (RTT)
El tiempo que lleva enviar un paquete de IP y recibir la confirmación de recepción.

Cuándo elegir tus regiones de Compute Engine

Al inicio de una fase de arquitectura de una app, decide cuántas regiones de Compute Engine usarás y cuáles serán. Tu elección puede afectar a la app, por ejemplo:

  • La arquitectura de tu app puede cambiar si sincronizas algunos datos entre copias debido a que los mismos usuarios se pueden conectar a través de regiones diferentes en momentos diferentes.
  • Los precios difieren por región.
  • El proceso de mover una app y sus datos entre regiones es complicado y, en ocasiones, costoso, por eso es mejor evitarlo una vez que la app está activa.

Factores que debes considerar cuando selecciones las regiones

Es común que las personas implementen en una región donde están ubicadas, pero deben considerar si esa es la mejor experiencia del usuario. Supongamos que estás en Europa con una base de usuarios global y quieres implementar en una sola región. La mayoría de las personas considerarían implementar en una región de Europa, pero en general la mejor opción es tener la app alojada en una de las regiones de EE.UU. debido a que EE.UU. está más conectado a otras regiones.

Muchos factores afectan al lugar en el que decides implementar tu app.

Latencia

El factor principal que debes considerar es la latencia que experimenta tu usuario. Sin embargo, este es un problema complejo debido a que la latencia se ve afectada por muchos aspectos, como mecanismos de balanceo de cargas y de almacenamiento en caché.

En casos prácticos empresariales, la latencia en sistemas locales o la latencia para un cierto subconjunto de usuarios o socios es más importante. Por ejemplo, elegir la región más cercana a los desarrolladores o a los servicios de bases de datos locales interconectados con Google Cloud podría ser un factor decisivo.

Precios

Los costos de los recursos de Google Cloud varían según la región. Los siguientes recursos están disponibles para estimar el precio:

Si decides implementar en regiones múltiples, ten en cuenta que existen cargos de transferencia de datos para datos sincronizados entre regiones.

Colocación con otros servicios de Google Cloud

Coloca tus recursos de Compute Engine con otros servicios de Google Cloud, siempre que sea posible. Si bien la mayoría de los servicios sensibles a la latencia están disponibles en cada región, algunos servicios están disponibles solo en ubicaciones específicas.

Disponibilidad de tipo de máquina

No todas las plataformas de CPU ni todos los tipos de máquinas están disponibles en todas las regiones. La disponibilidad de plataformas de CPU específicas o los tipos de instancias específicas difieren según la región y la zona. Si quieres implementar recursos mediante ciertos tipos de máquinas, obtén más información en disponibilidad zonal de esos recursos.

Cuotas de recursos

Tu capacidad para implementar recursos de Compute Engine está limitada por cuotas de recursos regionales, así que asegúrate de solicitar una cuota suficiente para las regiones en las que planeas implementar. Si planeas una implementación muy grande, pide asesoramiento al equipo de ventas antes a fin de discutir tus elecciones de selección de región para asegurarte de que tienes una capacidad de cuota suficiente.

Porcentaje de energía sin emisiones de carbono

Para potenciar cada región de Google Cloud, Google usa electricidad de la cuadrícula donde se encuentra la región. Esta electricidad genera más o menos emisiones de carbono, según el tipo de plantas de energía que generan electricidad para esa red y cuando Google la consume. Google estableció recientemente el objetivo de que para el año 2030 usaremos electricidad sin emisiones de carbono a fin de que tus aplicaciones puedan funcionar las 24 horas del día, en cualquier lugar de todas las regiones de Google Cloud.

Hasta que ese objetivo se alcance, cada región de Google Cloud se proporcionará mediante una combinación de fuentes de energía sin emisiones de carbono y sin emisiones de carbono cada hora. Esta métrica se conoce como el porcentaje de energía sin emisiones de carbono (CFE%) y publicamos CFE% para las regiones de Google Cloud. En las aplicaciones nuevas de Google Cloud, puedes usar esta tabla para comenzar a incorporar la huella de carbono en tus decisiones de arquitectura. La elección de una región con un CFE más alto significa que, en promedio, la aplicación funcionará con energía sin emisiones de carbono un porcentaje elevado de horas de lo que se ejecuta, lo que reduce las emisiones de carbono brutas de esa aplicación.

Evalúa los requisitos de latencia

La latencia es, en general, la consideración clave para la selección de la región debido a que la latencia alta de usuario puede llevar a una experiencia del usuario inferior. Puedes afectar a algunos aspectos de la latencia, pero otros están fuera de tu control.

Cuando se realiza una optimización de la latencia, muchos arquitectos de sistema consideran solo la latencia de red o la distancia entre el ISP del usuario y la instancia de máquina virtual. Sin embargo, ese solo es uno de los numerosos factores que afectan la latencia del usuario, como puedes ver en el siguiente diagrama.

Evalúa la latencia en la selección de la región de Compute Engine

Como arquitecto de apps, puedes optimizar la selección de la región y la latencia de la app, pero no puedes tener control sobre la última latencia y milla del usuario en los Puntos de presencia (POP) más cercanos a Google.

La selección de la región solo puede afectar la latencia de la región de Compute Engine y no la totalidad de la latencia. Según el caso práctico, esto podría ser solo una pequeña parte de la latencia total. Por ejemplo, si tus usuarios usan redes de celulares como opción principal, podría no ser útil tratar de optimizar tus regiones, debido a que eso no afecta a la latencia de usuario total.

Latencia de la última milla

La latencia de este segmento varía según la tecnología que se usa para acceder a Internet. Por ejemplo, la latencia típica para llegar a un ISP es de 1 a 10 ms en las redes modernas. Por el contrario, las latencias típicas en una red móvil 3G son de 100 a 500 ms. El rango de latencia para los proveedores de DSL y de cable es de alrededor de 10 a 60 ms.

Latencia POP perimetral y frontend de Google

Según tu modelo de implementación, la latencia para la red perimetral de Google también es importante. Ahí es adonde los productos de balanceo de cargas globales finalizan las sesiones de SSL y TCP y desde donde Cloud CDN entrega los resultados en caché. Según el contenido entregado, algunos de los viajes de ida y vuelta pueden terminar aquí debido a que se necesita recuperar solo parte de los datos de manera completa. Esta latencia puede ser mayor si usas el nivel de servicio de red estándar.

Latencia de la región de Compute Engine

La solicitud del usuario ingresa a la red de Google en el POP perimetral. La región de Compute Engine es donde se encuentran los recursos de Google Cloud que controlan las solicitudes. Este segmento es la latencia entre la región de Compute Engine y el POP perimetral, y se encuentra por completo dentro de la red global de Google.

Latencia de la app

Esta es la latencia de la app que responde a las solicitudes, incluido el tiempo que necesita la app para procesar la solicitud.

Las diferentes apps tienen requisitos de latencia diferentes. Según la app, los usuarios son más tolerantes con los problemas de latencia. Las apps que interactúan de manera asíncrona o las apps para dispositivos móviles con un umbral de latencia alto (100 milisegundos o más) se pueden implementar en una sola región sin comprometer la experiencia del usuario. Sin embargo, para apps como juegos en tiempo real, unos milisegundos de latencia pueden causar un gran efecto en la experiencia del usuario. Implementa este tipo de apps en regiones múltiples cerca de los usuarios.

Patrones de implementación global

En esta sección, se explica cómo varios modelos de implementación afectan a los factores de la latencia.

Implementación de una sola región

En la imagen siguiente, se ilustra una implementación de una sola región.

Latencia de una implementación de frontend sola

Incluso si la app entrega a una base de usuarios global, en muchos casos, una sola región es la mejor opción. Los beneficios de una latencia baja pueden no superar la complejidad agregada de una implementación multirregional. Incluso con una implementación de una sola región, puedes usar optimizaciones, como balanceo de cargas global y de Cloud CDN para reducir la latencia del usuario. Puedes elegir usar una segunda región como copia de seguridad y por razones de recuperación ante desastres, pero eso no afecta a la ruta de entrega de la app y, por lo tanto, no afectará a la latencia del usuario.

Frontend distribuido en varias regiones y backend en una sola región

En el siguiente diagrama, se muestra un modelo de implementación en el que se distribuye el frontend en varias regiones, pero se limita el backend a una sola región. Con este modelo, obtienes el beneficio de una latencia más baja en los servidores frontend sin tener que sincronizar datos en varias regiones.

Latencia de una implementación de frontend distribuido

Este modelo de implementación proporciona una latencia baja del usuario en situaciones en las que la solicitud promedio del usuario no implique solicitudes de datos o solo implique algunas solicitudes de datos al backend central antes de que la app pueda producir un resultado. Un ejemplo es una aplicación que implementa una capa de almacenamiento en caché inteligente en el frontend o que administra las operaciones de escritura de datos de manera asíncrona. Una app que realiza muchas solicitudes que requieren una ida y vuelta completa al backend puede no beneficiarse de este modelo.

Frontend y backend distribuidos en regiones múltiples

Un modelo de implementación en el que distribuyes el frontend y el backend en regiones múltiples te permite minimizar la latencia del usuario debido a que la app puede responder cualquier solicitud de manera local en su totalidad. Sin embargo, este modelo viene con una complejidad agregada debido a que todos los datos necesitan almacenarse y estar disponibles de manera local. Para responder a todas las solicitudes del usuario, los datos tienen que replicarse por completo en todas las regiones.

Latencia de una implementación múltiple distribuida

Spanner, la oferta de base de datos administrada con coherencia global, tiene una opción multirregional de tres continentes, en la que, además de réplicas de lectura y escritura en EE.UU., tiene dos réplicas de lectura en Europa y Asia. Esta opción proporciona un acceso de lectura de latencia baja a los datos para calcular las instancias ubicadas en EE.UU., Europa o Asia. Si tu servicio está orientado a EE.UU., hay una opción de regiones múltiples con replicación en ese país.

Si ejecutas tu propio servicio de base de datos en Compute Engine, debes replicar los datos tú mismo. Esta replicación es una tarea importante, ya que es difícil mantener la sincronización de los datos de forma coherente en todo el mundo. Puede ser más fácil de administrar si la base de datos se escribe en una sola región con escrituras asíncronas y si las demás regiones alojan réplicas de solo lectura de la base de datos.

Replicar bases de datos en varias regiones es difícil por eso recomendamos la participación de un socio con experiencia en esta área, como Datastax para la replicación de Cassandra.

Múltiples apps paralelas

Según la naturaleza de la app, con una variación del enfoque anterior, puedes conservar la latencia baja de usuario y reducir la necesidad de replicación de datos constante. Como se ilustra en la siguiente imagen, hay varias apps paralelas compuestas por un frontend y un backend, y los usuarios se dirigen a la app correcta. Solo se comparte una pequeña fracción de los datos entre los sitios.

Latencia de apps paralelas

Por ejemplo, si tienes un negocio de venta minorista puedes entregar a usuarios en regiones diferentes a través de dominios de países diferentes y ejecutar sitios paralelos en todas esas regiones, solo con la sincronización de datos del usuario y del producto cuando sea necesario. Los sitios locales mantienen la disponibilidad de stock local y los usuarios se conectan a un sitio alojado de manera local a través de la selección de un dominio de país. Cuando un usuario visita un dominio de país diferente, se lo redirecciona al dominio correcto.

Otro ejemplo son los juegos en tiempo real. Puedes tener solo un servicio de vestíbulo global en el que los usuarios elijan una sala de juegos o un mundo cercano a su ubicación y esas salas o mundos no compartan datos entre sí.

Un tercer ejemplo ofrece un software como servicio (SaaS) en regiones diferentes, en las que la ubicación de datos se selecciona en la creación de la cuenta y se basa en la ubicación del usuario o en su elección. Después de acceder, se redirecciona al usuario a un subdominio específico de ubicación y usa el servicio de manera regional.

Optimiza la latencia entre usuarios y regiones

Sin importar tu modelo de implementación, puedes combinar métodos de optimización para reducir la latencia visible del usuario final. Algunos de estos métodos son características de Google Cloud, mientras que otros requieren que cambies la app.

Usa herramientas de redes de nivel Premium

Google ofrece niveles de servicio de red Premium (predeterminado) y estándar. El tráfico del nivel Estándar se entrega mediante ISP de tránsito de regiones de Google Cloud, mientras que el nivel Premium ofrece una latencia más baja debido a que entrega el tráfico a través de la red privada global de Google. La herramienta de redes de nivel Premium reduce la latencia del usuario y debería usarse para todas las partes de la app en la ruta de entrega. La herramienta de redes de nivel Premium también es necesaria para usar productos de balanceo de cargas global de Google.

Usa Cloud Load Balancing y Cloud CDN

Cloud Load Balancing, como balanceador de cargas HTTP(S), balanceador de cargas TCP y proxy SSL, te permiten redireccionar de manera automática a los usuarios a la región más cercana en la que hay backends con capacidad disponible.

Incluso si tu app está en una sola región, usar Cloud Load Balancing proporciona una latencia de usuario más baja debido a que las sesiones de TCP y SSL se finalizan en el perímetro de la red. Finaliza con facilidad el tráfico de usuario con HTTP/2 y conexiones UDP rápidas en Internet (QUIC). También puedes integrar Cloud CDN en el balanceador de cargas de HTTP(S) para entregar elementos estáticos directamente desde el perímetro de la red, lo que reduce en mayor medida la latencia del usuario.

Almacenamiento en caché de manera local

Si tus ubicaciones de frontend son diferentes de tus ubicaciones de backend, asegúrate de almacenar en caché las respuestas de los servicios de backend cuando sea posible. Si el frontend y el backend están en la misma región, la latencia de la app se reduce debido a que las consultas que consumen mucho tiempo también se reducen. Puedes usar Memorystore para Redis, un almacén de datos en memoria completamente administrado.

Optimiza el cliente de la app o el frontend web

Puedes usar técnicas del lado del cliente, como una app para dispositivo móvil o un frontend web a fin de optimizar la latencia del usuario. Por ejemplo, precarga algunos elementos o datos almacenados en caché dentro de la app.

También puedes optimizar la manera en que tu app obtiene información mediante la reducción de la cantidad de solicitudes y la recuperación de información en paralelo, cuando sea posible.

Mide la latencia del usuario

Una vez que establezcas un modelo de referencia de tus requisitos de latencia, consulta tu base de usuarios para decidir la mejor ubicación de tus recursos de Google Cloud. Se emplean estrategias diferentes si la app es nueva o si ya existía.

Usa las siguientes estrategias para medir la latencia de los socios a los que accedes durante la entrega de la app o la latencia de tu red local que podría estar interconectada a tu proyecto de Google Cloud mediante Cloud VPN o una interconexión dedicada.

Realiza una estimación de la latencia para cargas de trabajo nuevas

Si no tienes una app existente con una base de usuarios similar a la nueva, calcula la latencia de varias regiones de Google Cloud según la distribución de la ubicación aproximada de la base de usuarios esperada.

Calcula 1 ms de latencia de ida y vuelta por cada 100 km recorridos. Debido a que las redes no siguen una ruta ideal desde el origen hasta el destino, por lo general, puedes adivinar que la distancia real es alrededor de 1.5 a 2 veces la distancia que se mide en un mapa. Por supuesto, en algunas regiones con menos densidad de población, las redes podrían seguir una ruta aún menos ideal. La latencia agregada a través de equipos activos dentro de las redes ISP no es en general importante cuando se tienen en cuenta las distancias interregionales.

Estas cantidades te pueden ayudar a estimar la latencia del perímetro POP y los nodos de Cloud CDN, como también de las regiones de Compute Engine por todo el mundo que se muestran en el mapa de red.

Mide la latencia de usuarios existentes

Si ya tienes una app con una base de usuarios similar, existen varias herramientas que puedes usar para estimar mejor las latencias.

  • Usuarios representantes: Si tiene usuarios o socios, que representan una sección transversal de tus distribuciones geográficas y que quieren a trabajar contigo o con empleados en esos países, pídeles que midan la latencia de varias regiones de Google Cloud. Los sitios web de terceros, como ping de Google Cloud, pueden ayudarte a obtener algunas medidas.
  • Registros de acceso: Si tienes una app activa alojada fuera de Google Cloud, usa los datos de los registros de acceso para obtener una sección transversal aproximada de los usuarios. Tus registros pueden proporcionar información sobre la ciudad o el país, lo que también te permite estimar latencias.
  • Dirección IP: Si tienes acceso a las direcciones IP de tus usuarios, crea secuencias de comandos para probar la accesibilidad y las latencias de varias regiones de Google Cloud. Si el firewall bloquea tus pruebas, trata de aleatorizar el último octeto de IP para obtener una respuesta de otro dispositivo con una latencia similar a la de tu app.

  • Información de latencia de Google Cloud: Si tienes una app existente en Google Cloud, hay varias formas de recopilar información de latencia.

Conectividad global

Cuando estimas la latencia, ten en cuenta la topología de la red global de Google.

  • POP: lugar por donde el tráfico de usuario ingresa a la red.
  • Nodos de Cloud CDN: lugar en donde el tráfico es almacenado en caché.
  • Regiones: lugar donde se pueden ubicar tus recursos.
  • Conectividad: entre POP y las regiones.

Encuentra una lista de ubicaciones donde Google se interconecta con otras ISP en PeeringDB.

Asegúrate de que tienes en cuenta la topología interregional cuando decides en qué regiones implementarás. Por ejemplo, si quieres implementar una app con una base de usuarios global en una sola región, es mejor tener esta app alojada en una de las regiones de EE.UU., debido a que EE.UU. está conectado a la mayoría de las otras regiones. Aunque hay conectividad directa entre varios continentes, existen casos en los que se pierde, como entre Europa y Asia, lo que quiere decir que el tráfico entre Europa y Asia fluye a través de EE.UU.

Si tu app está alojada en varias regiones y necesitas sincronizar los datos, ten en cuenta la latencia entre esas regiones. Aunque esta latencia pueda cambiar en el tiempo, en general es estable. Puedes medir la latencia tú mismo mediante la prueba de instancias en todas las regiones posibles o usa sitios web de terceros para obtener una idea de las latencias actuales entre las regiones.

Combina todas las opciones

Ahora que ya tuviste en cuenta los requisitos de la latencia, los modelos de implementación posibles y la distribución geográfica de tu base de usuarios, puedes entender cómo estos factores afectan la latencia en ciertas regiones. Es momento de decidir en qué regiones iniciar tu app.

Aunque no hay una manera correcta de considerar los diferentes factores, la metodología paso a paso siguiente puede ayudarte a decidir:

  1. Verifica si hay factores no relacionados con la latencia que te bloquean la implementación en regiones específicas, como precios o colocación. Quítalos de tu lista de regiones.
  2. Elige un modelo de implementación según los requisitos de latencia y la arquitectura general de la app. En la mayoría de las apps para dispositivos móviles y en otras no relacionadas con la latencia, una implementación de una sola región con entrega de contenido almacenado en caché de Cloud CDN y cancelación de SSL en el perímetro puede ser la mejor opción.

  3. Según tu modelo de implementación, elige regiones basadas en la distribución geográfica de la base de usuarios y las mediciones de la latencia:

    • Para una implementación de una sola región:

      • Si necesitas acceso de latencia baja a tus instalaciones corporativas, implementa en la región más cercana a esa ubicación.
      • Si tus usuarios son principalmente de un país o una región específica, implementa en una región cercana a los usuarios típicos.
      • Para una base de usuarios global, implementa en una región de EE.UU.

    • Para una implementación multirregión:

      • Elige regiones cercanas a los usuarios según su distribución geográfica y el requisito de latencia de la app. Según tu app, optimiza para una latencia mediana específica o asegúrate de que al 95-99% de los usuarios se les entregue con una latencia de destino específica. Los usuarios en ciertas ubicaciones geográficas suelen tener una tolerancia mayor que la latencia debido a sus limitaciones de infraestructura.

  4. Si la latencia de usuario es similar en muchas regiones, el precio es el factor decisivo.

Cuando seleccionas las regiones de Compute Engine, la latencia es uno de los factores más importantes a considerar. Evalúa y mide los requisitos de la latencia para entregar una experiencia del usuario de calidad y repite el proceso si la distribución geográfica de tu base de usuarios cambia.

¿Qué sigue?