É possível executar mais de uma instância de um aplicativo? Lista de verificação de prontidão

O que a escalabilidade horizontal muda — e o que ela não resolve

Escalabilidade horizontal, neste contexto, significa executar mais de uma instância do aplicativo. Essa opção só deve ser considerada depois de verificar se o fornecedor documenta esse modelo para o aplicativo e a implantação em questão.

A documentação do produto, o comportamento dos fluxos de trabalho e os procedimentos operacionais precisam ser avaliados para o caso específico. As perguntas desta lista são pontos para confirmar com o fornecedor e validar em testes; não são requisitos universais para todos os aplicativos.

• Defina o motivo para considerar réplicas: uma necessidade de capacidade, um gargalo identificado ou um requisito de disponibilidade.
• Procure orientações oficiais que descrevam várias instâncias atendendo à mesma implantação.
• Compare as opções com base nas necessidades e nas arquiteturas documentadas para o aplicativo, sem presumir que uma topologia seja sempre melhor.

Verifique o suporte documentado do aplicativo a várias instâncias

Procure orientações que descrevam explicitamente várias réplicas do aplicativo atendendo a uma mesma implantação. Termos semelhantes podem significar configurações diferentes. Por exemplo, a página da Retool intitulada [“Multi-instance deployment”](https://docs.retool.com/self-hosted/self-managed/concepts/multi-instance-deployment) descreve vários ambientes em uma única instância; isso, por si só, não comprova suporte a réplicas.

Consulte a documentação oficial do aplicativo e do modelo de implantação que você utiliza. Registre as condições e limitações descritas. Se o assunto não estiver coberto ou a orientação for ambígua, peça esclarecimentos ao fornecedor ou aos mantenedores.

A [lista de verificação de prontidão para produção do Temporal auto-hospedado](https://docs.temporal.io/self-hosted-guide/production-checklist) aborda escalabilidade, métricas, testes de carga e versionamento de workflows. Ela serve como exemplo de orientação específica do Temporal, não como uma lista universal para outros aplicativos.

• A documentação diz que várias instâncias do aplicativo podem atender à mesma implantação?
• Quais pré-requisitos ou limitações são indicados para esse modelo?
• As instruções distinguem instâncias do aplicativo de workers ou ambientes separados?
• A orientação corresponde à versão e ao método de instalação que você utiliza?

Mapeie o estado e os dados envolvidos

Antes de testar réplicas, liste os dados e componentes que os fluxos de trabalho da sua equipe usam. Para cada item, procure instruções específicas do aplicativo sobre compartilhamento, armazenamento local ou acesso por outro serviço. Não presuma que um banco de dados compartilhado seja a única consideração.

Sessões, arquivos enviados, caches, conexões de banco de dados, configurações e segredos podem merecer perguntas próprias. As exigências variam conforme o aplicativo; confirme-as na documentação e, quando possível, em testes de um ambiente não produtivo.

Se o ambiente permitir, teste um fluxo de trabalho iniciado em uma instância e continuado por outra. Compare o resultado com o comportamento documentado, sem tratar um teste isolado como prova de compatibilidade geral.

• Sessões: pergunte se o fluxo de trabalho pode continuar quando solicitações chegam a instâncias diferentes.
• Arquivos enviados: confirme onde são armazenados e quais instâncias precisam acessá-los.
• Caches: procure orientações do aplicativo sobre uso e consistência.
• Conexões de banco de dados: verifique os parâmetros recomendados para a implantação planejada.
• Configuração e segredos: confirme como mantê-los compatíveis entre as instâncias e evite expor credenciais durante os testes.

Esclareça o comportamento de workers e tarefas agendadas

Identifique os processos que tratam trabalhos em fila, tarefas recorrentes ou outras atividades fora das solicitações de usuários. Consulte a documentação para descobrir se o aplicativo especifica como esses processos devem ser distribuídos ou executados em uma implantação com réplicas.

Não conclua que o comportamento de agendamento é adequado apenas porque o aplicativo inicia em várias instâncias. Em um ambiente de teste, use uma tarefa inofensiva e identificável para observar o resultado e compará-lo às instruções do fornecedor.

Se a documentação não explicar como coordenar workers ou tarefas agendadas nesse modelo, trate esse ponto como não esclarecido e peça orientação antes de decidir.

• Liste as tarefas agendadas e os processos em segundo plano habilitados na implantação.
• Confira quais instruções o fornecedor oferece sobre a execução desses processos.
• Em testes controlados, observe se o resultado corresponde ao esperado, inclusive após reiniciar uma instância.
• Registre os resultados usando dados de teste, não trabalho de produção.

Revise o roteamento e os sinais de disponibilidade

Se considerar várias instâncias, confirme qual configuração de roteamento o fornecedor documenta para o aplicativo. Pergunte também como identificar uma instância apta a receber solicitações e se há orientações para conexões que permanecem abertas por mais tempo.

Teste os fluxos de trabalho relevantes no modelo de implantação pretendido. Não tome o início do processo como evidência suficiente de que os usuários conseguirão completar suas tarefas.

A Airbip automatiza o roteamento e os certificados TLS por meio do Traefik e do Let’s Encrypt nas implantações gerenciadas de aplicativos. Essa capacidade de infraestrutura não confirma, por si só, que um aplicativo seja compatível com várias réplicas nem estabelece o comportamento de verificações de integridade ou conexões.

• Confirme como o tráfego deve ser encaminhado segundo a documentação do aplicativo e da plataforma.
• Procure um método de prontidão ou verificação de integridade documentado para o aplicativo.
• Teste os fluxos de trabalho importantes, incluindo conexões de longa duração se forem relevantes para o uso.
• Verifique o roteamento e o TLS para o domínio e o modelo de implantação planejados.

Planeje migrações e mudanças de versão

Consulte as instruções do aplicativo para entender como mudanças de esquema e versões devem ser gerenciadas. Verifique se a documentação especifica uma sequência de atualização, se versões diferentes podem coexistir temporariamente e como tratar uma reversão.

Não presuma que um método de atualização seja apropriado para todos os aplicativos. Quando possível, ensaie a sequência documentada em um ambiente de teste com dados representativos.

A lista de verificação de prontidão para produção do Temporal inclui versionamento de workflows. Esse ponto se refere às orientações do Temporal e não comprova que outro aplicativo use o mesmo modelo.

• Registre a sequência de atualização e migração indicada pelo fornecedor.
• Confirme se a documentação permite a coexistência temporária de versões diferentes.
• Verifique os procedimentos de reversão ou recuperação descritos para o aplicativo.
• Depois da implantação, confira se as instâncias estão com versões e configurações compatíveis, conforme as orientações oficiais.

Teste fluxos de trabalho representativos e recuperação

Planeje testes com fluxos de trabalho que representem o uso real da sua equipe, em vez de verificar apenas se as instâncias iniciam. Selecione as ações relevantes para o aplicativo e defina o resultado esperado com base na documentação.

Em um ambiente não produtivo, teste situações controladas, como reiniciar ou remover uma instância, se isso fizer parte do plano de validação. Observe o que ocorre e compare com as instruções do fornecedor. Evite testar falhas com dados de produção ou processos empresariais em andamento.

A lista do Temporal menciona métricas e testes de carga entre seus tópicos. Consulte recomendações específicas do aplicativo antes de decidir quais medições ou testes são adequados; um teste curto não comprova o comportamento em todas as condições.

• Teste um fluxo de trabalho representativo usando o roteamento planejado.
• Inclua envio e recuperação de arquivos se esses recursos fizerem parte do uso do aplicativo.
• Observe o resultado de trabalhos agendados ou em fila em testes controlados.
• Simule uma reinicialização em ambiente de teste e compare a recuperação com a documentação.
• Registre os resultados e peça esclarecimentos sobre comportamentos não especificados.

Escolha o modelo de implantação com base nos requisitos

A documentação e os testes do aplicativo devem orientar a decisão sobre réplicas. Se o suporte não estiver confirmado, não trate uma implantação com várias instâncias como compatível apenas porque é possível iniciar mais de uma instância.

Não há uma comparação universal entre réplicas, uma instância maior e outras arquiteturas. Avalie as opções à luz do requisito que motivou a mudança, do modelo documentado pelo fornecedor e dos resultados obtidos em testes. Se os requisitos não forem atendidos por um modelo documentado, peça orientação ao fornecedor ou aos mantenedores.

A Airbip oferece implantação gerenciada para um catálogo público de aplicativos empresariais, de publicação, análise, colaboração e IA, como cargas de trabalho Docker em servidores na nuvem da Airbip. O serviço inclui backups diários, semanais e mensais configuráveis, verificações de DNS, gerenciamento do ciclo de vida dos serviços e roteamento e TLS automatizados. Esses recursos podem ajudar nas operações de infraestrutura, mas não confirmam o suporte a réplicas de um aplicativo específico. Consulte o site da Airbip para os planos e termos atuais.

• Defina os requisitos de capacidade, disponibilidade e operação que a mudança precisa atender.
• Confirme qual modelo de implantação o fornecedor documenta para o aplicativo.
• Use resultados de testes relevantes para avaliar se esse modelo atende aos requisitos.
• Considere outra arquitetura ou peça orientação quando não houver suporte documentado para a opção pretendida.