Redis 7.0：最初のリリース候補（RC1）がついに登場！

待望の新バージョンは、既存機能のさらなる進化と新機能の追加に加えて、より少ないリソースでより高いパフォーマンスを発揮します。

Redis 7.0 RC1（リリース候補第1版）がついに公開

本日、Redis v7.0の最初のリリース候補（RC1）が利用可能になったことをお知らせいたします。バージョン7.0は、昨年の大半をかけて開発が進められてきたプロジェクトにとって重要なマイルストーンです。メジャーリリースであるこの機会に、機能面でも内部実装面でも、より大胆な変更を行いました。今後は通常のリリースサイクルに従い、約3週間間隔でさらに2つのリリース候補を経た後、Redis 7.0の正式版（GA）の提供を予定しています。

Redis 7.0の主な新機能

Redis 7.0には、Functions（関数）、ACL v2、シャーデッドPub/Subなど、数多くの新機能が追加されました。これらについては、本記事および今後の一連の記事で順番に詳しく紹介していきます。

さらに注目すべきは、本バージョンへの取り組みの多くが、ほとんどのユーザーには見えにくい部分の改善と最適化に費やされた点です。その範囲は、永続化、レプリケーション、ネットワーク、メモリ、CPU使用率といったRedisのほぼすべてのサブシステムに及んでいます。その結果、これまで以上に高速で安定性が高く、経済的なRedisが実現しました。

「内省」から生まれたメジャーバージョン

今回の新バージョンは、新しいデータ構造の導入や運用面での飛躍的な拡張を掲げるものではありません。むしろ、プロジェクト自身を見つめ直し、既存の設計上の前提に疑問を投げかけ、インフラの改善へより大胆な一歩を踏み出すとともに、コミュニティのニーズやユースケースを深く汲み取ったリリースとなっています。

Redis Functions：プログラマビリティの次のステージ

Redis Functionsは、こうした方針を象徴する機能の一例です。Functionsは、Redisプログラマビリティ（Redisをプログラムする能力）という大きなテーマに属します。「Redisをプログラムする」とは、主にデータローカリティの観点から、サーバー側でユーザーのロジックを実行させることを意味します。プログラマビリティ自体は、バージョン2.6でLuaスクリプトが導入されて以来、Redisの一部となってきました。

Luaスクリプトの採用はそれ以来増え続けています。スクリプトを使えば、Redisのコア操作と制御構造を組み合わせて、シンプルかつ効果的にサーバー側のワークフローを構成できます。また、アプリケーションのネイティブコードから、基盤となるデータ構造を抽象化することも可能です。アプリケーションが持つLuaスクリプト群は、「ユーザー追加」や「注文確定」といった論理操作を実装するものとして機能します。

長年寄せられたスクリプト機能への3つの要望

スクリプティングは長年にわたり人気のあるRedisの機能であり、私たちは多くのフィードバックを収集してきました。その結果、ほとんどの要望は以下の3つのカテゴリーに分類されることが分かりました。

1. 独立性：スクリプトはアプリケーションの一部であり、その内部構造を反映するため、実装と密結合しています。アプリケーション側でスクリプトのソースコードを埋め込み、実行時にロードする必要があります。この結合は、開発、テスト、デプロイメントといったアプリケーションライフサイクルのあらゆる段階で複雑さを増大させます。
2. 実行エンジン：Redisでスクリプトを書ける言語はLuaのみです。しかも、さまざまな技術的理由から、長年にわたり同じLua 5.1を使い続けてきました。より新しいバージョンを求める声もあれば、まったく別の言語を望む声が大多数を占めています。
3. 堅牢性：他のソフトウェアと同様、RedisにおけるLuaスクリプティングの設計と実装にも前提条件や限界があります。場合によっては、この仕組みを拡張することが極めて困難、あるいは不可能になります。この土台の欠如が、イベント処理やクラスタースクリプトといった価値ある機能の追加を妨げてきました。

アプリケーションから独立した「第一級のデータベース市民」

話をRedis Functionsに戻しましょう。Redis 7.0では、Functionsはアプリケーションから完全に独立しています。その結果、Functionsは実行可能なソフトウェア成果物でありながら、第一級のデータベースオブジェクトとして扱われます。RedisサーバーはFunctionsをユーザーデータと同様に管理するため、可用性のために永続化・レプリケーションされます。データベースへのFunctionsのロードは、もはやアプリケーションが実行時に行う責務ではなく、計画・管理可能な管理保守タスクとなります。

Functionsがサーバーのコンテキスト内に存在することで、アプリケーションはFunctionsの実装から解放されます。アプリケーションは関数シグネチャを組み込みロジックへのAPIとして利用するだけで、背後でどのRedisコマンドやデータ型が使われているかを意識する必要はありません。これにより、異なるアプリケーション間でFunctionsを共有できるようになり、アプリケーションに依存しない形でのFunctionsの開発・テスト・保守も可能になります。

エンジン非依存の設計

Redis Functionsの設計は、特定の実行エンジンに依存しない（エンジンアグノスティックな）ものです。Redis 7.0ではLua 5.1で書かれたFunctionsのみをサポートしていますが、内部実装は他の実行エンジンと接続できる状態にほぼ整っています。将来的には、より多様な種類の実行エンジンのサポートを追加していく予定です。

ライブラリという新しいパラダイム

Functionsがもたらすもう一つのパラダイムシフトが、ライブラリの活用です。ライブラリは、1つ以上の登録済み関数（registered functions）と、必要に応じて内部的な関数で構成できます。登録済み関数はライブラリのエントリーポイントであり、アプリケーションとの契約上のAPIとなります。一方、内部関数はライブラリ内で直接呼び出せるため、コードの再利用性が高まります。

まとめ：Redisプログラマビリティの未来へ

Redis 7.0へのFunctionsの導入は、Redisのプログラマビリティを次のステージへ引き上げる大きな一歩になると期待しています。すでにアプリケーションでLuaスクリプトを使用している場合でも、Functionsへの移行は任意であり、かつ簡単です（詳細はRedis Functionsの公式ドキュメントをご覧ください）。さらに良いことに、今後はFunctionsが、Redisプログラマビリティの改善と革新のための、より優れた基盤を提供してくれるでしょう。