背景
RedisやMemcachedをオンライン特徴量ストアに使うときに起きやすいのが ホットキー問題 です。特定のユーザーやIDにアクセスが集中すると、一部のノードだけが過負荷になって遅延が増えたり、クラスタ全体が不安定になることがあります。
解決策：キー分散とフェイルセーフ設計
🔹 キーを分散してホットスポットを回避
- 同じユーザーでも複数のキーに分けて保存する。
- 有効期限（TTL）はランダムにして、一斉に失効しないようにする。
import random, redis
r = redis.Redis()
def set_feature(entity_id, features, ttl=3600):
shard = random.randint(0, 9) # 10分割してランダムに保存
key = f"feat:{entity_id}:{shard}"
r.hset(key, mapping=features)
r.expire(key, ttl + random.randint(-60, 60)) # ±1分のズレを加える🔹 フェイルセーフ設計
- Redisが落ちたときに備えて、DynamoDB や Bigtable をバックアップとして利用。
- Feast ならオンラインストアが落ちてもオフラインストアに切り替え可能。
やってはいけないアンチパターン
- キーをIDだけで設計する → 人気ユーザーが集中して過負荷に。
- TTLを固定値にする → 一斉にキャッシュ切れが起きてスパイク発生。
- バックエンドを用意しない → Redis障害でシステム全体が止まる。
関連技術の活用例
- Feast: Redisをオンライン、BigQuery/Bigtableをオフラインで組み合わせるのが王道。
- DynamoDB:
entity_id + ランダムサフィックスをキーにして自然に分散。 - Cassandra: TTL付きカラムで自動失効しつつ、分散設計が標準対応。
✅ まとめ
- ホットキー問題を無視すると、スケールさせたはずのシステムが逆に不安定に。
- キー分散 + TTLにジッター は必須の工夫。
- Redisだけに依存せず、バックアップ経路を設けることが安心運用のポイント。