Partager via

Conception d’applications résilientes avec des Kits de développement logiciel (SDK) Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

Lorsque vous créez des applications clientes qui interagissent avec Azure Cosmos DB via l’un des Kits de développement logiciel (SDK), il est important de comprendre quelques notions de base essentielles. Cet article est un guide de conception qui vous aide à comprendre ces notions de base et à concevoir des applications résilientes.

Vue d’ensemble

Pour obtenir une vue d’ensemble des concepts abordés dans cet article, consultez :

Modes de connectivité

Les Kits de développement logiciel (SDK) Azure Cosmos DB peuvent se connecter au service dans deux modes de connectivité. Les Kits de développement logiciel (SDK) .NET et Java peuvent se connecter au service à la fois en mode passerelle et en mode direct, tandis que les autres peuvent se connecter uniquement en mode passerelle. Le mode de passerelle utilise le protocole HTTP et le mode direct utilise généralement le protocole TCP.

Le mode de passerelle est toujours utilisé pour extraire des métadonnées, telles que les informations de compte, de conteneur et de routage, quel que soit le Kit de développement logiciel (SDK) qui est configuré pour l’utiliser. Ces informations sont mises en cache dans la mémoire et sont utilisées pour se connecter aux réplicas du service.

En résumé, pour les Kits de développement logiciel (SDK) en mode passerelle, vous pouvez vous attendre à un trafic HTTP, tandis que pour les Kits de développement logiciel en mode direct, vous pouvez vous attendre à une combinaison de trafic HTTP et TCP dans différentes circonstances (telles que l’initialisation, l’extraction des métadonnées ou les informations de routage).

Instances client et connexions

Quel que soit le mode de connectivité, il est essentiel de conserver une instance Singleton du client SDK par compte et par application. Les connexions HTTP et TCP sont étendues à l’instance client. La plupart des environnements de calcul présentent des limites en termes de nombre de connexions qui peuvent être ouvertes en même temps et lorsque ces limites sont atteintes, la connectivité est affectée.

Applications et réseaux distribués

Lorsque vous concevez des applications distribuées, il existe trois composants clés :

  • Votre application et l’environnement sur lequel elle s’exécute.
  • Le réseau, qui comprend tous les composants entre votre application et le point de terminaison du service Azure Cosmos DB.
  • Le point de terminaison du service Azure Cosmos DB.

En cas de défaillance, ils se trouvent souvent dans l’une de ces trois zones et il est important de comprendre qu’en raison de la nature distribuée du système, il est peu pratique d’attendre une disponibilité de 100 % pour l’un de ces composants.

Azure Cosmos DB possède un ensemble complet de contrats SLA de disponibilité, mais aucun d’entre eux n’est à 100 %. Les composants réseau qui connectent votre application au point de terminaison de service peuvent avoir des problèmes matériels temporaires et perdre des paquets. Même l’environnement Compute dans lequel votre application s’exécute peut avoir un pic d’UC affectant les opérations. Ces conditions d’échec peuvent affecter les opérations des Kits de développement logiciel (SDK) et apparaître normalement en tant qu’erreurs avec des codes particuliers.

Votre application doit être résiliente à un certain degré vis-à-vis des défaillances potentielles sur ces composants en implémentant des stratégies de nouvelle tentative sur les réponses fournies par les Kits de développement logiciel (SDK).

Mon application doit-elle réessayer en cas d’erreur ?

En un mot, oui. Mais cela n’a pas de sens d’effectuer de nouvelles tentatives pour toutes les erreurs, certains codes d’erreur ou d’état ne sont pas temporaires. Le tableau ci-dessous les décrit en détail :

Code d’état Vous devez ajouter une nouvelle tentative Kits SDK : nouvelle tentative Description
400 Non Non Demande incorrecte
401 Non Non Non autorisé
403 Facultatif Non Interdit
404 Non Non Ressource introuvable
408 Oui Oui La demande a expiré
409 Non Non Un échec de conflit se présente lorsque l’identité (ID et clé de partition) fournie pour une ressource sur une opération d’écriture a été prise par une ressource existante ou lorsqu’une contrainte de clé unique a été enfreinte.
410 Oui Oui Exceptions disparues (échec temporaire qui ne devrait pas enfreindre le SLA)
412 Non Non Un échec de condition préalable se produit quand l’opération a spécifié un eTag différent de la version disponible sur le serveur. Il s’agit d’une erreur d’accès concurrentiel optimiste. Effectuez une nouvelle tentative de requête après avoir lu la dernière version de la ressource et mis à jour l’eTag sur la requête.
413 Non Non Entité de requête trop grande
429 Oui Oui Vous pouvez retenter sans problème après une erreur 429. Consultez le Guide pour résoudre les problèmes liés à HTTP 429.
449 Oui Oui Erreur temporaire qui se produit uniquement lors des opérations d’écriture, et qui peut faire suite à une nouvelle tentative sans problème. Cela peut indiquer un problème de conception où un trop grand nombre d’opérations simultanées tentent de mettre à jour le même objet dans Azure Cosmos DB.
500 Non Non L’opération a échoué en raison d’une erreur de service inattendue. Contactez le support en renseignant un problème de support Azure.
503 Oui Oui Service indisponible.

Dans le tableau ci-dessus, tous les codes d’état marqués avec la valeur Oui dans la deuxième colonne doivent avoir un certain degré de couverture de nouvelle tentative dans votre application.

HTTP 403

Les Kits de développement logiciel (SDK) Azure Cosmos DB ne font pas de nouvelle tentative en cas d’échecs HTTP 403 en général, mais il existe certaines erreurs associées à HTTP 403 vis-à-vis desquelles votre application peut décider de réagir. Par exemple, si vous recevez une erreur indiquant qu’une clé de partition est pleine, vous pouvez décider de modifier la clé de partition du document que vous essayez d’écrire en fonction d’une règle d’entreprise.

HTTP 429

Les Kits de développement logiciel (SDK) Azure Cosmos DB réessaient les erreurs HTTP 429 par défaut en suivant la configuration du client et en respectant l’en-tête de réponse x-ms-retry-after-ms du service, en attendant l’heure indiquée et une nouvelle tentative après.

Lorsque les nouvelles tentatives du Kit de développement logiciel (SDK) sont dépassées, l’erreur est retournée à votre application. Dans l’idéal, l’inspection de l’en-tête x-ms-retry-after-ms dans la réponse peut être utilisée comme conseil pour décider du délai d’attente avant de retenter la demande. Une autre solution serait un algorithme d’interruption exponentielle ou la configuration du client pour étendre les nouvelles tentatives sur HTTP 429.

HTTP 449

Les Kits de développement logiciel (SDK) Azure Cosmos DB effectuent une nouvelle tentative sur HTTP 449 avec une interruption incrémentielle pendant une période de temps fixe pour prendre en charge la plupart des scénarios.

Lorsque les nouvelles tentatives du Kit de développement logiciel (SDK) automatiques sont dépassées, l’erreur est retournée à votre application. Les erreurs HTTP 449 peuvent être retentées en toute sécurité. En raison de la nature très simultanée des opérations d’écriture, il est préférable de disposer d’un algorithme de temporisation aléatoire pour éviter de répéter le même degré d’accès concurrentiel après un intervalle fixe.

Les délais d’attente réseau et les défaillances de connectivité font partie des erreurs les plus courantes. Les Kits de développement logiciel (SDK) Azure Cosmos DB sont eux-mêmes résilients et réessaient les délais d’attente et les problèmes de connectivité entre les protocoles HTTP et TCP si la nouvelle tentative est possible :

  • Pour les opérations de lecture, les Kits de développement logiciel (SDK) réessaient toute erreur de connexion ou de délai d’attente.
  • Pour les opérations d’écriture, les Kits de développement logiciel (SDK) ne réessaient pas, car ces opérations ne sont pas idempotent. Lorsqu’un délai d’attente se produit en attendant la réponse, il n’est pas possible de savoir si la demande a atteint le service.

Si plusieurs régions sont disponibles pour le compte, les Kits de développement logiciel (SDK) effectuent également une nouvelle tentative entre régions.

En raison de la nature des délais d’attente et des échecs de connectivité, ceux-ci peuvent ne pas apparaître dans vos métriques de compte, car ils couvrent uniquement les défaillances qui se produisent côté service.

Il est recommandé que les applications aient leur propre stratégie de nouvelle tentative pour ces scénarios et prennent en considération la résolution des délais d’attente d’écriture. Par exemple, une nouvelle tentative sur un délai d’attente de création peut générer un erreur HTTP 409 (conflit) si la requête précédente a atteint le service, mais cela réussit si ce n’est pas le cas.

Détails de l’implémentation spécifique au langage

Pour plus d’informations sur l’implémentation concernant un langage, consultez :

Les nouvelles tentatives affectent-elles la latence ?

Du point de vue du client, toute nouvelle tentative aura une incidence sur la latence de bout en bout d’une opération. Lorsque la latence P99 de votre application est affectée, il est important de comprendre les nouvelles tentatives qui se produisent et comment les résoudre.

Les Kits de développement logiciel (SDK) Azure Cosmos DB fournissent des informations détaillées dans les journaux et les diagnostics qui peuvent aider à identifier les nouvelles tentatives. Pour plus d’informations, consultez Comment collecter les diagnostics du Kit de développement logiciel (SDK) .NET et Comment collecter les diagnostics du SDK Java.

Comment puis-je résoudre une latence de nouvelle tentative ?

Selon les circonstances, le Kit de développement logiciel (SDK) achemine, dans la plupart des cas, les demandes vers la région locale, la région d’écriture (dans un scénario d’écriture à région unique) ou la première région dans la liste des régions préférées. Cette détermination de priorités diminue la latence dans des scénarios sains en se connectant principalement au centre de données le plus proche ou optimal.

Toutefois, cette détermination de priorités signifie également que les demandes qui vont entraîner un échec seront toujours triées d’abord dans une région spécifique pour un scénario d’erreur donné. Si le basculement vers une autre région est préférable dans ce scénario, il est généralement géré au niveau de la couche d’infrastructure (Traffic Manager) plutôt qu’au niveau du Kit de développement logiciel (SDK). Une installation et une configuration correctes de votre infrastructure peuvent veiller à ce que ce trafic soit réacheminé efficacement pendant des pannes régionales, ce qui résout donc la latence se produisant avec de nouvelles tentatives inter-région dans un scénario de panne. Pour découvrir des informations détaillées sur la configuration d’un basculement au niveau de l’infrastructure, vous pouvez consulter la Documentation Azure Traffic Manager. Certains Kits de développement logiciel (SDK) prennent en charge l’implémentation de stratégies de basculement semblables directement au niveau du Kit de développement logiciel (SDK). Par exemple, voir la haute disponibilité pour le Kit de développement logiciel (SDK) Java.

Qu’en est-il des pannes régionales ?

Les Kits de développement logiciel (SDK) Azure Cosmos DB couvrent la disponibilité régionale et peuvent effectuer de nouvelles tentatives sur une autre région de compte. Reportez-vous à l’article sur les scénarios et configurations de nouvelle tentative des environnements multirégions pour comprendre quels scénarios impliquent d’autres régions.

Quand contacter le service clientèle

Avant de contacter le support technique, suivez ces étapes :

  • Quel est l’impact mesuré en termes de volume d’opérations affectées par rapport aux opérations qui se déroulent correctement ? Est-ce que cela entre dans le cadre des contrats SLA de service ?
  • La latence P99 est-elle affectée ?
  • Les échecs sont-ils liés aux codes d’erreur que mon application doit réessayer et l’application couvre-t-elle ces nouvelles tentatives ?
  • Les échecs affectent-ils toutes les instances de votre application ou uniquement un sous-ensemble ? Lorsque le problème est réduit à un sous-ensemble d’instances, il s’agit généralement d’un problème lié à ces instances.
  • Avez-vous parcouru les documents de résolution des problèmes associés dans le tableau ci-dessus pour éliminer les problèmes survenus dans l’environnement d’application ?

Si toutes les instances d’application sont affectées ou si le pourcentage d’opérations affectées sort du cadre des contrats SLA de service, ou s’il affecte vos propres contrats SLA d’application et P99, contactez le support technique.

Étapes suivantes