Redis 7.0의 출시가 순조롭게 진행 중이며 두 번째 출시 후보를 발표했습니다. 이 릴리스 후보는 버전의 기능을 완성하기 위한 계획된 이정표이지만 새 버전에서 추가 콘텐츠를 제공할 수 있는 기회이기도 합니다. 예를 들어, Redis Functions는 Redis가 버전 2.6 이후로 제공했던 스크립팅에 대한 기존 지원에서 발전했습니다. 마찬가지로 Redis의 기능도 더 많이 발전했습니다.
자연에서 진화는 분명히 무작위로 발생하며 자연 선택은 결과를 분류합니다. 일반적으로 일반적으로 소프트웨어, 특히 Redis에서 이 프로세스는 역방향으로 발생합니다. 원하는 경로를 선택하고 그에 따라 프로젝트를 발전시킵니다. 무작위성이 미래를 결정하게 하기보다 로드맵의 계획 및 실행은 주로 사용자의 피드백과 Redis가 적합한 새로운 사용 사례에 따라 결정됩니다.
Redis 7.0에서는 ACL(액세스 제어 목록)도 한 단계 더 발전했습니다. Redis 6.0에 도입된 ACL은 사용자와 권한을 관리하는 메커니즘을 추가하여 보안에 대한 오랜 시각을 프로젝트 범위 밖이라고 생각했습니다. 그러나 커뮤니티는 올바른 방향으로 나아가는 단계이지만 여전히 필요한 기능이 부족하다는 사실을 빠르게 알려 주었습니다.
ACL의 격차 중 하나는 Redis 6.2에서 이미 해결되었습니다. 즉, Pub/Sub 채널 이름의 허용된 패턴을 제어합니다. 그러나 그것은 부분적인 임시방편에 불과했고 나머지 문제를 해결하기 위해 간단하고 효과적인 접근 방식을 찾는 데 더 오랜 시간이 걸렸습니다.
ACL의 원래 디자인은 기본 권한 제어 사용 사례에 대해서만 프로비저닝되었습니다. 사용자당 단일 명령 세트, 키 및 채널 이름 패턴에 대해서만 액세스를 허용하거나 거부할 수 있습니다. 예를 들어 'SET' 명령을 키의 한 하위 집합으로 제한하는 동시에 주어진 사용자에 대해 'GET'을 다른 키 하위 집합으로 허용하는 것은 불가능했습니다. 사실상 ACL은 보안 정책을 구현하는 효과적인 메커니즘이 아니었습니다.
Redis 7.0의 액세스 제어 목록(ACLv2)은 원본과 호환되지만 두 가지 중요한 개선 사항이 추가되었습니다. 첫째, ACLv2는 모두 선택기에 관한 것입니다. 둘째, ACLv2를 사용하면 특정 키에 대한 액세스 유형 권한을 설정할 수 있습니다. 이 기능을 사용하면 사용자가 키의 하위 집합에 대해 읽기 전용, 쓰기 전용 또는 읽기-쓰기 작업을 독점적으로 수행하도록 제한할 수 있습니다.
원래 ACL 디자인은 사용자당 하나의 선택기(기본 선택기)만 제공했습니다. 선택기는 사용자가 액세스할 수 있는 키와 채널, 범주 및 명령을 설명합니다. ACLv2를 사용하면 순서대로 적용되는 기본값 위에 원하는 수의 선택기를 추가할 수 있습니다. 이 접근 방식은 보다 까다로운 보안 정책의 요구 사항을 충족하고 ACL을 완성도에 더 가깝게 만듭니다.
서버의 내성적인 기능은 버전 7.0에서 크게 발전한 Redis의 또 다른 측면입니다. Redis는 API가 상호 작용하는 명령 사전인 API를 노출합니다. 프로젝트가 발전함에 따라 다양한 명령(및 해당 하위 명령)의 수가 증가하여 버전 7.0에서는 380개를 초과했습니다. 모든 Redis 명령은 주어진 작업에 특화되어 있기 때문에 각 명령의 호출 인수와 동작을 문서화하는 것이 프로젝트의 핵심 원칙입니다. 이 문서는 서버와 클라이언트 간의 유일한 계약입니다.
역사적으로 명령은 별도의 코드 리포지토리에서 프로젝트 자체의 외부에 문서화되었습니다. 모든 문서는 사람이 읽을 수 있도록 만들어졌기 때문에 (대부분) 사람이 읽을 수 있는 형식으로 보관했습니다. 이것은 산문을 코드로 번역하는 것이 지저분하고 부서지기 쉽기 때문에 기계(또는 기계를 프로그래밍하는 사람)에게 도전 과제를 제시했습니다. 특히 Redis용 클라이언트 작성자는 문서 변경 사항을 모니터링하고 릴리스 정보를 읽어 프로젝트를 최신 상태로 유지하기를 바랄 뿐입니다.
그래서 버전 2.8에서는 서버가 명령을 보고할 수 있도록 하는 프로그래밍 방식도 필요하다는 것을 깨달았습니다. 적절하게 명명된(하지만 혀를 뒤흔드는) `COMMAND` 명령은 서버가 지원하는 명령을 런타임에 나열합니다. 또한 'COMMAND GETKEYS' 하위 명령을 사용하면 클라이언트가 그대로 명령과 해당 인수를 보내 서버가 키 이름을 추출하도록 할 수 있습니다. 클라이언트가 클러스터된 배포에서 올바르게 작업을 지시할 수 있도록 명령에서 키 이름을 추출해야 합니다.
부분적으로는 ACLv2 관련 노력에 힘입어 런타임 명령 목록을 클라이언트에 더 유용하게 만들기 위해 버전 7.0은 서버 명령 관리의 내부 메커니즘 대부분을 정밀 검사합니다. 또한 서버가 각 명령에 대해 보관하는 메타데이터를 풍부하게 하여 서버 기능에 대한 사전 지식이 거의 없는 정교한 클라이언트를 구축할 수 있도록 했습니다. 마지막으로, 수정된 명령 테이블은 Redis 모듈이 핵심 명령과 동일한 수준의 내성을 제공하기 위해 해당 명령으로 확장할 수 있는 방식으로 구축되었습니다.
새로운 명령 키 사양을 사용하면 클라이언트가 클러스터의 서버를 사용하지 않고 축자 명령에서 로컬로 키를 추출할 수 있으므로 대기 시간이 개선되고 네트워크 대역폭이 줄어듭니다. 명령 인수에 대한 메타데이터를 통해 클라이언트는 서버 버전 간의 명령 구문 변경 사항을 발견하고 이에 적응할 수 있습니다. 클라이언트는 명령 팁에서 특수한 상황과 다양한 배포 유형에서 명령을 실행하는 방법에 대해 더 많은 정보를 얻을 수 있습니다.
이 노력에는 하위 명령을 서버 명령 테이블의 일급 시민으로 승격하는 것도 포함되었습니다. 원래 하위 명령은 API의 계속 증가하는 카디널리티를 방지하기 위해 Redis에 도입되었습니다. 이유는 모든 작업에 대해 새 명령을 추가하는 대신 "부모" 명령 하나만 호출하여 관련 작업을 호출한다는 것입니다. "parent" 명령은 첫 번째 인수로 하위 명령의 이름을 받아들이고, 이는 차례로 수행되는 작업을 나타냅니다. 기술적인 관점에서 하위 명령은 상위 명령의 모든 특성(예:ACL 범주, 읽기/쓰기 플래그, 키 사양 등)을 상속하므로 서로 다른 동작을 세밀하게 구분할 수 없습니다.
예를 들어, 'CLIENT' 명령은 15개 이상의 다른 하위 명령을 자랑하는 연결 관리 작업을 위한 포괄적인 바구니입니다. 'CLIENT SETNAME'과 같은 일부 하위 명령은 일반 클라이언트 연결에 의해 일상적으로 호출되는 반면, 'CLIENT KILL'과 같은 다른 명령은 오용 가능성이 있으므로 관리자만 사용하도록 제한해야 합니다. 이전 버전의 Redis에는 이러한 구분을 지원하는 내부 메커니즘이 없었기 때문에 개발자가 문서로 이동하고 혼란을 야기했습니다. 그러나 Redis 7.0에서 모든 하위 명령에는 부모나 형제에 관계없이 고유한 특성 집합이 있으므로 정확한 설명이 가능합니다.
이 게시물은 끝으로 갈수록 기술적인 세부 사항이 너무 많이 들어가는 텍스트 벽으로 밝혀졌습니다(기술적인 세부 사항이 너무 많은 경우). 그래도 지루하지 않았으면 하고, 새 버전과 프로젝트에 대한 적합성에 대해 조금이나마 설명했습니다. 우리는 버전의 일반 공급을 위해 최종 릴리스 후보를 작업 중이지만 새 버전의 투어를 계속할 시리즈의 다음 게시물을 기대해 주십시오.