Realscale is a philosophy for architecting cloud native applications to scale up to 1M visits/day and 1000 requests/sec, typically requiring 10-200 server instances and a variety of internal services.

DNS Scaling Strategies

The Domain Name System (DNS) is similar to a phone book for the Internet. It is most often used to associate a server’s IP address to a hostname (A records), alias one name to another (CNAME records), route email to the proper mail server (MX records), and general use text entries (TXT records). DNS also offers tools for cloud native applications to enable high availability configurations, failover, and service discovery.

Using Round Robin DNS for Server Load Balancing

Servers often fail, so it is helpful to have multiple server instances with the same code deployment and access to the same database(s). But, how do we share the load across these instances?

Most DNS servers, such as BIND, support multiple A record entries for the same hostname. This means we may configure our zone (domain) to return multiple entries for the same DNS query lookup. Servers such as BIND will then return each entry as the first record in the list, rotating through each one in turn (round robin). The result is that each request will rotate through the series of records in turn.

For example, if a single hostname has 3 A records ending in 1, 2, and 3, the following would be returned:

  • Request #1: x.x.x.1, x.x.x.2, x.x.x.3
  • Request #2: x.x.x.2, x.x.x.3, x.x.x.1
  • Request #3: x.x.x.3, x.x.x.1, x.x.x.2.

It is important to note that DNS requests are often cached by intermediate DNS servers, as well as DNS clients. Since a zone record is able to have a time-to-live (TTL), you will need to set the value to something low, such as 60 seconds. Otherwise, requests will always go to the same server, causing an unbalanced load across servers.

Since a round robin load balancing technique doesn’t take into account the load of individual servers and server outages, it is recommended to use DNS load balancing across more intelligent reverse proxy load balancers, such as HAProxy. This will ensure that some application servers are not unevenly balanced with others, and that failed servers are removed from the available server list.

Using DNS for Global/Geo-Based Load Balancing

Round Robin DNS is also used to distribute incoming traffic across multiple data centers, often spread across multiple geographical regions. Rules are established to route traffic to a specific data center based on the country where the request originated, improving the overall performance of the application. Without geo-based DNS support, requests from one country (e.g. South America), may be sent to servers in another country (e.g. North America) causing slow network performance.

Geo-based load balancing is often accomplished through the use of the GeoDNS BIND patch or by using a hosted DNS service that supports intelligent geo-based DNS load balancing.

Using DNS for Application Service Discovery

Combining these techniques together, we then use DNS records to point applications to specific application services, load balance between multiple instances, and even distribute these services across regions. Given that these services are meant for internal consumption only, the use of an internal private DNS server is recommended. This also provides the advantage of being able to use very low TTL for requests and even adding/removing service instances as necessary using custom automation scripts.

What’s Next?

Now that we better understand the use of DNS in cloud native architectures, let’s look at the remaining components within a cloud native architecture:

 Cloud Vendor Resources

Related Articles