Partager via

Modes de connectivité du Kit de développement logiciel (SDK) SQL Azure Cosmos DB

  • S’applique à: ✅ NoSQL

La façon dont un client se connecte à Azure Cosmos DB a des implications importantes sur les performances, en particulier pour la latence côté client observée. Azure Cosmos DB offre un modèle de programmation RESTful simple et ouvert sur HTTPS appelé mode passerelle . En outre, il offre un protocole TCP efficace, qui est également RESTful dans son modèle de communication et utilise TLS pour l’authentification initiale et le chiffrement du trafic, appelé mode direct .

Modes de connectivité disponibles

Les deux modes de connectivité disponibles sont les suivants :

  • Mode passerelle

    Le mode passerelle est pris en charge sur toutes les plateformes sdk. Si votre application s’exécute dans un réseau d’entreprise avec des restrictions de pare-feu strictes, le mode passerelle est le meilleur choix, car il utilise le port HTTPS standard et un seul point de terminaison DNS. Toutefois, le compromis des performances est que le mode passerelle implique un tronçon réseau supplémentaire chaque fois que les données sont lues ou écrites dans Azure Cosmos DB. Nous recommandons également le mode de connexion de passerelle lorsque vous exécutez des applications dans des environnements qui ont un nombre limité de connexions de socket.

    Lorsque vous utilisez le Kit de développement logiciel (SDK) dans Azure Functions, en particulier dans le plan Consommation, tenez compte des limites actuelles des connexions.

  • Mode direct

    Le mode direct prend en charge la connectivité via le protocole TCP, en utilisant TLS pour l’authentification initiale et le chiffrement du trafic, et offre de meilleures performances, car il y a moins de tronçons réseau. L’application se connecte directement aux réplicas principaux. Le mode direct n’est actuellement pris en charge que sur les plateformes du Kit de développement logiciel (SDK) .NET et Java.

Diagramme des modes de connectivité Azure Cosmos DB.

Ces modes de connectivité conditionnent essentiellement l’itinéraire que le plan de données demande (lectures et écritures de documents) prend de votre machine cliente aux partitions dans le back-end Azure Cosmos DB. Le mode direct est l’option préférée pour des performances optimales ; il permet à votre client d’ouvrir des connexions TCP directement à des partitions dans le back-end Azure Cosmos DB et d’envoyer des requêtes directementsans intermédiaire. En revanche, en mode passerelle, les demandes effectuées par votre client sont acheminées vers un serveur appelé passerelle dans le frontend Azure Cosmos DB, qui à son tour distribue vos demandes aux partitions appropriées dans le back-end Azure Cosmos DB.

Plages de ports de service

Lorsque vous utilisez le mode direct, vous devez vous assurer que votre client peut accéder aux ports compris entre 1 0000 et 20000, car Azure Cosmos DB utilise des ports TCP dynamiques. Cela s’ajoute aux ports de passerelle. Lorsque vous utilisez le mode direct sur des points de terminaison privés, Azure Cosmos DB peut utiliser la plage complète de ports TCP de 0 à 65535. Si ces ports ne sont pas ouverts sur votre client et que vous essayez d’utiliser le protocole TCP, vous pouvez recevoir une erreur « 503 Service indisponible ».

Le tableau suivant présente un résumé des modes de connectivité disponibles pour différentes API et les ports de service utilisés pour chaque API :

Mode de connexion Protocole pris en charge Kits SDK pris en charge API/Port de service
Gateway HTTPS Tous les kits SDK SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Immédiat TCP (chiffré via TLS) Kits SDK .NET Kits SDK Java Lors de l’utilisation de points de terminaison publics/de service : les ports de la plage 10000 à 20000

Lors de l’utilisation de points de terminaison privés : les ports compris entre 0 et 65535

Architecture de connexion en mode direct

Comme détaillé dans l’introduction, les clients en mode direct se connectent directement aux nœuds principaux via le protocole TCP. Chaque nœud principal représente un réplica dans un jeu de réplicas appartenant à une partition physique.

Routage

Lorsqu’un SDK Azure Cosmos DB en mode direct effectue une opération, il doit résoudre le réplica principal auquel se connecter. La première étape consiste à savoir quelle partition physique doit accéder à l’opération et, pour cela, le SDK obtient les informations de conteneur qui incluent la définition de clé de partition à partir d’un nœud de passerelle. Il est également nécessaire de disposer d’informations de routage qui contiennent les adresses TCP des réplicas. Les informations de routage sont également disponibles à partir de nœuds de passerelle et sont considérées comme des métadonnées de plan de contrôle. Une fois que le SDK obtient les informations de routage, il peut continuer à ouvrir les connexions TCP aux réplicas appartenant à la partition physique cible et exécuter les opérations.

Un jeu de réplicas contient un réplica principal et trois réplicas secondaires. Les opérations d’écriture sont toujours routées vers les nœuds réplicas principaux, tandis que les opérations de lecture peuvent être servies à partir de nœuds principaux ou secondaires.

Diagramme montrant comment le Kit de développement logiciel (SDK) en mode direct extrait le conteneur et les informations de routage de la passerelle avant d’ouvrir les connexions TCP aux nœuds principaux.

Étant donné que les informations de conteneur et de routage ne changent pas souvent, elles sont mises en cache localement sur les kits SDK afin que les opérations suivantes puissent tirer parti de ces informations. Les connexions TCP déjà établies sont également réutilisées entre les opérations. À moins qu’elles ne soient configurées par le biais des options sdk, les connexions sont conservées définitivement pendant la durée de vie de l’instance du Kit de développement logiciel (SDK).

Comme pour toute architecture distribuée, les machines contenant des réplicas peuvent subir des mises à niveau ou une maintenance. Le service garantit la cohérence de l'ensemble des répliques, mais tout déplacement de réplique entraînerait la modification des adresses TCP existantes. Dans ce cas, les kits SDK doivent actualiser les informations de routage et se reconnecter aux nouvelles adresses par le biais de nouvelles demandes de passerelle. Ces événements ne doivent pas affecter le contrat SLA P99 global.

Volume de connexions

Chaque partition physique dispose d’un jeu de réplicas de quatre réplicas afin de fournir les meilleures performances possibles, les kits SDK finissent par ouvrir des connexions à tous les réplicas pour les charges de travail qui combinent des opérations d’écriture et de lecture. Les opérations simultanées sont équilibrées entre les connexions existantes pour tirer parti du débit fourni par chaque réplica.

Il existe deux facteurs qui déterminent le nombre de connexions TCP que le Kit de développement logiciel (SDK) ouvre :

  • Nombre de partitions physiques

    Dans un état stable, le Kit de développement logiciel (SDK) dispose d’une connexion par réplica par partition physique. Plus le nombre de partitions physiques dans un conteneur est élevé, plus le nombre de connexions ouvertes est élevé. À mesure que les opérations sont routées sur différentes partitions, les connexions sont établies à la demande. Le nombre moyen de connexions serait alors le nombre de partitions physiques fois quatre.

  • Volume de requêtes simultanées

    Chaque connexion établie peut servir un nombre configurable d’opérations simultanées. Si le volume d’opérations simultanées dépasse ce seuil, de nouvelles connexions sont ouvertes pour les servir, et il est possible que pour une partition physique, le nombre de connexions ouvertes dépasse le nombre d’états stables. Ce comportement est attendu pour les charges de travail qui peuvent avoir des pics dans leur volume opérationnel. Pour le Kit de développement logiciel (SDK) .NET, cette configuration est définie par MaxRequestsPerTcpConnection et pour le Kit de développement logiciel (SDK) Java, vous pouvez personnaliser à l’aide de la classe DirectConnectionConfig.

Par défaut, les connexions sont conservées de façon permanente pour bénéficier des performances des opérations futures (l’ouverture d’une connexion a une surcharge de calcul). Il peut y avoir certains scénarios où vous souhaiterez peut-être fermer des connexions inutilisées pendant un certain temps, ce qui peut affecter légèrement les opérations futures. Pour le Kit de développement logiciel (SDK) .NET, cette configuration est définie par IdleTcpConnectionTimeout et pour le Kit de développement logiciel (SDK) Java, vous pouvez personnaliser à l’aide de la classe DirectConnectionConfig. Il n’est pas recommandé de définir ces configurations sur des valeurs faibles, car il peut entraîner la fermeture fréquente des connexions et affecter les performances globales.

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

Pour plus d’informations sur l’implémentation concernant une langue, consultez :

Étapes suivantes

Pour des optimisations spécifiques des performances de la plateforme SDK :

Vous tentez d’effectuer une planification de la capacité pour une migration vers Azure Cosmos DB ? Vous pouvez utiliser les informations sur votre cluster de bases de données existant pour la planification de la capacité.

  • Last updated on