Confiabilidade
Imagine que você executa um sistema clínico para uma organização de saúde. Os clínicos e os cuidadores têm pouca tolerância a tempo de inatividade. Eles precisam ter acesso aos sistemas de TI clínicos ininterruptamente para garantir que estejam sempre fornecendo serviços da mais alta qualidade.
Para atender às demandas imediatas dos médicos, os aplicativos precisam ser capazes de lidar com falhas com impacto mínimo para os usuários. Como manter os aplicativos operacionais em caso de incidentes localizados e em desastres em grande escala?
Nesta unidade, você aprende a incluir elementos do pilar da confiabilidade em seu design de arquitetura.
O que é confiabilidade?
Em um aplicativo complexo, podem ocorrer vários problemas em qualquer escala. Servidores e unidades de disco rígido individuais podem falhar. Um problema de implantação pode inadvertidamente remover todas as tabelas em um banco de dados. Datacenters inteiros podem ficar inacessíveis. Um incidente de ransomware pode, de modo mal-intencionado, criptografar todos os seus dados. É fundamental que seu aplicativo seja confiável e lide com incidentes de impacto amplo e localizado.
Projetar para confiabilidade inclui manter o tempo de atividade durante incidentes de pequena escala e condições temporárias, como interrupções parciais da rede. Você pode garantir que seu aplicativo lide com falhas localizadas integrando alta disponibilidade em cada componente. Esse design de aplicativo elimina pontos únicos de falha. Esse design também minimiza o impacto da manutenção da infraestrutura. Designs de alta disponibilidade normalmente têm como objetivo eliminar o impacto dos incidentes de maneira rápida e automática, além de garantir que o sistema possa continuar processando solicitações com pouco ou nenhum efeito.
O design que visa a confiabilidade também se concentra na recuperação após a perda de dados e desastres de escala maior. A recuperação desses tipos de incidentes geralmente envolve a intervenção ativa, embora as etapas de recuperação automatizadas possam reduzir o tempo necessário para a recuperação. Esses tipos de incidentes podem resultar em algum tempo de inatividade ou na perda permanente de dados. A recuperação de desastre exige cuidados com o planejamento e a execução.
Incluir alta disponibilidade e capacidade de recuperação no design da arquitetura protege sua empresa contra perdas financeiras resultantes de tempo de inatividade e perda de dados. Eles também protegem sua empresa de uma perda de reputação causada pela perda de confiança dos clientes.
Criar uma arquitetura para confiabilidade garante que seu aplicativo possa cumprir com os compromissos que você faz com seus clientes. Você quer garantir que seus sistemas estejam disponíveis aos usuários finais e possam se recuperar de quaisquer falhas.
Criar uma arquitetura altamente disponível
Para disponibilidade, identifique o SLA (Contrato de Nível de Serviço) com o qual está se comprometendo. Examine as possíveis capacidades de alta disponibilidade do aplicativo em relação ao seu SLA e identifique em que pontos você tem cobertura adequada e em quais precisa fazer aprimoramentos. Sua meta é adicionar redundância a componentes da arquitetura para que você tenha menos probabilidade de sofrer uma interrupção.
Exemplos de componentes de design de alta disponibilidade incluem clustering e balanceamento de carga:
Clustering substitui uma única VM por um conjunto de VMs coordenadas. Quando uma VM falha ou fica inacessível, os serviços podem fazer failover para outra que possa atender às solicitações.
O balanceamento de carga distribui solicitações entre muitas instâncias de um serviço, detectando instâncias com falha e impedindo que as solicitações sejam encaminhadas para elas.
Criar uma arquitetura que possa se recuperar de falhas
Para capacidade de recuperação, você deve executar uma análise que examine a possível perda de dados e os principais cenários de tempo de inatividade. Sua análise precisa incluir uma exploração das estratégias de recuperação e a relação custo/benefício de cada uma. Este exercício proporciona insights importantes sobre as prioridades da sua organização e ajudará a esclarecer a função do seu aplicativo. Os resultados de sua análise devem incluir esses valores de duração para seu aplicativo:
RPO (objetivo de ponto de recuperação): a duração máxima de perda de dados aceitável. O RPO é medido em unidades de tempo, não em volume. Por exemplo, "30 minutos de dados", "quatro horas de dados" e assim por diante. O RPO trata da limitação e da recuperação de dados perdidos, não de dados roubados.
RTO (objetivo de tempo de recuperação): a duração máxima de tempo de inatividade aceitável, em que "tempo de inatividade" é definido de acordo com sua especificação. Por exemplo, se a duração do tempo de inatividade aceitável for de oito horas no caso de desastre, o RTO será de oito horas.
Com o RPO e o RTO definidos, você pode criar funcionalidades de backup, restauração, replicação e recuperação em sua arquitetura para atingir esses objetivos.
Cada provedor de nuvem oferece um pacote de serviços e recursos que você pode usar para melhorar a disponibilidade e a capacidade de recuperação de seu aplicativo. Quando possível, use os serviços existentes e as melhores práticas, não crie seus próprios.
Unidades de disco rígido podem falhar, data centers podem ficar inacessíveis e hackers podem atacar. É importante manter uma boa reputação com seus clientes usando disponibilidade e capacidade de recuperação. Ter disponibilidade é manter o tempo de atividade durante condições como interrupções de rede. Capacidade de recuperação é recuperar os dados após um desastre.