loader

Escalabilidade e Alta Disponibilidade no PHP com NGINX

Monolithic X Microservices

Uma aplicação monolithic é construída em uma única base de código com um número variável de módulos. O número de módulos depende da complexidade do negócio e de suas características técnicas, já a arquitetura de microservices ela foi projetada para acomodar a necessidade de grande desenvolvimento de aplicativos, fornecendo um conjunto de componentes e serviços modulares. Recomendamos o uso de microservices independente das linguagens utilizadas para aplicações de alta disponibilidade e escalabilidade.

Digrama

Esse diagrama foi criado pensando em um modelo de aplicacao que utiliza microservices e abaixo será apresentado
  1. O usuário vai fazer uma requisição de um domínio no seu navegador, o servidor DNS vai fazer uma ligação entre um domínio e um número de IP e com isso o usuário chega a nossa infraestrutura.
  2. O usuário vai fazer uma requisição de um domínio no seu navegador, o servidor DNS vai fazer uma ligação entre um domínio e um número de IP e com isso o usuário chega aos containers de nossa infraestrutura.
  3. Os nossos containers estao separados em, load balancer, aplicação e banco de dados

Na prática - inicio Cloudflare

Após fazer esse passo a passo, será necessário realizar os apontamentos, abaixo vamos apresentar um exemplo de apontamentos:

Abaixo será apresentado algumas funcionalidades que sugerimos que sejam ativadas:

  1. SSL / TLS / Visão geral -> Manter o SSL do tipo completo.
  2. SSL / TLS / Certificados de Borda -> Marcar sempre usar HTTPS.
  3. Speed / Otimização -> Minificação atumámatica manter ativado JavaScript, CSS e HTML. Ativar Brotli. Não ativar o Rocket Loader.
  4. Rede -> Ativar HTTP/3 (com QUIC), Ativar 0-RTT, WebSockets e Onion Routing.

Na prática - Balancer Aplicação


  1. Distribuir as requisições - O nginx verifica quais servidores de aplicações estao disponiveis e direciona as requisições somente para esses.
  2. Camada de SSL - Pode ser utilizado para instalar o ceritifcado SSL.
  3. Atctive Fall Over - Este recurso permite desativar um ou outro servidor de aplicação quando é feita a implementação.
  4. Stick Sessions - O nginx faz a replicação da sessão entre os servidores de aplicação.

Na prática - Criar ambiente

Clicando na opção “Novo Ambiente” na parte superior do painel será apresentando uma janela para a configuração do ambiente, o primeiro ícone do painel seria o servidor de balancer logo abaixo dele o servidor de aplicação. escalando o servidor de aplicação horizontalmente, o painel irá acrescentar uma instancia do balancer automaticamente, como na imagem abaixo
Também é possível fazer a escala horizontal no balancer, caso algum servidor de balancer cair o outro processaria as requisições automaticamente
Os ip publico devem ser adicionado aos servidores de balancer pois é o mesmo que vai receber as requisições, o apontamento deve ser feito para ambos ips.
Os ip publico devem ser adicionado aos servidores de balancer pois é o mesmo que vai receber as requisições, o apontamento deve ser feito para ambos ips.

Na prática - Instalar SSL

Clicando sobre a opção “Add-ons” no balancer, será apresentado uma janela para a instalação do certificado, como na imagem abaixo.
Para realizar a instalação siga os passos a baixo:
  1. Coloque todos os domínios e subdomínios que farão parte do projeto, separados por virgula
  2. Clique no botão “Instalar”

Na prática - Arquivos Balancer

O balancer já vem configurado e otimizado sem necessidade de alterações, não recomendamos alterar nenhuma configuração se caso não possuir conhecimentos avançados, abaixo será apresentando os principais arquivos de configurações
  • /etc/nginx/nginx.conf – Algumas opções globais como numeros de processos
  • /etc/nginx/nginx-jelastic.conf – Regras de apontamentos para a porta 80
  • /etc/nginx/conf.d/ssl.conf – Regras de apontamento para a porta 443
É possivel acessar o diretorio de arquivos clicando na opção “Configurações” conforme a imagem abaixo:

Na prática - Performance Web

Abaixo será apresentado os principais arquivos de configuração para o servidor web nginx:
  • /etc/nginx/nginx.conf – Revisarconfigurações globais do NGINX WEB
  • /etc/nginx/conf.d/seudominio.com.br.conf – Revisar configurações especificas do Domínio
  • /etc/php.ini e /etc/php-fpm.conf – revisar configurações especificas do PHP

Na prática - Nginx.conf

Abaixo será apresentado as principais variaveis do arquivo /etc/nginx/nginx.conf e as configurações que recomendamos
  • work_connections 5000 – Essa variável é responsável para atribuir o numero de requisições para o servidor web
  • work_rlimit_nofile 12000 – Essa variável é responsável pelo numero de arquivos que podem estar abertos no sistema operacional
  • gzip_static on – GZIP é um recurso que já vem habilitado nos nossos ambientes, ele é responsável por compactar os arquivos da aplicação
  • sendfile on
  • multi_accept on
  • ese epoli
  • keepalive – Já vem habilitado habilitado nos nossos ambientes
  • Desabilitar os logs se caso desejar, comentando as linhas acess_log e error_log

Na prática - seudominio.com.br.conf

Abaixo sera apresentado as configurações do virtual host do dominio seudominio.com.br
  • Caso a aplicação for wordpress será necessário adicionar essa linha para funcionar o sistema de rotas: try_files $uri $uri/ /index.php?$args
  • Cache de domínio (usar com cuidado), se desejar ter cache(no exemplo abaixo, de 30 dias, nessas extensões de arquivo), adicionar a linha): location~*\.(?:ico|css|js|json|gif|jpe?g|png|woff2)$ {espires 7d;}
  • Para wordpress, por segurança, adicionar essas linhas baixo da linha server_name:
    location = /xmlrpc.php{
    deny all;
    acess_log off;
    log_not_found off;
    return 444; }

Na prática - php.ini e php-fpm.conf

No arquivo /etc/php.ini recomendamos manter as configurações que já estão otimizadas, se desejar apenas ajudar o uso de memoria na variável memory_limit.

No arquivo /etc/php-fpm.conf que é responsável por executar as requisições do php, recomendamos as configurações abaixo:
  • Conceitos do pm = static, dynamic e ondemand (Essa variável e responsável por definir a forma que será executado o php, para a nossa plataforma recomendamos a dynamic)
  • pm.max_children = 2 (Essa variável é responsável pela quantidade de processos php serão executados simultaneamente, sugerimos utilizar 1 por core, no comando ssh /proc/cpuinfo é apresentado quantos cores o servidor possui)
  • pm.process_idle_timeout = 10s (Essa variável é definida como padrão, recomendamos não alterar ela)
  • om.max_requests = 5000 (Essa variável é definida como padrão, recomendamos não alterar ela)

Extra - Restart sem downtime

Após a alteração de alguma variavel de configuração do serviço, normalmente é necessário reiniciar o container, com o restart sequencial, é possivel realizar esse procedimento com um intervalo de tempo, garatindo assim a disponibilidade do serviço, basta definir o tempo de atraso entre as reinicializações e clicar em “reinicio sequencial(um por um) com atraso”.


Extra - Deploy sem downtime

Na nossa plataforma tambem é possivel fazer o deploy da aplicação com zero downtime, desta forma os arquivos de projeto atualizados podem ser implantados perfeitamente, enquanto a versão de código inicial continua trabalhando e gerenciando as sessões dos usuários, basta clicar em “Habilitar Implantação de tempo de inatividade zero”.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Open chat