#elasticache

AWS ElastiCache | Managed Redis & Memcached Explained

⚡ AWS ElastiCache is a managed in-memory caching service that helps you improve application speed and scalability using Redis and Memcached. In this video, you’ll learn: ✔ What ElastiCache is ✔ How it improves performance ✔ Use cases for real-world apps

The Features of Amazon ElastiCache Serverless

Amazon ElastiCache Serverless, a new serverless offering, lets clients deploy a cache in under a minute and increase capacity depending on application traffic patterns. ElastiCache Serverless supports Redis and Memcached, two prominent open-source caching systems.

ElastiCache Serverless can run a cache for the most demanding workloads without capacity planning or caching knowledge. ElastiCache Serverless monitors your application’s memory, CPU, and network resource usage and scales immediately to match workload access patterns. Save time and money by creating a highly available cache with data automatically duplicated across several Availability Zones and up to 99.99 percent availability SLA for all workloads.

Customers needed extreme cache deployment and operation ease. ElastiCache Serverless abstracts cluster topology and cache infrastructure for basic endpoints. Without reconnects and node rediscoveries, you may simplify applications and improve operations.

ElastiCache Serverless has no upfront expenditures and charges for used resources. Pay for the cache data storage and ElastiCache Processing Units (ECPUs) your apps use.

Start using Amazon ElastiCache Serverless

In the left navigation pane of the ElastiCache console, select Redis or Memcached caches to begin. ElastiCache Serverless supports Redis 7.1 and Memcached 1.6.

Two deployment choices are Serverless or Design your own cache for a node-based cache cluster. Select Serverless, New cache, and name.

Create a cache in your default VPC, Availability Zones, service-owned encryption key, and security groups using default settings. Recommended best practices will be configured automatically. No other adjustments are needed.

Set your own security groups or enable automatic backups to adjust default settings. To prevent your cache from growing too large, specify maximum compute and memory restrictions. When your cache hits its memory limit, least recently used (LRU) logic evicts TTL keys. When your computing limit is reached, ElastiCache throttles requests, increasing request latencies.

A new serverless cache shows connection and data protection settings, including an endpoint and network environment.

You can now configure the ElastiCache Serverless endpoint in your application and connect using redis-cli or another cluster-mode Redis client.

Cache management is possible with AWS CLI or SDKs. See AWS documentation Getting started with Amazon ElastiCache for Redis for details.

ElastiCache Serverless allows you to migrate data from an existing Redis cluster by supplying the ElastiCache backups or Amazon S3 location of a regular Redis rdb file when constructing your cache.

A Memcached serverless cache can be created and used like Redis.

ElastiCache Serverless for Memcached provides high availability and quick scaling, which Memcached does not. Memcached provides high availability without specialized business logic, numerous caches, or a third-party proxy layer. Now you may receive 99.99 percent availability SLA and data replication across Availability Zones.

Scaling and performance

ElastiCache Serverless scales without application downtime or performance degradation by scaling up and scaling out simultaneously to meet capacity needs.

A simple scaling test showed ElastiCache Serverless’ performance. AWS started with a typical Redis workload with 80/20 reads and writes and 512-byte keys. The READONLY Redis command set our Redis client to Read From Replica (RFR) for optimal read performance. AWS want to demonstrate how ElastiCache Serverless can scale workloads quickly without latency.

As shown in the graph above, researchers doubled requests per second (RPS) every 10 minutes until the test’s target of 1M RPS. They found that p50 GET latency was always below 860 microseconds and about 751 microseconds. During rapid throughput increase, p50 SET latency stayed at 1,050 microseconds, not crossing 1,200.

Know something

Upgrade engine version – ElastiCache Serverless transparently deploys new features, bug fixes, security upgrades, and minor and patch engine versions to your cache. ElastiCache Serverless will notify you in the console and Amazon EventBridge about important version releases. No application impact is expected with ElastiCache Serverless major version updates.

Performance and monitoring – ElastiCache Serverless sends memory consumption (BytesUsedForCache), CPU usage (ElastiCacheProcessingUnits), and cache metrics (CacheMissRate, CacheHitRate, CacheHits, CacheMisses, and ThrottledRequests) to Amazon CloudWatch. ElastiCache Serverless publishes notable Amazon EventBridge events including cache creation, deletion, and limit adjustments. Details about metrics and events are in the documentation.

Security and compliance- ElastiCache Serverless caches are VPC-accessible. AWS IAM allows data plane access. The AWS account that created the ElastiCache Serverless cache has default access. Every ElastiCache Serverless connection is encrypted with transport layer security (TLS) to protect data at rest and in transit. You can restrict cache access by VPC, subnet, IAM access, and AWS KMS key for encryption. HIPAA-eligible ElastiCache Serverless is PCI-DSS, SOC, and ISO compliant.

Now available

Amazon ElastiCache Serverless is currently in all commercial AWS Regions, including China. ElastiCache Serverless has no upfront expenditures and charges for used resources. Cache data, ECPUs, and Snapshot storage cost GB-hours, GB-months, and GB-hours.

每年 AWS re:Invent 要到的時候就會有很多新的消息出來，Amazon ElastiCache 的團隊應該也是配合著這一波放出消息：「Amazon ElastiCache Now Supports the R4 Node Family」。 包括了 memcached 與 Redis 都支援了： Amazon ElastiCache now supports R4 node types. R4 nodes are optimized for latency sensitive and memory intensive workloads. They come in six sizes, providing 12.3GiB to 407GiB of available in-memory capacity. By setting up a 15-shard cluster for…

SQL world is easier to understand as compared to NoSQL world. NoSQL landscape is very confusing with multitude of solutions loaded with buzzwords. NoSQL solutions are often divided into categories based on solution type like key value, document or columnar. Sometimes they are also divided based on CAP theorem.

However, it's quite hard to classify an application as key-value or document or columnar. It is very much possible to architect an application to use any kind of nosql database. For example, one can store document as json in a key value store database. Or one can decompose the document into columns and store them in a columnar database. Similarly, a document or columnar database can easily fit in for a key-value solution.

This blog is focused on benchmark performance results between 3 popular NoSQL solutions - Redis, Couchbase, Cassandra. The test was done using the following scenario

DB server was running on AWS m4.large instance

DB Client was running on AWS c4.xlarge instance

Only a single DB server was used to compare performance in single instance solution

Both server and client were in same availability zone

All DB solutions were used as key-value store.

Data was written into database first, compacted, optimized and then test was 100% read workload

DB client was larger than DB server to ensure that server can be pushed to limits

First test was done with just 1,000 entries into the database

Redis was able to give 50k ops/sec, couchbase maxed out at 29k ops/sec, cassandra maxed out at 18k ops/sec. However, the biggest difference was in response times, where redis performed around 150 microseconds per response, cassandra starting reaching 1000 microseconds (1ms) for simple key value read.

Next, the test was done using 500k entries in the database

Here, Redis and Couchbase maxed out at 16k ops/sec. Redis response time was 250 microseconds compared to 375 microseconds for Couchbase. Cassandra started going beyond 1ms when pushed beyond 9000 ops/sec.

So far, all the data could be stored in RAM, since the data size (+indexes) was less than RAM size. So, all the databases were reading from RAM. Going further ahead on number of entries required configuring Redis to use swap along with RAM which is not recommended by Redis. The next test was done using 3M objects, each with 4k size. The total data size was approx 12GB and indexing (on primary key) led to approx 16 GB database size on a 8GB RAM machine. The reads were spread randomly across the 3M objects. Swap used was coming from EBS-SSD. Note that only Redis used Swap, Couchbase and Cassandra were not configured with Swap.

Cassandra was too slow to even compare. So, I dropped it out of the test after first read. Redis performed faster than Couchbase.

However, an interesting thing happened while I was prepping up for 3M test. I ran out of disk space while testing Couchbase. Couchbase became unresponsive, so I rebooted the machine. Once rebooted, couchbase failed to start and read the data from disk. I spent hours trying to get it to read the data, but ultimately, it led to data loss with Couchbase.

Next, I did the same 3M entries test, but read was confined to only 5% of the entries. So, the DB was storing 3M objects, but only 125,000 objects were read from DB.

Here, performance looked similar to 500K test. Redis with the help of Linux OS swap management was able to load keys into RAM. Couchbase already has logic to put cache in memory. However, Redis did outperform couchbase on both ops/sec and response times.

Summary:

Cassandra is quite slow as compared to Redis & Couchbase

Couchbase process list is huge and many components working together. It looks like a product built by acquisition. It's stability for production use is questionable.

Redis is blazing fast. It provides much more ops/sec on similar hardware. So, ops/$ spent is very good for Redis.

Redis Labs already has product for storing cold values on Flash. Hopefully, AWS will provide Flash as cheaper memory, expensive disk option sometime in future.

WHAT A MOUTHFUL.

MY GOD -- I just fixed this and I am going to write this down NOW. It’s fresh in my memory. I am going to describe my situation, explain how to fix it, and hopefully you can understand if you are looking for an answer. This was super annoying. I was so mad. I was like Bernie Mac:

I am in AWS (DUUUUHHHH) and I am using multiple regions for inherited reasons. Just as an example, let’s just say that I am in Singapore (ap-southeast-1) and in Sydney Australia (ap-southeast-2). Now, all of my main tools, EastiCache DBs, and apps are in Singapore and I am creating a secondary region for Sydney for new apps, and some newer tools. Now, you need access. So? VPN. Sure, you could do Hardware VPN (which is probably easier, as I shrug) but the free way is to do an opensource VPN solution.

Now, I am not going to write HOW to setup VPN. Because,** Raymii** and Alex @zeitgeist​ have great in-depth ways of setting this up. Just have the two VPN servers, one in each region, have a Public IP and point them to each other. Make sure your Security Groups allow for the UDP rules from each other and that’s it.

If your ElastiCache, or any service, is required across the VPN tunnel, then there are some caveats when connecting. Specifically, though, for ElastiCache. Strongswann IPSec.d is JUST the Tunnel. Maybe that is apparent to you, reader, but it wasn’t to me. The Routes are still regulated on the AWS level, so you need to go to VPC in each region and make sure you populate those routes on the correct VPC. Strongswann just connects, but any servers downstream do not know the routes directly.

Another challenge is MTU negotiation. Even if you let ICMP open on all SGs (Security Groups) for all internal IPs, the MTU is still not auto-negotiated on the VPN tunnel. It’s kind of a pain in the neck. I have been banging my head against the proverbial wall for a couple of weeks here, opened some AWS tickets, and got to a solution.

The problems to note:

ElastiCache **BLOCKS **ICMP by default and cannot be overwritten (even if you change the SG)

StrongSwann does not negotiate MTU by default either. Security Groups can be set, but sometimes those MTU blocks are dropped and connection from VPN1 to VPN2 can die..without much warning.

In my specific situation, I needed to access our ElastiCache cluster over the wire for some read reasons. Now, the MTU would drop and I had to set MTU manually. THAT IS ANNOYING. I don’t want to do that for every server that needs to make a call across the wire.

So, with the help of my friends - AWS - I found that all I needed to do this on my VPN nodes:

sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu_ sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128

I am running configuration with Puppet, ick, but if you use the PuppetLabs Firewall module, here, you can easily set your rules by either:

firewall { '110 TCPMSS for VPN clients': chain 'FORWARD', table 'mangle', source '10.0.2.0/24', proto tcp, tcp_flags 'SYN,RST SYN', mss '1361:1541', set_mss '1360', jump 'TCPMSS', }

OR - if you use hiera:

#firewall.pp class vpn::iptables inherits vpn::params { create_resources(’firewall’,$iptables) } #params.pp class vpn::params { $iptables = hiera(’vpn::iptable::rules, {}’) } #hiera where rule is located --- vpn::iptable::rules: '1-TCPMSS-for-VPN': chain: 'FORWARD' proto: 'tcp' tcp_flags: "SYN,RST SYN" jump: "TCPMSS" clamp_mss_to_pmtu: true ensure: 'present' '2-TCPMSS-for-VPN': chain: 'FORWARD' proto: 'tcp' tcp_flags: "SYN,RST SYN" jump: "TCPMSS" set_mss: "128" ensure: "present"

Now, you can test your connection and that should be it.

I’m adding this info so that it’s on the internet. I saw a lot of people saying that this was an issue but it wasn’t apparent that there was a ready-available solution.

Recently, I had to clone/backup a running redis elasticache instance on AWS. It turned out to be harder than expected. This post describes how I finally got my data out.

I have AOF turned on and fsync every second. This ensures that I will loose max 1s worth of data in case of a catastrophe.

Elasticache provides a snapshotting feature. However, you cannot download that snapshot. So if you want to clone onto, say localhost, it's pretty much useless.

Then I tried SAVE/BGSAVE. The commands seem to have been disabled. Actually, even if they worked it would be useless caus you cannot log onto the instance to scp the *.rdb file generated.

redis-cli has an interesting option called --rdb, that dumps the contents of redis onto a localfile. So I tried it.

The above worked, however I noticed that it was not an accurate reflection of my data. I could very easily confirm that some keys in prod were mising from the *.rdb file generated. Maybe caus I had AOF/fsync turned on, and hence all writes get recorded to an aof file, the rdb file generated was not entirely accurate? I'm not sure of how the --rdb flag works internally, but I was back at square one.

The suggestion from AWS was to spin up a new instance as a slave and dump the data on it. More here.

So the only reasonable way I found was to iterate through the entire keyspace, dump it out to file and then relay it on localhost. Dumb, but if you know of a better option, let me know!

When dumping out content, the best way is to dump the keys/values out in redis protocol. This will make doing a mass import into the localhost redis really fast (in case you have millions of keys in your keyspace). Here is the script to export the data out of redis into a flat file in the redis protocol:

https://gist.github.com/jimmyislive/0efd7a6a1c7f7afd73e8

NOTE: The script uses the KEYS command, which is a O(N) operation and hence blocking. (Thanks to @itamarhaber for pointing it out) The docs mention to be careful using the KEYS command in production owing to it's blocking nature. Now you know the pros/cons of using this script !

Once we have the above file, ship it to localhost and then use the shell script to mass import this into redis.

Why the inability to access ElastiCache from outside is a deal breaker

AWS ElastiCache cannot be accessed from the outside. Amazon cites latency issues as the cause for it but this may turn out to be a deal breaker for many customers. Here’s why:

The entire infrastructure might not be AWS based

Private-public hybrid clouds is a very real scenario and most companies prefer to have their test infrastructure on their own hardware and deploy on the cloud. While it…

これまで、ElastiCache (Redis) のバックアップをとりたいときは、EC2 上の Redis を ElastiCache のスレーブにして rdb ファイル等を取得する方法しかありませんでした。

まどろっこしくて、早く直接バックアップがとれるような機能がほしいなぁと思っていたのですが、とうとう実装されたようです！

現在はバックアップ/リストア等の操作は cache.m1.small 以上でしかできないようです。

自動スナップショットの設定

日毎に自動でバックアップを作成する設定ができます。

新規クラスタに設定する

通常通り Launch Cache Cluster からクラスタの作成を進めていくと、以下のような画面に進みます。

ここで Enable AutoMatic Backups で Yes を選ぶといろいろ設定できるようになります。

Backup Retention Period は「自動で作成されるスナップショットをどのくらいの期間残しておくか？」の設定です。

Snapshot window は「この時間帯であればスナップショットをとってもいいよ」という時間帯の設定です。

設定した時間帯を過ぎると、バックアップが作成されていることが確認できました！ 自動スナップショットの場合は Snapshot Type が automated になっているようです。

スナップショットの作成は、内部的には Redis の BGSAVE コマンドが実行されているらしいです。

BGSAVE コマンドで、子プロセスを spawn して RDB ファイルの生成を行うようになっていますが、子プロセスを spawn する数秒間は読み書きができなくなるらしいので、Snapshot window は慎重に指定する必要がありそうです。

また、スナップショット作成中はパフォーマンスが落ちる可能性があるので、もし可能であれば Primary からスナップショットをとるのではなく、Read Replica を作成した上でそこからスナップショットを作成するようにしたほうがよさそうです。

既存のクラスタに設定する

既存のクラスタに自動スナップショットを設定する場合は、クラスタ一覧の Modify ボタンから設定できるようになっています。

手動でスナップショットを作成

手動でもスナップショットがとれます。

Snapshots メニューに移動して、Create Snapshot を押すと以下のようなダイアログが出てくるので、スナップショットを作成したいクラスタを選択して、名前をつけて Yes, Create！

完了すると Snapshot Type が manual となっているスナップショットが作成されています。

手動でのスナップショット作成は、自動スナップショットと違って自動で削除されることがないので、長期間に渡ってスナップショットを保持しておきたい場合には、手動で作成することになります。

また、スナップショットを選択して Copy Snapshot を押すことで、自動スナップショットで作成されたスナップショットから手動スナップショットを作成することもできます。

スナップショットからのリストア

スナップショットからクラスタを立ち上げることができます。

スナップショットの一覧から目的のスナップショットを選択し、Restore Snapshot ボタンを押します。

すると、以下のようなダイアログが立ち上がるので、名前をつけて Launch Cache Cluster！