2009년에 만들어진 이후 Redis OSS는 매우 활기찬 오픈 소스 커뮤니티를 보유하고 있습니다. 이를 중심으로 많은 도구와 유틸리티가 개발되었으며 비분산 데이터 저장소를 위한 P2P 지리 분포 계층인 Dynomite가 그 중 하나입니다.
Dynomite는 Netflix의 엔지니어 팀에 의해 개발되었으며 오픈 소스로 출시되었습니다. 특정 요구 사항에 대한 좋은 솔루션을 제공했지만 지난 몇 년 동안 효과적으로 유지되지 않았습니다. 또한 Redis OSS의 일부 기능, 명령 및 데이터 유형(예:Pub/Sub 또는 Streams)은 사용할 수 없거나 Dynomite의 Redis OSS 인스턴스 배포 모델에 의해 제한됩니다.
이러한 이유로 우리는 조직의 Dynomite 데이터베이스를 Redis Enterprise 클러스터로 마이그레이션하는 데 도움을 주고 있습니다.
Dynomite와 Redis Enterprise 아키텍처 비교
Dynomite와 Redis Enterprise의 아키텍처에 대한 간략한 설명으로 비교를 시작하겠습니다.
다이노마이트
일반적인 Dynomite 클러스터는 다음과 같이 설명할 수 있습니다.
- 여러 데이터 센터에 걸쳐 있음
- 단일 데이터 센터는 랙 그룹입니다.
- 랙은 노드 그룹입니다. 각 랙은 해당 랙의 여러 노드에 분할된 전체 데이터 세트를 보유합니다.
Dynomite는 P2P 배포 계층이므로 클라이언트는 Dynomite 클러스터의 모든 노드에 쓰기 트래픽을 보낼 수 있습니다. 노드가 데이터를 담당하는 노드인 경우 데이터는 로컬 Redis OSS 서버 프로세스에 작성된 다음 모든 데이터 센터의 클러스터에 있는 다른 랙에 비동기식으로 복제됩니다. 노드가 데이터를 소유하지 않으면 코디네이터 역할을 하여 동일한 랙에 있는 데이터를 소유한 노드에 쓰기를 보냅니다. 또한 다른 랙 및 DC의 해당 노드에 쓰기를 복제합니다.
레디스 엔터프라이즈
Redis Enterprise 클러스터는 또한 다른 Redis 인스턴스 또는 샤드 간에 데이터를 배포하지만 두 가지 주요 차이점이 있습니다.
- 한 노드에 둘 이상의 샤드가 있을 수 있지만 고가용성을 위해 기본 및 복제본은 동일한 노드에 있을 수 없습니다.
- 각 기본 샤드에 대해 하나의 복제본만 있습니다. 클라이언트는 기본 샤드에서 데이터 작업을 수행합니다. 기본 샤드에 장애가 발생한 경우 고가용성을 위해 각각의 복제본이 존재합니다.
Redis Enterprise 클러스터의 또 다른 중요한 부분은 "관리 경로"입니다. 여기에는 클러스터 관리자, 프록시 및 REST API/UI가 포함됩니다. 클러스터 관리자는 클러스터를 조정하고, 데이터베이스 샤드를 고가용성 노드에 배치하고, 오류를 감지하는 역할을 합니다. 프록시는 클러스터 내의 각 데이터베이스에 대해 변경되지 않는 단일 엔드포인트를 제공하여 애플리케이션에서 Redis Enterprise의 클러스터 토폴로지를 숨깁니다. 또한 명령을 샤드에 다중화하고 파이프라이닝하여 클라이언트 연결을 확장하는 데 도움이 됩니다.
다음은 일반적인 Redis Enterprise Cluster의 예시입니다.
Redis Enterprise의 Active-Active 기능을 사용하면 여러 클러스터에 걸쳐 있는 글로벌 데이터베이스를 생성할 수 있습니다. 이러한 클러스터는 일반적으로 전 세계의 서로 다른 데이터 센터에 있습니다. Active-Active 데이터베이스에 쓰는 애플리케이션은 로컬 인스턴스 끝점에 연결됩니다. 로컬 인스턴스에 대한 애플리케이션의 모든 쓰기는 강력한 최종 일관성으로 다른 모든 인스턴스에 복제됩니다.
Active-Active 복제는 지리적으로 분산된 솔루션으로서 많은 이점을 제공합니다. 그 중 하나는 아래에서 논의할 단순하고 복잡한 Redis Enterprise 데이터 유형에 대한 원활한 충돌 해결입니다.
이제 Dynomite와 Redis Enterprise의 토폴로지에 대한 아이디어를 얻었으므로 이들이 조직 내 개발자와 DevOps에 무엇을 수반하는지 살펴보겠습니다.
Dynomite 또는 Redis Enterprise:개발자에게 어떤 차이가 있습니까?
Dynomite가 적극적으로 유지 관리되지 않는 것 외에도 조직에서 개발자의 관점에서 Redis Enterprise로 마이그레이션하려는 세 가지 주요 이유가 있습니다.
- Dynomite를 사용할 때 Redis의 기능은 제한적이고 더 복잡합니다.
- Dynomite는 지리적으로 분산된 쓰기 충돌을 처리하는 효과적인 방법이 없습니다.
- Redis에서 얻을 수 있는 지원
처음 두 가지를 더 자세히 살펴보겠습니다.
제한적이고 복잡한 Redis OSS
이미 알고 계시겠지만 Redis OSS는 문자열 키를 문자열 값에 연결할 수 있다는 점에서 일반 키-값 저장소가 아닙니다. Redis OSS는 목록, 집합, 해시 또는 스트림과 같은 다양한 종류의 값을 지원하는 데이터 구조 서버입니다. 우리는 이것을 Redis OSS의 "핵심 데이터 유형"이라고 부릅니다.
Redis OSS는 "모듈"이라는 동적 라이브러리를 통해 확장할 수도 있습니다. 모듈을 사용하면 코어 내부에서 수행할 수 있는 것과 유사한 기능으로 새로운 Redis 명령을 빠르게 구현할 수 있습니다. 가장 인기 있는 모듈로는 쿼리, 보조 인덱싱 및 전체 텍스트 검색을 제공하는 RediSearch와 Redis OSS를 강력한 문서 저장소로 바꾸는 RedisJSON이 있습니다.
도입부에서 논의한 바와 같이 일부 Redis OSS 명령 및 데이터 유형은 Dynomite에서 사용할 수 없거나 제한됩니다. 다음은 포괄적이지 않은 비교입니다.
여기에서 Dynomite에서 지원되는 명령과 지원되지 않는 명령의 전체 목록을 찾을 수 있습니다.
반면 Redis OSS와 함께 유지 관리되는 Redis Enterprise는 모듈을 사용한 다중 모델 작업과 핵심 Redis OSS 데이터 구조가 완전히 프로그래밍 가능하고 분산된 방식으로 실행되도록 합니다.
분쟁 해결의 부재
Dynomite는 AP 시스템이며 일관성을 위한 세 가지 옵션을 제공합니다. 어떤 옵션을 선택하든 Dynomite는 Last Write Wins 전략을 적용하여 비동기식 쓰기 충돌을 해결한다는 사실을 아는 것이 중요합니다. 이로 인해 특히 지리적으로 분산된 쓰기와 관련하여 관련 없는 타임스탬프로 인해 업데이트가 손실될 수 있습니다.
반면에 Redis Enterprise의 Active-Active 아키텍처는 CRDT(Conflict-Free-Replicated-Data-Types)라는 Redis OSS 명령 및 데이터 유형의 대체 구현을 기반으로 합니다. CRDT는 이벤트 순서 지정을 위해 벡터 클록을 사용합니다. 두 복제본이 동일한 업데이트 집합을 수신할 때 상태 수렴을 보장하기 위해 수학적으로 건전한 규칙을 채택하여 결정론적으로 동일한 상태에 도달하도록 합니다. 또한 인과적 일관성도 활성화할 수 있습니다.
따라서 Redis Enterprise:
- 동시 쓰기의 결과는 예측 가능하며 일련의 규칙을 기반으로 합니다.
- 애플리케이션이 동시 쓰기 및 쓰기 충돌 해결에 신경 쓸 필요 없음
- 데이터 세트는 결국 하나의 일관된 상태로 수렴됩니다.
준비가 되어 있다면 이 링크를 클릭하여 구현된 규칙과 충돌 해결의 예를 찾을 수 있습니다.
Dynomite 또는 Redis Enterprise:DevOps에 어떤 차이가 있습니까?
이제 다음 주제를 논의하여 DevOps 관점에서 Dynomite와 Redis Enterprise를 비교해 보겠습니다.
- 고가용성
- 확장성
- 배포 가능성
고가용성
Dynomite 랙 내에서 노드에 장애가 발생하면 랙에 대한 쓰기 및 읽기가 불가능해집니다. 이는 로컬로 작성하는 애플리케이션이 다른 랙에 대한 장애 조치를 자체적으로 처리해야 함을 의미합니다. 애플리케이션이 Java로 개발된 경우 Netflix의 Dyno 클라이언트는 로컬 Dynomite 노드에 장애가 발생하면 원격 랙에 대한 장애 조치를 처리할 수 있습니다.
또한 노드가 다시 복구되면 장애가 발생한 동안 원격 랙에 기록된 모든 데이터가 장애가 발생한 노드에서 누락됩니다. AWS Autoscaling 그룹 내에서 배포하는 경우 AWS Auto-scaling 그룹 내에서 노드 교체 및 노드 워밍업을 수행하는 Netflix의 Dynomite Manager를 사용할 수 있습니다.
Redis Enterprise의 고가용성은 어떻습니까?
노드에 장애가 발생하면 해당 노드에 있는 모든 기본 샤드에 대해 한 자릿수 초 장애 조치가 발생하고 해당 복제본은 기본 샤드로 승격됩니다. 이 자동 장애 조치 메커니즘은 최소한의 중단으로 데이터가 제공되도록 보장합니다.
이를 바탕으로 :
- Redis Enterprise Proxy는 장애 조치(failover) 시 변경되지 않는 데이터베이스의 단일 엔드포인트를 보장하므로 애플리케이션을 재구성할 필요가 없습니다.
- 복제본이 기본 노드로 승격될 때 사용 가능한 다른 노드에서 새로운 동기화된 복제본 샤드가 자동으로 생성되도록 하는 "replica_ha" 옵션이 있습니다.
이러한 메커니즘을 통해 Redis Enterprise는 Active-Active 배포에 대해 99.99% 가동 시간과 99.999% 가동 시간을 보장할 수 있습니다.
확장성
Dynomite를 사용하면 지연 시간 측면에서 우수한 성능을 유지하면서 Redis OSS를 확장할 수 있습니다. 벤치마크를 확인할 수는 있지만 Dynomite를 사용 중이라면 이미 알고 있을 것입니다.
확장성과 관련하여 Dynomite와 Redis Enterprise의 주요 차이점은 다음과 같습니다.
- 관리 효율성
- 즉시 연결 관리
- 리소스 최적화
관리 효율성
AWS Autoscaling 그룹 내에서 Dynomite Manager를 사용하지 않는 경우 실행 중인 Dynomite 랙에 호스트를 추가하려면 일반적으로 다음이 필요합니다.
- Java Dyno 클라이언트를 사용하여 "이중 쓰기" 기술 활용. 귀하의 애플리케이션은 이전/작은 클러스터와 새로운/확장된 클러스터에 기록합니다. 며칠 후 트래픽을 새 클러스터로만 라우팅하고 활성 클러스터로 만듭니다.
- 기존/소규모 클러스터에서 새로운/확장된 클러스터로 데이터베이스 마이그레이션
반면 Redis Enterprise를 사용하면 다음을 수행할 수 있습니다.
- 클러스터에 노드를 추가하지 않고 데이터베이스에 샤드를 추가하여 확장:이 시나리오는 클러스터에 충분히 활용되지 않는 용량이 있을 때 유용합니다. 기억하십시오:하나의 노드가 하나의 Redis 인스턴스와 같지 않습니다. Redis Enterprise UI를 통해 클릭 몇 번으로 또는 Redis Enterprise의 REST API를 활용하여 데이터베이스를 다시 샤딩할 수 있습니다. 다운타임이나 서비스 중단 없이 수행됩니다. 또한 데이터베이스의 엔드포인트가 변경되지 않으므로 애플리케이션에 투명합니다.
- 클러스터에 노드를 추가하여 확장합니다. 이 시나리오는 데이터베이스에 샤드를 추가하기 위해 더 많은 물리적 리소스가 필요한 경우에 유용합니다. 완전 관리형 DBaaS 제품인 Redis Enterprise Cloud를 사용하면 조직에서 이 단계에 대해 걱정할 필요가 없습니다. Redis는 인프라와 리소스를 프로비저닝하고 관리합니다. 이 문서의 배포 섹션에서 자세한 내용을 참조하세요.
다음은 Redis가 몇 년 전에 수행한 벤치마크로, Redis Enterprise는 40개의 AWS 인스턴스에서 밀리초 미만의 지연 시간으로 초당 2억 개 이상의 작업을 제공했습니다.
연결 관리
Redis를 사용한 연결 관리에 대해 이야기할 때 가장 먼저 떠오르는 것은 Jedis 또는 Lettuce와 같은 Redis 클라이언트가 연결 풀링 및 파이프라이닝을 처리하는 방법입니다. Netflix도 이에 예외가 아니었고 Dyno 클라이언트를 위해 이러한 기능을 구현했습니다.
Redis Enterprise는 즉시 사용 가능한 이러한 기능을 제공합니다. 프록시 자체는 클러스터의 샤드에 대한 영구 연결을 설정하고 이러한 연결은 클라이언트에서 공유됩니다. 또한 샤드에 대한 여러 영구 연결에 대한 요청을 예약하고, Redis 측에서 멀티플렉싱 및 파이프라이닝을 수행하여 성능 최적화를 적용합니다.
또한 프록시는 다중 스레드이며 클라이언트 연결의 버스트를 처리하도록 자동으로 확장됩니다.
리소스 최적화
먼저 Redis Enterprise 클러스터 내에서 하나의 머신이 하나의 Redis 인스턴스와 같지 않으며 각 기본 샤드는 최대 하나의 복제본만 가질 수 있다는 점을 기억하세요.
둘째, Redis Enterprise는 다중 테넌트입니다. 이는 단일 Redis Enterprise 클러스터가 완전히 격리된 수백 개의 데이터베이스를 제공할 수 있음을 의미합니다. 이것은 Dynomite를 사용하여 수행하는 것이 결코 쉬운 일이 아닙니다. Redis Enterprise의 다중 테넌시는 다중 모델 기능과 잘 맞습니다. 마이크로서비스의 맥락에서 각각 고유한 복제, 확장, 지속성 및 모듈 구성이 있는 단일 노드 집합에서 다양한 용도에 맞는 데이터베이스를 실행하는 것을 상상할 수 있습니다.
마지막으로 Redis Enterprise에는 RoF(Redis On Flash)라는 기능이 있습니다. RoF를 사용하면 데이터베이스에서 RAM과 전용 플래시 메모리(SSD/NVMe)를 모두 사용하여 RAM과 유사한 지연 시간과 성능으로 훨씬 더 큰 데이터세트를 처리할 수 있지만 전체 RAM 데이터베이스에 비해 비용이 70% 이상 저렴합니다.
배포 옵션
Dynomite는 Ubuntu, RHEL 및 CentOS를 실행하는 컨테이너 또는 머신에 배포할 수 있습니다. 클러스터를 관리하기 위해 인프라와 리소스를 제공해야 한다는 점에서 배포는 항상 자체 관리됩니다. 또한 앞서 설명한 것처럼 Dynomite Manager의 기능을 활용하려면 AWS Autoscaling 그룹 내에 Dynomite를 배포해야 합니다.
반면에 Redis Enterprise에는 두 그룹으로 나눌 수 있는 많은 배포 옵션이 있습니다.
- Redis Enterprise 소프트웨어를 직접 다운로드, 설치 및 배포하는 자체 관리형 솔루션입니다. Linux 설치 프로그램(다중 배포), Amazon Machine Image(AMI), Docker Containers, Kubernetes, RedHat OpenShift, Google Kubernetes Engine(GKE), Azure Kubernetes Service(AKS) 또는 Amazon Elastic Kubernetes Service(EKS)를 포함하는 많은 옵션이 있습니다. ).
- 관리형 솔루션:Redis Enterprise Cloud는 세 가지 주요 공용 클라우드 플랫폼(Google Cloud, AWS 및 Azure) 모두에서 완전 관리형 클라우드 서비스(DBaaS)로 제공됩니다. Redis는 필요한 리소스가 포함된 전용 환경을 호스팅하며, 여기에서 애플리케이션이 사용할 프라이빗 및 퍼블릭 엔드포인트가 있는 데이터베이스를 생성할 수 있습니다.