4.3. Redis 데이터베이스 분할 및 복제
분할이라고 하는 샤딩(Sharding)은 대규모 데이터베이스를 샤드 (shard)라는 작은 데이터베이스로 분리합니다. 복제를 사용하면 별도의 시스템에서 호스팅되는 동일한 데이터 집합의 사본으로 데이터베이스가 설정됩니다.
샤딩(Sharding)
샤딩을 사용하면 리더 인스턴스를 더 쉽게 추가할 수 있으므로 단일 데이터베이스에 적합하지 않거나 CPU 로드가 100%에 가까운 경우 유용합니다.
3scale용 Redis HA를 사용하면 샤딩이 중요한 두 가지 이유가 있습니다.
- 많은 양의 데이터를 분할하고 스케일링하고 특정 인덱스의 shard 수를 조정하여 병목 현상을 방지합니다.
- 다른 노드에 작업을 분산하므로 여러 머신이 동일한 쿼리에서 작업하는 경우와 같이 성능이 향상됩니다.
클러스터 모드가 비활성화된 Redis 데이터베이스 샤딩의 세 가지 주요 솔루션은 다음과 같습니다.
- Amazon ElastiCache
- Redis sentinels를 통한 표준 Redis
- Redis Enterprise
복제
Redis 데이터베이스 복제를 통해 데이터 세트를 다른 시스템에 복제하여 중복성을 확보할 수 있습니다. 복제를 사용하면 리더가 중단될 때 Redis를 계속 작업할 수 있습니다. 그런 다음 단일 인스턴스인 리더에서 데이터를 가져와 고가용성을 보장합니다.
3scale용 Redis HA를 사용하면 데이터베이스 복제가 기본 샤드의 고가용성 복제본을 보장합니다. 운영 원칙에는 다음이 포함됩니다.
- 기본 shard가 실패하면 복제본 shard가 자동으로 새 기본 shard로 승격됩니다.
- 원래 기본 shard를 복구하면 자동으로 새 기본 shard의 복제본 shard가 됩니다.
Redis 데이터베이스 복제의 세 가지 주요 솔루션은 다음과 같습니다.
- Redis Enterprise
- Amazon ElastiCache
- Redis sentinels를 통한 표준 Redis
twemproxy로 분할
Amazon ElastiCache 및 Standard Redis의 경우 sharding은 키를 기반으로 데이터를 분할해야 합니다. 특정 키에 대해 찾을 shard(예: Tw emproxy )를 알고 있는 프록시 구성 요소가 필요합니다. nutcracker라고도 하는 twemproxy 는 특정 키 또는 해당 키에 할당된 서버 맵을 기반으로 shard를 찾는 Redis 프로토콜의 경량 프록시 솔루션입니다. twemproxy 를 사용하여 Amazon ElastiCache 또는 Standard Redis 인스턴스에 분할 기능을 추가하면 다음과 같은 이점이 있습니다.
- 여러 서버에서 자동으로 데이터 분할 기능
- 여러 해시 모드 지원 및 일관된 해시 및 배포
- 클라이언트가 사용 가능한 첫 번째 프록시 서버에 연결할 수 있는 여러 인스턴스에서 실행할 수 있는 기능
- 백엔드의 캐싱 서버에 대한 연결 수 감소
Redis Enterprise는 자체 프록시를 사용하므로 twemproxy 가 필요하지 않습니다.
추가 리소스
