Compartilhar via

Design de aplicativos resilientes com SDKs do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

Ao criar aplicativos cliente que interagem com o Azure Cosmos DB por meio de qualquer um dos SDKs, é importante entender alguns dos principais conceitos básicos. Este artigo é um guia de design para ajudar a entender esses conceitos básicos e criar aplicativos resilientes.

Visão geral

Para obter uma visão geral em vídeo dos conceitos discutidos neste artigo, confira:

Modos de conectividade

Os SDKs do Azure Cosmos DB podem se conectar ao serviço usando dois modos de conectividade. Os SDKs do .NET e do Java podem se conectar ao serviço nos modos Gateway e Direto, enquanto os outros só podem se conectar no modo Gateway. O modo Gateway usa o protocolo HTTP e o modo Direto geralmente usa o protocolo TCP.

O modo Gateway é sempre usado para buscar metadados, como as informações de conta, contêiner e roteamento, independentemente de qual modo o SDK está configurado para usar. Essas informações são armazenadas em cache na memória e usadas para se conectar às réplicas de serviço.

Resumindo, para SDKs no modo Gateway, você pode esperar tráfego HTTP, enquanto para SDKs no modo Direto, você pode esperar uma combinação de tráfego HTTP e TCP em circunstâncias diferentes (como inicialização, busca de metadados ou informações de roteamento).

Instâncias e conexões do cliente

Independentemente do modo de conectividade, é essencial manter uma instância do Singleton do cliente do SDK por conta por aplicativo. O escopo das conexões HTTP e TCP é definido para a instância do cliente. A maioria dos ambientes de computação tem limitações em termos do número de conexões que podem ser abertas ao mesmo tempo e, quando esses limites são atingidos, a conectividade é afetada.

Redes e aplicativos distribuídos

Quando você cria aplicativos distribuídos, há três componentes principais:

  • O aplicativo e o ambiente em que é executado.
  • A rede, que inclui qualquer componente entre o aplicativo e o ponto de extremidade de serviço do Azure Cosmos DB.
  • O ponto de extremidade de serviço do Azure Cosmos DB.

Quando ocorrem falhas, elas geralmente se enquadram em uma dessas três áreas e é importante entender que, devido à natureza distribuída do sistema, é inviável esperar 100% de disponibilidade para qualquer um desses componentes.

O Azure Cosmos DB tem um conjunto abrangente de SLAs de disponibilidade, mas nenhum deles é 100%. Os componentes de rede que conectam o aplicativo ao ponto de extremidade de serviço podem ter problemas transitórios de hardware e perder pacotes. Até mesmo o ambiente de computação em que o aplicativo é executado pode ter um pico de CPU que afete as operações. Essas condições de falha podem afetar as operações dos SDKs e normalmente surgem como erros com códigos específicos.

O aplicativo deve ser resiliente até certo ponto de possíveis falhas nesses componentes, ao implementar políticas de repetição em relação às respostas fornecidas pelos SDKs.

Meu aplicativo deve repetir os erros?

A resposta simples é sim. Mas nem todos os erros fazem sentido para repetição, alguns dos códigos ou status de erro não são transitórios. A tabela abaixo descreve os erros detalhadamente:

Código de status Deve adicionar repetição Tentativa de repetição de SDKs Descrição
400 Não Não Solicitação incorreta
401 Não Não Não autorizado
403 Opcional Não Proibido
404 Não Não Recurso não encontrado
408 Sim Sim Tempo limite da solicitação atingido
409 Não Não Falha de conflito é quando a identidade (ID e chave de partição) fornecida para um recurso em uma operação de gravação foi tomada por um recurso existente ou quando uma restrição de chave exclusiva foi violada.
410 Sim Sim Exceções que não existem mais (falha transitória que não deve violar o SLA)
412 Não Não A falha de pré-condição é quando a operação especifica uma eTag diferente da versão disponível no servidor. Esse é um erro de simultaneidade otimista. Repita a solicitação depois de ler a versão mais recente do recurso e atualizar o eTag na solicitação.
413 Não Não A entidade da solicitação é muito grande
429 Sim Sim É seguro repetir um 429. Examine o guia para solucionar problemas de HTTP 429.
449 Sim Sim Erro transitório que só ocorre em operações de gravação, e é seguro executar a repetição. Pode apontar para um problema de design em que muitas operações simultâneas tentam atualizar o mesmo objeto no Azure Cosmos DB.
500 Não Não A operação falhou devido a um erro de serviço inesperado. Entre em contato com o suporte registrando um problema no Suporte do Azure.
503 Sim Sim Serviço indisponível

Na tabela acima, todos os códigos de status marcados com Sim na segunda coluna devem ter algum grau de cobertura de repetição do aplicativo.

HTTP 403

Os SDKs do Azure Cosmos DB não repetirão as falhas HTTP 403 em geral, mas há certos erros associados ao HTTP 403 aos quais o aplicativo pode decidir reagir. Por exemplo, se você receber um erro indicando que uma Chave de Partição está cheia, poderá optar por alterar a chave de partição do documento que está tentando gravar com base em alguma regra de negócio.

HTTP 429

Os SDKs do Azure Cosmos DB repetirão os erros HTTP 429 por padrão seguindo a configuração do cliente e atendendo ao cabeçalho x-ms-retry-after-ms de resposta do serviço, aguardando o tempo indicado e repetindo depois.

Quando as repetições do SDK são excedidas, o erro é retornado ao aplicativo. O ideal é que a inspeção do cabeçalho x-ms-retry-after-ms na resposta possa ser usada como dica para decidir quanto tempo esperar antes de repetir a solicitação. Outra alternativa seria um algoritmo de back-off exponencial ou configurar o cliente para estender as repetições no HTTP 429.

HTTP 449

Os SDKs do Azure Cosmos DB repetirão o HTTP 449 com um back-off incremental durante um período fixo para adaptar a maioria dos cenários.

Quando as repetições automáticas do SDK são excedidas, o erro é retornado ao aplicativo. Os erros HTTP 449 podem ser repetidos com segurança. Devido à natureza altamente simultânea das operações de gravação, é melhor ter um algoritmo de back-off aleatório para evitar a repetição do mesmo grau de simultaneidade após um intervalo fixo.

As falhas de tempo limite e de conectividade estão entre os erros mais comuns. Os SDKs do Azure Cosmos DB são resilientes e repetirão os problemas de tempo limite e de conectividade nos protocolos HTTP e TCP, se a repetição for viável:

  • Para operações de leitura, os SDKs repetirão os erros relacionados ao tempo limite ou à conectividade.
  • Para operações de gravação, os SDKs não repetirão, pois essas operações não são idempotentes. Quando a espera da resposta atinge o tempo limite, não é possível saber se a solicitação acessou o serviço.

Se a conta tiver várias regiões disponíveis, os SDKs também tentarão uma repetição entre regiões.

Devido à natureza das falhas de tempo limite e de conectividade, elas podem não aparecer nas métricas da conta, pois abrangem apenas as falhas que ocorrem no lado do serviço.

É recomendável que os aplicativos tenham sua própria política de repetição para esses cenários e levem em consideração como resolver os tempos limite de gravação. Por exemplo, repetir um tempo limite de Criação pode gerar um HTTP 409 (Conflito), se a solicitação anterior acessou o serviço, mas fosse bem-sucedida caso não acessasse.

Detalhes de implementação específicos da linguagem

Para obter mais detalhes de implementação sobre uma linguagem, consulte:

As repetições afetam minha latência?

Da perspectiva do cliente, as repetições afetarão a latência de ponta a ponta de uma operação. Quando a latência P99 do aplicativo está sendo afetada, é importante entender as repetições que estão ocorrendo e como lidar com elas.

Os SDKs do Azure Cosmos DB fornecem informações detalhadas nos logs e diagnósticos que podem ajudar a identificar quais repetições estão ocorrendo. Para obter mais informações, confira Como coletar diagnósticos do SDK do .NET e Como coletar diagnósticos do SDK do Java.

Como posso mitigar a latência de novas tentativas?

Dependendo das circunstâncias, na maioria dos casos o SDK encaminhará solicitações para a região local, para a região de gravação (em um cenário de gravação de região única) ou para a primeira região na lista de regiões preferenciais. Essa priorização minimiza a latência em cenários íntegros, conectando-se principalmente ao data center mais próximo ou ideal.

No entanto, essa priorização também significa que as solicitações que resultarão em falha serão sempre tentadas primeiro em uma região específica para um determinado cenário de erro. Se o failover para outra região for preferido nesse cenário, isso normalmente será tratado na camada de infraestrutura (gerenciador de tráfego) e não no nível do SDK. A configuração adequada da sua infraestrutura pode garantir que o tráfego seja redirecionado de forma eficiente durante interrupções regionais, mitigando assim a latência que pode surgir com novas tentativas entre regiões em um cenário de interrupção. Para obter informações mais detalhadas sobre a configuração do failover ao nível da infraestrutura, pode consultar documentação do Gestor de Tráfego do Azure. Alguns SDKs suportam a implementação de estratégias de failover semelhantes diretamente no nível do SDK. Por exemplo, veja alta disponibilidade para Java SDK.

E as interrupções regionais?

Os SDKs do Azure Cosmos DB abrangem a disponibilidade regional e podem executar repetições em outras regiões da conta. Veja o artigo cenários e configurações de repetição de ambientes em várias regiões para entender quais cenários envolvem outras regiões.

Quando entrar em contato com o atendimento ao cliente

Antes de entrar em contato com o atendimento ao cliente, siga estas etapas:

  • Qual é o impacto medido no volume de operações afetadas, em comparação às operações bem-sucedidas? Está nos SLAs de serviço?
  • A latência P99 é afetada?
  • As falhas estão relacionadas aos códigos de erro que meu aplicativo deve repetir e o aplicativo abrange essas repetições?
  • As falhas estão afetando todas as instâncias de aplicativo ou apenas um subconjunto? Quando o problema é reduzido a um subconjunto de instâncias, normalmente é um problema relacionado a essas instâncias.
  • Você examinou os documentos de solução de problemas relacionados na tabela acima para descartar um problema no ambiente do aplicativo?

Se todas as instâncias do aplicativo forem afetadas ou a porcentagem de operações afetadas estiver fora dos SLAs de serviço ou afetando seus próprios SLAs de aplicativo e P99s, entre em contato com o atendimento ao cliente.

Próximas etapas