Just
recently i was asked to develop a massively scalable webservice for a
client called FADU Bakery shop ;). I am also a software developer
like you who does less but only i know!!. I explored the concepts
involved in making a web service scalable and i am just trying to
sharing it with you. Have fun and hope you like it. Your comment is
always welcomed!!
When
we talk of scalability it involves:
1.
Application server scaling.
2.
Database server scaling.
3.
Memory scaling- Cache and MQ.
I
am trying to explore each concepts respectively.
Application
server scaling by cloning:
Usually
our application servers are hidden behind a black box called load
balancer. This load balancer evenly distribute the load onto the
group of hidden app server with high probability using the intelligent algorithm based on time-stamp or loads. That means if
User Mrs Ssoni interact with your service for the first time she may
be served by server 5 and in second request is served by server 2 and
may be in third request it again come to server5.
Ssoni
always get the same result of her same request independent of which
server she lands on. That gives us the first golden rule of scaling
-'Every server should have same code base and should not store user
data like profile pic or session data'. Otherwise imagine if Ssoni
has checked some milk bread on server1 but in second request server
is changed and the the milk-bread is not in her basket :(.
So
what next... where to store this user data?
One
among many solution is to store this user data in a centralize data
storage accessible to all the application server or store this user
data by scaling the memory of load balancer. It could be a database
in load balancer or the persistence cache like redis or memcached.
Please dont use the file based caching more frequently as it make
auto scaling and cloning pain.
So
far so good...But what about deployment on multi server?
How
do you assure that the code changes is effectively on all app server.
Dont worry this is tricky problem and already solved by multiple tools
like Capistrano or you can write own script for that to show you are
not lazy as me.
Now
we are serving the same codebase from all app servers, we can now
create an image file from one of these servers (AWS calls this AMI -
Amazon Machine Image.) Use this AMI as a “super-clone” that all
your new instances are based upon. Whenever you start a new instance,
just do an initial deployment of your latest code and you are ready!
Is not it simple enough...?
#database
and memory will be in next blog ... soon!!
#Names
are virtual.
Comments
Post a Comment