Zynga entra no jogo com o Amazon Aurora – Guest Post

Cliente de longa data da AWS a Zynga está fazendo grande uso do Amazon Aurora e outros serviços de banco de dados da AWS. No guest post de hoje você pode aprender sobre como eles usam o Amazon Aurora para acomodar picos das suas cargas de trabalho. Este post foi escrito por Chris Broglie da Zynga.

— Jeff Barr

Post original por Jeff Barr em 20 junho 2016

A Zynga há muito vem operando várias tecnologias de banco de dados, que vão desde simples caches na memória como o Memcached, para as lojas NoSQL persistentes como Redis e Membase, até bases de dados relacionais tradicionais, como MySQL. Nós amamos as características oferecidas por estas tecnologias, mas executá-las em escala demanda muito tempo manual para recuperar falhas de instâncias e criar scripts e monitorar tarefas mundanas, mas críticas, como backup e recuperação. À medida que migramos da nossa própria nuvem privada para a AWS em 2015, um dos objetivos principais era o de reduzir a carga operacional sobre nossos engenheiros ao abraçar os muitos serviços gerenciados oferecidos pela AWS.

Estamos usando amplamente o Amazon DynamoDB e o Amazon ElastiCache (Memcached e Redis) no lugar dos seus equivalentes autogeridos. Agora, os engenheiros são capazes de se concentrar no código do aplicativo em vez de gerenciar níveis de banco de dados, com isso melhoramos nossos tempos de recuperação de falha da instância (spoiler alert: máquinas são melhores nisso do que os seres humanos). Mas a única componente em falta aqui foi MySQL. Nós amamos a automação do Amazon RDS para ofertas MySQL, mas depende de volumes de uso geral Amazon Elastic Block Store (EBS) para armazenamento. Ser capaz de alocar dinamicamente armazenamento durável é ótimo, mas você deve escolher entre enviar o tráfego através da rede, e os bancos de dados tradicionais sofrem desta latência adicional. Nossos testes mostraram que o desempenho do RDS para MySQL simplesmente não se compara com o que poderíamos obter com instâncias i2 locais (embora efêmera) SSDs. IOPS provisionados diminuem a diferença, mas eles custam mais. Por estas razões, nós usamos instâncias i2 autogeridas sempre que haja requisitos de desempenho muito rigorosos.

No entanto, para um novo serviço que estávamos desenvolvendo durante a migração, decidimos apostar no Amazon Aurora. O Aurora é um banco de dados relacional compatível com MySQL oferecido através do Amazon RDS. Usamos o Aurora apenas na pré-visualização quando começamos a escrever o serviço, mas era esperado torná-lo disponível antes da produção, e sabíamos que sempre poderíamos voltar a executar o MySQL em nossas próprias instâncias i2. Estávamos naturalmente apreensivos diante da nova tecnologia, mas nós tivemos que ver por nós mesmos, se o Aurora poderia cumprir as suas reivindicações de ultrapassar a performance do MySQL em SSDs locais, enquanto ainda estiver usando armazenamento de rede e fornecendo toda a automação de um serviço gerenciado como RDS. E após 8 meses de produção, o Aurora não tem sido nada menos do que impressionante. Enquanto a nossa carga de trabalho é bastante modesta – a instância mais movimentada é uma manipulação r3.2xl ~ 9k seleções/segundo durante o pico de 150 GB de conjunto de dados – nós amamos que até agora o Aurora entregou o desempenho necessário, sem qualquer sobrecarga operacional de execução do MySQL.

Um exemplo do que este tipo de automação nos permitiu foi um incidente operacional, onde uma mudança nos padrões de tráfego resultou em um aumento enorme carga sobre uma das nossas instâncias Aurora. Felizmente, a instância foi capaz de manter o tráfico apesar de 100% da CPU, mas precisávamos de ainda mais rendimento. Com o Aurora fomos capazes de ampliar o leitor de uma instância em até 4x mais, e depois de vê-lo lidar com 4x o tráfego, tudo com apenas alguns cliques no console do RDS. Dias mais tarde depois que lançamos um patch para evitar que o incidente se repita, fomos capazes de escalar de volta para instâncias menores usando o mesmo procedimento. Antes do Aurora teríamos que obter um DBA on-line para manualmente disposição, replicar e failover a uma instância maior, ou tentar enviar uma correção de código para reduzir a carga no banco de dados. Alterações manuais são sempre mais lentas e mais arriscadas, por isso, a automação do Aurora é uma grande adição ao nosso ops toolbox, e neste caso, levou a uma resolução, medida em minutos em vez de horas.

A maior parte da automação que estamos desfrutando tem sido padrão para RDS, mas usar o Aurora entregou a automação do RDS juntamente com o desempenho de instâncias i2 auto-geridas. O Aurora é agora a nossa primeira escolha para novos serviços que utilizam bancos de dados relacionais.

— Chris Broglie, Arquiteto (Zynga)