生成AIのシステム開発をしていくにあたって、Cosmos DBやRedisといったRDB以外のデータストアサービスを使うことが増えてきました。
RedisとCosmos DBともに「NoSQL」というカテゴリに分類されます。
しかし、担う役割と設計思想が大きく異なるため同じものとして扱うのは危険です。
1. そもそもNoSQLの定義
「Not Only SQL」の略で、表形式のRDB(リレーショナルデータベース)ではない非リレーショナル型のデータストアのことを指します。
形式は「Key-Value型」「ドキュメント型」「グラフ型」などの種類が存在します。
従来のRDBでは扱いづらいデータを扱いたい時に使用し、柔軟なスキーマ定義や大量データの高速処理に向いています。
あくまでもデータの保存形式がRDBのようなテーブル形式ではない。ということだけで分類されているだけなので、「どういった仕組みでどのように保存するのか」「どのようなケースに向いているか」についてはNoSQLの中でもさらに種類が分かれることに注意が必要です。
2. RedisとCosmos DBの違い
「1.」のNoSQLの定義をもとに、同じNoSQLに分類されるRedisとCosmos DBについていろんな観点で分けてみました。
| Redis | Cosmos DB | |
|---|---|---|
| 種類 | Key-Value型 | マルチモデル型 |
| 設計上の前提 | 消失を許容できるケース | 強整合性・耐久性が必要なケース |
| 通信プロトコル | TCP + RESP | HTTPS (HTTP/REST) |
| レイテンシ | サブミリ秒〜数ms | 数ms ~ 10ms |
| データ格納場所 | 主にメモリ(RAM)。ただしRDB/AOFでディスク永続化も可能 | ディスク(ストレージ) |
| 苦手なケース | 主データ、監査ログ、証跡 | 高頻度キャッシュ、瞬間的状態 |
| ユースケース | 高速に何かデータを一時保存したいとき | 永続データ |
| 障害対策 | 落ちても別ルートで処理できる設計 | 継続バックアップ(標準7日 / 最大30日) |
| 選定を誤ると | データ消失によるサービス継続不可 | コスト爆増 |
Cosmos DBは RU/s(Request Units per second) という単位で課金されます。1KBの読み取りで約1RU、書き込みで約5RU、複雑なクエリではさらに大きなRUを消費します。生成AIの会話履歴のように 頻繁な書き込み + 大きなドキュメント を扱う場合、想定以上にRU消費が膨らみコストが跳ね上がるため、パーティションキー設計とインデックスポリシーの最適化が重要です。
【結論】
-
Redisを利用 ...最悪落ちてもサービスに致命的な影響が出ず、再処理と再取得が可能で、システムの処理速度向上とUXの向上をしたい場合
例)
・LLMとの接続セッション情報
・一時的な推論結果のキャッシュ
・UIに表示するためのステート管理 -
Cosmos DBを利用 ... データの永続化・再利用・監査が必要で、かつ可変・ネスト構造のドキュメント形式が適している場合
例)
・会話履歴
・監査・証跡目的のデータ
3. OSSのRedisとAzure Managed Redisの違い
Redisの中でもOSSで気軽に構築できるRedisとAzureが提供しているRedisの二つ存在します。
何か機能が変わるわけではなく、責任範囲が変わります。
| Head | OSS Redis | Azure Managed Redis |
|---|---|---|
| 位置づけ | Redis を自分で運用する | Redisをマネージドで使う |
| 構築 | VMやDockerコンテナ等で自前構築 | Azure Portal から数クリック |
| 運用責任 | すべて自分たち | Azure が肩代わり |
| 可用性 | 自分で設計・実装 | 標準で冗長化・フェイルオーバー |
| 監視 | 自前で設計・構築 | Azure Monitor と統合が可能 |
| 障害対応 | 原因調査・復旧は全て自分 | 基盤障害は Microsoft 側 |
| セキュリティ | ネットワーク・TLS・認証を自前設計 | TLS / 認証 / Azure 統合あり |
| ネットワーク | 自由度高いが責任も重い | VNet / Private Endpoint 連携 |
| SLA | なし（自前品質） | SLA あり |
| 同等性能コスト | ¥105,000〜¥115,000 | ¥86,744/月 |
※コストに関しては「メモリ6GB、SKU: X5、冗長化構成、東日本リージョン」を前提として算出
【結論】
-
OSSのRedisを利用 ... 個人開発やPoCでサクッと導入したい場合
※ 単純に同一スペックのVM上に構築する場合はOSS Redisの方が安いが、メモリリーク対応や障害時の切り分け対応など運用コストを考えると総合的にはAzure Managed Redisよりコストがかかる -
Azure Managed Redisを利用 ... 商用・本番用のシステム構築する場合
※また、Azure Managed Redisは「Redis Enterprise」を基盤としており、OSSのRedisにはない機能が標準で利用できます。
最後に
「Azure Cache for Redis」は2028年9月に廃止されます。
そのため、新規で構築する場合は「Azure Managed Redis」を使用しましょう。
※Azure Cache for RedisがAzure Managed Redisという名前に変わったというわけではなく、厳密には使える機能とかが変わっていますので注意。
Discussion