In most cases, developers face the problem of traffic distribution between several backends when already having some running application, with a pool of existing users and constant incoming load. Thus, besides the general traffic sharing configuration difficulties, it is additionally complicated with the necessity to apply the appropriate “on-fly” changes to the front-end application instance. In many cases, it causes a temporary app downtime. So in order to minimize such negative influence on your customers, below we’ll consider the ways to easily and painlessly integrate Traffic Distributor (TD) solution into your running application topology.
Note: Traffic Distributor provides the ability to benefit from a number of useful solutions, like:
- apply “invisible” application updates with blue-green deployment
- examine performance, user experience, and new app version’s stability through A/B testing
- increase service availability with advanced failover protection
To achieve this, you’ll need to pass through the following steps:
For this example, we run an application in the Apache server within the primary-env environment.
Tip: You can use the environment cloning feature to instantly get the identical environment copy (i.e. with all the appropriate data and settings being already set up inside) of any type.
Note: Don’t forget to properly configure any “hardcoded” data (direct links, IPs, etc.) for the cloned environment if needed.
Tip: If there are several environment regions available at the chosen hosting provider platform, you can subsequently migrate one of your environments to a different hardware set. This will grant better failover protection, as you’ll be able to deal with the hardware-dependent problem at one of your backends (if such occurs) by routing requests to the instance that remains operable.
The only remaining thing is to redirect incoming traffic from the first environment to Traffic Distributor.
Most applications in production have some custom domain. In our example, the initial environment (primary-env in our case) already has a custom domain name bound.
For the proper redirection of requests (i.e. to process them through the distributor), we need to move the appropriate entrypoint to the TD environment. In such a way, it will be placed in front of the chosen pair of backends and share the incoming load among them based on specified settings.In order to accomplish this, follow one of the next simple procedures based on the used custom domain binding method:
Now, click the Swap button and confirm this action within the pop-up to apply the changes.
The easiest way to pass public IP from primary-env (i.e. the one your custom domain is attached to) to Traffic Distributor is by using the corresponding External Addresses Swap functionality, available through platform API and CLI.
It allows performing the required configurations in a single command, sparing you from the manual A Record reconfiguration.
If you prefer to work via GUI, you need to go to your domain registrar and manually substitute an external IP address in the A Record for your custom domain.
Tips:
- For these changes to be applied, you need to wait for the current DNS record cache expiration (as until this happens, DNS servers may return the old domain address upon request). To know the exact period the domain’s old IP address will be kept in cache, check the TTL setting value within your DNS manager (usually stated in seconds).
- Do not forget to recheck your application configurations for the hardcoded IP-dependent settings and adjust them accordingly.
That’s it! Now, all incoming traffic for your custom domain will be processed by the Traffic Distributor solution, which, in its turn, will route it according to the set traffic ratio between application backends.