こんにちは！Redisの奥深い世界へようこそ。
今日は、Redisが裏側でやっている「メモリを極限まで節約する職人技」についてお話ししますね。
「Redisはとにかく速い」というのは、あなたも耳にしたことがあるかもしれません。その秘密は、データをすべてメモリ（RAM）の上に載せているからです。でも、メモリというのは無限にあるわけではありません。高価で、かつ有限な資源です。
「どうすれば、限られたメモリにたくさんのデータを詰め込めるだろう？」
この難問に対してRedisの設計者たちが編み出した、最も美しい発明の一つが「Ziplist（ジップリスト）」です。
ここをクリアすれば、Redisのメモリ管理の基本はバッチリマスターできますよ。難しい専門用語はなるべく使わずに、身近な例えで紐解いていきましょう！
—
1. Ziplistってなに？日常の例えで理解しよう
まずは、普段私たちがやっている「荷物のパッキング」を想像してください。
例えば、引越しをするときに、小さめのダンボール箱に、細々とした小物を隙間なくギュッと詰め込んだことはありませんか？ お皿とスプーンとフォークを、緩衝材を挟みながら一つの箱にパズルみたいにきれいに並べるイメージです。
Redisの通常の状態（リンクトリストなど）は、いわば「一人暮らしの家具付きアパートがバラバラに点在している状態」です。それぞれの部屋に管理人がいて、次の部屋への案内図を持っているため、管理コスト（メモリのオーバーヘッド）が余計にかかります。
一方、Ziplistは「一つの長細いカプセル（連続したメモリ領域）」です。
その中に、データを隙間なく、文字通り「ジッパーを閉じるように」ピタッと並べて格納します。これがZiplistの正体です。
2. Ziplistの巧妙なメモリレイアウト
Ziplistがすごいのは、メモリの無駄な隙間を徹底的に排除している点です。
通常のデータ構造だと、コンピュータの都合上「4バイトの倍数」や「8バイトの倍数」で区切る必要があり、データの間に「何の意味もない空白（パディング）」が生まれがちです。
しかし、Ziplistは違います。
「このデータは数字だから2バイトあれば十分だな」「次のデータは短い文字列だから5バイト分だけ場所を取ろう」といった具合に、必要な分だけのサイズを切り出して、1列にベタッと並べるのです。
構造をざっくり図解すると、こんなイメージです：
[ 전체サイズ ] [ 末尾までのオフセット ] [ 要素の数 ] [ データ1 ] [ データ2 ] … [ データN ] [ 終了を示すマーカー ]
- 無駄なポインタ（矢印）がない：普通なら「次のデータはこのアドレスにある」という矢印をデータごとに持たせますが、Ziplistはデータが連続して並んでいるため、矢印すらいりません。「次のデータ読みたかったら、今のデータのサイズ分だけ右にズレればいいよね」という算数で解決します。
これが、メモリ効率が爆発的に良くなる理由です。
3. いつZiplistは使われるの？
Redisのすべてのデータが最初からZiplistで保存されるわけではありません。Ziplistは、以下の3つのデータ型（の初期状態）で裏方として活躍しています。
1. List（リスト）：タイムラインやキューなど
2. Hash（ハッシュ）：ユーザー情報などのオブジェクト（名前、年齢、性別など）
3. Sorted Set（ソート済みセット）：ランキングなど
「じゃあ、ずっとZiplistを使えばいいじゃない！」と思いますよね？
実は、Ziplistには「大きくなりすぎると、かえって効率が落ちる」という弱点があります。
4. 限界が来たら変身する！「エンコーディング変換」の仕組み
Ziplistは「コンパクトで省スペースだけど、中身を探すときに端から順番に見る必要がある（＝データ数が多いと遅くなる）」という特徴があります。
そのため、Redisは「少量のデータのときはZiplistで省エネに、大量のデータのときは別の構造（高速に検索できる構造）に自動で変身する」という賢い仕組みを持っています。
この変身ルールの境界線は、Redisの設定ファイル（`redis.conf`）で次のように厳密に決められています。
ハッシュ（Hash）の例
- `hash-max-ziplist-entries 512` （要素数が512個以下）
- `hash-max-ziplist-value 64` （各データの文字数が64バイト以下）
この条件を満たしている間は、RedisはせっせとZiplistを使ってメモリを節約します。
しかし、例えば要素数が「513個」になった瞬間、あるいは65バイト以上の長い文章が突撃してきた瞬間、Redisは裏側でこう判断します。
> 「おっと、これ以上このカプセルに詰め込むと、中身を探すのに時間がかかりすぎるぞ。よし、通常の構造（ハッシュテーブル）にデータを引っ越そう！」
この瞬間、メモリ上で「Ziplistから別の構造へのデータお引越し（エンコーディング変換）」が実行されます。
—
5. 実務で活きる！知っておくべき注意点
私たちが実際にRedisを運用する上で、このZiplistの仕組みを知っていると、何が嬉しいのでしょうか？
それは、「メモリの節約とパフォーマンスのバランスをコントロールできる」ということです。
もし、あなたが扱うハッシュデータが「数万件あって、どれもフィールド数が2〜3個しかない」という場合、デフォルトのままだとすべてZiplistで保持され、驚異的なメモリ節約になります。
逆に、「1つのハッシュの中に、数千個ものフィールドを詰め込んでいる」ような使い方をすると、Redisは常に「Ziplistの肥大化と戦い、頻繁にエンコーディング変換やメモリの再割り当てを行う」ことになり、CPUに負荷がかかってしまいます。
設定チューニングの指針
- メモリを極限まで節約したい（かつ、要素数がそれほど爆発的に増えない）場合は、設定値を少し緩める。
- 巨大なコレクションを扱うことが最初から分かっている場合は、最初からZiplistを使わせないような設計にするか、適切なサイズ制限を設ける。
—
まとめ
いかがでしたでしょうか？
RedisのZiplistは、限られたメモリを1バイトたりとも無駄にしないという、開発者たちの執念と工夫が詰まった素晴らしい技術です。
- Ziplistとは：データを隙間なく連続して並べ、ポインタの無駄を省いた「超圧縮パッキング構造」。
- 得意なこと：データ量が少なく、サイズが小さいデータの保存（メモリ激減！）。
- 自動変身：データが大きくなりすぎると、検索スピードを維持するために、自動的に別の構造へお引越しする。
この仕組みを知っているだけで、Redisのメモリ使用量を見たときに「お、いま綺麗にパッキングされてるな」「おや、そろそろお引越しのタイミングだな」と、裏側の状態が手に取るように分かるようになります。
Redisの仕組みが少し身近に感じられたなら嬉しいです。
明日からの設計やチューニングに、ぜひこの知見を役立ててくださいね！
コメント