キャッシュ層が隠している本当の負荷
事業譲渡の資料には、よく「月間数百万ページビューを、月額数千円のサーバー一台で捌いています」という一文が誇らしげに書かれています。運用が効率的で、原価が低く、だから利益率が高い——売り手はそう伝えたいわけですし、数字だけを見ればその通りです。ところが私たちは、この一文をしばしば警告として読みます。小さなサーバーで大きなトラフィックが回っているとき、その差を埋めているのはたいていキャッシュ層だからです。
キャッシュとは、一度計算した結果や取り出したデータを手元に置いておき、次に同じ要求が来たら計算やデータベース照会をやり直さずに、置いておいた答えをそのまま返す仕組みです。RedisやMemcached、あるいはCDN(コンテンツ配信網。世界中の拠点にコピーを置いて近くから配る仕組み)がその代表です。うまく効いているとき、本番のデータベースやアプリケーションサーバーは、実際のアクセス数のほんの一部しか相手にしていません。残りはすべてキャッシュが肩代わりしています。
つまり「小さなサーバーで回っている」という状態は、多くの場合「サーバーが優秀だから」ではなく「サーバーがほとんど仕事をしていないから」成立しています。この違いは、事業を持っている限り表には出ません。しかし所有者が変わり、環境が移り、設定が引き継がれ損ねた瞬間に、覆っていた布が剥がれます。買収後に最初に落ちるのは、たいていこのキャッシュ層に守られていた部分です。
「小さなサーバーで回っています」を、私たちは警告として読む
効率の良い運用と、隠された脆さは、外から見ると区別がつきません。どちらも「軽いインフラで大きな成果」という同じ見た目をしているからです。前者は本当にオリジン(キャッシュの後ろにある本体のサーバーとデータベース)が強く、キャッシュはあくまで上乗せの高速化として効いています。後者はオリジンが弱く、キャッシュが無ければそもそも成り立たない事業です。損益計算書の「サーバー費用」の数字だけでは、この二つを見分けられません。
見分けるには、キャッシュを剥がしたときに何が残るかを想像する必要があります。健全な事業なら、キャッシュを外しても表示が少し遅くなる程度で、機能は動き続けます。脆い事業では、キャッシュを外した瞬間にデータベースが飽和し、応答が止まり、サイトそのものが立ち行かなくなります。同じ「軽くて速いサイト」でも、片方は補助輪付きの自転車、もう片方は補助輪だけで立っている自転車です。
この記事では、キャッシュ層という一点に絞って、それが覆い隠している「本当の負荷」と「本当の原価」をどう見抜くかを扱います。買い手が数字の裏で確認すべきことであり、売り手が売ると決める前に自分で把握しておくべきことでもあります。
ヒット率99%は「オリジンは1%しか見ていない」ということ
キャッシュがどれだけ効いているかは「ヒット率」という数字で表せます。要求のうち何%をキャッシュだけで返せたか、という割合です。CDNの管理画面なら「Cache Ratio」、Redisなら INFO stats コマンドで出る keyspace_hits と keyspace_misses の比から計算できます。健全に運用されたサイトのCDNヒット率は90%台後半、静的コンテンツ主体なら99%を超えることも珍しくありません。
ここで立ち止まってほしいのです。ヒット率99%とは、裏を返せば「オリジンは、全アクセスのわずか1%しか見ていない」という意味です。月間三百万リクエストのサイトでも、オリジンが実際に処理しているのは三万リクエスト、秒あたりにすればごくわずか、という計算になります。売り手が見せる「小さなサーバーで回っている」実績値は、この1%を処理した記録にすぎません。
もう一つ注意したいのは、ヒット率は一つではないということです。CDNのヒット率と、その内側にあるアプリケーションキャッシュ(RedisやMemcached)のヒット率は別物で、さらにデータベース自身が持つクエリキャッシュやページキャッシュもあります。負荷は何段にも重なったキャッシュで削られており、外側のCDNヒット率だけを見て安心すると、内側の段が実は薄いという事態を見落とします。層ごとに、どの段がどれだけ削っているのかを分けて見る必要があります。
デューデリジェンス(買収前の実態調査。以下DD)でヒット率を確認するとき、高ければ安心という読み方は危険です。ヒット率が高いほど、オリジンの本当の実力は隠されています。99%という数字は「オリジンが強い」証拠ではなく「オリジンがほとんど試されていない」証拠です。買った後にこの1%が10%になっただけで、オリジンにかかる負荷は十倍になります。技術的負債がどう査定に響くかはSaaS売却で値引きされる技術的負債でも触れましたが、キャッシュ依存はその中でも特に見えにくい負債です。
キャッシュを剥がした瞬間の「素の負荷」── DBは1%用に組まれている
キャッシュが剥がれる、あるいは効きが悪くなると、それまでキャッシュが肩代わりしていた要求がそのままオリジンのデータベースに流れ込みます。問題は、そのデータベースが「1%だけを処理する前提」で組まれていることです。インスタンスのサイズ、同時接続数の上限、インデックスの張り方、放置されたスロークエリ——キャッシュに守られている間は、これらの粗が表面化しません。秒間数件しか来ないなら、多少重いクエリでも捌けてしまうからです。
私たちが繰り返し見てきたのは、こういう場面です。買収後、環境を新しいサーバーへ移す。ドメインを切り替える。ところがCDNの設定が完全には移っておらず、キャッシュが十分に温まっていない状態で本番のトラフィックが到達する。すると、これまで秒間数件しか見ていなかったデータベースに、いきなり本来の全負荷がぶつかる。接続が上限に達し、待ち行列が伸び、タイムアウトが連鎖し、サイト全体が応答を止めます。
さらに厄介なのが「キャッシュ雪崩」と呼ばれる現象です。多数のキャッシュが同じタイミングで期限切れになると、その瞬間に大量の要求が一斉にオリジンへ押し寄せ、同じ重いクエリが同時多発的に走ります。平常時なら一回で済む計算が、キャッシュが冷えた瞬間には数百回同時に走り、データベースを一気に飽和させます。この挙動は平常運用ではまず観測されないため、DD資料のどこにも記録が残っていません。DBそのものの引き継ぎ困難さはマイグレーション履歴のないDBの怖さで扱っていますが、キャッシュ依存はそのDBがどれだけ脆いかを平時には見せない、という別の問題です。
CDNが隠すのはトラフィックだけではない ── egress原価という時限爆弾
キャッシュ層が覆い隠すのは負荷だけではありません。インフラの原価も同じように隠します。CDNが要求の99%を返しているということは、オリジンから外へ出ていくデータ転送量(egress。サーバーから外部へデータが出るときにかかる従量課金の通信費)の大部分を、CDN側が肩代わりしているということでもあります。
ここに落とし穴があります。CDNの料金体系は事業者ごとにまったく違います。転送量課金がほぼ無いプランで運用されている事業を、買い手が自分の慣れた別のCDNへ移すと、それまでゼロだったegress費用が突然発生します。逆に、無料枠や旧料金の恩恵で成立していた原価が、移管に伴う契約の切り替えで数倍になることもあります。損益計算書に載っている「サーバー費用」は、その事業者が偶然使っていた料金体系での数字であって、買い手が引き継いだときの数字ではありません。
画像や動画、ファイルダウンロードを多く含む事業ほど、この差は大きく出ます。DDでは「今いくらか」だけでなく「自分の環境に移したらいくらになるか」を、実際の月間転送量から見積もり直す必要があります。オリジンが外部サービスにどれだけぶら下がっているかという観点はWebサービス売却で効く第三者API依存と地続きで、CDNもまた、条件次第で原価が跳ね上がる第三者依存の一つです。
Redisが単一障害点になっている事業 ── 落ちたら全滅する設計
キャッシュは本来、性能を上げるための「あれば速い」補助装置です。ところが長く運用されるうちに、いつのまにか「無いと動かない」必須装置に変質していることがあります。この転倒は静かに進むため、運用している当事者すら気づいていないことが多いのです。
典型的なのは、Redisをキャッシュとしてだけでなく、セッション管理(ログイン状態の保持)、非同期処理の待ち行列、レート制限のカウンタなど、失われては困るデータの置き場としても使っている構成です。この状態でRedisが落ちると、単に表示が遅くなるのではなく、全員がログアウトされ、処理が止まり、サイトが機能を失います。「キャッシュだから落ちても平気」という一般的な想定が、この事業では成り立っていません。キャッシュだったはずのものが、いつのまにか事業の中枢データを握る単一障害点になっているわけです。
DDでは、キャッシュ層が落ちたときに何が起きる設計になっているかを必ず確認します。コードを読み、キャッシュに接続できなかったときのフォールバック(代替動作)が書かれているか、それとも例外を投げて止まるかを見ます。買収前にコードから読み取れる危険信号についてはサイト買収前に見るべきコードの兆候で整理していますが、キャッシュへの接続失敗をどう扱っているかは、その中でも設計の成熟度がはっきり出る箇所です。
TTLの長さは「鮮度」と「負荷」のトレードオフを覆い隠す
キャッシュには「TTL」(Time To Live。置いた答えを何秒間有効とみなすか)という設定があります。TTLを長くすれば、同じ答えを長く使い回せるのでオリジンの負荷は下がりますが、その分だけ表示されるデータが古くなります。TTLを短くすれば鮮度は上がりますが、オリジンに問い合わせる回数が増えて負荷が上がります。この綱引きの結果が、外から見える「軽くて速いサイト」です。
問題は、この綱引きが極端に「負荷を下げる」側へ倒されている事業があることです。たとえば在庫数や価格、残席のような、本来は最新であるべき情報に、数十分単位の長いTTLがかかっている。表面上はキビキビ動いて見えますが、それは古い答えを返し続けることで負荷を隠しているだけです。買い手がTTLを常識的な長さに詰めた途端、隠れていた負荷が姿を現します。
DDでは、主要なページや機能ごとにTTLが何秒に設定されているかを一覧化し、「なぜその長さなのか」を問います。事業上の要請から選ばれた値なのか、それともオリジンが耐えられないから仕方なく延ばした値なのか。後者であれば、その長いTTLは負荷問題を先送りにしているだけで、鮮度が事業価値に直結する場面では買収後に必ず短くせざるを得ず、そこで負荷が噴き出します。TTLの設定値は、その事業がオリジンの弱さをどれだけ鮮度で補っているかを映す鏡です。
移管の瞬間、キャッシュは必ず冷える ── コールドスタートで初日に落ちる
どれだけ設計が健全でも、事業の移管では避けられない一点があります。キャッシュは移管の瞬間に必ず冷える、ということです。キャッシュに溜まっているのは、これまでの運用の中で少しずつ蓄積された「よく使われる答え」の集まりです。この中身は、サーバーを移し、ドメインを切り替え、環境を作り直せば、原則としてゼロから溜め直しになります。
この「キャッシュが空の状態」をコールドスタート、あるいはコールドキャッシュと呼びます。切り替え直後の数分から数十分、キャッシュが空のままトラフィックだけが本来の量で到達すると、そのすべてがオリジンに向かいます。平常時のヒット率99%は、あくまでキャッシュが温まりきった後の数字であって、切り替え直後は0%から始まります。この初日の谷を越えられずに落ちる案件を、私たちは何度も見てきました。
だからこそ移管計画には「キャッシュを事前に温める(キャッシュウォーミング)」手順が要ります。主要なURLを切り替え前にあらかじめ巡回してキャッシュを作っておく、トラフィックを段階的に流す、切り替えは負荷の低い時間帯を選ぶ——こうした地味な段取りが、初日の可否を分けます。引き渡し後に問題が始まる構造そのものはサイト売買の失敗は引き渡し後に始まるで扱いましたが、コールドキャッシュはその中でも、準備次第で確実に避けられるのに最も見落とされやすい失敗です。
DDでキャッシュ依存度をどう測るか ── ヒット率・素の実性能・原価の三点
ここまでの話を、買い手が実際に確認できる手順として三点に整理します。第一に、キャッシュ依存度そのものです。CDNとアプリケーションキャッシュそれぞれのヒット率を、直近数ヶ月分、できれば時間帯別に取得します。ヒット率が高いほどオリジンは試されていない、という前提で読み、「もしこれが下がったら」を常に併記して考えます。数字が高いことに安心するのではなく、その高さが何を隠しているかを問うのがこの一点です。
第二に、オリジンの素の実性能です。可能なら検証環境でキャッシュを意図的に無効化し、あるいは k6・wrk・Apache Bench といった負荷試験ツールで一定のリクエストを直接オリジンへ投げて、どこまで捌けて、どこで壊れるかを実測します。ここで見るのは平均応答時間よりも、応答が急に悪化し始める折れ点(この同時接続数を超えると詰まる、という境界)と、その時にデータベースのCPU・接続数・待ち行列がどう動くかです。それが難しければ、少なくともデータベースのインスタンス構成、同時接続数の上限、スロークエリの記録を取り寄せ、「1%用の構成」がどの程度の余力を持っているかを見積もります。ここで得た「素の負荷」の数字こそが、キャッシュに覆われる前の、その事業の本当の姿です。
第三に、原価の再計算です。現在のサーバー費用やCDN費用は、その事業者が使っている料金体系の下での数字にすぎません。買い手自身の環境と契約に移したとき、egress費用やキャッシュ用インスタンスの費用がどう変わるかを、実際の転送量とリクエスト数から積み直します。この三点——依存度・素の実性能・移管後の原価——を揃えて初めて、キャッシュ層が覆っていた本当の負荷と原価が見えてきます。売り手にとっても、これらを事前に自分で把握し、キャッシュの効き方を説明できる状態にしておくことが、買い手の不安を減らし、引き渡し後のトラブルを避ける最短の道です。
キャッシュに覆われた事業の「素の負荷」と移管後の原価を、買う前に、あるいは売る前に把握しておきたいときは、AI技術デューデリジェンスで、キャッシュ依存度やオリジンの構成といった技術面の兆候を確認できます(登録不要)。
