【実務・中級編】 String型：ビット操作 – Redis

Redis String型極限最適化：ビット演算（Bitmaps & BITFIELD）でメモリを極限まで削ぎ落とす技術

こんにちは。テックリードの私だ。
今日のコードレビューで、また「ユーザーのオンライン状態を管理するために `users:12345:online` というキーでBooleanを保存しています」というプルリクエストを見かけた。

おいおい、待ってくれ。
数百万、数千万規模のユーザーを抱えるシステムで、そんな素朴なキー設計をしていたら、Redisのメモリはあっという間に枯渇し、メモリコストでインフラ予算が吹き飛ぶ。

Redisの真価は、単なるキーバリューストアとしての使い方にあるのではない。
今回解説する 「String型におけるビット操作（BitmapsとBITFIELD）」 を使いこなせば、メモリ効率を理論上の限界ギリギリまで高め、1億人の状態をたったの12MB程度で保持できるようになる。

今回は、実務の現場で即座に使える堅牢な設計パターンと、アーキテクトとして知っておくべきパフォーマンスの裏側を徹底的に叩き込む。

—

1. なぜ「String型でのビット操作」なのか？

RedisのString型は、最大512MBのバイナリセーフなデータ構造だ。
内部的には単なるバイト配列（byte array）であり、Redisはこの領域に対してビット単位のランダムアクセスや演算を行うプリミティブ（`SETBIT`, `GETBIT`, `BITCOUNT` 等）を提供している。

一般的なRDBや、Redisでも通常のString/Hashでフラグ管理をする場合と比較してみよう。

桁が違う。この圧倒的なメモリ効率こそが、大規模システムでビットマップを採用する最大の理由だ。

—

2. コアコマンドの徹底解説と実務での罠

まずは主要なコマンドを押さえる。ただし、教科書通りの説明はしない。「実務でどうハマるか」を含めて解説する。

`SETBIT` と `GETBIT`: O(1) のビット操作

指定したオフセット（位置）のビットを書き換える／読み出す。

ユーザーID: 1000000 のオンラインフラグを立てる (offsetは0起点)
SETBIT online_users 1000000 1

状態の確認
GETBIT online_users 1000000
=> (integer) 1

⚠️ チーフアーキテクトからの警告（メモリ割り当ての罠）:
`SETBIT` で巨大なオフセット（例: `4294967295`＝約42億）を指定した瞬間、Redisはそのオフセットまでの巨大なメモリ空間を一気にゼロ埋めして確保しようとする。
もしオフセットにユーザーの連番ではない「ランダムな数値（UUIDのハッシュ値など）」をそのまま突っ込むと、一瞬でメモリが暴発（OOM）するので絶対に避けること。オフセットは必ず「連番のID」にマッピングすること。

`BITCOUNT`: 高速な人口密度調査（Popcount）

指定した範囲（バイト単位、ビット単位ではない点に注意）に含まれる「1」の数を数える。

今日アクティブな総ユーザー数を一瞬で集計
BITCOUNT online_users

内部的にはCPUのハードウェア命令（POPCNTなど）を叩いているため、数千万bitのデータであっても数ミリ秒で完了する。圧倒的な速度だ。

`BITOP`: ビット単位の集合演算

`AND`, `OR`, `XOR`, `NOT` を使い、複数のビットマップ間で高速な集合演算を行える。

「月曜日にログインしたユーザー」と「火曜日にログインしたユーザー」のANDを取る（両日ともログインした常連）
BITOP AND active_mon_tue active_monday active_tuesday

MAU/DAUの分析、レコメンドの絞り込み、権限管理などで、この `BITOP` を使った高速なフィルタリングが実務では多用される。

—

3. 進化系：`BITFIELD` による高度な数値・構造体パッキング

「1bitのフラグだけじゃなく、小さな数値（例えば、ユーザーの連続ログイン日数: 0〜255）もビットマップに詰め込みたい」
そんな時に登場するのが `BITFIELD` コマンドだ。

これを使うと、String型の中を任意のビット幅のフィールド（符号付き／符号なし）に分割し、直接インクリメントや代入を行える。

ユーザーID: 5 の連続ログイン日数（符号なし8ビット = u8）を1増やす
BITFIELD user_streaks INCRBY u8 #40 1

ここで `#40` は、オフセットではなく「40ビット目から開始するフィールド」を意味する（もし1ユーザーあたり8ビット使うなら、ID 5 は `5 8 = 40` ビット目）。

実務設計パターン：複合ステータス管理

1つのStringキーの中に、複数の異なる属性をビット単位でパッキングする設計例だ。

0ビット目: メール認証済み (1bit)
1ビット目: プレミアム会員 (1bit)
2〜5ビット目: ユーザーランク (4bit / 0〜15の数値)

これを `BITFIELD` で制御すれば、1ユーザーあたりのメタデータをわずか1バイト（8bit）のなかに美しく格納し、アトミックに更新できる。アプリケーション層での競合（Race Condition）を防ぐ意味でも非常に強力だ。

—

4. 本番運用におけるチーフアーキテクトの知見（パフォーマンスとスケーリング）

綺麗に設計されたビットマップも、運用を誤ると障害の元になる。以下の鉄則を頭に叩き込んでおいてほしい。

1. キーの巨大化とレイテンシ（Blockingの回避）

前述の通り、極端に大きなオフセットを持つビットマップは、生成時のメモリ確保にコストがかかる。また、数MBを超えるような巨大なString型に対して `BITOP` や `BITCOUNT` を高頻度で実行すると、シングルスレッドであるRedisのメインループをブロックし、他のリクエストが遅延する（レイテンシスパイクの発生）。

対策: 期間ごとにキーを分割する。例えば日別（`online:2023-10-27`）に分け、1日あたりのサイズが数MB〜十数MB程度に収まるように設計する。

2. クラスタ環境（Redis Cluster）での注意点

Redis Clusterはキーのハッシュスロット（全16384スロット）に基づいてデータを分散配置する。
そのため、`BITOP` で異なるハッシュスロットに属するキー同士を演算させることはできない（エラーになる）。

対策: クラスタ環境で `BITOP` を使いたい場合は、ハッシュタグ（ `{}` ）を用いて、関連するキーが必ず同じシャード（スロット）にルーティングされるように強制すること。
例: `{user:2023-10}:mon` と `{user:2023-10}:tue` は同じハッシュタグ `{user:2023-10}` を含むため、同一ノードに配置される。

—

5. まとめ

RedisのString型におけるビット操作は、単なる「テクニック」ではない。ハードウェアの限界に肉薄し、メモリコストを極限まで最適化するためのアーキテクチャそのものだ。

オンライン判定や機能フラグには `SETBIT` / `GETBIT`
高速な集計には `BITCOUNT`
複数条件のフィルタリングには `BITOP`
複数属性のパッキングには `BITFIELD`

これらの特性を正確に理解し、システムのスケールに耐えうる堅牢なキー設計を行ってほしい。
君たちの書くコードが、将来の数千万ユーザーを支える基盤になるのだから。設計の妥協は一切許さない。