10M Ops/sec @ 1msec latence avec seulement 6 nœuds EC2

10M Ops/sec @ 1msec latence avec seulement 6 nœuds EC2

Notre nouveau Redis Enterprise 5.0 a introduit la prise en charge de l’API de cluster Open Source (OSS), qui permet un Grappe d’entreprise Redis pour évoluer à l’infini et de manière linéaire en ajoutant simplement des fragments et des nœuds. L’API de cluster OSS s’appuie sur l’intelligence des clients pour décider à quel fragment/nœud envoyer la demande en fonction de la partie clé de l’élément clé/valeur et d’une fonction de hachage partagée entre les clients et le cluster. Ce billet explique comment Entreprise Redis fonctionne avec l’API du cluster OSS et valide l’évolutivité linéaire infinie des performances.

Pour ceux d’entre vous qui ne sont pas familiers avec l’architecture Redis Enterprise, commençons par un bref historique :

L’architecture d’entreprise Redis en bref

Un cluster, en termes Redis Enterprise, est un ensemble d’instances cloud, de nœuds de machines virtuelles/de conteneurs ou de serveurs bare metal qui vous permet de créer un nombre illimité de bases de données Redis (une base de données dans la terminologie Redis Enterprise est l’entité qui gère l’ensemble de votre ensemble de données sur plusieurs partitions/instances Redis. Ne confondez pas cela avec les bases de données à l’intérieur de chaque instance Redis que vous pouvez exploiter pour effectuer une segmentation dans votre espace de clés à l’aide de la commande Redis SELECT.) dans le pool de mémoire partagé sur l’ensemble. Le cluster a une architecture symétrique sans partage, une séparation complète entre le chemin de données et le chemin de contrôle et de gestion, et il comprend les composants principaux suivants :

  • Redis Shards (data-path) – une instance Redis avec un rôle maître ou esclave
  • Proxy à latence zéro (chemin de données) – construit sur une architecture de transition, multithread et sans état et est responsable de la dissimulation de la complexité du cluster, de l’amélioration de la sécurité (SSL, authentification, protection DDoS) et de l’amélioration des performances (sans TCP, connexion gestion et pipeline)
  • Cluster Manager (chemin de contrôle et de gestion) – construit à partir d’un ensemble de processus distribués qui résident sur chaque nœud du cluster. Le gestionnaire de cluster s’occupe des activités de configuration du cluster, des demandes de provisionnement, de la gestion et de la surveillance des ressources, ainsi que d’agir en tant que chien de garde des ressources et de se décharger complètement de la tâche consistant à faire en sorte que les fragments Redis gèrent la santé des autres fragments du cluster ou prennent des décisions de basculement.

redisee architecture

Une base de données dans le cluster Redis Enterprise peut être créée dans l’une des configurations ci-dessous :

redisee db modes

Sur la base de sa puissante technologie multi-tenant, un cluster Redis Enterprise peut gérer plusieurs bases de données de différents types sur les mêmes ressources de cluster de manière totalement isolée.

Redis Enterprise avec l’API de cluster OSS

Afin d’utiliser la nouvelle API de cluster OSS, vous devez utiliser les propriétés suivantes lors de la création d’une base de données avec l’API Redis Enterprise :

  • “shards_placement”: “sparse” – distribue les fragments sur les nœuds du cluster Redis Enterprise
  • “proxy_policy”: “all-master-shards” – attribue un proxy sur chaque nœud qui a au moins un fragment maître
  • “oss_cluster”: “true” – rendre la base de données accessible via l’API du cluster OSS

Cela créera une base de données en cluster avec des propriétés similaires à celles présentées ci-dessous :

redisee

Comme tu peux le voir:

  • Du point de vue du client Redis, chaque proxy représente une plage de hash-slots (HS) égale à la somme de tous les HS servis par les fragments maîtres hébergés sur le nœud du proxy. En d’autres termes, du point de vue du client, le proxy représente une grande instance Redis avec un rôle de maître
  • Comme dans le cluster OSS, le client (un client OSS standard) envoie des requêtes au proxy concerné en fonction de la clé d’un élément clé/valeur et de la fonction de hachage du cluster Redis.
  • Une fois que la requête arrive au proxy, elle est transmise au fragment concerné sur le nœud en appliquant la même fonction de hachage.
  • Dans le cas d’un changement de topologie du cluster, c’est-à-dire migration de shard, basculement maître/esclave, etc., le proxy met à jour les HS qu’il gère et redirige si nécessaire les requêtes des clients vers un autre nœud du cluster (grâce à la réponse MOVED).

Construire l’environnement de test

Dans cet esprit, nous avons décidé de créer un environnement de test sur AWS pour valider si Redis Enterprise peut vraiment évoluer à l’infini et de manière linéaire. Comme nous avions prévu d’avoir une charge importante, nous avons décidé d’utiliser des instances EC2 m4.16xlarge (64 cœurs, 256 Go de RAM) pour les nœuds de cluster et des instances c4.8xlarge (36 cœurs, 60 Go de RAM) pour l’exécution. memtier_benchmarkun outil de génération de charge multithread open source.

L’utilisation de plusieurs instances de memtier_benchmark est indispensable, car dans de nombreux cas, un seul nœud Redis Enterprise peut gérer plus de trafic que le volume qu’une seule instance de memtier_benchmark peut générer. Cette approche nous permet également d’éviter les limitations de bande passante réseau et de paquets par seconde d’une seule carte réseau et facilite l’augmentation de la charge de trafic étape par étape (instance par instance).

Voici à quoi ressemble notre configuration finale :

  • 6 instances m4.16xlarge pour les nœuds de cluster Redis Enterprise :

bm nodes

  • 8 instances c4.8xlarge exécutant memtier_benchmark

bm clients

  • Nous avons utilisé Ubuntu Server 16.04 comme système d’exploitation et nous nous sommes assurés que les machines étaient configurées pour prendre en charge Mise en réseau améliorée. Toutes les instances ont été placées dans le même VPC, la même zone de disponibilité, le même sous-réseau et le même groupe de placement.

Création et réglage d’une base de données en cluster

Nous avons créé une base de données Redis en cluster de 192 partitions à l’aide de l’API Redis Enterprise avec les paramètres suivants :

{
"name": "api-benchmark",
"replication": false,
"port" : 12345,
"sharding": true,
"shards_count" : 192,
"version": "4.0",
"memory_size": 100000000000,
"type": "redis",
"oss_cluster":true,
"proxy_policy": "all-master-shards",>
"shards_placement": "sparse",
"shard_key_regex": [{"regex": ".*{(?.*)}.*"}, {"regex": "(?.*)"}]
}

> curl -k -X POST -u ":" -H "Content-Type: application/json" -d @create_db.json https://localhost:9443/v1/bdbs

Nous avons réglé le proxy sur chaque nœud pour faire face à la charge attendue en définissant le nombre de threads proxy sur 24 :

> rladmin tune proxy all max_threads 24
> rladmin tune proxy all threads 24

Remplissage de la base de données et exécution des tests

Nous avons utilisé la nouvelle version de memtier_benchmark qui prend en charge l’API du cluster OSS pour remplir d’abord la base de données avec environ 10 millions d’éléments, puis exécuter les tests.

Voici les paramètres memtier_benchmark que nous avons utilisés lors de nos étapes de population et de benchmark :

  • Modèle de clé: Nous avons utilisé un modèle d’accès aléatoire unifié pour les lectures et les écritures (−−key-pattern=R:R).
  • Nombre d’objets: Nous avons dû trouver une combinaison pour remplir et accéder à tous les emplacements de hachage de la manière la plus égale possible. Ceci a été réalisé en combinant le nombre de requêtes avec une plage de clés par slot (−−key-minimum=1 −−key-maximum=611 −−num_requests=40042496). Compte tenu de l’accès aléatoire, il était possible d’appuyer plusieurs fois sur la même touche pendant la population, c’est pourquoi nous avons exécuté plus de requêtes que notre objectif de 10 millions d’éléments.
  • Taille des données: Nous avons testé les tailles d’article (valeur) 100B et 500B.
  • Rapport écriture/lecture: Nous avons testé une charge de travail mixte (−−ratio=1:1), une charge de travail en lecture seule (−−ratio=0:1) et une charge de travail en écriture seule (−−ratio=1:0).
  • Canalisation: Nous avons utilisé une taille de pipeline réaliste pour tous nos tests, c’est-à-dire −−pipeline=9.
  • Nombre de clients et nombre de threads: Le nombre de connexions créées par notre instance memtier_benchmark était égal à la multiplication du nombre de threads (-t) et du nombre de clients par thread (-c). Dans notre configuration finale, chacune des 8 machines clientes de référence a exécuté 40 clients sur 12 à 15 threads, créant plus de 3 000 connexions au cluster au total.

Voici un exemple de ligne de commande memtier_benchmark :

> memtier_benchmark -s $DB_SERVER -p $DB_PORT
--pipeline=$PIPELINE_SIZE -c $NUM_CLIENTS -t $NUM_THREADS
-d $DATA_SIZE --key-minimum=$KEY_MIN
--key-maximum=$MAX_KEYS_PER_SLOT --key-pattern=R:R
--ratio=$WR_RATIO --run-count=1 --requests=$NUM_REQ
--out-file=$OUT_FILE --oss-cluster

Résultats de test

Notre configuration finale a exécuté une base de données de 192 partitions sur seulement 6 nœuds sur le cluster Redis Enterprise et a démontré des résultats exceptionnels : plus de 10 millions d’opérations/sec à une latence légèrement supérieure à 1 msec ! Voici une capture d’écran tirée de l’interface utilisateur Redis Enterprise :

results

Nous avons mené cette expérience afin de valider que l’architecture sans partage de Redis Enterprise peut évoluer de manière linéaire grâce à la nouvelle API de cluster OSS introduite dans Redis Enterprise 5.0. Notre expérience comprenait :

  • Analyse comparative d’une base de données à 32 partitions sur un cluster Redis Enterprise à nœud unique
  • Analyse comparative d’une base de données de 64 partitions sur un cluster Redis Enterprise à deux nœuds
  • Analyse comparative d’une base de données de 192 partitions sur un cluster Redis Enterprise à 6 nœuds

Nous avons constaté une évolutivité linéaire des performances lors du passage d’un cluster à 1 nœud à un cluster à 6 nœuds, comme illustré dans le graphique suivant :

scalability

Une analyse plus approfondie de ces résultats indique que le débit par nœud n’a pas changé de plus de 10 % lors du passage d’un cluster à un seul nœud à un cluster à deux nœuds, puis à un cluster à 6 nœuds. Nous pensons que ces changements de performances entre les tests pourraient être liés à différentes conditions de ressources (réseau, VM, etc.) à chaque itération de test.

throughput per node

Sommaire

Avec l’introduction de l’API de cluster OSS, Redis Enterprise 5.0 peut facilement évoluer de manière linéaire en ajoutant simplement des fragments à la base de données et des nœuds au cluster, comme le prouve ce benchmark. Nous prévoyons de continuer à battre des records de performances dans l’espace des bases de données, mais nous voulions partager cela pour re:invent 2017, nous nous sommes donc arrêtés ici. S’il vous plaît restez à l’écoute!

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *