Alta disponibilidade e recuperação de desastres

01

Falhas vão acontecer: números de disponibilidade e pontos únicos de falha

Disponibilidade é a fração do tempo em que o seu serviço pôde ser usado. 99,9% parece bem alto, mas, em um ano, significa cerca de 8 horas e 45 minutos fora do ar. Cada 9 a mais corta para um décimo o tempo parado que você pode ter, e o custo e o projeto ficam mais difíceis na mesma medida.

Em série, ela cai; lado a lado, ela sobe

Um serviço é feito de vários componentes ligados entre si. Se a resposta precisa passar por um servidor web, depois por um servidor de app e depois por um banco de dados, os três precisam estar no ar. Por isso, a disponibilidade total é o produto da disponibilidade de cada componente. Ligue três componentes de 99,9% e você cai para cerca de 99,7%. Já com dois servidores iguais lado a lado, a camada só para se os dois pararem, e ela sobe para 99,9999% (supondo que os dois falham de forma independente). Na cena abaixo, experimente dobrar cada camada.

Um ponto em que uma única peça parando para tudo se chama ponto único de falha. Projetar para alta disponibilidade é encontrar os pontos únicos de falha e eliminá-los um por um. E não são só servidores. Um banco de dados, um balanceador de carga, um caminho de rede e até "a única pessoa que sabe como esse servidor está configurado" podem ser um ponto único de falha.

SLA é promessa de reembolso, não garantia

Cada serviço de nuvem promete um tempo de atividade mensal no seu SLA (acordo de nível de serviço). Aqui está a pegadinha: o SLA não garante que "vai funcionar com certeza esse tanto". Ele promete que "se a gente não cumprir, devolve parte da fatura em créditos". Ele não cobre o que você perde enquanto está fora do ar, então a disponibilidade do seu serviço tem que vir do seu projeto. Mesmo para o mesmo serviço, o SLA é maior quando você o distribui por várias zonas do que quando roda um servidor só.

Para eliminar o ponto único de falha, você passou de um servidor para dois. Mas e se os dois estiverem no mesmo prédio?

02

O tamanho da falha: servidores, zonas e regiões

Falhas têm tamanhos diferentes. Às vezes o disco de um servidor queima. Às vezes um data center inteiro para por queda de energia, incêndio ou falha de rede. E, de vez em quando, uma área geográfica inteira para por um desastre natural ou uma pane de grande escala. A área atingida por uma única falha se chama raio de impacto (blast radius).

A nuvem mostra essa área como zonas de disponibilidade e regiões. Uma região é uma área geográfica, como São Paulo ou Tóquio, e dentro dela há várias zonas de disponibilidade: grupos de data centers, cada um com energia, refrigeração e rede independentes. As zonas ficam perto o bastante para a replicação síncrona (alguns milissegundos de latência), mas longe o bastante para que um desastre em uma não se espalhe para a outra.

A maioria dos serviços em produção usa várias zonas como base. Elas ficam na mesma região, então a latência é baixa o bastante para replicar o banco de dados de forma síncrona, e você aguenta a falha de uma zona. Você só parte para várias regiões quando precisa aguentar também a falha de uma região (leis e regulamentações, ou um serviço muito grande), e o jeito de fazer isso são as estratégias de recuperação de desastres do capítulo 7.

Para decidir até onde aguentar, primeiro você precisa de uma meta. Quanto tempo você pode ficar fora do ar, e quantos dados pode perder?

03

O que proteger, e quanto: RTO e RPO

Quando você projeta a recuperação de desastres, há dois números para decidir antes de tudo. O RPO (objetivo de ponto de recuperação) é "quantos dados você pode perder quando algo falha", medido em tempo. O RTO (objetivo de tempo de recuperação) é "quanto tempo você pode ficar fora do ar".

Fica mais fácil se você colocar o momento da falha no meio. Olhando para trás, tudo desde o último ponto em que os dados ficaram protegidos (o último backup ou a última replicação) são os dados que você perde: esse é o RPO. Olhando para a frente, tudo até o serviço voltar é o tempo fora do ar: esse é o RTO. Na cena abaixo, experimente mudar o jeito de proteger os dados e o jeito de recuperar.

Essas duas metas são definidas pelo negócio, não pela tecnologia. Um sistema de pedidos perde muito se ficar parado nem que seja um minuto e não pode perder um único pedido, enquanto um sistema interno de relatórios pode ficar um dia parado sem problema. Quanto mais curta a meta, maior o custo, então você pesa perdas e custo para cada sistema. Se recuperar custa mais do que a falha faria você perder, a meta ficou alta demais.

Com as metas definidas, chegou a hora de não deixar o serviço parar. Primeiro, como fazer os servidores aguentarem quando as requisições chegam de uma vez.