Elección de la arquitectura correcta para la distribución de datos globales

En esta solución se describen tres arquitecturas de ejemplo que puedes usar para distribuir datos en las regiones de Google Cloud.

Muchas empresas trabajan con datos de distintas ubicaciones geográficas mientras responden a solicitudes de clientes casi en tiempo real. Por ejemplo, una plataforma orientada a la demanda (DSP) para publicidad digital puede tener clientes que esperen que los tiempos de respuesta de las bases de datos sean inferiores a veinte milisegundos, sin importar la ubicación geográfica o la carga de red actual. Implementar esta clase de solución de DSP global no es posible si la arquitectura de red se funda en una única base de datos centralizada, que es vulnerable a las latencias según la distancia física y que, además, se ve afectada considerablemente por los aumentos bruscos en el uso.

Puedes satisfacer estas necesidades con una arquitectura distribuida para el almacenamiento de datos. No todas las arquitecturas son apropiadas para cualquier necesidad empresarial, y cada una tiene sus propias fortalezas y debilidades. Por lo tanto, esta solución ofrece varias alternativas de Google Cloud para ayudarte a implementar tu estrategia comercial general y guiar tu enfoque de implementación de red.

Ventajas de Google Cloud

Google Cloud ofrece un ancho de banda de red sólido y estable en todo el mundo. Google Cloud tiene muchas ventajas adicionales:

Google Cloud es muy flexible, y puedes usarlo para crear una red virtual global, lo que permite que tus aplicaciones se comuniquen de manera más segura entre regiones mediante direcciones IP privadas. Por ejemplo, puedes configurar instancias de máquinas virtuales (VM) de Compute Engine en dos regiones, como us-central1 y asia-east1. Puedes hacer que esas instancias de VM usen direcciones IP privadas para comunicarse directamente entre sí mediante la creación de una red de nube privada virtual. De esta manera tu organización puede mantener comunicaciones seguras entre instancias.

Con la IP anycast de Google Cloud, se asigna una única dirección IP global a un servicio administrado, como el de balanceo de cargas. Con una IP anycast puedes crear un solo balanceador de cargas global en lugar de configurar balanceadores de cargas en cada región. El balanceador de cargas global enruta las solicitudes de clientes a las aplicaciones que se ejecutan en las regiones más cercanas y ajusta la escala de forma automática para satisfacer la demanda cambiante.

Tres arquitecturas de distribución de datos de ejemplo

En esta sección se describen tres arquitecturas de implementación y se analiza cuándo son apropiadas. Las arquitecturas y los casos prácticos son los siguientes:

  • Implementación híbrida con Google Cloud y servicios locales. Quieres mantener algunos servicios locales, pero te gustaría aprovechar las funciones de Google Cloud. Google Cloud está vinculado a tu red actual y se incorpora a los procesos empresariales en curso. Algunos datos locales, o todos, se copian a Google Cloud o se incorporan en ese servicio.

  • Implementación híbrida con Google Cloud y otras plataformas de proveedores de servicios en la nube. Quieres mantener tus operaciones actuales del proveedor de servicios en la nube, pero te gustaría incluir algunas funciones de Google Cloud y configurar los dos sistemas para que se comuniquen entre sí.

  • Google Cloud con varias regiones. Quieres admitir transferencias de datos casi síncronas, tal vez a escala global. Configurar Google Cloud en varias regiones permite que la transferencia de datos sea muy rápida y casi simultánea en todo el mundo.

Implementación híbrida: Google Cloud y servicios locales

La combinación de Google Cloud con servicios locales es adecuada para casos prácticos que involucran aplicaciones que almacenan datos locales y, además, propagan datos a Google Cloud.

Por ejemplo, en la industria minorista, se pueden insertar datos principales (también conocidos como datos maestros) sobre productos nuevos en las bases de datos locales para un sistema administrado de inventario heredado. Es posible que la empresa también deba propagar esos datos a una base de datos de Google Cloud que se usa para tiendas web en línea. Con un enfoque híbrido, puedes compilar un sistema nuevo que use Google Cloud sin afectar el sistema local existente. En esta arquitectura, Google Cloud funciona esencialmente en paralelo con las estructuras de red locales.

Si decides realizar una implementación híbrida de Google Cloud y local, debes tener en cuenta los siguientes problemas:

  • Si los datos son locales y, también, se encuentran en Google Cloud, debes decidir qué datos tratar como datos principales, y dónde deben estar. Por ejemplo, puedes definir los datos de Google Cloud como los datos principales. En ese caso Google Cloud se comporta como un centro de datos que conecta uno o varios entornos locales y realiza intercambios de datos entre ellos. Después de agregar o actualizar datos en el entorno de Google Cloud, los datos se transmiten a los sistemas locales. Como alternativa, los sistemas locales podrían conservar los datos principales y actualizar Google Cloud de forma periódica.
  • Si estás desarrollando una aplicación para este entorno híbrido, ten en cuenta que los servicios administrados solo están disponibles para los recursos de Google Cloud. Es posible que las aplicaciones que se ejecutan de manera local y en el entorno de Google Cloud no puedan aprovechar los servicios administrados, como las copias de seguridad, la redundancia y la escalabilidad automáticas.
  • Para mantener la portabilidad de los datos y garantizar operaciones administrativas coherentes, posiblemente sea más fácil alojar almacenes de datos multiplataforma, como MySQL, en máquinas virtuales tanto en tu implementación de Google Cloud como en la local.

Arquitectura híbrida de ejemplo

En el siguiente diagrama, se ilustra un ejemplo de una arquitectura híbrida con Google Cloud y sistemas locales.

Arquitectura de un sistema híbrido.

En la arquitectura de ejemplo, se dan las siguientes situaciones:

  • Los datos se intercambian entre los servidores de archivos locales y Cloud Storage. Esto puede incluir la copia de seguridad de archivos locales en Google Cloud, el procesamiento por lotes de archivos como entrada o la descarga de archivos de Google Cloud a redes locales.
  • Las aplicaciones personalizadas de centros de datos locales usan las API de REST para acceder a aplicaciones de App Engine y recuperar o enviar datos. Las solicitudes de REST suelen ser síncronas y bloquean los clientes hasta que se muestran los resultados. En esta arquitectura App Engine proporciona ajuste de escala automático para aumentar la capacidad según sea necesario, lo cual ayuda a mantener baja la latencia de estas llamadas síncronas.
  • Las aplicaciones personalizadas envían mensajes directamente a Pub/Sub a fin de almacenarlos en una cola replicada para el procesamiento posterior. Cuando llegan mensajes a Pub/Sub, este muestra el estado de forma inmediata y no bloquea los clientes. Los mensajes se pueden recuperar y procesar de manera asíncrona mediante Cloud Functions, Dataflow, aplicaciones que se ejecutan en Compute Engine y otros métodos. Las aplicaciones cliente de entornos locales también pueden recuperar mensajes.
  • Los datos almacenados en bases de datos locales se exportan (quizás como archivos CSV) y se suben a Google Cloud para la carga por lotes en bases de datos administradas por Cloud SQL.
  • Se usa una base de datos de Firebase para sincronizar datos entre sistemas locales y Google Cloud. Las aplicaciones se suscriben a claves en la base de datos y, cada vez que se actualizan valores, estas reciben notificaciones en tiempo real así como los valores actualizados. Las aplicaciones que interactúan con Firebase pueden encontrarse en entornos locales, en Google Cloud o en ambos.

Implementación híbrida: Google Cloud y otros proveedores de servicios en la nube

Puedes combinar Google Cloud con otros proveedores de servicios en la nube para distribuir tus datos de manera más eficaz, emplear varios mecanismos a prueba de fallas o aprovechar funciones específicas de Google Cloud. Esta arquitectura es una buena opción cuando ya tienes servicios de producción en ejecución en otros proveedores de servicios en la nube, pero quieres aprovechar funciones de Google Cloud. Por ejemplo, puede que quieras usar BigQuery para analizar datos de aplicaciones, además de registros y métricas de supervisión.

Esta arquitectura es similar a la arquitectura híbrida local y de Google Cloud que se describió antes. Cuando realizas una implementación híbrida de Google Cloud y otros proveedores de servicios en la nube, debes tener en cuenta los siguientes problemas:

  • Puedes usar bibliotecas cliente de múltiples nubes de código abierto como jcloudslibcloud para integrar API entre Google Cloud y otros servicios de nube.
  • Google Cloud ofrece formas de transferir datos desde Amazon Web Services (AWS), como el Servicio de transferencia de almacenamiento, Cloud Monitoring y Cloud Logging. Puedes exportar los registros a BigQuery para analizarlos en detalle.
  • Pub/Sub es un servicio global, y tus aplicaciones no necesitan saber en qué región existen colas de Pub/Sub. Puedes publicar mensajes o suscribirte a temas disponibles de manera global. Con Google Cloud, las apps cliente deben conocer solo un conjunto de direcciones IP y puertos. Es posible que en el caso de otros proveedores de servicios en la nube las colas sean específicas de cada región. Si es así, cuando implementas apps en varias regiones, las apps cliente necesitan conocer los extremos correspondientes a cada región. Hacer un seguimiento de los extremos puede ser engorroso, en especial si se agregan servicios desde regiones nuevas.

Arquitectura de ejemplo para Google Cloud combinada con otro proveedor de servicios en la nube

En el siguiente diagrama, se muestra una arquitectura híbrida que incluye GCP y otros proveedores de servicios en la nube.

Arquitectura de un sistema que involucra Google Cloud y otro proveedor de servicios en la nube.

En la arquitectura de ejemplo, se dan las siguientes situaciones:

  • Los mensajes se intercambian entre Pub/Sub y otras nubes públicas. Pub/Sub proporciona un extremo global y puede actuar como centro de mensajes entre nubes, ya que las aplicaciones no necesitan saber en qué región concreta existen colas de mensajes.
  • Se instalan instancias del agente de Cloud Monitoring en máquinas virtuales de otras nubes públicas para recopilar métricas sobre el uso de la CPU, el uso de la memoria, información de procesos y otros datos. Cloud Monitoring supervisa el uso de recursos en entornos de nube híbrida.
  • Las aplicaciones personalizadas que se ejecutan en máquinas virtuales en otros entornos de nube usan API de REST para llamar a aplicaciones alojadas en App Engine y así poder enviar o recuperar datos.
  • El Servicio de transferencia de almacenamiento transfiere archivos directamente desde Amazon S3 a pedido o de manera periódica. Los archivos transferidos pueden procesarse en Compute Engine para cargarlos en Cloud SQL.

Implementación híbrida: Google Cloud con varias regiones

Una arquitectura basada en Google Cloud en varias regiones es una buena opción cuando tu aplicación debe completar solicitudes de usuarios a nivel global y sincronizar datos entre regiones con una latencia mínima. Un ejemplo de esta arquitectura podría ser un videojuego con acceso a Internet que debe funcionar en todo el mundo con sincronización casi en tiempo real entre jugadores.

Esta arquitectura aprovecha la potencia de los servicios administrados de Google Cloud para reducir las tareas administrativas y facilitar el diseño del sistema. Google Cloud te permite concentrarte en tus aplicaciones sin perder tiempo en el diseño de la infraestructura. Si decides realizar una implementación híbrida de Google Cloud con varias regiones debes tener en cuenta los siguientes problemas:

  • Es posible implementar servicios de procesamiento de datos multirregionales con facilidad, ya que los suscriptores y publicadores de mensajes pueden ejecutarse en cualquier región. Pub/Sub puede intercambiar mensajes entre aplicaciones que se ejecutan en regiones diferentes sin que sea necesario especificar la ubicación en la que se ejecuta la aplicación. En esta arquitectura los mensajes de Pub/Sub permanecen en su totalidad dentro de Google Cloud y no se envían a través de Internet, lo que reduce la latencia.
  • Las aplicaciones que se ejecutan en instancias de Compute Engine pueden comunicarse directamente entre regiones mediante direcciones IP privadas dentro de una red de VPC de Google Cloud.
  • Puedes usar API de REST para que las aplicaciones personalizadas se vinculen de manera flexible. Debido a que la arquitectura está por completo dentro del entorno de Google Cloud, puedes usar App Engine para administrar aplicaciones respecto de las cuales prevés la realización de tareas administrativas mínimas.
  • Después de distribuir datos entre regiones, puedes usar Dataflow o Dataproc para procesar cargas de trabajo de ETL o analíticas.

Ejemplo de arquitectura multirregional de Google Cloud

En el siguiente diagrama, se ilustra la arquitectura de una implementación de Google Cloud con varias regiones.

Arquitectura de un sistema que involucra varias regiones de Google Cloud.

En la arquitectura de ejemplo, se dan las siguientes situaciones:

  • Al igual que con la arquitectura de nube híbrida, Cloud Monitoring supervisa todos los recursos informáticos y muestra una vista global consolidada del uso de recursos. Los registros y las métricas recopilados se exportan a BigQuery para analizarlos en detalle.
  • Al igual que con la arquitectura de nube híbrida, Pub/Sub se usa como centro de mensajes. Pub/Sub permite que los servicios se vinculen de manera flexible y sean independientes de la ubicación concreta en la que se ejecuta la aplicación.
  • Las aplicaciones personalizadas que se ejecutan en App Engine o Compute Engine intercambian mensajes directamente con otras mediante API de REST. Esta es una arquitectura vinculada con menor flexibilidad que la híbrida y, por lo tanto, alcanza niveles de latencia más predecibles.
  • El Servicio de transferencia de almacenamiento se usa para sincronizar depósitos de Cloud Storage. De manera alternativa la herramienta de gsutil se puede usar para transferencias a pedido entre depósitos de distintas regiones.

Próximos pasos

Obtén más información sobre la administración de datos en Google Cloud en los siguientes vínculos: