Bonjour, tout le monde, et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons aborder les bases du proxy de Rrd.
Avant de comprendre ce sujet plus en détail, il est important que nous comprenions d'abord les
principes de base et les avantages du proxy de base de données.
Tout d'abord, discutons des bases du proxy de base de données à un haut niveau.
Le proxy de base de données est un intermédiaire entre un utilisateur et la base de données, comme le montre ce
diagramme où le proxy agit comme un intermédiaire entre le client et la base de données.
L'un des avantages de cette approche est que, puisque toutes les requêtes du client passent par ce
proxy spécifique, de nombreux contrôles et optimisations peuvent être appliqués au niveau du proxy.
Par exemple, disons que vous voulez bloquer un type spécifique de demande.
C'est quelque chose que vous pouvez faire au niveau du proxy lui-même.
Ainsi, si une telle demande est reçue d'un client, à chaque fois qu'elle est directement bloquée au niveau d'un proxy, la demande ne
va jamais à la base de données et il y a donc beaucoup de contrôles et d'optimisations que vous pouvez appliquer dans une
telle architecture.
Afin de mieux comprendre les choses, prenons un cas d'utilisation simple associé à un scénario de basculement.
Ainsi, dans ce diagramme spécifique, vous avez une seule base de données et toutes les connexions à la base de données
passent par le proxy.
Maintenant, pour une raison quelconque, disons que cette base de données primaire échoue dans de tels cas.
Si une base de données de secours est disponible, le proxy peut rediriger la demande vers l'instance
de la base de données de secours.
Très bien.
Ici, le client n'a pas vraiment besoin de s'inquiéter de l'adresse IP de l'instance de la base de données de secours, car si l'instance
primaire change, l'adresse IP de la base de données changera également ou l'URL de la base de données changera
également.
Mais puisque le client se connecte au proxy, le proxy se charge de rediriger la demande, ainsi que la
demande existante qui était arrivée au proxy et qui était censée aller à la base de données primaire.
Comme la base de données primaire a échoué, le proxy peut rediriger ces demandes vers la base de données de secours.
Ces demandes n'échoueront pas, ce qui améliorera également la résilience globale de l'application.
Sinon, si le client communique directement avec la base de données primaire et que celle-ci tombe en panne,
c'est toute l'application qui s'arrête, ce qui n'est pas recommandé en production.
Maintenant, pour comprendre le proxy SIDA, il est important que nous comprenions les bases de
la connexion à la base de données.
Par exemple, lorsqu'un client envoie une requête à une base de données, disons qu'il envoie une requête d'écriture dans laquelle
il veut écrire une donnée spécifique dans la base de données.
Donc, en coulisses, même si une petite donnée est écrite dans la base de données, il y a beaucoup d'étapes
qui se déroulent en coulisses.
L'une des premières étapes est donc que l'application utilise le pilote de la base de données pour ouvrir la connexion
à la base de données.
Voici donc la première partie.
Deuxièmement, le socket réseau est ouvert au niveau du système d'exploitation pour connecter l'application à la
base de données.
Ensuite, il y a aussi l'authentification qui a lieu.
Vous avez également des données qui sont écrites une fois que l'authentification est terminée et une fois que l'opération,
quelle que soit l'opération de la base de données, est terminée, la connexion peut être fermée du côté de l'application, puis
le socket réseau est fermé.
Nous pouvons donc comprendre que, même si un client veut lire ou écrire une petite quantité de
données dans les coulisses, beaucoup de choses se passent.
Et cela se traduit par un coût en termes de CPU et de mémoire.
S'il y a une seule demande, cela n'a pas vraiment d'impact, mais disons qu'il y a des millions de demandes, des millions
d'utilisateurs qui visitent le site Web, des millions de demandes qui vont vers la base
de données.
Ensuite, le maintien de la connexion à la base de données est quelque chose qui augmentera la charge de manière significative.
Pour pallier ce problème, il existe un concept appelé pooling de connexion.
La mise en commun des connexions de base de données est donc un moyen de réduire le coût de l'ouverture et de la fermeture de la connexion
en maintenant un pool de connexions ouvertes.
Donc ce qui se passe ici, c'est que vous avez le proxy pour un exemple entre un proxy et une base de données.
Il y a une connexion ouverte qui est déjà établie.
Ainsi, lorsque le client envoie la demande au proxy, puisque les connexions sont déjà présentes, le
proxy utilisera la connexion existante pour effectuer l'opération demandée par le
client.
Ainsi, un certain ensemble ou un certain pool de connexions ouvertes est maintenu par le proxy, ce qui
réduit le coût en termes de CPU et de mémoire.
Très bien.
J'espère donc qu'avec ceci vous avez compris certains des avantages qu'un proxy de base de données peut fournir.
Et de la même manière, lorsque nous parlons d'annonces, nous disposons d'une fonctionnalité appelée RDF Proxy.
Ainsi, à un haut niveau, le proxy Ideas est un proxy de base de données entièrement géré pour les idées Amazon dont nous discutons.
Comme pour les idées de proxy de base de données, le proxy offre également de nombreux avantages comme la mise en commun des connexions.
Nous avons discuté de la disponibilité en cas de défaillance de la base de données primaire, le proxy peut alors se connecter automatiquement
à l'instance de secours et les connexions ne sont pas interrompues.
Et vous avez également l'avantage de l'authentification où, au niveau du proxy, vous pouvez appliquer l'authentification IAM pour la base de données, vous n'avez
pas vraiment besoin de spécifier les informations d'identification de la base de données.
Toutes ces mesures peuvent donc être appliquées au niveau du proxy.
Alors faisons une chose.
Allons-y et faisons une démonstration rapide.
Maintenant, pour la démonstration d'aujourd'hui, j'ai une instance de base de données qui est disponible.
Ouvrons rapidement ce dossier.
C'est le point d'arrivée de la base de données.
Allons-y et connectons nous rapidement depuis l'ALC.
Allons-y et connectons nous rapidement au point de terminaison de la base de données.
Je vais spécifier le nom d'utilisateur admin et le mot de passe comme prévu.
Vous voyez, nous sommes connectés et si vous faites quelque chose comme montrer les bases de données, nous sommes en mesure de voir la liste de
la grille de la base de données.
Alors allons-y et sortons.
À ce stade, nous avons pris un exemple où le client communique directement avec la base de données.
Prenons maintenant un exemple de proxy de Rrd, où le client se connectera à la base de données
via un proxy de Rrd.
Maintenant, depuis la console IDS, j'ai déjà le proxy configuré.
Laissez-moi vous montrer rapidement.
Il y a donc un proxy qui est configuré.
Maintenant, si nous regardons ici, il y a un point de terminaison de proxy.
C'est donc le point final auquel le client doit se connecter.
En général, une fois que le proxy est disponible, il faut configurer le client de façon à ce qu'il envoie
les demandes uniquement au proxy et non à la base de données.
Et cela peut également être mis en œuvre en utilisant le groupe de sécurité, si vous le souhaitez.
Et à l'intérieur de vous, vous voyez que vous avez le groupe cible et le groupe cible ici est la base de données 1.
Donc la base de données associée est la base de données 1, qui n'est rien d'autre que cette base de données spécifique.
Donc le proxy est connecté à la base de données.
Maintenant, allons-y et envoyons la requête au point de terminaison du proxy.
Donc depuis mon CLA, essayons de nous connecter au proxy.
Spécifions le mot de passe.
Et vous voyez, nous sommes connectés à la base de données.
Si vous faites à nouveau une démonstration des bases de données, vous verrez la même liste de bases de données qui sont disponibles
maintenant, puisque vous avez le proxy des ID en place.
Diverses choses comme la mise en commun des connexions et autres sont automatiquement prises en charge par le proxy.
En plus de cela, il y a d'autres choses que vous pouvez également faire respecter.
Permettez-moi de vous donner rapidement un exemple.
Donc ici, dans l'authentification IAM, vous pouvez spécifier si c'est nécessaire ou non.
Parfois, comme dans ce cas, nous avons fourni manuellement l'administrateur, l'utilisateur et le mot
de passe.
Disons que vous ne voulez pas vraiment ou que vous ne voulez pas du tout permettre cela.
Il s'agit donc d'une mesure qui peut être appliquée au niveau des mandataires.
Ainsi, si vous le sélectionnez comme requis, cela signifie qu'il faut autoriser uniquement l'authentification IM, les informations d'identification de la base de données
ne peuvent pas être utilisées, donc toutes ces choses peuvent être configurées.
Vous pouvez également configurer le TLS au cas où si vous le souhaitez.
Super.
J'espère donc qu'avec cette vue d'ensemble de haut niveau, vous avez compris les bases de ce que notre mandataire nous permet
de faire, et c'est ainsi que se termine la vidéo d'aujourd'hui.