Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configuration d'un routeur cellulaire sans serveur pour une architecture cellulaire
*Mian Tariq et Ioannis Lioupras, Amazon Web Services*
## Résumé
En tant que point d'entrée du système global d'une application cellulaire, le routeur cellulaire est chargé d'affecter efficacement les utilisateurs aux cellules appropriées et de fournir les points de terminaison aux utilisateurs. Le routeur cellulaire gère des fonctions telles que le stockage des user-to-cell mappages, la surveillance de la capacité des cellules et la demande de nouvelles cellules en cas de besoin. Il est important de maintenir le fonctionnement du routeur cellulaire en cas d'interruption potentielle.
Dans ce modèle, le cadre de conception des routeurs cellulaires met l'accent sur la résilience, l'évolutivité et l'optimisation des performances globales. Le modèle utilise un routage statique, dans lequel les clients mettent en cache les points de terminaison lors de la connexion initiale et communiquent directement avec les cellules. Ce découplage améliore la résilience du système en garantissant le fonctionnement ininterrompu de l'application cellulaire en cas de défaillance d'un routeur cellulaire.
Ce modèle utilise un AWS CloudFormation modèle pour déployer l'architecture. Pour plus de détails sur ce que le modèle déploie, ou pour déployer la même configuration à l'aide du AWS Management Console, consultez la section [Informations supplémentaires](#serverless-cell-router-architecture-additional).
**Important**
La démonstration, le code et le CloudFormation modèle présentés dans ce modèle sont uniquement destinés à des fins explicatives. Le matériel fourni est uniquement destiné à illustrer le modèle de conception et à faciliter la compréhension. La démo et le code ne sont pas prêts pour la production et ne doivent pas être utilisés pour des activités de production en direct. Toute tentative d'utilisation du code ou de la démo dans un environnement de production est fortement déconseillée et se fait à vos propres risques. Nous vous recommandons de consulter les professionnels appropriés et d'effectuer des tests approfondis avant d'implémenter ce modèle ou l'un de ses composants dans un environnement de production.
## Conditions préalables et limitations
**Conditions préalables**
+ Un compte Amazon Web Services (AWS) actif
+ La dernière version de [AWS Command Line Interface (AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html))
+ [Informations d'identification AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) avec les autorisations nécessaires pour créer la CloudFormation pile, AWS Lambda les fonctions et les ressources associées
**Versions du produit**
+ Python 3.12
## Architecture
Le schéma suivant montre une conception de haut niveau du routeur cellulaire.
Le diagramme décrit le flux de travail suivant :
1. L'utilisateur contacte Amazon API Gateway, qui sert de façade aux points de terminaison de l'API du routeur cellulaire.
1. Amazon Cognito gère l'authentification et l'autorisation.
1. Le AWS Step Functions flux de travail comprend les éléments suivants :
+ **Orchestrateur** ‒ `Orchestrator` Utilisations AWS Step Functions pour créer un flux de travail ou une machine à états. Le flux de travail est déclenché par l'API du routeur cellulaire. `Orchestrator`Exécute les fonctions Lambda en fonction du chemin de la ressource.
+ **Dispatcher** ‒ La fonction `Dispatcher` Lambda identifie et affecte une cellule statique par nouvel utilisateur enregistré. La fonction recherche la cellule comportant le moins d'utilisateurs, l'affecte à l'utilisateur et renvoie les points de terminaison.
+ **Mappeur** ‒ L'`Mapper`opération gère les user-to-cell mappages au sein de la `RoutingDB` base de données Amazon DynamoDB créée par le modèle. CloudFormation Lorsqu'elle est déclenchée, la `Mapper` fonction fournit aux utilisateurs déjà assignés leurs points de terminaison.
+ **Scaler** ‒ La `Scaler` fonction assure le suivi de l'occupation des cellules et de la capacité disponible. En cas de besoin, la `Scaler` fonction peut envoyer une demande via Amazon Simple Queue Service (Amazon SQS) à la couche Provision and Deploy pour demander de nouvelles cellules.
+ **Validateur** ‒ La `Validator` fonction valide les extrémités des cellules et détecte tout problème potentiel.
1. `RoutingDB`Stocke les informations et les attributs des cellules (points de terminaison de l'API Région AWS, état, métriques).
1. Lorsque la capacité disponible des cellules dépasse un seuil, le routeur cellulaire demande des services de provisionnement et de déploiement via Amazon SQS pour créer de nouvelles cellules.
Lorsque de nouvelles cellules sont créées, elles sont mises `RoutingDB` à jour à partir de la couche Provision and Deploy. Toutefois, ce processus dépasse le cadre de ce modèle. Pour un aperçu des prémisses de conception de l'architecture basée sur les cellules et des détails sur la conception du routeur cellulaire utilisée dans ce modèle, consultez la section [Informations supplémentaires](#serverless-cell-router-architecture-additional).
## Outils
**Services AWS**
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) vous aide à créer, publier, gérer, surveiller et sécuriser REST, HTTP, et ce, WebSocket APIs à n'importe quelle échelle.
+ [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)vous aide à configurer les AWS ressources, à les approvisionner rapidement et de manière cohérente, et à les gérer tout au long de leur cycle de vie à travers Comptes AWS et Régions AWS.
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html) fournit des fonctionnalités d'authentification, d'autorisation et de gestion des utilisateurs pour les applications Web et mobiles.
+ [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) est un service de base de données NoSQL entièrement géré, offrant des performances rapides, prévisibles et évolutives.
+ [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) est un service de calcul qui vous aide à exécuter du code sans avoir à allouer ni à gérer des serveurs. Il exécute votre code uniquement lorsque cela est nécessaire et évolue automatiquement, de sorte que vous ne payez que pour le temps de calcul que vous utilisez.
+ [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) est un service de stockage d'objets basé sur le cloud qui vous permet de stocker, de protéger et de récupérer n'importe quel volume de données.
+ [Amazon Simple Queue Service (Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)) fournit une file d'attente hébergée sécurisée, durable et disponible qui vous permet d'intégrer et de dissocier les systèmes et composants logiciels distribués.
+ [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)est un service d'orchestration sans serveur qui vous aide à combiner des fonctions Lambda et d'autres fonctions pour créer des applications critiques Services AWS pour l'entreprise.
**Autres outils**
+ [Python](https://www.python.org/) est un langage de programmation informatique polyvalent.
**Référentiel de code**
Le code de ce modèle est disponible dans le référentiel GitHub [Serverless-Cell-Router](https://github.com/aws-samples/Serverless-Cell-Router/).
## Bonnes pratiques
Pour connaître les meilleures pratiques en matière de création d'architectures basées sur des cellules, consultez le guide AWS Well-Architected suivant :
+ [Réduction de la portée de l'impact grâce à une architecture basée sur les cellules](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html)
+ [AWS Pilier de fiabilité du framework Well-Architected REL1 : 0-BP04 Utiliser des architectures de cloisons pour limiter la portée de l'impact](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_use_bulkhead.html)
## Épopées
### Préparation des fichiers source
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Clonez le référentiel d'exemples de code. | Pour cloner le Serverless-Cell-Router GitHub dépôt sur votre ordinateur, utilisez la commande suivante :git clone https://github.com/aws-samples/Serverless-Cell-Router/
| Developer |
| Configurez des informations d'identification AWS CLI temporaires. | Configurez le AWS CLI avec des informations d'identification pour votre Compte AWS. Cette procédure pas à pas utilise les informations d'identification temporaires fournies par la **ligne de commande ou l'option d'accès programmatique** d' AWS IAM Identity Center. Cela définit les variables`AWS_ACCESS_KEY_ID`,`AWS_SECRET_ACCESS_KEY`, et d'`AWS_SESSION_TOKEN` AWS environnement avec les informations d'identification appropriées à utiliser avec le AWS CLI. | Developer |
| Créez un compartiment S3. | Créez un compartiment S3 qui sera utilisé pour stocker et accéder aux fonctions Serverless-Cell-Router Lambda à déployer par le CloudFormation modèle. Pour créer le compartiment S3, utilisez la commande suivante : aws s3api create-bucket --bucket --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1
| Developer |
| Créez des fichiers .zip. | Créez un fichier .zip pour chaque fonction Lambda située dans [le](https://github.com/aws-samples/Serverless-Cell-Router/tree/main/Functions) répertoire Functions. Ces fichiers .zip seront utilisés pour déployer les fonctions Lambda. Sur un Mac, utilisez les `zip` commandes suivantes :zip -j mapper-scr.zip Functions/Mapper.py
zip -j dispatcher-scr.zip Functions/Dispatcher.py
zip -j scaler-scr.zip Functions/Scaler.py
zip -j cp validator-scr.zip Functions/Validator.py
zip -j dynamodbDummyData-scr.zip Functions/DynamodbDummyData.py
| Developer |
| Copiez les fichiers .zip dans le compartiment S3. | Pour copier tous les fichiers .zip de la fonction Lambda dans le compartiment S3, utilisez les commandes suivantes :aws s3 cp mapper-scr.zip s3://
aws s3 cp dispatcher-scr.zip s3://
aws s3 cp scaler-scr.zip s3://
aws s3 cp validator-scr.zip s3://
aws s3 cp dynamodbDummyData-scr.zip s3://
| Developer |
### Créez la CloudFormation pile
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Déployez le CloudFormation modèle. | Pour déployer le CloudFormation modèle, exécutez la AWS CLI commande suivante :aws cloudformation create-stack --stack-name serverless.cell-router \
--template-body file://Serverless-Cell-Router-Stack-v10.yaml \
--capabilities CAPABILITY_IAM \
--parameters ParameterKey=LambdaFunctionMapperS3KeyParameterSCR,ParameterValue=mapper-scr.zip \
ParameterKey=LambdaFunctionDispatcherS3KeyParameterSCR,ParameterValue=dispatcher-scr.zip \
ParameterKey=LambdaFunctionScalerS3KeyParameterSCR,ParameterValue=scaler-scr.zip \
ParameterKey=LambdaFunctionAddDynamoDBDummyItemsS3KeyParameterSCR,ParameterValue=dynamodbDummyData-scr.zip \
ParameterKey=LambdaFunctionsS3BucketParameterSCR,ParameterValue= \
ParameterKey=CognitoDomain,ParameterValue= \
--region
| Developer |
| Vérifiez les progrès. | Connectez-vous au AWS Management Console, ouvrez la CloudFormation console sur [https://console.aws.amazon.com/cloudformation/]()et vérifiez la progression du développement de la pile. Lorsque le statut est défini`CREATE_COMPLETE`, la pile a été déployée avec succès. | Developer |
### Évaluer et vérifier
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Attribuez des cellules à l'utilisateur. | Pour lancer le`Orchestrator`, exécutez la commande curl suivante :curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/cells
`Orchestrator`Déclenche l'exécution de la `Dispatcher` fonction. À son tour`Dispatcher`, il vérifie l'existence de l'utilisateur. Si l'utilisateur est trouvé, il `Dispatcher` renvoie l'ID de cellule et le point de terminaison associés URLs. Si l'utilisateur n'est pas trouvé, une cellule `Dispatcher` lui est attribuée et envoie l'identifiant de la cellule à la `Scaler` fonction pour évaluer la capacité résiduelle de la cellule attribuée.
La réponse de la `Scaler` fonction est la suivante :
`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | Developer |
| Récupérez les cellules des utilisateurs. | Pour exécuter la `Orchestrator` `Mapper` fonction, exécutez la commande suivante :curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/mapper
`Orchestrator`Recherche la cellule assignée à l'utilisateur et renvoie l'ID de la cellule ainsi URLs que la réponse suivante :
`"cellID : cell-0002 , endPoint_1 : https://xxxxx.execute-api.eu-north-1.amazonaws.com/ , endPoint_2 : https://xxxxxxx.execute-api.eu-central-1.amazonaws.com/"` | Developer |
### Nettoyage
| Sous-tâche | Description | Compétences requises |
| --- | --- | --- |
| Nettoyez les ressources. | Pour éviter d'encourir des frais supplémentaires sur votre compte, procédez comme suit :[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/patterns/serverless-cell-router-architecture.html) | Développeur d’applications |
## Ressources connexes
**Références**
+ [Stabilité statique avec les zones de disponibilité](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [Limites d'isolation des pannes AWS : stabilité statique](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html)
**Vidéo**
[Physalia : architecture basée sur les cellules pour améliorer la disponibilité sur Amazon EBS](https://www.youtube.com/watch?v=6IknqRZMFic)
[https://www.youtube-nocookie.com/embed/6 Tu sais ? RZMFic contrôles = 0](https://www.youtube-nocookie.com/embed/6IknqRZMFic?controls=0)
## Informations supplémentaires
**Locaux de conception d'une architecture basée sur les cellules**
Bien que ce modèle se concentre sur le routeur cellulaire, il est important de comprendre l'environnement dans son ensemble. L'environnement est structuré en trois couches distinctes :
+ La couche de routage, ou couche mince, qui contient le routeur cellulaire
+ La couche cellulaire, composée de différentes cellules
+ La couche de mise à disposition et de déploiement, qui approvisionne les cellules et déploie l'application
Chaque couche conserve ses fonctionnalités même en cas de détérioration affectant les autres couches. Comptes AWS servent de limite d'isolation des défauts.
Le schéma suivant montre les couches à un niveau élevé. La couche Cell et la couche Provision and Deploy ne sont pas concernées par ce modèle.
Pour plus d'informations sur l'architecture basée sur les cellules, voir [Réduction de la portée de l'impact grâce à l'architecture basée sur les cellules : routage des cellules](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/cell-routing.html).
**Modèle de conception du routeur cellulaire**
Le routeur cellulaire est un composant partagé entre les cellules. Pour atténuer les impacts potentiels, il est important que la couche de routage utilise une conception simpliste et évolutive horizontalement aussi fine que possible. En tant que point d'entrée du système, la couche de routage comprend uniquement les composants nécessaires pour affecter efficacement les utilisateurs aux cellules appropriées. Les composants de cette couche ne participent pas à la gestion ou à la création de cellules.
Ce modèle utilise un routage statique, ce qui signifie que le client met en cache les points de terminaison lors de la connexion initiale et établit ensuite une communication directe avec la cellule. Des interactions périodiques entre le client et le routeur cellulaire sont initiées pour confirmer l'état actuel ou récupérer des mises à jour. Ce découplage intentionnel permet aux utilisateurs existants de fonctionner sans interruption en cas d'indisponibilité du routeur cellulaire, tout en garantissant la continuité des fonctionnalités et de la résilience au sein du système.
Dans ce modèle, le routeur cellulaire prend en charge les fonctionnalités suivantes :
+ Extraction des données cellulaires de la base de données de cellules dans la couche Provision and Deploy et stockage ou mise à jour de la base de données locale.
+ Affectation d'une cellule à chaque nouvel utilisateur enregistré de l'application à l'aide de l'algorithme d'attribution de cellule.
+ user-to-cellsStockage du mappage dans la base de données locale.
+ Vérification de la capacité des cellules lors de l'affectation des utilisateurs et activation d'un événement pour le distributeur automatique dans la couche Provision and Deploy afin de créer des cellules.
+ Utilisation de l'algorithme des critères de création de cellules pour fournir cette fonctionnalité.
+ Répondre aux demandes des utilisateurs nouvellement enregistrés en fournissant URLs les cellules statiques. Ils URLs seront mis en cache sur le client avec une durée de vie (TTL).
+ Répondre aux demandes d'utilisateurs existantes concernant une URL non valide en fournissant une URL nouvelle ou mise à jour.
Pour mieux comprendre le routeur cellulaire de démonstration configuré par le CloudFormation modèle, passez en revue les composants et les étapes suivants :
1. Configurez et configurez le groupe d'utilisateurs Amazon Cognito.
1. Configurez et configurez l'API API Gateway pour le routeur cellulaire.
1. Créez une table DynamoDB.
1. Créez et configurez une file d'attente SQS.
1. Implémentez le`Orchestrator`.
1. Implémentez les fonctions Lambda :`Dispatcher`,,`Scaler`,`Mapper`. `Validator`
1. Évaluez et vérifiez.
Le présupposé est que la couche Provision and Deploy est déjà établie. Les détails de sa mise en œuvre dépassent le cadre de cet artefact.
Ces composants étant définis et configurés par un CloudFormation modèle, les étapes suivantes sont présentées de manière descriptive et détaillée. L'hypothèse est que vous possédez les AWS compétences requises pour effectuer l'installation et la configuration.
*1. Configuration et configuration du groupe d'utilisateurs Amazon Cognito*
Connectez-vous à la AWS Management Console console Amazon Cognito et ouvrez-la à l'adresse. [https://console.aws.amazon.com/cognito/]() Configurez et configurez un groupe d'utilisateurs Amazon Cognito nommé`CellRouterPool`, avec intégration d'applications, interface utilisateur hébergée et autorisations nécessaires.
*2. Installation et configuration de l'API API Gateway pour le routeur cellulaire*
Ouvrez la console API Gateway à l'adresse [https://console.aws.amazon.com/apigateway/](). Configurez et configurez une API nommée `CellRouter` à l'aide d'un autorisateur Amazon Cognito intégré au groupe d'utilisateurs Amazon Cognito. `CellRouterPool` Implémentez les éléments suivants :
+ `CellRouter`Ressources d'API, y compris `POST` les méthodes
+ Intégration au flux de travail Step Functions implémenté à l'étape 5
+ Autorisation via l'autorisateur Amazon Cognito
+ Mappages de demandes et de réponses d'intégration
+ Attribution des autorisations nécessaires
*3. Création d'une table DynamoDB*
Ouvrez la console DynamoDB [https://console.aws.amazon.com/dynamodb/]()à l'adresse et créez une table DynamoDB standard appelée avec la configuration suivante : `tbl_router`
+ **Clé de partition** ‒ `marketId`
+ **Clé de tri** ‒ `cellId`
+ **Mode capacité** ‒ Provisionné
+ **Point-in-time restauration (PITR) ‒ Désactivé**
Dans l'onglet **Indexes**, créez un index secondaire global appelé`marketId-currentCapacity-index`. La fonction `Scaler` Lambda utilisera l'index pour effectuer des recherches efficaces dans la cellule ayant le plus petit nombre d'utilisateurs assignés.
Créez la structure du tableau avec les attributs suivants :
+ `marketId`‒ L'Europe
+ `cellId`‒ cellule-0002
+ `currentCapacity`‒ 2
+ `endPoint_1`‒
+ `endPoint_2`‒
+ `IsHealthy`‒ Vrai
+ `maxCapacity`‒ 10
+ `regionCode_1` ‒ `eu-north-1`
+ `regionCode_2` ‒ `eu-central-1`
+ `userIds`‒
*4. Création et configuration d'une file d'attente SQS*
Ouvrez la console Amazon SQS à [https://console.aws.amazon.com/sqs/]()l'adresse et créez une file d'attente SQS standard appelée `CellProvisioning` configurée avec le chiffrement par clé **Amazon** SQS.
*5. Implémenter l'orchestrateur*
Développez un flux de travail Step Functions qui servira `Orchestrator` de fil au routeur. Le flux de travail est appelable via l'API du routeur cellulaire. Le flux de travail exécute les fonctions Lambda désignées en fonction du chemin de ressource. Intégrez la fonction step à l'API API Gateway du routeur `CellRouter` cellulaire et configurez les autorisations nécessaires pour appeler les fonctions Lambda.
Le schéma suivant montre le flux de travail. L'état du choix invoque l'une des fonctions Lambda. Si la fonction Lambda est réussie, le flux de travail se termine. Si la fonction Lambda échoue, l'état fail est appelé.
*6. Implémenter les fonctions Lambda*
`Dispatcher`Implémentez les `Validator` fonctions `Mapper``Scaler`,, et. Lorsque vous configurez et configurez chaque fonction dans la démonstration, définissez un rôle pour la fonction et attribuez les autorisations nécessaires pour effectuer les opérations requises sur la table DynamoDB`tbl_router`. Intégrez également chaque fonction dans le flux de travail`Orchestrator`.
*Fonction Dispatcher*
La `Dispatcher` fonction est chargée d'identifier et d'attribuer une seule cellule statique à chaque nouvel utilisateur enregistré. Lorsqu'un nouvel utilisateur s'enregistre auprès de l'application globale, la demande est envoyée à la `Dispatcher` fonction. La fonction traite la demande en utilisant des critères d'évaluation prédéfinis tels que les suivants :
1. **Région** ‒ Sélectionnez la cellule du marché où se trouve l'utilisateur. Par exemple, si l'utilisateur accède à l'application globale depuis l'Europe, sélectionnez une cellule qui utilise Régions AWS en Europe.
1. **Proximité ou latence** ‒ Sélectionnez la cellule la plus proche de l'utilisateur Par exemple, si l'utilisateur accède à l'application depuis les Pays-Bas, la fonction considère une cellule qui utilise Francfort et l'Irlande. La décision concernant la cellule la plus proche est basée sur des métriques telles que le temps de latence entre l'emplacement de l'utilisateur et les régions de la cellule. Pour cet exemple de modèle, les informations sont alimentées de manière statique à partir de la couche Provision and Deploy.
1. **Santé** ‒ La `Dispatcher` fonction vérifie si la cellule sélectionnée est saine en fonction de l'état de cellule indiqué (Healthy = vrai ou faux).
1. **Capacité** ‒ La distribution des utilisateurs est basée sur le *nombre minimal d'utilisateurs dans une logique de cellule*, de sorte que l'utilisateur est affecté à la cellule qui compte le moins d'utilisateurs.
**Note**
Ces critères sont présentés uniquement pour expliquer cet exemple de modèle. Pour une implémentation réelle d'un routeur cellulaire, vous pouvez définir des critères plus précis et utiliser des critères basés sur des cas.
`Orchestrator`Invoque la fonction Dispatcher pour affecter les utilisateurs aux cellules. Dans cette fonction de démonstration, la valeur de marché est un paramètre statique défini comme`europe`.
La `Dispatcher` fonction détermine si une cellule est déjà attribuée à l'utilisateur. Si la cellule est déjà affectée, la `Dispatcher` fonction renvoie les extrémités de la cellule. Si aucune cellule n'est attribuée à l'utilisateur, la fonction recherche la cellule qui compte le moins d'utilisateurs, l'affecte à l'utilisateur et renvoie les points de terminaison. L'efficacité de la requête de recherche de cellules est optimisée en utilisant l'index secondaire global.
*Fonction de mappage*
La `Mapper` fonction supervise le stockage et la maintenance des user-to-cell mappages dans la base de données. Une cellule singulière est attribuée à chaque utilisateur enregistré. Chaque cellule possède deux cellules distinctes URLs, une pour chaque région AWS. Servant de points de terminaison d'API hébergés sur API Gateway, URLs ils fonctionnent comme des points entrants vers l'application globale.
Lorsque la `Mapper` fonction reçoit une demande de l'application cliente, elle exécute une requête sur la `tbl_router` table DynamoDB pour récupérer user-to-cell le mappage associé à l'identifiant e-mail fourni. Si elle trouve une cellule assignée, la `Mapper` fonction fournit rapidement les deux cellules URLs. La `Mapper` fonction surveille également activement les modifications apportées à la cellule URLs et lance des notifications ou des mises à jour des paramètres utilisateur.
*Fonction Scaler*
La `Scaler` fonction gère la capacité résiduelle de la cellule. Pour chaque nouvelle demande d'enregistrement d'utilisateur, la `Scaler` fonction évalue la capacité disponible de la cellule que la `Dispatcher` fonction a attribuée à l'utilisateur. Si la cellule a atteint sa limite prédéterminée conformément aux critères d'évaluation spécifiés, la fonction lance une demande via une file d'attente Amazon SQS vers la couche Provision and Deploy, sollicitant le provisionnement et le déploiement de nouvelles cellules. La mise à l'échelle des cellules peut être exécutée en fonction d'un ensemble de critères d'évaluation tels que les suivants :
1. **Nombre maximum d'utilisateurs** ‒ Chaque cellule peut avoir un nombre maximum de 500 utilisateurs.
1. **Capacité tampon** ‒ La capacité tampon de chaque cellule est de 20 %, ce qui signifie que chaque cellule peut être affectée à 400 utilisateurs à tout moment. Les 20 % de capacité tampon restants sont réservés aux futurs cas d'utilisation et à la gestion de scénarios inattendus (par exemple, lorsque les services de création et de provisionnement de cellules ne sont pas disponibles).
1. **Création de cellules** ‒ Dès qu'une cellule existante atteint 70 % de sa capacité, une demande est déclenchée pour créer une cellule supplémentaire.
**Note**
Ces critères sont présentés uniquement pour expliquer cet exemple de modèle. Pour une implémentation réelle d'un routeur cellulaire, vous pouvez définir des critères plus précis et utiliser des critères basés sur des cas.
Le `Scaler` code de démonstration est exécuté `Orchestrator` après avoir attribué `Dispatcher` avec succès une cellule à l'utilisateur nouvellement enregistré. Sur réception de l'identifiant de cellule du`Dispatcher`, évalue si la cellule désignée a une capacité suffisante pour accueillir des utilisateurs supplémentaires, sur la base de critères d'évaluation prédéfinis. `Scaler` Si la capacité de la cellule est insuffisante, la `Scaler` fonction envoie un message au service Amazon SQS. Ce message est récupéré par le service dans la couche Provision and Deploy, ce qui lance le provisionnement d'une nouvelle cellule.
**Fonction de validation**
La `Validator` fonction identifie et résout les problèmes relatifs à l'accès aux cellules. Lorsqu'un utilisateur se connecte à l'application globale, l'application extrait les cellules des paramètres URLs du profil utilisateur et achemine les demandes des utilisateurs vers l'une des deux régions attribuées dans la cellule. S' URLs ils sont inaccessibles, l'application peut envoyer une demande d'URL de validation au routeur cellulaire. Le routeur cellulaire `Orchestrator` invoque le. `Validator` `Validator`Lance le processus de validation. La validation peut inclure, entre autres, les vérifications suivantes :
+ Référencement croisé entre la cellule URLs de la demande et la cellule URLs stockée dans la base de données pour identifier et traiter les mises à jour potentielles
+ Exécution d'un bilan de santé approfondi (par exemple, une `HTTP GET` demande adressée au point de terminaison de la cellule)
En conclusion, la `Validator` fonction fournit des réponses aux demandes des applications clientes, en fournissant le statut de validation ainsi que les étapes de correction requises.
`Validator`Il est conçu pour améliorer l'expérience utilisateur. Imaginons un scénario dans lequel certains utilisateurs rencontrent des difficultés pour accéder à l'application globale en raison d'un incident qui rend les cellules temporairement indisponibles. Au lieu de présenter des erreurs génériques, la `Validator` fonction peut fournir des étapes de correction instructives. Ces étapes peuvent inclure les actions suivantes :
+ Informez les utilisateurs de l'incident.
+ Indiquez le temps d'attente approximatif avant la disponibilité du service.
+ Indiquez le numéro de téléphone du service d'assistance pour obtenir des informations supplémentaires.
Le code de démonstration de la `Validator` fonction vérifie que la cellule fournie par l'utilisateur URLs dans la demande correspond aux enregistrements stockés dans la `tbl_router` table. La `Validator` fonction vérifie également si les cellules sont saines.