AWS 25：キャッシュ ― ElastiCache で DB を休ませる

キャッシュ＝よく使う答えを、手の届く所に置いておく

キャッシュを、図書館で調べものをする場面にたとえてみます。

必要な本はすべて奥の書庫にあります。書庫には何でもそろっていますが、取りに行くのに時間がかかります。そこで、よく調べることは机の上のメモに書き写しておきます。次に同じことを調べたくなったら、まずメモを見ます。メモにあれば書庫へ行かずに済みます。

ここで大事なのは、キャッシュは正本ではなく写しだということです。キャッシュが消えても、書庫（DB）から写し直せば元に戻ります。逆に言えば、キャッシュにしか無いデータを作ってはいけません。

そして、写しである以上、古くなる瞬間が必ずあります。キャッシュを使うことは、「速さ」を手に入れる代わりに「少し古いかもしれない」を引き受けることです。この章の後半は、ほとんどがこの「古さ」との付き合い方の話です。

メモにあれば、DB には行かない（ヒット）

では、キャッシュを置いたフォトログの動きを見ていきます。図の舞台は、左から利用者、アプリ（Web サーバー）、右上がキャッシュ、右下が DB です。

利用者がトップ画面を開くと、アプリは DB に聞く前に、まずキャッシュに「timeline:new という名前で答えを持っていますか」と聞きます。この名前をキーと呼びます。キャッシュは、キーと値（答え）の組を覚えておく、単純な仕組みです。

ヒットした場合、DB は一度も働きません。キャッシュはメモリから読むので、DB で並べ替えるよりずっと速く返せます。

全体のうち、ヒットした割合をヒット率と呼びます。ヒット率が 95% なら、DB に届く問い合わせは元の 20分の1 になります。人気のある画面ほど同じ答えが何度も求められるので、ヒット率は上がりやすくなります。

ElastiCache のヒット数・ミス数は CloudWatch（第17章）のメトリクスで見られます。キャッシュを入れたら、ヒット率と、DB の CPU がどれだけ下がったかを必ず確かめましょう。

メモに無ければ、DB で調べてメモに写す（ミス）

キャッシュに答えが無かった場合です。図の番号の順に動きます。

次に同じ画面を開いた人は、①でヒットします。つまり、DB が働くのは「期限が切れた後の最初の1人」の分だけです。

このやり方をキャッシュアサイド（cache-aside、脇に置いたキャッシュ）と呼びます。アプリが「先にキャッシュ、無ければ DB、答えを写す」を自分で行う、いちばん基本の型です。

キャッシュアサイドのよいところは、キャッシュが止まっても、アプリは DB に直接聞けば動き続けられることです。遅くはなりますが、止まりはしません。キャッシュを「無くても動く部品」にしておくと、壊れたときに慌てずに済みます。

もう1つの型に、DB に書くたびにキャッシュにも同じ値を書くライトスルーもあります。常に新しい写しを持てますが、読まれないデータまで写すことになります。まずはキャッシュアサイドから始めるのが一般的です。

キャッシュの置き場所は1つではない

実は、キャッシュは ElastiCache だけではありません。利用者から DB までの道の途中、あちこちに置けます。

図の左ほど利用者に近く、速く返せます。そのかわり、一度配った写しを消しにくくなります。右ほど正本に近く、新しい答えを返せますが、遅くなります。

フォトログでは、写真そのものは一度上げたら変わらないので、CloudFront に任せます（第15章）。一方、タイムラインやいいね数のように、数秒ごとに変わったり、人ごとに違ったりするものは、CloudFront では扱いにくい。これを受け持つのが、アプリと DB の間に置く ElastiCache です。

「何を、どこに置くか」は、どれだけ古くてもよいかとどれだけ速くしたいかの釣り合いで決めます。1か所に全部を置くのではなく、ものごとに向いた場所を選びます。

アプリのメモリに置くと、台数ぶんの「違う答え」ができる

「キャッシュなら、アプリのメモリに置けば、別のサービスを借りなくて済むのでは」と思うかもしれません。サーバーが1台なら、それでも動きます。

しかし、フォトログは第11・12章で、ALB の後ろに複数台のサーバーを並べ、Auto Scaling で台数を増減する形にしました。ここでメモリにキャッシュを置くと、次のことが起きます。

台数が増えるほど、同じ答えを台数ぶん写すことになり、DB の負担も思ったほど減りません。

アプリのメモリに置いてよいのは、全台で少しずれていても困らず、めったに変わらないもの（アプリの設定など）です。利用者が見るデータを置くなら、台の外に置く必要があります。

だから、全台が見る「共有のキャッシュ」を1つ置く

解決策は、キャッシュをサーバーの外に出し、全台が同じキャッシュを見ることです。

図では、アプリ 1 もアプリ 2 も、同じ ElastiCache に聞いています。どちらの台に振り分けられても、返ってくるいいね数は同じ 12 です。書き込みがあったときに消すのも、ElastiCache の1か所だけで済みます。

これは、第12章で学んだステートレス（サーバーに状態を置かない）と同じ考え方です。第12章では「セッションや画像をサーバーに置かない」と言いました。画像は S3 へ出しました。セッションの置き場として、ここで ElastiCache が出てきます（後で説明します）。

サーバーの外に「速い共有の置き場」が1つあると、Web サーバーは本当に使い捨てにできます。台が壊れて入れ替わっても、利用者はログインし直す必要がなく、キャッシュもそのまま使えます。

ElastiCache：メモリの置き場を借りるサービス

Amazon ElastiCache は、メモリ上の置き場（インメモリのキー・値ストア）を、AWS が面倒を見る形で借りられるサービスです。RDS（第13章）が DB サーバーの世話を肩代わりしてくれたのと同じで、故障した機械の交換や、ソフトの更新を AWS が行います。

中で動く仕組みをエンジンと呼び、3つから選びます。

少し事情を説明します。Redis は長くキャッシュの定番でしたが、2024年にライセンス（使ってよい条件）が変わりました。それを受けて、元の自由な条件のまま開発を続けるために分かれたのが Valkey です。Valkey は Redis と同じ命令で話せるので、Redis 用のライブラリからそのまま使えます。

Valkey と Redis OSS は、複製（レプリカ）と自動切り替えに対応し、数・リスト・順位表のようないろいろな形のデータを扱えます。Memcached は複製ができないので、ノードが壊れるとその中身は消えます。フォトログでは Valkey を選びます。

サーバーレスか、ノードを選ぶか

ElastiCache には、作り方が2通りあります。

サーバーレスは、名前と置き場所（VPC とサブネット）を選ぶだけで作れる形です。量が増えれば自動で大きくなり、最初から複数の AZ（第2章）に写しが置かれます。接続先は1つだけで、裏で機械が増えても減っても、アプリは気にしなくて済みます。

ノード型は、ノード（キャッシュ用のサーバー）の種類と台数、置く AZ を自分で決める形です。細かい設定を変えたいときや、量が安定していて、ずっと同じ大きさで動かすほうが安くなるときに選びます。

迷ったらサーバーレスから始めるのがおすすめです。容量の見積もりが要らず、複数 AZ の設計も自動で済みます。使い方が落ち着いて、量が読めるようになってから、ノード型のほうが安くならないかを見直せば十分です。

どちらも VPC（第5章）の中に置く部品です。インターネットから直接つなぐものではなく、同じ VPC の中のアプリから使います。

期限（TTL）：どれくらい古くてもよいかを決める

ここからが、キャッシュでいちばん大事な話です。キャッシュは写しなので、DB が変わった後も、しばらく古い写しを返してしまいます。

図の時間の流れで見てみます。

この期限を TTL（Time To Live、生きていてよい時間）と呼びます。TTL は、言い換えれば「最大でこれだけ古い答えを返してもよい」という約束です。

TTL に正解はありません。画面ごとに「何秒古くても、利用者は困らないか」を考えて決めます。新着の写真が30秒遅れて出ても、誰も困りません。一方、自分がいいねしたのに数字が増えないと、利用者は「押せなかった」と思って何度も押すかもしれません。そういう画面には、次に説明する「書いたら消す」を組み合わせます。

変わったら消す：書いたときにキャッシュを捨てる

TTL を待たずに、DB を書き換えたときに、関係するキャッシュを自分で消すこともできます。これを無効化（invalidation）と呼びます。

フォトログで、誰かがいいねした場合を図で見ます。

キャッシュの値を「12 に書き換える」のではなく「消す」のがおすすめです。書き換えにすると、アプリが同時に2つ動いたときに、古いほうが後から書いてしまう、といった食い違いが起きやすいからです。消しておけば、次に読んだ人が必ず DB の最新を写します。

順番も大事です。先に DB に書き、それからキャッシュを消します。逆に「先に消して、後で DB に書く」と、消した直後から DB に書くまでの短い間に別の人が読みに来て、古い値を写し直してしまうことがあります。

それでも、消し忘れやエラーで消せないことはあります。だから、無効化をするときも TTL は必ず付けておきます。消し忘れても、TTL が来れば自然に直ります。「書いたら消す」と「期限で消える」の2段構えにしておくのが安全です。

セッションや順位表の置き場にもなる

ElastiCache は、DB の答えの写しを置くだけの場所ではありません。「速く、何度も読み書きする、小さなデータ」の置き場としても使えます。

1つ目はセッションです。セッションとは、ログインした人に渡す「入場券の番号」と、「その番号は誰のものか」の対応のことです。これをサーバーのメモリに置くと、別の台に振り分けられた瞬間にログインが切れます。ElastiCache に置けば、どの台からでも同じ入場券を確かめられます。セッションはログインの有効期間が過ぎたら不要になるので、TTL をその期間に合わせます。

2つ目は順位表です。Valkey には、値に点数を付けて、点数順に並べたまま覚えておくソート済みセットという形があります。

ZINCRBY likes:today 1 photo:123   # photo:123 の点数を +1
ZREVRANGE likes:today 0 9          # 点数の高い順に10件

いいねのたびに点数を足しておけば、「今日の人気の写真」を DB で毎回並べ替えずに取り出せます。この場合、キャッシュというより、速さのために使う集計の置き場です。消えても DB から数え直せるようにしておけば安心です。

ほかにも、「1分間に何回投稿したか」を数えて連投を止める回数制限などにもよく使われます。

作り方：VPC の中に置き、アプリの SG からだけ通す

コンソールでサーバーレスのキャッシュを作る流れは、次のとおりです。

6379 番は、Valkey と Redis が使う標準のポート（第8章。サーバーの中の窓口の番号）です。SG で「0.0.0.0/0（どこからでも）」を許すのは絶対に避けます。SG から SG を許せば、Web サーバーが何台に増えても設定を変えずに済みます。

サーバーレスは通信が必ず TLS（暗号化）なので、アプリ側のライブラリでも TLS を有効にしてつなぎます。

アプリの中は、図の右のようなコードになります。cache.get で探し、無ければ DB から読み、cache.set で書いて返します。"EX", 30 の部分が TTL（30秒）です。IaC（第18章）で書く場合も、作るものは同じ「キャッシュ本体・サブネット・SG」の3つです。

フォトログでは、何をどこに、何秒置くか

ここまでをまとめて、フォトログで実際に何をキャッシュするかを決めます。

判断の基準は3つです。全員に同じか（人ごとに違うなら、キーに利用者 ID を入れる）、よく読まれるか（たまにしか読まないならヒットしない）、少し古くても困らないか。

逆に、キャッシュに置かないものもあります。お金の残高、在庫、権限（この人がこの写真を消してよいか）のように、古い値を使うと事故になるものは、毎回 DB で確かめます。

また、投稿した本人が直後に自分のページを開いたとき、キャッシュのせいで自分の写真が出ないと「投稿に失敗した」と思われます。本人の画面は、投稿直後だけキャッシュを使わない、消してから表示する、といった工夫をします。

お金：何に払うのか

ElastiCache の料金は、作り方によって単位が違います。

ECPU（ElastiCache Processing Unit）は、サーバーレスの処理の量を数える単位です。簡単な読み書きなら、やり取りするデータ 1KB あたり 1 ECPU が目安で、重い命令ほど多く数えられます。

サーバーレスは、データが少なくても1つのキャッシュあたりの最低の計量があります。この最低ラインは Valkey のほうが小さく、単価も Valkey のほうが Redis OSS・Memcached より安く設定されています。新しく作るなら Valkey を選ぶ理由の1つです。単価そのものは変わることがあるので、料金ページと Pricing Calculator（第4章）で確かめてください。

ノード型は、使っていない夜中も、置いている台数分の料金がかかります。複数 AZ にするためにレプリカを足すと、その分も増えます。

お金の面では、キャッシュは「足すと費用が増えるもの」ですが、同時に「RDS を大きくしなくて済む」ものでもあります。DB の CPU が足りないとき、大きな DB に替えるより、キャッシュでよく読む画面を肩代わりするほうが安いことはよくあります。DB の費用と合わせて比べるのがコツです。

よくある落とし穴

キャッシュは、うまく働いているときは目立ちません。壊れ方を知っておきましょう。

1つ目は特に危険です。キャッシュのおかげで DB が小さくても回っていると、キャッシュが空になった瞬間に、本来の負荷が一気に DB に戻ってきます。キャッシュは速さのための部品であって、DB の能力の代わりではありません。

2つ目は、情報流出の事故になります。個人ごとの情報をキャッシュするときは、キーの作り方をチームで決めておきましょう。

いつ ElastiCache を足すか

キャッシュは便利ですが、最初から置く部品ではありません。「古さ」という新しい悩みを連れてくるからです。

足すかどうかは、監視（第17章）で原因を確かめてから決めます。

判断の問いは、「その遅さは、同じ仕事の繰り返しから来ているか」です。そうなら、キャッシュがよく効きます。そうでないなら、キャッシュは問題を隠すだけです。

片付け：消す順番

ElastiCache は、何も読み書きしていなくても、置いているだけで課金されます（サーバーレスは最低の計量分、ノード型は台数分）。練習で作ったら、その日のうちに消しましょう。

CLI（第1章の CloudShell など）なら、サーバーレスのキャッシュは次の1行で消せます。

aws elasticache delete-serverless-cache --serverless-cache-name photolog-cache

ノード型の場合は、レプリケーショングループ（主とレプリカのまとまり）ごと削除します。

また、バックアップ（スナップショット）を取っていた場合、それも保存している間は課金されます。要らなければ一緒に削除します。

アプリの設定にキャッシュの接続先を書いたままにしておくと、キャッシュアサイドの作りなら DB に直接聞いて動き続けますが、毎回つなごうとして失敗する分だけ遅くなります。練習後は設定も戻しておきましょう。