Elegir un paradigma de implementación requiere considerar las necesidades de la aplicación en cuanto a disponibilidad (tanto en general como en caso de una Interrupción del servicio), latencia, cumplimiento de normativas y costo. No existe un único paradigma 'correcto' para la implementación. Esta sección explora las arquitecturas disponibles para ayudarte a satisfacer tus necesidades de implementación.
Al implementar tu base de datos, primero debes elegir entre implementar en una sola región o en varias regiones. El siguiente diagrama muestra estas opciones, que se explican más adelante:
Implementaciones de una sola región
A La implementación de una sola región es la opción de implementación más sencilla. En una implementación de una sola región, tus datos se almacenan en una de las regiones de un proveedor (como la de AWS us-west-2
o del asia-northeast3 de Google). Para aquellas regiones que cuentan con múltiples zonas, Atlas siempre proporciona disponibilidad a nivel de zona. Los nodos de tu clúster están distribuidos en las zonas de disponibilidad dentro de una región única. Por lo tanto, si una sola zona falla, tus datos siguen estando disponibles en las otras zonas.
Nota
Las regiones recomendadas cuentan con tres zonas de disponibilidad y están marcadas con un ícono de estrella en la interfaz de usuario de Atlas.
Con la simplicidad y el menor costo de una implementación en una sola región conlleva el riesgo de una menor disponibilidad y, potencialmente, una mayor latencia, dependiendo de la distribución de los usuarios de la aplicación.
Implementaciones multiregión
Una implementación multirregional es un paradigma de implementación más complejo que proporciona mayor disponibilidad y baja latencia en un rango geográfico mayor que una implementación monorregional. Existen varios tipos de implementaciones multirregionales:
Multi-región en una geografía: Se implementa en múltiples regiones alojadas por un único proveedor de nube dentro de una única geografía, definida como un área grande como un país o un continente. Esto garantiza la disponibilidad en caso de que alguna región falle.
Por ejemplo, implementa clústeres en la Las regiones deAWS
us-west-1yus-east-1se encuentran en Estados Unidos. Sius-east-1deja de estar disponible,us-west-1seguirá aceptando lecturas y escrituras con un rendimiento casi normal.Multiregión en varias geografías: La implementación se realiza en una o más regiones de dos o más geografías. Esto garantiza la disponibilidad si alguna región determinada falla o si un área geográfica completa no está disponible.
Por ejemplo, se despliegan clústeres en las regiones AWS
us-east-1yus-east-2, ambas en Estados Unidos, y un tercer clúster eneu-west-2, que se encuentra en Europa.Multi-nube : Despliegue en una o más regiones alojadas por múltiples proveedores de nube. Esto proporciona el mayor nivel de disponibilidad, asegurando que tus datos estén disponibles si alguna región falla o si falla un proveedor de nube completo.
Por ejemplo, se implementan clústeres en la región AWS
us-west-1y en la regiónus-east4de Google Cloud.
Consideraciones sobre la disponibilidad
La disponibilidad suele considerarse en términos de la resistencia de tus clústeres a las interrupciones, mientras que la recuperación ante desastres se refiere a la rapidez con que tu sistema puede recuperarse de una interrupción del servicio (RTO) y a la cantidad de datos que podrían perderse en una interrupción del servicio (RPO). Porque todas las instancias de Atlas siempre cuentan con datos actualizados, los failovers no requieren la restauración de copias de seguridad.
Atlas tiene la replicación integrada en tus implementaciones, lo que significa:
Las instancias de base de datos se mantienen estrictamente sincronizadas entre sí, generalmente en el rango de milisegundos.
En caso de una Interrupción del servicio, el cambio por falla entre instancias de bases de datos es completamente automático. No requiere intervención humana y sólo lleva unos segundos.
Al usar la configuración por defecto writeConcern de
majority, entonces no se produce pérdida de datos durante el traspaso porque todos los datos se escribieron en varias ubicaciones, lo que impide la pérdida de datos. Además, el controlador DB reintentará automáticamente cualquier operación en curso para garantizar su éxito.
Esto significa que el RTO, el RPO y la frecuencia de replicación de datos son prácticamente iguales y los clústeres de Atlas están totalmente operativos siempre que la mayoría de los nodos estén en buen estado.
Nota
El RTO y el RPO máximos se deben considerar de manera integral tanto en todo el clúster como en la forma de implementar la aplicación. Se debe considerar la carga de trabajo completa del clúster para garantizar que sea compatible con los requisitos.
Comparación de paradigmas de implementación
Para determinar qué patrón de implementación es el adecuado para ti, clasifica las aplicaciones según su importancia para el negocio principal. Cuanto más importante sea la aplicación (en otras palabras, cuanto mayor sea el impacto de una interrupción del servicio en el negocio), más deberías considerar una arquitectura que gestione automáticamente cualquier evento de interrupción del servicio.
La siguiente tabla ofrece una comparación de los paradigmas de implementación para ayudarte a determinar el que mejor se adapta a tus necesidades:
Nivel de prioridad | Descripción | RTO | Modelo de implementación | Costo relativo |
|---|---|---|---|---|
Nivel 0 | Aplicaciones de la mayor criticidad. Requiere conmutación por error completamente automática incluso en evento de interrupciones del servicio regionales. | 0 | $$$ | |
Nivel 1 | Aplicaciones de criticidad menor. Puede experimentar algunos periodos de inactividad o periodos de mantenimiento sin un impacto significativo en las ganancias. | > 1 hora y < 8 horas | $$ | |
Nivel 2 | Aplicaciones de menor criticidad. Puede estar inactivo durante 24 horas sin un impacto significativo en las ganancias. | > 8 horas | $+ | |
No producción | Aplicaciones no críticas. Entornos que no son directamente responsables de la ganancia ni están orientados al cliente. Normalmente entornos de desarrollo y prueba. | N/A | $0 en adelante |
Nota
El costo de cada tipo de implementación depende de varios factores, incluido el(los) proveedor(es) que selecciones, el número de regiones que necesites, la cantidad de almacenamiento y la potencia de procesamiento de los servidores. Para obtener la información de precios más reciente, consulta Precios de MongoDB.
Casos de uso
A la hora de elegir tu paradigma de implementación, empieza por identificar el menor número de regiones que puedes implementar para servir a la distribución geográfica más amplia de tus usuarios. Después, considera la posibilidad de agregar regiones o proveedores de nube adicionales según tus requisitos de disponibilidad, rendimiento y soberanía de los datos.
Considera los siguientes casos de uso para ayudar a decidir qué paradigma de implementación se adapta mejor a la distribución geográfica de los usuarios de tu aplicación:
Usuarios mayormente en una sola geografía
Si la mayoría de los usuarios de tu aplicación se encuentran en una geografía, te recomendamos que la implementes en una o más regiones dentro de la misma geografía. Mientras que una implementación de una sola región puede proteger contra una interrupción del servicio en una sola zona de disponibilidad, una implementación multiregión cubre una área geográfica más grande y garantiza la disponibilidad tanto durante interrupciones del servicio zonales como regionales. Para una disponibilidad aún mayor, puedes implementar en varias regiones. Todas estas opciones admiten baja latencia y simplifican el cumplimiento de los requisitos de soberanía de datos porque todos los datos de los usuarios se acceden y almacenan dentro de la misma geografía.
Para aprender más sobre estos paradigmas de implementación, consulte las siguientes páginas de paradigmas:
Usuarios distribuidos en múltiples geografías
Si los usuarios de tu aplicación están distribuidos en varias geografías, como entre EE. UU. y Europa, te recomendamos implementar en una o más regiones en cada geografía. El despliegue en una región de cada zona geográfica donde se atienden clientes garantiza baja latencia y disponibilidad en caso de una interrupción del servicio geográfica. También puede cumplir con los requisitos de soberanía de datos al realizar el particionamiento de sus datos para que los datos de los usuarios de cada región se alojen dentro de esa región.
Para garantizar una alta disponibilidad en caso de interrupciones regionales sin aumentar la latencia ni violar los requisitos de soberanía de los datos, también puedes implementar en varias regiones de cada zona geográfica. Se puede lograr la mayor disponibilidad para una implementación multiregión al implementar clústeres en múltiples regiones, en diferentes ubicaciones geográficas.
Para aprender más sobre estos paradigmas de implementación, consulte las siguientes páginas de paradigmas:
Usuarios distribuidos en todo el mundo
Si vas a implementar una aplicación para una audiencia mundial, te recomendamos implementar una implementación multiregión en múltiples geografías antes de considerar una implementación global. En casi todos los casos, una implementación multiregión en varias geografías puede cumplir tus requisitos de alta disponibilidad, baja latencia y soberanía de datos. En casos excepcionales, es posible que necesites implementaciones globales de Atlas, que son los paradigmas de implementación multiregión más complejos y requieren una planificación muy cuidadosa.
Para aprender más sobre estos paradigmas de implementación, consulta las siguientes páginas: