Como entender as necessidades de disponibilidade

É comum pensar inicialmente na disponibilidade de uma aplicação como um único objetivo para a aplicação como um todo. Porém, com uma inspeção mais detalhada, é comum descobrirmos que determinados aspectos de uma aplicação ou serviço têm requisitos de disponibilidade diferentes. Por exemplo, alguns sistemas podem priorizar a capacidade de receber e armazenar novos dados antes de recuperar dados existentes. Outros sistemas priorizam operações em tempo real sobre operações que mudam a configuração ou o ambiente de um sistema. Os serviços podem ter requisitos de disponibilidade muito altos durante determinados horários do dia, mas podem tolerar períodos muito mais longos de interrupção fora desses horários. Estas são algumas das maneiras como você pode dividir uma única aplicação nas partes que a compõem e avaliar os requisitos de disponibilidade de cada uma. O benefício de fazer isso é concentrar os esforços (e as despesas) de disponibilidade conforme as necessidades específicas, em vez de projetar todo o sistema conforme o requisito mais rígido.

Na AWS, normalmente dividimos os serviços em "plano de dados" e "ambiente de gerenciamento". O plano de dados é responsável por prestar serviço em tempo real, enquanto os ambientes de gerenciamento são usados para configurar o ambiente. Por exemplo, instâncias do Amazon EC2, bancos de dados do Amazon RDS e operações de leitura/gravação de tabela do Amazon DynamoDB são operações no plano de dados. Em contraste, iniciar novas instâncias do EC2 ou bancos de dados do RDS ou adicionar ou alterar metadados de tabela no DynamoDB são consideradas operações no ambiente de gerenciamento. Embora altos níveis de disponibilidade sejam importantes para todas essas capacidades, os planos de dados costumam ter metas de design de disponibilidade maiores que os ambientes de gerenciamento. Portanto, as workloads com requisitos de alta disponibilidade devem evitar a dependência de tempo de execução nas operações do ambiente de gerenciamento.

Muitos dos clientes da AWS adotam uma abordagem similar para avaliar de modo crítico suas aplicações e identificar subcomponentes com diferentes necessidades de disponibilidade. As metas de design de disponibilidade são personalizadas para os diferentes aspectos, e os esforços de trabalho adequados são empregados para projetar o sistema. A AWS possui experiência significativa de aplicações de engenharia com uma série de metas de design de disponibilidade, incluindo serviços com 99,999% ou mais de disponibilidade. AWS Os arquitetos de soluções (SAs) podem ajudar você a projetar adequadamente conforme suas metas de disponibilidade. Envolver a AWS no início do processo de design melhora nossa capacidade de ajudar você a atingir suas metas de disponibilidade. O planejamento da disponibilidade não é feito apenas antes do início de sua workload. Isso também é feito de modo contínuo para refinar seu design conforme você ganha experiência operacional, aprende com eventos do mundo real e tolera falhas de diferentes tipos. Assim você pode aplicar o esforço de trabalho adequado para melhorar sua implementação.

As necessidades de disponibilidade necessárias para uma workload devem estar alinhadas à necessidade e à criticidade da empresa. Ao definir primeiro a estrutura de criticidade empresarial com RTO, RPO e disponibilidade específicos, é possível avaliar cada workload. Essa abordagem exige que as pessoas envolvidas na implementação da workload tenham conhecimento da estrutura e do impacto que sua workload tem sobre as necessidades empresariais.