Uma única instância do RDS é aceitável para locais com múltiplas geografias?

Question

Estou procurando criar uma infraestrutura multi-geográfica. Essencialmente, eu preciso servir um site para usuários dos EUA, UE e UA.

O desafio é que este site é ecommerce, por isso é necessário ler & acesso de gravação no banco de dados.

Até onde sei, há várias opções:

1. Tenha uma única instância do RDS (multi AZ) em um data center central (provavelmente na UE). Ter vários EC2 em cada território, que se conectam ao RDS.

2. Tenha um ambiente completo em cada território (RDS e EC2 separados, não conectados aos outros de forma alguma). Viva com o fato de que o usuário não pode compartilhar logins / dados entre territórios.

3. Ter EC2s executando o MySQL em cada território. Construa algo na camada de aplicativo para lidar com a sincronização entre os bancos de dados à medida que as gravações acontecem.

4. Tenha um RDS central que armazene todos os dados. Ter instâncias de RDS filho em cada território que abriga todos os dados somente leitura (dados do produto principalmente). Crie algo na camada do aplicativo para que as consultas específicas do produto aconteçam no banco de dados local, mas as gravações acontecem na instância central do RDS.

No momento, a opção nº 1 parece ser a mais sensata, mas não tenho certeza da latência real entre os data centers e não consigo fornecer informações confiáveis sobre ela.

Não. 2 é limitante, mas uma possibilidade.

Não. 3 está cheio de possíveis problemas com a sincronização que não funciona conforme o esperado.

Não. 4 é possível, mas exigirá substancial refatoração da camada de aplicação, o que poderia, por si só, levar a problemas.

Qual é a melhor abordagem aqui? Estou faltando opções? A latência entre os data centers é "aceitável"?

    

Answer 1

Opções

A opção 2 não pode ser confiável em um único URL, pois dependeria de geolocalização. A geolocalização não selecionará com confiança o mesmo servidor para um determinado usuário ao longo do tempo. Para isso, você precisaria de URLs diferentes para cada região.

Você perdeu várias opções:

5. Use uma instância central do RDS para gravações, com réplicas de leitura em cada região.
6. Use a replicação incorporada do MySQL, em vez dos recursos da AWS. Eu não sei se você pode fazer isso com o RDS - eu suspeito que você teria que executar o MySQL no EC2. Isso é semelhante ao # 4, mas não exatamente o mesmo.
7. Tenha uma única instância / cluster do EC2 e uma instância do RDS. Acelere o aplicativo usando uma distribuição de conteúdo, como o CloudFront.

Análise de opções

Eu sempre usaria a opção mais simples primeiro, que nesse caso é o EC2 e o RDS no mesmo local, usando um CDN para aumentar o desempenho. Você não disse por que acha que precisa de vários servidores de aplicativos em regiões diferentes, por isso estou confuso por que você pulou direto para opções relativamente complexas.

Se um único local não atender às necessidades de desempenho, você poderia considerar colocar servidores de aplicativos em cada região com um único banco de dados RDS. Isso pode ser mais rápido, depende do comportamento do seu aplicativo. Você teria que avaliar.

Só então eu consideraria a complexidade adicional de vários bancos de dados.

Réplicas de leitura

Se você tiver controle sobre o aplicativo, criaria a capacidade de ter URLs de banco de dados diferentes para leitura e gravação desde o início. Isso permite que você se mova para ler réplicas mais tarde, se precisar.