Hacker News new | ask | show | jobs
by Animats 1181 days ago
I'd seen a more useful paper on this subject, on how to organize your game servers for a big MMO. The most economical strategy was to own your servers for the base load, and go out for AWS for peaks. Running 24/7 compute bound work on AWS is at least 2x as expensive as owning your own co-located servers.
3 comments

You can buy reserved instances that are about half the price as on-demand, so it really depends on how long the peaks are.
Dedicated servers are 1/4 or less of price of on-demand (don't forget the bandwidth!!!).
And all you need to do is pay a sysadmin or two in pizza to operate them :-)

Dedicated servers are undoubtedly cheaper in some circumstances than even a well-managed AWS account. But you do need to account for redundancy (including staffing), scaling up, possibly geographic replication, etc.). Setting up a dedicated server is just the beginning and be sure to take into account all costs--as is the case on a cloud provider too of course.

You absolutely need experts to run your cloud aswell, and there are colocating services that offer staff on hand for hardware issues, you don't actually have to run an entire datacenter even if you run baremetal
I guess the latency between AWS and your data centre would have a negative impact on game performance.
I believe the idea is to spin new servers on AWS and and connect players directly to them instead of hopping via their own infra.

That’s way your profit margins on the AWS servers is lower than self hosted ones but at least you’re making money.

The latency is still a factor of the AWS players interact with the non AWS ones.
I don't know how MMOs do this at all, but I would assume that for an MMO to be scalable, you do some sort of population-based geometric slicing of the world, and then assign each slice to a server such that players communicate with the server for their slice and the server for adjacent slices that are in some sort of visible/soon-to-be-visible range. That would mean no interaction between the servers - just between clients and servers. It also means that servers can be smoothly scaled out by cutting one server's area into two servers.

Edit - And if a group of players raid a dungeon, the population of that dungeon is strictly limited, so you can park that raid on one server and don't worry at all about inter-player latency.

The latency critical stuff traditionally happens in dungeons or other instances, precisely to get those players on a shared physical server. You just have a fleet of servers that each can handle X instances, and have a queue in between. And conveniently player state can just be synced in the loading time before and after the dungeon.

The bigger world is handled by slicing it up, but you still have a lot of communication going on with central databases for stuff like inventory management, chat, quests, etc. so you would probably try to keep all that within your own server racks.

Depends on the details, but pick an AWS location near your DC. And/or pick a DC location near AWS.
Mind linking the said paper?