Sobre práticas de topologia de nuvem confiáveis e resilientes

A arquitetura de um aplicativo confiável na nuvem geralmente é diferente de uma arquitetura de aplicativo tradicional. Embora historicamente você possa ter comprado hardware redundante de ponta para minimizar a chance de uma plataforma de aplicativo inteira falhar, na nuvem, é importante reconhecer antecipadamente que as falhas acontecerão. Em vez de tentar evitar falhas por completo, o objetivo é minimizar os efeitos de um único componente com falha (ponto único de falha ou SPOF). Siga essas melhores práticas para aumentar a confiabilidade em cada etapa do seu processo de design.

Aplicações confiáveis são:

Resiliente e recupere normalmente de falhas, e elas continuam a funcionar com o mínimo de tempo de inatividade e perda de dados antes da recuperação total.
Altamente disponível (HA) e executado conforme projetado em um estado íntegro, sem tempo de inatividade significativo.
Protegido contra falha da Região por meio de um bom design de recuperação de desastres (DR).

Entender como esses elementos funcionam juntos e como eles afetam os custos é essencial para criar uma aplicação confiável. Ele pode ajudá-lo a determinar quanto tempo de inatividade é aceitável, o custo potencial para o seu negócio e quais funções são necessárias durante uma recuperação.

Arquiteto para Confiabilidade

Ao criar um aplicativo em nuvem, use o seguinte para aumentar a confiabilidade.

Definir os requisitos.
Defina seus requisitos de disponibilidade e recuperação com base nas cargas de trabalho que você está trazendo para a nuvem e as necessidades de negócios.
Aplique as melhores práticas de arquitetura.
Siga práticas comprovadas, identifique possíveis pontos de falha na arquitetura e determine como o aplicativo responderá à falha.
Teste com simulações e failovers forçados.
Simule falhas, acione failovers forçados e teste a detecção e a recuperação dessas falhas.
Implantar aplicativos de forma consistente.
Liberar para a produção usando processos confiáveis e repetíveis e automatizar sempre que possível.
Monitore a integridade do aplicativo.
Detecte falhas, monitore indicadores de possíveis falhas e avalie a integridade de seus aplicativos.
Gerencie falhas e desastres.
Identifique quando ocorre uma falha e determine como resolvê-la com base em estratégias estabelecidas.

Definir os Requisitos

Defina seus requisitos de disponibilidade e recuperação com base nas cargas de trabalho que você está trazendo para a nuvem e as necessidades de negócios.

Considere o seguinte ao identificar suas necessidades de negócios e combine seu plano de confiabilidade com elas:

Identificar cargas de trabalho e seus requisitos
Uma carga de trabalho é um recurso ou uma tarefa distinta que é logicamente separada de outras cargas de trabalho, em termos de lógica de negócios e requisitos de armazenamento de dados. Cada carga de trabalho tem diferentes requisitos de disponibilidade, escalabilidade, consistência de dados e recuperação de desastres.
Determinar padrões de uso
A forma como um aplicativo é usado desempenha um papel nos requisitos. Identifique diferenças nos requisitos durante períodos críticos e não críticos. Por exemplo, um processamento de final de mês de tratamento de aplicativos não pode falhar durante o final do mês, mas pode tratar a falha em outros momentos. Para garantir o tempo de atividade, componentes adicionais ou redundância podem ser adicionados durante períodos críticos e removidos quando não agregam mais valor.
Identificar componentes e caminhos críticos
Nem todos os componentes do seu sistema podem ser tão importantes quanto outros. Por exemplo, você pode ter um componente opcional que adiciona valor incremental, mas a carga de trabalho pode ser executada sem, se necessário. Entenda onde estão esses componentes e, inversamente, onde estão as partes críticas da sua carga de trabalho. Isso ajudará a definir o escopo de suas métricas de disponibilidade e confiabilidade e a planejar suas estratégias de recuperação para priorizar os componentes de maior importância.
Identificar dependências externas e o efeito da falha downstream
Se sua carga de trabalho depender de serviços externos, uma falha nessas dependências poderá afetar negativamente a disponibilidade da carga de trabalho. Implementar métodos de dissociação da integração para isolar contra falhas a jusante.
Determine os requisitos de disponibilidade de carga de trabalho
A alta disponibilidade (HA) é normalmente definida em termos de uma meta de tempo de atividade. Uma meta de alta disponibilidade de 99%, por exemplo, significa que um recurso específico pode ficar indisponível por 3,65 dias em um ano. O OCI (Oracle Cloud Infrastructure) foi projetado para fornecer a você um ambiente altamente disponível. A OCI publica um SLA (Service Level Agreement) para cada um de seus serviços, que descreve os compromissos da Oracle com relação ao tempo de atividade e conectividade com esses serviços, e você deve revisá-los para ver como eles atendem aos seus requisitos. Alguns serviços na OCI têm altos níveis de HA incorporados, particularmente serviços gerenciados pela Oracle, como o banco de dados autônomo. Para garantir que uma arquitetura de aplicativo atenda aos seus requisitos de negócios, defina SLAs de destino para cada carga de trabalho, incluindo dependências externas. Contabilizar o custo e a complexidade de atender aos requisitos de disponibilidade, além das dependências do aplicativo.
Estabeleça suas métricas de recuperação — RTO (Recovery Time Objective) e RPO (Recovery Point Objective)
RTO é o tempo máximo aceitável que um aplicativo pode ficar indisponível após um incidente de desastre.

RPO é a duração máxima de perda de dados aceitável durante um desastre.

Para derivar esses valores, faça uma avaliação de risco e certifique-se de entender o custo e o risco de tempo de inatividade ou perda de dados em sua organização.

Os backups incrementais para armazenamento fornecem segurança contra perda de dados por meio de pontos de recuperação. O período entre cada backup limita a quantidade máxima de dados perdidos após a restauração de um backup.

Por exemplo, considere o uso de uma das políticas de backup predefinidas da Oracle para armazenamento do OCI Block Volumes: Bronze, Silver e Gold. Cada política de backup é composta de programações com uma frequência de backup incremental definida, como mensal, semanal ou diária, e um período de retenção definido.
Definir um Desastre
Ter planos e requisitos de recuperação de desastres bem documentados é importante, mas a natureza caótica de tal evento pode criar confusão. Entenda o que constitui um desastre para sua empresa, identifique as principais funções que serão necessárias durante um desastre e estabeleça um plano de comunicação bem definido para iniciar uma resposta a desastres.
Considerar Custos
Do ponto de vista do FinOps, considere as implicações de custo de diferentes estratégias de confiabilidade. Isso ajuda você a fazer escolhas informadas sobre seus requisitos de disponibilidade e recuperação.

Aplicar Melhores Práticas de Arquitetura

Ao projetar sua arquitetura, concentre-se na implementação de práticas que atendam aos requisitos de negócios, identifique pontos de falha e minimize o escopo de falhas.

Considere as seguintes práticas recomendadas:

Determinar onde as falhas podem ocorrer
Analise sua arquitetura para identificar os tipos de falhas que seu aplicativo pode experimentar, os efeitos potenciais de cada um e possíveis estratégias de recuperação.
Determine o nível de redundância necessário, com base em seus requisitos de HA e DR
O nível de redundância necessário para cada carga de trabalho depende das suas necessidades de negócios e fatores no custo geral do seu aplicativo.
Design para escalabilidade
Um aplicativo em nuvem deve ser capaz de escalar para acomodar alterações no uso. Comece com componentes discretos e crie o aplicativo para responder automaticamente às alterações de carga sempre que possível. Mantenha os limites de escala em mente durante o design para que você possa expandir facilmente no futuro.
Usar balanceamento de carga para distribuir solicitações
O balanceamento de carga distribui as solicitações do seu aplicativo para instâncias de serviço íntegras, removendo instâncias não íntegras da rotação. A externalização das informações de estado tornará o dimensionamento de backend transparente para o usuário final. Se o estado for rastreado na sessão, a persistência pode ser necessária.
Crie requisitos de disponibilidade e resiliência em seu design
Resiliência é a capacidade de um sistema de se recuperar de falhas e continuar a funcionar. Disponibilidade é a proporção de tempo que seu sistema está funcional e funcionando. Implemente as melhores práticas de alta disponibilidade, como evitar pontos únicos de falha e decompor cargas de trabalho por objetivo de nível de serviço. Utilize os recursos padrão de sua camada de dados, como continuidade de aplicativos e transações assíncronas para garantir disponibilidade e resiliência.
Implementar DR
Projete sua solução para atender aos requisitos de RTO e RPO identificados. Certifique-se de que você possa colocar todos os componentes da sua solução de DR on-line dentro do seu RTO. Proteja seus dados para que você possa atender ao seu RPO. A forma como você armazena, faz backup e replica dados é fundamental.
- Faça backup de seus dados
  Mesmo com um ambiente de DR totalmente replicado, os backups regulares ainda são críticos. Faça backup e valide dados regularmente e certifique-se de que nenhuma conta de usuário tenha acesso a dados de produção e backup.
- Escolha métodos de replicação para os dados do seu aplicativo
  Os dados do aplicativo são armazenados em vários armazenamentos de dados e podem ter requisitos de disponibilidade diferentes. Avalie os métodos e os locais de replicação de cada tipo de armazenamento de dados para garantir que eles atendam aos seus requisitos de HA e RPO.
- Entenda as implicações do failover e seu efeito na prontidão para desastres
  Você precisará instanciar outra região para replicação a fim de atender aos requisitos de suas cargas de trabalho? Você precisará se preocupar com a consistência dos dados após o failback?
- Documente e teste seus processos de failover e failback
  Documente claramente as instruções para falhar em um novo armazenamento de dados e teste-as regularmente para garantir que sejam precisas e fáceis de seguir.
- Garanta que seu plano de recuperação de dados atenda ao seu RTO
  Certifique-se de que sua estratégia de backup e replicação forneça tempos de recuperação de dados que atendam ao seu RTO, bem como ao seu RPO. Conta para todos os tipos de dados que seu aplicativo usa, incluindo dados de referência, arquivos e bancos de dados.

Teste Periodicamente com Simulações e Failovers Forçados

O teste de confiabilidade requer a medição do desempenho da carga de trabalho de ponta a ponta em condições de falha que ocorrem apenas intermitentemente.

Testar cenários de falha comuns acionando falhas reais ou simulando-os
Use testes de injeção de falhas para testar cenários comuns (incluindo combinações de falhas) e tempo de recuperação.
Identificar falhas que ocorrem somente sob carga
Teste a carga máxima, usando dados de produção ou dados sintéticos o mais próximo possível dos dados de produção, para ver como o aplicativo se comporta em condições reais.
Executar drills de recuperação de desastre
Tenha um plano de recuperação de desastres em vigor e teste-o periodicamente para garantir que ele funcione.
Executar teste de failover e failback
Verifique se os serviços dependentes do seu aplicativo falharam e falharam na ordem correta.
Executar testes de simulação
Testar cenários da vida real pode destacar problemas que precisam ser resolvidos. Os cenários devem ser controláveis e sem interrupções para o negócio. Informar o gerenciamento dos planos de teste de simulação.
Testes de integridade
Configure investigações de integridade para balanceadores de carga e gerenciadores de tráfego para verificar componentes críticos do sistema. Teste-os para garantir que eles respondam adequadamente.
Testar sistemas de monitoramento
Certifique-se de que os sistemas de monitoramento estejam relatando de forma confiável informações críticas e dados precisos para ajudar a identificar possíveis falhas.
Incluir serviços de terceiros em cenários de teste
Teste possíveis pontos de falha devido a interrupção do serviço de terceiros, além da recuperação.
Aprenda com os problemas encontrados durante os testes
Se os testes revelarem problemas ou lacunas, certifique-se de que eles sejam identificados e abordados adicionando monitoramento adicional ou ajustando os processos operacionais.

Implantar Aplicativos de Forma Consistente

A implantação inclui o provisionamento de serviços e recursos do Oracle Cloud Infrastructure (OCI), a implantação do código do aplicativo e a aplicação de definições de configuração. Uma atualização pode envolver todas as três tarefas ou um subconjunto delas.

Automatize seu processo de implantação de aplicativos
Automatize o maior número possível de processos. Se possível, implementações manuais em produção devem ser eliminadas, embora isso possa ser aceitável em ambientes mais baixos para promover velocidade e flexibilidade.
Aproveite a automação para testar seu código antes da implantação
O teste de bugs, vulnerabilidades de segurança, funcionalidade, desempenho e integrações é fundamental para minimizar os problemas que os usuários finais descobrem. As falhas de teste devem impedir que o código seja liberado na produção.
Projete seu processo de lançamento para maximizar a disponibilidade
Se o processo de liberação exigir que os serviços fiquem off-line durante a implantação, seu aplicativo ficará indisponível até que eles voltem on-line. Aproveite os recursos de preparação e produção da plataforma. Se possível, libere novas implantações em um subconjunto de usuários para monitorar falhas de hora inicial.
Ter um plano de rollback para implantação
Projete um processo de rollback para retornar a uma última versão válida conhecida e minimizar o tempo de inatividade se uma implantação falhar. A automação do rollback na implantação com falha pode evitar tempo de inatividade desnecessário.
Implantações de log e auditoria
Se você usar técnicas de implantação preparada, mais de uma versão do seu aplicativo estará em execução na produção. Implemente uma estratégia robusta de registro em log para capturar o máximo possível de informações específicas da versão.
Documente o processo de liberação do aplicativo
Defina e documente claramente seu processo de liberação e certifique-se de que ele esteja disponível para toda a equipe de operações.

Monitorar a Integridade do Aplicativo

Implemente as melhores práticas de monitoramento e alertas em seu aplicativo para que você possa detectar falhas e alertar um operador para corrigi-las.

Implementar rastreamento em torno de chamadas de serviço
Os dados de desempenho da linha de base podem ajudar a fornecer dados de tendência que podem ser usados para identificar proativamente problemas de desempenho antes que eles afetem os usuários.
Implementar investigações de integridade
Execute-os regularmente de fora da aplicação para identificar a degradação da integridade e do desempenho da aplicação. Essas sondas devem ser mais do que apenas testes de página estáticos, elas devem refletir a integridade holística da aplicação.
Verificar workflows de longa execução
Pegar problemas antecipadamente pode minimizar a necessidade de reverter todo o fluxo de trabalho ou executar várias transações de compensação.
Manter logs de sistema, aplicativo e auditoria
Utilize um serviço de log centralizado para armazenar seus logs.
Configurar um sistema de aviso prévio
Identifique os principais indicadores de desempenho (KPIs) da integridade de um aplicativo, como exceções transitórias e latência de chamada remota, e defina valores de limite apropriados para cada um deles. Envie um alerta para operações quando o valor limite for atingido.
Treine vários operadores para monitorar o aplicativo e executar etapas de recuperação manuais
Certifique-se de que sempre haja pelo menos um operador treinado ativo.

Gerenciar Falhas e Desastres

Crie um plano de recuperação e certifique-se de que ele cubra restauração de dados, interrupções de rede, falhas de serviço dependentes e interrupções de serviço em toda a região. Considere suas VMs, armazenamento, bancos de dados e outros serviços da OCI em sua estratégia de recuperação.

Planeje o gerenciamento de incidentes
Defina funções e responsabilidades claras para o gerenciamento de incidentes para manter os serviços em execução ou restaurá-los o mais rápido possível.
Documentar e testar seu plano de recuperação de desastre
Crie um plano de recuperação de desastres que reflita o impacto comercial das falhas de aplicativos. Automatize o processo de recuperação o máximo possível e documente todas as etapas manuais. Teste regularmente seu processo de recuperação de desastres para validar e melhorar o plano.
Compreender as principais atribuições necessárias para a coordenação de DR
Certifique-se de que os esforços de DR sejam bem coordenados e que os aplicativos sejam priorizados com base no valor comercial.
Preparar-se para a falha do aplicativo
Prepare-se para uma série de falhas, incluindo falhas que são tratadas automaticamente, aquelas que resultam em funcionalidade reduzida e aquelas que fazem com que o aplicativo fique indisponível. O aplicativo deve informar os usuários sobre problemas temporários.
Recuperar-se de corrompimento de dados
Se ocorrer uma falha em um armazenamento de dados, verifique inconsistências de dados quando o armazenamento estiver disponível novamente, especialmente se os dados foram replicados. Restaurar dados corrompidos de um backup.
Recupere-se de uma interrupção da rede
Você pode usar dados armazenados em cache para execução local com funcionalidade de aplicativo reduzida. Caso contrário, considere o tempo de inatividade do aplicativo ou faça failover para outra região. Armazene seus dados em um local alternativo até que a conectividade seja restaurada.
Recuperar-se de uma falha de serviço dependente
Determine qual funcionalidade ainda está disponível e como o aplicativo deve responder.
Recuperar-se de uma interrupção de serviço em toda a região
As interrupções de serviço em toda a região são incomuns, mas você deve ter uma estratégia para resolvê-las, especialmente para aplicativos críticos. Talvez você possa reimplantar o aplicativo em outra região ou redistribuir o tráfego.
Aprender com testes de DR e melhorar processos
Certifique-se de que quaisquer problemas encontrados durante o teste de DR sejam capturados e os planos para remediar esses problemas sejam resolvidos em testes ou failovers futuros.