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 que o faça. Isso inclui a capacidade de operar e testar a carga de trabalho durante todo o seu ciclo de vida.

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 afetam o comportamento da carga de trabalho em todos os pilares do Well-Architected. Para maior confiabilidade, há padrões específicos que você deve seguir, conforme discutido nesta seção.

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

Sua AWS conta tem cotas padrão (anteriormente chamadas de limites) para cada uma. AWS service (Serviço da AWS) A menos que especificado de outra forma, cada cota é específica da região. Você pode solicitar aumentos para algumas cotas, mas não para todas.

Para encontrar cotas para o Neptune Analytics, abra o console Service Quotas. No painel de navegação, escolha e, em seguida Serviços da AWS, selecione Amazon Neptune Analytics. Preste atenção às cotas no número de gráficos e instantâneos, na memória máxima provisionada para um gráfico e nas taxas de solicitação de API.

Se a memória máxima provisionada não for suficiente para seu conjunto de dados, avalie quais tipos de nós e bordas são essenciais para o uso analítico pretendido. Carregue um subconjunto dos dados para que a análise seja possível dentro de uma capacidade provisionada permitida. Muitas cargas de trabalho de análise, especialmente aquelas que executam algoritmos gráficos, precisam apenas da topologia com um conjunto limitado de propriedades, em vez do gráfico transacional completo. (Para uma discussão sobre as diferenças entre cargas de trabalho transacionais e analíticas, consulte a seção Pilar de eficiência de desempenho.)

Se o número máximo de gráficos não for suficiente para o uso pretendido:

• Considere combinar gráficos que tenham usos semelhantes.

• Avalie quantos gráficos precisam ser executados em um determinado momento. Se você tiver um caso de uso de análise efêmero, capture e exclua um gráfico quando ele não for mais necessário. Isso reduz o número de gráficos em relação à cota.

• Considere gráficos de provisionamento em diferentes. Contas da AWS

Entenda os padrões de implantação do Neptune

Entenda os seguintes pontos de decisão ao planejar a implantação de um gráfico do Neptune Analytics:

• Semeadura: decida se deseja criar um gráfico vazio ou carregar dados nele no momento da criação com dados do Amazon S3, de um cluster de banco de dados Neptune existente ou de um snapshot de banco de dados Neptune existente.

  Recomendação: se a origem for um cluster ou snapshot do Neptune, você deverá carregar seus dados no momento da criação do gráfico. Se a fonte for o Amazon S3, carregue os dados no momento da criação se o esforço de carregá-los for significativo e melhor executado como uma atividade de provisionamento de infraestrutura. Se você preferir carregar dados como uma atividade de engenharia de dados ou de aplicação, crie um gráfico vazio e carregue dados do Amazon S3 posteriormente.

• Capacidade: estime a capacidade provisionada necessária para um gráfico, considerando o tamanho dos dados e o uso esperado do aplicativo.

  Recomendação: no momento da criação, especifique a memória máxima provisionada para limitar o tamanho do gráfico. Essa configuração é obrigatória. Você pode alterar a capacidade posteriormente, se necessário.

• Disponibilidade e tolerância a falhas: decida se as réplicas são necessárias para garantir a disponibilidade. Uma réplica atua como um modo de espera para recuperação em caso de falha no gráfico. Um gráfico com réplicas se recupera mais rápido do que um gráfico sem réplicas. Considere também por quanto tempo o gráfico é necessário, se é apenas para análises efêmeras e, em caso afirmativo, quando será removido.

  Recomendação: determine os requisitos de disponibilidade, como por quanto tempo o gráfico pode ficar indisponível e quando ele pode ser removido, antes de criar um gráfico.

• Rede e segurança: determine se você precisa de conectividade pública, privada ou ambas e se deseja criptografar seus dados.

  Recomendação: entenda os requisitos organizacionais, como se a conectividade pública é permitida e onde os aplicativos cliente gráficos serão implantados, antes de criar um gráfico.

• Backups e recuperação: determine se os instantâneos devem ser criados e, em caso afirmativo, quando ou sob quais condições. Considere se sua organização tem requisitos de recuperação de desastres (DR).

  Recomendação: criar instantâneos é uma atividade manual. Decida quando criar instantâneos e considere seus requisitos de DR antes de criar um gráfico.

Gerencie e escale os clusters do Neptune

Um gráfico do Neptune Analytics consiste em uma única instância otimizada para memória. A capacidade (m-NCU) da instância é definida no momento da criação. A instância pode ser escalada verticalmente aumentando a capacidade provisionada por meio de uma ação administrativa; a capacidade provisionada também pode ser reduzida. As réplicas são alvos passivos de failover, portanto, não aumentam a escala de um gráfico. Nesse aspecto, uma réplica gráfica difere de uma réplica de leitura do banco de dados Neptune, que é uma instância ativa em um cluster do Neptune que pode processar operações de leitura de aplicativos.

As réplicas têm custos. O preço da réplica é baseado na taxa m-NCU do gráfico. Por exemplo, se um gráfico for provisionado para 128 m-NCU e tiver uma única réplica, o custo será o dobro de um gráfico equivalente sem réplicas.

Na análise, há dois motivos principais para aumentar a escala:

• Para fornecer mais memória e CPU para consultas e algoritmos analíticos, porque a consulta individual é cara, o algoritmo gráfico a ser executado é inerentemente complexo e requer mais recursos de acordo com sua entrada, ou a taxa de solicitações simultâneas é alta. Se essas consultas encontrarem out-of-memory erros, aumentar a escala é uma solução razoável.

• Para suportar um tamanho de gráfico maior do que o planejado. Por exemplo, se a capacidade provisionada atual for de 128 M-NCU para suportar 60 GB de dados de origem e você precisar de mais 40 GB de dados de origem, um aumento para 256 M-NCU é garantido.

Monitore CloudWatch métricas do Neptune Analytics, NumQueuedRequestsPerSec como,,, CPUUtilization e NumOpenCypherRequestsPerSec GraphStorageUsagePercentGraphSizeBytes, para determinar se o dimensionamento é necessário. Você pode atualizar a configuração de um gráfico por meio do console ou SDKs. AWS CLI(Para exemplos e melhores práticas, consulte a seção Pilar de excelência operacional.)

Gerencie backups e eventos de failover

Use réplicas para garantir que um gráfico permaneça disponível em caso de falha. Um gráfico usa persistência baseada em registros para confirmar alterações nas zonas de disponibilidade em um. Região da AWS A réplica funciona como um modo de espera dinâmico e tem acesso a esses dados. Se houver uma falha, o gráfico retoma as operações na réplica. O aplicativo continua usando o mesmo endpoint para se conectar ao gráfico. Solicitações em andamento durante a falha geram erros com uma exceção de serviço indisponível. Considere usar uma nova tentativa com padrão de recuo no código do aplicativo para capturar o erro e tente novamente após um breve intervalo. Novas solicitações feitas durante o failover ficam na fila e podem ter uma latência maior.

Se nenhuma réplica estiver configurada e o gráfico falhar, o Neptune Analytics se recuperará do armazenamento durável, mas a recuperação demorará mais porque o Neptune precisa reinicializar os recursos.

Crie instantâneos do gráfico. (O Neptune Analytics não tira instantâneos automáticos.) Se o gráfico for modificado regularmente após a criação, tire instantâneos frequentes para capturar seu estado atual. Exclua instantâneos antigos se a restauração para um momento anterior não for necessária.

Você pode compartilhar instantâneos com outras contas e entre Regiões da AWS si. Se você tiver requisitos de DR, considere se a restauração do gráfico em uma região diferente de um snapshot atende aos requisitos de objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO).