Recomendaciones para seleccionar la región de Compute Engine

En este artículo, se describen los criterios que debes considerar cuando eliges qué regiones de Google Cloud Platform (GCP) usar para tus 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. Las ubicaciones dentro de las regiones suelen tener latencias de red de ida y vuelta de <1 ms en el percentil 95.
zona
Un área de implementación para recursos de GCP dentro de una región. Las zonas están diseñadas para ser independientes una de otras: los planos de control, herramientas de redes, enfriamiento y energía están aislados de otras zonas. Los eventos de falla únicos afectan a una zona sola.
recursos de Compute Engine
Los recursos en Compute Engine, como instancias de máquina virtual, se implementan en una zona dentro de una región. Otros productos, como Google Kubernetes Engine y Cloud 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 IP y recibir la confirmació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 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 fundamental. Por ejemplo, elegir la región más cercana a tus desarrolladores o a los servicios de base de datos locales interconectados con GCP puede ser el factor determinante.

Precios

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

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

Colocación con otros servicios de GCP

Coloca tus recursos de Compute Engine con otros servicios de GCP, 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.

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 es uno de los numerosos factores que afectan la latencia del usuario, como puedes ver en el diagrama siguiente.

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, si un usuario está conectado a Internet mediante una computadora de escritorio con fibra, la latencia típica para alcanzar el ISP es 1-10 ms. Por el contrario, las latencias típicas en una red de celular 3G son 100-500 ms. El rango de la latencia para proveedores de cable y DLS es en general de 10-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 por POP perimetral. La región de Compute Engine es donde se ubican los recursos de GCP que controlan las solicitudes. Este segmento es la latencia entre la región de Compute Engine y 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 tu 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 y backend distribuidos en una sola región

En el diagrama siguiente, se muestra un modelo de implementación en el que distribuyes el frontend y el backend en una sola región. Este modelo permite que te beneficies con una latencia menor en los servidores de frontend sin tener que sincronizar datos en regiones múltiples.

Latencia de una implementación de frontend distribuido

Sin embargo, la latencia del usuario disminuye en implementaciones de backend de una sola región si la solicitud del usuario promedio requiere solicitudes sin datos o solicitudes con pocos datos al backend central hasta que la app da un resultado. Por ejemplo, implementa una capa de almacenamiento en caché inteligente en el frontend o controla escrituras de datos de manera asíncrona.

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 con totalidad en todas las regiones.

Latencia de una implementación múltiple distribuida

Cloud 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. La replicación es una tarea importante debido a que mantener los datos sincronizados de manera consistente en todo el mundo es muy difícil. 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 otras regiones alojan réplicas de solo lectura de la base de datos.

La replicación con instancias principales múltiples en varias regiones es difícil, por eso recomendamos la participación de un socio con experiencia es 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. En la imagen siguiente, se ilustran múltiples apps paralelas, todas contienen un backend y un frontend, y los usuarios se dirigen a la app correcta. Los sitios comparten solo una fracción pequeña de datos.

Latencia de apps paralelas

Por ejemplo, si tienes un negocio de ventas 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 producto cuando es 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 GCP, y otros requieren que cambies tu app.

Usa herramientas de redes de nivel Premium

Google ofrece niveles de servicio de red Premium (predeterminado) y estándar. El tráfico de nivel estándar se entrega por tránsito ISP de regiones de GCP, mientras que el nivel Premium ofrece una latencia más baja debido a que entrega el tráfico a través de la red de fibra 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. Cloud Memorystore para Redis es un almacén de datos en memoria administrado por completo que puedes usar.

Optimiza tu app de cliente 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 estableces una línea de base de los requisitos de la latencia, mira la base de usuarios para decidir la mejor ubicación de tus recursos de GCP. Se emplean estrategias diferentes si la app es nueva o si ya existía.

Usa las estrategias siguientes 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 puede estar interconectada con tu proyecto de GCP mediante Cloud VPN o Cloud Interconnect, dedicada.

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

Si no tienes una app existente con una base de usuario similar a la de tu app nueva, realiza una estimación de la latencia de varias regiones de GCP basadas en una distribución de ubicación aproximada de tu base de usuarios esperada.

La luz viaja a unos 200,000 km/s (124,000 millas) en fibra, pero la estimación es de 1 ms de latencia ida y vuelta por cada 100 km recorridos. Dado que los cables de fibra no siguen una ruta especial desde el origen hasta el destino, puedes suponer que la distancia real es alrededor de 1.5 a 2 veces la distancia medida en un mapa. Por supuesto, en regiones con menos población, la fibra puede 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 tienes usuarios o socios, que representan una sección transversal de tus distribuciones geográficas y que quieren trabajar contigo, o empleados en esos países, pídeles que midan la latencia de varias regiones de GCP. Los sitios web de terceros como ping de GCP te pueden ayudar a obtener algunas medidas.
  • Registros de acceso: si tienes una app activa alojada fuera de GCP, 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 el alcance y las latencias de varias regiones de GCP. 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 la latencia de GCP: si tienes una app existente en GCP, existen varias maneras de recopilar información de la 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 usar 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 basado en los requisitos de la latencia y la arquitectura general de la app. Para la mayoría de las apps para dispositivos móviles y no relacionadas con la latencia, una implementación en una sola región con entrega de contenido almacenado en caché de Cloud CDN y cancelación 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 de las mediciones de la latencia:

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

      • Si necesitas acceso a una latencia baja para tus instalaciones corporativas, implementa en la región más cercana a esa ubicación.
      • Si tus usuarios son de un país o una región específica, implementa en una región cercana a los usuarios representantes.
      • 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.

Pasos siguientes

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...