As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Pilar Confiabilidade
O pilar de confiabilidade do AWS Well-Architected Framework engloba a capacidade de uma carga de trabalho realizar a função pretendida de forma correta e consistente, quando se espera. Isso inclui a capacidade de operar e testar a workload durante todo o ciclo de vida dela.
Uma workload confiável começa com as decisões iniciais de projeto que envolvem tanto o software quanto a infraestrutura. Suas decisões de arquitetura afetarão o comportamento da workload em todos os pilares do Well-Architected. Para atingir a confiabilidade, há padrões específicos que devem ser seguidos.
O pilar de confiabilidade se concentra nas seguintes áreas principais:
-
Arquitetura de carga de trabalho, incluindo cotas de serviço e padrões de implantação
-
Gerenciamento de alterações
-
Gerenciamento de falhas
Entenda as cotas de serviço do Neptune
Um volume de cluster Neptune pode crescer até um tamanho máximo de 128 tebibytes (TiB) em todos os países Regiões da AWS suportados, exceto na GovCloud China, onde a cota é de 64 TiB.
A cota de 128 TiB é suficiente para armazenar aproximadamente 200-400 bilhões de objetos no gráfico. Em um gráfico de propriedades rotulado (LPG), um objeto é um nó, uma borda ou uma propriedade em um nó ou borda. Em um gráfico do Resource Description Framework (RDF), um objeto é um quad.
Para qualquer cluster Neptune Serverless, você define o número mínimo e máximo de Neptune Capacity Units (). NCUs Cada NCU consiste em 2 gibibytes (GiB) de memória e na vCPU e na rede associadas. Os valores mínimo e máximo de NCU se aplicam a qualquer instância sem servidor no cluster. O valor máximo de NCU mais alto que você pode definir é 128,0 NCUs e o mínimo mais baixo é 1,0. NCUs Otimize a faixa de NCU que funciona melhor para sua aplicação observando as CloudWatch métricas da Amazon ServerlessDatabaseCapacity e capturando a faixa em que você normalmente se NCUUtilization depara e correlacionando comportamentos ou custos indesejados dentro dessa faixa. Se você achar que sua carga de trabalho não é dimensionada com rapidez suficiente, aumente o mínimo NCUs para fornecer processamento suficiente para o aumento inicial durante a escalada.
Cada um Conta da AWS tem cotas para cada região no número de recursos de banco de dados que você pode criar. Esses recursos incluem instâncias de banco de dados e clusters de banco de dados. Depois de atingir o limite de um recurso, as chamadas adicionais para criá-lo falham, com uma exceção. Algumas cotas são cotas flexíveis que podem ser aumentadas mediante solicitação. Para obter uma lista de cotas compartilhadas entre o Amazon Neptune e o Amazon RDS, o Amazon Aurora e o Amazon DocumentDB (com compatibilidade com o MongoDB), além de links para solicitar aumentos de cotas quando disponíveis, consulte Cotas no Amazon RDS.
Entenda os padrões de implantação do Neptune
Nos clusters de banco de dados Neptune, há uma instância de banco de dados primária e até 15 réplicas do Neptune. A instância de banco de dados primária suporta operações de leitura e gravação e realiza todas as modificações de dados no volume do cluster. As réplicas do Neptune se conectam ao mesmo volume de armazenamento da instância de banco de dados primária e oferecem suporte somente às operações de leitura. As réplicas do Neptune podem descarregar cargas de trabalho de leitura da instância de banco de dados primária.
Para obter alta disponibilidade, use réplicas de leitura. Ter uma ou mais instâncias de réplica de leitura disponíveis em diferentes zonas de disponibilidade pode aumentar a disponibilidade, pois as réplicas de leitura servem como destinos de failover para a instância primária. Se a instância do gravador falhar, o Neptune promoverá uma instância de réplica de leitura para se tornar a instância primária. Quando isso acontece, há uma breve interrupção (geralmente menos de 30 segundos) enquanto a instância promovida é reinicializada, durante a qual as solicitações de leitura e gravação feitas à instância primária falham com uma exceção. Para maior confiabilidade, considere duas réplicas de leitura em diferentes zonas de disponibilidade. Se a instância primária na Zona de Disponibilidade 1 ficar off-line, a instância na Zona de Disponibilidade 2 será promovida para primária, mas não poderá lidar com consultas enquanto isso acontece. Portanto, é necessária uma instância na Zona de Disponibilidade 3 para lidar com consultas de leitura durante a transição.
Se você estiver usando o Neptune Serverless, as instâncias de leitura e gravação em todas as zonas de disponibilidade aumentarão e diminuirão, independentemente umas das outras, dependendo da carga do banco de dados. Você pode definir o nível de promoção de uma instância do leitor como 0 ou 1 para que ela aumente e diminua junto com a capacidade da instância do gravador. Isso o prepara para assumir a carga de trabalho atual a qualquer momento.
Gerencie e escale os clusters do Neptune
Você pode usar o auto-scaling do Neptune para ajustar automaticamente o número de réplicas do Neptune em um cluster de banco de dados para atender aos requisitos de conectividade e carga de trabalho com base nos limites de utilização da CPU. Com o auto-scaling, seu cluster de banco de dados Neptune pode lidar com aumentos repentinos na carga de trabalho. Quando a carga de trabalho diminui, o auto-scaling remove réplicas desnecessárias para que você não pague pela capacidade não utilizada. Lembre-se de que a inicialização de uma nova instância pode levar até 15 minutos, portanto, o auto-scaling por si só não é uma solução suficiente para mudanças rápidas na demanda.
Você pode usar o auto-scaling somente com um cluster de banco de dados Neptune que já tenha uma instância de gravador principal e pelo menos uma instância de réplica de leitura (consulte Clusters e instâncias de banco de dados do Amazon Neptune). Além disso, todas as instâncias de réplica de leitura no cluster devem estar em um estado disponível. Se alguma réplica de leitura estiver em um estado diferente de disponível, o auto-scaling do Neptune não fará nada até que todas as réplicas de leitura no cluster estejam disponíveis.
Se você tiver mudanças rápidas na demanda, considere usar instâncias sem servidor. As instâncias sem servidor podem ser escaladas verticalmente em períodos curtos, enquanto o escalonamento automático é dimensionado horizontalmente em períodos mais longos. Essa configuração fornece escalabilidade ideal porque as instâncias sem servidor são dimensionadas verticalmente, enquanto o auto-scaling instancia novas réplicas de leitura para lidar com a carga de trabalho além da capacidade máxima de uma única instância sem servidor. Para obter mais informações sobre o escalonamento de capacidade do Amazon Neptune Serverless, consulte Escalabilidade de capacidade em um cluster de banco de dados Neptune Serverless.
Se suas necessidades de escalabilidade mudarem em horários previsíveis, você poderá programar mudanças nas instâncias mínimas, máximas e limites para lidar melhor com essas necessidades variáveis. Lembre-se de agendar eventos de expansão com pelo menos 15 minutos de antecedência para permitir que essas instâncias fiquem on-line quando necessário.
Gerencia a configuração de banco de dados no Amazon Neptune usando parâmetros em um grupo de parâmetros. Grupos de parâmetros atuam como contêineres de valores de configuração do mecanismo que são aplicados a uma ou mais instâncias de bancos de dados. Ao modificar parâmetros de cluster em grupos de parâmetros, entenda a diferença entre parâmetros estáticos e dinâmicos e como e quando eles são aplicados. Use o endpoint de status para ver a configuração aplicada atual.
Gerencie backups e eventos de failover
O Neptune faz backup automático do volume do cluster e retém os dados de backup durante o período de retenção do backup. Os backups do Neptune são contínuos e incrementais para que você possa restaurar rapidamente em qualquer momento do período de retenção de backup. Você pode especificar um período de retenção de backup de 1 a 35 dias ao criar ou modificar um cluster de banco de dados.
Para reter um backup além do período de retenção do backup, você também pode tirar um instantâneo dos dados no volume do cluster. Armazenar snapshots gera taxas de armazenamento padrão do Neptune.
Quando você cria um snapshot do Amazon Neptune de um cluster de banco de dados, o Neptune cria um snapshot do volume de armazenamento do cluster, fazendo backup de todos os seus dados, não apenas de instâncias individuais. É possível criar um cluster de banco de dados restaurando pelo snapshot desse cluster de banco de dados. Ao restaurar o cluster de banco de dados, você fornece o nome do snapshot do cluster de banco de dados a partir do qual restaurar e, em seguida, fornece um nome para o novo cluster de banco de dados criado pela restauração.
Teste como seu sistema responde aos eventos de failover. Use a API Neptune para forçar um evento de failover. A reinicialização com failover é vantajosa quando você deseja simular uma falha de uma instância de banco de dados para testar ou restaurar operações na zona de disponibilidade original após a ocorrência de um failover. Para obter mais informações, consulte Configuração e gerenciamento de uma implantação Multi-AZ. Quando você reinicializa uma instância de gravador de banco de dados, ela passa para a réplica em espera. A reinicialização de uma réplica do Neptune não inicia um failover.
Projete seus clientes para garantir a confiabilidade. Teste seu comportamento durante eventos de failover. Implemente a lógica de repetição em seu cliente com a lógica de recuo exponencial. Exemplos de código que implementam essa lógica podem ser encontrados em exemplos de AWS Lambda funções do Amazon Neptune.
Considere usar AWS Backup
