Arquitetura e Escalabilidade com PHP: garantindo a disponibilidade de uma aplicação

PHP-FPM - Apresentação

Olá, estudante! Te desejo as boas-vinda à Alura. Meu nome é Vinicius Dias e serei seu instrutor neste curso sobre escalabilidade de aplicações PHP e arquitetura de sistemas!

Audiodescrição: Vinicius se descreve como um homem branco, de cabelos escuros e curtos. Usa bigode e cavanhaque e veste uma camisa azul escura com o escrito "PHP Rio", também em tons azuis. Está sentado em uma cadeira preta alcolchoada. Ao fundo, uma parede lisa sob iluminação roxa.

Se você trabalha como pessoa desenvolvedora PHP, este curso será de grande importância. Diferente do curso anterior, que é um dos pré-requisitos, este será um pouco mais específico para PHP, contendo menos conceitos gerais sobre arquitetura de sistemas e mais sobre PHP em si, junto de suas ferramentas e configurações. Como sempre, focaremos em arquitetura de sistemas e escalabilidade.

Iniciaremos entendendo mais sobre o PHP FPM (Fast Process Manager) e como configurá-lo para obter o melhor desempenho, já que vimos a relação entre desempenho e escalabilidade no curso anterior. Falaremos também sobre Swoole e, como estamos usando Laravel, vamos utilizar o Laravel Octane na prática. Além disso, discutiremos sobre o Symfony Runtime e como podemos usar o Swoole em qualquer aplicação PHP.

Em seguida, conversaremos sobre monitoramento. Vamos entender por que é necessária a monitoração de uma aplicação quando se trata de escalabilidade e veremos exemplos de ferramentas profissionais para essa tarefa. Neste ponto, mencionaremos o profiling.

Posteriormente, abordaremos uma prática muito importante, tanto para a economia de recursos quanto para a segurança de qualquer aplicação que aspira ser escalável: o Wait Limit.

Para concluir, falaremos um pouco sobre a documentação de todas as decisões tomadas. Abordaremos os diagramas, o modelo C4 e discutiremos sobre ADRs (Architecture Decision Records), que são os Documentos de Decisão sobre Arquitetura.

Há muito a se aprender neste curso. É importante que, para acompanhá-lo, você tenha assistido o curso inicial sobre escalabilidade e arquitetura de sistemas. Lá, definimos toda a base de arquitetura e escalabilidade e apresentamos a aplicação para este curso atual.

Caso haja alguma dúvida no decorrer do processo, temos um fórum para que você possa sanar duas dúvidas e ajudar outras pessoas. Além do nosso fórum, você pode participar do Discord da nossa comunidade, onde a interação é um pouco mais dinâmica.

Te espero você no próximo vídeo para entendermos o que é este PHP FPM e como podemos configurá-lo para extrair o máximo de desempenho possível!

PHP-FPM - Como o PHP funciona na web

Antes de prosseguirmos com qualquer configuração ou continuidade no aperfeiçoamento da nossa aplicação para torná-la mais eficiente e escalável, vamos entender brevemente como o PHP funciona na web.

Alguns conteúdos complementares serão disponibilizados na seção "Para Saber Mais", onde você poderá encontrar explicações mais detalhadas sobre o funcionamento do PHP na web.

Aqui, focaremos na funcionalidade do PHP FPM , que é o servidor de aplicação utilizado na maioria das aplicações atuais para executar o PHP no nosso servidor. FPM significa Fast Process Manager, ele é um gerenciador de processos que recebe a requisição utilizando o protocolo FastCGI. Assim, o NGINX encaminha essa requisição para o PHP FPM.

O PHP FPM tem um processo principal que gerencia outros processos. Esse processo principal cria vários outros pools de processos, ou seja, conjuntos de processos. Então, suponhamos que temos dois pools do PHP FPM e cada um desses pools pode lidar com várias requisições. Se estamos, por exemplo, recebendo quatro requisições, duas podem ser encarregadas ao primeiro pool e as outras duas ao segundo pool. Dessa maneira, esses dois processos separados do PHP FPM gerenciam várias requisições. Isso foi uma revolução quando lançado e hoje consideramos como um padrão.

Então, o PHP FPM terá esse número de processos, onde cada processo pode lidar com várias requisições. Podemos configurar toda essa operação, como determinar quantos processos o PHP FPM criará, com quantas requisições cada processo irá lidar e quantas requisições ele tratará antes do processo ser reiniciado.

Mas por que esse processo seria reiniciado? Nos primórdios do PHP, quando ainda não tínhamos o FastCGI, iniciávamos um processo, lidávamos com a requisição, e o processo era terminado. Naquela época, não nos preocupávamos com limpar recursos, fechar conexões, ou vazamento de memória. Portanto, reiniciar os processos do PHP FPM para lidar com esse problema antiquado é fundamental.

Hoje em dia, é menos comum ter vazamento de memória, principalmente usamos um framework. Atualmente, esses frameworks se preocupavam em limpar a memória e fechar recursos. Então, essa funcionalidade de reiniciar o processo do PHP FPM é mais útil com um código antigo que apresentava esses vazamentos de memória. Contudo, ainda é fundamental conhecermos essa funcionalidade, pois podem existir códigos que propositalmente causem vazamentos de memória.

O monolog é um exemplo sobre o qual teremos mais detalhes na seção "Para Saber Mais". Mas, no curso de Symfony, falamos sobre o monolog, que é uma ferramenta de log. Ele tem uma funcionalidade que armazena todos os logs de debug, informações, avisos, entre outros. Se ocorre um erro, ele envia todos esses logs, seja para um arquivo ou e-mail.

Por natureza, ele armazena muita informação e ocupa muita memória, então, nesses cenários específicos, é bom estarmos atentos. No entanto, em geral, nós não temos mais esses vazamentos de memória.

Podemos, ainda, configurar funções como reiniciar ou não o processo, o número de processos e a maneira como esses processos serão criados. Portanto, note que há muitas coisas que podemos configurar no PHP FPM.

Quando falamos de escalabilidade, é crucial que nosso servidor de aplicação esteja preparado para receber muitas requisições de forma performática.

Discutimos a relação entre desempenho e escalabilidade no curso anterior. Portanto, quando falamos de uma aplicação PHP, todas essas configurações de produção precisam ser executadas corretamente. Dessa forma, o objetivo dessa aula é analisar o PHP FPM e algumas configurações que podemos ajustar para preparar melhor nossa aplicação para cenários de grande escalabilidade.

Não seria possível fornecer todas as configurações aqui. Na próxima aula, faremos algumas configurações e entenderemos uma das mais importantes, senão a mais crucial. Evidentemente, forneceremos uma referência para que você possa ver todas as configurações existentes no PHP FPM.

Você não precisa memorizar todas as configurações. É mais significativo ler a documentação e ver o que faz sentido no seu contexto. Você pode optar, por exemplo, por ter um documento para consultar sempre que for colocar uma aplicação em produção. Não é necessário memorizar, mas é vital conhecer as opções de configuração.

Você provavelmente já entendeu o que é o PHP FPM: o servidor de aplicação. Cada pool de processos contém o PHP, que interpreta efetivamente o código. Então, vamos configurar esses pools de processos e ver como podemos tornar toda essa infraestrutura um pouco mais performática., sempre considerando a possibilidade de escalar nossa aplicação.

No próximo vídeo, vamos criar uma configuração efetiva para o PHP FPM. Até lá!

PHP-FPM - Configurando PHP-FPM

Vamos configurar o PHP FPM!

Com a aplicação em execução, após rodar o comando docker compose up, abrimos um segundo terminal e entramos no container app, que é um dos containers que roda o PHP FPM. Instalamos uma ferramenta usando o comando apk add htop.

Vamos executar htop para ver alguns detalhes.

Exemplo dos primeiros registros da visualização. Para acessá-la da íntegra, execute o comando na sua máquina.

A ferramenta HTOP mostra os processos em nosso sistema operacional. Como no container app temos apenas o PHP FPM rodando, é isso que será mostrado.

Os processos que estão aparecendo são o SH, que é o terminal que está sendo usando, e o PHP FPM. O PHPFPM tem um processo principal, o processo mestre, que lê nossas configurações e cria cada um dos pools (grupos de processos).

Em nossa configuração atual, temos dois processos de pool do PHP FPM. Conseguimos visualizar isso na tela com o HTOP. Na aba "Command" (comando), temos o processo principal e, como processos filhos, temos dois outros processos do PHP FPM.

Um detalhe muito importante é que, ao lado de "master process" nos é mostrado o caminho do arquivo de configuração. Dentro do container de instalação padrão do PHP, essa configuração fica dentro de "/usr/local/etc" e nesse diretório temos o arquivo "php-fpm.conf". Nesse arquivo, conseguimos fazer todas as configurações que são possíveis de verificar na documentação.

Consultando a documentação, na parte de configuração do PHP FPM, temos configurações globais, onde será armazenado o ID desse processo e onde serão salvos os logs.

Além disso, temos as configurações de cada pool. É possível ter vários grupos de pools diferentes. Em aplicações mais simples, que ficam em hospedagens compartilhadas, isso é bastante comum. Nesse caso, o mesmo servidor tem aplicações de várias pessoas desenvolvedoras, então é possível ter um grupo de pools para cada um dos usuários. No nosso caso, temos um pool apenas, mas há essas configurações nos pools separados. Então, conseguimos configurar de forma individual.

No gerenciador de processos, conseguimos ver que o nosso pool tem o nome "www", como se fosse o site principal. Se tivesse um subdomínio, usaria o nome desse subdomínio.

Recapitulando um pouco o conceito dos processos de PHP FPM, vamos efetivamente configurar.

Primeiro, vamos acessar a pasta "/usr/local/etc". Portanto, pressionamos "Q" para sair do HTOP e rodamos o comando cd /usr/local/etc.

cd /usr/local/etc

Em seguida, usamos o comando ls para listar as pastas e arquivos.

pear.conf php-fpm.conf php-fpm.d

php php-fpm.conf.default

Temos o arquivo php-fpm.conf e a pasta php-fpm.d. Esta pasta contém todos os arquivos que serão incluídos também como configuração do PHP FPM.

Vamos rodar um comando que você não precisa executar necessariamente, pode apenas acompanhar. É o cat php-fpm.conf que serve ler todo o arquivo de configuração. Junto, usaremos | grep -ve '^$' para excluir linhas vazias e | greg -ve '^;' para remover as linhas comentadas

cat php-fpm.conf | grep -ve '^$' | greg -ve '^;'

O php.conf usa o formato .ini, similar ao php.ini. Portanto, esse formato - o ponto e vírgula no início da linha - define que é um comentário. Dessa forma, estamos removendo todos os comentários e todas as linhas vazias.

[global]

include=etc/php-fpm.d/*.conf

Repare que só sobra uma instrução global que inclui tudo que estiver dentro da pasta php-fpm.d com a extensão .conf.

Todo esse processo foi para mostrar que os arquivos que podemos criar e modificar estão dentro desta pasta php-fpm.d.

Ao entrar nessa pasta com o comando cd php-fpm.d/ e executar um ls, já verificamos alguns arquivos.

cd php-fpm.d/

ls

docker.conf www.conf www.conf.default zz-docker.confer

Note que temos um docker.conf, que é uma configuração criada especificamente para a imagem do Docker do php-fpm, o que também acontece com zz-docker.conf.

No que consiste esse procedimento? Os arquivos são incluídos em ordem alfabética. Então, se temos uma configuração, por exemplo, de quantos processos teremos em um arquivo, e quantos processos teremos em outro, a última inclusão sobrepõe a configuração anterior.

Dentro desta pasta, vamos criar um arquivo de configuração com um nome que segue o padrão do Docker, como zz-fpm.conf, por exemplo.

Faremos isso no PHP Storm. Então, vamos abrir o projeto e dentro de infra criaremos um arquivo chamado fpm.ini. Como o formato é ini, utilizaremos isso apenas para o PHP Storm nos ajudar.

No docker-compose.yaml, vamos adicionar como volume ./infra/fpm.ini:, mapear isso para a pasta /usr/local/etc/php-fpm.d e chamar de zz-app.conf:

volumes:
    - ./:/app 
    - ./infra/prod.ini:/usr/local/etc/php/conf.d/prod.ini 
    - ./infra/fpm.ini:/usr/local/etc/php-fpm.d/zz-app.conf

Utilizamos "zz" simplesmente para fazer com que seja um dos últimos arquivos a ser incluído e tenha uma prioridade maior. Assim, nossas configurações vão sobrescrever as outras.

No lugar de "app" poderíamos ter qualquer nome, mas optamos por este apenas para simplificar. Adicionaremos esse volume nos dois contêineres, no "app" e no "app2", porque temos dois contêineres do PHP FPM.

Agora, vamos configurar nosso php.ini.

Para configurar algo específico de nosso pool, que se chama "www", vamos iniciar uma sessão no arquivo fpm.ini com [www]. Tudo que fizermos aqui dentro será configuração do nosso PHP FPM.

[www]

No próximo vídeo, entenderemos como funcionam os formatos de gerenciador de processos e as estratégias de gerenciamento de processos do PHP FPM.

Sobre o curso Arquitetura e Escalabilidade com PHP: garantindo a disponibilidade de uma aplicação

O curso Arquitetura e Escalabilidade com PHP: garantindo a disponibilidade de uma aplicação possui 124 minutos de vídeos, em um total de 43 atividades. Gostou? Conheça nossos outros cursos de PHP em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• PHP-FPM
• I/O não bloqueante
• Monitoramento
• Garantindo a disponibilidade
• Documentação