Créez un plan de migration pour migrer d'Apache Cassandra vers Amazon Keyspaces

Téléchargez le script Python de compatibilité depuis GitHub et déplacez-le vers un emplacement ayant accès à votre cluster Apache Cassandra existant.

Le script de compatibilité utilise des paramètres similaires à ceux utilisésCQLSH. Pour --host et --port entrez l'adresse IP et le port que vous utilisez pour vous connecter et exécuter des requêtes sur l'un des nœuds Cassandra de votre cluster.

Si votre cluster Cassandra utilise l'authentification, vous devez également fournir -username et-password. Pour exécuter le script de compatibilité, vous pouvez utiliser la commande suivante.

python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port

Déterminer la taille des lignes

La taille des lignes est importante pour déterminer la capacité de lecture et l'utilisation de la capacité d'écriture dans Amazon Keyspaces. Le schéma suivant montre la distribution typique des données sur une plage de jetons Cassandra.

Vous pouvez utiliser un script d'échantillonnage de taille de ligne disponible sur GitHub pour collecter des mesures de taille de ligne pour chaque table de votre cluster Cassandra.

Le script exporte les données des tables depuis Apache Cassandra en utilisant cqlsh et awk pour calculer l'écart minimum, maximum, moyen et type de la taille des lignes sur un ensemble d'échantillons configurable de données de table. L'échantillonneur de taille de ligne transmet les arguments àcqlsh, de sorte que les mêmes paramètres peuvent être utilisés pour vous connecter et lire à partir de votre cluster Cassandra.

La déclaration suivante en est un exemple.

./row-size-sampler.sh 10.22.33.44 9142 \\
   -u "username" -p "password" --ssl

Pour plus d'informations sur la façon dont la taille des lignes est calculée dans Amazon Keyspaces, consultezEstimer la taille des lignes dans Amazon Keyspaces.

Déterminer la taille de la table

Avec Amazon Keyspaces, vous n'avez pas besoin de provisionner l'espace de stockage à l'avance. Amazon Keyspaces surveille en permanence la taille facturable de vos tables afin de déterminer vos frais de stockage. Le stockage est facturé au. GB-month La taille du tableau Amazon Keyspaces est basée sur la taille brute (non compressée) d'une seule réplique.

Pour contrôler la taille du tableau dans Amazon Keyspaces, vous pouvez utiliser la métriqueBillableTableSizeInBytes, qui est affichée pour chaque tableau dans le Console de gestion AWS.

Pour estimer la taille facturable de votre tableau Amazon Keyspaces, vous pouvez utiliser l'une des deux méthodes suivantes :

• Utilisez la taille moyenne des lignes et multipliez par le nombre de lignes.

  Vous pouvez estimer la taille de la table Amazon Keyspaces en multipliant la taille moyenne des lignes par le nombre de lignes de votre table source Cassandra. Utilisez l'exemple de script de taille de ligne de la section précédente pour capturer la taille moyenne des lignes. Pour capturer le nombre de lignes, vous pouvez utiliser des outils tels que dsbulk count pour déterminer le nombre total de lignes de votre table source.

• Utilisez le nodetool pour collecter les métadonnées du tableau.

  Nodetoolest un outil d'administration fourni dans la distribution Apache Cassandra qui fournit un aperçu de l'état du processus Cassandra et renvoie les métadonnées des tables. Vous pouvez les utiliser nodetool pour échantillonner des métadonnées relatives à la taille de la table et ainsi extrapoler la taille de la table dans Amazon Keyspaces.

  La commande à utiliser estnodetool tablestats. Tablestats renvoie la taille et le taux de compression du tableau. La taille de la table est enregistrée comme tablelivespace pour la table et vous pouvez la diviser parcompression ratio. Multipliez ensuite cette valeur de taille par le nombre de nœuds. Enfin, divisez par le facteur de réplication (généralement trois).

  Il s'agit de la formule complète pour le calcul que vous pouvez utiliser pour évaluer la taille de la table.

  ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)

  Supposons que votre cluster Cassandra possède 12 nœuds. L'exécution de la nodetool tablestats commande renvoie une valeur tablelivespace de 200 Go et une valeur compression ratio de 0,5. Le keyspace possède un facteur de réplication de trois.

  Voici à quoi ressemble le calcul pour cet exemple.

  (200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
                          = 4,800 GB / 3
                          = 1,600 GB is the table size estimate for Amazon Keyspaces

Capturez le nombre de lectures et d'écritures

Pour déterminer les exigences de capacité et d'évolutivité de vos tables Amazon Keyspaces, capturez le taux de demandes de lecture et d'écriture de vos tables Cassandra avant la migration.

Amazon Keyspaces fonctionne sans serveur et vous ne payez que pour ce que vous utilisez. En général, le prix du read/write débit dans Amazon Keyspaces est basé sur le nombre et la taille des requêtes.

Amazon Keyspaces propose deux modes de capacité :

Étant donné que vous provisionnez séparément la capacité de débit de lecture et d'écriture dans Amazon Keyspaces, vous devez mesurer indépendamment le taux de demandes pour les lectures et les écritures dans vos tables existantes.

Pour recueillir les mesures d'utilisation les plus précises de votre cluster Cassandra existant, capturez la moyenne des demandes par seconde (RPS) pour les opérations de lecture et d'écriture au niveau du coordinateur sur une période prolongée pour une table agrégée sur tous les nœuds d'un seul centre de données.

La capture du RPS moyen sur une période d'au moins plusieurs semaines permet de saisir les pics et les creux de vos modèles de trafic, comme le montre le schéma suivant.

Deux options s'offrent à vous pour déterminer le taux de demandes de lecture et d'écriture de votre table Cassandra.

• Utiliser la surveillance Cassandra existante

  Vous pouvez utiliser les mesures présentées dans le tableau suivant pour observer les demandes de lecture et d'écriture. Notez que les noms des métriques peuvent changer en fonction de l'outil de surveillance que vous utilisez.

  Dimension	Métrique Cassandra JMX
  Écritures	org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count
  Lectures	org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

• Utilisation de la nodetool

  Utilisez nodetool tablestats et nodetool info pour capturer les opérations de lecture et d'écriture moyennes à partir de la table. tablestatsrenvoie le nombre total de lectures et d'écritures depuis le moment où le nœud a été initié. nodetool infofournit le temps de disponibilité d'un nœud en secondes.

  Pour obtenir la moyenne des lectures et des écritures par seconde, divisez le nombre de lectures et d'écritures par le temps de disponibilité du nœud en secondes. Ensuite, pour les lectures, vous divisez par le niveau de cohérence et pour les écritures, vous divisez par le facteur de réplication. Ces calculs sont exprimés dans les formules suivantes.

  Formule pour le nombre moyen de lectures par seconde :

  ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime

  Formule pour le nombre moyen d'écritures par seconde :

  ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime

  Supposons que nous ayons un cluster de 12 nœuds en activité depuis 4 semaines. nodetool inforenvoie 2 419 200 secondes de disponibilité et nodetool tablestats renvoie 1 milliard d'écritures et 2 milliards de lectures. Cet exemple aboutirait au calcul suivant.

  ((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
  =  12 billion reads / 2,419,200 seconds
  =  4,960 read request per second
                          ((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
  =  4 billion writes / 2,419,200 seconds
  =  1,653 write request per second

Déterminez l'utilisation de la capacité de la table

Pour estimer l'utilisation moyenne de la capacité, commencez par les taux de demande moyens et la taille moyenne des lignes de votre table source Cassandra.

Amazon Keyspaces utilise des unités de capacité de lecture (RCU) et des unités de capacité d'écriture (WCU) pour mesurer la capacité de débit allouée pour les lectures et les écritures des tables. Pour cette estimation, nous utilisons ces unités pour calculer les besoins en capacité de lecture et d'écriture de la nouvelle table Amazon Keyspaces après la migration.

Plus loin dans cette rubrique, nous verrons comment le choix entre le mode de capacité provisionné et le mode de capacité à la demande affecte la facturation. Mais pour l'estimation de l'utilisation de la capacité dans cet exemple, nous supposons que la table est en mode provisionné.

La formule suivante peut être utilisée pour estimer les UCR et les WCU requises.

Ceci est exprimé dans les formules suivantes.

Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) =  RCUs per second
                
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second

Par exemple, si vous effectuez 4 960 demandes de lecture avec une taille de ligne de 2,5 Ko sur votre table Cassandra, vous avez besoin de 4 960 RCU dans Amazon Keyspaces. Si vous effectuez actuellement 1 653 demandes d'écriture par seconde avec une taille de ligne de 2,5 Ko sur votre table Cassandra, vous avez besoin de 4 959 WCU par seconde dans Amazon Keyspaces.

Cet exemple est exprimé dans les formules suivantes.

4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
                
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit) 
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs

L'utilisation vous eventual consistency permet d'économiser jusqu'à la moitié de la capacité de débit sur chaque demande de lecture. Chaque lecture finalement cohérente peut consommer jusqu'à 8 Ko. Vous pouvez calculer d'éventuelles lectures cohérentes en multipliant le calcul précédent par 0,5, comme indiqué dans la formule suivante.

4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 
= 2,480 read request per second * 1 RCU
= 2,480 RCUs

Calculez l'estimation de prix mensuelle pour Amazon Keyspaces

Pour estimer la facturation mensuelle de la table en fonction du débit de read/write capacité, vous pouvez calculer la tarification pour le mode à la demande et pour le mode provisionné à l'aide de différentes formules et comparer les options de votre tableau.

Mode provisionné  : la consommation de capacité de lecture et d'écriture est facturée selon un taux horaire basé sur les unités de capacité par seconde. Tout d'abord, divisez ce taux par 0,7 pour représenter l'utilisation cible d'autoscaling par défaut de 70 %. Multipliez ensuite par 30 jours civils, 24 heures sur 24, et le tarif régional.

Ce calcul est résumé dans les formules suivantes.

(read capacity per second / .7) * 24 hours * 30 days * regional rate
                (write capacity per second / .7) * 24 hours * 30 days * regional rate

On-demand mode — Les capacités de lecture et d'écriture sont facturées au tarif par demande. Commencez par multiplier le taux de demandes par 30 jours civils et 24 heures par jour. Divisez ensuite par un million d'unités de requête. Enfin, multipliez par le taux régional.

Ce calcul est résumé dans les formules suivantes.

((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
                ((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate