4. Option 1: Traditional Multiple App and DB Read Instances Auto Scaling Performance Fail-over Geographical Fail-over Maintenance Cost and Set-up Backups Multiple Read Instances Self setup DB w/ multiple reads No High No No Very High Yes Yes
6. Application Cloud Options Performance Load Balancer Auto Scaling Geographical Fail-over Maintenance Cost and Set-up Provider Profile EC2 instances (recommend) High Yes Yes Yes (set one instance in East and West coast) Medium High Strong Heroku High Internal Handling No No Low BlueBox High Yes Yes No Low Low Internal Handling No No Low Medium
7. Database Cloud Auto Scaling Performance Fail-over Geographical Fail-over Maintenance Cost and Set-up Backups Master-Master Network Latency Multiple Reads Instances Provider Profile Amazon RDS (Cloud DB) No Medium-high Yes No High Yes but weekly down time No ~500ms per transaction Manual Strong XeRound (Cloud DB) Yes High Yes Yes Low Yes Yes ~500 ms per transaction Yes Medium Heruko No High Yes No Low Yes No Low No Medium Self setup DB w/ multiple reads No High No No High Yes Yes (limited to 2 instances) Not Recommended None Yes Strong
8. Suggested Architecture: Two (or more) Geographically spread EC2 instances for Application layer with Xeround for Database Layer
9.
10.
11.
Editor's Notes
We worked with following priorities High: a) Scalability - especially on DB layer b) Easy maintenance as we do not want to keep an admin team /guy for server side c) Geographical fail-over - high availability Medium: a) Network latency - we think about 500 ms is acceptable) Auto Scaling on app layer processing on application layer is less than DB. 2 large servers should be enough with buffer in computing power for load spikes c) Cost - while we want to be efficient but we do not want to optimize scaling too much so we loose grip on it But let's discuss!
Why Amazon-RDS is here: While we did not recommend Amazon RDS at first place, the idea was to discuss different options we studied for knowledge sharing reasons
Why Two Amazon EC2 Large Instances: a) Large instance comes with 7.5 G memory. The cheaper option is only a small instance with 1.7GB of memory and that is not recommended for enterprise Ruby to work b) 2 Large instances will suffice for spikes of load to us. Current production is an Extra Large instance. It holds DB and Ruby and so far have not reached 10% resource utilization till today. c) If DB is externalized, large instances will be good enough to handle Ruby with a cache mechanism enabled
We worked with following priorities High: a) Scalability - especially on DB layer i.e. performance and failover b) Easy maintenance as we do not want to keep an admin team /guy for server side c) Geographical fail-over - high availability d) Backups: e) Auto Scaling Medium: a) Network latency - we think about 500 ms is acceptable) c) Master-Master: d) Multiple Read instances Low:- Provider Profile But let's discuss!
No Autoscaling on Ruby level here, why? We can look towards adding a third server launch based on auto-scale policies. However a) EC2 auto-scale launches an instance based on AMI. There is additional maintenance to keep an updated AMI as server code enhances over time. b) Sometimes (not often) instance launch based on AMI fails on EC2 Heroku provides failover in this case.
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)