Elixir e Phoenix: lidando com milhões de conexões simultâneas

1. Introdução ao paradigma da concorrência em Elixir

1.1. A Máquina Virtual da Erlang (BEAM) e o modelo de atores

Elixir roda sobre a BEAM (Bogdan/Björn's Erlang Abstract Machine), uma máquina virtual projetada originalmente para sistemas de telecomunicações que exigiam disponibilidade de 99,999% (cinco noves). O modelo de atores da BEAM trata cada unidade de execução como um processo isolado que se comunica exclusivamente por troca de mensagens assíncronas. Diferentemente de threads tradicionais, esses processos não compartilham memória, eliminando a necessidade de locks e evitando race conditions.

# Exemplo de criação de processo leve em Elixir
pid = spawn(fn -> 
  receive do
    {:saudacao, nome} -> IO.puts("Olá, #{nome}!")
  end
end)

send(pid, {:saudacao, "Mundo"})
# Saída: Olá, Mundo!

1.2. Processos leves vs. threads do sistema operacional

Enquanto uma thread do sistema operacional consome cerca de 8 MB de memória, um processo Elixir consome aproximadamente 2-3 KB. Isso significa que uma máquina com 16 GB de RAM pode teoricamente hospedar mais de 5 milhões de processos Elixir simultâneos. A BEAM utiliza um scheduler preemptivo que distribui esses processos entre os núcleos da CPU de forma eficiente.

1.3. Imutabilidade e tolerância a falhas como base para escalabilidade

A imutabilidade dos dados em Elixir garante que nenhum processo possa corromper o estado de outro. Aliado ao "Let it crash" — filosofia de que falhas devem ser isoladas e tratadas por supervisores —, o sistema se recupera automaticamente sem intervenção manual.

2. Arquitetura do Phoenix Framework para alta concorrência

2.1. O pipeline de conexão: do roteador ao endpoint

Phoenix organiza as requisições em um pipeline de plugs (módulos que transformam a conexão). Cada requisição HTTP passa por etapas como parsing, autenticação e roteamento, tudo de forma assíncrona e não-bloqueante.

# Exemplo de pipeline no endpoint
defmodule MeuApp.Endpoint do
  use Phoenix.Endpoint, otp_app: :meu_app

  plug Plug.RequestId
  plug Plug.Telemetry, event_prefix: [:phoenix, :endpoint]
  plug Plug.Parsers,
    parsers: [:urlencoded, :multipart, :json],
    pass: ["*/*"]

  plug MeuApp.Router
end

2.2. Supervisão e árvores de supervisão (Supervision Trees)

As árvores de supervisão definem hierarquias de processos onde supervisores monitoram workers e os reiniciam em caso de falha. Essa arquitetura garante que erros em conexões individuais não derrubem todo o sistema.

# Exemplo de árvore de supervisão
defmodule MeuApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      MeuApp.Repo,
      MeuAppWeb.Endpoint,
      {MeuApp.ConnectionPool, pool_size: 1000}
    ]

    opts = [strategy: :one_for_one, name: MeuApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

2.3. Estratégias de pooling de conexões com o banco de dados

Para bancos de dados relacionais, Phoenix utiliza pools como DBConnection, que mantém um número fixo de conexões abertas. Para alta concorrência, recomenda-se usar filas assíncronas (como Broadway) para operações de escrita, evitando saturar o banco.

3. WebSockets e canais: o coração das conexões persistentes

3.1. Funcionamento interno dos Phoenix Channels

Phoenix Channels abstraem WebSockets em canais temáticos. Cada canal mantém um estado via GenServer e pode se inscrever em tópicos do PubSub interno. A troca de mensagens é otimizada para binários, reduzindo overhead.

# Exemplo de canal Phoenix
defmodule MeuApp.ChatChannel do
  use Phoenix.Channel

  def join("sala:" <> sala_id, _payload, socket) do
    {:ok, assign(socket, :sala_id, sala_id)}
  end

  def handle_in("nova_mensagem", %{"texto" => texto}, socket) do
    broadcast!(socket, "nova_mensagem", %{texto: texto, usuario: socket.assigns.usuario})
    {:noreply, socket}
  end
end

3.2. Gerenciamento de milhões de sockets com GenServer e PubSub

O PubSub do Phoenix utiliza um mecanismo distribuído baseado em PG (Process Groups) da Erlang. Cada nó mantém uma tabela local de tópicos, e mensagens são roteadas apenas para nós com assinantes relevantes. Para 2 milhões de conexões, recomenda-se particionar tópicos por região geográfica.

3.3. Broadcast eficiente e particionamento de tópicos

Para evitar sobrecarga, tópicos muito populares devem ser particionados. Por exemplo, em vez de um tópico "notificações", use "notificacoes:usuario_#{id}". O Phoenix PubSuporta broadcast assíncrono com backpressure configurável.

4. Técnicas de otimização de desempenho no BEAM

4.1. Ajuste de parâmetros da VM (schedulers, garbage collection)

A BEAM permite ajustar o número de schedulers (tipicamente igual ao número de núcleos) e configurar o garbage collection por processo. Para conexões de longa duração, aumente o +hm (heap minimum) para reduzir coletas frequentes.

# Configuração no arquivo de release
export ERL_AFLAGS="+sbwt none +sbwtdcpu none +sbwtdio none"
export ELIXIR_ERL_OPTIONS="+hm 4194304"

4.2. Uso de ETS (Erlang Term Storage) para cache concorrente

ETS permite armazenar dados em tabelas na memória com acesso concorrente de milhares de processos sem locks. É ideal para cache de sessões e configurações.

# Exemplo de ETS para cache
defmodule MeuApp.Cache do
  def start_link do
    :ets.new(:cache, [:set, :public, :named_table])
  end

  def put(key, value) do
    :ets.insert(:cache, {key, value})
  end

  def get(key) do
    case :ets.lookup(:cache, key) do
      [{^key, value}] -> value
      [] -> nil
    end
  end
end

4.3. Profiling com Observer e reconhecimento de bottlenecks

O Observer é uma ferramenta gráfica que acompanha a BEAM. Permite visualizar uso de memória por processo, contagem de mensagens em filas e tempo de CPU. Bottlenecks típicos incluem processos que acumulam mensagens não processadas (mailbox overload).

5. Estratégias de balanceamento de carga e distribuição

5.1. Distribuição de nós Elixir (node clustering) com libcluster

A biblioteca libcluster automatiza a descoberta e conexão entre nós Elixir. Suporta estratégias como DNS, Kubernetes e multicast. Uma vez clusterizados, os nós compartilham o PubSub e podem balancear carga automaticamente.

# Configuração de cluster com libcluster
config :libcluster,
  topologies: [
    k8s_example: [
      strategy: Cluster.Strategy.Kubernetes,
      config: [
        mode: :dns,
        kubernetes_node_basename: "meu-app"
      ]
    ]
  ]

5.2. Roteamento de conexões via proxies reversos (Nginx, HAProxy)

Nginx e HAProxy funcionam como terminadores TLS e balanceadores. Para WebSockets, configure timeouts longos e sticky sessions baseadas em IP ou cookie.

# Configuração Nginx para WebSocket
upstream phoenix_backend {
    server 10.0.0.1:4000;
    server 10.0.0.2:4000;
}

server {
    location /socket {
        proxy_pass http://phoenix_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 86400s;
    }
}

5.3. Sincronização de estado distribuído com Mnesia ou Redis

Mnesia é o banco de dados distribuído nativo da Erlang, ideal para dados que precisam ser replicados entre nós. Redis é uma alternativa popular para cache e PubSub externo, mas adiciona latência de rede.

6. Casos reais e métricas de escalabilidade

6.1. Estudo de caso: Phoenix no Discord e no Bleacher Report

O Discord utiliza Elixir para gerenciar milhões de conexões WebSocket simultâneas em seus servidores de voz e texto. O Bleacher Report, site de esportes com picos de 2 milhões de usuários durante eventos ao vivo, migrou para Phoenix e reduziu o uso de servidores em 80%.

6.2. Testes de carga: simulando 2 milhões de conexões simultâneas

Testes realizados pela comunidade mostram que um servidor Phoenix com 8 GB de RAM e 4 núcleos consegue manter 2 milhões de conexões WebSocket ociosas. Para conexões ativas (enviando mensagens a cada 5 segundos), o limite cai para aproximadamente 500 mil, dependendo da complexidade do processamento.

6.3. Monitoramento em produção: Telemetry e Prometheus

A biblioteca Telemetry permite instrumentar cada etapa do pipeline. Com o Prometheus, é possível criar dashboards que mostram métricas como número de conexões ativas, latência de broadcast e uso de memória por processo.

7. Armadilhas comuns e boas práticas

7.1. Vazamento de processos e memory leaks no BEAM

Processos que nunca recebem mensagens de término acumulam-se na memória. Sempre implemente timeouts em receive e monitore o número de processos ativos com Process.info(self(), :total_run_time).

# Exemplo de timeout em receive
receive do
  mensagem -> processar(mensagem)
after
  5000 -> {:error, :timeout}
end

7.2. Gerenciamento de backpressure em streams de dados

Para streams de dados (como arquivos grandes ou APIs externas), use Flow ou GenStage para controlar a taxa de processamento. Evite Enum.map em listas enormes — prefira Stream.map com buffer limitado.

7.3. Estratégias de graceful shutdown e reinicialização de conexões

Implemente handlers para SIGTERM que fechem conexões WebSocket de forma ordenada. Use o mecanismo de :shutdown do supervisor para dar tempo aos processos finalizarem operações pendentes.

8. Conclusão e próximos passos

8.1. Resumo das vantagens do ecossistema Elixir/Phoenix

A combinação da BEAM com Phoenix oferece uma plataforma madura para aplicações que exigem milhões de conexões simultâneas com baixa latência. A imutabilidade, tolerância a falhas e o modelo de atores tornam o sistema previsível e resiliente.

8.2. Recursos para aprofundamento

Para dominar o tema, estude a documentação oficial do Phoenix Channels, pratique com projetos como o Discord clone, e explore bibliotecas como Broadway para processamento de streams e libcluster para distribuição.

8.3. Integração com outras ferramentas da lista

Phoenix pode ser combinado com Node.js para microserviços, Python para machine learning, e Flutter para frontends móveis, formando um ecossistema completo e escalável.

Referências