As the ingress point to most applications, DNS can be a great tool for distributing traffic across your endpoints. Traditionally providers have followed two simple rules: don’t send users to a server that’s currently down, and try to send users to the closest server in order to give them the best performance.
Infrastructure can be more than just up or down: it can be at capacity but still servicing current connections well, it can thrash and flap, or it can even be underutilized. Taking a binary approach to endpoint management can be dangerous – marking an answer as failed means that the infrastructure can’t be utilized in any further way, and pulling a node that’s functional but nearly overloaded can lead to cascading failures as all of your traffic is firehosed at the next-in-line datacenter.
A better approach would be to dictate routing policy based on real metrics coming from your end points. If your New York POP can service 20,000 simultaneous connections, let’s make sure the number of connections never exceeds 20,000. If it approaches that number we still want to use it as effectively as possible to service end users, but in order to avoid overloading it and impacting service we should start to bleed traffic off to the next best option.
NS1 was built from the ground up to service these kinds of use cases. Our Load Shedding automatically adjusts the flow of traffic to your endpoints in real-time based on telemetry coming right from your endpoints or application.
Our approach is data driven and it’s snap to implement: use one of our third party Datafeeds or leverage the NS1 API to push us metrics on the state of your systems, and for every single DNS query we receive we’ll look at the numbers in order to make sure we’re not overloading any of your infrastructure.
Load Shedding natively understands how to act on data like load averages, connection counts, and requests per second, but you can use it to route on nearly any metric that’s consistent across your endpoints, including things like APDEX or your own own custom application health values. Best of all it can be used in conjunction with any of our other powerful Filters to accommodate all sorts of interesting and practical use cases. A CDN for example might choose to route end users to the closest node unless it’s overloaded, in which case users will seamlessly be directed to the next nearest node.
To get started simply follow our step-by-step guide or get in touch with us today to learn more.