So I'm digging into AppFog's pricing sheet and I am struggling to figure out which one I need. here
Several questions
What is a service instance?
How do I somehow translate "service instance" to web traffic capabilities?
I am deploying a web app soon and looking at something to handle serious traffic (around a million users a month)
Being in a similar situation as you I think that a possible hint is the Pagodabox traffic visualizer. Also from one of the Pagodabox user stories I've concluded that having 16 service instances with 400 MB RAM each can handle 1M users (assuming that you have a reliable DB, and probably using Memcached).
(In AppFog the Services menu in the admin portal is really misleading - count instances in the Applications menu)
Related
We have EC2 instance hosting a web application and another RDS Server with SQL Server. Both are in US-WEST-2 region. The web site has a single page with button. When user clicks the button it UPDATES a table using a stored procedure. This update is not a complex updates, it selects a single row based on criteria and then updates that row. However table has more than 200K rows.
When users from the US access application they don't seems to have any issue. However, we have couple of users access the application from Africa. Users from Africa,however experience slow access and for them page crash every now and then.
When i checked the log, it always SQL timeout. Total number of users from US and Africa are not more than 10 so even if all clicked the button at the same time SQL Server should be able to handle 10 users.
(On our dev server I have done load testing with 100 users and I never got SQL timeout)
I understand that there will be latency for Users from Africa while accessing application. However, i am not able to understand why only those users seems have SQL timeout issue?
Is there any settings/configuration in AWS that we need to check for cross region requests? Does EC2 handles request differently when it comes from different continent/region? I understand its hard to pinpoint exact problem here but I am looking for suggestions especially related to AWS configuration for cross region requests.
I am at the beginning of a large migration from a single monolithic web service to a collection of microservices using Spring Cloud/Spring Cloud Netflix. Through my research of microservices I understand that the lines of demarcation between services should mirror the separations of concerns between them. An additional factor affecting separation is which services are required to scale individually.
As a concrete example, depending on the level of granularity desired, a microservice environment could end up like this:
Accounts (containing Signup, Login, Profiles, etc.)
Store (containing Products, Payments, Reporting, Inventories, etc.)
Chat/Social (containing chat rooms, user statuses, etc.)
...
Or it could end up with each of the areas of concern in brackets represented by their own microservice, e.g:
Accounts
Signup
Login
...
I believe there is a preference in the microservices community for the second approach, and I tend to agree. However, the issue I have is one of hosting and resource limitations.
In the migration I would like to streamline the provisioning of resources and the installation of updated services. Since we use the AWS stack, Elastic Beanstalk seemed like the perfect choice. While researching Elastic Beanstalk though I was rather disheartened to discover that there was a limit of 25 applications per account. Not only that, but EC2 has a limit of 20 instances per region per account. It seems like a microservice architecture will hit that limit very quickly, especially when you add multiple environments (staging and production) for each service into the mix, let alone websites and internal tooling.
With all of the amazing content that I've seen around the web regarding microservices, I'm surprised and somewhat disappointed at the lack of information regarding the actual hosting of microservices beyond the development of them. Have I missed something? Is there any information about deploying more than a couple of microservices on AWS?
It is my understanding that Netflix use AWS for their own microservice hosting, beyond requesting additional resources from Amazon and throwing money at it, are there other solutions? Would their Asgard tool help with this issue (possibly by handling the sharing of instances between services) or would it result in the same outcome?
As mentioned in the above comments, AWS will raise your limits if you have a legit use case - why wouldn't they? they are in the business of selling you services.
But since you have asked for suggestion other than increasing those limits, and since you are in the early stages of designing your solution, you should consider basing part of your micro-services architecture on Docker or another container/container like service (my own preference would be for the AWS's container service). Depending on the nature of you solution, even within the limits of 20 EC2 instances (per region), if you had large enough instances running you could fit dozens (or even hundreds of lightweight) docker images running on each of those allocated 20 instances - so potentially hundres or thousands of walled off micro-services running on those 20 EC2 instances.
Using an entire EC2 image for each of many micro-services you may have may end up being a lot more expensive than it needs to be.
You should also consider the use of AWS Lamba for at least portions of your micro-service architecture - its the 'ultra-micro service' tool also offered by AWS.
I'm about to get an Amazone ec2 account for my 4 e-commerce websites. Sometimes there is a big traffic or i have to make a lot of queries to generate some products feeds.
But there is something i can't figure out about this system : Why there is different instances specs ?
I mean if i pay per hour, then why don't i get the smallest instance spec, and if needed the auto-scale will make 2 or 100 instances to deal with the traffic.
So can someone advice or explain why should i or shouldn't do what i said above ?
And why there is different instance sizes ?
Thank you
Not all applications are same, the number of requests these web applications handle quite different, basically Amazon AWS provides various flavors of virtual servers http://aws.amazon.com/ec2/instance-types/, some are best suitable for E commerce websites with predictable bursts, blogs with less usage, Compute intensive apps, Media Streaming Servers which requires higher RAM etc.
You decide the best suitable type and size of the virtual server for your application to begin with and then scale up and scale down based on the load. AWS provides reference use-cases and best practices here http://aws.amazon.com/architecture/ to architect elastic, scalable and fault tolerant web services.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 days ago.
Improve this question
I am extremely new to Amazon Web Services. I would sincerely appreciate any help on finalising the architecture and arriving at a costing schedule. I am working on designing a AWS based solution for a dynamic website that we are designing. To begin with I need to have 2 High CPU Medium Utilisation EC2 instances (both will act as web servers), 1 High CPU Medium Utilisation EC2 instance for my database which will be Postgre SQL and 1 High CPU Medium Utilisation EC2 instance to serve as a read replica for my database. I will also be having a considerable volume of static content like images, videos or just .doc files for which I am contemplating using an S3 bucket. So, my website will be a dynamic + static kind of a website. I am expecting a rapid exponential scale up of users from 0 to say for example 1 million in a year. Hence I will need to scale up my EC2 combos (as described earlier) according to traffic. I am contemplatng using a CloudFormation stack for rapidly scaling my deployment. Also, to efficiently route traffic I will be using a single ELB to start with. Also, I would want to vertically partition my database based on user id's. For example, user ID 1 - 2000 on one EC2 database instance users 2001 to 4000 on second EC2 database instance etc... I will be auto scaling only the web server EC2 instances while my database EC2 instances will have a 100% uptime
My questions are:
What should be my auto scaling strategy for the web server EC2 instances and how do I know what will be the monthly costing when the scaling is so dynamic. I mean is there any way to predict so that I can do a cost break even analysis?
Do all the EC2 instances (web server and database) necessarily need an EBS backing or will Ephemeral storage suffice? I believe that for the database EC2 instances I will need an EBS backing. What about the web server Ec2 instances?
Suppose I end up scaling up to 100 EC2 instances. Will just one ELB suffice or do I need multiple ELBs?
How do I analyse as to how many HTTP requests can one High CPU Medium Utilisation EC2 instance handle before a breakdown?
Can CloudFront be used to host this kind of a dynamic + static site or is it used only for static sites?
Please help me with these questions as I have no clue on cloud solution architecting...
Thanks...
Vikram.
Here is a white paper we (RunSignUp) wrote about how we scaled on Amazon. Our use case was handling opening of an online race registration where 50,000 runners would want to sign up in less than 10 minutes. This shows how we configured everything including settings as well as some of the code we developed. We basically had the same issues as you and did not find anything that had a full use case of how to build a scalable app and how Amazon was used to scale with it. Hope it is helpful.
A quick attempt at an answer to get you started;
#1 is too big to answer without writing a book, it has too much to do with the system and its design to answer in a generic way.
#2 You'll definitely want backing for your database. The web servers on the other hand are probably better off with ephemeral storage, the more stateless/setup free they are, the easier to create/destroy instances dynamically.
#3 As far as I know, there's no upper limit on the number of machines "attached" to a single ELB. Under extreme load, you may experience slightly lesser latency if you split your site over multiple load balancers. You'll find more info that you can map against your actual architecture here.
#4 Only load testing of your system can tell you that.
#5 From the Cloudfront page;
Amazon CloudFront can be used to deliver your entire website, including dynamic, static and streaming content using a global network of edge locations.
In other words, its architecture does not prevent you from mixing static and dynamic content on your site.
The company I work for built and hosts a web app used by our customers and I am interested in creating some kind of external monitoring page (similar to trust.salesforce.com) that users can go to to see the current state of our servers/app. I know there are tons of different 'monitoring' services out there but I want to create the service myself, to have complete control and customization. Obviously, the service would have to be hosted in a different location and data center than the app itself. One thing I am concerned about is that if I just choose a different host in a different location, if that host goes down for any reason (power failure, server failure, or even ISP failure) the monitoring software is down. For this reason, I am thinking of hosting the monitoring app on an amazon EC2 instance. With their elastic IP feature, if for some reason the data center or point where the instance is running fails, I can just create a duplicate instance with the same data (but in a different location) and everything would work fine still.
Does this sound like a feasible plan? For even more security, I was thinking of creating 2 instances in different locations and monitoring from both of them. If one instance fails, the other would still be up. Obviously, one instance has to act as the actual web host for the monitoring page. Is it possible programatically for one instance to switch the elastic IP over to itself if it detects the other instance has failed for any reason?
I know there's a lot of different things involved in this question, I'm just looking for feedback regarding ANY of it...
If you've made it this far, thanks for taking the time to read this!
What you are talking about is a complicated solution for a complicated issue. I think you are on the right track with using something like Amazon's EC2 to reduce the chance of your monitoring app of going down. Also, you could develop it yourself but there are a great deal of free monitoring solutions out there like Nagios that will do everything you are asking for and is highly extensible so you can spend your time making it look and feel like you want while leaving the more complicated portions under the hood to software that is tried and tested. The worst thing would be for you to have a bug in your software that shows something as up when it is actually down. Based off of what you are talking about doing, I would assume that would be a huge issue.
Instead of using an elastic ip - which is only assigned to one instance, consider using the Elastic Load Balancer http://aws.amazon.com/elasticloadbalancing/ which then can route over instances in any of the availability zones. This way AWS manages taking instances in/out of the pool if they become unavailable for some reason and you do not have to spend time 'moving' the Elastic IP around. It is then easy to assign your monitoring cname to the ELB hostname.
I think RandomBen's idea of using Nagios on your instances is a good one because then you do not have to recreate all the functionality in Nagios. You then spend development time setting up the system and customizing the look and feel to your needs.
Also, if you can use MySQL, you should consider using RDS http://aws.amazon.com/rds/ although you will need to pay transfer fees if you have servers outside of a region accessing the RDS in another region.