Redisと野心の代償：機能肥大化のケーススタディ

Redisの進化は、成功したソフトウェアプロジェクトにとって教訓となる物語を提供しています。それは、あらゆる人にとっての「すべて」になろうと追求するあまり、自らのアイデンティティを失うリスクです。当初は、焦点を絞ったエレガントな「data structure server」として始まったものが、今や広大な「AIアプリのためのReal-Time Context Engine」へと変貌を遂げており、この移行はシステムエンジニアやオープンソースコミュニティの間で大きな議論を巻き起こしています。

エレガンスの時代：Data Structure ServerとしてのRedis

初期の頃、Redisは2010年代初頭の時代精神を捉えていました。それはデータベースとしてではなく、「advanced key-value store」および「data structure server」として位置づけられていました。その成功は、現代のウェブスタックにおいて即座に不可欠なものとなった、いくつかの重要な設計上の選択に根ざしています。

• シンプルで表現力豊かなプロトコル: ワイヤプロトコルは、数時間で実装できるほど直感的でありながら、豊かなデータ型を扱うのに十分なほど強力でした。
• シングルスレッド・アーキテクチャ: シングルスレッドかつイベント駆動であり続けることで、Redisはすべての操作に対して原子性を保証し、膨大な種類の並行性バグを排除し、システムの推論を容易にしました。
• 洗練されたプリミティブ: あらゆる可能な機能を提供するのではなく、Redisは、キャッシュやキュー、レート制限、リーダーボードなど、ウェブアプリケーションのニーズの大部分をカバーする、厳選されたいくつかのプリミティブ（strings, lists, sets, sorted sets）を提供しました。

野心へのシフト

時間の経過とともに、プロジェクトの野心は変化しました。Redisは、補助的なユーティリティから主要なデータベースへと移行し始めました。このシフトは、NoSQLやデータベースの分野におけるあらゆる「クール」なトレンドを反映しようとする欲求によって特徴づけられます。Hacker Newsや業界で新しい技術が注目を集めるたびに、Redisは同様の機能を統合しようと試みました。

• ドキュメントストレージ: MongoDBに従い、RedisはJSONサポートを追加しました。
• 検索: Elasticsearchに従い、検索およびクエリ機能を導入しました。
• イベントストリーミング: Kafkaに従い、Streamsを実装しました。
• 一貫性: 強力な一貫性を提供しようとする試みとして、Redis-Raftが導入されました。
• AIとベクトル: 現在のAIの波に乗るために、ベクトルセットやAI駆動のコンテキストエンジンへと軸足を移しました。

このような「宇宙飛行士モード」の開発——特定のユーザーニーズではなく、個人的な挑戦やハイプ（熱狂）への反応として機能を作り上げること——は、しばしば断片的な結果を招きました。著者は、Disqueをその典型的な例として挙げています。これは、市場の特定のギャップに応えるためではなく、人々がRedisをどのように「使用していたか」への反応として構築されたプロジェクトであり、最終的には放棄されたソフトウェア（abandonware）となりました。

機能肥大化の結末

この拡張には代償が伴いました。著者は、RabbitMQ、Elasticsearch、またはetcdのような専門的なツールに取って代わろうとすることで、Redisは自らの核となる価値提案を希薄化させてしまったと主張しています。

最も顕著な問題の一つは、「Redis module」と専用システムとの間のギャップです。例えば、Redis-RaftのJepsen分析では、データの損失や利用不可を含む重大な失敗が明らかになり、複雑なシステムの不完全な実装は、インフラストラクチャの基盤となる柱を代替することはできないことを示唆しています。

さらに、Redis Inc.による企業的なシフト——物議を醸したBSDライセンスからAGPLv3を含むトライライセンスへの変更を含む——は、コミュニティとの間に亀裂を生じさせました。焦点は技術的なエレガンスから、エンタープライズ販売を目的としたCTAや「demo」ボタンへと移っています。

反論： 「Postgres」論法

すべての観察者がこの拡張を失敗と見なしているわけではありません。単一のサービスが複数のニーズに応える能力は、バグではなく「機能」であると主張する人々もいます。一般的な反論は、PostgreSQLとの比較です。

Why does Postgres get a pass on being a message queue, distributed lock manager, JSON document store, and vector database, while Redis is not allowed to? （なぜPostgresはメッセージキュー、分散ロックマネージャー、JSONドキュメントストア、ベクトルデータベースとしての役割を許容されているのに、Redisはそれが許されないのか？）

この観点からは、より多くのデータ構造を追加することは、核となるkey-value機能の低下を本質的に招くものではありません。核となる部分が高速で信頼できるままであれば、追加の機能は単にツールのユー用性を高めるだけです。

市場の審判：Valkeyの台頭

Valkeyの出現は、市場のシグナルとして機能しています。最新の機能の箇条書きを追いかけるのではなく、Valkeyは「地味な」作業に焦点を当てています。つまり、マルチスレッド性能の向上、メモリ効率、およびクラスターの信頼性の向上です。

2011年当時のRedisが持っていた、高速で信頼できるdata structure serverとしてのユーザーの80%をターゲットにしていることから、Valkeyは、業界の主要なニーズは新しい配列型やAIコンテキストエンジンではなく、Redisの本来の、洗練された、軽量なビジョンを洗練させたバージョンであるということを示唆しています。