Part 3: Cost of Latency Series:Sample technical architecture using Route53 LBR

Complexities and Best Practices behind Geo Distributed + R53 LBR

Let us take a simple Geo distributed online app stack and explore the technicalities and best practices a bit:

DNS and CDN Layer: Configure Route 53 to manage the DNS entries,map Domain Names to CloudFront distributions to and Latency Based Routing entries. LBR records point to the Amazon Elastic Load Balancer's endpoint in Europe and Singapore. Amazon Route 53’s Latency Based Routing (LBR) feature will route Amazon CloudFront origin requests to the AWS Region that provides the lowest possible latency. Internally Amazon Route 53 is integrated with Amazon CloudFront to collect latency measurements from each Amazon CloudFront edge location, resulting in optimal performance for origin fetches and improving overall performance

Load Balancing Layer: Amazon Elastic Load Balancing (ELB) is used as the Load Balancing layer. ELB can elastically expand its capacity to handle load during peak traffic. Amazon ELB should be configured with SSL termination @ Apache Backends, for meeting Security and Compliance in case sensitive information gets passed. Round Robin Algorithm is ideal for most scenarios. ELB should be configured to load balance across Multiple –AZ inside an Amazon EC2 Region. For more details about architecting using ELB refer http://harish11g.blogspot.in/2012/07/aws-elastic-load-balancing-elb-amazon.html

Web/App Layer: Apache Tomcat EC2’s are launched from S3 backed Linux AMI’s in Multiple-AZ’s. Logs periodically shipped to S3. Amazon Auto Scaling can be configured based on CPU or custom metrics to elastically increase/decrease the EC2 instances across Multiple AZ (recommended approach for Scalability and HA). ELB, Amazon Auto Scaling, CloudWatch and Route 53 work together. Session State is synchronized on MemCached. For more details on Amazon EC2 Availability Zones refer http://harish11g.blogspot.in/2012/07/amazon-availability-zones-aws-az.html

Solr Search Layer: Solr Search Instances are launched as EBS backed AMI’s. Solr EC2 can be replicated between Multiple –AZ’s or sharded inside an AZ depending upon need. High Memory instances with RAID levels (EBS Striping) + EBS optimized + Provisioned IOPS give better performance on AWS. Periodic Snapshots are taken and moved across regions. Sync Solr and DB periodically. For more details on Solr Sharding refer http://harish11g.blogspot.in/2012/02/apache-solr-sharding-amazon-ec2.html

Database Layer:

If the use case demands the Data to be localized inside an Amazon EC2 region then one of the following approaches are recommended:

• ·   RDS with Multi-AZ for HA, HAProxy Load balanced RDS Read Replicas across Multiple AZ’s for Read scaling are recommended approaches
• ·   MySQL Master with 1-2 Slaves spread across multiple AZ’s inside a Region , RAID 0 with XFS + EBS optimized + PIOPS for performance

If the use case demands the unidirectional Data synchronization across Amazon EC2 regions then:

• MySQL Master can sync data to a MySQL Slave in another Amazon EC2 region. Data can be sent over SSL or clear according to the requirements. 
• If the MySQL is inside VPC (private subnet) then IPSEC tunnel should be established across 2 Amazon EC2 regions for communication.

If the use case demands the Bi directional Data synchronization across Amazon EC2 regions then:

• MySQL Master-Master across regions and Master-Slave inside Regions can be configured. Though the bi directional data synch can be achieved, transactional integrity will become complex. Overall this model is not very efficient when the number of AWS regions increase.
• Usually the best practice is to streamline and avoid bidirectional sync and expose the function as common data web service that can be consumed over web. This way the Geo distributed applications in both the Amazon EC2 regions can consume that function for information.

Note: Geographically distributed Database is a hot field and lots of stuff are happening/emerging everyday like Google Spanner, Yahoo PNUTS, NuoDB, TransLattice Elastic Database, Cloudant, ClearDB etc. In coming days you will be using these systems which will make your life easier for architecting Geo Distributed applications. I also hope AWS product team comes with solution for this Geo distributed database problem.

Caching Layer: Use MemCacheD/ElastiCache for storing Sessions, results of Heavy queries, frequently used queries and complex queries of DB/Solr and thereby significantly reducing the database load . ElastiCache cannot be distributed over AZ. MemCacheD over Amazon EC2 with Multi-AZ distribution is recommended for website which heavily relies on Caching Layer. Cache need not be replicated across regions, in case needed you need to sync Master/Slave DB's replication with MemCacheD to ensure some consistency.

Storage Layer: S3 for storing Images, JS and other static assets. S3 can be the CloudFront origin. All logs, user uploaded files will be synched to S3 in Amazon EC2 region. 

View Full Detailed article at http://harish11g.blogspot.in/2012/09/geo-distributed-route53-lbr-latency.html

Part 2: Cost of Latency Series: Welcome to Geo Distributed Architecture using Route53 LBR

Welcome to Geo Distributed Architecture (Using Route53 LBR)

In this architecture, the web/app infrastructure of the XYZ Airlines is geo distributed across multiple AWS regions (example Singapore, Japan, Europe etc). 

User requests originating all around the world are directed to the nearest AWS region or AWS region with lowest network latency (more precisely). For example, suppose you have Load balancers in the Singapore, Japan and Europe Amazon EC2 region and we have created a latency resource record set in Route 53 for each load balancer. An end user in Dubai enters the name of our domain in their browser, and the Domain Name System routes their request to a Route 53 name server. Route 53 refers to its data on latency between Dubai and the Europe EC2 region and between Dubai and the Singapore EC2 region. If latency is lower between Dubai and the Europe region( most of the times), Route 53 responds to the end user's request with the IP address of your load balancer in the Amazon EC2 data center in Europe EC2 region. If latency is lower between Dubai and the Singapore region, Route 53 responds with the IP address of the load balancer in the Amazon EC2 data center in Singapore. This architecture rapidly cuts down the latency and gives the user a better experience. Also in case one of the regions is facing network problems, the requests can be routed to alternate low latency region achieving High Availability at overall website level. Though this architecture has benefits it comes with various complexities depending upon the use case and technical stack used, we will uncover some of them in this article.

If the XYZ airline follows GEO distributed architecture and has data centers in Singapore, Japan and Europe, let us see what it takes as the roundtrip latency measurements to access their website:

The XYZ airlines website is hosted on multiple AWS region with LBR configured	From Japan (ms)	From Germany(ms)	From Malaysia (ms)	From Rio (ms)
	12	21	30	75

Note: The above measurements are not constant and may keep varying every few seconds.

From the above table we can observe that using the Geo Distributed architecture the HTTP/S and AJAX calls are delivered from the AWS regions with lowest latency (usually nearest region), the round trip latency measurements have significantly dropped and overall performance has increased for the users.

View Full Detailed article at http://harish11g.blogspot.in/2012/09/geo-distributed-route53-lbr-latency.html

Part 1: Cost of Latency Series: Why do we need Latency Based Routing ?

Why do we need Latency Based Routing (LBR) ?

Imagine a XYZ Low Cost Airlines from Singapore which operates 100+ destinations around the globe (rapidly expanding its operations every year) with following characteristics :

• Majority of the bookings and business happens through online and mobile medium
• Their Website and online services are visited by users from Japan, Singapore, Australia, Europe and Middle East all over the year
• During Sales promotions and holiday seasons they will have visitors from more locations around the world

Since their business has heavy dependence upon the online mediums (web and mobile), their site needs to be highly available, scalable with better performance. Like most of the online companies, the XYZ airlines started their operations with the - Centralized Architecture

Effect of Centralized Architecture 

The entire web/app infrastructure is provisioned inside a single AWS region (example Singapore region). User requests originating all around the world are directed to the centralized infrastructure launched at single region. This architecture may be optimum to start with, but when your user base is distributed across multiple geographies things start crumbling. The users accessing the site from different geographies will have different response times because of the network latency in the internet, Also there is single point of failure if the network link to that particular Amazon EC2 region is broken (though the latter is a very rare occurrence).Example: Users from Singapore and Malaysia will have faster response times with AWS Singapore Servers than Users from Europe, MEA regions (they might feel the latency creeping up).

Since the XYZ airline follows a simple centralized architecture and has a data center in Singapore and all the visitors are distributed across the globe, let us see what it takes as the roundtrip latency measurements to access their website in centralized infrastructure:

Website is hosted on Singapore region (centralized architecture)	From Japan (ms)	From Germany(ms)	From Malaysia (ms)	From Rio (ms)
	74	121	30	176

Note: The above measurements are not constant and may keep varying every few seconds.

If a single round trip takes 121ms from Europe imagine content heavy pages loading multiple images, JS, scripts, HTTP/S, hundreds of AJAX calls etc. It is sure they will land in problems when they expand.


View Full Detailed article at http://harish11g.blogspot.in/2012/09/geo-distributed-route53-lbr-latency.html