MEO Cloud - Python Lisbon Meetup
-
Upload
andre-cruz -
Category
Internet
-
view
218 -
download
2
Transcript of MEO Cloud - Python Lisbon Meetup
MEO Cloud• Serviço de alojamento e sincronização de ficheiros
• Clientes desktop para Windows, OSX e Linux (inc RPI)
• Clientes mobile para iOS, Android, Windows Phone
• Cifra client-side (beta)
• Tráfego mobile gratuito na rede PT
• Music player
• Upload2Me
Arquitectura inicial• Metadata:
• BD relacional (MySQL)
• Ficheiros:
• Filesystem distribuído (GlusterFS)
• Web app:
• Nginx + Apache (mod_wsgi) + Python (Django)
Desafios desenvolvimento
• Pedidos buffered
• Muitos pedidos lentos em simultâneo
• Green threads
• Modelo event-driven
• Expor servidor aplicacional
Desafios desenvolvimento
• Sincronização de alterações eficiente (deltas)
• Objectos (ficheiros) potencialmente grandes
• librsync
• dividir ficheiros em blocos <= 4MB
Desafios desenvolvimento
• Grande volume de dados (e metadados)
• Resiliência a falhas
• Sistemas escaláveis na horizontal
• Sem SPOF
Tecnologias usadas• Python + gevent + Django + M2Crypto
• Cassandra
• Solr
• Zookeeper
• Swift
• uWSGI
• Nginx
• SAPO Broker
• Memcached
requirements.txt
• Pillow
• mutagen
• pybloomfiltermmap
• progressbar
• defusedxml
• dm.xmlsec.binding
• objgraph
• Jinja2
Utils
Desafios pós-lançamento
• Solução criada de raiz usando tecnologia recente (bleeding edge)
• uWSGI - http parser, connector https, Gevent loop engine, cache distribuído de sessões SSL
• Pycassa - connection pool && long-lived applications
• Solr - SolrCloud
Desafios pós-lançamento
• Schema Cassandra
• normalização vs desnormalização
• tombstones && slice queries
Desafios pós-lançamento
• Processamento não cooperativo ou CPU bound
• Muitos stacktraces, muito debugging
Alguns números…
• 60% imagens, 20% música, 10% vídeos
• 1,2M uploads/dia - 4,8MB tamanho médio
• 310K downloads/dia - 35MB tamanho médio
• Compressão - BZip2 (12,4%) - Zlib (11,7%)
Desafios• Codebase comum entre Windows, OS X e Linux
• Sincronização transparente em background (daemon que reage a eventos de rede e filesystem)
• Efficiente (RAM, CPU, Disco, Rede, Bateria)
• Robusta/Fiável -> Just works
• De longe, o maior desafio
• A vossa ajuda é preciosa. Really
Tecnologias usadas
• GUI Windows: C++, Win32 API [Jorge Cruz]
• GUI OS X: Objective-C, Cocoa [Paulo Andrade]
• CLI Linux: Python, gevent [Francisco Vieira]
• GUI Linux: Python, GTK [Ivo Nunes]
Tratamento de erros• Não podemos pedir ao utilizador “Tente novamente mais
tarde”.
• Manter estado:
• O que é que falhou?
• Porque é que falhou?
• Já avisámos o utilizador?
• Quando é podemos voltar a tentar?
• O problema já está resolvido?
• Se é para rebentar, fazê-lo ASAP!
Sistema de Ficheiros• Surpresas do Python em Windows (para quem vem do Unix)
• rename() se ficheiro de destino já existe, erro
• open(<path>, ‘rb’) abertura em modo exclusivo -> várias aplicações partem
• readlink() (suporte para symlinks em Windows) não existe
• Tesourinhos: PROGRA~1 -> Usar GetLongPathNameW()
• OS X e Linux
• Pop quiz: link(file1, file2); rename(file1, file2). O que acontece?
Hint: é diferente de mv file1 file2
Nomes de ficheiros(pequeno guia para manter a sanidade mental)
• Em Windows, utilizar paths Unicode e “Long Path Names”, e.g. u’\\\\?\\C:\\file.txt' (>= Windows Vista)
• Em OS X, filesystem utiliza NFD
>>> unicodedata.normalize('NFC', u'João').encode('utf-8')
'Jo\xc3\xa3o'
>>> unicodedata.normalize('NFD', u'João').encode('utf-8')
'Joa\xcc\x83o'
• Em Linux, vale tudo :(
Rede(Much love for pycurl and pyuv)
• Reutilizar ligações para reduzir overhead handshake TCP e SSL
• Transferências simultâneas
• Mitigar overhead relacionado com disk seeks, deltas rsync, etc.
• Minimizar efeito “dente de serra” do TCP quando a latência ou packet loss são elevados
• Enviar apenas o que foi modificado (deltas rsync)
• SSL/TLS: garantir que os certificados são mesmo validados. Bonus points: Certificate Pinning
• Tratar timeouts, resets, stalls, outros.
CPU
• “O Python é lento” -> ineficiente, battery hog?
• “O Python não consegue usar mais que um processador em simultâneo” o “drama” do GIL (Global Interpreter Lock)”
CPU• O core é IO-bound (filesystem e rede)
• Tarefas que usam mais CPU implementadas em C:
• Crypto (block hashes, cifra client-side, SSL)
• deltas rsync
• sqlite (Row objects are cool)
CPU
• Na verdade, o GIL é liberto em muitos casos:
• Quando há IO (rede, filesystem)
• Quando os módulos querem :)
The GIL is free
Memória• Melhorou muito a partir do Python 3.4 (issue #11849)
• Fizemos backport do novo memory allocator (mmap/VirtualAlloc based) para o nossa versão do Python
• Exemplo: Quanta RAM precisamos para sincronizar?:
• 148.887 ficheiros (100.000 ficheiros aleatórios de 10KB + Linux 3.14 source tree):
• Ficheiro 50GB (much data)
API Pública• Autenticação:
• OAuth 1.0a
• OAuth 2.0
• Documentação:
• https://meocloud.pt/developers
• Superset da API REST da Dropbox
• 40+ operações
Exemplos• Long-polling para notificação de alterações
• Key-Value store por user e por aplicação
• Download de pasta como zip
• Thumbnails
• …
• 95% da funcionalidade do web site
Use case(s)
• Cameras + Long polling = motion sensor
• CopyRef + Proximidade = instant transfers
• Upload 2 me = transferências anónimas