O documento discute a integração de sistemas para publicação de vídeos no site Globo.com utilizando arquitetura baseada em microsserviços e comunicação REST. O fluxo de publicação é dividido em etapas independentes executadas por deamons e a integração é feita através de uma API REST centralizada que gerencia o estado de cada vídeo. A arquitetura proposta permite escalabilidade, alta disponibilidade e recuperação mais fácil em caso de falhas.

1. INTEGRAÇÃO DE SISTEMAS
CASE: GLOBO.COM
Utilizando software livre
@pac_man
Hack ‘n Rio 2011

2. QUEM SOU EU?
• Tiago Peczenyj (@pac_man)
• Desenvolvedor da globo.com
• Distribuição de Videos/Webmedia
• Apaixonado por Open Source
• Blog pacman.blog.br

3. OPEN SOURCE NA
GLOBO.COM
• php, perl, python (Django, Tornado), ruby (Rails, Sinatra),
• apache, nginx, mysql, memcached, jQuery, CentOS...
• ffmpeg, mencoder, ImageMagick

4. INTEGRAÇÃO DE SISTEMAS
• File Transfer
• Shared Database
• Remote Procedure Invocation
• Messaging

5. CASE: PUBLICAÇÃO VIDEOS
• Eisque eu preciso pegar um video bruto e publicar na
internet...

6. PUBLICAÇÃO DE VIDEOS
• E(f) - encodar o video no(s) formato(s) especificos
•M - inserir meta-dados do video no(s) sistema(s)
•D - disponibilizar video adequadamente

7. RESUMO
• E(f) -> M -> D

8. THUMBNAILS?
• E(f) -> T -> M -> D

9. DISPONIBILIZAR: FTP E
SINALIZAR QUE ESTA OK
• E(f) -> T -> M -> F -> S

10. DEFINIR OS FORMATOS
• D-> E(f) -> T -> M -> F -> S

11. E TAMBÉM
• Publicar em um tempo X (SLA)
• Resistir à catástrofes (rede, banco, disco)
• Utilizar bem meus recursos

12. COMOFAS/
• Com um sistema apenas posso fazer tudo isso.
•N vídeos, N instâncias do sistema simultaneamente.
• Monolítico

13. MAS E O SLA?
• Se
tiver que produzir varios formatos, vou demorar se esperar
um formato ficar pronto para produzir o próximo

14. RESISTIR À CATÁSTROFE
• Sealguma das etapas falhar, precisarei seguir alguma protocolo
de acordo com a natureza da falha.
• Seprecisar retentar enquanto a falha persiste (ex: rede) pode
ficar complexo o tratamento disso.
• Devo evitar estados inconsistentes e voltar a funcionar OK

15. UTILIZAÇÃO DE RECURSOS
• Linguagens interpretadas podem apresentar GIL
• Maquinas atuais possuem CPU com varios cores
• Precisoainda de redundância para garantir alta
disponibilidade, meus gastos podem facilmente sair o dobro
do esperado.
• Cores de CPU ociosas são prejuizo

16. SOLUÇÃO
• Perl
• FFmpeg
• PHP
• MySQL

17. CONCEITOS

18. PROCESSOS
• Possoter varios processos na mesma maquina trabalhando de
forma cooperativa
• A “morte” deum desses processos deve produzir uma
resposta adequada (alarmar, reiniciar o processo por exemplo)
• Monitoria dos processos é essencial (Watchdog, Monit, etc)

19. FILESYSTEM
• Emintegração de sistemas as vezes precisamos realizar
operações atômicas (ex: um mesmo video não pode ser
encodado varias vezes).
• Mover um arquivo entre diretórios É uma operação atômica.
• Tudo no mundo *nix é arquivo...
•2 + 2...

20. HTTP
• HyperText Transfer Protocol
• Define 4 métodos: GET, POST, PUT, DELETE (HEAD, etc)
• Mensagem possui Header e Body
• Codigos de retorno bem compreendidos (200, 404, 500, 302)
• Trata de transferir recursos

21. REST
• Representational State Transfer
• Posso utilizar caracteristicas do HTTP para representar e
transferir recursos entre sistemas
• Facilita a integração pois praticamente tudo acessa a WEB
• Equivalência entre métodos HTTP e CRUD

22. REST (2)
• PUT -> Create
• GET -> Retrieve
• POST -> Update
• DELETE -> Delete

23. REST (FIM)
• Possotrafegar a representação (em XML, JSON, YAML...)
entre aplicações diferentes.
• Respeitando as regras e os verbos HTTP posso fazer muita
coisa (no mínimo CRUD).
• Tolerância a erros: problemas temporários basta tentar
novamente apos X segundos, problemas irreversíveis devem
ser vistos imediatamente.

24. VIDEO (REST)
• Possui meta-dados, identificador e estado
• Uma API REST (PHP) centraliza a maquina de estados
• Video (dado) é armazenado em banco, arquivo no filesystem
• Basta operar sobre o arquivo e alterar o estado na API

25. CARTAS NA MESA
• Posso
dividir as etapas em deamons independentes, que se
comunicam transferindo o arquivo de video entre diretorios.
• Consistencia é feita pela comunicação com a API
• API fornece formatos de video
• Cumprir todas as etapas torna o video apto a ser consumido

26. FLUXO UNICO
•D -> E(f) -> T -> M -> F -> S (teorico)
•D <- E(f) -> T -> M -> F -> S (pratico)

27. MAS O QUE FAZ A API?
• Outros sistemas integram com a API
• Um fluxo pode ser interrompido
• Posso saber o que esta acontecendo
• Centraliza regras de negócio

28. DEAMON TIPICO
• Trabalha com conceito de diretorios
• Indir é a entrada de videos
• Workdir é onde o deamon trabalha
• Outdir é a saída de videos
• Se o outdir de um deamon for o Indir de outro... ?

29. REDUNDANCIA DE
DEAMONS?
• Operação move é atomica
• Cada processo deve ter o seu Workdir
• Varios procesos de uma mesma etapa tem o mesmo Indir
• Quem chegar primeiro leva.
• Reporta tudo a API REST (LWP)

30. use LWP::UserAgent;
my $ua = LWP::UserAgent−>new;
my $req = HTTP::Request−>new(
GET => "http://api.xxx.com/video/$id"
);
my $res = $ua−>request($req);
if ($res−>is_success) {
process $res−>content;
} else {
error $res−>status_line ;
}

31. <?php
# http://www.slimframework.com
require "Slim/Slim.php";
$app = new Slim();
$app->get('/video/:id', function($id) use ($app) {
$service = new VideoService();
if ( !$service->exists($id) ) {
$app->notFound();
} else {
$app->render('video.tpl', $service->retrieve($id));
}
});
?>

32. E O SLA
• Arquitetura garante paralelismo de atividades demoradas
• Limita-se o tempo de encoding (via SIGALARM)
• Dimensiona-se a infraestrutura para suportar uma média de
videos
• SLA é estatística

33. RESISTENCIA A DESASTRES
• Separandoos deamons cada um fica com codigo minimo e
reusando modulos (CPAN) evitamos (os nossos) bugs
• Perda de rede não trava o encoding, são processos separados
• Perda de banco local não trava o fluxo, depois o sistema é
atualizado desde que haja cache de dados (http!)
• Redundância natural, perder um processo não trava tudo
• Recuperação simples: basta mover de volta o arquivo

34. OUTROS DETALHES
• Meta Dados são publicados usando SOAP::Lite (ugh)
• Thumbs são tranferidos usando base64 dentro do SOAP
• Thumbs gerados pelo FFmpeg e ImageMagick
• 5% dos videos são descartados por falta de qualidade
• Transferencia hoje é SFTP

35. PERGUNTAS?