Redisと野心の代償

 (charlesleifer.com)
4 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Redisは2026年のarray type PR まで検討するようになり、単純なデータ構造サーバーから複数領域をまたぐ製品へと変化してきた
  • 初期のRedisはRemote Dictionary Serverの名の通り、高速なインメモリ辞書、狭く絞られたコマンド、単純なプロトコルによってWebスタックに素早く定着した
  • この10年でRedisはStreams、JSON、search、graph、time-series、Redis-Raft、vector setsなどへ拡張し、database志向を強めてきた
  • 機能の肥大化は、Redisの強みだった単純さと一貫性を弱め、専門ツールが必要な領域に中途半端な統合を増やした
  • Valkeyは派手な機能競争よりも、マルチスレッド性能、メモリ効率、クラスター信頼性に注力し、2011年型のRedisユーザー層を狙っている

Redisが失ったアイデンティティ

  • Redisは2026年にarray type追加のための大規模PRを検討する段階にまで来ており、これは単純なデータ構造サーバーから複数領域を包摂しようとする製品へ変わった姿を象徴している
  • antirezのarray type PRは、Hash、List、Streamがそれぞれ任意参照、append/trim、append-onlyイベントには強みを持つ一方で、配列のように中間アクセスと範囲可視性を同時に提供できないという問題から出発している
  • RedisにはすでにJSON配列、time-series、sorted-setのように配列的に使える機能があるが、それでも新しい型を追加しようとする方向性自体が機能拡張の性格をよく示している
  • Redisが最初に成功した理由だった単純さ、明快なプロトコル、狭く直交的なコマンド、概念的一貫性が弱まっていることが核心的な問題である

この10年の変化

  • ライセンスと企業の方向性

    • Redis Incは2024年にBSDライセンスを終了し、その後はAGPLv3を唯一のOSIオプションとして含む3重ライセンス体制へ後退した
    • AGPLv3のおかげでRedis Incはオープンソースだと言えるが、BSDとは性格が大きく異なるライセンスである
    • Redisの背後にあるVC支援企業はもともとGarantia DataというNoSQLクラウドホスティングサービスで、Redisホスティングへ移った後にRedis系の名称へ変更し、antirezを迎え入れて正当性を確保した
    • 数年後に商標権を引き継いだ経緯は、その後のライセンス転換の基盤となり、当時の関連記事やコメントは予想通り古びて見える

  • 機能の肥大化と製品ポジショニング

    • Redisは少数の有用なデータ型から始まったが、時がたつにつれて異種のデータ構造、Streamsのような複雑なstatefulシステム、バージョンによっては半ば独占的な性格を帯びるモジュールまで抱え込むようになった
    • 2026年のRedisのランディングページのポジショニングは「The Real-Time Context Engine for AI Apps」へと変わっている
    • ランディングページには「Try Redis for Free」と「Get a Demo」のボタンが並び、スクリーンショットでも確認できる

  • ウェブスケールデータベース志向

    • Sentinel、Cluster、Redis-Raft、active-active geo-distribution®、Redis Flex®、Redis-on-Flash®といった機能は、Redisが「ウェブスケールデータベース」を志向してきたことを示している

  • プロトコルの変化とクライアント側キャッシュ

    • RESP3はRESP2の基本前提だったリクエスト/レスポンスモデルを崩す点が多く、Brooksが語った第二システム症候群に近いものとして評価されている
    • Redisはもともとキャッシュとして広く使われていたが、いまやクライアント側キャッシュを支えるために新しいプロトコルまで必要な状態になっている

初期Redisがうまくはまった理由

  • 時代背景

    • 2011年前後のWeb開発者の間では、NoSQL、「web scale」、Bigtable、Dynamo、Ruby on Rails、REST、JSONといった流れが強かった
    • Redisはこの空気によく合い、ほとんど一夜にして多くのスタックに入り込んだツールになった
    • 2011年末のRedis紹介では、自らをadvanced key-value storeおよびdata structure serverと表現しており、「database」という言葉は使っていなかった

  • Memcachedより優れたリモート辞書

    • memcachedは多くのWebサーバーで静かに動く必須インフラであり、キャッシュ以外にもロック、カウンター、rate limitのような一時的用途によく使われていた
    • Redisは当時「memcached but way better」に近いツールとして受け止められ、名前のRemote Dictionary Serverも高速なインメモリ辞書という性格を強調していた
    • Redisはバイトblobだけでなく、linked-list、hash-table、set、sorted-setのような厳選されたデータ構造を提供し、一時的かつ実用的な用途を大きく広げた

  • 単純で十分に表現力のあるプロトコル

    • Redisのwire protocolは、1時間もあれば理解して実装できるほど単純でありながら、複数のデータ型を表現するのに十分強力だった
    • クライアントライブラリの実装は単純でクリーンであり、プロトコル自体も自然に感じられると評価されていた
    • Redisプロトコルと単純なサーバーを自作するwrite your own Redisチュートリアルは、約10年前に書かれた人気記事として今も残っている

  • シングルスレッド、イベント駆動、インメモリ

    • Redisのシングルスレッド設計は、すべての操作の原子性を保証して複雑さを大きく減らし、推論を容易にした
    • シングルスレッドを成立させるには、サーバーがnon-blocking I/Oで実装され、データ操作も非常に高速である必要があった
    • この組み合わせによって、多数のクライアントを処理できる高速なkey/value storeを単一スレッドで実現できた

  • Webアプリケーションに合ったデータ構造

    • 文字列と有効期限はキャッシュに、リストはキューに、ハッシュは構造化データに適していた
    • ロック、カウンター、rate limiting、liveness、モニタリング、リーダーボードのような用途も、組み込みデータ型だけで容易に構成できた

データベースになろうとする野心

  • Redisの採用は急速に増え大きな成功を収めたが、ある時点からプロジェクトの野心はdatabaseになる方向へ変わった
  • 一部の機能は実際に有用であり、Redis 5.0に追加されたBZPOPMINはsorted-setをpriority queueとして使う際にblocking popを可能にし、実用性を高めた
  • 一方でACLのような機能はRedisらしく見えず、全体としてRedisを万人向けの万能ツールにしようとする欲求が目立った
  • Redisの機能追加は、この10年で開発者たちがHacker Newsで語ってきた「最新の流行」を追った様相と重なっている
    • MongoDBがJSONを保存するなら、Redisもdocument databaseになるべきだという方向
    • ElasticSearchがfull-text searchを提供するなら、Redisもsearch engineになるべきだという方向
    • Graph databaseが注目されると、Redisもgraph databaseになろうとしたが、その後RedisGraph EOLに至った
    • Kafkaが注目されると、Redisもevent streaming platformになろうとした
    • ZooKeeperや強整合性データベースが重要になるとRedis-Raftが登場し、AphyrのJepsen分析は必読に近い資料とされる
    • InfluxDBが注目されると、Redisもtime series databaseになろうとした
    • AIの流れに乗り遅れないために、vector setsのようなAI関連機能まで必要になった

機能拡張の代償

  • 第一の問題は、Redisを誰のスタックにも欠かせないツールにした要因を、Redis自身が弱めていることにある
    • Redisは単純で、コマンドは直交的かつ狭く定義され、プロトコルはクリーンで、概念的に一貫したツールだった
  • 第二の問題は、full-text search、event stream processing、strong-consistency key/value、time-series、vector storageを本気で統合したいユーザーは、Redisの制約を引きずった中途半端なモジュールではなく、専門ツールを求めるという点にある
  • Redisの高可用性は複雑で、永続化には微妙なトレードオフがあり、プロトコル負荷やクライアントの断片化も現実の障害になる
  • RedisはPostgresを置き換えるためのツールではなく、ElasticSearchやRabbitMQのようなシステムもそれぞれ独自の基盤として残るべきだ、という立場である
  • Aphyrによる初期Redis-Raft実装の分析では、21件の問題が見つかったとされる
    • 健全なクラスターでの長時間の利用不能
    • 8件のクラッシュ
    • 3件のstale read
    • 1件のaborted read
    • コミット済み更新の喪失につながる5件のバグ
    • 1件の無限ループ
    • クライアントへ論理的に破損した応答を送る可能性がある2件の問題
    • テスト対象だった最初のバージョン1b3fbf6は、実質的に使いものにならない水準だったと評価されている
  • キャッシュでありデータ構造サーバーであるRedisと、「Redis the etcd」や他の専門データベースを目指すRedisとは根本的に異なる提案であり、この隔たりこそが核心的な問題である

Disqueが示した同じパターン

  • antirezは2015年にDisqueを発表し、当時それが実際のユースケースから出発したものではなく、Redisをメッセージキューのように使う人々や他のメッセージキューを見て「astronaut mode」で設計したと明かしている
  • 実際のユースケースなしに個人的な挑戦や学習課題として作られたプロジェクトも優れたものになりうるが、ユーザーが増えた後に現れる長い尾の難題を継続的に解決できるかは別問題である
  • 高可用なメッセージ配送は本質的に解くのが難しい問題であり、CAP定理のどちら側を最適化しても、トレードオフや難題の解決を避けることはできない
  • 2015年にはすでに成熟したメッセージブローカーが多くあり、人々がRedisをメッセージブローカーとして使っていた理由は、Redisをすでに使っており、しかも十分に単純だったからである
  • 必要だったのは新しいメッセージブローカーでも、Redisがより複雑なメッセージブローカーになることでもなかった
  • Disqueは発表直後から事実上のabandonwareとなり、GitHubで8K starsを得ながらも放置された
  • その後Redisモジュールとして書き直されたが、そのプロジェクトもこの7〜8年放置されたままである

Valkeyが示す別の方向

  • Redisの流れを動かした力は、複雑な問題を解こうとする開発者の野心、万人向けの万能な存在になろうとする野心、そしてRedisの所有者がAWSやGCPに押し切られる前に最大限の収益を引き出そうとする野心にまとめられる
  • 野心そのものが問題なのではなく、成功の理由を失わせるときに問題になる
  • Valkeyの存在と採用は、この力学に対するより広い市場の最終判断として示されている
  • Valkeyは機能追随や比較表のbullet pointではなく、マルチスレッド性能、メモリ効率、クラスター信頼性、スループット改善といった地味だが重要な作業に投資している
  • Valkeyの性能ベンチマークは印象的であり、2011年のRedisが提供していた機能で十分だと考えるRedisユーザーの80%を真正面から狙っている
  • Valkeyの世界では、新しいarray typeは必要ないという結論につながる

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見

  • オープンソースをかなり大きな規模まで育て、会社を立ち上げて数億ドルの売上やIPO、数十億ドルでの売却まで経験し、その過程でOSSから外れるライセンス変更も行った立場から見ると、Redisの「AIアプリのためのリアルタイム・コンテキスト・エンジン」というポジショニングは、方向性としては正しく見える
    ソフトウェア購入には実利用者と**技術意思決定者（TDM）**がいるが、Redisのランディングページは実際に使う開発者より、予算権限を持つTDMを狙ったサイトに見える。多くのTDMは「IBMを選んで解雇された者はいない」のような、解雇されにくい決定を好み、GartnerやMcKinseyがAI戦略とコンテキスト管理を強調すれば、「AIアプリ向けContext Engine」は防御可能な購買理由になる
    HashiCorpでも terraform.io は実務者向け、hashicorp.com はTDM向けに分けようとして、ある程度は機能したが限界もあった。開発者主導のOSS企業には難しい問題だ
    「Redisを無料で使う」と「デモを受ける」ボタンも、TDMの観点では不自然ではない。TDMは技術的判断の責任を負いたがらず、むしろお金を払ってソフトウェアを買いたがるので、無料は体験版のように位置づけ、人とつながるコールトゥアクションを前面に出す
    Redis Inc. の経営陣は、開発者や運用担当者よりTDMに訴求するほうが重要だと結論づけたようで、内部データなしに正しいとも間違いとも言いにくいが、意図なく取られた戦略ではないはずだ
    機能を追加し続けるのも、新しいツールを導入するコストより既存ツールを拡張するコストのほうがはるかに低いからだ。商業的動機がなくても、プログラミング言語は中核的なアイデンティティを守るより、あらゆる機能の最小公倍数になりがちであり、商業企業では「land and expand」が強く働く。代表機能で最初の契約を取り、その後で平均的な追加機能を付けて売っても、調達部門は新規契約より既存契約の拡張のほうを簡単に処理できる
    「本気の顧客は全文検索、イベントストリーム、強整合性KV、時系列、ベクターストアには本物の専用製品を求めるはずだ」という主張も非常に論争的だ。公開ソフトウェア企業のデータを見るだけでも、顧客は非技術的な理由で、より悪い選択肢をしばしば選ぶ
    Valkeyが市場の最終判定だというのも断定しにくい。Valkeyは平均的なフォークよりはるかにうまくやっているが（https://redmonk.com/sogrady/2026/…
    商業的利益を擁護したいわけではなく、そちら側から見た観点を共有しているだけだ。同じ農産物でも、買い物をする人と農家とでは見る問いや目標がまったく違うのに似ている

    • 商業的観点での「なぜ」がうまく説明されていて、Redisが純粋なソフトウェアの真空状態にあるわけではなく、OSSオタクがターゲットではなく、意思決定者はシステムエンジニアとは異なる基準を持つ、という文脈が補われている
      ただ、この論理はみんなの目標が金だと前提しているようにも感じる。Redisで莫大な金を稼ぐという野心は、あくまで特定の野心にすぎず、antirezが文中で見せた姿勢からは、彼が金をそれほど重視する人だったようには読めない
      反例としてSQLiteがある。数百万の売上や数十億ドルでの売却を語ることなく、よく定義された何かを静かに提供することに集中している。SQLiteは最も人気のある組み込みデータベースになった理由を失っておらず、大規模データベース側ではPostgresも同様だ。金と商業的利害の世界に対しても、それと同じくらいこの世界から反例を持ち出せる
      Redisについては、「すでにAWS/GCPを使っているのだから、そちらのRedisっぽいものを使おう」が水平展開の自然な帰結に見える。よりIBM的な道はクラウドプロバイダーを選び、そのRedisを使うことだが、今ではそれがValkeyになっている
      人々がより悪い選択肢を選ぶというのは論争点ではなく事実であり、Redisがそういうモードで拡張されたことこそ、まさに強調したかった野心と漂流の一例だ
    • Redis Labsで働いていたので、ほとんど文字どおり悪魔の開発者擁護人の立場だった。退職時にベストしたオプションは行使せず、Silicon Valleyからかなり離れた場所に住んでいるので、あまり橋を焼く心配なく話せる
      以前は redis.com がTDM向けサイトで redis.io が開発者向けだったが、Redis Labsがantirezの持っていた redis.io を取得したあと、ダウンロードリンクすら見つけにくいほど壊してしまい、今では両方のURLがTDM向けサイトに飛ぶ。今でもRedisのダウンロードリンクは簡単には見つからず、自分で探してみてほしいくらいだ
      核心的な問題は、Redis Labsが常にマーケティング・リーダーシップの採用にひどく失敗してきたことにある。CMOやVPたちがやって来て、短期間で好感度を可能な限り燃やし尽くし、6か月後には「次の冒険」へ去っていった。redis.io のトラフィックが redis.com よりはるかに多いのを見て、ダウンロードリンクを見つけられなかった人が「try free」を押すことを期待して redis.io を壊したのも、そうした短期的クリック欲の典型に見える
      追加機能の販売は、競合との差別化をチェックボックス上で示すのにも役立つ。特に価格で競争しにくいときはそうで、AWSはElastiCacheに強いクラウド割引を抱き合わせられたし、最悪の競争相手は無料のオープンソースRedisだった
      Valkeyには一般的なフォークよりはるかに多くの金が投入されている。たとえばRedis Labsの元デベロッパー・リレーションズ責任者が今はAWSでValkeyに関わっている
      ただ、Valkeyが「派手ではない作業」しかしていないという評価は残念だ。Redisはすでにかなり前からマルチスレッド化されており、コントロールプレーンは今でもシングルスレッドだが、I/Oはマルチスレッドなので、Valkeyの仕事は筆者が考えているほど新しいものではない
      Valkeyは露骨に、AWSなどのクラウド企業が誰にも金を払わずRedisを売り続けられるようにする作戦だ。その他の理屈は、彼らがやり続けたいことを正当化するためのマーケティング道具にすぎず、Redisとの互換性を壊すほうが商業的に有利だと判断すれば、そうするだろう。すでに双方である程度そうなっている可能性にもそこそこ賭けられるが、十分には追っていない
      派手ではない作業をしながら単純さを保とうとする本当のRedisフォークが欲しいなら、redict がある
      それでもRedisの時代は終わりに向かっていると思う。今の奇妙な商業的地形では、各フォークがそれぞれどこかで足を引きずっている。最も徳のある redict ですら、antirezが独裁者のように元プロジェクトを押し進めていた時代と同じやり方でRedisを前に進めようという本気の関心は不足している。ソフトウェアが「完成」することが悪いという意味ではないが、Redisにはまだ探れる素晴らしい未開拓領域があると思っており、商業的フォークがそうした生態系を生むかは疑わしい。もちろんArraysやAI関連応用の価値を過小評価しているのかもしれないので、耳は開いていたい
      振り返ると、Redis Labsがこのすべてをここまでひどく台無しにしたのは驚くべきことで、時間が十分にたったおかげで今は以前ほど腹が立っていないのは幸いだ
    • 企業は金を払わずに、できるだけ多くを持っていこうとしているのではないかと思う。だからRedis、MongoDB、HashiCorpも結局ライセンスを変えたのではないかと思う

  • 会社でLuaスクリプトを使って、より公平なジョブキューシステムを作っているのだが、Redisはとても奇妙に感じる。頭の中のモデルはいつも「単純なキーバリューストア」だったのに、グローバルロックの中でLuaスクリプトを実行する機能のような、いろいろな機能を学ぶことになる
    ところが文書はきらびやかなウェブサイトに載っていて、明確に教えてくれない。設定値も設定サンプルの中でしか説明されていないような感じだ
    Redisがよく動くことは知っているし、皆そう言うのだが、Redisの機能を学んでいく体験はかなり不便だ。誰かが本当に良いプログラムを作ったのに、良いプログラムなら普通備わっているはずの優れた文書を忘れてしまったような感じがある
    変な不満ではある。Redisは極端によく動いているようだし、Postgresの文書のように「全部」を説明してくれる文書が好きだ

    • TDM志向が弱い製品の文書のほうが分かりやすいのか気になる: https://valkey.io/topics/programmability/
      多くのオープンソースプロジェクトも文書が弱いことはよく知られているので、この実験には尖った頭の上司という変数だけがあるわけではなさそうだ
    • Redisには以前、いろいろな文書があったし、幸いWayback MachineでRedis Labsが加えた損傷を巻き戻せる。ここで欲しいものが見つかるかもしれない: https://web.archive.org/web/20190725152042/…
      redict も文書が良さそうだ: https://redict.io/docs/scripting/