本番DBとキャッシュを同じ物理サーバーに置くなら、128GBと256GBのどちらにする？

まず3つの使用量を足す

どちらも AMD EPYC 7543P、32コア / 64スレッド、2.8–3.7 GHz。128GBは月額 $449、256GBは月額 $599。 メモリはどちらも DDR4-3200 ECC RDIMM。注文時に決まり、あとからモジュールは足せない。 本番DBとキャッシュを同じ筐体に置くかどうかは、支払い前に計算する。あとから第3の容量へ上げる枠はない。

1台の上でメモリは少なくとも3つに分かれる。1つ目はOS、ページキャッシュ、接続そのもの。SSHで入ったあとの管理プロセスも含む。 2つ目はデータベースが常駐させたいホットデータ。MySQLでは主に InnoDB バッファプール。PostgreSQLでは shared_buffers に、OSが残すページキャッシュが加わる。 3つ目は Redis などキャッシュの maxmemory。アプリケーションも同じ筐体で動かすなら、その常駐量も引く。

3つを足し、余裕を残してから 128 と 256 を比べる。ディスク上のデータベース容量を、そのままメモリ要求にしない。 データディレクトリが 400GB でも、実際に読まれるホットデータは数十GBのことがある。逆に、ディレクトリは小さくてもキャッシュがオブジェクトの大半をメモリに載せるなら、128GBが先に不足する。 見るのはホットセットとキャッシュの目標であり、ディレクトリの合計サイズではない。

この記事は Linux 上の MySQL、PostgreSQL、Redis 向け。Windows Server を選んだ場合、SQL Server のメモリ上限は別に計算する。下のバッファプール比率を Windows に写さない。 Linux では SSH で入って設定を変える。ログイン方法はメモリ容量では変わらない。

128GBで足りる条件

128GBで足りるのは、次が同時に成り立つとき。ホットデータがバッファプールに収まり、ヒット率が安定している。 Redis はセッション、ホットキー、または上限のあるオブジェクトキャッシュで、目安は 8GB から 24GB。エビクションは許容範囲にある。 OS、接続、同居するアプリを足しても 16GB から 24GB 残る。半年先までホットデータは倍にならず、もう1つの大きなメモリサービスを載せない。

これは試算であり、容量の保証ではない。128GBではまず約 20GB をOSと接続に残す。 Redis を 16GB にするなら、データベースには約 90GB が残る。MySQL のバッファプールは 64GB から 80GB を起点にし、ページキャッシュと一時ソートの隙間を残す。 Redis が数GBなら、プールは 80GB に近づけてよい。Redis がすでに 24GB 必要なら、プールを 80GB より上に押さない。

PostgreSQL は shared_buffers を MySQL のバッファプールより低く置くことが多い。起点は物理メモリのおよそ4分の1で、残りはOSのページキャッシュに任せる。 同じホットデータなら 128GB に残せることもある。条件は、並行ソートとハッシュ集約が work_mem を大きなピークにしないこと。 1つのクエリに複数のソートノードがあり、同時実行数を掛ける。64MB に数十の並行なら、まだ余裕に収まることが多い。数百MBの work_mem に百を超える並行を重ねると、128GBの空きは埋まる。

256GBを選ぶ条件

次のどれか一つでも当たるなら 256GB を見る。バッファプールを 80GB 前後にしたいのに、Redis も数十GBほしい。 今のマシンで、データベースプロセスとキャッシュプロセスの常駐がすでに 90GB 前後か、それを超えている。 PostgreSQL の並行ソートが多く、work_mem に並行数を掛けると余裕が埋まる。 本番DBと Redis 以外に検索エンジンや、ヒープを大きく使うサービスを同じ筐体に置く。アプリを分けておらず、アプリだけで十数GBいる。

256GBの試算でも、まず 24GB から 32GB をOSと接続に残す。Redis が 32GB から 48GB なら、バッファプールは 120GB から 160GB に置ける。 これは起点。稼働後にヒット率、一時ファイル、Redis のエビクションを見て上限を戻す。 物理メモリの約9割をバッファプールに渡し、同じ筐体で大きな Redis を動かさない。両方が膨らむとスワップが始まり、ディスクに落ちたミスより原因が見えにくい。

月額の差は $150。四半期は $1,347 と $1,797、半年は $2,694 と $3,594、年額は $5,388 と $7,188。 期間は月額を月数で掛けるだけ。256GBを選んでも割引は付かない。メモリ不足でデータベースを移すコストは、たいていこの $150 より大きい。 今の使用量が 128GB の水位に近いなら、注文時に 256GB を選ぶ。ホットデータが集中し、ヒット率が高く、キャッシュが 8–24GB なら 128GB に残す。

手元の数字で照合する

本番か、前のホストで測った数字を表に入れる。右の列に一つでも当たるなら 256GB で準備する。5行とも左なら、今回の注文は 128GB で足りる。

ヒット率が高く、エビクションが許容でき、ホットデータが集中しているなら 128GB。ディスクでメモリの代わりをしている、または Redis がまだ必要なキーを捨てているなら 256GB。 数字が曖昧なら、前のホストの常駐メモリに 1.3 を掛けて伸びしろを見てから 128 と 256 を比べる。約 100GB 未満なら今回は 128GB。100GB を超えるなら 256GB。

導入後に上限を固定する

容量を決めたあとも、データベースとキャッシュの上限を設定に書く。書かないと InnoDB と Redis がそれぞれの初期値で、同じ物理メモリを取り合う。

1. 1
   3つの数字を書く

   データベースの常駐、Redis の used_memory、OSがまだ使えるメモリ。MySQL はバッファプールの読み取りヒット、Redis は used_memory と evicted_keys、PostgreSQL はキャッシュヒットと一時ファイルを見る。

2. 2
   プールと maxmemory を別々に上限する

   同居するなら、Redis が小さい場合を除き、InnoDB バッファプールは物理メモリのおおよそ6割から7割に収める。Redis には maxmemory とエビクション方針を置く。両方の上限を同時に置く。

3. 3
   ページキャッシュの隙間を残す

   バッファプールと Redis の上限の合計は、物理メモリからOSと接続を引いた値より下にする。128GBでは合計を約 100GB までで試す。256GBでは約 210GB までで試す。

4. 4
   稼働1週間後にもう一度見る

   スワップが増え続けるなら上限が大きすぎる。先にバッファプールか Redis を縮め、ヒット率を見る。ディスク読み取りがあっただけで、容量の選択が誤りだと決めない。

ディスクを足してもメモリは増えない

標準ディスクは 2 × 1TB NVMe。ハードウェア RAID はない。2本はそれぞれ直結で、使える容量は 2TB。ホットデータがメモリに乗らない読み取りは、このディスクに落ちる。 NVMe はミスを受け止める。レイテンシはメモリヒットより高い。追加の 2TB は1本あたり月額 $79、最大2本、やはり直結。増えるのは容量であり、メモリモジュールではない。 データファイルとバックアップをどう分けるかはディスクの話。メモリを選ぶときに「ディスクをもう1本」で 256GB の代わりにしない。

帯域もバッファプールを埋めない。標準は 250M で転送量無制限。1G は +$250、2G は +$750。変わるのは出口の速度。 本番DBとローカル Redis の通信はループバックで、この帯域を使わない。メモリと帯域は別の明細。 バックアップを筐体の外へ出すなら、その転送量で 250M が足りるかを見る。それは別の選択。

2つの機種のどこに当たるか

ホットデータ、キャッシュ、余裕を足したあと、注文画面にあるのはこの2つ。128GBは月額 $449、256GBは月額 $599。 CPUはどちらも EPYC 7543P、32コア / 64スレッド、2.8–3.7 GHz。メモリはどちらも DDR4-3200 ECC RDIMM。注文時に決まり、あとから増設しない。 サーバは日本の東京にある。Linux は SSH で入り、バッファプールと maxmemory を変える。初期費用はない。 支払額は月額に月数を掛けたもの。月額、四半期、半年、年額に追加の割引はない。この筐体のディスク追加と帯域も、同じ期間で前払いする。

合計が 256GB で余裕をもって収まる範囲をすでに超えているなら、大きなバッファプール、大きなキャッシュ、検索のヒープ、アプリを1台に詰め込まない。 キャッシュか検索を2台目に分ける。すべての上限を天井まで書くよりはっきりする。この記事が決めるのは、注文できる2つの容量のどちらにするかだけ。