ElastiCache for Redis 백업 및 복원 - Amazon ElastiCache for Redis

ElastiCache for Redis 백업 및 복원

Redis를 실행하는 Amazon ElastiCache 클러스터는 데이터를 백업할 수 있습니다. 클러스터를 복원하거나 새 클러스터를 시드하기 위해 백업을 사용할 수 있습니다. 백업은 클러스터의 모든 데이터와 클러스터의 메타데이터로 구성됩니다. 모든 백업은 Amazon Simple Storage Service(Amazon S3)에 쓰여지므로 내구성 있는 스토리지가 확보됩니다. 언제든지 새로운 Redis 클러스터를 생성하고 백업의 데이터로 클러스터를 채워 데이터를 복원할 수 있습니다. ElastiCache를 통해 AWS Management Console, AWS Command Line Interface(AWS CLI) 및 ElastiCache API를 사용하여 백업을 관리할 수 있습니다.

Redis 버전 2.8.22부터는 사용 가능한 메모리에 따라 백업 방법을 선택합니다. 사용 가능한 메모리가 충분하면 캐시가 백업되는 동안 캐시의 예약된 메모리에 모든 변경 사항을 쓰는 하위 프로세스가 생성됩니다. 백업 프로세스 중에 캐시에 쓰는 수에 따라 이 하위 프로세스가 모든 예약된 메모리를 소비하므로 백업이 실패할 수 있습니다.

사용 가능한 메모리가 부족하면 forkless 협조 백그라운드 프로세스가 적용됩니다. forkless 방법은 지연 시간과 처리량 모두에 영향을 줄 수 있습니다. 자세한 정보는 동기화 및 백업 구현 방법을 참조하십시오.

백업 프로세스의 성능 영향에 대한 자세한 내용은 백업의 성능 영향 섹션을 참조하세요.

다음은 백업 및 복원 작업의 개요입니다.

중요

드물지만 백업 프로세스에서 최종 백업을 포함하여 백업 생성에 실패하는 경우가 있습니다. 예약된 메모리가 부족하여 백업이 실패하기도 합니다. 따라서 백업을 시도하기 전에 예약된 메모리를 충분히 확보해야 합니다. 메모리가 부족하면 일부 키를 제거하거나 reserved-memory-percent의 값을 늘릴 수 있습니다.

자세한 정보는 다음 자료를 참조하세요.

클러스터를 삭제하려고 하고 데이터를 보존하는 것이 중요한 경우 추가적인 예방 조치를 취할 수 있습니다. 이렇게 하려면 먼저 수동 백업을 생성하고 사용 가능한 상태인지 확인한 다음 클러스터를 삭제합니다. 이렇게 하면 백업에 실패하더라도 클러스터 데이터를 계속 사용할 수 있습니다. 앞서 설명한 모범 사례에 따라 백업을 다시 시도할 수 있습니다.

백업 제약 조건

백업을 계획하거나 만들려는 경우 다음 제약 조건을 고려해야 합니다.

  • 이때 Redis에서 실행되는 클러스터에 대해서만 백업 및 복원이 지원됩니다.

  • Redis(클러스터 모드 비활성화됨) 클러스터의 경우 cache.t1.micro 노드에서 백업 및 복원이 지원되지 않습니다. 다른 모든 캐시 노드 유형은 지원됩니다.

  • Redis(클러스터 모드 활성화됨) 클러스터의 경우 모든 노드 유형에 대해 백업 및 복원이 지원됩니다.

  • 24시간 연속으로 클러스터의 노드당 20개 이내의 수동 백업을 만들 수 있습니다.

  • Redis(클러스터 모드 활성화됨)는 클러스터 수준(API 또는 CLI의 경우 복제 그룹 수준)에서만 백업 생성을 지원합니다. Redis(클러스터 모드 활성화됨)는 샤드 수준(API 또는 CLI의 경우 노드 그룹 수준)에서는 백업 생성을 지원하지 않습니다.

  • 백업 프로세스 중에는 클러스터에서 다른 API 또는 CLI 작업을 실행할 수 없습니다.

  • 데이터 계층화가 있는 클러스터를 사용하는 경우 백업을 Amazon S3로 내보낼 수 없습니다.

  • r6gd 노드 유형을 사용하는 클러스터의 백업은 r6gd 노드 유형을 사용하는 클러스터에만 복원할 수 있습니다.

백업 비용

ElastiCache를 사용하여 활성 Redis 클러스터마다 백업 하나를 무료로 저장할 수 있습니다. 추가 백업을 위한 스토리지 공간은 모든 AWS 리전에 대해 매월 0.085 USD/GB의 요금이 청구됩니다. 백업을 만들거나 백업의 데이터를 Redis 클러스터에 복원하는 경우에는 데이터 전송 요금이 없습니다.

백업의 성능 영향

백업 프로세스는 실행 중인 Redis 버전에 따라 결정됩니다. Redis 2.8.22부터는 프로세스가 forkless입니다.

Redis 2.8.22 이상을 실행하는 경우 백업

버전 2.8.22 이상에서 Redis 백업은 두 가지 방법 중 하나를 선택합니다. forked 백업을 지원할 메모리가 부족할 경우 ElastiCache에서 협조 백그라운드 처리를 사용하는 forkless 방법을 사용합니다. forked 저장 프로세스를 지원할 메모리가 충분할 경우 이전의 Redis 버전과 동일한 프로세스가 사용됩니다.

forkless 백업 중에 쓰기 로드가 높으면 캐시에 대한 쓰기가 지연됩니다. 이렇게 지연되면 변경 사항이 너무 많이 누적되지 않았는지 확인하므로 백업이 성공적으로 수행되지 않습니다.

2.8.22 이전 Redis 버전을 실행하는 경우 백업

Redis의 기본 BGSAVE 작업을 사용하여 백업이 생성됩니다. 캐시 노드의 Redis 프로세스에서 하위 프로세스를 생성하여 캐시에서 Redis .rdb 파일로 모든 데이터를 씁니다. 하위 프로세스를 생성하는 데 최대 10초가 걸릴 수 있습니다. 이 시간 동안 상위 프로세스는 들어오는 애플리케이션 요청을 수락할 수 없습니다. 하위 프로세스가 독립적으로 실행된 후 상위 프로세스에서 일반적인 작업을 다시 시작합니다. 백업 작업이 완료되면 하위 프로세스가 생깁니다.

백업을 쓰는 동안 추가 캐시 노드 메모리가 새로운 쓰기에 사용됩니다. 이 추가 메모리 사용량이 노드의 사용 가능한 메모리를 초과하면 과도한 페이징으로 인해 처리가 느려지거나 실패할 수 있습니다.

백업 성능 개선

다음은 백업 성능을 개선하기 위한 지침입니다.

  • reserved-memory-percent 파라미터 설정 - 과도한 페이징을 완화하려면 reserved-memory-percent 파라미터를 설정하는 것이 좋습니다. 이 파라미터를 사용하면 Redis가 노드의 모든 사용 가능한 메모리를 소비하고 페이징 양을 줄이는 데 도움이 됩니다. 더 큰 노드를 사용하기만 해도 성능 개선을 확인할 수 있습니다. reserved-memoryreserved-memory-percent 파라미터에 대한 자세한 내용은 예약된 메모리 관리 섹션을 참조하세요.

     

  • 읽기 전용 복제본으로 백업을 만듭니다. 노드가 2개 이상인 노드 그룹에서 Redis를 실행하는 경우 기본 노드 또는 읽기 전용 복제본 중 하나에서 백업을 만들 수 있습니다. BGSAVE 도중 필요한 시스템 리소스로 인해 읽기 전용 복제본 중 하나에서 백업을 생성하는 것이 좋습니다. 복제본으로 백업을 생성하는 동안 기본 노드는 BGSAVE 리소스 요구 사항의 영향을 받지 않습니다. 기본 노드는 속도를 늦추지 않고 계속해서 요청을 처리할 수 있습니다.

    이렇게 하려면 수동 백업 생성(콘솔) 섹션을 참조하고, 백업 생성 창의 클러스터 이름 필드에서 기본값인 기본 노드 대신 복제본을 선택합니다.

복제 그룹을 삭제하고 최종 백업을 요청할 경우 ElastiCache에서는 언제나 기본 노드에서 백업을 만듭니다. 그러면 복제 그룹이 삭제되기 전에 가장 최신 Redis 데이터를 캡처할 수 있습니다.