Os Worlds brasileiros já estão disponíveis!

Os Worlds BR já estão disponíveis!

A partir de hoje, inauguramos oficialmente quatro mundos de jogo baseados no Brasil!

Isso significa um ping melhor para os jogadores da região da América Latina, tornando a jogabilidade de alta intensidade muito mais viável. Derrote o Doom of Mokhaiotl, junte-se aos seus companheiros de clã em uma raid de alto risco ou dedique-se a treinar sua habilidade de Ladrão, tudo isso com menos interrupções.

Embora nossos novos servidores estejam localizados na América Latina, trata-se de uma região enorme e jogadores em alguns locais podem descobrir que ainda obtêm a melhor latência em nossos mundos nos EUA.

Se você não consegue ver a imagem acima, clique aqui!

Agora você poderá acessar os seguintes mundos:

• 692 - F2P

• 693 - Membros

• 694 - Membros

• 695 - Membros

Encontre os novos mundos de jogo brasileiros na sua lista de mundos, agora mesmo!

Lançar esse trabalho uma semana antes do Leagues significa que podemos abrir mais dois mundos de jogo dedicados ao Leagues para o lançamento do Leagues VI! Além disso, com a infraestrutura pronta, temos flexibilidade para adicionar mais, se for necessário.

A jornada até o Brasil não foi simples, então conversamos com a equipe de infraestrutura para saber todos os detalhes.

Os mundos de jogo baseados no Brasil estão chegando à AWS.

Isso parece simples, mas chegar lá exigiu várias mudanças na forma como operamos o Old School na nuvem e na forma como nossa rede se integra.

Os J-Mods de infraestrutura estão de volta com mais um post no blog da Spudworks. Desta vez, vamos falar sobre os mundos de jogo brasileiros, hospedagem na nuvem e por que fazer isso em 2026 é muito diferente de como era há 10 anos.

Como sempre, esta é a abordagem técnica. Queríamos dar um pouco mais de insight sobre o que precisou mudar nos bastidores para tornar os mundos de jogo brasileiros na AWS uma realidade, em vez de apenas uma boa ideia.

Hospedagem regional: uma história

Como estamos na Spudworks, vamos dar uma rápida volta pela história do Git.

Se você já está por aqui há bastante tempo, talvez se lembre de que costumávamos operar uma região extra no Leste dos Estados Unidos para o RuneScape:

Se você não consegue ver a imagem acima, clique aqui!

• Leste dos Estados Unidos 2 - Miami

Além disso, em 2014, tínhamos uma pequena presença em Incheon, na Coreia, e na Cidade do Cabo, na África do Sul, com nossos próprios servidores, incluindo o RuneScape World 51 e o RuneScape 106.

No fim das contas, decidimos não continuar com esses locais, principalmente devido ao custo em comparação com a falta de ganhos de desempenho que estávamos observando. No entanto, eles se mostraram uma experiência interessante, e definitivamente aprendemos com ela, inclusive quando, acidentalmente, redirecionamos todo o tráfego pela Cidade do Cabo!

Por que o Brasil, por que agora?

Por muito tempo, Miami foi nossa resposta para atender melhor a América Latina. Ficava mais perto da América do Sul do que a Virgínia do Norte, era mais simples de operar para nós e, na época, fazia mais sentido do que tentar montar nossa própria estrutura diretamente no Brasil.

Ao longo dos anos, analisamos regularmente a viabilidade de nos estabelecermos no Brasil, mas o problema era que, na década de 2010, hospedar-se diretamente lá era uma tarefa muito mais complexa: hardware, instalações, suporte, despesas operacionais e complexidade jurídica pareciam muito mais difíceis do que são hoje.

Então, Miami continuou sendo o meio-termo.

Embora saibamos que isso ajudou, também sabemos que teve um alcance limitado. Para muitos jogadores, a melhoria na latência em relação à Virgínia do Norte foi modesta, e não dramática, e, com o tempo, essa região fez cada vez menos sentido como solução de longo prazo. O hardware estava ficando obsoleto, levando a um aumento na taxa de falhas, e, na verdade, ele só estava rodando torneios de RuneScape e Deadman para o Old School devido à capacidade limitada.

Assim, em 14 de fevereiro de 2023, voltamos a nos concentrar em uma única região do Leste dos EUA, na Virgínia do Norte. Atualizamos todo o nosso hardware e expandimos nosso data center do Leste dos EUA para torná-lo o maior de todos. Isso trouxe hardware e equipamentos de rede consideravelmente mais rápidos, juntamente com uma arquitetura aprimorada para implantações mundiais, resultando em ticks de servidor muito mais confiáveis.

Mas o desejo de atender melhor nossos jogadores sul-americanos nunca desapareceu. Continuamos a investigar maneiras de levar a hospedagem do Old School para a região e poupar os jogadores da longa viagem pan-americana até nossas fazendas de batata na Virgínia.

No ano passado, em julho de 2025, realizamos uma pesquisa para avaliar onde vocês prefeririam que começássemos. Os resultados dessa pesquisa consolidaram nossa decisão de ir para o Brasil como nosso primeiro destino.

A Jornada para o Brasil

Uma das razões pelas quais os mundos brasileiros são possíveis agora é que dedicamos tempo para experimentar e investigar minuciosamente.

Em março de 2023, nossa equipe se dedicou a explorar a possibilidade de adicionar uma infraestrutura de nuvem brasileira ao nosso ambiente de produção como parte de uma Game Jam. A partir daí, isso deixou de ser uma discussão teórica e começou a se tornar algo que poderíamos realmente fazer.

Em outubro de 2024, executamos os mundos Old School 596 e 597 na AWS na Austrália como nosso primeiro protótipo de produção, com os jogadores podendo acessar e usar os mundos. Inicialmente, comparamos o desempenho de tick entre nossos mundos existentes e as instâncias EC2 x86 e ARM (graviton) na AWS.

Identificamos alguns ganhos de desempenho no ARM em comparação com o x86, bem como as mudanças no motor e na infraestrutura necessárias para executar essa configuração.

Entre aquele momento e onde estamos agora, duas coisas importantes aconteceram com base no que aprendemos ao executar o protótipo australiano:

• Fizemos grandes mudanças na infraestrutura de rede global da Jagex; e

• O Projeto Zanaris trouxe algumas melhorias no motor que ajudaram os mundos Old School a rodarem na infraestrutura em nuvem de forma mais nativa.

Desde novembro de 2025, os mundos Old School 596 e 597 estão rodando na AWS na região Leste dos EUA como mundos de recuperação em uma arquitetura mais recente, aprimorada com o que aprendemos sobre o que não funcionou no protótipo anterior. Agora temos dados confiáveis sobre o custo de execução de diferentes modos de jogo e atividades na AWS, bem como os ganhos de desempenho relacionados a isso.

Isso é importante porque o Brasil na AWS não significa simplesmente pular de um modelo de hospedagem antigo para uma região totalmente nova e torcer para que dê certo. Temos trabalhado constantemente nas peças necessárias para que os mundos Old School hospedados na nuvem pareçam parte do ambiente normal.

Não é nada espetacular e não aparece nas notas de atualização, mas é esse tipo de trabalho de base que torna novas regiões possíveis.

O que mudou na rede?

Se você se lembra da nossa postagem no blog em agosto de 2025, compartilhamos que tínhamos concluído totalmente a configuração de nossa infraestrutura com conectividade híbrida globalmente. Aqui está uma atualização do diagrama prático que compartilhamos para ajudar a ilustrar o trabalho e como ele mudou desde então.

A espinha dorsal era originalmente conectada por um VPLS e agora foi totalmente substituída pelo Direct Connect com SiteLink.

Então, o que isso significa?

Bem, o VPLS (Virtual Private LAN Service) basicamente permite que você configure uma rede que funciona como uma grande rede única. É por meio dela que nossos mundos de jogo e serviços de back-end se comunicam constantemente. Nós conectávamos cada um de nossos data centers a uma rede VPLS dedicada de um provedor. Ou seja, se algum dia sofrêssemos um ataque DDoS, nossos serviços ainda poderiam se comunicar e, mais importante, seu jogo salvo seria preservado sem interrupção.

No entanto, queríamos mundos de jogo na AWS e no local, então nossos serviços de back-end e mundos de jogo precisam ser capazes de se comunicar de forma confiável, independentemente de onde estejam localizados.

É aí que o Direct Connect com SiteLink entra em cena, permitindo-nos alcançar o mesmo resultado de quando usávamos nosso VPLS para anunciar nossas redes aos outros data centers via BGP. O BGP (Border Gateway Protocol) é um sistema que informa a diferentes redes “esta é a melhor maneira de chegar até mim”, para que os dados saibam para onde ir em grandes redes conectadas.

Configuramos a substituição da AWS com o SiteLink habilitado, já que ele depende do BGP para trocar informações de rede entre os sites conectados e a VPC da nossa rede AWS. Ele também atua como um recurso de plano de dados que permite que o tráfego flua diretamente entre nossos sites usando a AWS como backbone privado global da Jagex, ao mesmo tempo em que nos dá a capacidade de nos conectarmos aos nossos mundos de jogo e serviços de back-end na AWS em escala.

Agora, em vez de tratar as regiões de nuvem como complementos distantes, podemos conectá-las a um ambiente mais amplo de uma forma muito mais natural operacionalmente.

Com esse trabalho concluído, em princípio, é consideravelmente mais rápido ativar novas regiões. No entanto, isso não significa que sua região favorita esteja necessariamente "Em breve"; custos, considerações legais e o benefício total para os jogadores afetam quais regiões podemos oferecer.

AWS Cloud WAN

Para manter uma rede global no local e na nuvem com um ambiente AWS bastante extenso, utilizamos AWS Cloud WAN.

Em termos simples, a Cloud WAN atua como um hub de rede global gerenciado centralmente dentro da AWS. Ela nos permite definir como todas as nossas regiões e redes devem se conectar umas às outras em um único local, em vez de configurar cada conexão individualmente. Nos bastidores, ela ainda usa conceitos familiares como roteamento e segmentação, mas os envolve em um serviço gerenciado que lida com o trabalho pesado de manter tudo conectado e consistente. O Cloud WAN nos oferece uma maneira mais estruturada e escalável de organizar essa conectividade dentro da própria AWS. Em vez de pensar em termos de links ponto a ponto ou roteamento gerenciado manualmente entre regiões, podemos tratar o lado AWS da nossa rede como um backbone coeso com políticas definidas centralmente.

Isso se torna particularmente importante à medida que escalamos. À medida que adicionamos mais regiões ou serviços, não precisamos reestruturar a forma como tudo se conecta a cada vez. Em vez disso, estendemos o modelo de rede existente de maneira previsível. Isso reduz a sobrecarga operacional e torna a rede mais fácil de entender e gerenciar.

No entanto, isso não significa que todas as regiões sejam idênticas; cada uma terá suas próprias complexidades a serem contornadas.

Ao configurar nossos mundos de jogos no Brasil, tivemos que levar em conta o fato de que São Paulo (sa-east-1) é uma das poucas regiões que não oferece suporte à Cloud WAN ainda. Portanto, embora muitos de nossos modelos mais recentes tenham facilitado os mundos de jogos brasileiros, ainda tivemos que fazer um trabalho extra com o AWS Transit Gateway nessa região. Embora a nuvem facilite algumas coisas, foi necessário o trabalho árduo que realizamos nos últimos anos para tornar até mesmo os casos mais complexos agora mais práticos de uma forma que não eram antes.

Por que isso torna o Brasil viável?

Na época em que Miami foi escolhida, uma implantação do mundo de jogos no Brasil teria se parecido muito mais com uma construção regional pontual, com um custo operacional mais alto e menos integração com o resto da plataforma. Além de ser insustentável, isso teria proporcionado uma experiência de segunda classe para os usuários dessa região, o que não estávamos dispostos a aceitar.

Hoje, o quadro é diferente.

Agora temos:

• Um verdadeiro modelo de rede híbrida

• Experiência prática na operação de mundos Old School na AWS

• Mudanças no motor que fazem com que os mundos hospedados na nuvem se comportem de maneira mais natural do que nas tentativas anteriores

Junte tudo isso e os mundos de jogos brasileiros deixam de parecer um caso especial isolado e passam a parecer algo que podemos oferecer suporte adequadamente.

O que realmente mudou?

Se resumirmos tudo, os mundos de jogos brasileiros na AWS são possíveis agora porque várias vertentes diferentes finalmente se alinharam:

• Deixamos de depender de padrões regionais mais antigos que eram apenas soluções parciais.

• Agora temos um processo para mundos Old School hospedados na nuvem, feito em etapas, em vez de um grande salto de uma só vez.

• A rede passou de uma estrutura mais tradicional conectada por VPLS para um modelo híbrido conectado à AWS.

• Parte do trabalho do Projeto Zanaris ajudou o Old School a rodar na nuvem de forma mais natural.

• Fizemos o trabalho extra necessário para tornar os mundos de jogos brasileiros viáveis, mesmo sem a AWS Cloud WAN em São Paulo.

O anúncio dos mundos de jogo brasileiros é a manchete principal, mas por trás dela houve um trabalho considerável e iterativo de rede, nuvem, plataforma e motor que tornou possível levar os mundos de jogo brasileiros na AWS do quadro branco para a realidade.

Se você quiser ver mais desses aprofundamentos sobre como operamos a infraestrutura por trás do Old School, entre em contato conosco!

Você também pode discutir esta atualização no subreddit 2007Scape, nos fóruns do Steam ou no Discord do OSRS liderado pela comunidade, no canal #gameupdate. Para mais informações sobre o conteúdo acima, confira a Wiki oficial do Old School.

Mods Adad, Bash, Boko, Cky, Drax, Haydon, Ibex, Kraken, Maniac, M0iqp, Qwert, Roman, Titus, Vallcore, Vxp ... e🐹

Os J-Mods de Infraestrutura

E é isso, galera do Oldvicios. Esse artigo foi traduzido por nossa equipe e estamos abertos a feedback, de modo a trazer um conteúdo cada vez melhor para a comunidade BR.