Fiabilidade
Imagine que é responsável pela gestão de um sistema clínico numa organização de cuidados de saúde. Os médicos e prestadores de cuidados têm pouca tolerância para períodos de inatividade. Eles precisam ter acesso a sistemas de TI clínicos o tempo todo para garantir que estão sempre prestando cuidados da mais alta qualidade.
Para satisfazer as necessidades constantes dos médicos, as aplicações têm de gerir as falhas com um impacto mínimo para os utilizadores. Como é que mantêm as suas aplicações operacionais, tanto no que diz respeito a incidentes localizados como a desastres em grande escala?
Nesta unidade, você aprende a incluir elementos do pilar de confiabilidade em seu projeto de arquitetura.
O que é fiabilidade?
Numa aplicação complexa, várias coisas podem correr mal em qualquer escala. Os servidores individuais e as unidades de disco rígido podem falhar. Um problema de implementação pode inadvertidamente remover todas as tabelas numa base de dados. Datacenters completos podem ficar inacessíveis. Um incidente de ransomware pode encriptar maliciosamente todos os seus dados. É fundamental que a sua aplicação se mantenha fiável e tenha a capacidade de lidar com incidentes de impacto localizado e amplo.
A conceção com vista à fiabilidade inclui manter o tempo de atividade durante incidentes de pequena escala e condições temporárias, como indisponibilidade parcial da rede. Você pode garantir que seu aplicativo lide com falhas localizadas integrando alta disponibilidade em cada componente. Este design de aplicativo elimina pontos únicos de falha. Uma conceção deste tipo minimiza também o impacto da manutenção da infraestrutura. Os projetos de alta disponibilidade normalmente visam eliminar o impacto de incidentes de forma rápida e automática e garantir que o sistema possa continuar a processar solicitações com pouco ou nenhum efeito.
A conceção com vista à fiabilidade também se centra na recuperação da perda de dados e de desastres de grande escala. A recuperação destes tipos de incidentes envolve, muitas vezes, uma intervenção ativa, ainda que os passos de recuperação automática possam reduzir o tempo necessário para recuperar. Este tipo de incidentes pode resultar em algum tempo de inatividade ou na perda definitiva de dados. A recuperação após desastre foca-se tanto no planeamento cuidadoso como na execução.
A inclusão de alta disponibilidade e capacidade de recuperação em seu projeto de 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 por uma perda de confiança de seus clientes.
Arquitetar com o objetivo de obter fiabilidade garante que a sua aplicação consegue cumprir os seus compromissos para com os clientes. Você deseja garantir que seus sistemas estejam disponíveis para os usuários finais e possam se recuperar de quaisquer falhas.
Criar uma arquitetura de elevada disponibilidade
Para disponibilidade, identifique o contrato de nível de serviço (SLA) com o qual você está se comprometendo. Examine os recursos potenciais de alta disponibilidade do seu aplicativo em relação ao seu SLA e identifique onde você tem cobertura adequada e onde precisa fazer melhorias. O objetivo é adicionar redundância a componentes da arquitetura para que exista uma menor probabilidade de ocorrer indisponibilidade.
Exemplos de componentes de design de elevada disponibilidade incluem o clustering e o balanceamento de carga:
O clustering substitui uma única VM com um conjunto de VMs coordenadas. Quando uma VM falha ou fica inacessível, os serviços podem efetuar a ativação pós-falha para outra que possa processar os pedidos.
O balanceamento de carga distribui os pedidos entre várias instâncias de um serviço, ao detetar instâncias de falha e ao impedir que os pedidos sejam encaminhados para elas.
Criar uma arquitetura que possa recuperar de falhas
Para a capacidade de recuperação, deve executar uma análise que examine a sua possível perda de dados e os principais cenários de tempo de inatividade. A análise deve incluir uma exploração das estratégias de recuperação e a desvantagem custo-benefício para cada uma. Este exercício fornece informações importantes sobre as prioridades da sua organização e ajuda a esclarecer o papel do seu aplicativo. Os resultados da sua análise devem incluir estes valores de duração para a sua aplicação:
RPO (Recovery Point Objetive, objetivo de ponto de recuperação): a duração máxima da perda de dados aceitável. O RPO é medido em unidades de tempo, não em volume. Os exemplos são "30 minutos de dados", "quatro horas de dados" e assim sucessivamente. O RPO tem que ver com limitação e recuperação de uma perda de dados e não de furto de dados.
RTO (Recovery Time Objetive, objetivo de tempo de recuperação): a duração máxima do tempo de inatividade aceitável, em que sua especificação define "tempo de inatividade". Por exemplo, se a duração aceitável do tempo de inatividade for de oito horas em caso de desastre, o RTO será de oito horas.
Com o RPO e o RTO definidos, pode criar funcionalidades de backup, restauro, replicação e recuperação na sua arquitetura para atingir estes objetivos.
Cada fornecedor de cloud oferece um conjunto de serviços e funcionalidades que pode utilizar para melhorar a disponibilidade e a capacidade de recuperação da sua aplicação. Sempre que possível, utilize os serviços existentes e as melhores práticas e tente não criar os seus próprios.
As unidades de disco rígido podem falhar, os datacenters podem tornar-se inacessíveis e os hackers podem atacar. É importante que mantenha uma boa reputação junto dos clientes através da disponibilidade e capacidade de recuperação. A disponibilidade centra-se em manter o tempo de atividade em condições como falhas de rede e a capacidade de recuperação foca-se na obtenção de dados após um desastre.