キャッシュ

同じ答えを再利用する

席の予約サービスでは、同じ公演の空席数が何度も読まれます。毎回データベースで同じ集計をする代わりに、一度作った答えを保存して再利用できます。

この再利用する答えがキャッシュです。答えがあればそこから返し、なければデータベースを読んで答えを作り、次の要求のために保存します。

同じ公演への問い合わせが多いほど、同じ集計を省けます。公演ごとに答えを分け、別の公演の空席数を返さないようにします。

予約や取り消しで空席数が変わると、保存した答えは古くなります。そこで、読む場面ごとに許せる古さを決め、使える期限や更新時の消し方を選びます。

今回は公演一覧や座席表の表示なら3秒の遅れを許すとします。表示を見た利用者が予約するときは、実際には埋まっている可能性を踏まえて結果を返します。

予約の確定には古い空席数を使えません。保存先で最新の在庫を確かめ、同じ席をほかの予約が取れない形で確定する必要があります。

ヒット率と古さを分けて見る

問い合わせのうちキャッシュで答えられた割合を、ヒット率と呼びます。手元で答えた件数を、問い合わせの総件数で割って求めます。

高ければ保存先への読み取りは減りますが、値の新しさは割合だけでは分かりません。期限を延ばして古い値を返し続けても、ヒット率だけは上がるからです。

一方、更新時に消す仕組みなどで新しさを保ち、ヒット率を高くできる場合もあります。許せる古さを満たしたうえで、読み取りがどれだけ減ったかを測ります。

予約サービスで解いてみる

DAU3万人、1人1日6回の要求から、平均を約2 QPSと丸めます。ピーク係数50で100 QPSを置き、毎秒40件のアプリ1台で足りないという規模を引き継ぎます。

その100件のうち、空席表示の読み取りが80件あり、64件をキャッシュで返せたとします。式は、手元で答えた件数を読み取りの総件数で割る、です。

64 ÷ 80 ＝ 0.8 なのでヒット率は80パーセントです。この読み取りが1件につき保存先を1回読む仮定なら、保存先へ行くのは80 − 64 ＝ 毎秒16件になります。

残る20件の要求は、この計算に含めていません。予約確定の読み書きは続き、アプリも要求を受けるため、保存先が楽になっただけで1台に戻せるとは言えません。

月5万円の予算と、表示を3秒まで古くできる条件を照合します。読み取りの待ちが減ったかを測り、キャッシュの費用を払う理由があるときに採用します。