Sharding e routing dell'applicazione cross region su AWS

3

Attualmente disponiamo di un monolite Multi Tenant molto semplice, con un backend SQL SERVER (Self ospitato su EC2 su AWS) e più servizi applicativi che parlano di un DB dietro un ELB Classic AWS. Il nostro database è cresciuto fino a un punto tale da prendere in considerazione la possibilità di suddividerlo per tenant per regione, a causa della crescita in diverse regioni e dei problemi di latenza, oltre alle considerazioni sulla finestra di manutenzione dei tempi di inattività. Vogliamo anche mantenere lo stesso DNS ... www.domain.com ad esempio per entrambe le regioni a causa di collegamenti esistenti ecc ...

Stiamo considerando ora

  1. Utilizza Cloudfront per eseguire il routing basato sul geo e la cache di base cdn davanti ai servizi, come un proxy di bordo di tipo
  2. Shard sql server in 2 regioni principali, Australia e Nord America, in base alla posizione del titolare.
  3. I servizi applicativi esistono su entrambe le regioni con db separato.
  4. Avere una tabella di shard magari nella dynamodb global table o s3 da qualche parte, e poiché abbiamo meno di qualche centinaio di inquilini, e per lo più immutabili, può essere messo in cache per un lungo periodo.

Area grigia principale, cosa posso fare quando il percorso va nella Regione / Db sbagliata?

Ad esempio, supponiamo di avere

  1. Inquilini da 1 a 10 in Australia
  2. Inquilini da 11 a 20 negli Stati Uniti

Il Tenant 1 è andato negli Stati Uniti per una vacanza e ha provato ad accedere a www.domain.com, in base al geo-routing, verrà indirizzato al datacenter USA, che nel database negli Stati Uniti non conterrà i suoi dati. Stavo pensando

  • In base all'utente di login, posso determinare il tenant (nel servizio dell'applicazione), quindi se si è loggato nella regione sbagliata, in base alla ricerca della tabella shard, risponderò a un reindirizzamento 304, magari con un un cookie di sorta, forse cloudfront, con lambda a bordo che può leggere e fare una logica di reindirizzamento extra? Non è ancora chiaro se è possibile o una buona soluzione.

Quali sono le migliori pratiche in merito? Penso che sarebbe un problema risolto ma non riesco a trovare nulla di più pratico con esempi con le mie cattive qualità di google, la maggior parte di loro sono come la teoria dei tavoli shard ecc ...

Qualunque consiglio sarebbe molto apprezzato.

    
posta Joshscorp 18.10.2018 - 08:18
fonte

1 risposta

2

Main grey area, what can I do when the route goes to the wrong Region/Db?

Re-instradali al DB corretto. Sembra semplice. Ma ...

Tenant 1 went to USA for a holiday and tried to access www.domain.com, based on geo routing, he will be routed to the USA datacenter, which in the database in USA will not contain his data.

... è solo la punta dell'iceberg. Diciamo che risolvi questo problema. Quindi ...

Tenant 2 went to USA and liked it so much they decided to stay. But now and forever more will find that your service is really laggy.

Ciò di cui hai bisogno è un sistema che trasformerà un errore di geo-routing in un nuovo percorso verso la home, ma eseguirà la migrazione dei dati dopo un determinato numero di errori di geo-routing. In questo modo le uniche persone che veramente ti infastidiscono non avendo un vero sistema distribuito sono volantini frequenti.

A quel punto devi chiedere: "quanto ci importa dei volantini frequenti?"

    
risposta data 23.10.2018 - 22:50
fonte

Leggi altre domande sui tag