Addressing CloudWatch Alarm for Amazon ElastiCache Evictions
Question
Your company uses Amazon ElastiCache for Memcached as a cache solution for a new web application.
A feature was deployed last week.
Since then, the CloudWatch alarm has been triggered for the “Evictions” metric.
It looks like the cache has evicted a large number of items to allow space for new writes.
The function of the new feature is working as expected.
Which action would you take to address the CloudWatch alarm? (Select TWO.)
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D. E.Correct Answers: A and C.
Option A is CORRECT because the ElastiCache cluster has an ongoing performance issue.
Scaling up the node can allocate more resources to address the problem.
Option B is incorrect because this option does not resolve the performance issue of the cache.
The evicting of items still exists, and the application is being impacted.
Option C is CORRECT because allocating more nodes can decrease the number of cache evictions and improve the application performance.
Option D is incorrect because changing the cache engine requires lots of effort and is unnecessary for the question.
Besides, ElastiCache for Redis cannot be used for certain circumstances.
Option E is incorrect because the CloudWatch alarm indicates a performance issue of the cache, and the question does not mention any software issue of the new feature.
There is no need to roll back the application.
References:
https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/CacheMetrics.WhichShouldIMonitor.html#metrics-evictions https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/CacheMetrics.Memcached.htmlThe CloudWatch alarm for "Evictions" metric indicates that the cache is running out of memory and has started to evict items to create space for new writes. This may result in decreased application performance if frequently used items are evicted. To address this issue, we need to take the following actions:
Scale out ElastiCache for Memcached by adding more nodes: This will increase the overall cache capacity, and each node can handle a portion of the total cache load, reducing the likelihood of evictions. To achieve this, we can use the AWS Management Console, AWS CLI or AWS SDK to add more cache nodes to the existing ElastiCache cluster.
Scale up the Memcached node by using a larger node type: This action will increase the memory capacity of each node, allowing it to store more data. By doing so, the number of evictions can be reduced. However, this approach is limited by the maximum node size available for ElastiCache for Memcached. Therefore, if the cache size continues to grow, scaling out is a more suitable approach.
Option B, Increase the CloudWatch alarm threshold is not a good option as it only hides the issue and does not resolve the root cause.
Option D, Changing the ElastiCache cluster to Redis is not a feasible option in this scenario, as this would require significant changes to the application's caching layer, including data serialization and deserialization, and configuration.
Option E, Rolling back the application is not necessary as the new feature is working as expected. The issue is related to the cache capacity and can be resolved by scaling out or scaling up the cache nodes.
In summary, the best course of action to address the CloudWatch alarm for "Evictions" metric is to scale out ElastiCache for Memcached by adding more nodes or scale up the Memcached node by using a larger node type.
