Redis 7.0の進化：ACL v2とコマンド管理の大幅強化

Redis 7.0：複数の面にまたがる進化

Redis 7.0のリリースに向けた開発は順調に進んでおり、このたび2つ目のリリース候補（RC2）を公開しました。今回のリリース候補は、バージョンの機能を確定させるための計画的なマイルストーンであると同時に、新バージョンの追加コンテンツをご紹介する絶好の機会でもあります。たとえば、Redis Functionsは、バージョン2.6以来サポートされてきたスクリプト機能から進化したものです。同様に、Redisの他の多くの機能も進化を遂げています。

自然界における進化は一見ランダムに起こり、その結果は自然選択によってふるい分けられます。しかし、ソフトウェア全般、そして特にRedisにおいては、このプロセスは逆向きに進みます。つまり、望ましい方向性を選び、それに沿ってプロジェクトを進化させていくのです。偶然に未来を委ねるのではなく、ロードマップの計画と実行は、主にユーザーからのフィードバックや、Redisが適合する新しいユースケースによって導かれています。

ACLv2：セキュリティ機能の大きな飛躍

Redis 7.0では、アクセスコントロールリスト（ACL）も進化の一歩を踏み出しました。Redis 6.0で導入されたACLは、「セキュリティはプロジェクトの範囲外」という長年の見方を覆し、ユーザーとその権限を管理するメカニズムを追加しました。しかしコミュニティからは、「方向性は正しいものの、まだ必要な機能が不足している」という指摘が寄せられました。

ACLのギャップの一つは、すでにRedis 6.2で解決されています。それはPub/Subチャネル名の許可パターンを制御する機能です。しかしそれは部分的な応急措置にすぎず、残りの課題に対するシンプルかつ効果的なアプローチを考案するには、さらに時間が必要でした。

ACLの当初の設計では、基本的な権限管理のユースケースのみが想定されていました。ユーザーごとに、コマンド・キー・チャネル名のパターンを1セットだけ許可または拒否できる仕組みです。たとえば、特定のユーザーに対してSETコマンドをあるキーのサブセットに制限しつつ、GETコマンドは別のキーのサブセットに許可するといったことはできませんでした。実質的に、ACLはセキュリティポリシーを実装するための効果的なメカニズムとは言えなかったのです。

Redis 7.0のアクセスコントロールリスト（略してACLv2）は、元の設計との互換性を保ちながら、2つの重要な改善を加えています。第一に、ACLv2はセレクタを中心とした設計になったこと。第二に、特定のキーに対してアクセス種別の権限を設定できるようになったことです。これにより、キーのサブセットに対して、読み取り専用・書き込み専用・読み書き両方のいずれかにユーザーの操作を限定することが可能になります。

元のACL設計では、ユーザーごとに1つのセレクタ（デフォルトセレクタ）しか提供されていませんでした。セレクタは、ユーザーがアクセスできるキーとチャネル、カテゴリ、コマンドを記述するものです。ACLv2では、デフォルトのセレクタの上に任意の数のセレクタを追加でき、それらは順番に適用されます。このアプローチにより、より厳格なセキュリティポリシーの要件を満たせるようになり、ACLは完成度へと近づいています。

サーバーのイントロスペクション能力の向上

サーバーの自己検査（イントロスペクション）能力も、Redisがバージョン7.0で大きく前進させた側面の一つです。RedisはAPIとしてコマンド辞書を公開しており、これを通じて外部とやり取りします。プロジェクトの発展に伴い、コマンド（およびサブコマンド）の数は増え続け、バージョン7.0では380を超えるまでになりました。すべてのRedisコマンドは特定のタスクに特化しているため、各コマンドの呼び出し引数と動作を文書化することはプロジェクトの基本原則であり、このドキュメントこそがサーバーとクライアント間の唯一の契約となります。

歴史的には、コマンドのドキュメントはプロジェクト本体とは別のコードリポジトリで管理されてきました。人間が読むことを想定していたため、（ほぼ）人間が読みやすい形式で維持していました。しかし、これは機械にとって（正確には、機械をプログラミングする人々にとって）大きな課題となりました。散文をコードに変換する作業は面倒で壊れやすいからです。具体的には、Redisクライアントの開発者は、ドキュメントの変更を監視し、リリースノートを読むことでしか、自分のプロジェクトを最新の状態に保てませんでした。

そこでバージョン2.8の時点で、サーバーが自身のコマンドを報告できるプログラマティックな方法が必要だと気づきました。その名もズバリ（そして少し舌を噛みそうな名前の）COMMANDコマンドは、実行時にサーバーがサポートするコマンドを一覧表示します。さらに、COMMAND GETKEYSサブコマンドを使うと、クライアントはコマンドとその引数をそのまま送信し、サーバーにキー名を抽出させることができます。クラスタ構成の環境で操作を正しく振り分けるには、コマンドからキー名を抽出することが不可欠なのです。

ACLv2関連の取り組みに一部後押しされた形ですが、実行時のコマンドリストをクライアントにとってより有用なものにするためにも、バージョン7.0ではサーバーのコマンド管理に関する内部メカニズムの多くを見直しました。さらに、サーバーが各コマンドについて保持するメタデータを充実させ、サーバーの能力に関する事前知識が（ほぼ）なくても高度なクライアントを構築できるようにしています。最後に、刷新されたコマンドテーブルは、Redisモジュールがそれぞれのコマンドで拡張できるよう設計されており、コアコマンドと同等レベルのイントロスペクションを提供できます。

コマンドキー仕様とメタデータの活用

新しいコマンドキー仕様により、クライアントはクラスタのサーバーに問い合わせることなく、逐語的なコマンドからローカルでキーを抽出できるようになり、レイテンシの改善とネットワーク帯域幅の削減が実現しました。コマンド引数に関するメタデータにより、クライアントはサーバーバージョン間でのコマンド構文の変化を検出し、柔軟に対応できます。さらに、コマンドヒントからは、特殊な状況下や異なるデプロイメントタイプでコマンドを実行する際の詳細な情報を得ることが可能です。

サブコマンドの一人前のコマンドへの昇格

この取り組みには、サブコマンドをサーバーのコマンドテーブルにおける一人前の存在（ファーストクラスシチズン）へと昇格させることも含まれています。そもそもサブコマンドは、増大し続けるAPIの基数（カーディナリティ）に対抗するためにRedisに導入されました。すべてのタスクごとに新しいコマンドを追加する代わりに、関連するタスクは1つの「親」コマンドの呼び出しで実行できるようにするという考え方です。「親」コマンドは最初の引数としてサブコマンド名を受け取り、それによって実行されるアクションが決定されます。しかし技術的な観点から見ると、サブコマンドは親コマンドの特性（ACLカテゴリ、読み取り/書き込みフラグ、キー仕様など）をすべて引き継ぐため、それぞれの異なる動作をきめ細かく区別することができませんでした。

たとえば、CLIENTコマンドは接続管理タスクを網羅するコマンドで、15以上の異なるサブコマンドを備えています。CLIENT SETNAMEのようなサブコマンドは通常のクライアント接続から日常的に呼び出されますが、CLIENT KILLのようなサブコマンドは誤用される恐れがあるため、管理者専用に制限すべきものです。以前のバージョンのRedisには、こうした区別をサポートする内部メカニズムがなかったため、開発者はドキュメントに頼るしかなく、混乱を招いていました。しかしRedis 7.0では、すべてのサブコマンドが親や兄弟に関係なく独自の特性セットを持つようになり、正確な記述が可能になりました。

この記事はかなり長文となり、終盤はやや技術的な詳細に入り込みすぎたかもしれません（ただし、「技術的詳細すぎる」ということは本当に存在するのでしょうか）。退屈ではなかったことを願いつつ、新バージョンとそのプロジェクトにおける位置づけについて、いくらか光を当てられていれば幸いです。私たちは一般提供（GA）に向けた最終リリース候補の作業を進めています。新バージョンのツアーを続けるシリーズの次の投稿にも、ぜひご期待ください。