スライディングTTLで推論失敗を回避する

背景

特徴量をRedisやDynamoDBにキャッシュするとき、固定TTLを設定すると「必要な瞬間に失効して値が取れない」問題が発生しがちです。推論リクエストの直前にキーが失効すると、DBやオフラインストアへのフェッチが発生し、レイテンシ急増やタイムアウトを引き起こします。

解決策：スライディングTTL（アクセス時に延長）

アクセスごとにTTLを更新することで、よく使う特徴量は保持し、使わない特徴量だけ自然に消えるようにできます。

実装例（Python + Redis）

import redis, time

r = redis.Redis()

BASE_TTL = 3600  # 1時間

def get_feature(entity_id):
    key = f"feat:user:{entity_id}"
    features = r.hgetall(key)
    if features:
        # アクセス時にTTLを延長
        r.expire(key, BASE_TTL)
    return features

アンチパターン

• TTLなし → 古いデータが残り続け、一貫性崩壊やメモリ圧迫。
• 固定TTLのみ → よく使う特徴量まで期限切れになり、推論失敗。
• 過度に長いTTL → 一貫性が保てず、古い特徴量を学習・推論に使ってしまう。

関連技術での応用

• Feast: オンラインストアで ttl_seconds を定義可能。スライディング更新を併用すると実用的。
• DynamoDB: TTL属性は「自動削除のみ」なので、スライディングを実現するならアプリ側で UpdateItem を使う。
• Cassandra: USING TTL を設定しつつ、再アクセス時に UPDATE でTTL延長可能。

✅ まとめ

• よく使う特徴量を維持しつつ、不要データを自然に削除するには スライディングTTL が有効。
• 固定TTLだけでは推論時にキャッシュ切れが起こりやすく、安定運用に不向き。
• TTLは「固定＋スライディング」併用が実務的ベストプラクティス。