Amazon ElastiCache for RedisがSSDキャッシュに対応。大容量のキャッシュを低コストに運用できるようになりました

DRAMとSSDにキャッシュを保存するAmazon ElastiCache for Redis Data Tieringが登場。 SSDアクセス時はレイテンシーが増加するトレードオフとして、安価にクラスター運用できるようになりました

#ElastiCache for Redis

#Redis

#Amazon ElastiCache

#AWS

quiver

2021.11.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ホットキーはDRAM、ウォームキーはNVMeに保存するData Tieringの登場

Redisはインメモリ型のKVSです。扱える容量はノードのメモリ容量に依存するため、大容量のキャッシュを扱いたい場合は、垂直方向にノードのメモリ容量をふやしたり、水平方向にシャーディングする必要がありました。

Amazon ElastiCache for Redisの場合、クラスターモードを有効にすると、シャード対応したクラスターを簡単に作成できます。しかし、各シャードは、プライマリ・レプリカの冗長構成をとり、ランニングコストもかさむのがネックです。

そこで登場したのがdata tieringです。

より安価に大容量のキャッシュを扱えるよう、ローカルストレージのNVMe SSDを活用し、ホットなキャッシュはこれまでと同じくインメモリに保存し、古いキャッシュはSSDに保存されます。ノードあたりの容量が5倍に増え、ノードコストも大幅に下がるトレードオフとして、SSDキャッシュアクセス時にレイテンシーが増加します。

最大スペックの16xlargeでは、1ノードあたりRAM 419GiBとSSD 1592GiBの合計2TiBを扱えるようになり、500シャードの場合、1PiBのRedisクラスターまで組めます。

Data Tiering Redisはサーバー内の挙動が変わるだけであり、クライアントからは透過のため、導入は容易です。

11月23日から、東京を含む、9リージョンで利用できるようになりました。

ユースケース

繰り返しとなりますが、Amazon ElastiCache for Redisを利用すると、ストレージコストが大幅に安価になる一方で、SSDキャッシュアクセス時のレイテンシーが増加します。

ホットキーはRAMで管理され、LRUにより、古いキーが SSD に移動します。

ドキュメントによると、20％のデータを頻繁にアクセスし、レイテンシーの増加を受け入れられるようなワークロードにData Tieringが最適です。ストレージ容量に関して、RAM:SSD=1:4です。頻繁にアクセスするホットキーが全データの20％の場合、これらデータをRAMに乗せる事ができるからです。

どのくらい安くなる?

各ノードの容量は RAM:SSD≒1:4 のため、ノードあたり5倍の容量を扱えます。

東京リージョンのオンデマンドの場合、Data Tier版と従来版のノードタイプ別スペックをまとめたのが、次の表です。

Cache Node Type	vCPU	Memory(GiB)	SSD(GiB)	Total(GiB)	Network Performance	$/Hour(Data Tier版)	$/Hour(非Data Tier版)	$/GiB(Data Tier版)	$/GiB(非Data Tier版)
large	2	13.07	N.A.	N.A.	Up to 10 Gigabit	N.A.	0.247	N.A.	0.0189
xlarge	4	26.32	99.33	125.65	Up to 10 Gigabit	0.937	0.493	0.0074	0.0187
2xlarge	8	52.82	199.07	251.89	Up to 10 Gigabit	1.872	0.985	0.0074	0.0186
4xlarge	16	105.81	398.14	503.95	Up to 10 Gigabit	3.741	1.969	0.0074	0.0186
8xlarge	32	209.55	796.28	1005.83	12 Gigabit	7.48	3.937	0.0074	0.0188
12xlarge	48	317.77	1194.42	1512.19	20 Gigabit	11.221	5.906	0.0074	0.0186
16xlarge	64	419.09	1592.56	2011.65	25 Gigabit	14.961	7.874	0.0074	0.0188

Data Tier RedisのMemoryのサイズは従来型と同じです。 Data Tierには SSD が付属し、 Total列に Memory と SSD を足した値を入れています。

ストレージあたりのコストは、同じファミリー内であれば、インスタンスタイプによらず同じです。

従来のインメモリ Redisは $0.0186/GiB
新しい Data Tier Redis は $0.0074/GiB

のため、Data Tierは約6割安で利用できます。

次にインスタンスタイプごとに利用費を比較してみましょう。

105.81GiBの 4xlarge ノードを運用している場合、 Data Tierでは最小スペックの xlarge(125.65GiB)に置き換えられます。

時間単価は $1.97 から $0.94 へと約半減します。

クラスターモードで最大スペック 419.09GiB の 16xlargeを5シャードで運用している場合(約2TiB)、 Data Tierでは同じ16xlarge(2011.65GiB)1台に置き換えられます。

時間単価は 5 * $7.87 = $39.35 から $14.96 へと約6割安になりました。 1ヶ月の利用費では、1ノードあたり、 $28,800(≒326万円) から $10,800(≒122万円) への変化です。

Data Tieringを使うと、より少ない台数でより安く運用できるようになります。

どのくらい遅くなる?

Data Tieringを使うと、ストレージコストが安くなる代償として、レイテンシーが増加します。

アクセスの10％がSSDを経由するようなベンチマークを実施した結果が次のグラフです。

※図は公式ブログから

ほぼ同じ値を指すAvg/P50はRAMへのアクセス、p90以上はSSDへのアクセスです。

P99 でもP50の倍程度に収まっています。

RAM/SSDの2層キャッシュの仕組み

Data Tier Redis の構成図を公式ブログから引用します。

下半分の

LRU
Tiering Engine
SSD

が Data Tier Redis向けの追加コンポーネントです。

LRU

Data Tier 向けデータにはLRU管理のために、16バイトのメタデータが追加されます。

この情報を元に、古いキャッシュはLRU(least-recently used)アルゴリズムにより、自動的に RAM から SSD に移動します。

逆に、SSDへのアクセスが発生すると、非同期にRAMに戻ります。

なお、すべてのキーはRAM層で管理され、バリューだけがRAM⇔SSD間を移動します。

SSD

ドキュメント内の"locally attached NVMe solid state drives (SSDs)" という表現やノードタイプ(r6gd)の「d」から、このSSDはいわゆるインスタンスストアであることがわかります。

Tiering Engine

Tiering Engine は NVMe SSD 向けに最適化されたエンジンです。

ElastiCache for Redis stores data on NVMe SSDs using a purpose-built tiering engine, which is fine-tuned for high throughput and low latency.

気になりますね。

re:InventのDeep Diveセッションで、開発チームに内部実装をドヤっていただきたいところです。

Data Tier 用監視

Data Tier Redis向けにディメンションとメトリクスが追加されています。

SSD への読み書きが増えだしたら、ホットキーがRAMに収まっていないことが考えられます。大きいインスタンスタイプへの変更をご検討ください。

メトリクス

SSDとの読み書きで

サイズ数をモニタリングする BytesReadFromDisk/BytesWrittenToDisk
アクセス数をモニタリングする NumItemsReadFromDisk/NumItemsWrittenToDisk

が追加されています。

ディメンション

Tier ディメンションが追加され、メトリクス

CurrItems : キャッシュアイテム数
BytesUsedForCache : キャッシュサイズ

を Memory, SSD それぞれで監視できるようになりました。

詳細 : Metrics for Redis - Amazon ElastiCache for Redis

メモリーポリシー

Redis はキャッシュが溢れているときの振る舞いを maxmemory-policy という設定でコントロールします。

Data Tiering版では、RAMとSSDを使い切った場合です。項目名の「memory」に惑わされないようにしましょう。

Data Tiering版では以下のポリシーから選択できます。

noeviction : 新規キーの追加を受け付けない
allkeys-lru : LRUベースで古い者から削除
volatile-lru : EXPIRE 設定されたキーを古いものから削除

デフォルトは volatile-lru です。

詳細 : Using Redis as an LRU cache – Redis

制限事項

最後に、制限事項をドキュメントから転載します。リリースされたばかりの製品のため、今後は制約はゆるくなっていくと思われます。

You can only use data tiering on clusters that are part of a replication group.
The node type you use must be from the r6gd family, which is available in the following regions: us-east-2, us-east-1, us-west-2, us-west-1, eu-west-1, eu-central-1, ap-northeast-1, ap-southeast-1, ap-southeast-2.
You must use the Redis 6.2 or later engine.
You cannot restore a backup of an r6gd cluster into another cluster unless it also uses r6gd.
You cannot export a backup to Amazon S3 for data-tiering clusters.
Online migration is not supported for clusters running on the r6gd node type.
Scaling is not supported from a data tiering cluster (for example, a cluster using an r6gd node type) to a cluster that does not use data tiering (for example, a cluster using an r6g node type).
Auto scaling is not supported for clusters running using data tiering.
Data tiering only supports volatile-lru, allkeys-lru and noeviction maxmemory policies.
Forkless save is not supported. For more information, see How synchronization and backup are implemented.

また、ドキュメントには記載がありませんが、ElastiCache for Redis の Product Managerのトークによると、128MBを超えるアイテムはSSDに保存できず、RAMにとどまるようです。