Redisを極限まで使い倒す：SDS（Simple Dynamic String）のメモリ最適化とアーキテクチャの深層
こんにちは。テックリードの私だ。今日のコードレビューで、また「とりあえず文字列だからRedisの`SET`でいいか」という安易な実装を見かけた。
Redisは「超高速なインメモリDB」として広く認知されているが、その実態を支えているのは、データ構造の変態的なまでのメモリ効率化へのこだわりだ。特に、内部で文字列を表現するために使われる SDS（Simple Dynamic String） は、C言語の標準的なヌル終端文字列の概念を粉砕し、パフォーマンスとメモリ最適化の極限を追求した傑作である。
今回は、Redisのパフォーマンスを限界まで引き出し、数千万〜数億件のキーを扱う大規模システムでメモリ爆発を起こさないための「SDSのメモリ最適化メカニズム」を、シニアエンジニアの視点から徹底的に解説する。
—
1. なぜCの `char` ではダメなのか？ RedisがSDSを自作した理由
C言語のネイティブな文字列（`char`）は、シンプルゆえにRedisのユースケースにおいては致命的な欠陥を抱えている。
1. 長さ取得（`strlen`）が $O(N)$ である:
文字列の長さを知るために毎回ヌル文字（`\0`）までスキャンする必要がある。シングルスレッドで動くRedisにおいて、これは致命的なCPUサイクルの無駄遣いだ。
2. バイナリセーフではない:
`\0`（ヌルバイト）がデータに含まれていると、そこで文字列が途切れてしまう。画像やシリアライズされたバイナリデータを扱えない。
3. バッファオーバーランの危険性:
書き込み先のメモリ領域が足りているかを事前にチェックする仕組みがない。
これらを解決するため、Redisはメタデータと実データを一体化させた独自の文字列構造体 SDS を発明した。
—
2. SDSの内部構造：ヘッダサイズの動的最適化の妙
Redis 5以降、SDSはメモリ使用量を極限まで削るため、文字列の長さに応じて5種類のヘッダ（`sdshdr5`, `sdshdr8`, `sdshdr16`, `sdshdr32`, `sdshdr64`）を動的に使い分ける設計になっている。
構造体の定義を見てみよう。Cのパッキング（`__attribute__((__packed__))`）を駆使し、パディングによるメモリの隙間すら排除している。
// 例: sdshdr8 の構造（最大長 255 バイトまでの文字列用）
struct __attribute__((__packed__)) sdshdr8 {
uint8_t len; ន្ទ // 使用しているバイト数
uint8_t alloc; // 割り当て済みの総バイト数（ヌル文字除く）
unsigned char flags; // ヘッダの型を示すフラグ（下位3bit）
char buf[]; // フレキシブル・アレイ・メンバー（実データ）
};
注目すべきは、メタデータが実データ（`buf`）の「直前」に配置されている点だ。
これにより、ポインタを少し逆方向（低アドレス側）にキャストするだけで、`len` や `alloc` に一瞬でアクセスできる。C言語のポインタ演算のロマンがここにある。
メモリ効率のシミュレーション
例えば、「”OK”」という短い文字列を保存する場合、`sdshdr5` または `sdshdr8` が選択される。
ヘッダサイズはわずか数バイト。余計なオーバーヘッドを極限まで削ぎ落とすことで、Redisは数千万のキーを持つメタデータであっても、RAMの消費を最小限に抑え込んでいる。
—
3. メモリ断片化を防ぐ：動的再割り当て（Pre-allocation）戦略
文字列の結合や追記（`APPEND` コマンドなど）を行う際、Redisは毎回厳密に必要なサイズだけを再割り当てするような愚かな真似はしない。そんなことをすれば、メモリマネージャ（jemallocなど）レベルで激しいメモリ断片化（Fragmentation）を引き起こし、OS全体のパフォーマンスが崩壊する。
そこでSDSには、以下の緩衝材（オーバーアロケーション）戦略が組み込まれている。
1. 1MB未満の場合:
拡張後の長さが1MB未満の場合、必要サイズの2倍のメモリが確保される。
2. 1MB以上の場合:
拡張後、常に1MBの余分なバッファ（free space）が常に追加で確保される。
なぜこの戦略が実務で効くのか？
例えば、ログメッセージやJSONペイロードをインクリメンタルに構築する場合を想像してほしい。毎回の `realloc`（メモリの再割り当てとコピー）が発生すると、CPUバウンドになりスループットが急低下する。
SDSの事前割り当て戦略により、「頻繁なリサイズコストの抑制」と「メモリ断片化の防止」を高次元で両立させている。
—
4. 設計レビュー：実務でやってはいけないアンチパターン
ここで、現場のコードレビューで私が即座に差し戻す「Redisのメモリを殺す設計」をいくつか挙げておく。
アンチパターン A: 巨大なJSON文字列の頻繁な部分更新
最悪な例：数MBあるJSONを毎回取得・パッチ・再設定している
json_data = redis_client.get(“user:1000:profile”)
data = json.loads(json_data)
data[“last_login”] = current_time()
redis_client.set(“user:1000:profile”, json.dumps(data))
何が問題か？
数MBのSDSに対して、`SET`を毎秒何千回も行うと、SDSのバッファサイズが肥大化したまま縮小しない（`sdsfree` による縮小最適化は行われるが、安易なリサイズはjemallocのヒープを荒らす）。また、ネットワーク帯域とCPU（シリアライズ/デシリアライズ）の無駄。
対策:
フィールド単位で管理できるなら Hash（`HSET`） を使え。Hashの内部表現（ziplistやlistpack）も、メモリ効率を極限まで高めるように設計されている。
アンチパターン B: プレフィックスの肥大化によるキーのメモリ圧迫
冗長なキー設計
redis_client.set(“application:production:user:account:id:12345:profile”, “data”)
何が問題か？
Redisでは、すべてのキー自体もSDSとして保持される。数千万件のキーがある場合、この長大なプレフィックス文字列だけで、何ギガバイトものRAMが無駄に消費されることになる。
対策:
キーのプレフィックスは短くし、必要であれば `redis.conf` の `hash-max-ziplist-entries` などのチューニングと合わせて、メモリフットプリントを常に意識した設計にすること。
—
5. チーフアーキテクトからの提言
RedisのSDSに代表されるデータ構造の最適化は、「動けばいい」というレベルのプログラミングからは見えない領域で行われている。しかし、数百万QPSを処理する分散システムや、可用性とレイテンシが厳しく問われるミッションクリティカルな現場では、こうした下回りの知識がシステムの生死を分ける。
- 「なぜそのデータ構造を選ぶのか」
- 「メモリの裏側で何が起きているのか」
これを言語化し、設計に落とし込めるエンジニアであれ。Redisをただの「便利なKVS」として扱う時代は終わった。アーキテクチャをハックし、極限まで洗練されたシステムを構築しよう。
コメント