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. Existen varios factores importantes en la elección de 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 y, por lo general, son al menos tres. 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 los recursos de Google Cloud dentro de una región. Las zonas están diseñadas para ser independientes unas de otras: los planos de control, las herramientas de redes, el enfriamiento y la alimentación están aislados de otras zonas. Los eventos de falla únicos, por lo general, afectan a una sola zona.
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 distintas regiones 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 del usuario 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. Para estimar el precio, se encuentran disponibles los siguientes recursos:

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 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íficos 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 sobre la 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 una latencia alta de usuario puede llevar a una experiencia del usuario menos satisfactoria. Puedes modificar 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 controlar la red de acceso y latencia del usuario en los puntos de presencia (POP) perimetral 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, es probable que no sea útil tratar de optimizar tus regiones, debido a que eso no afecta la latencia de usuario total.

Latencia de la red de acceso

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 en 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 almacenados en caché. Según el contenido entregado, algunos de los viajes de ida y vuelta pueden terminar aquí debido a que solo una parte de los datos se necesita recuperar 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 límite 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 para reducir la latencia del usuario, como el balanceo de cargas global y Cloud CDN. Puedes elegir usar una segunda región como copia de seguridad por razones de recuperación ante desastres, pero eso no afecta la ruta de entrega de la app y, por lo tanto, no afectará 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 tienes 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

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. Esta replicación es una tarea importante, ya que es difícil mantener la sincronización de los datos de manera 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.

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 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 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 del 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 sala de espera global en la que el usuario elija un mundo o sala de juegos que se encuentre cerca de su ubicación y esas salas o esos mundos no compartan datos entre sí.

Un tercer ejemplo es ofrecer 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 este 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 tu 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 por tráfico ISP 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. Las herramientas de redes de nivel Premium reducen la latencia del usuario y deberían usarse para todas las partes de la app en la ruta de entrega. Las herramientas de redes de nivel Premium también son necesarias para usar productos de balanceo de cargas global de Google.

Usa Cloud Load Balancing y Cloud CDN

Cloud Load Balancing, como el balanceo de cargas HTTP(S), el balanceo de cargas TCP y proxy SSL, te permite redireccionar de manera automática a los usuarios a la región más cercana en la que haya 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 a Internet UDP rápidas (QUIC). También puedes integrar Cloud CDN en el balanceo de cargas 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.

Almacena 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 tu app de cliente o el frontend web

Puedes usar técnicas del cliente, como una app para dispositivos móviles o un frontend web a fin de optimizar la latencia del usuario. Por ejemplo, sube con anterioridad 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 ubicación aproximada de la distribución 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 de ISP no es en general importante cuando se tienen en cuenta las distancias interregionales.

Estas cantidades te pueden ayudar a estimar la latencia del POP perimetral 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 calcular 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 la latencia.

Conectividad global

Cuando calculas 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 los POP y las regiones.

Encuentra una lista de ubicaciones donde Google se interconecta con otros 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 no, 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 siguiente metodología paso a paso 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 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 de las mediciones de la latencia:

    • Para una implementación de una sola región, sigue estos pasos:

      • 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, sigue estos pasos:

      • 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 a la latencia debido a sus limitaciones de infraestructura.
  4. Si la latencia de usuario es similar en muchas regiones, el precio puede ser 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.

Próximos pasos