ElastiCache(Redis)実務 — キャッシュ設計の型

ElastiCache(Redis)は「置けば速くなる」わけではありません。戦略・TTL・スタンピード・フェイルオーバーの設計が甘いと、障害時にDBを巻き込んで落ちます。実務で効く設計の型を、AWS一次情報をもとに整理します。

「DBが重いのでElastiCacheを前に置きたい」という相談は多くいただきます。ただ、キャッシュは魔法ではなく、戦略・TTL・可用性・障害時の振る舞いを設計しないと、平常時は速くても、有事にはDBを巻き込んで全体を落とす層になり得ます。本記事では、AWS公式の考え方をベースに、実務でつまずくポイントを順に整理します。

01まず用途を切り分ける — キャッシュ/セッション/その他

ElastiCacheの用途は大きく分けて次の3つで、設計上の要求がまったく異なります。ここを混ぜると設計がぶれます。

DB前段のキャッシュ：正はDB。キャッシュは消えても再構築できる。可用性より「消えても壊れない設計」が主。
セッションストア：正がRedis側にある。消えると全ユーザーがログアウトするなど業務影響が直接出る。可用性・永続性の要求が上がる。
レートリミット/キュー/ランキング等：Redisのデータ構造そのものを機能として使う。揮発性の許容度は要件次第。

現場のコツ：「キャッシュ」と「セッション」を1つのクラスタに同居させる構成は、初期はよく見ますが、TTL方針もフェイルオーバー要件も違うため、規模が出てきたら分離を検討してください。片方の事故がもう片方に波及します。

02キャッシュ戦略 — cache-aside と write-through

AWSが挙げる代表的な戦略はLazy Loading(cache-aside)とWrite-Throughです(Caching strategies)。それぞれ長所と短所が明確です。

cache-aside(遅延読み込み)：アプリはまずキャッシュを引き、ミスならDBを引いてキャッシュに書き戻す。要求されたデータだけ載るためメモリ効率が良く、ノード障害でも空ノードから再構築でき「壊れない」。反面、キャッシュミス時は3往復(キャッシュ→DB→書き戻し)のペナルティがあり、DB更新時にキャッシュは更新されないため古くなり得る(stale)。
write-through：DB書き込みと同時にキャッシュも更新する。データは常に新しいが、書き込みごとに2往復のコストがかかり、読まれないデータもキャッシュに載るため無駄が出る。また新規ノードは書き込みが来るまでデータが欠けている。

実務ではcache-asideを基本とし、更新頻度が高く鮮度が重要なキーだけwrite-throughを併用するのが素直です。AWSも「両者にTTLを組み合わせる」ことを推奨しています。判断軸は下表の通りです。

図：cache-aside(遅延読み込み)の基本フロー。ミス時のみDBを引き、TTL付きで書き戻す。

戦略の判断軸

参照が圧倒的に多く、多少の陳腐化を許容できる → cache-aside + TTL
更新が頻繁で、常に最新でないと業務が成立しない → write-through(+ 更新時のキャッシュ無効化)
更新時に確実に古い値を消したい → 書き込みパスで該当キーをDELする明示的無効化を組み合わせる(TTL任せにしない)

02bTTL設計 — 「とりあえず1時間」をやめる

TTLはcache-asideとwrite-throughの弱点を埋める要です(Adding TTL)。期限切れキーは「見つからない」扱いになり、DBから引き直してキャッシュが更新されます。設計時に押さえるべき点は次の通りです。

データ特性でTTLを変える：マスタ系(ほぼ不変)は長め、価格や在庫など鮮度が要るものは短めに。全キー一律TTLは、鮮度過剰かメモリ浪費のどちらかに寄ります。
更新時無効化とTTLは併用：TTLは「最終防衛線」。正しい鮮度は更新パスでのDEL/SETで担保し、TTLはそれが漏れた時の保険と考えると設計がぶれません。
TTLをそろえない:大量のキーが同じTTLで一斉失効すると、次章のスタンピードを誘発します。

03キャッシュスタンピード — 有事にDBを守る

キャッシュ設計で最も事故になりやすいのがスタンピード(thundering herd)です。人気キーが失効した瞬間、多数のリクエストが一斉にミスしてDBへ殺到し、DBが飽和して全体が落ちます。ノード障害でキャッシュが空になった直後も同じことが起きます。代表的な対策を整理します。

TTLのジッター(ばらつき)：TTLに乱数の揺らぎを加え、失効タイミングを分散する。実装が軽く効果が大きい第一手です。
再計算ロック(single-flight)：失効時、最初の1リクエストだけがDBを引いて再構築し、他は短時間待つか古い値を返す。SET NXによるロックで実装します。
非同期リフレッシュ：失効前に裏で更新し、ユーザーリクエスト経路ではミスを起こさない(AWSの言う「プロアクティブなキャッシュ充填」)。
古い値の許容(stale-while-revalidate)：再構築中は一時的に古い値を返し、裏で更新する。鮮度を少し犠牲にDBを守ります。

現場のコツ：スタンピードは平常時のベンチでは絶対に顕在化しません。顕在化するのは「キャッシュノード再起動直後」「一斉失効」「アクセス急増」の3シーンです。設計レビューでは必ず「人気キーが今この瞬間に消えたら、DBは何QPS受けるか」を試算してください。この一問で構成の穴が見えます。

04クラスタモード — 有効/無効の選択

Redis/Valkeyにはクラスタモード無効(CMD)とクラスタモード有効(CME)があります(レプリケーションの理解)。要点は「シャーディングするか否か」です。

CMD(単一シャード)：1プライマリ+最大5レプリカ。データは1ノードに収まる前提。構成がシンプルで、多くのキャッシュ用途はこれで足ります。
CME(複数シャード):データを複数シャードに分散する分散データベースとして動作。単一ノードのメモリ/スループット上限を超える規模、または水平スケールが要る場合に選択。

選定の判断軸

データが1ノードのメモリに十分収まり、当面スケールアウト不要 → CMD
データ量・スループットが単一ノードを超える/超える見込み → CME
CMEはクライアントがクラスタ対応(スロット/リダイレクト対応)である必要がある。マルチキー操作は同一スロットに限られる({tag}によるハッシュタグ設計が要る)点に注意。ライブラリと運用の複雑さが1段上がります。

迷ったらCMDで始め、上限が見えてきた段階でCMEを検討する、で実務は回ります。数値上限はバージョン・ノードタイプ依存のため、公式で最新を確認してください。

05フェイルオーバーと Multi-AZ — 「消えても壊れない」を設計に落とす

可用性はMulti-AZと自動フェイルオーバーで担保します(Multi-AZによるダウンタイム最小化)。AWSの記述から、実務で押さえるべき挙動を抜き出します。

Multi-AZ有効にはレプリカが必須:レプリカのないクラスタは高可用性を提供しません。プライマリ障害時、レプリケーションラグが最小のレプリカが昇格し、通常は数秒で書き込み再開できます。
プライマリエンドポイントは変わらない:昇格レプリカのDNSがプライマリエンドポイントに伝播されるため、アプリ側のエンドポイント変更は不要です。個別リーダーエンドポイントを直接指しているとハマるので、原則プライマリ/リーダーエンドポイント経由で接続します。
レプリケーションは非同期:フェイルオーバー時、ラグ分のデータが失われ得ます。セッションストアなど損失が許容できない用途では、この特性を前提に設計してください(新しいエンジンでは永続性オプションの有無も含め公式で最新仕様を確認)。
Multi-AZとAOFは排他:ElastiCacheではMulti-AZとappend-only file(AOF)を同時には有効化できません。
テストできる:test-failoverで本番同等のフェイルオーバー挙動を検証できます。設計しただけで検証しないのが一番危険です。

現場のコツ：「レプリカ0でMulti-AZ有効のつもり」という構成ミスは監査でよく見ます。レプリカがなければ自動フェイルオーバーは働きません。本番のキャッシュ/セッション層は、最低でも別AZに1レプリカ、を出発点にしてください。

06セッションストア用途 — 揮発前提を捨てる

ELB配下でステートレスにAPサーバをスケールさせる際、セッションをElastiCacheに外出しする構成は定番です。ただしキャッシュ用途と根本的に違うのは正データがRedis側にある点です。設計の勘所は次の通りです。

喪失=業務影響:フェイルオーバー時のラグ損失や全ノード障害でのデータ消失が、そのまま「全ユーザー強制ログアウト」になります。Multi-AZ+レプリカを前提に、要件次第で永続性の強いエンジン/オプションを検討します。
TTL=セッション有効期限:キャッシュのTTLと違い、業務上のセッション寿命そのもの。延長(スライディング)の実装有無を明確に。
キー設計:個人情報を平文で載せない、暗号化・最小化を徹底。転送時/保管時暗号化(TLS/at-rest)を有効化。

DB接続の枯渇対策と混同されがちですが、コネクション管理は別テーマです。RDS前段の接続集約はRDS Proxyによる接続管理を、DBそのものの選定はAurora/RDS選定を参照してください。

07Valkey/Redis OSSの動向 — 何を選ぶか

2024年以降、大きな地殻変動がありました。Redisのライセンス変更を受け、Linux Foundation配下でValkey(Redis OSS互換のフォーク)が立ち上がり、AWSもElastiCacheでValkeyを提供しています。EMWの見立てとして、新規はValkeyを基本線に据えて問題ない段階に来ています。

ドロップイン互換:ValkeyはRedis OSSの実質ドロップイン置換として提供され、既存クラスタからのアップグレード経路が用意されています(最新の移行手順・ダウンタイム条件は公式で確認)。
コスト優位:AWSは、Valkeyがサーバーレスで他エンジン比33%低価格、ノードベース(セルフデザイン)で20%低価格と案内しています。加えて新しいValkeyのメモリ効率改善によるノードダウンサイズを重ねると、条件次第で最大60%のコスト削減余地があるとされます(AWS Database Blog)。
互換性の確認は必須:とはいえ本番移行では、使用中のコマンド・モジュール・クライアントライブラリの互換性を必ず検証してください。「互換」を額面で信じず、ステージングでtest-failoverまで含めて通すのが実務です。

数値・料率はリージョンとバージョンで変わるため、必ず公式の最新料金で試算してください。

08コストの考え方 — 効くのはメモリとエンジン選択

ElastiCacheのコストは、突き詰めれば「どれだけのメモリ容量を、どの構成で確保するか」です。効かせどころを整理します。

右サイズ:キャッシュはメモリ使用率とエビクション、ヒット率を見て継続的に調整する対象です。過大なノードは無駄、過小はエビクション多発でヒット率低下。EvictionsやCacheHitRate系メトリクスをCloudWatchで監視します。
エンジン選択:前述の通りValkeyでエンジン単価が下がり、メモリ効率改善でノードを1段落とせる余地もあります。既存Redis OSSクラスタは移行検討の価値があります。
予約/セーバー:定常稼働が読めるなら予約系割引を活用。既存のRedis OSS予約をValkeyに引き継げるケースもあります(条件は公式で確認)。
サーバーレス vs ノードベース:トラフィックが読みにくい/スパイクが激しいならサーバーレス、定常で読めるならノードベース+予約、が素直な出発点です。

監視設計そのものの型は監視・アラート設計やCloudWatch監視の第一歩も併せて参照してください。

—まとめ

ElastiCache(Redis/Valkey)は、置くだけで速くなる部品ではなく、次の型を通して初めて「有事に強い」層になります。

用途(キャッシュ/セッション/データ構造)を切り分け、TTL方針とフェイルオーバー要件を分けて設計する。
cache-asideを基本に、鮮度が要るキーだけwrite-through/明示的無効化を足す。TTLは最終防衛線として揺らぎを持たせる。
スタンピードは「人気キーが今消えたらDBは何QPS受けるか」で必ず試算し、ジッター/single-flight/非同期リフレッシュで守る。
CMDで始めCMEは上限が見えてから。Multi-AZはレプリカ必須で、test-failoverまで検証する。
新規・既存ともValkey移行はコスト効果が大きいが、互換性はステージングで実測する。

「今のキャッシュ層、有事に耐えるのか」を一度棚卸ししたい場合は、EMWが設計レビューから移行まで手を動かして支援します。お問い合わせください。導入事例もあわせてご覧ください。

—参考(一次情報)

キャッシュ層の設計やDB前段の性能・可用性でお困りなら、お問い合わせください。現場で手を動かすコンサルとして、設計レビューから移行まで支援します。

相談する

← ブログ一覧へ戻る