Amazon ElastiCache for Memcached | Configuration and Scaling Flashcards
I use Memcached today. How do I migrate to Amazon ElastiCache?
Configuration and Scaling
Amazon ElastiCache for Memcached | Database
Amazon ElastiCache is protocol-compliant with Memcached. Therefore, you can use standard Memcached operations like get, set, incr and decr in exactly the same way as you would in your existing Memcached deployments. Amazon ElastiCache supports both the text and binary protocols. It also supports most of the standard stats results, which can also be viewed as graphs via CloudWatch. As a result, you can switch to using Amazon ElastiCache without recompiling or re-linking your applications - the libraries you use will continue to work. To configure the cache servers your application accesses, all you will need to do is to update your application’s Memcached config file to include the endpoints of the servers (nodes) we provision for you. You can simply use the “Copy Node Endpoints” option on the AWS Management Console or the “DescribeCacheClusters” API to get a list of the endpoints. As with any migration process, we recommend thorough testing of your new Amazon ElastiCache deployment before completing the cut over from your current solution.
Please note that Amazon ElastiCache currently allows access only from the Amazon EC2 network, so in order to use the service, you should have your application servers in Amazon EC2.
Amazon ElastiCache uses DNS entries to allow client applications to locate servers (nodes). The DNS name for a node remains constant, but the IP address of a node can change over time, for example, when nodes are auto replaced after a failure on a non-VPC installation. See this FAQ for recommendations to deal with node failures.
How do I select an appropriate Node Type for my application?
Configuration and Scaling
Amazon ElastiCache for Memcached | Database
Though there is no precise answer for this question, with Amazon ElastiCache, you don’t need to worry about getting the number of nodes exactly right, as you can very easily add or remove nodes later. The following two inter-related aspects could be considered for the choice of your initial configuration:
The total memory required for your data to achieve your target cache-hit rate, and
The number of nodes required to maintaining acceptable application performance without overloading the database backend in the event of node failure(s).
The amount of memory required is dependent upon the size of your data set and the access patterns of your application. To improve fault tolerance, once you have a rough idea of the total memory required, divide that memory into enough nodes such that your application can survive the loss of one or two nodes. For example, if your memory requirement is 13GB, you may want to use two cache.m4.large nodes instead of using one cache.m4.xlarge node. It is important that other systems such as databases will not be overloaded if the cache-hit rate is temporarily reduced during failure recovery of one or more of nodes. Please refer to the Amazon ElastiCache User Guide for more details.
Can a cluster span multiple Availability Zones?
Configuration and Scaling
Amazon ElastiCache for Memcached | Database
Yes. When creating a cluster or adding nodes to an existing cluster, you can chose the availability zones for the new nodes. You can either specify the requested amount of nodes in each availability zones or select “spread nodes across zones”. If the cluster is in VPC, nodes can only be placed in availability zones that are part of the selected cache subnet group. For additional details please see ElastiCache VPC documentation.
How many nodes can I run per region in Amazon ElastiCache Memcached?
Configuration and Scaling
Amazon ElastiCache for Memcached | Database
You can run a maximum of 100 nodes per region. If you need more nodes, please fill in the ElastiCache Limit Increase Request form.
How does Amazon ElastiCache respond to node failure?
Configuration and Scaling
Amazon ElastiCache for Memcached | Database
The service will detect the node failure and react with the following automatic steps:
Amazon ElastiCache will repair the node by acquiring new service resources, and will then redirect the node’s existing DNS name to point to the new service resources. For VPC installations, ElastiCache will ensure that both the DNS name and the IP address of the node remain the same when nodes are recovered in case of failure. For non-VPC installations, ElastiCache will ensure that the DNS name of a node is unchanged; however, the underlying IP address of the node can change.
If you associated an SNS topic with your cluster, when the new node is configured and ready to be used, Amazon ElastiCache will send an SNS notification to let you know that node recovery occurred. This allows you to optionally arrange for your applications to force the Memcached client library to attempt to reconnect to the repaired nodes. This may be important, as some Memcached libraries will stop using a server (node) indefinitely if they encounter communication errors or timeouts with that server.
