It does this by acting as a parallel high-performance network, maintaining its own network of highly-distributed servers. By being dispersed over many physical and network locations, but optimized as one network, more control and reliability exists for user requests.
As a business grows, scaling to meet higher demands on the content origin also has challenges. We will also look at how CDN tools can be used to reduce load on the origin, helping not just improve performance, but also reduce cost by reducing how high the origin must be scaled.
When a user makes a request, Akamai dynamically maps this to the closest available edge server. The edge server applies the business rules that the content provider has specified, before using the best available route between all other edge servers within the Akamai network to fetch content from the origin.
Business rules are replicated on each edge server. Any content available and configured to be cached is then cached on the edge server for future requests connecting to that node.
We will look at this in more detail later on. As seen in the Monitor tab, many reporting and analytics tools are available for generating insights at a CDN level. Logs from edge servers are also available on request. In the Configure tab we will focus on introducing Property Manager, and leave other options for a future post. A property , sometimes also referred to as a configuration , is the main way to control how edge servers respond to user requests.
Properties apply a list of rules to a set of hostnames , and you can only apply one property at a time to any given hostname.
An additional example of this will be seen later when looking at caching. When making changes to a property a new version is first created, allowing changes to be made and tested while the previous property remains active. The new version can be first activated on the Akamai staging network, that a developer can point their local machine to run tests against, before activating in production.
Production activation takes roughly ten minutes to globally roll out the new version to all edge servers, with a fast fallback option rolling back within minutes. In addition to providing an ever increasing amount of distributed edge servers, to be able to serve cached content from as close to every user as possible, the route to the content origin can be optimized. The default route may pass between several different ISPs and networks, which may not always peer well with each other.
As seen above, a lossy link or other such degradation may mean a non-obvious route is the best option. This means that on every request to an edge server the fastest and most reliable route at that point in time can be used to reach the origin.
As organizations scale caching can also become increasingly important to reduce load on the content origin for both better performance and to reduce costs.
If no content is cached along the entire route then it will return to the origin and repopulate the cache with its response. The standard cache key used is made up of the host name domain , path and query string. Edge DNS.
Web Application Protector. Specific product s for this. Kona DDoS Defender. Requests costs Customers pay for client to CDN requests. Ingress costs Customers pay for origin-to-CDN bytes transferred. Instant setup Sign up, configure, start testing. Can't sign up and get started.
Must talk to sales. Change propagation delay How fast do config changes propagate to all POPs? If you also use their Fast DNS for your domain. IPv6 Do the edge servers have IPv6? Compression Reduce file size for faster delivery. Resend from origin, or compress on edge. Set specific value? Cache control - CDN caching. Cache control - client caching. Serve Stale CDN serves cached but expired content in case origin is in trouble.
Purge Invalidate or delete cached objects on CDN.
0コメント