Configuração de um roteador celular sem servidor para uma arquitetura baseada em células

Mian Tariq e Ioannis Lioupras, Amazon Web Services

Resumo

Como ponto de entrada para um sistema global de aplicações baseado em células, o roteador celular é responsável por atribuir eficientemente os usuários às células apropriadas e fornecer os endpoints aos usuários. O roteador celular executa funções como armazenar user-to-cell mapeamentos, monitorar a capacidade da célula e solicitar novas células quando necessário. É importante manter a funcionalidade do roteador celular durante possíveis interrupções.

A estrutura de design do roteador celular neste padrão se concentra na resiliência, escalabilidade e otimização geral da performance. O padrão usa roteamento estático, em que os clientes armazenam os endpoints no login inicial e se comunicam diretamente com as células. Esse desacoplamento aumenta a resiliência do sistema, ajudando a garantir a funcionalidade ininterrupta da aplicação baseado em células durante uma deficiência no roteador celular.

Esse padrão usa um AWS CloudFormation modelo para implantar a arquitetura. Para obter detalhes sobre o que o modelo implanta ou sobre como implantar a mesma configuração usando o Console de gerenciamento da AWS, consulte a seção Informações adicionais.

Pré-requisitos e limitações

Pré-requisitos

Versões do produto

Arquitetura

O diagrama a seguir mostra um design de alto nível do roteador celular.

O diagrama mostra o seguinte fluxo de trabalho:

Quando novas células são criadas, RoutingDB é atualizado com base na camada de provisionamento e implantação. No entanto, esse processo está além do escopo desse padrão. Para obter uma visão geral das premissas do projeto de arquitetura baseada em células e detalhes sobre o design do roteador celular usado neste padrão, consulte a seção Informações adicionais.

Ferramentas

Serviços da AWS

Outras ferramentas

Repositório de código

O código desse padrão está disponível no repositório GitHub Serverless-Cell-Router.

Práticas recomendadas

Para obter as melhores práticas ao criar arquiteturas baseadas em células, consulte a seguinte orientação do Well-Architected AWS :

Épicos

git clone https://github.com/aws-samples/Serverless-Cell-Router/

aws s3api create-bucket --bucket <bucket name> --region eu-central-1 --create-bucket-configuration LocationConstraint=eu-central-1

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

aws s3 cp mapper-scr.zip s3://<bucket name>
aws s3 cp dispatcher-scr.zip s3://<bucket name>
aws s3 cp scaler-scr.zip s3://<bucket name>
aws s3 cp validator-scr.zip s3://<bucket name>
aws s3 cp dynamodbDummyData-scr.zip s3://<bucket name>

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=<S3 bucket storing lambda zip files> \
ParameterKey=CognitoDomain,ParameterValue=<Cognito Domain Name> \
--region <enter your aws region id, e.g. "eu-central-1">

curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/cells

curl -X POST \
-H "Authorization: Bearer {User id_token}" \
https://xxxxxxxxx.execute-api.eu-central-1.amazonaws.com/Cell_Router_Development/mapper

Recursos relacionados

Referências

Vídeo

Physalia: arquitetura baseada em células para fornecer maior disponibilidade no Amazon EBS

https://www.youtube-nocookie.com/embed/6 Eu sei? RZMFic controles = 0

Mais informações

Instalações de design de arquitetura baseada em células

Embora este padrão se concentre no roteador celular, é importante entender todo o ambiente. O ambiente é estruturado em três camadas distintas:

Cada camada mantém a funcionalidade mesmo no caso de deficiências que afetem outras camadas. Contas da AWS serve como um limite de isolamento de falhas.

O diagrama a seguir mostra as camadas em alto nível. A camada celular e a camada de provisionamento e implantação estão fora do escopo deste padrão.

Para obter mais informações sobre a arquitetura baseada em células, consulte Reducing the Scope of Impact with Cell-Based Architecture: Cell routing.

Padrão de design de roteador celular

O roteador celular é um componente compartilhado entre as células. Para mitigar possíveis impactos, é importante que a camada de roteamento use um design simplista e escalável horizontalmente que seja o mais fino possível. Servindo como ponto de entrada do sistema, a camada de roteamento consiste somente nos componentes necessários para atribuir eficientemente os usuários às células apropriadas. Os componentes dessa camada não se envolvem no gerenciamento ou na criação de células.

Este padrão usa roteamento estático, o que significa que o cliente armazena em cache os endpoints no login inicial e, posteriormente, estabelece comunicação direta com a célula. Interações periódicas entre o cliente e o roteador celular são iniciadas para confirmar o status atual ou recuperar quaisquer atualizações. Esse desacoplamento intencional permite operações ininterruptas para os usuários existentes em caso de inatividade do roteador celular e fornece funcionalidade e resiliência contínuas dentro do sistema.

Neste padrão, o roteador celular oferece suporte às seguintes funcionalidades:

Para entender melhor o roteador celular de demonstração configurado pelo CloudFormation modelo, revise os seguintes componentes e etapas:

O pressuposto é que a camada de provisionamento e implantação já esteja estabelecida. Os detalhes de implementação estão além do escopo desse artefato.

Como esses componentes são configurados e configurados por um CloudFormation modelo, as etapas a seguir são apresentadas de forma descritiva e de alto nível. A suposição é que você tenha as AWS habilidades necessárias para concluir a instalação e a configuração.

1. Definir e configurar o grupo de usuários do Amazon Cognito

Faça login no e abra Console de gerenciamento da AWS o console do Amazon Cognito em. https://console.aws.amazon.com/cognito/ Defina e configure um grupo de usuários do Amazon Cognito chamado CellRouterPool, com integração de aplicações, interface de usuário hospedada e as permissões necessárias.

2. Definir e configurar a API do API Gateway para o roteador celular

Abra o console do API Gateway em https://console.aws.amazon.com/apigateway/. Defina e configure uma API chamada CellRouter, usando um autorizador do Amazon Cognito integrado ao grupo de usuários CellRouterPool do Amazon Cognito. Implemente os seguintes elementos:

3. Criar uma tabela do DynamoDB

Abra o console do DynamoDB https://console.aws.amazon.com/dynamodb/em e crie uma tabela padrão do DynamoDB chamada com a seguinte configuração: tbl_router

Na guia Índices, crie um índice secundário global chamado marketId-currentCapacity-index. A função do Lambda Scaler usará o índice para realizar pesquisas eficientes na célula com o menor número de usuários atribuídos.

Crie a estrutura da tabela com os seguintes atributos:

4. Criar e configurar uma fila SQS

Abra o console do Amazon SQS em https://console.aws.amazon.com/sqs/e crie uma fila SQS padrão chamada configurada com criptografia de chave do CellProvisioning Amazon SQS.

5. Implementar o orquestrador

Desenvolva um fluxo de trabalho do Step Functions para servir como Orchestrator para o roteador. O fluxo de trabalho pode ser chamado por meio da API do roteador celular. O fluxo de trabalho executa as funções do Lambda designadas com base no caminho do recurso. Integre a função step com a API do API Gateway para o roteador celular CellRouter e configure as permissões necessárias para invocar as funções do Lambda.

O diagrama mostra o fluxo de trabalho. O estado de escolha invoca uma das funções do Lambda. Se a função do Lambda for bem-sucedida, o fluxo de trabalho será encerrado. Se a função do Lambda falhar, o estado de falha será chamado.

6. Implementar as funções do Lambda

Implemente as funções Dispatcher, Mapper, Scaler e Validator. Ao configurar cada função na demonstração, defina uma função para a função e atribua as permissões necessárias para realizar as operações necessárias na tabela do DynamoDB tbl_router. Além disso, integre cada função ao fluxo de trabalho Orchestrator.

Função Dispatcher

A função Dispatcher é responsável por identificar e atribuir uma única célula estática para cada novo usuário cadastrado. Quando um novo usuário se registra na aplicação global, a solicitação vai para a função Dispatcher. A função processa a solicitação usando critérios de avaliação predefinidos, como os seguintes:

O Orchestrator invoca a função Dispatcher para atribuir usuários às células. Nessa função de demonstração, o valor de mercado é um parâmetro estático definido como europe.

A função Dispatcher avalia se uma célula já está atribuída ao usuário. Se a célula já estiver atribuída, a função Dispatcher retornará os endpoints da célula. Se nenhuma célula for atribuída ao usuário, a função pesquisará a célula com o menor número de usuários, a atribuirá ao usuário e retornará os endpoints. A eficiência da consulta de pesquisa celular é otimizada usando o índice secundário global.

Função Mapper

A Mapper função supervisiona o armazenamento e a manutenção dos user-to-cell mapeamentos no banco de dados. Uma única célula é alocada para cada usuário registrado. Cada célula tem duas células distintas URLs — uma para cada região da AWS. Servindo como endpoints de API hospedados no API Gateway, eles URLs funcionam como pontos de entrada para o aplicativo global.

Quando a Mapper função recebe uma solicitação do aplicativo cliente, ela executa uma consulta na tbl_router tabela do DynamoDB para recuperar user-to-cell o mapeamento associado ao ID de e-mail fornecido. Se encontrar uma célula atribuída, a Mapper função fornecerá imediatamente as duas URLs células. A Mapper função também monitora ativamente as alterações na célula URLs e inicia notificações ou atualizações nas configurações do usuário.

Função Scaler

A função Scaler gerencia a capacidade residual da célula. Para cada nova solicitação de registro de usuário, a função Scaler avalia a capacidade disponível da célula que a função Dispatcher atribuiu ao usuário. Se a célula tiver atingido seu limite predeterminado de acordo com os critérios de avaliação especificados, a função iniciará uma solicitação por meio de uma fila do Amazon SQS para a camada de provisionamento e implantação, solicitando o provisionamento e a implantação de novas células. O dimensionamento das células pode ser executado com base em um conjunto de critérios de avaliação, como os seguintes:

O código de demonstração Scaler é executado pelo Orchestrator depois que Dispatcher atribuir uma célula com sucesso ao usuário recém-registrado. Ao receber o ID da célula do Dispatcher, o Scaler avalia se a célula designada tem capacidade adequada para acomodar usuários adicionais, com base em critérios de avaliação predefinidos. Se a capacidade da célula for insuficiente, a função Scaler enviará uma mensagem para o serviço Amazon SQS. Essa mensagem é recuperada pelo serviço na camada de provisionamento e implantação, iniciando o provisionamento de uma nova célula.

Função Validador

A função Validator identifica e resolve problemas relacionados ao acesso à célula. Quando um usuário faz login no aplicativo global, o aplicativo recupera as células das configurações do perfil URLs do usuário e encaminha as solicitações do usuário para uma das duas regiões atribuídas dentro da célula. Se URLs estiverem inacessíveis, o aplicativo poderá enviar uma solicitação de URL de validação para o roteador celular. O roteador celular Orchestrator invoca o Validator. O Validator inicia o processo de validação. A validação pode incluir, entre outras verificações, o seguinte:

Concluindo, a função Validator fornece respostas às solicitações da aplicação do cliente, fornecendo o status de validação junto com todas as etapas de remediação necessárias.

O Validator projetado para aprimorar a experiência do usuário. Considere um cenário em que determinados usuários tenham dificuldade em acessar a aplicação global porque um incidente faz com que as células fiquem temporariamente indisponíveis. Em vez de apresentar erros genéricos, a função Validator pode fornecer etapas instrutivas de correção. Essas etapas talvez incluam as seguintes ações:

O código de demonstração da Validator função verifica se a célula fornecida pelo usuário URLs na solicitação corresponde aos registros armazenados na tbl_router tabela. A função Validator também verifica se as células estão íntegras.