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 engloba a capacidade de uma carga de trabalho realizar a função pretendida de forma correta e consistente quando se espera que isso aconteça. 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 escolhas de arquitetura afetarão o comportamento da carga de trabalho em todos os pilares do AWS Well-Architected. Para atingir a confiabilidade, há padrões específicos que devem ser seguidos.

O pilar de confiabilidade foca as seguintes áreas principais:

Entender as cotas de serviço do Neptune

Um volume de cluster do Neptune pode crescer até um tamanho máximo de 128 tebibytes (TiB) em todos os países com Regiões da AWS suporte, exceto na GovCloud China, onde a cota é de 64 TiB.

A cota de 128 TiB é suficiente para armazenar aproximadamente 200 a 400 bilhões de objetos no grafo. Em um grafo rotulado de propriedades (LPG), um objeto é um nó, uma borda ou uma propriedade em um nó ou borda. Em um grafo 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 da vCPU e das redes associadas. Os mesmos valores mínimo e máximo das NCUs se aplicam a todas as instâncias de 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. Em muitas cargas de trabalho, 1.0 NCU é um ponto de partida muito baixo e resulta em um comportamento não confiável após períodos de inatividade. Se você achar que sua carga de trabalho não se expande 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 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 (compatível com 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

Em clusters de banco de dados do 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 é compatível com operações de leitura e gravação, além de realizar 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 primária de banco de dados, e só é compatível com operações de leitura. As réplicas do Neptune podem descarregar workloads 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. Ou seja, 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 na 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 offline, 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 Sem Servidor, as instâncias do leitor e do gravador em todas as zonas de disponibilidade aumentarão e reduzirão a escala verticalmente, independentemente umas das outras, dependendo da carga do banco de dados. É possível definir a camada de promoção de uma instância do leitor como 0 ou 1 para que a escala seja aumentada ou reduzida verticalmente junto com a capacidade da instância do gravador. Isso a torna pronta para assumir a workload atual a qualquer momento.

Se seu aplicativo tem uma presença mundial ou requer failover em várias regiões, considere usar um banco de dados global Neptune. Um banco de dados global do Amazon Neptune abrange Regiões da AWS vários, permitindo leituras globais de baixa latência e fornecendo recuperação rápida no caso raro de uma interrupção afetar um todo. Região da AWS Um banco de dados global Neptune consiste em um cluster de banco de dados primário em uma região e até cinco clusters de banco de dados secundários em diferentes regiões.

Gerenciar e escalar os clusters do Neptune

É possível usar o ajuste de escala automático 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 workload com base nos limites de utilização de CPU. Com o ajuste de escala automático, seu cluster de banco de dados do Neptune pode lidar com aumentos repentinos na workload. Quando a workload diminui, o ajuste de escala automático 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 ajuste de escala automático por si só não é uma solução suficiente para mudanças rápidas na demanda.

É possível usar o ajuste de escala automático apenas com um cluster de banco de dados do Neptune que já tenha uma instância primária do gravador e pelo menos uma instância de réplica de leitura (consulte Instâncias e clusters 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 ajuste de escala automático 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 escaladas verticalmente, enquanto o ajuste de escala automático instancia novas réplicas de leitura para lidar com a workload além da capacidade máxima de uma única instância sem servidor. Para obter mais informações sobre a escalabilidade da capacidade do Amazon Neptune Sem Servidor, consulte Escalabilidade de capacidade em um cluster de banco de dados do Neptune Sem Servidor.

Se suas necessidades de escalabilidade mudarem em horários previsíveis, você poderá programar mudanças nas instâncias mínimas, nas máximas e nos limites para lidar melhor com essas necessidades variáveis. Lembre-se de agendar eventos de aumento horizontal da escala 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 do volume de cluster automaticamente e mantém dados de backup pelo período de retenção de 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.

Se você quiser manter um backup além do período de retenção do backup, também poderá obter um snapshot dos dados no seu volume de 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 dados e não apenas das 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 do qual restaurar e 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 opção Reinicialização com failover é vantajosa quando você deseja simular uma falha de uma instância de banco de dados para testes ou restaurar as 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 um cluster de banco de dados do gravador, ele executa failover na réplica em espera. A reinicialização de uma réplica do Neptune não inicia um failover.

Desenvolva 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 na documentação abaixo dos exemplos de AWS Lambda funções do Amazon Neptune.

Considere usar o AWS Backup se você tiver um conjunto comum de requisitos de backup que você aplica em vários mecanismos de banco de dados.