@
Leobahia
Bem bacana o Podcast...esse assunto de cloud computing vai longe. Por ser parte do meu dia-a-dia, adoro discutir isso.
Eu não creio que uma arquitetura de cloud seria de grande ajuda para conter botters e cheaters...para ser muito sincero, não tenho conhecimento sobre esses jogos por streaming. Entretanto, esse tipo de arquitetura resolveria vários outros problemas existentes no jogo atualmente, principalmente no que se diz respeito a
ataques DDoS. Como eu sou uma matraca, vou explicar por cima (e de maneira grosseira) como funciona uma aplicação
* em cloud.
*Ao utilizar o termo aplicação, não estou me referindo ao software que você executa em seu computador. Estou me referindo aos sistemas que rodam em server-side. Assim, no caso do Tibia, me refiro aos servidores em si.
O Tibia é dividido, de maneira simplista, em client e servidor. O client fica recebendo informações do servidor constantemente, ou seja, tudo aquilo que você e o player que está ao seu lado veem no mapa (baseado em suas posições) o client está recebendo o servidor. Essa comunicação é extremamente rápida: no segundo entre você clicar em um item e arrastá-lo para outro sqm, essa comunicação já aconteceu dezenas de vezes.
Até onde sabemos, hoje, os servidores do Tibia são completamente monolíticos, ou seja, Pacera é um único servidor e todos os players nele conectados acessam exatamente a mesma máquina. Se 800 players estão conectados, existem 800 conexões abertas (supondo que seja apenas uma por player)...pode ser que haja algum tipo de replicação, mas ela é bem limitada. Quando rola algum tipo de ataque DDoS aqui, o servidor fica sobrecarregado e os players começam a sentir os efeitos na forma de lag e timeouts (vulgo, kicks).
Quando falamos em cloud, o foco é
alta disponibilidade, ou seja, é garantir que sua aplicação vai estar acessível, mesmo que esteja sob algum tipo de ataque ou que algum servidor ou disco quebre. Isso significa, basicamente, que você tem a sua aplicação sendo executada em diversos servidores diferentes, com diversas instâncias do seu banco de dados rodando simultaneamente.
Apesar das soluções de clouds parecerem caras, elas podem ter um custo muito menor do que manter um servidor único. Isso acontece por conta do sentido em que esses servidores crescem. Quando falamos em manter um servidor único para uma aplicação, conforme a demanda e quantidade de acessos aumentam, uma das únicas saídas é melhorar o seu hardware, ou seja, comprar mais memória e mais processadores. Isso se chama
escalabilidade vertical. Quando falamos em cloud, caso a demanda aumente, não vamos aumentar o hardware, mas vamos ligar outro servidor, o qual vai dividir a demanda com o primeiro, essa é a
escalabilidade horizontal. Tá, mas não é mais caro ainda ter duas ou mais máquinas? Não, pois ambientes cloud utilizam máquinas virtuais...logo, se você precisa de mais demanda para um determinado momento, você sobe mais algumas máquinas(e paga por isso de acordo). Quando o horário de pico passar, você desligas as excedentes. Empresas especializadas, como a Amazon, possuem servidores extremamente poderosos, capazes de manter centenas, se não milhares, de máquinas virtuais (cada um deles).
Essa comunicação tende a ser transparente para os usuários. Normalmente, existe um load balancer na frente dos servidores. Esse carinha é responsável por receber sua comunicação e passá-la para um dos servidores disponíveis para atendê-la. Mas e se o load balancer cair? Se ele cair, sua comunicação é interrompida, mas é bem difícil isso acontecer. No caso da Amazon (referência em cloud), por exemplo, ela fornece um load balancer com disponibilidade de 99.99999%. Isso significa que, caso seu balanceador fique offline por 3.15
segundos por ano, a Amazon será multada.
Agora, com todo esse monte de coisa de nerd que eu falei, onde eu quero chegar? Isso pode resolver problemas de latência por região, reduzir o lag, minimizar (em muito) ataques DDoS e reduzir o impacto em caso de resets. Como?
Antigamente eu jogava em Secura, e vou usar esse servidor como exemplo, um servidor Europeu.
Caso Secura estívesse em um ambiente cloud, o primeiro ponto seria: ele não seria um "servidor Europeu". Haveriam instâncias desse servidor na Europa, nos EUA e, por que não, no Brasil. Isso já garante o primeiro ponto: seria um servidor em que players de várias nacionalidades poderiam jogar tranquilamente, afinal, o balanceador jogaria as conexões para seu respectivo nó no país certo.
Um outro ponto que isso já garante: caso haja algum ataque DDoS, o hacker terá que derrubar vários servidores, em diferentes regiões. Isso é muito, mas MUITO mais difícil. Os players até poderiam sentir algum impacto, mas seria muito menor. Afinal de contas, se um ataque derruba o servidor que está rodando no EUA, os jogadores americanos passam a ser direcionados ao servidor Europeu. O próprio tráfego produzido pelo ataque já diluiria os jogadores em diferentes servidores. A latência poderia aumentar um pouco, mas o impacto é muito menor do que travar tudo e seu char morrer.
Além disso, esse tipo de estrutura também conta com bancos de dados distribuídos, ou seja, poderia haver um banco de dados em cada região e eles seriam sincronizados. Atualmente, o server save salva seus dados de D-1, ou seja, do dia anterior. Com várias instâncias de bancos de dados, você pode tirar uma delas em diferentes momento do dia para fazer backups mais frequentes sem que os players sintam o impacto.
Em resumo: seria um servidor onde não haveria qualquer segregação gerada por regiões (devido a latência) com menos ocorrência de ataques e mais segurança de backups.
Agora, por que a CipSoft não faz isso?
O Tibia (tanto client quanto servidores) são softwares antigos. Implementar soluções em cloud exigem vários cuidados e adaptações. Um exemplo clássico: quem trabalha com desenvolvimento/bancos de dados sabe que é muito comum utilizar ids sequenciais no banco de dados (1, 2, 3...) de acordo com a ordem em que os dados são gravados. Quando trabalhamos com bancos de dados distribuídos, existe a grande chance de duas instâncias gravarem um player (exemplo) com o ID 1500. Quando os bancos forem sincronizados, vai haver um conflito gigantesco. É necessário trabalhar com identificadores únicos (UUIDs)...quando isso vai para o banco de dados, fica mais complexo, pois há a preocupação de performance do banco. Existem soluções, como o Snowflake (desenvolvido pelo Twitter), mas não é trivial. Em casos de bancos de dados, os bancos relacionais nem sempre são a melhor opção...existem os bancos NoSQL, muito indicados para ambientes distribuídos, mas a alteração é muito brusca considerando a idade do software.
Seria ideal, mas infelizmente acho improvável.
O esforço para adaptar um software de 18 anos para uma arquitetura cloud é gigantesco...deve-se levar em conta as mudanças de tecnologia e como isso impacta no que já existe. Sei que muitos vão dar o rage de sempre dizendo "quem quer faz", "contrata mais gente" e o de sempre...mas, por experiência própria: é mais fácil construir do zero do que adaptar tudo isso.
Desculpem o texto longo...acabei me empolgando.