Esse post tem sido adiado a no mínimo a uns 2 anos, desde que eu estava em alguns estudos para finalizar a minha dissertação de mestrado, mas como acredito que o conteúdo dele é atemporal, e por isso vou falar um pouquinho sobre essa técnica MARS aqui no How Movile Works.

Contudo, mesmo com todo o material que está na Web, há algumas coisas a serem ditas sobre Multivariate Adaptive Regression Splines, ou simplesmente MARS, dado que essa é uma das técnicas mais subestimadas e desconhecidas de todo universo de algoritmos regressores de Machine Learning.

Uma das primeiras interações que eu tive com MARS foi em um dos testes com o software da Salford Systems, que detém a patente sobre essa técnica. MARS é uma forma de regressão criada em meados da década de 90 por Jerome Friedman.

Eu poderia fazer várias descrições, mas o sumário do artigo original já é matador nesse sentido:

A new method is presented for flexible regression modeling of high dimensional data. The model takes the form of an expansion in product spline basis functions, where the number of basis functions as well as the parameters associated with each one (product degree and knot locations) are automatically determined by the data. This procedure is motivated by the recursive partitioning approach to regression and shares its attractive properties. Unlike recursive partitioning, however, this method produces continuous models with continuous derivatives. It has more power and flexibility to model relationships that are nearly additive or involve interactions in at most a few variables. In addition, the model can be represented in a form that separately identifies the additive contributions and those associated with the different multivariable interactions.

A primeira coisa que me chamou atenção nessa técnica de Machine Learning na época era devido ao fato de que a MARS foi desenhada para atacar dois dos maiores problemas que eu enfrentei, na época trabalhando no mercado financeiro, que eram: (i) bases de dados com alta dimensionalidade e (ii) não linearidades nas dinâmicas de recuperação de Non-Performing Loans.

Continue reading

Há muito tempo atrás, em uma galáxia não muito distante, vivia um povo pacífico que adorava disputar com seus amigos para ver quem tinha um servidor rodando a mais tempo. Naquele tempo, era incrível ver um servidor rodando interruptamente por mais de 1.000 dias sem reiniciar para mostrar como o Linux era algo bom e estável.

sysadmins

Hoje em dia, quando eu vejo um servidor rodando há muito tempo, eu penso em coisas como:

“Caramba, este servidor deve estar muito desatualizado, cheio de problemas de segurança e sabe-se lá o que vai acontecer quando ele reiniciar. O fsck vai levar uma eternidade para rodar, isso se o servidor voltar…”

Mas não me entenda mal: O uptime continua sendo importante, mas não de apenas uma máquina. Agora, o que importa é a disponibilidade do sistema como um todo.

É por isso que na Movile, nós construímos nossas plataformas para rodarem em vários data centers com tolerância à falhas, porque nós sabemos que o hardware vai falhar cedo ou tarde.

Com isso em mente, nós iremos fazer um plugin que mostra o uptime de nossos nodes, podendo separar por datacenter e ordenando do maior para o menor. Esta será uma ótima oportunidade para aprender a melhorar o Chef Server e o Knife usando um exemplo prático. Além disso, este plugin irá nos ajudar a monitorar os hosts que ainda precisam ser reiniciados após a aplicação do patch “GHOST: glibc vulnerability (CVE-2015-0235)” que está a solta comendo o nosso tempo

Continue reading

São inúmeros os benefícios que a centralização de logs traz para sua infraestrutura, por isso nos últimos anos varias soluções veem surgindo, dentre elas destaca-se o Logstash.

Neste artigo irei explicar como criar um cluster de alta disponibilidade para logs centralizados com Logstash e Elasticsearch. Com esse cluster seremos capazes de indexar 750GB de logs por dia.

Continue reading

Na Amazon Web Services (AWS), uma das práticas que se tornaram mais comuns é dividir uma conta em várias sub-contas, onde cada conta tem suas próprias credenciais, instâncias e serviços. A prática adiciona complexidade quando se tem uma rede grande, mas por outro lado facilita em vários quesitos: cada conta pode ter pessoas com autonomias diferentes sem regras de IAM muito complexas; os centros de custos ficam separados de forma muito fácil (sem o uso de tags, como seria o caso de uma conta só); grandes projetos podem ter uma infraestrutura totalmente independente; entre outros.

Quando se tem múltiplas contas em uma mesma empresa, geralmente necessitamos interligar estas contas de forma segura. Uma ótima forma de fazer isso é usar o VPC Peering para criar VPCs em uma mesma região. Mas e quando as VPCs estão em regiões separadas, como se comunicar entre elas? Neste caso, ao invés de utilizar o VPC Peering nativo oferecido pela AWS, podemos montar instâncias EC2 com IPSEC configurado, para montar VPNs criptografadas entre quaisquer redes. Para esse tipo de VPN chamados de VPN site-to-site.

Aqui na Movile utilizamos muitas contas AWS em várias regiões diferentes. Para manter serviços de monitoramento e automação com segurança, tivemos que implementar esses mecanismos. Aqui neste tutorial, mostramos como fizemos isso.

Continue reading