Cette section résume nos bonnes pratiques et fournit nos recommandations pour l'utilisation d'OPDK avec le cloud AWS.
Cassandra est utilisé comme backend et datastore pour presque toutes les règles. Il s'agit d'un élément essentiel de l'environnement d'exécution Apigee Edge. Ce document se concentre sur l'optimisation de Cassandra pour l'environnement AWS.
Exigences de stockage et d'E/S
La plupart des E/S Cassandra sont séquentielles, mais il peut arriver que vous ayez besoin d'E/S aléatoires. Par exemple, lors de la lecture de tables de chaînes triées pendant les opérations de lecture. Le SSD est le mécanisme de stockage recommandé pour Cassandra, car il offre des temps de réponse à très faible latence pour les opérations de lecture aléatoire, tout en fournissant des performances d'écriture séquentielle suffisantes pour les opérations de compactage. La réplication est également prise en compte ici.
De nombreuses instances d'AWS EC2 sont fournies avec un stockage local dans lequel le disque dur est physiquement rattaché au matériel sur lequel l'instance EC2 est hébergée. Apigee recommande d'utiliser à la fois des disques SSD et des stockages d'instances lors de l'exécution de Cassandra en production. Lorsque vous utilisez un type d'instance avec plus d'un SSD, vous pouvez utiliser RAID0 pour obtenir plus de débit et de capacité de stockage.
Configuration réseau requise
Cassandra utilise le protocole Gossip pour échanger des informations avec d'autres nœuds sur la topologie du réseau. En plus de la nature distribuée de Cassandra qui implique de communiquer avec plusieurs nœuds pour les opérations de lecture et d'écriture, l'utilisation de Gossip entraîne le transfert d'un grand nombre de données via le réseau. Apigee recommande d'utiliser un type d'instance disposant d'une bande passante réseau d'au moins 1 Gbit/s et de plus de 1 Gbit/s pour les systèmes de production.
Utilisez un VPC avec un CIDR de /16. Étant donné que les sous-réseaux dans AWS ne peuvent pas s'étendre sur plus d'une zone de disponibilité, Apigee recommande ce qui suit :
- Créez un sous-réseau par zone de disponibilité.
- Utilisez trois sous-réseaux privés pour votre installation Apigee, avec un nœud Cassandra dans chaque zone de disponibilité. Les trois sous-réseaux doivent disposer de suffisamment de blocs CIDR pour permettre l'expansion horizontale du cluster Cassandra.
- Configurez trois sous-réseaux publics avec une NAT dédiée pour que Cassandra puisse communiquer avec Internet pour le téléchargement de logiciels et les mises à jour de sécurité.
Contrairement aux anciennes architectures maître-esclave, Cassandra possède une architecture sans maître dans laquelle tous les nœuds jouent un rôle identique. Il n'y a donc pas de point de défaillance unique. Envisagez de répartir vos nœuds Cassandra sur plusieurs zones de disponibilité pour assurer la haute disponibilité. En répartissant les nœuds entre les zones de disponibilité, vous pouvez maintenir la disponibilité et le temps d'activité en cas de sinistre.
Choisir une famille d'instances
Lorsque vous examinez les exigences de Cassandra en termes de processeur, il est utile de noter que les charges de travail à forte intensité d'insertion sont liées au processeur dans Cassandra avant d'être liées aux E/S. En d'autres termes, toutes les opérations d'écriture sont envoyées au journal de commit, mais Cassandra est si efficace en écriture que le processeur devient le facteur limitant. Cassandra est hautement simultané et utilise autant de cœurs de processeur que possible.
Apigee recommande d'utiliser une famille d'instances, qui offre un équilibre entre le processeur et la mémoire. Plus précisément, nous vous recommandons d'utiliser des instances de la famille C5 si elles sont disponibles dans votre région AWS, et des instances C3 comme option de remplacement. Dans certains cas, 4xlarge est l'instance optimale dans les deux familles qui offre le meilleur rapport prix/performances.
Apigee recommande également d'utiliser une location par défaut pour les instances Cassandra. Lorsque vous effectuez un scaling pour passer à plus d'une instance par zone de disponibilité, il est fort probable que toutes vos instances Cassandra soient placées sur le même matériel sous-jacent si vous définissez la location sur "Dédiée". Ainsi, en cas de défaillance matérielle, vous perdrez probablement toutes vos instances dans cette AZ.
Récapitulatif des recommandations
Le tableau suivant récapitule les recommandations d'Apigee pour l'utilisation d'AWS avec Apigee Edge pour Private Cloud :
| Famille d'instances | C5d (de préférence) ou C3 |
| Type d'instance | C(x).4xlarge |
| Instance Store | SSD (stockage local) avec RAID0 |
| Type de location | par défaut |
| Emplacement des nœuds | 1 nœud Cassandra par AZ |
| VPC et sous-réseau | Un sous-réseau par zone de disponibilité et un VPC par région |
Pour en savoir plus, consultez Types d'instances Amazon.