Lo mejor es siempre una cuestión de opinión, y especialmente una cuestión de medir y volver a medir. Y también en su definición de agrupamiento.
Una consideración importante es su infraestructura (¿está ejecutando en AWS / Azure / etc, o está autohospedado?). Los proveedores de la nube proporcionan varias herramientas que puede usar para manejar consideraciones geográficas. Considere, por ejemplo, una solución basada en DNS como AWS Route 53. Por lo general, estas soluciones emplean algo como Anycast, donde varios nodos dan servicio a la misma IP.
- ¿Cómo se asegura que el aprendizaje automático no aprenda la correlación cuando no hay causalidad, especialmente para la predicción?
- ¿Qué es la transformación logarítmica en el análisis de regresión?
- ¿Qué es el procesamiento de señales y cómo se relaciona con el aprendizaje automático?
- ¿Cómo se puede usar el aprendizaje profundo para la detección de eventos anormales en los videos?
- ¿Necesitamos aplicar una prueba de significación estadística en el aprendizaje automático?
(Figura) Unicast vs Anicast. En cualquier difusión, varios nodos pueden dar servicio a la misma IP.
Luego, los proveedores de la nube tienen centros de datos regionales (bajo varios nombres, para AWS son zonas de disponibilidad). Puede colocar sus servidores en varios centros de datos, luego usar DNS para conectarse a la región más cercana según la ubicación del cliente. Es importante tener en cuenta que algunas soluciones se ajustan en función de la latencia observada, por lo que no se garantiza que se conecte a la región físicamente más cercana. Esto normalmente se desea, pero puede causar problemas legales (se indica más adelante en la respuesta)
En cuanto a la agrupación, depende. Idealmente, su solución no tendría estado (o el estado se mantendría en el cliente), por lo que cambiar de un punto final en una región a un punto final en otra no causaría ningún tiempo de inactividad. Si no está apátrida, es posible que necesite usar un equilibrador de carga, como ELB, ya que admite conexiones “fijas”, pero existen varias complicaciones debido a la limitación de ELB. Lo mejor que puedes hacer es mantenerte apátrida.
Las bases de datos generalmente son el dolor de cabeza, especialmente si intenta sincronizar las escrituras en todas las regiones. Con los servicios en la nube, a menos que necesite soluciones basadas en bases de datos de terceros, el proveedor de la nube generalmente le proporciona un DaaS (bases de datos como servicio) que se ocupa de esto en cierta medida (no espere que infrinjan las leyes) de física y computación, y sincronice instantáneamente sus datos en todas las regiones al instante). Hay otros enfoques (tal vez mantener una sola instancia de la base de datos en algún lugar del mundo, mantener una instancia de conmutación por error en otro lugar. Esto resolvería el problema de sincronización, pero agregaría latencia entre los servicios y la base de datos y el potencial de pérdida de datos cuando se produce una falla) a la copia de seguridad, ya que la copia de seguridad puede no estar totalmente sincronizada, se trata de compensaciones, y también son posibles otras arquitecturas).
Hay algunas soluciones interesantes en torno a la agrupación, que vale la pena considerar. En estas soluciones, agrega soporte de agrupamiento a su aplicación, en lugar de fuera de la aplicación. Ver por ejemplo Akka Clustering. Creo que este tipo de soluciones son más fáciles de probar y escalar entre desarrollo y producción. No resuelven sus problemas regionales, pero abordan el “agrupamiento” en su pregunta. También lo mantienen algo independiente del proveedor de la nube. Vea el caso de estudio Apache Gearpump (anteriormente Intel Gearpump).
Tenga en cuenta que existen consideraciones regionales (debido a la legislación) donde los datos pueden no salir de ciertas regiones. Eso generalmente está relacionado con la información de identificación personal, por lo que si recopila este tipo de información, debe consultar a alguien que conozca las implicaciones. Por lo tanto, es posible que algunos datos no puedan ir al centro de datos más cercano (en cuanto a velocidad). Hay varias complicaciones (que pueden o no haber sido aclaradas, no me he mantenido al día con esto) con respecto a los usuarios que viajan dentro y fuera de estas regiones.
De todos modos, no hay una solución única, necesita construir para sus necesidades. Tienes que considerar todo lo que estás tratando de resolver. ¿Latencia, resistencia, regulaciones? Luego, debe desarrollar una estrategia para la disponibilidad entre AZ, la disponibilidad entre regiones y la disponibilidad de WW. La medida en que tome esto depende de sus necesidades.
Te sugiero que leas esto:
Un estudio de caso en aislamiento global de fallas
Superar interrupciones en AWS: arquitecturas de alta disponibilidad
Espero que esto ayude, pero me temo que es demasiado superficial y un poco por todos lados.
