Prácticas recomendadas para seleccionar regiones de Compute Engine

En este artículo se describen los criterios que se deben tener en cuenta a la hora de elegir las Google Cloud regiones que se van a usar para los recursos de Compute Engine, una decisión que suelen tomar los arquitectos de la nube o los responsables de ingeniería. Este documento se centra principalmente en la latencia del proceso de selección y está dirigido a aplicaciones a las que acceden los consumidores, como aplicaciones o juegos móviles o web, aunque muchos de los conceptos se pueden aplicar a otros casos prácticos.

Google ofrece varias regiones en todo el mundo para desplegar tus recursos de Compute Engine. Hay varios factores que influyen en la elección de las regiones:

  • Restricciones específicas de cada territorio
  • Latencia de los usuarios por región
  • Requisitos de latencia de tu aplicación
  • Cantidad de control sobre la latencia
  • Equilibrio entre baja latencia y simplicidad

Terminología

región
Un área geográfica independiente en la que ejecutas tus recursos. Cada región consta de zonas, normalmente al menos tres.
zona
Área de implementación de Google Cloud recursos en una región. Si colocas los recursos en zonas diferentes de una región, se reduce el riesgo de que un fallo de la infraestructura afecte a todos los recursos al mismo tiempo.
Recursos de Compute Engine
Los recursos de Compute Engine, como las instancias de máquina virtual, se implementan en una zona 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 se tarda en enviar un paquete IP y en recibir la confirmación.

Cuándo elegir las regiones de Compute Engine

Al principio de la fase de arquitectura de una aplicación, decide cuántas regiones de Compute Engine vas a usar y cuáles. Tu elección puede afectar a tu aplicación. Por ejemplo:

  • La arquitectura de tu aplicación puede cambiar si sincronizas algunos datos entre copias, ya que los mismos usuarios podrían conectarse a través de diferentes regiones en distintos momentos.
  • El precio varía según la región.
  • El proceso para mover una aplicación y sus datos entre regiones es engorroso y, en ocasiones, costoso, por lo que debe evitarse una vez que la aplicación esté activa.

Factores que deben tenerse en cuenta al seleccionar regiones

Es habitual que los usuarios implementen en una región en la que se encuentren, pero no tienen en cuenta si es la mejor experiencia de usuario. Supongamos que te encuentras en Europa, tienes una base de usuarios global y quieres implementar tu aplicación en una sola región. La mayoría de los usuarios se plantearían implementar la aplicación en una región de Europa, pero lo más recomendable es alojarla en una de las regiones de EE. UU., ya que es la que tiene más conexiones con otras regiones.

Hay varios factores que influyen en la decisión de dónde implementar tu aplicación.

Latencia

El factor principal que debes tener en cuenta es la latencia que experimenta el usuario. Sin embargo, se trata de un problema complejo, ya que la latencia de los usuarios se ve afectada por varios aspectos, como los mecanismos de almacenamiento en caché y de equilibrio de carga.

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

Precios

Google Cloud Los costes de los recursos varían según la región. Para estimar el precio, puedes consultar los siguientes recursos:

Si decides hacer el despliegue en varias regiones, ten en cuenta que se aplican cargos por transferencia de datos por los datos sincronizados entre regiones.

Colocación con otros Google Cloud servicios

Coloca tus recursos de Compute Engine junto con otros servicios Google Cloud siempre que sea posible. Aunque la mayoría de los servicios sensibles a la latencia están disponibles en todas las regiones, algunos solo se ofrecen en ubicaciones específicas.

Disponibilidad de tipos de máquina

No todas las plataformas de CPU y los tipos de máquinas están disponibles en todas las regiones. La disponibilidad de plataformas de CPU o tipos de instancias específicos varía según la región e incluso la zona. Si quieres desplegar recursos con determinados tipos de máquinas, consulta la disponibilidad por zonas de estos recursos.

Cuotas de recursos

Tu capacidad para desplegar recursos de Compute Engine está limitada por las cuotas de recursos regionales, así que asegúrate de solicitar cuota suficiente para las regiones en las que tienes previsto desplegar recursos. Si tienes previsto hacer una implementación especialmente grande, ponte en contacto con el equipo de ventas con antelación para hablar sobre las opciones de selección de regiones y asegurarte de que tienes suficiente capacidad de cuota.

Porcentaje de energía libre de carbono

Para suministrar energía a cada Google Cloud región, Google utiliza la electricidad de la red en la que se encuentra la región. Esta electricidad genera más o menos emisiones de carbono, en función del tipo de centrales eléctricas que generen electricidad para esa red y de cuándo la consuma Google. Recientemente, Google se ha fijado el objetivo de que, para el 2030, tus aplicaciones se alimenten con electricidad libre de carbono en el momento y el lugar que necesites, las 24 horas del día, en todas las regiones. Google Cloud

Hasta que alcancemos ese objetivo, cada Google Cloud región se abastecerá de una combinación de fuentes de energía basadas en carbono y libres de carbono cada hora. Denominamos a esta métrica "porcentaje de energía libre de carbono" (CFE%) y publicamos el CFE% de las Google Cloud regiones. En el caso de las nuevas aplicaciones de Google Cloud, puedes usar esta tabla para empezar a incorporar el impacto del carbono en tus decisiones de arquitectura. Si eliges una región con un porcentaje de energía libre de carbono más alto, significa que, de media, tu aplicación se alimentará con energía libre de carbono durante un porcentaje más alto de las horas que esté en funcionamiento, lo que reducirá las emisiones brutas de carbono de esa aplicación.

Evaluar los requisitos de latencia

La latencia suele ser el factor clave a la hora de seleccionar una región, ya que una latencia alta puede empeorar la experiencia de los usuarios. Puedes influir en algunos aspectos de la latencia, pero otros están fuera de tu control.

Cuando se optimiza la latencia, muchos arquitectos de sistemas solo tienen en cuenta la latencia de la red o la distancia entre el ISP del usuario y la instancia de máquina virtual. Sin embargo, este es solo uno de los muchos factores que afectan a la latencia del usuario, como puedes ver en el siguiente diagrama.

Evaluar la latencia en la selección de la región de Compute Engine

Como arquitecto de aplicaciones, puedes optimizar la selección de la región y la latencia de la aplicación, pero no tienes control sobre la última milla de los usuarios ni sobre la latencia hasta los puntos de presencia (POP) de Google más cercanos.

La selección de la región solo puede afectar a la latencia de la región de Compute Engine, no a la latencia completa. En función del caso práctico, puede que solo sea una pequeña parte de la latencia general. Por ejemplo, si tus usuarios utilizan principalmente redes móviles, puede que no te resulte útil intentar optimizar tus regiones, ya que esto apenas afecta a la latencia total de los usuarios.

Latencia del último tramo

La latencia de este segmento varía en función de la tecnología utilizada para acceder a Internet. Por ejemplo, la latencia habitual para llegar a un proveedor de Internet es de 1 a 10 ms en las redes modernas. Por el contrario, las latencias habituales en una red móvil 3G son de entre 100 y 500 ms. El intervalo de latencia de los proveedores de DSL y cable es de entre 10 y 60 ms.

Latencia de frontend y POP de Google

En función de tu modelo de implementación, la latencia hasta el extremo de la red de Google también es importante. Es donde los productos de balanceo de carga global finalizan las sesiones TCP y SSL, y desde donde Cloud CDN ofrece resultados almacenados en caché. En función del contenido servido, es posible que muchos viajes de ida y vuelta ya terminen aquí, ya que solo se debe recuperar una parte de los datos. Esta latencia puede ser significativamente mayor si usas el nivel de servicio de red estándar.

Latencia de la región de Compute Engine

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

Latencia de las aplicaciones

Es la latencia desde que la aplicación responde a las solicitudes, incluido el tiempo que necesita para procesarlas.

Cada aplicación tiene unos requisitos de latencia diferentes. En función de la aplicación, los usuarios toleran más los problemas de latencia. Las aplicaciones que interactúan de forma asíncrona o las aplicaciones móviles con un umbral de latencia alto (100 milisegundos o más) se pueden implementar en una sola región sin que se vea afectada la experiencia del usuario. Sin embargo, en aplicaciones como los juegos en tiempo real, unos pocos milisegundos de latencia pueden tener un mayor efecto en la experiencia de usuario. Implementa estos tipos de aplicaciones en varias regiones cercanas a los usuarios.

Patrones de despliegue global

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

Implementación en una sola región

En la siguiente imagen se muestra una implementación en una sola región.

Latencia de un solo despliegue de frontend

Aunque tu aplicación esté dirigida a una base de usuarios internacional, en muchos casos, una sola región sigue siendo la mejor opción. Las ventajas de una latencia más baja podrían no compensar la complejidad añadida de un despliegue multirregional. Aunque solo se implemente en una región, puedes usar optimizaciones, como Cloud CDN y el balanceo de carga global, para reducir la latencia de los usuarios. Puedes usar una segunda región por motivos de copia de seguridad y recuperación ante desastres, pero esto no afecta a la ruta de servicio de la aplicación y, por lo tanto, no afectará a la latencia de los usuarios.

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. Este modelo te ofrece la ventaja de una latencia más baja en los servidores frontend sin tener que sincronizar datos en varias regiones.

Latencia del despliegue del frontend distribuido

Este modelo de implementación ofrece una latencia baja para los usuarios en situaciones en las que la solicitud media de los usuarios no implica ninguna solicitud de datos o implica solo unas pocas solicitudes de datos al backend central antes de que la aplicación pueda producir un resultado. Por ejemplo, una aplicación que implementa una capa de almacenamiento en caché inteligente en el frontend o que gestiona las escrituras de datos de forma asíncrona. Una aplicación que haga muchas solicitudes que requieran un viaje de ida y vuelta completo al backend puede que no se beneficie de este modelo.

Frontend y backend distribuidos en varias regiones

Un modelo de implementación en el que distribuyes el frontend y el backend en varias regiones te permite minimizar la latencia de los usuarios, ya que la aplicación puede responder completamente a cualquier solicitud de forma local. Sin embargo, este modelo conlleva una mayor complejidad, ya que todos los datos deben almacenarse y ser accesibles de forma local. Para responder a todas las solicitudes de los usuarios, los datos deben replicarse por completo en todas las regiones.

Latencia de la implementación multirregional distribuida

Spanner, la base de datos gestionada con coherencia global, tiene una opción multirregional de tres continentes, donde, además de las réplicas de lectura y escritura en EE. UU., hay dos réplicas de lectura en Europa y Asia. Esta opción proporciona acceso de lectura con baja latencia a los datos de las instancias de cálculo situadas en EE. UU., Europa o Asia. Si tu servicio está orientado a EE. UU., también puedes elegir una opción multirregional con replicación en EE. UU.

Si decides ejecutar 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 los datos sincronizados de forma coherente en todo el mundo. Es más fácil de gestionar si la base de datos se escribe en una sola región mediante escrituras asíncronas y las demás regiones alojan réplicas de solo lectura de la base de datos.

Replicar bases de datos en distintas regiones es difícil, por lo que te recomendamos que colabores con un partner fiable que tenga experiencia en este ámbito, como Datastax, para la replicación de Cassandra.

Varias aplicaciones paralelas

En función de la naturaleza de tu aplicación, con una variación del enfoque anterior, puedes mantener una latencia baja para los usuarios y, al mismo tiempo, reducir la necesidad de replicar datos constantemente. Como se muestra en la siguiente imagen, hay varias aplicaciones paralelas, todas ellas con un frontend y un backend, y los usuarios se dirigen a la aplicación correcta. Solo se comparte una pequeña parte de los datos entre los sitios.

Latencia de las aplicaciones paralelas

Por ejemplo, si tienes un negocio minorista, puedes ofrecer tus servicios a usuarios de diferentes regiones a través de distintos dominios de país y tener sitios paralelos en todas esas regiones, sincronizando solo los datos de productos y usuarios cuando sea necesario. Los sitios locales mantienen su disponibilidad de stock local y los usuarios se conectan a un sitio alojado localmente seleccionando un dominio de país. Cuando un usuario visita un dominio de otro país, se le redirige al dominio correcto.

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

Otro ejemplo es ofrecer software como servicio (SaaS) en diferentes regiones, donde la ubicación de los datos se selecciona al crear la cuenta, ya sea en función de la ubicación del usuario o de su elección. Después de iniciar sesión, se redirige al usuario a un subdominio específico de la ubicación y utiliza el servicio a nivel regional.

Optimizar la latencia entre usuarios y regiones

Independientemente del modelo de implementación que elijas, puedes combinar métodos de optimización para reducir la latencia visible para el usuario final. Algunos de estos métodos sonGoogle Cloud funciones, mientras que otros requieren que cambies tu aplicación.

Usar la red de nivel Premium

Google ofrece niveles de servicio de red premium (predeterminado) y estándar. El tráfico del nivel Estándar se envía a través de proveedores de Internet de tránsito desde Google Cloud regiones, mientras que el nivel Premium ofrece una latencia más baja al enviar el tráfico a través de la red privada global de Google. La red de nivel premium reduce la latencia de los usuarios y debe usarse en todas las partes de la aplicación en la ruta de servicio. También es necesario tener la red de nivel premium para usar los productos de balanceo de carga global de Google.

Usar Cloud Load Balancing y Cloud CDN

Cloud Load Balancing, como el balanceo de carga HTTP(S), TCP y de proxy SSL, te permite redirigir automáticamente a los usuarios a la región más cercana en la que haya backends con capacidad disponible.

Aunque tu aplicación solo esté disponible en una región, Cloud Load Balancing sigue ofreciendo una latencia más baja a los usuarios porque las sesiones TCP y SSL se terminan en el perímetro de la red. Termina fácilmente el tráfico de los usuarios con HTTP/2 y Quick UDP Internet Connections (QUIC). También puedes integrar Cloud CDN con el balanceo de carga HTTP y HTTPS para distribuir recursos estáticos directamente desde el perímetro de la red, lo que reduce aún más la latencia de los usuarios.

Almacenar en caché de forma local

Si las ubicaciones de frontend son diferentes de las de backend, asegúrate de almacenar en caché las respuestas de los servicios de backend siempre que sea posible. Cuando el frontend y el backend están en la misma región, la latencia de la aplicación se reduce porque también se reducen las consultas que requieren mucho tiempo. Memorystore para Redis es un almacén de datos en memoria totalmente gestionado que puedes usar.

Optimizar el cliente de la aplicación o el frontend web

Puede usar técnicas del lado del cliente, ya sea una aplicación móvil o el frontend web, para optimizar la latencia de los usuarios. Por ejemplo, precarga algunos recursos o datos de la caché en la aplicación.

También puedes optimizar la forma en que tu aplicación obtiene información reduciendo el número de solicitudes y recuperando información en paralelo siempre que sea posible.

Medir la latencia de los usuarios

Una vez que hayas establecido una base de referencia de tus requisitos de latencia, analiza tu base de usuarios para decidir la mejor ubicación de tus recursos de Google Cloud . En función de si se trata de una aplicación nueva o ya existente, se pueden emplear diferentes estrategias.

Usa las siguientes estrategias para medir la latencia de los partners a los que accedes durante el servicio de aplicaciones o para medir la latencia de tu red on-premise, que puede estar interconectada con tu proyecto Google Cloud mediante Cloud VPN o Interconexión dedicada.

Estimar la latencia de las nuevas cargas de trabajo

Si no tienes una aplicación con una base de usuarios similar a la de tu nueva aplicación, estima la latencia de varias Google Cloud regiones en función de la distribución aproximada de la ubicación de tu base de usuarios prevista.

Estima 1 ms de latencia de ida y vuelta por cada 100 km recorridos. Como las redes no siguen una ruta ideal desde el origen hasta el destino, normalmente se puede suponer que la distancia real es entre 1,5 y 2 veces la distancia medida en un mapa. Por supuesto, en algunas regiones menos densamente pobladas, las redes pueden seguir un camino aún menos ideal. La latencia añadida a través de equipos activos en las redes de los ISPs suele ser insignificante cuando se trata de distancias entre regiones.

Estos números pueden ayudarte a estimar la latencia de los POP de la red perimetral y los nodos de Cloud CDN, así como las regiones de Compute Engine de todo el mundo, tal como se indica en el mapa de la red.

Medir la latencia de los usuarios actuales

Si ya tienes una aplicación con una base de usuarios similar, puedes usar varias herramientas para estimar mejor las latencias.

  • Usuarios representativos: si tienes usuarios o partners que representen una muestra representativa de tus distribuciones geográficas y que estén dispuestos a colaborar contigo, o empleados en esos países, pídeles que midan la latencia en varias Google Cloud regiones. Los sitios web de terceros, como Google Cloud ping, pueden ayudarte a obtener algunas mediciones.
  • Registros de acceso: si tienes una aplicación activa alojada fuera deGoogle Cloud, usa los datos de los registros de acceso para obtener una muestra representativa de los usuarios. Los registros pueden proporcionar información sobre el país o la ciudad, lo que también te permite estimar las 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 desde varias Google Cloud regiones. Si su firewall bloquea tus sondeos, prueba a aleatorizar el último octeto de la IP para obtener una respuesta de otro dispositivo con una latencia similar a la de tu aplicación.

  • Información de latencia de Google Cloud: si tienes una aplicación en Google Cloud, hay varias formas de recoger información de latencia.

Conectividad global

Cuando calcules la latencia, ten en cuenta la topología de la red mundial de Google.

  • Puntos de presencia: lugares por los que el tráfico de los usuarios entra en la red.
  • Nodos de Cloud CDN: donde se almacena en caché el tráfico.
  • Regiones: dónde se pueden ubicar tus recursos.
  • Conectividad: entre los POPs y las regiones.

Consulta una lista de las ubicaciones en las que Google se interconecta con otros ISPs en PeeringDB.

A la hora de decidir en qué regiones vas a implementar la aplicación, ten en cuenta la topología interregional. Por ejemplo, si quieres implementar una aplicación con una base de usuarios global en una sola región, suele ser mejor alojarla en una de las regiones de EE. UU., ya que este país está conectado con la mayoría de las demás regiones. Aunque hay conectividad directa entre muchos continentes, en algunos casos no es así, por ejemplo, entre Europa y Asia, por lo que el tráfico entre Europa y Asia fluye a través de EE. UU.

Si tu aplicación está alojada en varias regiones y necesitas sincronizar datos, ten en cuenta la latencia entre esas regiones. Aunque esta latencia puede cambiar con el tiempo, suele ser estable. Mide la latencia tú mismo creando instancias de prueba en todas las regiones posibles o usa sitios web de terceros para hacerte una idea de las latencias actuales entre regiones.

Analizar todos los datos en conjunto

Ahora que has tenido en cuenta los requisitos de latencia, los posibles modelos de implementación y la distribución geográfica de tu base de usuarios, sabes cómo afectan estos factores a la latencia en determinadas regiones. Es el momento de decidir en qué regiones quieres lanzar tu aplicación.

Aunque no hay una forma correcta de sopesar los diferentes factores, la siguiente metodología paso a paso puede ayudarte a tomar una decisión:

  1. Comprueba si hay factores no relacionados con la latencia que te impidan implementar en regiones específicas, como el precio o la colocación. Quítalos de tu lista de regiones.
  2. Elige un modelo de implementación en función de los requisitos de latencia y la arquitectura general de la aplicación. En la mayoría de las aplicaciones móviles y otras aplicaciones que no sean críticas para la latencia, la opción óptima puede ser una implementación de una sola región con la entrega de contenido almacenable en caché y la finalización de SSL en el perímetro mediante Cloud CDN.

  3. En función de tu modelo de implementación, elige las regiones según la distribución geográfica de tu base de usuarios y tus mediciones de latencia:

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

      • Si necesitas acceder a tu oficina con baja latencia, implementa la solución en la región más cercana a esa ubicación.
      • Si tus usuarios proceden principalmente de un país o una región, implementa la aplicación en la región más cercana a tus usuarios representativos.
      • Si tienes una base de usuarios global, implementa la aplicación en una región de EE. UU.

    • En el caso de un despliegue multirregional:

      • Elige regiones cercanas a tus usuarios en función de su distribución geográfica y de los requisitos de latencia de la aplicación. En función de tu aplicación, optimiza la latencia media específica o asegúrate de que entre el 95 y el 99% de los usuarios reciban el servicio con una latencia objetivo específica. Los usuarios de determinadas ubicaciones geográficas suelen tener una mayor tolerancia a la latencia debido a las limitaciones de su infraestructura.

  4. Si la latencia de los usuarios es similar en varias regiones, el precio puede ser el factor decisivo.

Al seleccionar regiones de Compute Engine, la latencia es uno de los factores más importantes que se deben tener en cuenta. Evalúa y mide los requisitos de latencia para ofrecer una experiencia de usuario de calidad y repite el proceso si cambia la distribución geográfica de tu base de usuarios.

Siguientes pasos