Qual é uma boa estratégia para manter meu site online quando o S3 ficar offline?

Qual é uma boa estratégia para manter meu site online quando o S3 ficar offline?

Se o S3 Leste dos EUA 1 ficar offline, como devo ter meu aplicativo configurado / estruturado para impedir que meu site inteiro fique offline?

Quais são as melhores estratégias para diversificar nesse tipo de situação?

Em março de 2015, o Amazon AWS anunciou que suporta a replicação S3 entre regiões. Quando uma determinada região do S3 fica offline, você pode servir arquivos do seu espelho em outra região.

^{fonte: https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/}

A prática de manter sua infraestrutura on-line, alternando para outra região é complexa, mas o S3 é um componente relativamente pequeno e simples. A Netflix tem um ótimo artigo sobre sua experiência com o Chaos Gorilla.

Isso também se aplica à degradação do serviço, como maior latência. Não apenas quando um serviço do qual você depende está completamente offline. A Netflix também tem um artigo sobre isso: Chaos Engineering Upgrade .

O que você está pedindo é, basicamente, alta disponibilidade. Para tornar um sistema altamente disponível, você precisa de três coisas:

1. Elimine pontos únicos de falha
2. Um mecanismo para alternar de um terminal para outro
3. Uma maneira de detectar falhas

Elimine pontos únicos de falha

No caso do S3, o ponto 1 é abordado, como Evgeny apontou, pela replicação entre regiões do S3 .

A replicação, no entanto, não é instantânea e você deve verificar se deseja conscientizar ou não a replicação do aplicativo. No caso de uma interrupção, é possível que algo que foi gravado no seu bucket de origem ainda não o tenha feito (não foi replicado) no bucket de destino. Você precisa pensar em como o aplicativo lidaria com esse cenário. Isso realmente depende do tipo de dados, do que está sendo feito com eles e (potencialmente) dos usuários finais ou das expectativas de gerenciamento.

Um mecanismo para alternar de um terminal para outro

Para o S3, isso significa que, no caso de uma interrupção, você deseja que o aplicativo pare de ler e gravar do / para o intervalo A e use o intervalo B.

Como conseguir isso, até onde eu sei, depende de você por enquanto. Alguns outros serviços da AWS oferecem failovers completamente transparentes, mas não estou ciente disso no S3 no momento.

Existem várias maneiras de conseguir isso. Um exemplo é o uso de um proxy que direcionará o tráfego para o bucket apropriado. Durante uma interrupção, você atualizaria / alteraria o proxy para rotear o tráfego para um bucket não afetado pela interrupção. Outro exemplo seria tornar a configuração do aplicativo dinâmica e armazená-la em um armazenamento de valores-chave. Se o aplicativo ler o repositório KV para obter as propriedades atualizadas com bastante frequência, você poderá mudar de onde lê e grava (o Spring Cloud tem suporte para um ouvinte "EnvironmentChange", por exemplo).

Uma maneira de detectar falhas

Bem, esse é fácil, eu acho. Basta configurar um loop de gravação + leitura e alertar assim que algo não estiver certo :)

Notas finais

• Se seu aplicativo estiver gravando no bucket, você deverá pensar no que aconteceria no caso de um failover. Todas as gravações chegaram ao depósito de destino (e você pode dizer)? Você pode permitir gravações no bloco de destino (tornando-o o novo "primário")? Um planejamento cuidadoso evitará cenários de atualizações de cérebro dividido ou perdidos.
• Dependendo do seu SLA, convém que os pontos 2 e 3 sejam automatizados ou automáticos. Isso requer planejamento, ferramentas e testes adicionais, mas scripts bem escritos sempre reagirão mais rápido e de maneira mais previsível do que a capacidade humana (as falhas também têm o hábito irritante de acontecer no meio da noite, quando a intervenção humana é algo perigoso.
• Vale ressaltar que mesmo a replicação entre regiões não elimina completamente os pontos únicos de falha. Claro, se uma região cair, você estará coberto. Mas e se ocorrer uma interrupção na AWS nos EUA? O Azure teve uma interrupção parcial, mas global, no ano passado e uma em 2014 também.