Redis와 Valkey, 라이선스 변경으로 갈라진 두 프로젝트

AWS에서 ElastiCache로 캐시를 만들려고 하면 엔진을 고르는 단계가 나온다.
목록에는 Valkey, Memcached, Redis OSS가 있다.
Redis는 들어 봤어도 Valkey라는 이름은 낯설 수 있다.

Valkey와 Redis는 같은 코드에서 출발했다.
2024년에 하나가 둘로 갈라졌고, 그 계기는 라이선스 변경이었다.
Redis가 어떤 일을 하는 프로그램인지부터 정리한다.

메모리에 사본을 두는 캐시

데이터베이스는 보통 데이터를 디스크에 저장한다.
오래 보관하기에는 좋지만, 같은 값을 초마다 수천 번 읽는 서비스라면 매번 디스크까지 다녀오는 일이 부담이 된다.

그래서 자주 읽는 값의 사본을 메모리에 올려 두고, 요청이 오면 그쪽이 먼저 답하게 한다.
이렇게 원본의 임시 사본을 더 빠른 곳에 두는 방법을 캐시(cache)⁠라고 한다.

캐시에 값이 있으면 메모리에서 바로 응답하고, 없을 때만 데이터베이스를 읽어 그 결과를 캐시에 채워 넣는다.
앞의 경우를 캐시 적중(hit), 뒤의 경우를 캐시 미스(miss)⁠라고 부른다.

사본을 두면 원본이 바뀔 때 사본도 맞춰 줘야 한다.
상품 가격을 바꿨는데 캐시에 옛 가격이 남아 있으면 안 된다.
이렇게 값들이 서로 맞는 성질을 정합성이라고 한다.

Redis는 캐시 말고도 여러 일을 맡는다

Redis는 데이터를 메모리 중심으로 다루는 저장소다.
응답이 빠르고 구조가 단순해서 앞에서 말한 캐시로 오래 쓰여 왔다.

쓰임은 캐시에서 끝나지 않는다.
로그인한 사용자를 기억하는 세션, 점수 순서대로 보여 주는 순위표, 처리할 작업을 차례로 쌓아 두는 큐(queue)⁠에도 Redis를 쓴다.

캐시에 든 값은 원본이 따로 있어서 지워져도 다시 채우면 된다.
그런데 세션이나 큐에 든 값은 Redis에만 있는 경우가 많아서, 지워지면 로그인이 풀리거나 작업이 사라진다.

상품 정보 캐시, 로그인 세션, 보낼 메일을 쌓아 둔 작업 큐가 한 Redis에 함께 들어 있다.

Redis에 든 값

• 저장한 값상태
• 저장한 값: 상품 정보 캐시 원본: 데이터베이스상태: 있음
• 저장한 값: 로그인 세션 원본 없음 · Redis에만 있음상태: 있음
• 저장한 값: 메일 작업 큐 원본 없음 · 보낼 메일 3건상태: 있음

앱이 읽는 곳

Redis 메모리

세 값 모두 바로 읽음

데이터베이스

상품 정보 원본

세션과 메일 작업은 없음

Redis가 비면 세 값이 모두 사라진다. 다음 요청에서 상품 정보 캐시는 데이터베이스를 읽어 다시 채워지지만, Redis에만 있던 로그인 세션과 메일 작업은 돌아오지 않는다.

세 값이 모두 Redis 메모리에 있다. 데이터베이스에 원본이 있는 것은 상품 정보 캐시뿐이다.

Redis가 비어 세 값이 모두 사라졌다. 상품 정보의 원본은 데이터베이스에 그대로 남아 있다.

다음 요청에서 상품 정보는 캐시 미스가 나 데이터베이스를 읽고 다시 채워졌다. 세션과 메일 작업에는 다시 읽어 올 원본이 없다.

디스크에 따로 저장하거나 복제해 두지 않은 Redis가 통째로 비었다고 가정한 예시다. 값의 종류와 메일 3건은 설명을 위한 것이다.

소스를 볼 수 있다고 다 오픈소스는 아니다

Redis는 오랫동안 BSD 3-Clause라는 라이선스로 배포되었다.
라이선스는 소프트웨어를 누가 쓰고, 고치고, 다시 배포할 수 있는지 정한 조건이다.
BSD 계열은 조건이 아주 느슨해서, 누구든 Redis를 가져다 상품을 만들기 쉬웠다.

오픈소스라는 말에는 기준이 있다.
오픈소스 라이선스를 심사해 인정하는 비영리 단체 Open Source Initiative(OSI)⁠가 그 정의를 관리한다.

이 정의는 소스 코드에 접근할 수 있다는 것만으로는 오픈소스가 아니라고 밝힌다.
특정 분야에서 쓰지 못하게 막는 라이선스도 이 정의를 만족하지 못한다.

그래서 소스는 공개하되 일부 쓰임을 제한하는 라이선스는 소스 공개(source-available) 라이선스라고 따로 부른다.

2024년 3월, Redis의 라이선스가 바뀌었다

Redis를 개발하는 회사에는 고민이 있었다.
회사가 보기에 Redis의 상업적 매출 대부분은 큰 클라우드 업체를 거쳐 나갔고, 그 업체들은 회사의 투자와 오픈소스 공동체를 상품으로만 소비하고 있었다.

2024년 3월 20일 회사는 Redis 7.4부터 BSD 대신 RSALv2와 SSPLv1 가운데 하나를 고르게 한다고 발표했다.
두 라이선스 모두 OSI가 인정한 라이선스가 아니라는 점도 회사가 직접 밝혔다.

회사는 내부 용도나 개인 용도로 쓰는 사용자에게는 달라지는 것이 없다고 덧붙였다.
새 버전을 무료로 쓸 수 없게 된 쪽은 Redis와 경쟁하는 서비스를 내놓는 업체였다.

관리형 서비스는 ElastiCache처럼 클라우드 업체가 설치와 운영을 대신 맡아 주는 상품이다.
클라우드 업체가 Redis 7.4 이후 버전을 이런 상품으로 제공하려면 Redis와 따로 계약이 필요해졌다.

여드레 뒤, Valkey가 갈라져 나왔다

반응은 빨랐다.
3월 28일 Linux Foundation이 Valkey를 만든다고 발표했다.
BSD 라이선스로 나온 Redis 7.2.4에서 출발해, 같은 BSD 3-Clause로 개발을 이어 가는 프로젝트다.

이렇게 공개된 코드를 복사해 다른 방향으로 따로 개발을 이어 가는 것을 포크(fork)⁠라고 한다.
발표에는 AWS, Google Cloud, Oracle, Ericsson, Snap이 지원 기업으로 이름을 올렸다.

Linux Foundation은 여러 회사와 개발자가 한 회사에 매이지 않고 오픈소스 프로젝트를 운영하도록 돕는 비영리 재단이다.
Valkey의 방향도 재단 아래 모인 여러 회사와 개발자가 함께 정한다.

Redis도 오픈소스 선택지를 다시 더했다

Redis 쪽은 나중에 이 결정이 공동체와의 관계를 해쳤다고 인정했다.
그사이 2024년 11월에는 Redis를 처음 만든 Salvatore Sanfilippo도 회사로 돌아오기로 했다.

2025년 5월 정식 출시된 Redis 8에는 AGPLv3가 세 번째 라이선스 선택지로 들어갔다.
AGPLv3는 OSI가 인정한 오픈소스 라이선스라서, Redis도 다시 오픈소스 조건으로 쓸 수 있게 되었다.

다만 AGPLv3는 BSD보다 조건이 까다롭다.
라이선스 13조는 프로그램을 고쳐서 네트워크로 사용자에게 제공하면, 그 사용자에게 고친 소스를 받을 길을 열어 주라고 요구한다.

두 프로젝트는 얼마나 같을까

애플리케이션 코드가 Redis에 명령을 보내고 응답을 받을 때는 클라이언트 라이브러리라는 패키지를 쓴다.
Valkey는 Redis와 같은 통신 규약을 써서, 기존 Redis 클라이언트 라이브러리가 코드 변경 없이 접속할 수 있다.

Valkey는 Redis OSS 7.2와 그 이전 오픈소스 버전과 호환된다.
Valkey의 마이그레이션 안내도 그 버전들에서 옮기는 일을 사실상 업그레이드로 본다.

주의할 점도 있다.
Redis 7.4 이후 버전이 만든 데이터 파일은 Valkey와 호환되지 않는다.
이미 7.4나 8을 쓰고 있다면 파일을 그대로 옮기는 식으로는 넘어갈 수 없다.

갈라진 뒤 두 프로젝트는 각자 기능을 더하고 있다.
오래된 공통 기능만 쓴다면 차이를 느끼기 어렵지만, 새 기능을 쓰려면 그 기능이 어느 쪽에 있는지 확인해야 한다.

무엇을 보고 고르나	확인할 것	놓치면
라이선스	내 쓰임새가 그 조건에 걸리는가	재배포나 서비스 제공 단계에서 뒤늦게 막힌다
관리 주체	앞으로의 방향을 누가 정하는가	필요한 기능이 다른 쪽에만 생긴다
옮기는 경로	데이터 파일이 호환되고 되돌릴 길이 있는가	전환 중 문제가 생겨도 앞으로만 갈 수 있다

옮길 때는 무엇이 들어 있는지부터 본다

ElastiCache를 쓰고 있다면 Redis OSS로 만든 클러스터의 엔진을 Valkey로 바꾸는 엔진 간 업그레이드를 할 수 있다.
애플리케이션 설정에 적어 둔 접속 주소(엔드포인트 이름)⁠는 고치지 않아도 된다.

Redis OSS 5.0.6 이상에서는 쓰기가 멈추는 시간이 다른 노드가 역할을 넘겨받는 몇 초뿐이다.

엔진 교체가 간단해도 순서는 따져야 한다.
먼저 그 저장소에 무엇이 들어 있는지 확인한다.
원본이 따로 있는 캐시뿐이라면 잠깐 비어도 다시 채워지지만, 세션이나 아직 처리하지 않은 작업이 들어 있다면 잃으면 안 되는 데이터다.

쓰지 않는 키가 쌓여 있다면 옮기기 전에 정리해 두는 편이 좋다.
새 환경에 메모리를 얼마나 잡을지 가늠할 수 있고, 옮긴 뒤 사용량이 바뀌었을 때 그 이유를 가려내기도 쉽다.

그다음 개발 환경을 먼저 바꿔서 애플리케이션의 명령과 클라이언트 라이브러리가 그대로 도는지 본다.
운영을 옮긴 뒤에는 메모리 사용량과 캐시 적중률이 예상 범위 안인지 확인하고, 벗어나면 되돌릴 기준을 미리 정해 둔다.

라이선스를 얼마나 따져야 하는지는 쓰는 방식에 달렸다.
내 서비스 뒤에서 캐시로만 쓰는 경우와, Redis 자체를 고쳐 배포하거나 남에게 서비스로 제공하는 경우는 걸리는 조건이 다르다.
뒤쪽이라면 라이선스 원문을 직접 읽어 봐야 한다.