Mise à l'échelle du service d'identité dans plusieurs régions

Question

Nous avons une base de données utilisateur qui est utilisée pour créer/mettre à jour des utilisateurs et pour les identifier (lire). Nous lisons plus souvent que nous écrivons. Ecrire dire environ 1 million/jour et lire environ 100+ millions. Nous pouvons séparer la lecture et l'écriture, mais AFAIK nous avons besoin d'une forte cohérence.

Si nous commençons à lire des réplicas en lecture, il sera finalement cohérent. Il pourrait y avoir des scénarios lorsque l'utilisateur a été créé mais n'est pas encore disponible dans la réplique en lecture. Ou, l'utilisateur a mis à jour certaines informations (nom) et ce changement n'est pas encore présent dans d'autres régions. Le fait de ne fournir qu'une seule région signifierait une plus grande latence pour les autres régions.

Nous utilisons actuellement RDBMS. Netflix's Active-Active blog était une bonne lecture. Mais ce serait un grand changement. Plus important encore, il faudrait changer d'état d'esprit de l'équipe/organisation. En outre, il faudrait beaucoup d'efforts pour bien faire les choses. Nous devons immédiatement mettre en place quelque chose, car les réponses lentes troublent l'entreprise. Ainsi, j'essaie d'explorer d'autres options qui peuvent nous donner le temps de penser à la mise en œuvre effective. Dans un premier temps, je prévois d'avoir un cache de premier niveau avec une faible TTL dans différentes régions. Cela réduira beaucoup de lectures. Cela serait à nouveau cohérent.

La deuxième étape pourrait être d'avoir une invalidation de cache en place. Cela pourrait réduire un peu les incohérences. Cela serait à nouveau cohérent.

• Quelles sont les autres options disponibles? Comment les entreprises comme Google, Facebook etc échelle?
• Je ne veux pas entrer dans sharding. Ou devrais-je? Nous avons auto-incréments.
• Est-ce que la cohérence éventuelle est vraiment une si grande douleur? J'ai l'expérience dans un scénario orienté lecture mais celui-ci est en lecture/écriture.

[EDIT] - Sur la base des commentaires/suggestions

Je parle ici de différentes régions AWS. Comme nous avons un système d'écriture unique (1 SGBDR), toutes les écritures viendront à une seule région. Mais pour implémenter des lectures multirégionales, même avec une réplication asynchrone via db ou custom (disons SNS + SQS ou Dynamodb), il peut y avoir un retard car les appels traversent les frontières de la région. Il pourrait y avoir des pannes dues à des problèmes de réseau qui peuvent à nouveau expliquer un retard supplémentaire (tentatives, etc.). Oui, la cohérence éventuelle aidera mais alors nous devrons tenir compte des problèmes énumérés ci-dessus. Nous pourrions devoir accepter peu d'incohérences et d'échecs. Peut être gérer les problèmes des clients via le support à certains moments. Je crois aussi que ces problèmes seront relativement moindres par rapport aux avantages et la plupart du temps, ces problèmes seront temporaires. Ce que j'essaie de découvrir, c'est une solution meilleure et plus simple, le cas échéant. Je pense que c'est un problème que beaucoup d'entre nous essaieraient de résoudre ou que beaucoup auraient déjà résolu. Ainsi, mieux vaut prendre des conseils et apprendre.

Merci d'avance !!!

Answer 1

Je pense que votre solution (avoir des réplicas en lecture dans les régions et avoir un cache en mémoire de premier niveau avec un faible ttl) est appropriée. Servir le client à partir de votre cache en mémoire. Si l'objet utilisateur n'est pas présent dans ce cache, récupérez-le dans read replica -> store in cache -> servez-le.Si l'utilisateur change de nom, Il suffit de mettre à jour votre cache en mémoire et de créer un événement asynchrone (probablement en envoyant un message JMS) pour mettre à jour la base de données maître.

Parce que vous servez d'un utilisateur en mémoire, vous verrez les informations mises à jour.

Notez que cette solution est parfaite parce que c'est pour IAM et non pour quelque chose comme des informations sur les produits, car l'utilisateur sera connecté à partir d'un seul emplacement à la fois.