Redisのメモリ効率を極限まで高める：Intset最適化の裏側と設計の急所
こんにちは。開発チームの設計レビューをしていると、メモリ効率への配慮が欠けたデータ構造の選定によく直面する。特に「とりあえずSet型を使えばいいや」という安易なアプローチは、大規模システムにおいては数ギガバイト単位の無駄なメモリ消費、ひいてはGCプレッシャーやスワップ多発によるレイテンシ悪化を引き起こす時限爆弾になり得る。
Redisは、単に「高速なインメモリKVS」として使うだけなら素人でも扱える。しかし、その内部表現（Encoding）の特性を理解し、メモリとCPUのトレードオフをコントロールしてこそ、プロのエンジニアと言える。
今回は、RedisのSet型が内部で隠し持つ秘密兵器、「Intset（整数セット）」のメカニズムと、その限界点、そして実務でどうチューニングすべきかを徹底的に解説しよう。
—
1. Intsetとは何か？ なぜ標準のSetではないのか？
Redisの `SET` 型は、デフォルトではハッシュテーブル（Hash Table）として実装されている。O(1)の極めて高いルックアップ性能を誇る一方で、ハッシュテーブル特有のポインタオーバーヘッド（各エントリのメタデータ、メモリ断片化など）を伴う。
もし、保持するデータが「純粋な整数のみ」であり、かつ「要素数が少ない」場合、このハッシュテーブルを使うのはメモリの無駄遣いだ。
そこでRedisは、整数の集合をメモリ上の単一の連続した領域（Contiguous Memory Block）に密にパッキングする Intset という内部データ構造を自動的に採用する。
Intsetのメモリレイアウトの美しさ
IntsetのC言語レベルでの構造体（`intset`）は、おおむね以下のようになっている。
typedef struct intset {
uint32_t encoding; // 整数のサイズ（INTSET_ENC_INT16, INTSET_ENC_INT32, INTSET_ENC_INT64）
uint32_t length; // 格納されている要素数
int8_t contents[]; // 可変長の連続したメモリ領域
} intset;
ここでの最大の肝は `contents` がポインタの配列ではなく、「ソートされた数値そのものの連続配列」である点だ。
ポインタを持たないため、ポインタサイズ（64bit環境なら8バイト）のオーバーヘッドが完全に消滅する。さらにメモリが完全に連続しているため、CPUキャッシュヒット率が劇的に向上する。
探索には 二分探索（Binary Search） が使われるため、時間計算量は $O(\log N)$ となる。数千件程度のエントリ数であれば、ハッシュの $O(1)$ と遜色ない速度で動作しつつ、メモリフットプリントを極限まで圧縮できる。
—
2. 自動昇格（Promotion）のメカニズム
Intsetの最もエレガントかつ注意すべき特性が、「自動昇格」だ。
Intsetは、保持する数値の最大値・最小値に合わせて、エンコーディングのビット幅を動的に変更する。
1. `INTSET_ENC_INT16` (-32,876 ～ 32,767)
2. `INTSET_ENC_INT32` (-2,147,483,648 ～ 2,147,483,647)
3. `INTSET_ENC_INT64` (超巨大な整数範囲)
最初は小さなビット幅（例：`INTSET_ENC_INT16`）でメモリを節約しているが、その範囲を超える整数（例：`50000`）が `SADD` された瞬間、Redisは裏側で何を行っているか？
1. メモリ領域の再確保（Reallocation）を行い、全体のサイズを拡張。
2. 既存の全要素を新しいビット幅に合わせて再配置（アップグレード）。
3. 新しい要素を追加。
この処理は `contents` 全体の再配置を伴うため、コストは $O(N)$ となる。
「Intsetの途中での昇格はコストがかかる」ということは、アーキテクトとして必ず頭に入れておかなければならない事実だ。
—
3. 実務の急所：`set-max-intset-entries` のチューニング
Redisのデフォルト設定では、Intsetの恩恵を受けられる境界値が `redis.conf` で以下のように定義されている。
set-max-intset-entries 512
これは、「Setの要素数が 512個以下 で、かつ すべての要素が整数 である場合、Redisは自動的にハッシュテーブルではなくIntsetとしてメモリ上に保持する」という意味だ。
この閾値をどう設計すべきか？
開発プロジェクトのレビューで、「とりあえずデフォルトのままでいいや」というコードを見つけたら、私はこう問い質す。
「そのSetに入る要素の性質とサイズを計測したか？」と。
ケーススタディ A: ユーザーの権限IDリスト（要素数：約200個）
- データ: `[1001, 1045, 2099, …]`（すべて32bit以内の整数）
- 判定: Intset最適。 デフォルトの512に収まるため、メモリ効率は最高潮に達する。ハッシュテーブルに比べて数分の一のメモリしか消費しない。
ケーススタディ B: アクティブなセッションIDのハッシュ（要素数：5,000個）
- データ: `[100001, 100002, …]`（整数だが、上限の512を超えている）
- 判定: 強制的にハッシュテーブルへ移行（DowngradeではなくUpgade扱い）。
- 設計上の注意: もしこのSetの要素数が「常に数千件」あるなら、`set-max-intset-entries` を例えば `10000` に引き上げればIntsetのままでいられるか？
- 答えは「NO、絶対にやるな」。
- 先述した通り、Intsetの検索は $O(\log N)$、挿入は $O(N)$ だ。要素数が数千〜数万になると、二分探索と要素シフトのコスト（CPU負荷）が無視できなくなり、シングルスレッドのRedisにおいてレイテンシ悪化（レイテンシスパイク）を引き起こす主原因になる。
—
4. コードレビューで使える「設計のアンチパターンと正解」
実務でよくある誤った設計と、それをどう修正すべきかの指針を示そう。
❌ アンチパターン：文字列混入によるIntset破棄
Intsetは「すべての要素が整数であること」が絶対条件だ。
1. 最初はすべて整数なので Intset として保持される
127.0.0.1:6379> SADD active:users 101 102 103
(integer) 3
2. 冗談半分で文字列を1つ混ぜる
127.0.0.1:6379> SADD active:users “user_104”
(integer) 1
3. この瞬間、このSetの内部エンコーディングは「ハッシュテーブル」に永久変換される
一度ハッシュテーブルに変換されると、たとえ後から文字列の要素をすべて削除して整数だけに戻したとしても、自動的にIntsetにはダウングレードされない。 Redisは無駄なメモリ領域を持ち続けることになる。
【対策】
アプリケーション層のバリデーションを厳格化し、数値IDを扱うSetに文字列が混入するパイプラインを絶対に作らないこと。確認には `OBJECT ENCODING` コマンドを使用する。
127.0.0.1:6379> OBJECT ENCODING active:users
“hashtable” # 「intset」であってほしい場面でこれが出てきたら設計ミスのシグナル
—
5. まとめ：プロフェッショナルなRedis活用のために
RedisのIntsetは、数あるデータ構造最適化の機能の一つにすぎない。しかし、こうした「省メモリの仕組み」をどれだけ深く理解し、アプリケーションのデータ特性（ cardinality や data type ）に適合させられるかが、ジュニアエンジニアとシニアアーキテクトを分ける境界線だ。
- 要素数が数百件程度で、確実に整数のみが入るデータ（タグID、フラグ、小規模なリレーション）は、Intsetの恩恵を最大限に受ける設計にする。
- `set-max-intset-entries` のデフォルト値を安易にいじらず、CPU（$O(\log N)$の探索コスト）とメモリ（連続領域によるキャッシュ効率）のバランスを常に意識する。
- `OBJECT ENCODING` を監視し、意図しないハッシュテーブルへの昇格を見逃さない。
「動けばいい」ではなく、「スケールしても破綻しない」コードと設計を、あなたのプロダクトでも実現してほしい。
コメント