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

Redis 7.0のリリースは順調に進んでおり、2番目のリリース候補を公開しました。このリリース候補は、バージョンの機能を完了することを目的とした計画されたマイルストーンですが、新しいバージョンで追加のコンテンツを提示する機会でもあります。たとえば、Redis関数は、バージョン2.6以降にRedisが持っていたスクリプトの既存のサポートから進化しました。同様に、Redisの機能の多くが進化しました。

自然界では、進化は明らかにランダムに起こり、自然淘汰がその結果を整理します。一般に、ソフトウェア一般、特にRedisでは、このプロセスは逆方向に発生します。目的のパスを選択し、それに応じてプロジェクトを進化させます。ランダム性によって将来を決定するのではなく、ロードマップの計画と実行は、主にユーザーのフィードバックとRedisが適している新しいユースケースによって導かれます。

Redis 7.0では、アクセス制御リスト（ACL）も進化のはしごを強化していました。 Redis 6.0で導入されたACLは、ユーザーとその権限を管理するメカニズムを追加することで、セキュリティに関する長年の見方をプロジェクトの範囲外であると逆転させました。しかし、私たちのコミュニティは、それが正しい方向に進んだ一歩であるにもかかわらず、この機能にはまだ必要な機能が不足していることをすぐに教えてくれました。

ACLのギャップの1つは、Redis 6.2によってすでに対処されています。つまり、Pub/Subチャネル名の許可されたパターンを制御します。しかし、それは部分的な一時的なギャップに過ぎず、残りのアプローチに対処するためのシンプルで効果的なアプローチを考え出すのに時間がかかりました。

ACLの元の設計は、基本的なアクセス制御のユースケースに対してのみプロビジョニングされていました。これにより、ユーザーごとに1セットのコマンド、キー、およびチャネルの名前パターンへのアクセスのみを許可または拒否できるようになりました。たとえば、 `SET`コマンドをキーの1つのサブセットに制限すると同時に、特定のユーザーのキーの別のサブセットに`GET`を許可することは不可能でした。事実上、ACLはセキュリティポリシーを実装するための効果的なメカニズムではありませんでした。

Redis 7.0のアクセス制御リスト（略してACLv2）は、元のリストと互換性がありますが、2つの重要な改善が追加されています。まず、ACLv2はすべてセレクターに関するものです。次に、ACLv2では、特定のキーにアクセスタイプのアクセス許可を設定できます。この機能により、ユーザーを読み取り専用、書き込み専用、または読み取り/書き込み操作に限定して、キーのサブセットに限定することができます。

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

サーバーの内省的な機能は、バージョン7.0で大幅に進歩したRedisのもう1つの側面です。 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では、親や兄弟に関係なく、すべてのサブコマンドに独自の特性セットがあり、正確な説明が可能です。

この投稿は、テキストの壁であり、おそらくその終わりに向かって技術的な詳細が多すぎることが判明しました（技術的な詳細が多すぎるなどの場合でも）。しかし、それがすべて退屈ではなかったこと、そして新しいバージョンとそのプロジェクトへの適合性に光を当てたことを願っています。バージョンの一般提供に向けて最終リリース候補に取り組んでいますが、新しいバージョンのツアーを継続するシリーズの次の投稿にご期待ください。