Comecemos com o que 4 9’s significa exatamente:
Four Nines é 4,38 minutos de inatividade por mês, ou 52,56 minutos por ano.
Isso é provavelmente mais do que aceitável para quase todos os serviços na Internet, não todos, mas quase todos. Portanto, o seu e-mail fica 4 minutos em baixo a cada mês, não no fim do mundo. Quero dizer, você provavelmente nem iria notar. Quando você for verificar no Twitter se é só você ou não, ele já estará de volta.
Tipicamente para ter um bom tempo de atividade, pensamos em adicionar redundância e replicação, então se um servidor falhar, você já tem outros rodando que imediatamente assumem o controle. O problema com esta abordagem é que ela é complicada e cara. Você precisa de vários servidores, geralmente 3 ou mais, tanto para o seu aplicativo quanto para o seu banco de dados, além de precisar de um balanceador de carga na frente dele. E então você precisa gerenciar/monitorar todas essas máquinas.
E com a nova tendência Microservices onde as pessoas estão dividindo seus aplicativos em serviços menores, você tem que repetir essas configurações complicadas para cada serviço.
Se você está construindo um Microservice, quanto menos “coisas” você precisar para executá-lo, melhor. Você não quer ter que ir configurar uma nova base de dados replicada toda vez que quiser juntar uma pequena API, não é mesmo? Eu quero ser super produtivo, eu quero ser capaz de iniciar um serviço rapidamente sem ter que lidar com todas as coisas complicadas, perdendo tempo com operações.
Então eu comecei a pensar, “bem, e se houver uma maneira de ser… confiável o suficiente?” Quero dizer, quantas das coisas que você constrói realmente precisam estar altamente disponíveis? Quantos serviços não podem se dar ao luxo de ficar em baixo por alguns minutos aqui e ali ou perder um pouquinho de dados uma vez na lua azul devido a uma falha fatal do servidor?
O meu palpite é que não há muitos serviços que não podem perder uma quantidade muito pequena de dados e ter alguns minutos de downtime por ano. Mesmo se você arquitetar o seu serviço, você provavelmente ainda terá tempo de inatividade por alguma razão. Então, porque não manter simples.
Primeiro, alguns números: digamos, em média, uma instância AWS EC2 falha a cada seis meses. Eu acho que é muito menos do que isso hoje em dia, mas ninguém sabe realmente, então vamos ser conservadores. Isso nos dá aproximadamente 26,5 minutos para recuperar a aplicação a cada seis meses enquanto ainda temos 4 9’s de uptime.
Aqui está como você pode obter 4 9’s em uma única máquina.
Passo 1) Launch Server, Deploy App e Change DNS Script
A primeira coisa que precisamos é de um script simples que possa lançar uma nova instância, iniciar a aplicação (Docker torna isso fácil) e alterar o DNS para apontar para a nova instância. Eu não vou entrar em detalhes sobre este passo neste post, mas se você puder fazer um script de um liner que possa fazer esses passos, você é bom. Serviço falha: execute script.
Passo 2) Base de dados com backup automático e recuperação automática
Se você pode garantir que tem backups muito recentes da sua base de dados e estes são armazenados em um local de fácil acesso como o S3, então você pode criar um aplicativo que pode se recuperar quando ele é iniciado. Usar um banco de dados incorporado torna tudo mais simples, já que você só precisa implantar uma única coisa: seu aplicativo.
I’ve been using BoltDB a lot lately, mostly because I write a lot of Go and Bolt is a simple embedded database available in a Go package that you use like any other dependency. Assim não tem de correr uma base de dados separada à qual se liga e tem de lidar para a manter a correr. Você apenas usa a biblioteca e os dados são escritos no seu disco local.
Agora esse também é o problema com Bolt, os dados estão apenas na sua máquina local ao lado da sua aplicação. Se a máquina falhar, você perde todos os seus dados.
Bem, que tal fazer uma cópia de segurança a cada minuto ou 2? E ser capaz de recuperar automaticamente desse backup quando a aplicação inicia?
Criei uma biblioteca que faz exatamente isso, chamada Bolt Backup e apenas alterando a linha de inicialização do BoltDb, ele irá automaticamente fazer o backup da sua base de dados para S3 e melhor ainda, quando você iniciar a aplicação, ele irá recuperar a partir do backup mais recente.
Você pode facilmente testar isso, adicionando dados à sua base de dados Bolt, matando a sua aplicação, apagando o arquivo de dados Bolt e, em seguida, reiniciando a sua aplicação. Ele continuará de onde parou, não importa onde você iniciar seu aplicativo novamente.
Aqui está um exemplo de aplicativo usando isto que você pode tentar: https://github.com/treeder/bolt-backup/tree/master/example
Conclusion
Com os conceitos simples acima, você pode recuperar sua aplicação em menos de 26 minutos e, portanto, alcançar 4 9’s ou melhor de tempo de atividade. Apenas certifique-se de que é tudo automatizado com um script de lançamento e recuperação automática de banco de dados como a biblioteca Bolt Backup mencionada acima.
O valor da simplicidade pode às vezes se perder quando ficamos todos entusiasmados com a “escala web”, mas muitas vezes você pode economizar muito tempo e luto se você mantiver as coisas simples. E muito dinheiro.