Tair (Redis® OSS-Compatible):AI エージェント向け短期記憶のための Tair

適用範囲

本記事で紹介する設計パターンは、以下の AI エージェントのユースケースに適用可能です：

• カスタマーサポートボット、ショッピングアシスタント、パーソナルアシスタントなど、マルチターン対話においてコンテキストを維持する必要がある対話型エージェント。

• エンドツーエンドレイテンシに敏感で、ミリ秒単位のメモリ読み書き操作を要求するリアルタイムインタラクティブなシナリオ。

• AI エージェントが複数のツールを同時に呼び出すなど、並列書き込みのリスクがあるマルチツール呼び出しシナリオ。

• トラフィック変動が激しく、弾力的スケーリングを必要とするオンラインサービス。

なぜメモリシステムに Tair が必要か

AI エージェントのメモリシステムは、レイテンシに対して極めて敏感です。リトルの法則（同時実行数 ≈ QPS × レイテンシ）によると、メモリアクセスレイテンシが 5 ms から 50 ms に増加すると、処理中のリクエスト数は 10 倍に膨らみます。これにより、接続、スレッド、キューなどのリソースが急速に枯渇する可能性があります。また、各対話ターンでは複数回のメモリ読み書きが発生するため、レイテンシは累積し、キューイング、タイムアウト、さらにはカスケード障害を引き起こすおそれがあります。

5 ms と 50 ms の差は、単なるユーザーエクスペリエンスの最適化ではなく、安定的にスケール可能なシステムと、そうでないシステムを分ける分水嶺です。 これが、タオバオ・フラッシュセールの AI エージェントがメモリレイヤーに Tair を採用した根本的な理由です。Tair は独自のマルチスレッドカーネルを備えており、安定した低レイテンシを実現します。これにより、メモリアクセスが安全なしきい値内に保たれ、高同時実行時における性能劣化の悪循環を根本的に防止します。

モデルメモリ — List

モデルメモリは、大規模言語モデル（LLM）が処理するための対話履歴を格納します。各ターンにおいて、エージェントはユーザーの入力および自身の応答を記録し、次回のモデル推論時にコンテキストとして渡します。

この履歴は、Tair の List に格納され、セッションごとに 1 つのキーが使用されます：

Key:  memory:model:{sessionId}
Type: List

Example data:
[
  {"role": "user",      "content": "ミルクティーを注文したいです。"},
  {"role": "assistant", "content": "近くにあるミルクティー店を 3 件見つけました...", "cards": [...]},
  {"role": "user",      "content": "この店で、糖分少なめ・氷抜きにしてください。"},
  {"role": "assistant", "content": "選択しました：白鴉絶鮮、糖分少なめ、氷抜き、大サイズ..."}
]

主な操作：

# 各対話ターン終了後に、新しい対話レコードを追加
RPUSH memory:model:{sessionId} "{Conversation Record JSON}"

# モデル推論前に、直近 N ターンの履歴をコンテキストとして読み取り
LRANGE memory:model:{sessionId} -{N} -1

# セッションの有効期限（例：30 分）を設定
EXPIRE memory:model:{sessionId} 1800

ビジネスコンテキストメモリ — Hash

ビジネスコンテキストメモリは、ビジネスプロセスから得られる構造化された状態情報を格納します。エージェントのツールレイヤーおよびインテントプロセッサは、ビジネスロジックを実行する際に、この情報を照会および更新します。

このメモリは、ビジネスドメインごとに 6 つのサブモジュールに分割され、Tair の Hash に格納されます：

Key:  memory:context:{sessionId}
Type: Hash

Field structure:
{
  "session":      "{セッションメタデータ：ユーザー ID、チャネル、セッションステージなど}",
  "search":       "{検索ステータス：現在のクエリ、検索結果、おすすめ商品リストなど}",
  "order":        "{注文ステータス：ショッピングカートの内容、選択 SKU、数量など}",
  "conversation": "{対話ステータス：現在のインテント、前回のインテント、インテント切り替えフラグなど}",
  "coupon":       "{クーポン情報：利用可能なクーポン、選択済みクーポンなど}",
  "bizState":     "{ビジネスステート：配送先住所、配送方法、支払いステータスなど}"
}

主な操作：

# 単一サブモジュールの更新（例：ユーザーが配送先住所を確定した場合）
HSET memory:context:{sessionId} bizState "{Updated Business State JSON}"

# 特定サブモジュールの読み取り
HGET memory:context:{sessionId} order

# 全コンテキストの一括読み取り（インテント認識など、グローバル情報が必要なシナリオ向け）
HGETALL memory:context:{sessionId}

# 有効期限の設定
EXPIRE memory:context:{sessionId} 1800

データ構造の比較

Tair カーネル性能

Tair は マルチスレッドモデルを採用しており、同一仕様のオープンソース Redis インスタンスと比較して、最大 3 倍の読み書き性能を実現します。これは、同一サイズのインスタンスにおいて、Tair がオープンソース Redis の 3 倍の操作スループットを処理できることを意味します。

この性能上の優位性は、AI エージェントのユースケースにおいて特に重要です。単一のユーザー対話は、対話履歴の読み取り、ビジネスコンテキストの更新、分散ロックの取得／解放など、数十回の Tair 操作をトリガーします。オープンソース Redis のシングルスレッドモデルでは、高同時実行時にデータベースが容易にボトルネックとなり得ますが、Tair のマルチスレッドカーネルにより、単一ノードがマルチコア CPU リソースを十分に活用でき、ノード数を増やすことなくより高い同時実行性を処理できます。

弾力的かつシームレスなスケーリング

エージェントの対話フローにおいて、メモリデータは典型的な 読み取り重視 パターンを示します：各推論ラウンドの前に、エージェントは完全な対話履歴およびビジネスコンテキストを読み取る必要があります（読み取り操作）、一方で書き込み操作は各ターン終了時に新規レコードを追加するのみです。読み取りと書き込みの比率は通常 5:1 ～ 10:1 です。

Tair は 読み書き分離を備えたクラスタアーキテクチャ をサポートしています。Tair は、読み取りリクエストを自動的に読み取り専用レプリカに分散し、書き込みリクエストはプライマリノードにルーティングします。読み取り専用レプリカの数は 1～9 で柔軟に調整可能であり、クラスタのシャード数は 2～256 まで水平方向にスケールできます。トラフィックピーク前に読み取り専用レプリカまたはシャードを追加することで、スループットを線形に向上させ、ピーク後にはコスト削減のために縮小できます。

例

通常トラフィック：日常的なビジネスニーズを満たすために、シャード数 8、各シャードに読み取り専用レプリカ 1 台のクラスタを使用。

春節イベント（ピークトラフィックが 5～10 倍）：

• オプション 1：各シャードの読み取り専用レプリカを 5 台に増やし、読み取りスループットを線形に向上。

• オプション 2：シャード数を 16 に増やし、各シャードに読み取り専用レプリカを 3 台配置して、読み取りおよび書き込みの両方のキャパシティを 2 倍に拡張。

これらのスケーリング操作は、お客様のサービスに対して完全に透明です。従来の Redis クラスタでは、スロット移行中に -ASK や -TRYAGAIN などのエラーが発生することがあります。対話型エージェントのユースケースでは、リクエストの失敗は対話の中断やメモリ損失につながり得ます。Tair のクラウドネイティブ版は、カーネルレベルの最適化により シームレスなスケーリング を実現します。データはキー単位ではなく、スロット単位で原子的に移行されるため、スロット分割が発生しません。さらに、集中制御コンポーネントがクラスタの動作を調整し、より高い移行効率とより精密な意思決定を実現します。

弾力的帯域幅スケーリング

QPS の負荷に加え、イベントは著しい 帯域幅の課題 も提示しました。AI エージェントによる各メモリ読み取りは、対話履歴およびビジネスコンテキストの転送を伴うため、従来のキャッシュ用途における単純なキー・バリューリードと比較して、1 回のリクエストあたりのデータペイロードが大幅に大きくなります。業務ピーク時には、CPU やメモリよりも先に帯域幅がボトルネックとなることがあります。

Tair アーキテクチャは、2 層の弾力性を提供します：

• クラスタ帯域幅の水平スケーリング：クラスタアーキテクチャでは、ロードバランサー（LB）を追加することで、インスタンスの総帯域幅を増加できます。単一 LB の帯域幅制限は 20 Gbps です。シャード数が 8 を超える場合、既存の接続を中断することなく、必要に応じて LB を追加できます。

• バースト帯域幅：瞬間的なトラフィックが固定帯域幅を超えた場合、システムは 数秒で帯域幅を自動的に拡張 します（ノードあたり最大 288 MB/s）。トラフィックが収まると帯域幅は自動的に解放され、使用したバースト分のみが課金されます。バースト帯域幅は 各シャードごとに独立して動作 します。あるシャードがホットキーによって帯域幅ボトルネックを起こした場合、そのシャードの帯域幅のみが自動的に拡張され、他のシャードには影響しません。

  説明

  バースト帯域幅は、AI エージェントのユースケースに多く見られる予測困難なトラフィックスパイクに特に適しています。高スペックの固定帯域幅パッケージを事前に購入するよりも、オンデマンドでバーストする方がコスト効率が優れています。

自動 TTL クリーンアップ

すべてのセッションキーに適切な TTL（例：30 分）を設定することで、トラフィックピーク後のメモリ使用量が手動介入なしに自動的に減少します。Tair の弾力的スケーリングと組み合わせることで、ピーク時のスケールアウト、トラフィック低下時のスケールイン、および期限切れデータの自動クリーンアップを含む、完全自動化されたリソース管理が実現します。

その結果、春節期間中のトラフィック急増時にも、メモリサービス全体が安定して稼働し、P99 レイテンシは一貫してミリ秒レベルで制御されました。