Expansão do setor de jogos com Gaspard Petit, da Square Enix
Michael Lynn29 min read • Published May 09, 2022 • Updated Mar 22, 2023
Avalie esse Podcast
A Table Enix é uma das marcas de jogos mais populares do mundo. Eles são conhecidos por jogos de franquias como Tomb Raider, Final Identity, Dragon Quest e muito mais. Neste artigo, fornecemos uma transcrição do capítulo do Podcast do MongoDB em que Michael e Nic se reúnem com Gapard Pett, arquiteto de software da Square Enix, para contar como estão utilizando o MongoDB e sua própria experiência pessoal com o MongoDB como um banco de dados plataforma.
Junte-se a nós nos fóruns para conversar sobre este capítulo, sobre jogos ou sobre qualquer coisa relacionada ao MongoDB e desenvolvimento de software.
Gapard Pett (00:00): Olá a todos, este é Gapard Pett. Meu nome é da Square Enix. Bem-vindo a este Podcast do MongoDB.
Gaspard Petit (00:09): O MongoDB era perfeito para processos, não havia colunas predefinidas, nenhum esquema, podíamos apenas adicionar campos. E por que isso é importante como designers é que não sabemos de antemão como será o jogo final. Isso é algo que evolui, fazemos um protótipo, você gosta, não gosta, desfaz algo, refaz algo, volta para algo que fez anteriormente e continua mudando conforme o jogo evolui. É muito raro eu ver uma produção de jogo Go direto do ponto A ao Z sem girar um pouco e ir para frente e para trás. Portanto, esse processo de vai e vem é trabalhoso. Para o back-end, onde os requisitos são imutáveis, você precisa entregá-lo para que a equipe do jogo possa experimentá-lo e, em seguida, eles irão iterar nele. E se você está definido em seu banco de dados, e cada vez que você muda algo, você tem que migrar seus dados, você está perdendo muito tempo.
Michael Lynn (00:50): Bem-vindo ao show. No episódio de hoje, estamos conversando com Gaspard Petit, da Square Enix, criador de alguns dos jogos mais conhecidos e amados da indústria de jogos. Hoje, estamos falando sobre como eles estão aproveitando o MongoDB e um pouco sobre a diário de Gapard como arquitecto de software. Espero que você goste desse episódio.
Automatizado (01:07): Você está ouvindo o podcast do MongoDB, explorando o mundo do desenvolvimento de software, dados e tudo relacionado ao MongoDB. E agora seus apresentadores, michael lynn e Nic Raboy.
michael lynn (01:26): Oi, Nic. Como você está hoje?
Nic Raboy (01:27): Estou muito bem, Lake. Estou muito ansioso por este capítulo. Estou ansioso por isso. O que é isso? Mais de um mês agora, porque é realmente uma das coisas que me atinge em casa, e isso é jogo. Essa é uma das razões pelas quais entrei no desenvolvimento de software. Então isso vai ser demais. O que você acha, Mick?
michael lynn (01:43): fantástico. Estou ansioso por isso também. E temos um convidado especial, Gaspard Petit, da Square Enix. Bem-vindo ao podcast, é ótimo ter você no programa.
Gaspard Petit (01:51): Olá, é bom estar aqui.
michael lynn (01:52): fantástico. Talvez se você pudesse se apresentar ao pessoal e deixar as pessoas saberem o que você faz na Square Enix.
Gaspard Petit (01:58): Claro. Então, eu trabalho como arquiteta de software on-line na Square Enix. Eu joguei praticamente toda a minha vida. E quando eu era criança, desenhava níveis de jogos em pedaços de papel com meus amigos, fui para a universidade como engenheiro de software, trabalhei em algumas empresas, algumas eram jogos, outras eram jogos. Por exemplo, com Autodesk ou Flexibleimage. E então começou a jogar, o primeiro jogo foi um jogo multijogador. E isso me levou lentamente a jogos multijogador. A primeira empresa foi na Behaviour e depois na Eidos trabalhando na reinicialização de Tomb Raider no lado multiplayer. Fiz uma pequena pausa, voltei para uma empresa chamada Datamine, onde aprendi sobre o back-end como trabalhar. Não estava na Azure Cloud na época. E aprender muito sobre como fazer esses processos na cloud, o que se tornou surpreendente como você pode convergir muitas solicitações, muitos usuários em um ambiente distribuído e processar esses dados com eficiência.
Gaspard Petit (03:03): E depois retornou à Square Enix como líder da suíte online, que chamamos internamente de nossa equipe, que é responsável por muitos dos back-ends de jogos da Square Enix. E eu estou lá há alguns anos. Seis anos, eu acho, e agora me tornei arquiteto online. Então, minha função é garantir que estejamos nos desenvolvendo na direção certa usando os serviços certos, que nossas soluções sejam escaláveis e adequadas às necessidades da equipe do jogo. Basicamente, estamos oferecendo a eles bons serviços on-line e que eles também são confiáveis para os usuários.
Nic Raboy (03:44): Então, a reinicialização de Tomb Raider, foi seu primeiro grande momento na indústria de jogos profissionais, ou você teve grandes momentos anteriores antes disso?
Gaspard Petit (03:54): Devo dizer que foi provavelmente um dos que mais me orgulho. Para ser sincero, trabalhei em um jogo anterior, chamado Naughty Bear. Não foi um grande sucesso do ponto de vista do público, os metacríticos não foram ótimos. Mas a equipe em que trabalhei era uma equipe incrível, e todos nessa equipe eram dedicados. Era uma equipe pequena, os desafios eram enormes. Então, do meu ponto de vista, esse jogo foi um grande sucesso. Não deu certo, o público não viu dessa forma. Mas os desafios, era um jogo multiplayer. Tivemos os requisitos de última hora para fazer deste um jogo multijogador. Então tivemos que transformar o single player em multiplayer, fazer a replicação. Muitas coisas complicadas em um curto espaço de tempo. Mas com a equipe certa, com as pessoas certas motivadas. Para mim, essa foi minha primeira conquista no jogo.
Michael Lynn (04:49): Você disse que o jogo se chama Naughty Bear?
Gaspard Petit (04:51): Urso travesso, sim.
michael lynn (04:52): que tipo de jogo é esse? Porque não estou familiarizado com isso.
Gapard Pett (04:55): Não, muitas pessoas não são. É um jogo em que você joga com um ursinho de pelúcia que acorda em uma ilha. E você percebe que há uma festa e que você não foi convidado para ela. Então você simplesmente Go e mata praticamente todos os ursos da ilha. Mas há AI envolvida, há maneiras diferentes de matar, há maneiras diferentes de interagir com esses ursinhos de peluche. E, claro, não há sangue, certo? Então não é Violência. É simplesmente fun, certo? Então, está tocando um pouco desse lado, do-
michael lynn (05:23): Com certeza.
Gaspard Petit (05:26): Mas está em uma ilha pequena, então é muito limitado. Mas a preocupação é com a AI e jogar com os amigos. Então você pode jogar como os ursos que estão tentando se esconder ou como o urso que está tentando carnificina a ilha.
Gapard Pett (05:41): Foi praticamente o que me introduziu às tabelas de classificação e à replicação multijogador. Não temos nenhum jogo salvo. Foi há mais 10 anos, então a nuvem estava apenas se formando. Mas você ainda teria que adicionar recursos de aggregation, esse tipo de recursos que me levaram ao ambiente online.
Nic Raboy (05:59): Incrível. Em relação ao seu jogo Naughty Bear, antes de entrarmos na pontuação e outras coisas, o que você usou para desenvolvê-lo?
Gapard Pett (06:05): era tudo C++, um pouco de Nua na época. Como eu disse, no lado de trás, não havia muito o que fazer. Usamos as API's de primeira parte que eram C++ conectadas ao servidor. O resto era uma caixa-preta. Na época, eu não sabia como funcionava o matchmaking ou como funcionavam todas essas tabelas de classificação, só me lembro que era um pouco frustrante postar pontuações, por exemplo, nas tabelas de classificação. E, às vezes, demorava alguns segundos para que a classificação fosse atualizada. E lembrei-me de ter me sentido um pouco mal por isso. Por que isso não é atualizado imediatamente? Acabei de postar minha pontuação e pode levar um ou dois minutos até que minha classificação seja atualizada. E agora que estou trabalhando com back-end, entenda totalmente. Entendo o volume de pontuações que são publicadas, a classificação, a triagem e todos os desafios no back-end. Mas para mim, naquela época, ainda era uma caixa preta.
michael lynn (06:57): Então, esse jogo estava aproveitando o MongoDB como parte do back-end?
Gaspard Petit (07:01): Não, não, não. Como eu disse, não estava realmente na nuvem. Foi apenas a API primária. Não saberia lhe dizer o que a Microsoft e aSony estão usando. Mas, do nosso ponto de vista, não estávamos usando nenhum banco de dados interno. Então aquela era uma empresa diferente, era na Behavior.
Michael Lynn (07:19): E eu estou curioso, como desenvolvedor no início de sua carreira, o que você aprendeu sobre desenvolvimento de jogos e que ainda leva com você hoje?
Gaspard Petit (07:28): Acho que muitas pessoas estão interessadas no desenvolvimento de jogos pelas mesmas razões que eu. É muito cérebro esquerdo e direito, você tem muita criatividade, você tem que encontrar maneiras de fazer as coisas funcionarem. Às vezes, você está no início de um projeto e tem a chance de fazer as coisas da maneira certa. Então você arquiteta as coisas, faz o design adequado, às vezes até desenha UML e organiza seus objetos para que tudo fique limpo, e você sente que está quase fazendo um trabalho teórico e acadêmico, e então o projeto evolui. E à medida que você se aproxima da data de lançamento, isso não é algo que viverá para sempre, não é um produto que você reciclará e precisa ser mantido pelos próximos 10 anos. Isso é algo que você vai enviar e tem que funcionar idealmente no dia em que você o enviar.
Gaspard Petit (08:13): Então você começa a mudar seu foco dizendo: "Isso tem que funcionar, não importa o que aconteça. Preciso encontrar uma solução. Há algo aqui que não funciona." E não tenho tempo para encontrar um design adequado para refatorar isso, só tenho que fazê-lo funcionar. E você muda sua maneira de trabalhar completamente para enviá-lo, fazê-lo funcionar, encontrar uma solução. E você entra em um tipo diferente de Criatividade como programador. O que eu adoro, o que também é assustador às vezes porque você coloca essa fita adesiva em seu código e funciona. E você está se perguntando: "Devo me sentir bem ao enviar isso?" E, na verdade, ninguém vai notar e vai aguentar e o jogo vai ser divertido. E não importa que você tenha essa fita adesiva em algum lugar. Acho que isso faz parte da diversão de moldar o jogo, fazendo-o funcionar no final, não importa o que aconteça. E não precisa ser perfeitamente limpo, mas tem que ser divertido no final.
Gaspard Petit (09:08): Este é definitivamente um aspecto disso. O outro aspecto é o tempo real, você quer atingir 30fps ou 60fps ou mais. Tenho certeza de que o pessoal do PC agora está exigindo mais. Mas você quer essa taxa de quadros e, ao mesmo tempo, quer o AI, o áudio, a física e tudo nesse FPS. E você de alguma forma tem que fazer tudo funcionar. E você tem que encontrar qualquer truque que puder. Se você puder pré-processar coisas em seus ativos de disco rígido, você o faz. Quaisquer que sejam as necessidades que você possa otimizar, você terá a chance de otimizá-las.
Gaspard Petit (09:37): E há muito poucos lugares na indústria onde você ainda tem a chance de otimizar as coisas e dizer: "Se eu puder remover esse milissegundo em algum lugar, isso terá realmente um impacto em algo". Backend tem isso de certa forma. MongoDB, estou certo de que, se você pode remover um segundo em um só lugar, tem a impressão de que agora posso realizar mais queries por segundo. Mas o jogo também tem esse aspecto de, eu poderei processar um pouco mais, poderei carregar mais ativos, mais triângulos, renderizar mais coisas ou acertar mais caixas delimitadoras. Então a performance é sem dúvidas um aspecto interessante do jogo.
Nic Raboy (10:12): Você passou muito tempo fazendo o desenvolvimento real do jogo sendo o lado criativo, sendo engenheiro de desempenho, coisas assim. Como foi a transição para se tornar um arquiteto online? Suponha que, pelo menos, você não esteja mais fazendo o que as pessoas veem, mas o que as pessoas experimentam no backend, certo? Como é isso?
Gapard Pett (10:34): Isso mesmo. Não foi uma transição fácil. E eu era o líder da equipe por alguns anos. Então eu peguei isso de alguns candidatos que se juntaram à equipe, você poderia dizer que eles gostariam de estar fazendo jogabilidade ou gráficos, e eles entraram na equipe de back-end. E parece que você está, "Ok, eu vou fazer isso por alguns anos e depois eu vou ver." Mas acabou que eu realmente amei. Você tem uma visão global dos jogadores o que eles estão fazendo, não apenas em um único console, você também pode experimentar o jogo ao vivo, o que eu não tive quando estava programando o jogo, você programa o jogo, ele vai para um disco ou um formato digital, é enviado e é aqui que Julian, Você tira suas férias depois que um jogo é lançado.
Gaspard Petit (11:20): A alegria de viver o momento em que o jogo está fora, monitorando-o, vendo o jogador enquanto algo se desconecta, ou tendo alguns problemas, monitorando as métricas, vendo se o jogo está funcionando conforme o esperado ou não. E então você entra em outras coisas interessantes que você pode fazer no back-end, o que eu não poderia fazer no jogo é consertar o jogo depois que ele foi lançado. Então, por exemplo, você descobre que o balanceamento está desativado. Algo no jogo não funciona como o esperado. Mas você tem uma maneira de descobrir pelo back-end como pode corrigir isso.
Gapard Pett (11:54): é claro que, idealmente, você corrigiria no jogo. Mas, hoje em dia, nem sempre é fácil reembalar o jogo em cada plataforma e entregá-lo no prazo. Pode levar algumas semanas para consertar o jogo a partir do código. Então, tudo o que pudermos corrigir do back-end, nós corrigimos. Portanto, precisamos ter as ferramentas adequadas para monitorar essa enorme quantidade de dados que chegam até nós. E, então, a criatividade entra em ação, dizendo: "Ok, eu tenho esses dados, como posso agir com base neles para melhorar o jogo?" Então, ainda continuo tendo essas preocupações do back-end.
michael lynn (12:25): E eu estou sentido que a linha entre back-end e front-end está realmente se misturando recentemente. Sempre que fico on-line para jogar, sou forçado a Go pelo processo de atualização de muitos dos jogos que jogo. Até que ponto você tem flexibilidade? Farei a pergunta desta forma. Com que frequência você faz alterações em jogos que já foram lançados?
Gaspard Petit (12:46): Não é tão frequente. Também não é raro. Está em algum lugar no meio. Idealmente, não precisaríamos fazer nenhuma alteração após o lançamento do jogo. Mas, na prática, os jogos estão se tornando tão complexos que não cabem mais em um cartucho pequeno de 32 megabytes. Então, há muitas coisas passando pelo jogo. Eles são enormes. É quase impossível acertá-los perfeitamente e entregá-los em alguns anos.
Gaspard Petit (13:16): E também há uma limitação para o que você pode testar internamente. Mesmo com uma equipe enorme de QA, você descobrirá coisas somente quando os jogadores estiverem experimentando o jogo. Como eu disse, o fluxo de reparos do jogo é longo. Você ouve sobre o relatório no Reddit ou no Twitter e tenta reproduzi-lo internamente ali mesmo. Pode levar alguns dias para obter o mesmo erro relatado pelo jogador. E depois disso, você precisa descobrir no código como corrigi-lo, certifique-se de não quebrar mais nada. Portanto, pode levar literalmente semanas até que você conserte algo muito trivial.
Gaspard Petit (13:55): No back-end, se pudermos experimentá-lo, podemos segmentar uma correção específica para um único jogador, certifique-se de que funcione para esse jogador. Faça alguma introdução azul-esverdeada desse teste ou faça-o apenas no teste primeiro, certificando-se de que funciona, fazendo isso na produção. E dentro de algumas vezes, eu diria, uma correção saiu em algumas horas em algum caso em que notamos isso na produção, fomos para a preparação e para a produção no mesmo dia com algo que consertaria o jogo.
Gapard Pett (14:25): Então, idealmente, você colocaria o máximo que pudesse no back-end porque você tem muita agilidade do back-end. Eu sei que os jogadores têm uma certa rejeição a essa ideia de usar back-ends para jogos porque a veem como uma ameaça. Acho que eles não percebem o quanto podem se beneficiar das correções que fazemos no back-end.
Nic Raboy (14:45): Então, em relação ao back-end do qual você faz parte, o que normalmente vai para o back-end? Suponho que você esteja usando algumas ferramentas, frameworks, linguagens de programação, talvez você possa lançar alguma luz sobre isso.
Gapard Pett (14:57): Sim, com certeza. Então, normalmente, em quase todos os projetos, há alguma telemetria que é útil para monitorarmos se o jogo está funcionando como eu disse, como esperado. Queremos saber se o jogo está travando, queremos saber se os jogadores estão presos no nível e não conseguem passar por ele. Se houver uma conquista que não trava ou algo que não deveria estar acontecendo e não acontece. Portanto, queremos ter certeza de que estamos monitorando essas coisas.
Gapard Pett (15:23): dependendo do projeto, temos funcionalidades de comunidade. Por exemplo, comparando o que você fez na série de experiências de vida com o que a comunidade fez, e em algum momento serão os engajamentos ou a criação de desafios que mudarão semanalmente. Em alguns casos recentemente para outriders, por exemplo, temos todo o jogo salvo salvo online, o que significa duas coisas, certo? Podemos ter uma ideia do estado de cada reprodutor, mas também podemos corrigir as coisas. Então depende muito do projeto. Começa desde a simples telemetria, apenas para sabermos que as coisas estão a ir bem, ou podemos agir sobre isso para adicionar alguma lógica de jogo no backend que está sendo executado no backend.
Michael Lynn (16:09): E quais são as estruturas e ferramentas de desenvolvimento que você aproveita?
Gaspard Petit (16:12): Sim, desculpe. Então, os back-ends que escrevemos são escritos em Java. Temos ferramentas diferentes, usamos fora do back-end. Implementamos em Kubernetes. Quase tudo são imagens Docker neste ponto. Usamos o MongoDB como armazenamento principal. Redis como armazenamento efêmero. Também usamos Kafka para o pipeline de telemetria para garantir que não os perdemos e que podemos processá-los de forma assíncrona. Jenkins para a construção. Portanto, este é praticamente o nosso ambiente.
Gapard Pett (16:45): Também estamos trabalhando na integração do jogo, em C++ e C#. Então, nossa equipe fornece e realmente faz algum desenvolvimento em C++ em que tentamos criar um cliente HTTP, clientes C++, que seja multiplataforma e o mais eficiente possível. Então, pelo menos impactando a taxa de quadros. Mesmo às vezes, isso significa que o download das coisas está um pouco mais lento ou não está marcando tantos ticks. Mas personalizamos nosso cliente HTTP para garantir que o impacto online seja mínimo no jogo. Portanto, nossa equipe é responsável pela integração do cliente ao jogo e pelo desenvolvimento do back-end.
michael lynn (17:24): Então, esses clientes HTTP, são esses SDKs personalizados que você está fornecendo a seus próprios desenvolvedores internos para usar?
Gapard Pet (17:31): Exatamente, então é nossa própria biblioteca que mantemos. Ele garante que o que fornecemos possa autenticar corretamente com o backend como uma maneira correta de se comunicar com ele, as novas tentativas certas, o enfileiramento correto. Portanto, não precisamos impor políticas a cada tema do jogo, como nos conectar ao back-end. Podemos agrupar essas políticas no SDK que fornecemos a eles.
Michael Lynn (17:57): Então, que conselho você daria para alguém que está apenas começando a desenvolver jogos? Talvez algum conselho sobre onde se concentrar em sua jornada como desenvolvedor de jogos?
Gaspard Petit (18:08): Essa é uma ótima pergunta. O conselho que eu daria é, claro, ser apaixonado por isso. Tem que fazer porque há muito trabalho no jogo, é verdade que fazemos muitas horas. Se não gostssemos do trabalho que fizemos, provavelmente Go para outro lugar. Mas é divertido. Se você é apaixonado por isso, não se importará tanto, porque o sucesso e a sensação que você tem em cada lançamento compensa o esforço que você coloca nesses projetos. Então primeiro você precisa ser apaixonado por isso, você precisa querer realizar esses projetos e ter orgulho deles.
Gaspard Petit (18:46): E então eu diria para não focar muito em um aspecto do jogo porque, no começo, fiz várias coisas, certo? Meus estudos foram sobre processamento de imagens, eu queria fazer a renderização 3D. No início, esse era o meu objetivo inicial quando criança. E definitivamente não foi isso que acabei fazendo. Eu fez quase tudo. Fiz um pouco de renderização, mas quase nada. Eu terminei no back-end. E aprendi que quase todos os aspectos do desenvolvimento do jogo têm algo interessante e desafiador.
Gaspard Petit (19:18): Então, eu diria que não muito para se concentrar em fazer a física ou a renderização, às vezes você pode acabar fazendo o áudio e isso ainda é algo fascinante. Como você pode colocar seu áudio dentro da cena e fazer parecer que vem de um lugar e bater nas paredes. E então, em cada aspecto, você pode pesquisar e fazer algo interessante. E os jogos agora, pelo menos dentro da Square Enix, eles são grandes demais para uma pessoa fazer tudo. Então, de forma geral, você fará parte de uma equipe de qualquer forma. E dentro dessa equipe, haverá algo difícil de fazer.
Gaspard Petit (19:49): E mesmo o back-end, eu sei que muitas pessoas não consideram o back-end como sua primeira escolha. Mas isso é algo que é realmente um erro. Há muitas coisas interessantes para fazer com o back-end, especialmente agora que há alguma jogabilidade acontecendo nos back-ends, e cada vez mais lógica acontecendo no back-end. Não gostaria de dizer que um é melhor que o outro, é claro, mas pessoalmente não voltaria e nunca esperei adorá-lo tanto. Portanto, tenha a mente aberta e seja apaixonado. Acho que esse é o meu conselho geral.
michael lynn (20:26): Então, por falar em back-end, podemos falar um pouco sobre como a Square Enix está aproveitando o MongoDB hoje?
Gapard Pett (20:32): Então, usamos o MongoDB há algum tempo. Quando entrei para a equipe, ela já estava sendo usada. Nós estavamos na versão 2.4. O MongoDB tinha acabado de implementar autenticação em collection, eu acha. Então, há um bom tempo, e vi isso desenvolver-se com o tempo. Se puder compartilhar isso, lembrei-me do meu primeiro dia na equipe acessando o MongoDB. E eu estava começando de um mundo semelhante ao SQL e estava refletindo: "O que é isso? O que é essa linguagem de query e JSON?" E, é claro, não podi consultar nada no início porque tudo era como se a sintaxe me parecesse completamente estranha. E eu não entendia nada sobre sharding, nada sobre chunking, nada sobre como o banco de dados funciona. Então, na verdade, demorei alguns meses, eu direi, antes de começar a avaliar o que o Mongo fez e por que ele foi escolhido.
Gaspard Petit (21:27): Portanto, foi recomendado, se bem me lembro, não quero dizer coisas incorretas. Mas acha que tinha sido recomendado antes do meu tempo. Foi uma equipe de consultoria que recomendado MongoDB para o jogo. Eu não seria capaz de dizer exatamente por quê. Então, com o tempo, o que Percebi é que o MongoDB era perfeita para nossos processos porque não havia nenhuma predefinição de colunas, qualquer esquema, podamos apenas adicionar campos. Se os campos estivessem faltando, não era grande coisa, poderíamos codificar no back-end e simplesmente defini-los com valores padrão.
Gaspard Petit (22:03): E por que isso é importante é porque a equipe do jogo geralmente não sabe. Não quero dizer que a equipe do jogo, na verdade, os designers ou o produtor, não saibam com antecedência como será o jogo final, isso é algo que evolui. Você joga, faz um protótipo, gosta, não gosta, desfaz algo, refaz algo, Go para algo que fez anteriormente e continua mudando conforme o jogo evolui. É muito raro eu ver uma produção de jogo Go direto do ponto A ao Z sem girar um pouco e ir para frente e para trás.
Gapard Pett (22:30): de modo que o processo de ida e volta é trabalhoso para o back-end. Você será solicitado a implementar algo antes que os requisitos sejam definidos, você precisa entregá-lo para que a equipe do jogo possa testá-lo e, em seguida, iteraremos sobre isso. E se você estiver gravando em seu banco de dados e cada vez que alterar algo, tiver que migrar seus dados, estará desperdiçando muito tempo. E depois, como eu disse, depois de alguns meses que se tornou obvio que o MongoDB era a opção perfeita para isso, porque a equipe do jogo nos perguntava: "Ei, preciso armazenar isso agora, ou você pode alterar esse tipo para outro tipo?" E era fácil, mudamos uma string para um número inteiro ou uma string, adicionamos um campo a um documento e pronto. Sem migração. Se necessário, o backend detectaria os casos em que um valor padrão estivesse faltando. Mas foi isso.
Gaspard Petit (23:19): E conseguimos progredir com a equipe do jogo à medida que ela evoluía seu design. Conseguimos acompanhá-la rapidamente com nosso banco de dados sem esquemas. Então agora eu não mudaria de volta. Já me acostumei com a linguagem de query JSON,acho que o ser humano se acostuma com qualquer coisa. E, uma vez que esteja familiarizado com algo, não quer aprender outra. E terminei aprendendo a sintaxe SQL Mongo, e agora estou realmente muito confortável com ela. Eu faço agregação na linha de comando, esses tipos de coisas. Portanto, é apenas algo que você precisa ter cuidado se não tiver usado o MongoDB antes. A princípio, parece um pouco estranho, mas logo se torna óbvio o motivo pelo qual foi projetado dessa forma. Na verdade, é muito intuitivo de usar.
Nic Raboy (24:07): Em relação ao desenvolvimento de jogos em geral, quem determina a aparência dos dados? Essas são as pessoas que estão realmente criando a cópia local instalável do jogo? Ou é a equipe de back-end que decide como é o modelo em geral?
Gapard Pett (24:23): é uma mistura de ambos. Nossa equipe atua como uma equipe de especialistas, portanto, não ditamos onde o back-end deve estar. Mas como estivemos em vários projetos, temos alguma experiência nos padrões bons e ruins. E no MongoDB nem sempre é fácil, certo? Já fomos muito atingidos por antipadrões no passado. Então, agora pularíamos imediatamente se a equipe do jogo nos pedisse para armazenar algo de uma forma que sabíamos que não teria um bom desempenho ao aumentar a escala. Portanto, somos cautelosos com isso, mas, em geral, os requisitos vêm da equipe do jogo, e traduzimos isso em um esquema de banco de dados, que diz que, em alguns casos, a equipe do jogo sabe exatamente o que quer. E, nesses casos, geralmente apenas armazenamos seus dados como uma string bruta no MongoDB. E então podemos processá-lo de volta, seja JSON ou qualquer outro formato que eles desejarem. Damos a eles um campo dizendo: "Isso pertence a você e usamos o esquema que quiser dentro dele".
Gaspard Petit (25:28): Mas é claro que eles não poderão inserir nenhuma consulta nesses dados. É mais um armazenamento do que qualquer outra coisa. Se eles precisarem realizar operações, e nós estamos definitivamente envolvidos, porque queremos ter certeza de que eles estarão atingindo os índices corretos, que o sharding será feito corretamente. Então é uma combinação dos dois lados.
michael lynn (25:47): Ok, então temos o MongoDB na pilha. E estou visualizando que, como desenvolvedor, terei um ambiente de desenvolvimento. E conte-me sobre a maneira como, como desenvolvedor, estou interagindo com o MongoDB. E então como essa transição para o ambiente de produção?
Gaspard Petit (26:04): Claro. Portanto, todo desenvolvedor tem um MongoDB local, usamos isso para desenvolvimento. Então nós temos o nosso. No momento, a imagem é docker-compose. E tem um ambiente virtual completo. Ele tem todos os outros componentes que mencionei anteriormente, tem Kafka, tem até LDAP, tem um monte de coisas executando virtualmente, incluindo o MongoDB. E ele está até configurado como um cluster fragmentado. Portanto, temos um cluster sharded local em cada uma de nossas máquinas para garantir que nossas consultas funcionem bem no cluster sharded real. Então, está realmente muito próximo da produção, mesmo que esteja em nosso PC local. E começamos com isso, desenvolvemos em Java e escrevemos nosso teste de unidade para garantir que cobrimos o que escrevemos e não temos regressão. E esses testes de unidade serão executados em uma instância local do MongoDB.
Gaspard Petit (26:54): Em algum momento, estamos prestes a lançar algo em produção, especialmente quando há muitas mudanças. Queremos garantir que façamos testes de carga. Para nosso teste de carga, temos outra coisa e não estou certo de que seja um recurso muito conhecido do MongoDB, mas é extremamente útil para nós. É o Operador MongoDB, que é um operador dentro do Kubernetes. E permite girar clusters com base no simples YAML. Portanto, você pode dizer: ". Quero um cluster sharded com três shards profundos, cinco shards," e ele o ativará para você, o que levará alguns segundos ou alguns minutos, dependendo do que você tiver em seu YAML. E então você tem isso. Você tem seu cluster configurado em seu cluster Kubernetes. E então executamos nossos testes sobre isso. É um novo cluster, novinho em folha. Execute o teste completo, simule milhões de solicitações de usuários, destrua-o. E então, se estamos nos perguntando, você sabe o que? Nosso backend escala com o número de shards? E então apenas criamos um novo cluster de shard com o dobro do número de shards, esperamos o dobro do desempenho e executamos o mesmo teste. Novamente, se não tivermos um. Geralmente, não obteremos exatamente o dobro do desempenho, certo? Mas para se ter uma ideia, esta operação seria escalonada com o número de shards, e esta não.
Gaspard Petit (28:13): Então esse Operador é muito útil para nós porque nos permitirá simular esses cenários com muita facilidade. Há muito pouco trabalho envolvido na rotação desses clusters Kubernetes.
Gaspard Petit (28:23): E quando estamos satisfeitos com isso, vamos ao Atlas, que nos fornece a implantação dos clusters CloudReady. Portanto, não sou eu pessoalmente que faço isso, temos uma equipe de operações que cuida disso, mas eles se preparam para nós por meio do Atlas, preparam o banco de dados final que queremos usar. Colaboramos juntos para encontrar o número de shards, o tipo de instância que queremos implementar. E então o Atlas trata disso. Nós nos beneficiamos do auto-scaling de disco no Atlas. Geralmente, começamos com uma instância mais baixa, para configurar o banco de dados, quando o lançamento do jogo se aproxima, aumentamos o tipo de instância novamente por meio do Atlas.
Gapard Pett (29:10): Em alguns casos, notamos que o número de shards era insuficiente após o teste, e o Atlas nos permite fazer essas alterações bem perto da data de lançamento. Então, o que isso significa é que podemos ter uma boa estimativa algumas semanas antes do lançamento de nossos requisitos em termos de infraestrutura, mas se estivermos errados, não demora muito para ajustar e dizer: "Ok, quer saber? Não precisamos de cinco fragmentos, precisamos de fragmentos 10. " E, especialmente se você estiver antes do lançamento, não terá tantos dados. O Atlas leva apenas alguns minutos, algumas horas para reimplantar essas coisas e preparar o banco de dados para nós. O mesmo acontece nesses três estágios de ir local para testes de unidade com nossa própria imagem do Mongo. Temos um cluster Kubernetes para testes de carga que usam o Mongo Operator e, em seguida, usamos o Atlas no final para a implantação real na cloud.
Gapard Pett (30:08): Na verdade, Go quando o jogo está ficando antigo e a carga é previsível nele. E não é tão alto como costumava ser, movemos esse banco de dados internamente. Portanto, temos nossos próprios data centers. E, na verdade, compartilharemos instâncias Mongo para vários jogos. Por isso, co-hospedamos vários jogos em um único cluster, não um único banco de dados, é claro, mas um único cluster Mongo. E isso se torna muito, muito econômico. Podemos ver, por exemplo, se há vendas em um jogo, enquanto os outros jogos são menos ativos, é preciso um pouco mais de carga. Mas na próxima semana, outra coisa está em vendas, e eles meio que fazem a média nesse cluster. Então, jogos mais antigos, estou falando de jogos de quatro ou cinco anos tendem a ser movidos de volta para o local para custo-benefício.
Nic Raboy (31:00): Então, é ótimo saber que você pode ter a opção de trazer os jogos de volta quando eles ficarem velhos e precisar reduzi-los. Talvez você possa falar sobre alguns dos outros benefícios que vêm com isso.
Gaspard Petit (31:12): Sim. E ao mesmo tempo em que também está vinculado aos outros aspectos que mencionei. Não nos queremos encontrar com o MongoDB, temos opções. Então temos a opção Atlas, que é extremamente útil quando iniciamos um jogo. E é alto risco, certo? Se um incidente aconteceu na primeira semana de lançamento de um jogo, você quer todas as mãos no convés e o máximo de apoio possível. Depois de alguns anos, sabemos o tipo de erros que podemos ter, sabemos o que pode dar errado com o back-end. E geralmente o volume não é tão alto, então não precisamos mais desse tipo de suporte. E também há muita sobrecarga na execução de coisas na nuvem, se você estiver em um volume pequeno. Não há apenas o Mongo em si, há os próprios Pods que precisam ser executados em um ambiente de computação, há o tráfego que está contando.
Gaspard Petit (32:05): Então temos esse data center. Na verdade, temos vários data centers, temos a sorte de ser grandes o suficiente para tê-los. Mas nos dá essa opção extra de dizer: "Não estamos bloqueados à cloud, é uma opção estar na cloud com o MongoDB." Podemos executá-lo localmente em um Docker, podemos executá-lo na cloud, onde podemos controlar para onde Go. E isso tem sido um elemento-chave na arquitetura de nossos back-ends desde o início, na verdade, garantindo que todos os componentes que usamos possam ser virtualizados, trazidos de volta ao local para que possamos controlar localmente. Por exemplo, podemos executar testes e ter tudo controlado, não dependendo da cloud. Mas também temos a oportunidade de ter uma equipe externa analisando o projeto conosco nos momentos críticos. Então, acho que estamos muito felizes em ter essas opções de executá-lo onde quisermos.
michael lynn (32:56): Sim, isso é obviamente um benefício. Fale-me um pouco sobre a escala. Eu sei que você provavelmente não pode mencionar números e transações por segundo e coisas assim. Mas esse é claramente um dos desafios no espaço de jogos: você terá que enfrentar uma escala enorme. Você quer falar um pouco sobre alguns dos desafios que você está enfrentando, com o nível de escala que você está alcançando hoje?
Gapard Pett (33:17): Sim, com certeza. Na verdade, esse é um dos aspectos desafiadores do back-end, garantir que você não atinja um teto em algum momento ou em um teto inesperado. E sempre há um, você nem sempre sabe qual é. Quando nos preparamos para o lançamento de um jogo, independentemente do seu sucesso, temos que nos preparar para o pior, o melhor sucesso. Não saberia como frasear isso. Mas o melhor sucesso pode ser o pior caso para nós. Mas queremos ter certeza de que apoiaremos qualquer número de jogadores que surja em nosso caminho. E temos que estar preparados para isso.
Gaspard Petit (33:48): E dependendo dos cenários, pode ser extremamente caro estar preparado para o pior/melhor. Porque pode ser que você precise escalar demais imediatamente e garantir que seu teto seja muito alto. O ideal é chegar a um ponto intermediário em que você se sinta confortável, pois, se Go além disso, poderá se ajustar rapidamente. Então, você meio que compromete o custo do seu lançamento com o risco e chegar a um ponto em que se sente confortável dizendo: " Se eu acertasse isso e demorasse 30 minutos para me recuperar, tudo bem. " Ninguém se importaria, porque é um sucesso tão grande que todos entenderiam naquele momento. Esse teto deve ser bem alto na indústria de jogos. Estamos falando de milhões de usuários simultâneos que se conectam no mesmo minuto e fazem queries em seus dados ao mesmo tempo. É um número grande. É difícil, na verdade, até para a mente humana compreender esses números quando estamos falando de milhões.
Gapard Pett (34:50): são muitas solicitações por segundo. Portanto, ele tem que ser distribuído de uma forma que seja escalável, e essa também foi uma das coisas que percebi que o Mongo se saiu muito bem com os mongos e o mongod dividido em um cluster fragmentado, onde você tem praticamente quantos bancos de dados quiser. Você pode dividir a carga de trabalho em quantos bancos de dados quiser com os mongos, roteando-a para o lugar certo. Então, se você está atingindo seu limite com dois fragmentos e tem mais dois fragmentos, em teoria, você pode obter o dobro do volume de consultas. Para que isso funcione, você precisa ser cuidadoso, precisa fragmentar adequadamente. Então é aqui que você quer ter alguma experiência e ter certeza de que suas chaves fragmentadas estão bem escolhidas. Isso é algo que ajustamos ao longo dos anos por termos diferentes experiências com diferentes chaves de shard.
Gaspard Petit (35:41): Para nós, não sei se todos no jogo estão fazendo dessa maneira, mas o que parece ser a chave de fragmento mais intuitiva e conveniente é o ID do usuário, e nós o hash. Assim vai para... Cada perfil de usuário vai para um fragmento aleatório, e podemos escalar o mongo dentro de praticamente o número de usuários que temos, que geralmente é o que tende a subir e descer no nosso caso.
Gaspard Petit (36:05): Então, tivemos alguns projetos, tivemos clusters menores em um, dois. Praticamente nunca temos um fragmento, mas dois fragmentos, três fragmentos. E, em alguns casos, usamos até 30 plus shards, e isso nunca foi realmente um problema. O tamanho, em termos de Mongo, eu diria. Houve problemas, mas não foi realmente com a arquitetura em si, foi mais o padrão de consulta ou, em alguns casos, extrairíamos muitos dados no cache. E o cache não foi usado de forma eficiente. Mas sempre havia uma solução alternativa. E nunca foi realmente uma limitação do banco de dados. Portanto, o modelo de fragmentação funciona muito bem para nós.
michael lynn (36:45): Estou interessado em saber como você testa esse tipo de escala. Imagino que você possa duplicar os padrões de carregamento, mas deve ser difícil aproximar o número de transações por segundo em um ambiente de desenvolvimento. Você está aproveitando o Atlas para testes de carga de produção?
Gaspard Petit (37:04): Não. Bem, sim e não. Os testes iniciais são feitos no Kubernetes usando o Operador Mongo. Então é aqui que simularemos. Para uma operação, testaremos se ela será dimensionada com o tipo de instância? Então, adicionar mais CPU e mais RAM será dimensionado com o número de shards? Portanto, fazemos essa grade em cada operação que os jogadores podem estar usando com antecedência. Em algum momento, estamos certos de que tudo parece bem. Mas testar cada operação individualmente não significa que todas funcionarão bem, todas funcionarão bem quando forem misturadas. Portanto, a mixagem final passa pelo banco de dados de produção, se ainda não estiver sendo usado, ou por uma cópia que se pareceria com o banco de dados de produção no Atlas.
Gapard Pett (37:52): Então, criamos um banco de dados do Atlas semelhante ao que queremos usar na produção. E executamos o teste de carga final nele, apenas para obter um número claro com seus componentes reais, como será. Portanto, não é necessariamente o cluster final que usaremos, às vezes é uma cópia dele. Dependendo se estiver disponível, às vezes já há certificação em andamento ou o QA já está testando em produção. Portanto, não podemos acessar o banco de dados de produção para isso, então apenas giramos uma instância diferente dele.
Nic Raboy (38:22): Então, esse episódio tem sido fantástico até agora, eu queria deixá-lo aberto para você, dar a nós ou aos ouvintes, devo dizer, qualquer tipo de palavra de sabedoria de última hora ou qualquer coisa que possamos ter perdido e que você acha que seria valiosa para eles seguirem em frente.
Gaspard Petit (38:38): Claro. Então, talvez eu possa compartilhar algo sobre por que acho que somos eficientes no que fazemos e por que ainda estamos gostando do trabalho que estamos fazendo. E isso tem a ver um pouco com a forma como estamos organizados na Square Enix com as diferentes equipes. Mencionei anteriormente que nossa interação com a equipe do jogo não era tanto para ditar como o back-end deveria ser para eles, mas sim para atuar como especialistas. E acho que temos sorte de ter isso na Square Enix, onde nossa equipe de operação e nossa equipe de desenvolvimento não estão necessariamente atuando apenas como prestadoras de serviços. E isso também afeta o Mongo, a forma como integramos o Mongo em nosso ecossistema não é tanto em... Em parte, é o seguinte: "Por favor, forneça nosso banco de dados, certifique-se de que eles estejam saudáveis e funcionando e nos dê suporte quando precisarmos." Mas também se trata de aproveitar equipes diferentes como especialistas.
Gaspard Petit (39:31): Então, para nós, o Mongo é uma fonte de especialistas onde, se precisarmos de recomendações sobre fragmentos, padrões de consulta, até mesmo sabemos como usar um driver Java. Temos a chance de consultar especialistas do MongoDB e obter um feedback preciso sobre como devemos fazer as coisas. E isso se traduz em todos os níveis dos nossos processos. Temos a equipe de operações que, obviamente, monitorará e garantirá que as coisas estejam saudáveis, mas eles também atuam como especialistas para nos dizer como o desenvolvimento deve ser feito ou quais são as práticas recomendadas.
Gaspard Petit (40:03): A equipe de desenvolvimento de back-end faz a mesma coisa com a equipe de desenvolvimento de jogos, onde apresentaremos nossas recomendações sobre como o jogo deve usar, consumir os serviços do back-end e até mesmo como eles devem projetar alguns recursos para que sejam escalados com eficiência ou lhes diremos: " Isso não funcionará porque o back-end não escalará. " Mas atue como especialistas, e acho que a chave para nosso sucesso é garantir que cada equipe não seja apenas uma prestadora de serviços, mas também ofereça experiência para que cada equipe possa ser orientada na direção certa.
Gaspard Petit (40:37): Então essa é definitivamente uma das coisas que eu aprecio ao longo dos meus anos. E isso foi transferido da gerência para todos os desenvolvedores, onde temos essa mentalidade de atuar como especialistas para outros. Então, temos isso como modelo de engenheiros incorporados, onde temos alguns de nossos funcionários em nossa equipe dedicados às equipes de jogos. E a mesma coisa com a equipe de operações, eles têm os engenheiros embarcados dedicados de sua equipe dedicados à nossa equipe, garantindo que não estejamos em silos. Portanto, essa é definitivamente uma recomendação que eu daria a qualquer pessoa desse setor, certificando-se de que os silos sejam quebrados e que cada equipe esteja ensinando outras equipes sobre suas melhores práticas.
michael lynn (41:21): fantástico. E adoramos que os clientes estejam dispostos a fazer parcerias dessa forma e alavancar as equipes que têm essas práticas recomendadas. Então, Gapard, gostaria de agradecê-lo por passar tanto tempo conosco. Foi ótimo conversar com você e saber mais sobre como a Sqre Enix está usando o MongoDB e tudo mais no espaço de jogo.
Gapard Pett (41:40): Bem, muito obrigado. Foi um deleite.
Automatizado (41:44):Obrigado por ouvir. Se você curtou este capítulo, por favor curta e se inscreva. Tem uma pergunta ou uma sugestão para o show? Visite-nos nos fóruns da comunidade MongoDB em community.mongodb.com.
Avalie esse Podcast