On 11/30/06, Nicholas Koranda <nkk@eml.cc> wrote:
> I have not been personally involved with the backend server side of a
> massive online game but I understand the general concepts of how they
> work. One of the costs associated with running a server farm is the
> inability to scale the cost of running the server farm with the scale of
> the load. For instance, if a game has 10,000 simultaneous users spread
> out over 20 servers, the load is (if the players are equally spaced) 500
> users per server. Some server farms can scale what regions they cover
> so that if groups of users merge into a smaller area, several servers
> can be used to break up the load (i.e. a 1000 x 1000 "grid" could be
> broken into two 500 x 1000 grids or some other way.)
>
> Now the problem occurs when there are still 20 servers and only say
> 2,000 users or how about if there is a huge "flaming sword of sheeba"
> contest and 25,000 users all log into to get a chance to win it. Adding
> more servers quickly can be a problem for two reasons: 1) You would
> have to have purchased them beforehand (inefficient and cost ineffective
> since you dont always use them) or 2) you would have to get some more
> when need arrises (at a cost of time and flexability (this is more of a
> long term solution since you cant react to spikes in the load.)
>
> So my thought is to use the Amazon.com S3 (Simple Storage Solution) and
> ECC (Elastic Compute Cloud) as the server base for a massive online
> game. The services allow you to only pay for what you use, including
> server time. For those that dont know, the ECC is a service that allows
> you to "rent" an instance of a server on the Amazon ECC. You basically
> upload an image of what the hard drive would be on a server and it is
> loaded each time you use it. You pay $0.10 an hour for each instance of
> the cloud. You also pay $0.15/GB storage and $0.20/GB BW (That is what
> the S3 service is.)
>
> Anytime your userbase increases or decreases to a threshold, another
> server instance would be fired up or shut down. You could load up an
> instance before hand as the load is increasing, or you could base it on
> user login data from previous days/times. The method you use to start
> and stop instances is not important, it is the fact that with these
> services you have a method to scale both updwards and downwards your
> server farm with the server load, providing a very efficient and cost
> effective way to handle the load of a MMORPG.
>
> Any thoughts?
Sounds like a plan to me. The only stick I can thrust into the spokes
is in regards to how the virtual servers actually perform in real life
with a customized communications protocol. Amazon is a web service,
and as a web service its priorities lies in ensuring fidelity of data
over speed of communication. A web shopper does not detect a one
second delay in their credit card verification process, but would
definitely notice if an extra zero was sent across the wire. By
contrast, an MMO is normally more concerned with keeping a low latency
real-time connection to the client, where the user wouldn't notice if
the mob they're fighting is at coordinate X+1,Y rather than at X,Y but
certainly does notice a one second long lag. Thus why many (?) MMO's
use UDP, while all web services uses TCP, for example. In my opinion,
the viability of Amazon's EC2 and S3 services for MMO use cannot be
determined until the MMO in question is up and running, as each
communication protocol will have its own priorities which may or may
not be in line with Amazon's model.