Considerações sobre design

Opções de implantação

Se esta for a primeira instalação, ou se você não tiver certeza do que instalar, implante o CloudFormation modelo virtual-waiting-room-on-aws-getting-started.template aninhado, que instala o núcleo, os autorizadores e os modelos de amostra da sala de espera. Isso fornece uma sala de espera mínima com um fluxo simples.

Protocolos compatíveis

A AWS solução Virtual Waiting Room on pode ser integrada com o seguinte:

• Bibliotecas e ferramentas de verificação do JSON Web Token

• Implantações existentes do API Gateway

• Clientes da API REST

• Clientes e provedores OpenID

Estratégias de entrada na sala de espera

As estratégias de entrada encapsulam a lógica e os dados necessários para mover os clientes da sala de espera para o site. Uma estratégia de entrada pode ser implementada como uma função Lambda, contêiner, instância do Amazon EC2 ou qualquer outro recurso computacional. Ele não precisa ser um recurso de nuvem, desde que possa chamar as APIs públicas e privadas da sala de espera. A estratégia de entrada recebe eventos sobre a sala de espera, o site ou outros indicadores externos que a ajudam a decidir quando mais clientes podem emitir tokens e entrar no site. Existem várias abordagens para estratégias de entrada. Qual deles você adota depende dos recursos disponíveis para você e das restrições no design do site que está sendo protegido.

A principal ação tomada pela estratégia de entrada é chamar a API privada do increment_serving_num Amazon API Gateway com um valor relativo que indica quantos clientes a mais podem entrar no site. Esta seção descreve dois exemplos de estratégias de entrada. Eles podem ser usados como estão, personalizados ou você pode empregar uma abordagem completamente diferente.

MaxSize

Usando a MaxSize estratégia, a função MaxSizeInlet Lambda é configurada com o número máximo de clientes que podem usar o site simultaneamente. Esse é um valor fixo. Um cliente emite uma notificação do Amazon SNS que invoca a função MaxSizeInlet Lambda para aumentar o contador de atendimento com base na carga útil da mensagem. A origem da mensagem do SNS pode vir de qualquer lugar, incluindo o código no site ou uma ferramenta de monitoramento que observa o nível de utilização do site.

A função MaxSizeInlet Lambda espera receber uma mensagem que pode incluir:

• exited :número de transações que foram concluídas

• lista de IDs de solicitação a serem marcados como concluídos

• lista de IDs de solicitação a serem marcados como abandonados

Esses dados são usados para determinar quanto incrementar o contador de porções. Pode haver casos em que não haja capacidade adicional para incrementar o contador, com base no número atual de clientes.

Periódico

Ao usar a estratégia periódica, uma CloudWatch regra invoca a função PeriodicInlet Lambda a cada minuto para aumentar o contador de porções em uma quantidade fixa. A entrada periódica é parametrizada com a hora de início, a hora de término e o valor do incremento do evento. Opcionalmente, essa estratégia também verifica um CloudWatch alarme e, se o alarme estiver em OK estado, executa o incremento, caso contrário, o ignora. Os integradores do site podem conectar uma métrica de utilização a um alarme e usar esse alarme para pausar a entrada periódica. Essa estratégia só altera a posição de serviço enquanto a hora atual está entre os horários de início e término e, opcionalmente, o alarme especificado está no OK estado.

Personalizando e estendendo a solução

O administrador do site da sua organização deve decidir sobre os métodos de integração a serem usados com a sala de espera. Existem duas opções:

1. Integração básica diretamente usando APIs e autorizadores do API Gateway.

2. Integração com o OpenID por meio de um provedor de identidade.

Além da integração acima, talvez seja necessário configurar o redirecionamento do nome de domínio. Você também é responsável por implantar uma página personalizada do site da sala de espera.

A AWS solução Virtual Waiting Room on foi projetada para extensão por meio de dois mecanismos: EventBridge para notificação unidirecional de eventos e APIs REST para comunicação bidirecional.

Cotas

A principal limitação de escala para a Sala de Espera Virtual em AWS é o limite de aceleração do Lambda para a região instalada. AWS Quando instalada em uma AWS conta com a cota padrão de execução simultânea do Lambda, a AWS solução Virtual Waiting Room on pode lidar com até 500 clientes por segundo solicitando uma posição na fila. A taxa de 500 clientes por segundo é baseada na solução com todos os limites de cota simultâneos da função Lambda disponíveis exclusivamente. Se a região na conta for compartilhada com outras soluções que invocam funções Lambda, a sala de espera virtual AWS na solução deverá ter pelo menos 1.000 invocações simultâneas disponíveis. Você pode usar CloudWatch métricas para traçar as invocações simultâneas do Lambda em sua conta ao longo do tempo para fazer uma determinação. Você pode usar o console Service Quotas para solicitar aumentos. Aumentar o limite de aceleração do Lambda só aumenta as cobranças mensais da conta se invocações adicionais realmente ocorrerem.

Para cada 500 clientes adicionais por segundo, aumente seu limite de aceleração em 1.000.

Espera-se a entrada de usuários por segundo	Cota recomendada de execução simultânea
0-500	1.000 (padrão)
501-1.000	2.000
1.001-1.500	3.000

O Lambda tem um limite fixo de intermitência de 3.000 invocações simultâneas. Para obter mais informações, consulte Dimensionamento da função Lambda. O código do cliente deve esperar e repetir algumas chamadas de API se um código de erro for retornado indicando uma situação temporária de aceleração. O exemplo de cliente de sala de espera inclui esse código como um exemplo de como projetar clientes usados em eventos de alta capacidade e alta intensidade.

Essa solução também é compatível com a simultaneidade reservada e provisionada do Lambda com etapas de configuração personalizadas. Para obter detalhes, consulte Gerenciando a simultaneidade reservada do Lambda.

O limite superior de usuários que podem entrar na sala de espera, receber um token e continuar com uma transação é limitado pelo limite superior de quatro contadores do ElastiCache Redis. Os contadores são usados para a posição de atendimento da sala de espera e para rastrear o estado resumido da solução. Os contadores usados no Redis têm um limite superior de ElastiCache 9.223.372.036.854.775.807. Uma tabela do DynamoDB é usada para armazenar uma cópia de cada token emitido para um usuário da sala de espera. O DynamoDB não tem limite prático para o tamanho de uma tabela.

Implantações regionais

Os serviços usados por essa solução são compatíveis em todas as AWS regiões. Para obter a disponibilidade mais atual dos AWS serviços por região, consulte a Lista de serviços AWS regionais.