Introduction and the Problem:
Recently, I was talking to someone and they had an interesting problem. They wanted to send their traffic first to the service running on their on-prem data center, and only if the request fails, reroute it to the service running on the cloud. But the gateway they were using had no possible way to find out if the service is up before sending the traffic, so they had some lengthy workaround to manage this - They are using a Lambda function to route to one of the endpoints in the network. If there is a 502 error, it will write to S3 bucket (there was no retry implemented) so the same can be replayed later.
They asked me, can we make it simpler and more efficient with Apigee?
Solution:
The answer is yes, we can make it much more efficient and simple with Apigee X.
Apigee can help with this problem by providing built-in support for Load Balancing and failover across multiple backend server instances.
Instead of giving concrete endpoint URLs in the configuration, you can configure one or more named TargetServers and then reference TargetServer by name in the TargetEndpoint HTTPConnection.
Whenever a request comes, Apigee will send the request across multiple target servers based on the load balancing algorithm. By enabling Health Monitoring on load balancing, you can enhance the load balancing configurations by actively polling the backend service URLs defined in the TargetServer configurations. With health monitoring enabled, TargetServers that are unreachable or return an error response are marked unhealthy and traffic won’t be sent to them unless they are active again. A failed TargetServer is automatically put back into rotation when the HealthMonitor determines that the TargetServer is active.
Sample Config for TCP Monitor:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<Server name="target2" />
<MaxFailures>5</MaxFailures>
</LoadBalancer>
<Path>/test</Path>
<HealthMonitor>
<IsEnabled>true</IsEnabled>
<IntervalInSec>5</IntervalInSec>
<TCPMonitor>
<ConnectTimeoutInSec>10</ConnectTimeoutInSec>
<Port>80</Port>
</TCPMonitor>
</HealthMonitor>
</HTTPTargetConnection>
</TargetEndpoint>
Sample Config for HTTP Monitor:
<HealthMonitor>
<IsEnabled>true</IsEnabled>
<IntervalInSec>5</IntervalInSec>
<HTTPMonitor>
<Request>
<ConnectTimeoutInSec>10</ConnectTimeoutInSec>
<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
<Port>80</Port>
<Verb>GET</Verb>
<Path>/healthcheck</Path>
<Header name="Authorization">xxx</Header>
<IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
</Request>
<SuccessResponse>
<ResponseCode>200</ResponseCode>
<Header name="ImOK">YourOK</Header>
</SuccessResponse>
</HTTPMonitor>
</HealthMonitor>
P.S. You can also specify a fallback server - when the load balancer determines that all TargetServers are unavailable, all traffic will be routed to that fallback server.
Sample Config: (Here target 3 is a fallback server, when both target1and target 2 are unavailable, all traffic will be routed to target3)
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<Server name="target2" />
<Server name="target3">
<IsFallback>true</IsFallback>
</Server>
</LoadBalancer>
You can read this in more detail here: https://cloud.google.com/apigee/docs/api-platform/deploy/load-balancing-across-backend-servers#healt...
LinkedIn
Twitter
