One of the biggest technical challenges of running an online
business is how well they are able to handle the scalability requirements. The Load traffic pattern keeps varying for online
businesses and accordingly they will have to scale and maintain the acceptable
performance levels. Since the Traffic
patterns are fluctuating in online business, they either tend to under
provision and loose customers (or) over provision and waste hardware + costs.
This problem is well illustrated in the below diagrams.
Business usually makes detailed capacity planning and large
upfront investment in their hardware and software. This HW/SW’s are usually provisioned
with fixed capacity.
Many times because of variations in capacity planning and usage
predictions, you can observe that HW/SW capacity is underutilized. This is
because in reality the actual demand may not be uniform with your predictions. The
systems are utilized well during peak period but lie idle most of the times
when the peak period is over. This
leakage is illustrated in the below diagram in Grey shades.
On the other hand, sometimes online businesses totally get
their predictions wrong and under provision their HW/SW. This is a usual
occurrence during holiday seasons and campaigns where one cannot predict the
user traffic accurately. Though the business provision 4X more capacity during these
period as buffer, still there are lots of chances that they get traffic more
than expected. In case the traffic exceeds, users can experience degraded
performance or altogether cannot access the site itself sometimes. Companies
can lose customers and potential business opportunities because of this
mismatch. This scenario is illustrated as grey shade in the below diagram
If businesses can closely align their load requirements and
capacities then above scenarios can be countered efficiently. To solve this, we
need an elastic and auto scalable infrastructure, which can be automated to
expand and collapse depending upon the load traffic. Let us explore in AWS Cloud
computing context how this problem can be solved.
Auto scaling service was introduced by Amazon Web services especially
to balance this problem by increasing/decreasing capacities automatically
depending upon the traffic.
Let us explore few Load Volatility patterns and how Amazon
Auto Scaling can be used to reduce leakages and save cost.
Scenario 1: Daily
Spikes-Valley
Daily Spikes and Valley pattern can be best illustrated by
the below diagram.
This pattern is usually observed by ecommerce companies
which have peak usage for 12 hours between 8:00 am to 8:00 pm in a day and rest
of the day the capacities are usually under-utilized. Imagine you are running
20 X m1.large for you web/app tier and they are fully utilized during peak
hours. During the non-peak period the
load decreases gradually and ~25 % utilization overall is observed in the
nights. Since only 25% utilization is
observed in nights if you can reduce your capacity to 5 EC2 web/app instances
in an automated way it will save infra + labor costs. Let us calculate the savings one can achieve
by introducing Amazon Auto Scaling into this scenario:
Formula: Number of EC2 X current cost of m1.large (0.24
USD) X Hours
Without Cost Optimization
|
|
20 X m1.Large X 744
|
~3572 USD per month
|
Cost Optimization with Amazon Auto Scaling
|
|
20 X m1.large X 372 (hrs)
|
~1785 USD per month
|
15 X m1.large X 124
|
~446
|
10 X m1.Large X 124
|
~298
|
5 X m1.large X 124
|
~149
|
|
~2678 USD per month
|
Savings: Using Amazon
Auto Scaling you can save ~25 % leakage a month in this scenario
Image source: AWS
Scenario 2: Weekly
Fluctuation
Weekly Spikes and Valley pattern can be best illustrated by
the below diagram.
This pattern is usually observed by online ticketing companies
which have peak usage for 4 days week and normal -> under-utilization other
days of the week. Since the load is fluctuating in a week, these companies
cannot afford to lease capacity weekly. They usually plan their capacity based
on the peak load traffic and provision their infrastructure. Since the entire
infrastructure is running all days in a week, they will be wasting resources
during the normal days.
These dynamic workloads are very good use case for Amazon
Web Services and Amazon Auto Scaling. Let us explore this scenario in detail
below. Imagine the ticketing company needs 20 m1.large ec2 instances to handle
their peak periods. Instead of running 20 X m1.large EC2 instances satisfying
your peak capacities all the time, you can run 5 EC2 instances for the normal
days and Schedule an auto scale out to 20 EC2 instances before the peak days of
the week. During the normal or peak days of the week, if the load traffic
exceeds your capacity planning you can still automatically add more EC2
instances into your fleet. Since 3 of
the 7 days your instances are under-utilized (+) 8-12 hours under-utilization
(late nights) during the peak days as well, using amazon auto scaling and
dynamically expanding/collapsing the web-app tier will save lots of cost to the
company. Let us calculate the savings one can achieve by introducing Amazon
Auto Scaling into this scenario:
Without Cost Optimization
|
|
20 X m1.Large X 168
|
~806 USD per week
|
Cost Optimization with Amazon Auto Scaling
|
|
20 X m1.large X 48 (hrs)
|
~230 USD per week
|
15 X m1.large X 24
|
~87
|
5 X m1.large X 96
|
~115
|
|
~432 USD per week
|
Savings: From the
above calculation you can observe that using Amazon Auto Scaling ~25 % leakage
can be saved in a week.
Scenario 3: Seasonal
Spike scenario
Seasonal Spikes pattern can be best illustrated by the below
diagram.
This pattern is usually observed by online travel/ecommerce
companies which have peak holiday period for 3-5 months with heavy utilization
and rest of the year with normal/ under-utilized capacities. Companies
traditionally used to buy or lease capacities well before the season and spend months
provisioning them before the holiday season. Whereas Amazon Cloud world, though
you can launch instances on demand, still some companies have this traditional
mind set and run their infrastructure with peak capacity throughout the year. Reasons:
sometimes it is because of the bad application/infra architecture and at times
it because of IT team’s inadequate knowledge in AWS infra. This is a complete
waste of resources and will eventually lead to leakage in cost.
Imagine for serving your peak traffic during holiday season you
need 20 m1.large web/app instances, instead of having them running for whole
year, you can automatically scale them down post the season gradually in Amazon
infrastructure.
Using Amazon Auto Scaling you can schedule gradual increase
of EC2 instance capacity 2 months before the holiday season and gradually
decrease capacity 1-2 months post the peak season. During the peak season if there is unpredictable
increase in traffic auto scaling can still increase the EC2 fleet dynamically to
handle the dynamic load. This approach avoids both cost leakage and lost
opportunity cost for business. Let us calculate the savings one can achieve by introducing
Amazon Auto Scaling into this scenario:
Formula: Number of EC2 X current cost of m1.large (0.24
USD) X Hours X months
Without Cost Optimization
|
|
20 EC2 X m1.Large X 744 hrs X 12 months
|
~42,854 USD
per year
|
Cost Optimization with Amazon Auto Scaling
|
|
20 X m1.large X 744 X 4
|
~14,284 USD per year
|
10 X m1.large X 744 X 2
|
~3571
|
5 X m1.large X 124 X 7
|
~6249
|
|
~24,105 USD per year
|
Savings: Using Amazon
Auto Scaling you can save ~43 % leakage over a year in this scenario
Other Tips
Cost Saving Tip 1: Amazon SQS Long Polling and Batch requests
Cost Saving Tip 2: How right search technology choice saves cost in AWS ?
Cost Saving Tip 3: Using Amazon CloudFront Price Class to minimize costs
Cost Saving Tip 4 : Right Sizing Amazon ElastiCache Cluster
Cost Saving Tip 5: How Amazon Auto Scaling can save costs ?
Cost Saving Tip 6: Amazon Auto Scaling Termination policy and savings
Cost Saving Tip 7: Use Amazon S3 Object Expiration
Cost Saving Tip 8: Use Amazon S3 Reduced Redundancy Storage
