이 기사의 1부인 "Dynomite 데이터베이스를 Redis Enterprise Active-Active 데이터베이스로 마이그레이션하는 이유는 무엇입니까?"에서 Dynomite와 Redis Enterprise의 아키텍처와 기능을 비교했습니다. Redis Enterprise가 기능이 풍부하고 쉽게 관리할 수 있는 방식으로 Redis Enterprise를 지리적으로 배포하는 데 도움이 되며 동시 쓰기 간의 충돌에 대해 걱정하지 않는 방법을 보여주었습니다.
2부에서는 Dynomite에서 Redis Enterprise로 이동하는 데 사용할 수 있는 마이그레이션 옵션에 대해 설명합니다.
이후 Redis Enterprise의 자체 관리형 제품은 "Redis Enterprise 소프트웨어"라고 하고 관리형 제품은 "Redis Enterprise Cloud" 또는 "클라우드 구독"으로 표기합니다.
Dynomite 데이터베이스 마이그레이션
실습을 통해 두 가지 유형의 마이그레이션을 실행하는 방법을 알아보겠습니다.
- Redis Enterprise의 가져오기/내보내기 기능을 사용한 마이그레이션
- Active-Passive라고도 하는 Redis Enterprise의 ReplicaOf 기능을 사용한 마이그레이션
설명을 위해 dc-a 및 dc-b의 두 데이터 센터에 걸쳐 있는 Dynomite 클러스터가 있다고 가정해 보겠습니다. 각 데이터 센터에는 하나의 랙이 있고 각 랙은 두 개의 노드로 구성되어 데이터 세트가 분산됩니다.
Dynomite 아키텍처에 대한 설명을 기억하면 각 Dynomite 랙에 전체 데이터 세트가 포함되어 있다는 것을 알 수 있습니다.
따라서 가져오기/내보내기 또는 능동-수동 여부에 관계없이 Dynomite 설정 내의 단일 랙으로 마이그레이션 범위를 제한할 수 있습니다.
Rack-1-dc-a를 선택하고 두 노드의 IP가 다음과 같다고 가정해 보겠습니다.
- a1:10.0.0.1
- a2:10.0.0.2
명확성을 위해 다음은 Dynomite 설정을 위한 yaml 구성입니다.
#a1 dyn_o_mite: datacenter: dc-a dyn_listen: 10.0.0.1:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.3:7379:rack1:dc-a:4294967294 - 10.0.0.4:7379:rack1:dc-b:4294967294 - 10.0.0.2:7379:rack1:dc-b:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 2147483647 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM #a2 dyn_o_mite: datacenter: dc-a dyn_listen: 10.0.0.3:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.1:7379:rack1:dc-a:2147483647 - 10.0.0.4:7379:rack1:dc-b:4294967294 - 10.0.0.2:7379:rack1:dc-b:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 4294967294 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM #b1 dyn_o_mite: datacenter: dc-b dyn_listen: 10.0.0.2:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.4:7379:rack1:dc-b:4294967294 - 10.0.0.1:7379:rack1:dc-a:4294967294 - 10.0.0.3:7379:rack1:dc-a:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 2147483647 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM #b2 dyn_o_mite: datacenter: dc-b dyn_listen: 10.0.0.4:7379 dyn_port: 7379 dyn_seed_provider: simple_provider dyn_seeds: - 10.0.0.2:7379:rack1:dc-b:2147483647 - 10.0.0.1:7379:rack1:dc-a:4294967294 - 10.0.0.3:7379:rack1:dc-a:2147483647 listen: 0.0.0.0:8379 rack: rack1 servers: - 127.0.0.1:6379:1 timeout: 150000 tokens: 4294967294 secure_server_option: datacenter pem_key_file: /root/dynomite/conf/dynomite.pem data_store: 0 stats_listen: 127.0.0.1:22222 read_consistency : DC_QUORUM write_consistency : DC_QUORUM
이 구성 및 이 튜토리얼을 테스트하는 데 사용된 설정에 대한 몇 가지 관찰:
- Ubuntu 18.04를 실행하는 4개의 GCP VM
- VM은 여러 지역에 걸쳐 있는 동일한 VPC에 있습니다.
- Dynomite가 데이터 복제를 위해 포트 7379 및 7380을 열었습니다(yaml 구성의 "dyn_port").
- Redis OSS는 포트 6379의 각 노드에서 실행 중입니다. yaml 구성의 "서버"를 참조하십시오.
- Dynomite는 포트 8379(예:redis-cli -h 10.0.0.1 -p 8379)에서 클라이언트의 요청을 수신합니다. yaml 구성의 "수신"을 참조하십시오.
이제 설정을 이해하고 마이그레이션에 사용할 랙을 결정했으므로 Redis Enterprise 데이터베이스를 생성해 보겠습니다.
Redis Enterprise Active-Active 데이터베이스 생성
이 문서의 목적은 클러스터를 설정하거나 데이터베이스를 생성하는 방법을 설명하는 것이 아니므로 Active-Active 데이터베이스를 설정하고 실행하려면 아래 문서를 참조하십시오.
- Redis 엔터프라이즈 소프트웨어 클러스터
- 클라우드 구독
- 소프트웨어 데이터베이스 생성
- 소프트웨어 Active-Active 데이터베이스 생성
- 클라우드 데이터베이스 생성
두 가지 마이그레이션 시나리오를 테스트하기 위해 두 개의 Redis Enterprise Software 클러스터에 걸쳐 있는 Active-Active 데이터베이스를 만들었습니다. 하나는 유럽에, 다른 하나는 미국에 있습니다. 각 클러스터는 Ubuntu 18.04를 실행하는 3개의 VM으로 구성됩니다. Active-Active 없이 데이터베이스를 생성하는 경우 이 문서에서 달리 지정하지 않는 한 마이그레이션 단계는 동일합니다.
첫 번째 유형의 마이그레이션을 진행해 보겠습니다.
가져오기/내보내기 기능을 사용한 마이그레이션
Redis OSS는 지정된 간격으로 또는 SAVE 또는 BGSAVE 명령에 의해 트리거될 때 데이터세트의 특정 시점 스냅샷을 수행하는 RDB 또는 Redis 데이터베이스 백업 파일이라는 지속성 옵션을 제공합니다.
이러한 스냅샷은 .rdb 파일(이하 RDB 파일이라고 함)에 저장됩니다. Dynomite 서버에서 내보내고 Redis Enterprise 데이터베이스로 가져올 것입니다. 이 솔루션을 사용하면 델타 마이그레이션이 불가능하며 데이터 크기에 따라 가져오기에 시간이 걸릴 수 있습니다.
중요:Redis Enterprise의 지리적이 아닌 분산 데이터베이스와 Active-Active 데이터베이스에는 큰 차이가 있습니다.
- 지리적으로 분산되지 않은 데이터베이스:RDB 파일을 가져올 때 기존 데이터베이스 콘텐츠가 모두 지워집니다.
- Active-Active 데이터베이스:RDB 파일을 가져와 기존 데이터세트에 병합할 수 있습니다. 즉, 가져오기 전과 가져오기 중에 활성-활성 데이터베이스에 쓰기 트래픽을 보낼 수 있습니다. 주의 – Dynomite에 이미 존재하는 Active-Active 데이터베이스에 키를 쓰는 경우 후속 가져오기가 새 값을 이전 값으로 덮어쓸 수 있습니다. ! 신중한 계획이 필요합니다.
RDB 파일을 사용하여 Dynomite에서 Redis Enterprise로 데이터를 마이그레이션하는 방법은 다음과 같습니다.
- Dynomite 데이터베이스에서 트래픽을 중지하고 마이그레이션을 신중하게 계획하고 Active-Active 데이터베이스를 사용하는 경우 Redis Enterprise 데이터베이스로 전환합니다.
- 각 노드의 데이터(여기서는 a1 및 a2)를 RDB 파일로 내보냅니다.
- Redis Enterprise 클러스터에 액세스할 수 있는 위치(예:Google Cloud Storage 버킷, AWS S3 버킷, FTP 서버 등)에 RDB 파일 업로드
- RDB 파일을 Redis Enterprise 데이터베이스로 가져옵니다.
- Redis Enterprise 데이터베이스로의 전환
위의 단계를 더 자세히 살펴보겠습니다.
선택 사항:각 노드에서 Redis OSS 구성 파일 편집
Dynomite 노드에서 실행되는 Redis OSS 인스턴스의 구성 파일은 "apt-get"으로 설치한 경우 기본적으로 /etc/redis에 있고 Redis OSS를 직접 빌드한 경우 Redis 폴더에 있습니다. 이 파일의 이름은 "redis.conf"입니다.
즐겨 사용하는 텍스트 편집기로 이 파일을 열고 "dbfilename" 지시어를 검색하십시오.
와 같이 각 노드의 파일 이름을 변경합니다.- node1의 "dump1.rdb",
- node2의 "dump2.rdb".
이렇게 하면 RDB 파일을 외부 저장소로 내보낼 때 이름이 같지 않습니다. 원하는 경우 이 단계를 건너뛰고 스냅샷을 찍은 후 이름을 변경할 수 있습니다.
선택적으로 다음을 수행할 수도 있습니다.
- "dir" 지시어로 RDB 파일이 저장될 디렉토리를 변경합니다.
- 스냅샷 간격을 변경하거나 자동 스냅샷을 비활성화합니다. 이 자습서에서는 SAVE Redis 명령을 사용하여 스냅샷 생성을 트리거하여 트래픽을 중지한 후 전체 데이터 세트를 덤프할 수 있습니다.
Redis OSS 구성 파일을 편집한 후 Redis OSS 서버를 다시 시작해야 변경 사항이 적용됩니다.
데이터 덤프
이제 포트 8379를 통해 Dynomite 데이터베이스로 들어오는 트래픽을 중지합니다. 다시 말하지만, Active-Active 데이터베이스로 가져오고 가져오는 동안 실수로 덮어쓸 위험이 없도록 마이그레이션을 신중하게 계획한 경우 트래픽을 차단할 수 있습니다. Active-Active 데이터베이스.
redis-cli를 실행합니다. Dynomite의 수신 포트인 포트 8379를 사용하지 마십시오. 대신 포트 6379를 사용하십시오. 이는 SAVE 명령을 지원하지 않는 Dynomite 클러스터가 아니라 노드에서 실행 중인 Redis OSS 인스턴스에 연결해야 하기 때문입니다. 명령줄 인수 없이 redis-cli를 실행할 수 있습니다.
각 노드에서 DBSIZE 명령을 실행하십시오. Redis OSS의 각 인스턴스에 저장된 키 수를 가져옵니다. 총계는 Dynomite 데이터베이스의 키 수여야 합니다.
#a1 127.0.0.1:6379> dbsize (integer) 1323 #a2 127.0.0.1:6379> dbsize (integer) 1371
SAVE 명령을 실행하고 RDB 파일이 /var/lib/redis 또는 지정한 디렉토리에 생성되었는지 확인하십시오.
두 개의 덤프 파일을 외부 저장소로 내보내기
이제 두 개의 RDB 파일을 외부 저장소로 내보낼 준비가 되었습니다.
이 가이드에서는 파일을 Google Cloud의 Cloud Storage로 내보내지만 FTP 서버, 다른 클라우드 서비스 제공업체 스토리지 솔루션 또는 Redis Enterprise 클러스터에서 액세스할 수 있는 외부 디스크와 같은 다른 외부 스토리지 옵션을 사용할 수도 있습니다. 아래에서 해당 옵션에 대한 자세한 정보를 찾을 수 있습니다.
- Redis 엔터프라이즈 소프트웨어
- Redis 엔터프라이즈 클라우드
Google Cloud에서 다음을 만들었습니다.
- JSON 키를 생성한 서비스 계정입니다.
- 내 서비스 계정에 Storage Legacy Object Reader 권한을 할당한 클라우드 스토리지 버킷입니다.
이제 각 노드에 대해 다음 명령을 실행합니다.
gsutil cp path_to_dump_file gs://your_bucket
이제 Google Cloud 버킷에서 두 개의 RDB 파일을 볼 수 있습니다.
이제 Active-Active 데이터베이스로 가져올 준비가 되었습니다.
Redis Enterprise 데이터베이스로 덤프 파일 가져오기
Redis Enterprise UI에 로그인하고 Active-Active 데이터베이스를 선택합니다. 이 튜토리얼에서처럼 여러 클러스터에 걸쳐 있는 Redis Enterprise Active-Active 데이터베이스를 생성했다면 원하는 클러스터를 통해 UI에 연결할 수 있습니다. 이 자습서에서는 유럽(EU) 클러스터를 사용합니다.
Cloud Active-Active 데이터베이스를 사용하는 경우 Cloud UI에 연결하고 데이터베이스를 선택하기만 하면 됩니다.
데이터베이스의 구성 페이지로 이동하여 가져오기 버튼을 클릭해 보겠습니다. 적절한 스토리지 유형을 선택합니다. 이 경우 Google Cloud Storage가 됩니다.
이제 다음과 같은 두 RDB 파일의 Cloud Storage 경로를 추가할 수 있습니다.
- /helene-test/dump1.rdb
- /helene-test/dump2.rdb
다음 정보도 추가해야 합니다.
- 클라이언트 ID
- 고객 이메일
- 개인 키 ID
- 개인 키
이 정보는 Google 클라우드 서비스 계정용 키를 만들 때 다운로드한 JSON 키 파일에서 찾을 수 있습니다.
개인 키는 JSON 파일에서 이상하게 형식이 지정되어 있습니다. 따옴표와 줄 바꿈이 있습니다. Redis Enterprise UI가 허용하는 방식으로 빠르게 형식을 지정하려면 Python 인터프리터를 시작하고 인쇄하면 됩니다.
print(WHOLE_COPIED_KEY)
이제 다음 가져오기 구성이 있습니다.
가져오기를 클릭하고 데이터베이스 크기에 따라 가져오기가 완료될 때까지 기다립니다.
데이터베이스 및 컷오버 확인
redis-cli를 사용하여 Redis Enterprise 데이터베이스의 끝점에 연결합니다. 일부 키를 읽고 DBSIZE 명령을 실행하여 올바른 총 키 수가 있는지 확인하십시오.
redis-12000.internal.helene-eu-cluster.demo.redislabs.com:12000> dbsize (integer) 2694
Active-Active Geo-Dupplication도 확인하는 것을 잊지 마세요! 다른 클러스터의 데이터베이스 엔드포인트(여기서는 미국 엔드포인트)에 연결하고 받는 키의 수를 확인하기만 하면 됩니다.
이제 마이그레이션이 끝났습니다. 데이터베이스에 대한 트래픽을 아직 차단하지 않은 경우 차단할 수 있습니다.
ReplicaOf 기능을 사용한 마이그레이션
이제 지속적인 마이그레이션을 실행해 보겠습니다.
Redis Enterprise 기능 'ReplicaOf'(Redis Cloud UI에서는 Active-Passive라고도 함)를 사용하면 두 Redis 데이터베이스 간에 데이터를 지속적으로 복제할 수 있습니다. 주요 이점은 초기 동기화가 완료된 후 델타를 복제한다는 것입니다. 즉, 애플리케이션 측 다운타임이 거의 관찰되지 않습니다.
단계는 다음과 같습니다.
- Dynomite 데이터베이스와 Active-Active 데이터베이스 간의 ReplicaOf 링크 설정
- 초기 동기화가 완료될 때까지 기다리기
- Dynomite 데이터베이스의 트래픽 중지
- 델타가 복제될 때까지 기다립니다.
- 데이터베이스 간의 ReplicaOf 링크 삭제
- Active-Active 데이터베이스로 전환
ReplicaOf는 능동-수동 방식으로 사용하기 위한 것입니다. 즉, 대상이 수동적이라고 가정하고 대상이 완전히 다시 동기화되도록 허용해야 합니다(대상 데이터베이스 플러시 + 소스 데이터베이스에서 동기화).
마이그레이션을 시작하기 전에 몇 가지 보안 측면에 대해 논의하겠습니다.
Dynomite 설정에서 Redis OSS에 대한 보안 구성
먼저 Dynomite 랙이 있는 네트워크에 대해 6379 포트가 있는 사용자 지정 TCP에 대한 인바운드 규칙을 추가해야 합니다.
둘째, 두 Dynomite 노드의 Redis OSS 구성 파일을 업데이트해야 합니다. 기본적으로 Redis는 IPv4 및 IPv6(사용 가능한 경우) 루프백 인터페이스 주소에서만 수신 대기합니다. 이는 Redis OSS가 실행 중인 동일한 호스트의 클라이언트 연결만 수락할 수 있음을 의미합니다. Redis OSS가 Redis Enterprise 클러스터 호스트의 연결을 수신할 수 있도록 Redis OSS의 "바인드" 지시문을 업데이트해야 합니다.
두 가지 방법이 있습니다.
- Redis OSS가 피어링된 VPC의 시스템에서 오는 연결만 수신하도록 설정 - 권장되고 더 안전합니다.
- 모든 호스트에서 Redis OSS에 액세스하도록 허용 - 특히 Dynomite가 데이터베이스 비밀번호를 지원하지 않기 때문에 안전하지 않음
이 두 가지 옵션에 대해 자세히 살펴보겠습니다.
옵션 1 – VPC 피어링 사용
첫 번째 옵션은 Dynomite 랙이 있는 VPC를 Redis Enterprise 클러스터가 있는 VPC와 피어링하는 것입니다. 우리처럼 Active-Active 데이터베이스를 생성했다면 모든 클러스터에 존재할 수 있습니다. 이전과 마찬가지로 우리는 시연을 위해 유럽(EU) 클러스터를 사용할 것입니다.
네트워크를 피어링한 후에는 redis.conf 파일에서 "bind" 지시문을 편집하기만 하면 됩니다. 기본 루프백 인터페이스 주소 뒤에 Dynomite 시스템의 개인 IP를 추가합니다.
랙의 모든 노드에 대해 이 작업을 수행하면 됩니다. Redis OSS 인스턴스를 다시 시작하는 것을 잊지 마십시오.
옵션 2 – VPC 피어링 없음
네트워크를 피어링할 수 없거나 피어링하지 않으려면 각 노드에서 다음과 같은 방식으로 Redis OSS 구성 파일을 업데이트해야 합니다.
- Redis OSS 인스턴스를 인터넷의 모든 사람에게 공개하는 "바인드" 지시문을 주석 처리합니다.
- "protected-mode"를 "no"로 설정하면 인증이 구성되지 않았더라도 다른 호스트의 클라이언트가 Redis에 연결할 수 있고 특정 인터페이스 집합이 "bind" 지시문을 사용하여 명시적으로 나열되지 않아도 됩니다.
중요: Dynomite는 Redis의 OSS AUTH 명령을 지원하지 않기 때문에 이 마지막 단계가 필요합니다. 따라서 방화벽을 사용하여 사용 중인 포트에 연결하는 사람을 제어하지 않으면 누구나 Redis OSS 인스턴스에 연결하여 해당 데이터에 액세스/변경/삭제할 수 있습니다. Redis Enterprise 클러스터의 호스트에만 포트 6379를 엽니다.
정말로 암호를 사용하고 싶다면 그렇게 할 수 있습니다. 그러나 다음을 수행해야 하므로 연속 마이그레이션을 실행할 수 없습니다.
- Dynomite 데이터베이스에 대한 트래픽 중지
- "requirepass" 지시문을 편집하여 데이터베이스의 비밀번호를 설정하십시오. 이 시점부터 데이터베이스에 액세스하려면 AUTH 명령이 필요하므로 포트 8379를 사용하여 Dynomite 데이터베이스에 쓰기 트래픽을 보낼 수 없습니다.
- 아래에 설명된 대로 ReplicaOf를 사용하여 마이그레이션 수행
- Redis Enterprise 데이터베이스에 대한 트래픽 차단
보안을 한 번 더 고려하면 마이그레이션을 시작할 준비가 되었습니다!
선택 사항 – TLS 활성화
데이터에 대한 무단 액세스를 방지하기 위해 Redis Enterprise는 TLS 프로토콜을 지원합니다.
Redis Enterprise Software를 사용하는 경우 ReplicaOf 통신을 위해 특별히 구성할 수 있습니다. Redis Enterprise Cloud를 사용하는 경우 일반적으로 TLS를 활성화할 수 있습니다.
데이터베이스 간의 ReplicaOf 링크 설정
Redis Enterprise UI에서 Active-Active 데이터베이스 구성 페이지로 이동하여 편집을 클릭하겠습니다.
Active-Passive/ReplicaOf를 활성화하는 옵션이 있습니다. 그렇게 하면 다음 형식으로 소스를 추가할 수 있습니다.
redis://:@IP:port
참고:
- ReplicaOf는 최대 32개의 소스를 허용합니다. 즉, Dynomite 랙의 32개 이상의 노드에 데이터 세트를 배포한 경우 이 옵션을 사용할 수 없습니다.
- VPC 피어링을 사용한 경우 머신의 사설 IP를 사용해야 합니다.
- VPC 피어링을 사용하지 않은 경우:
- 컴퓨터의 공개 IP를 사용해야 합니다.
- 데이터베이스에 비밀번호를 설정하고 일회성 마이그레이션을 실행하기로 결정했다면 redis://:password@IP:port와 같이 비밀번호를 제공해야 합니다.
VPC 피어링을 사용하는 우리의 경우 소스는 다음과 같습니다.
이전 시작
이제 다음 단계를 수행해 보겠습니다.
- Redis Enterprise UI에서 업데이트를 클릭합니다.
- 초기 동기화가 끝날 때까지 기다리세요.
- Dynomite 데이터베이스에 대한 트래픽을 중지합니다.
- 델타가 동기화될 때까지 기다립니다.
- ReplicaOf를 비활성화하려면 Active-Active 데이터베이스를 다시 업데이트합니다.
- Active-Active 데이터베이스에서 트래픽을 시작합니다.
데이터 확인
이전과 마찬가지로 redis-cli를 사용하여 데이터베이스에 연결하고 데이터가 마이그레이션되었는지 확인합니다. 다른 클러스터/기타 로컬 엔드포인트에 연결하여 Active-Active Geo-Dupplication도 확인하세요.
결론
Redis는 수년간 개발자들에게 가장 사랑받는 데이터베이스로 선정되었습니다. Dynomite를 사용하고 있다면 Redis도 사랑하기 때문일 것입니다. Redis OSS와 Redis Enterprise의 본고장인 Redis에서는 조직이 갈등 해결을 위한 가장 높은 학문적 표준을 유지하면서 보다 관리하기 쉬운 방식으로 Redis를 지리적으로 배포하도록 도울 수 있습니다.