Partager via

Modes de connectivité du SDK SQL Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

La façon dont un client se connecte à Azure Cosmos DB a des conséquences importantes sur les performances, notamment en matière de latence côté client. 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 connexion disponibles sont les suivants :

  • Mode passerelle

    Le mode de 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 la meilleure option, car il utilise le port HTTPS standard et un seul point de terminaison DNS. Toutefois, il existe un compromis en termes de performances : 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 vous recommandons le mode de connexion de passerelle quand vous exécutez des applications dans des environnements présentant un nombre limité de connexions de socket.

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

  • 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 est actuellement uniquement pris en charge sur les plateformes SDK .NET et Java.

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) pris de votre ordinateur client vers des partitions dans le serveur principal Azure Cosmos DB. Le mode direct est l’option la plus appropriés pour optimiser les performances. Il permet à votre client d’ouvrir des connexions TCP directement aux partitions dans le back-end Azure Cosmos DB et d’envoyer des demandes directement, sans intermédiaire. En revanche, en mode passerelle, les demandes effectuées par votre client sont acheminées vers un serveur « passerelle » dans le Azure Cosmos DB frontal, qui à son tour répartit vos demandes vers les partitions appropriées dans le serveur principal Azure Cosmos DB.

Plages de ports de service

Lorsque vous utilisez le mode direct, vous devez vous assurer que votre client peut accéder à des ports compris entre 10 000 et 20 000, 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, la plage complète des ports TCP (de 0 à 65 535) peuvent être utilisés par Azure Cosmos DB. Si ces ports ne sont pas ouverts et que votre client et vous-même essayez d’utiliser le protocole TCP, vous pouvez recevoir une erreur 503 de service non disponible.

Le tableau suivant présente un résumé des modes de connectivité disponibles pour les 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
Passerelle HTTPS Tous les kits SDK SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direct 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 indiqué 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 Kit de développement logiciel (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 Kit de développement logiciel (SDK) obtient les informations du 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 des nœuds de passerelle et les deux sont considérées comme des métadonnées du 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.

Chaque jeu de réplicas contient un réplica principal et trois 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 qui montre comment les SDK en mode direct récupèrent le conteneur et les informations de routage de la passerelle avant d’ouvrir les connexions TCP aux nœuds principaux

Comme les informations relatives au conteneur et au routage ne changent pas souvent, elles sont mises en cache localement sur les SDK afin que les opérations suivantes puissent bénéficier 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 SDK.

Comme pour toute architecture distribuée, les machines qui détiennent des réplicas peuvent subir des mises à niveau ou une maintenance. Le service garantit la cohérence du jeu de réplicas, mais tout déplacement de réplica entraîne la modification des adresses TCP existantes. Dans ces cas, les KITS de développement logiciel (SDK) doivent actualiser les informations de routage et se connecter à nouveau aux nouvelles adresses via 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.

Deux facteurs dictent le nombre de connexions TCP ouvertes par le Kit de développement logiciel (SDK) :

  • 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 l’est également. À 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 égal au nombre de partitions physiques multiplié par quatre.

  • Volume de requêtes simultanées

    Chaque connexion établie peut servir un nombre configurable d’opérations simultanées. Si le volume des 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 de volume opérationnel. Pour le Kit de développement logiciel (SDK) .NET, cette configuration est définie par CosmosClientOptions.IdleTcpConnectionTimeout et pour le Kit de développement logiciel (SDK) Java, vous pouvez personnaliser le comportement à l’aide de DirectConnectionConfig.setMaxRequestsPerConnection.

Par défaut, les connexions sont maintenues en permanence afin de favoriser les performances des opérations futures (l’ouverture d’une connexion entraîne une surcharge de calcul). Il peut arriver que vous souhaitiez fermer des connexions inutilisées depuis un certain temps, sachant que cela peut affecter légèrement les opérations futures. Pour le Kit de développement logiciel (SDK) .NET, cette configuration est définie par CosmosClientOptions.IdleTcpConnectionTimeout et pour le Kit de développement logiciel (SDK) Java, vous pouvez personnaliser à l’aide de DirectConnectionConfig.setIdleConnectionTimeout. Il n’est pas recommandé de définir ces configurations sur des valeurs faibles, car cela pourrait entraîner la fermeture répétée 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 un langage, consultez :

Étapes suivantes

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