Comment puis-je résoudre les problèmes liés aux exceptions ReadTimeout et WriteTimeout dans Amazon Keyspaces ?
Je souhaite résoudre les problèmes liés aux exceptions de dépassement de délais d'attente dans Amazon Keyspaces (pour Apache Cassandra).
Résolution
Amazon Keyspaces fonctionne sans serveur, contrairement à Apache Cassandra qui est conçu pour exécuter un cluster sur une flotte de nœuds. Apache Cassandra ne comporte aucune exception liée aux fonctionnalités sans serveur, notamment la capacité. La plupart des implémentations du pilote Apache Cassandra ne gèrent que les erreurs disponibles dans Apache Cassandra. Par conséquent, Amazon Keyspaces doit utiliser les mêmes codes d'erreur pour garantir la compatibilité.
Pour plus d'informations sur la résolution des problèmes de connexion, reportez-vous à Résolution des problèmes de connexion dans Amazon Keyspaces.
Pour résoudre les problèmes de temporisation dans Keyspaces, utilisez la surveillance Amazon CloudWatch. Pour consulter les statistiques de la table, vous pouvez utiliser les graphiques de la console Amazon Keyspaces. Sélectionnez la table, puis choisissez l'onglet Surveiller. Pour plus d'informations sur l'utilisation de CloudWatch pour surveiller les métriques Apache Cassandra disponibles, reportez-vous à Métriques et dimensions d'Amazon Keyspaces.
Vous pouvez également utiliser un modèle AWS CloudFormation (à partir du site Web GitHub) pour déployer un tableau de bord CloudWatch afin de surveiller vos espaces clés ou vos tables individuelles. Vous pouvez surveiller les métriques suivantes :
- PerConnectionRequestRateExceeded
- StoragePartitionThroughputCapacityExceeded
- ReadThrottleEvents et WriteThrottleEvents
PerConnectionRequestRateExceeded
La métrique PerConnectionRequestRateExceeded mesure les requêtes Amazon Keyspaces qui dépassent le quota de débit par requête de connexion. Une connexion à un pair peut prendre en charge jusqu'à 3 000 requêtes CQL par seconde. Pour plus d'informations, reportez-vous à Quotas pour Amazon Keyspaces (pour Apache Cassandra). Lorsque vous vous connectez à un terminal public, neuf pairs sont disponibles pour se connecter. Par conséquent, la limite par défaut est de 27 000 requêtes CQL par seconde avec le paramètre de pilote par défaut d'une connexion par pair.
Lorsque vous utilisez un point de terminaison Amazon Virtual Private Cloud (Amazon VPC), le nombre de pairs dépend du nombre de zones de disponibilité dans lesquelles le point de terminaison dispose d'une interface. Par exemple, ap-southeast-2 inclut trois zones de disponibilité. Dans cette région, avec une connexion par pair configurée, votre application est limitée à 9 000 requêtes CQL par seconde. Pour augmenter le nombre de requêtes CQL autorisées par seconde, augmentez le nombre de connexions effectuées par pair. Par exemple, l'utilisation d'un point de terminaison public pour définir le nombre de connexions à deux par pair fournit 9 * 3 000 * 2 = 54 000 requêtes CQL.
Si vous utilisez le pilote Java Datastax v3, assurez-vous que votre cluster inclut les options de regroupement suivantes :
Cluster cluster =Cluster.builder() .addContactPoint("cassandra.ap-southeast-2.amazonaws.com") .withPort(9142) ... .withPoolingOptions(new PoolingOptions().setConnectionsPerHost(HostDistance.LOCAL,9,9)) .build();
Si vous utilisez le pilote Java Datastax v4, assurez-vous que le fichier application.conf inclut les éléments suivants :
datastax-java-driver { advanced.connection { pool { local { size = 9 } } } }
Vous ne pouvez pas utiliser le protocole v3 ou v4 requis par Amazon Keyspaces pour augmenter le nombre de connexions par pair avec le pilote Python. Si vous utilisez le pilote Datastax Java v4, désactivez hostname-validation. Si vous l'activez, le pilote se connecte à un seul pair et limite considérablement le nombre total de requêtes par seconde.
Le fichier application.conf doit inclure les éléments suivants :
datastax-java-driver { advanced { ssl-engine-factory { class = DefaultSslEngineFactory hostname-validation = false } } }
Lorsque vous vous connectez par le biais d'un point de terminaison Amazon VPC, ajoutez des autorisations à votre politique AWS Identity and Access Management (IAM) pour permettre à Amazon Keyspaces d'interroger les informations de votre VPC et de votre point de terminaison. Ces informations sont requises pour remplir la table system.peers. La politique IAM doit disposer des autorisations suivantes :
{ "Version": "2012-10-17", "Statement": [{ "Sid": "ListVPCEndpoints", "Effect": "Allow", "Action": ["ec2:DescribeNetworkInterfaces", "ec2:DescribeVpcEndpoints"], "Resource": "*" }] }
Si la politique IAM ne dispose pas de ces autorisations, votre pilote ne peut se connecter qu'à un seul hôte, ce qui limite le nombre total de requêtes par seconde.
StoragePartitionThroughputCapacityExceeded
La métrique StoragePartitionThroughputCapacityExceeded mesure les requêtes qui dépassent la limite de 3 000 RCU/RRU et de 1 000 WCU/WRU d'une partition. Cela signifie que vos modèles de trafic actuels se concentrent sur une ou plusieurs partitions, au lieu d'être répartis uniformément sur plusieurs partitions. Pour résoudre ce problème, modifiez vos modèles de trafic. Pour plus d'informations, reportez-vous à Modélisation des données dans Amazon Keyspaces (pour Apache Cassandra).
ReadThrottleEvents et WriteThrottleEvents
Les métriques ReadThrottleEvents et WriteThrottleEvents mesurent les requêtes qui dépassent la capacité disponible pour une table ou un compte AWS. Notez que toutes les limitations provoquées par PerConnectionRequestRateExceeded sont également incluses dans les métriques.
Si vous utilisez de la capacité allouée, augmentez la capacité configurée en lecture ou en écriture. Vous pouvez également utiliser AWS Auto Scaling. Si vous utilisez AWS Auto Scaling, augmentez la capacité maximale disponible. Cette augmentation peut nécessiter une augmentation de la table de comptes ou de la limite de régions AWS pour permettre une mise à l'échelle plus élevée. Si vous rencontrez des pics de trafic qu'Auto Scaling ne peut pas gérer, utilisez plutôt les réserves de capacité à la demande.
Erreur AllNodesFailedException ou NoHostAvailable
Lorsqu'un problème survient, tel qu'un dépassement du délai de lecture ou d'écriture, les pilotes Apache Cassandra essaient de se connecter à un autre pair par défaut. Dans le cas d'un cluster Apache Cassandra, cela peut permettre d'éviter qu'un seul nœud ne soit à l'origine du problème. Toutefois, pour Amazon Keyspaces, le nouveau nœud peut rencontrer le même problème. Amazon Keyspaces peut ensuite passer au pair suivant jusqu'à ce que tous les pairs soient épuisés. Dans ce cas, le message d'erreur AllNodesFailedException ou NoHostAvailable s'affiche.
Il est recommandé de configurer le pilote pour qu'il reste sur l'hôte et de mettre en œuvre un mécanisme de backoff exponentiel et de nouvelle tentative. Pour voir des exemples de configurations, reportez-vous à amazon-keyspaces-java-driver-helpers sur le site Web GitHub.
Contenus pertinents
- demandé il y a 3 moislg...
- demandé il y a 5 moislg...
- demandé il y a 8 moislg...
- demandé il y a 2 anslg...
- demandé il y a 7 moislg...
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an