Aplicaciones distribuidas globalmente mediante Cosmos DB

Cosmos DB
Traffic Manager

Idea de solución

Si le gustaría que expandamos este artículo con más información, como posibles casos de uso, servicios alternativos, consideraciones de implementación o una guía de precios, comuníquese a través de los Comentarios de GitHub.

Garantice el acceso a los usuarios de todo el mundo con las funcionalidades de alta disponibilidad y baja latencia integradas en los centros de datos globales de Microsoft.

Arquitectura

Diagrama de la arquitectura
Descargue una versión SVG de esta arquitectura.

Flujo de datos

  1. El usuario accede a la aplicación a través del cliente dedicado.
  2. Azure Traffic Manager enrutará la conexión del usuario a la mejor ubicación para acceder a la aplicación, en función de un perfil de enrutamiento único o anidado.
  3. En la región de destino donde se hospede la aplicación, la aplicación controlará la sesión y la conexión a la base de datos.
  4. Esta aplicación puede abarcar desde una página estática simple hasta una aplicación orientada a microservicios hospedada en Kubernetes, por ejemplo.
  5. La conexión entre el entorno de la aplicación y la instancia de Cosmos DB se controla a través de un usuario de Azure Active Directory que puede seleccionar las claves de Cosmos DB en Key Vault.
  6. Con las API de hospedaje múltiple de Azure Cosmos DB, la aplicación sabe cuál es la región más cercana y envía las solicitudes a esa región. La región más cercana se identifica sin ningún cambio de configuración. Dado que agrega y quita regiones en la cuenta de Azure Cosmos, no es necesario volver a implementar la aplicación ni pausarla, ya que sigue teniendo alta disponibilidad en todo momento. En segundo plano, Cosmos DB controlará la distribución global y la replicación de los datos en función del número de regiones definidas. Además, se debe poder usar la opción de conmutación automática por error para la conmutación por error en la región con la prioridad de conmutación por error más alta sin acción del usuario si una región deja de estar disponible. Cuando la conmutación automática por error está habilitada, es posible modificar la prioridad de región.

Componentes

  • Azure Traffic Manager: cree opciones de equilibrio de carga o enrutamiento basadas en DNS para sus aplicaciones con seis tipos de opciones de enrutamiento de tráfico basadas en DNS, que se pueden anidar.
  • Azure Active Directory: sincronice los directorios locales y habilite el inicio de sesión único.
  • Azure Cosmos DB: Base de datos multimodelo distribuida globalmente para cualquier escala.

Opciones de proceso

  • Azure Virtual Machines: cree máquinas virtuales (VM) Linux y Windows en segundos y reduzca los costos.
  • Azure Kubernetes Services: servicio de Kubernetes de alta disponibilidad, seguro y totalmente administrado para todas sus cargas de trabajo base de aplicaciones y microservicios.
  • App Service: cree aplicaciones eficaces en la nube con rapidez para la web y móviles.

Opciones sin servidor

Consideraciones

Disponibilidad

La disponibilidad de la instancia de Cosmos DB depende de una serie de factores. A mayor número de regiones en las que Cosmos se replique, mayor será la disponibilidad de la aplicación. Cada región contiene todas las particiones de datos de un contenedor de Azure Cosmos DB y puede atender operaciones de escritura de forma predeterminada. Para aumentar la disponibilidad de la capa de datos, puede habilitar la escritura en varias regiones. Al hacerlo, aumenta la disponibilidad de la capa de datos. También puede aumentar la disponibilidad mediante el empleo de niveles de coherencia y zonas de disponibilidad más débiles.

Al considerar el enfoque anterior, si logra una alta disponibilidad en la conmutación automática por error de Azure Cosmos DB, está configurando la solución para mantener la aplicación en ejecución en el Acuerdo de Nivel de Servicio proporcionado más alto posible.

Para el nivel de aplicación, Traffic Manager debe configurarse con perfiles anidados. Al insertar este diseño en el nivel más alto, puede escalar las distintas opciones de la aplicación por región. La implementación por región también adopta un enfoque de alta disponibilidad.

Rendimiento

El rendimiento del sistema se ve afectado por una serie de factores en el nivel de proceso y de base de datos. La SKU de un plan de App Service u otra opción de proceso afecta a la memoria y a los núcleos que están disponibles en cada región. Además, el número de regiones en las que se implementa la capa de proceso determina la escala que es capaz de controlar. La implementación de ubicaciones adicionales alivia la presión sobre las regiones existentes y debería provocar aumentos lineales en el rendimiento máximo que puede satisfacer la aplicación.

Cosmos DB debe configurarse para que no cause un cuello de botella con los recursos del nivel de proceso. Cada base de datos y contenedor de Cosmos DB debe configurarse para el escalado automático y se les debe proporcionar un valor máximo de unidad de solicitud que garantice que Cosmos DB no limita las solicitudes. Para determinar los valores de unidad de solicitud máxima adecuados para las entidades de Cosmos DB, puede ejecutar pruebas de carga cerca del rendimiento máximo aproximado de la aplicación. En comparación con sus homólogos más fuertes, los niveles de coherencia más débiles ofrecen mayores ventajas de rendimiento y capacidad de proceso.

Fundamentalmente, al implementar la lógica en código que realiza operaciones de lectura y escritura en Cosmos DB, ya sea a través del SDK, enlaces de Azure Functions, etc., debe usarse PreferredLocations para que cada API regional enrute las solicitudes a la región de Cosmos DB más cercana. Según la configuración de la cuenta de Azure Cosmos DB, la disponibilidad regional actual y la lista de preferencias especificada, el SDK elegirá el punto de conexión óptimo para realizar las operaciones de lectura y escritura. Este proceso da lugar a importantes aumentos en el rendimiento.

Resistencia

Para una mayor resistencia, puede usar zonas de disponibilidad para las implementaciones de Azure Cosmos DB. La resistencia también depende de las opciones de nivel de coherencia que elija en su implementación de Cosmos DB. Dependiendo de este nivel de coherencia, logrará un nivel diferente de resistencia (consulte el tema sobre el equilibrio entre coherencia, disponibilidad y rendimiento para obtener más información).

Escalabilidad

El escalado se basa en muchos niveles en este diagrama. Azure Cosmos DB está diseñado específicamente para el escalado elástico y un rendimiento predecible. En el nivel de la aplicación, debe consultar el modelo de proceso usado. Azure Functions y App Service se pueden escalar automáticamente. Para Azure Virtual Machines, puede usar Azure Virtual Machine Scale Sets. En caso de conocer esta necesidad, debe optar por una opción sin servidor siempre que sea posible.

Seguridad

Desde una perspectiva de seguridad, opte por un sistema basado en identidades, donde se pueda usar Azure Active Directory para proteger el acceso al entorno. En el back-end, se accede a la aplicación (por mejor diseño) a través de identidades administradas, aunque también se podría considerar el empleo de usuarios de Azure Active Directory y Azure Key Vault para proteger el acceso. Además, la instancia de Cosmos DB se debe proteger aún más, de forma que las únicas entidades que puedan realizar operaciones de lectura y escritura en ella sean los diversos servidores back-end que se implementan en distintas regiones. Se pueden aplicar restricciones de IP a la cuenta mediante el firewall integrado.

Nota

Desde la edición de Ignite de marzo de 2021, ahora también se admite RBAC de Azure Active Directory directamente en la API Cosmos DB SQL.

Pasos siguientes

Obtener más información sobre Azure Cosmos DB:

Más información acerca de Azure Traffic Manager:

Ideas de soluciones relacionadas:

Arquitecturas completas relacionadas:

Guía de arquitectura relacionada: