osFoundry / Platform
アプリ単位のKVストア
TTL付きのRedis互換KV。セッション、キャッシュ、カウンタ ― アプリに合わせたサイズで。
概要
アプリ別KVストアは、osFoundry内で作るすべてのアプリに、専用のRedis互換キーバリューバックエンドを提供します。Redisを使ったことがあれば、そのまま同じ感覚で扱えます。キーを書き込み、読み戻し、カウンターを増やし、TTL（有効期限）を付けてエントリを自動的に失効させる、という具合です。各アプリには独立した名前空間が割り当てられるので、あるアプリのセッションキーが別のアプリのキャッシュエントリと衝突することはありません。プロビジョニングや保護、維持のための別立てのRedisサーバーは不要で、ストアはアプリランタイムの一部として、使うアプリに見合ったサイズで動きます。
KVストアの要はTTLであり、その挙動は期待どおりです。セッショントークンを有効期限30分で書き込めば、時間が過ぎた時点で消えます。コストの高いAPIレスポンスを5分間キャッシュして自然にリフレッシュさせることも、短命なロックやレートリミットのウィンドウを自動的にクリアさせることもできます。キーは掃除用のジョブなしに失効するため、ゴミを溜め込まずに一時的な状態を保持できます。カウンターも第一級の機能です。アトミックなインクリメントとデクリメントによって、閲覧数のカウント、クォータの追跡、単純なシーケンス番号を、read-modify-writeの競合なしに扱えます。
これは、チャット、エージェント、アプリ、コード、ナレッジ、データが一か所にまとまるBYOK型デスクトップワークスペースというosFoundryの形によく合います。KVストアは、アプリの他のデータと並んで置かれる高速で揮発的なティアです。ホットで小さく短命なものはここに置き、永続的な記録は別の場所に保ちましょう。Redis互換であるということは、これまで作ってきたものからメンタルモデルとコマンドの語彙がそのまま引き継げるということであり、セッションやキャッシュを動かすために新しいAPIを学び直す必要はありません。
主な機能
- Redis互換のキーバリューAPI。GET、SET、INCR、EXPIREなど使い慣れたコマンドがそのまま使え、新しいクライアントを覚える必要はありません
- キーごとのTTLにより、セッション、キャッシュエントリ、ロックが自動で失効し、掃除用のジョブは要りません
- アプリごとに独立した名前空間。各アプリのキーはそのアプリに閉じており、他のアプリのキーと衝突しません
- インクリメントとデクリメントによるアトミックなカウンター。閲覧数、クォータ、レートリミットのウィンドウを競合なしに扱えます
- osFoundry内でアプリの一部として動作。プロビジョニングは不要で、ストアは使うアプリに合わせたサイズになります
活用例
- アプリ開発者：スライディングTTLでログインセッションを保持し、ユーザーはサインイン状態を維持しつつ、古いトークンは自動でクリアされます
- バックエンド構築者：遅い外部APIのレスポンスを数分間キャッシュし、レイテンシと重複呼び出しを削減します
- エージェントツール作者：失効するキーで自動リセットされる、1分あたりのレートリミットカウンターを保持します
よくある質問
これは本当のRedisですか、それともRedis風なだけですか
Redis互換です。つまり、あなたがすでに使っているのと同じキーバリューのコマンドとセマンティクス、たとえば有効期限付きのSET、GET、INCR、DELを話すので、既存の習慣やコードのパターンがそのまま通用します。強みは、これがosFoundryのアプリランタイムに組み込まれている点で、別立てのRedisサーバーを立ち上げたり保護したりせずに使えます。
KVストアと本物のデータベース、それぞれ何を置くべきですか
KVには、ホットで小さく短命な状態を置きます。セッション、キャッシュ、カウンター、レートリミットのウィンドウ、ロックなど、失効して構わないものです。存続してクエリされる必要のある永続的な記録は、きちんとしたデータベースに保ちます。KVストアは高速で揮発的なティアであって、記録の正本ではありません。
TTLはキーを自動で失効させますか
はい。キーにTTLを設定すると、その期間が過ぎた時点で削除され、こちら側で掃除用のジョブを回す必要はありません。これがセッションやキャッシュに向いている理由です。一時的であるべきデータは、溜まっていくのではなく自ら消えていきます。