E-mail para milhões
Francisco Freire @ffreire Gleicon Moraes @gleicon
Construir um sistema de e-mails escalável para milhões de acessos/ usuários.
Como era: Recebimento
•
QMAIL;•
Apenas 1 filtro (Externo);•
MX sem fila local;•
MX sem fila fallback;•
Erros de backend repassados para fora;•
Sem limites;•
Balanceamento por LVS;•
Servidores consultando DB sem cache;•
MTA sem alta disponibilidade;•
MTA sempre com filas de entrega;MX (Qmail) QMQP MTA (Qmail) Entrada SMTP DB Storage NFS MySQL
Como era: Leitura
•
QMAIL;•
Usuário acessa diretamente o backend;•
Sem Limitações;•
Acesso a banco sem cache;•
Falta de logs completos;•
Balanceamento por LVS;•
Sem SSL;•
Bugs e mais bugs;•
2 tipos de imap rodando;o Dovecot (143) o Courier (144) Backend (Qmail / Dovecot / Courier) Usuário Pop3 / Imap DB Storage NFS MySQL
Como era: Webmail
•
PERL;•
CGI;•
NFS; Webmail Usuário HTTP DB Storage NFS MySQLTeoria
•
POSTFIX;•
Diminuir a entrada de lixo;•
Não voltar erros para fora;•
Melhorar tracking de problemas;•
Alterações mínimas da estrutura;•
Diminuir carga no banco comCDB;
•
Implementação da fallback;•
Implementação de limitações;Prática
•
POSTFIX;•
Implementação rápida;•
Redução bruta da entrada de lixo;•
Problemas para entrega viaQMQP;
•
Demanda reprimida;•
Sobrecarga nos backends;•
10x consumo de banda•
Problemas com DNSMX (Postfix) QMQP MTA (Qmail) SMTP DB Storage NFS MySQL
Recebimento (MX)
Entrada CDB Fallback (Postfix) CacheRecebimento (MX)
● Muito cuidado com capacity, picos de recebimento, podem e irão acontecer.
● Fila fallback recebe o excedente.
Teoria
•
Acessar via IMAP;•
Utilizar PHP;•
Roundcube;•
Mod_php;•
Slaves de banco locais;•
Pool único;•
Independente de backend;Prática
•
Sobrecarga nos backends;•
Adaptação de usuários;•
Adaptação de capacity;•
Mudança cultural;•
Primeiros problemas globais;Webmail
•
Ganho de latência com database local;•
Ganho de eficiência com mod_php;•
Ganho de eficiência com acesso via IMAP;Webmail Usuário HTTP / HTTPS DB Storage NFS MySQL Backend (Qmail / Dovecot / Courier) IMAP DB MySQL (local) Replication
Teoria
•
Adicionar camada global;•
Evitar acesso direto ao backend;•
Fail2ban / Limites;•
Padronização;•
Dovecot apenas;•
Cache no acesso ao banco;•
Melhor balanceamento;•
SSL;Prática
•
Novos problemas globais;•
Adaptação de capacity;•
Aprendizado;•
Melhor utilização do banco;•
Maior estabilidade;•
Melhor administração;•
SSL;Leitura (Proxy)
Backend (Qmail / Dovecot / Courier) Usuário Pop3(s) / Imap(s) DB Storage NFS MySQL Frontend (Proxy) Cache Pop3 / ImapTeoria
•
Dovecot;•
Cache;•
Suporte ao mesmo formato(maildir);
•
Novos mailboxes = mdbox;•
Lmtp;•
Alta disponibilidade + director;Prática
•
Melhora considerável naestabilidade;
•
Migração dolorida (+cache);•
Melhor uso de storage;•
Maior disponibilidade;•
Menos filas;Novo ambiente
Backend (Dovecot) Storage NFS Recebimento Pop3 / Imap Webmail Imap Leitura Backend (Qmail / Dovecot / Courier) Storage NFS Recebimento Qmqp Webmail Leitura LmtpAcesso ao banco
Master Slave Cache Webmail Frontend Backend•
FreeBSD
•
Sem backup;
•
Sem HA;
•
Pouco espaço;
•
UFS + async;
•
Único dataset;
•
Arquivamento manual
com link simbólico;
Evolução de Storage (V1)
Produção 2TB /home{%d}/{%login} Archive 2TB /home{%d}/{%login} mv + ln -s•
OpenIndiana
•
ZFS;
•
Backup cruzado;
•
Sem HA;
•
Snapshot;
•
8 datasets;
•
Sem arquivamento;
•
ZFS send;
Evolução de Storage (V2)
Produção 7TB /storage/{%h}/{%h}/{%login}•
Isilon;
•
Backup cruzado;
•
HA;
•
Tiering;
•
Snapshot;
•
OneFS;
•
1 dataset;
•
Sem arquivamento;
Evolução de Storage (V3)
Produção +PB /storage/{%h}/{%h}/{%login}•
Red Hat AS 3 -> Debian squeeze (Wheezy)•
Qmail -> Postfix / Dovecot•
LVS nat -> LVS DR / F5 / Haproxy•
MySQL 4x -> Percona 5x•
Master/Slave -> Master/Slave/Cluster•
Provisionamento via raid -> Closed-loop / Cfengine•
Vdeliver -> Sieve•
Diversas linguagens -> Python•
Servidor de logs•
Métricas (+leela)Sem eles não seria possível...
Mailfromd (http://puszcza.gnu.org.ua/software/mailfromd/)
Postfix milter rápido e escalável o suficiente para aplicarmos regras de negócio como por exemplo: Análise de headers e conteúdo de mensagens.
Redis (http://redis.io/)
Key/Value database extremamente rápido, usamos e abusamos de "sorted sets". Todos os nossos contadores e muita informação de cache está nele. Único contra é usar apenas 1 core da máquina.
Twenproxy (Nutcracker) (https://github.com/twitter/twemproxy)
Proxy para redis/memcache. Com ele resolvemos o problema do redis usar apenas 1 core da máquina e utilizando shard conseguimos escalar o ambiente conforme necessidade.
Haproxy (http://haproxy.1wt.eu/)
De longe, o melhor proxy tcp que encontramos, utilizamos nele tanto o balanceamento de banco de dados quanto HTTP.
Python (https://www.python.org/)
Linguagem de programação que adotamos, fácil aprendizado e conseguimos utilizá-lo em diversos items da estrutura, policy, scripts, dashboard (django) e mais.
Estrutura:
Servidores (Físicos e Virtuais): 595 Storage utilizado: 2.5PB Domínios: 450K Mailboxes: 6M Destinations: 10M+
Números (10/04/2014)
MX:Mensagens recebidas: 160MMensagens recebidas (facebook): 7M
Conexões barradas: 450M Spam detectados: 54M
Frontend:
Total de autenticações: 260M
Média de usuários ativos (imap): 200k Média de usuários ativos (pop3): 20k
Webmail:
Relatórios de performance
•
Estatísticas por cluster;
•
Detecção de problemas;
•
~ 1MM mailboxes/sysadmin•
Sysadmins programando em Python e Go•
Ciclos rápidos de correção de elementos da arquitetura•
Rápida adaptação a outras plataformas e OSs•
Sysadmins originais -> Gerentes e lideres técnicos•
Logs e métricas em todo lugarAntes
"Há 5 anos atrás, até 15 minutos não era considerado atraso"
"Possuímos pessoas especializadas em olhar filas"
"Não era possível uma análise mais completa por falta de logs" "Tinhamos o equivalente a pelo menos 1 crise por dia"
"Estrema demora para o provisionamento de um novo servidor"
Hoje
"Se o email não chega em 5 minutos temos clientes reclamando" "Fila hoje possui a prioridade máxima de incidentes"
"Temos logs de tudo e os guardamos para sempre"
"Temos crises esporádias, com visibilidade a rápida atuação" "Simples provisionamento de novos servidores"
