Bonnes pratiques opérationnelles relatives à ISVs

La plupart des directives de cette section constituent les meilleures pratiques pour tous les clients, mais elles ont une importance accrue pourISVs.

Mettez à jour votre cluster Neptune avec les dernières versions

Dans les notes de mise à jour d'Amazon Neptune, vous pouvez voir que chaque version apporte un certain nombre de corrections de bogues, d'améliorations des performances et de nouvelles fonctionnalités. Utilisez la dernière version de vos clusters Neptune autant que possible.

Si vous trouvez un bogue non découvert dans votre charge de travail et que votre cluster utilise la dernière version, les ingénieurs de Neptune peuvent créer un correctif privé pour votre cluster (si cela est justifié et si vous le souhaitez). Le correctif peut être transféré jusqu'à la prochaine version, date à laquelle ce correctif sera généralement disponible. Pour vous aider à mettre à jour vos clusters vers la dernière version, utilisez la solution Neptune Blue/Green.

Utilisez des deltas au lieu de supprimer et de remplacer pour l'ingestion de données

Vous pouvez utiliser plusieurs techniques pour apporter ou écrire des données dans Neptune. De nombreux clients essaient de simplifier leur ingestion de données en supprimant et en réinsérant leur graphique chaque fois qu'une modification est reçue dans le flux. Ils peuvent ajouter une last-modified propriété à chaque nœud et rechercher régulièrement les nœuds qui n'ont pas été modifiés depuis une date spécifiée et les supprimer. Bien que ces techniques simplifient le processus d'ingestion des données, elles ont des répercussions sur la santé et l'évolutivité à long terme de votre cluster Neptune.

Neptune utilise tout d'abord le codage des chaînes par dictionnaire. À moins que vous ne spécifiiez explicitement les IDs nœuds et les arêtes, Neptune génère une chaîne GUID représentée sous forme de chaîne pour l'ID et stocke cette chaîne dans le dictionnaire. Si vous supprimez et ajoutez constamment des objets, la génération automatique IDs provoquera une surcharge dans le dictionnaire.

Ensuite, Neptune évolue pour ingérer au maximum 120 000 objets par seconde. Si vous supprimez et ajoutez continuellement des objets, vous consommez une grande partie de cette bande passante sur des objets qui ne changent pratiquement pas. Cela limite le nombre de locataires que vous pouvez héberger sur un cluster, nécessite des instances d'écriture plus importantes dans les clusters et nécessite davantage d'opérations d'E/S. Tous ces facteurs augmentent vos coûts.

Nous vous recommandons vivement de développer un moyen de calculer le delta réel de ce qui a changé au lieu d'utiliser les méthodes de suppression et d'ajout. Cependant, certaines sources de données ne sont pas propices à cela (par exemple, les API appels renvoyant l'état actuel ou les événements qui ne permettent pas de suivre exactement ce qui a changé). Si votre source de données brutes ne permet pas d'identifier les modifications, utilisez vos processus d'extraction, de transformation et de chargement (ETL) pour calculer le delta. Par exemple, vous pouvez conserver les instantanés de chaque capture de données précédente au format Parquet, les utiliser AWS Glue pour calculer les différences entre ces instantanés et transmettre uniquement les différences à Neptune.

Modélisez l'évolution des coûts de Neptune avec vos locataires

Que vous utilisiez un modèle de silo, de pool ou hybride, vos coûts de cloud évolueront en fonction de la taille de vos locataires. Les locataires qui ont besoin d'un plus grand nombre de connexions simultanées ont besoin d'instances plus grandes ou de répliques en lecture que ceux qui ont moins de connexions simultanées. Il en va de même pour les locataires qui ont besoin d'une ingestion de données plus rapide.

Les trois composantes du coût du cluster Neptune sont la taille (et le nombre) d'instances, la taille des données (Go-mois) et les opérations d'E/S (par million). Bien que ces coûts soient généralement spécifiques à la charge de travail, ils varient en fonction de la taille et du volume de données et peuvent être mesurés à l'aide d' AWS outils. Suivez et comprenez les économies d'échelle par rapport aux indicateurs clés de la taille de vos locataires, notamment la façon dont leur taille varie au fil du temps. Si l'imprévisibilité de vos frais d'E/S a un impact sur vos marges, pensez à choisir le stockage optimisé pour les E/S de Neptune pour un coût plus prévisible.

Adaptez vos clusters à la demande des clients

Il n'existe aucune formule éprouvée pour dimensionner correctement la taille de votre instance Neptune. La documentation de Neptune fournit des conseils, mais les variables sont trop nombreuses pour recommander un mappage direct. Ces variables incluent, mais sans s'y limiter :

• Modèle de données

• Forme de données

• Simultanéité des requêtes

• Complexité de requête

Planifiez des tests afin de déterminer la taille optimale pour vos charges de travail et vos profils de locataires. En général, nous recommandons d'utiliser des instances provisionnées pour des raisons de rentabilité et de prévisibilité. Si vos objectifs en matière d'expérience client privilégient une évolutivité optimale par rapport aux coûts, pensez à utiliser les instances Neptune Serverless pour garantir une expérience plus cohérente, quelles que soient les fluctuations de charge de travail.

Si les charges de travail de lecture de votre locataire présentent une variabilité significative entre leurs pics et leurs creux, combinez les instances Neptune Serverless avec l'auto-scaling de Neptune.  Il faut généralement 10 à 15 minutes pour qu'une nouvelle réplique de lecture soit mise en ligne après son initialisation. Cela signifie que l'auto-scaling peut à lui seul gérer les variations prolongées du trafic, mais qu'il n'est pas suffisant pour les pics d'activité qui évoluent rapidement. En combinant Neptune Serverless et Neptune auto-scaling, vous pouvez à la fois augmenter ou diminuer le nombre de répliques de lecture entrantes et sortantes.

Si vos locataires ont des profils de charge de travail ou des accords de niveau de service (SLAs) très différents, envisagez d'utiliser des points de terminaison personnalisés et des répliques de lecture dédiées pour diriger le trafic vers des instances optimisées pour ce trafic. L'optimisation peut inclure un dimensionnement différent de l'instance, des modèles de requête spécifiques ou le préchauffage du cache tampon.