IBM Cloud Docs
Databases for Redis에 대한 고가용성 및 재해 복구 이해

Databases for Redis에 대한 고가용성 및 재해 복구 이해

고가용성서비스 또는 작업 부하가 장애를 견디고 사전 정의된 서비스 수준에 따라 처리 기능을 계속 제공할 수 있는 능력. 서비스의 경우, 가용성은 서비스 수준 협약에 정의되어 있습니다. 가용성에는 유지보수, 고장, 재해 등 계획된 이벤트와 계획되지 않은 이벤트가 모두 포함됩니다. (HA)은 예기치 않은 장애가 발생하더라도 서비스가 계속 작동하고 액세스할 수 있는 기능입니다. 재해 복구는서비스 중단과 같은 드물지만 심각한 사고와 광범위한 장애로부터 복구할 수 있는 서비스 또는 작업량 능력. 여기에는 전체 지역에 영향을 미치는 물리적 재해, 데이터베이스 손상, 또는 작업 부하에 기여하는 서비스의 손실이 포함됩니다. 그 영향은 고가용성 설계가 처리할 수 있는 능력을 초과합니다. 서비스 인스턴스를 작동 상태로 복구하는 프로세스입니다.

Databases for Redis 는 표준 요금제로 정의된 서비스 수준 목표(SLO)를 충족하는 지역 서비스입니다.

사용 가능한 IBM Cloud 지역 및 데이터 센터에 대한 자세한 내용은 Databases for Redis, 위치별 서비스 및 인프라 가용성을 참조하세요.

고가용성 아키텍처

Redis 건축 건축
Redis

Databases for Redis 는 인프라 유지보수, 업그레이드 및 일부 장애로부터 데이터베이스와 데이터를 보호하는 복제, 장애 복구 및 고가용성 기능을 제공합니다. 배포에는 기본 구성과 복제본 구성에 두 개의 데이터 멤버가 있는 클러스터가 포함되어 있습니다. 복제본은 비동기 복제를 사용하여 최신 상태로 유지됩니다. 3개의 Redis 센티널을 통해 고가용성을 모니터링 및 관리합니다

기본적으로 데이터 지속성은 모든 배포에서 사용하도록 설정되며 데이터는 디스크에 기록됩니다. Databases for Redis 에서는 RDB 스냅샷과 AOF(Append Only File) 의 조합을 사용하여 데이터를 디스크에 지속합니다. 내구성과 성능의 균형을 맞추기 위해 Databases for Redis 의 디스크 쓰기(fsync) 간격은 1초에 한 번으로 설정되어 있습니다.

데이터 지속성을 끌 수 있으며, 이는 Redis를 캐시로 구성하는 데 유용합니다.

고가용성 기능

Databases for Redis 는 다음과 같은 고가용성 기능을 지원합니다:

고가용성 기능
기능 설명 고려사항
자동 페일오버 모든 클러스터에 표준으로 적용되며 영역 또는 단일 구성원 장애에 대해 복원력 제공
구성원 수 최소 - 2명. 기본값은 기본 및 복제본 구성의 표준 두 멤버 클러스터입니다. 2명으로 구성된 클러스터는 단일 인스턴스 또는 영역 장애(지연 임계값까지 데이터 손실)가 발생하면 자동으로 복구됩니다. 클러스터의 상태를 모니터링하고 장애 조치를 조정하는 3개의 Sentinel 노드.
비동기 복제 쓰기 경로를 차단하지 않고 기본에서 복제본으로 복제할 수 있어 짧은 지연 시간으로 고가용성을 보장합니다. 아래 비동기 복제를 참조하세요. 복제 지연(RPO > 0)으로 인해 장애 조치 중 데이터가 손실될 수 있습니다. 엄격한 데이터 내구성이 필요한 곳에는 적합하지 않습니다.

비동기 복제를 위한 Databases for Redis

기본적으로 Databases for Redis 는 기본 노드가 복제본이 쓰기를 승인할 때까지 기다리지 않는 비동기 복제를 사용합니다. 따라서 짧은 지연 시간과 높은 처리량을 보장하므로 Databases for Redis 은 캐싱 및 성능에 민감한 워크로드에 이상적입니다. 그러나 기본 장애가 발생하면 복제 지연으로 인해 복제본이 가장 최근의 쓰기를 받지 못하여 데이터 손실이 발생할 수 있습니다.

Databases for Redis 복제는 엄격한 내구성이 아닌 고가용성을 위해 설계되었습니다. 주 서버에 연결할 수 없게 되면 자동으로 장애 조치가 트리거되어 복제본이 리더로 승격됩니다. 복제는 비동기식이기 때문에 이 과정에서 일부 커밋된 쓰기가 손실될 수 있습니다. 이 복제 지연은 Databases for Redis 배포의 복구 지점 목표(RPO)를 정의합니다.

데이터 손실 위험을 줄이기 위해 Databases for Redis 에서는 복제 프로세스와 독립적으로 디스크에 데이터를 기록하는 RDB 스냅샷 및 AOF(Append Only File)와 같은 지속성 메커니즘을 지원합니다. 워크로드 요구 사항에 따라 신중하게 구성해야 합니다.

Databases for Redis 의 비동기 복제는 빠른 성능을 보장하지만 장애 조치 이벤트 중 데이터 손실 가능성을 없애지는 못합니다. 속도와 가용성이 엄격한 데이터 일관성보다 중요한 워크로드에 권장됩니다.

재해 복구 아키텍처

재해 복구를 위한 일반적인 전략은 아래의 Restore 데이터베이스와 같은 새 데이터베이스를 만드는 것입니다. 새 데이터베이스의 콘텐츠는 재해 이전에 생성된 원본 데이터베이스의 백업일 수 있습니다.

Redis 재해 복구 아키텍처 재해 복구 아키텍처
Redis

재해 복구 기능

Databases for Redis 는 다음과 같은 재해 복구 기능을 지원합니다:

재해 복구 기능
기능 설명 고려사항
백업 복원 이전에 만든 백업에서 데이터베이스를 만듭니다( Cloud Databases 백업 관리하기를 참조하세요). 복원된 데이터베이스에 대한 새 연결 문자열은 워크로드 전체에서 참조해야 합니다.

재해 복구 계획

재해 복구 단계는 정기적으로 연습해야 합니다. 계획을 수립할 때 다음과 같은 실패 시나리오와 해결 방법을 고려하세요.

실패 시나리오 및 해결 방법
실패 분석
하드웨어 장애(단일 지점) (예: IBM ) 영역 내 단일 하드웨어 장애 지점으로부터 복원력이 있는 데이터베이스를 제공합니다. 고객 구성이 필요하지 않습니다.
구역 장애 자동 장애 조치. 데이터베이스 멤버는 영역 간에 분산되어 있습니다.
데이터 손상 백업 복원. 프로덕션 또는 소스 데이터에 복원된 데이터베이스를 사용하여 복원된 데이터베이스의 손상을 수정합니다.

애플리케이션 레벨의 고가용성

네트워크 및 클라우드 서비스를 통해 통신하는 애플리케이션은 일시적 연결 실패의 영향을 받습니다. 사용자 배치 또는 IBM Cloud에 대한 연결에서 일시적인 끊김으로 인한 오류가 발생하는 경우 연결을 재시도하도록 애플리케이션을 디자인하려고 합니다.

Databases for Redis 은 관리형 서비스이므로 정기적인 업데이트와 데이터베이스 유지보수는 정상적인 운영의 일부로 이루어집니다. 이로 인해 가끔 짧은 간격으로 데이터베이스를 사용할 수 없게 될 수 있습니다. 또한 이로 인해 데이터베이스가 정상적인 장애 복구, 재시도 및 다시 연결을 트리거할 수도 있습니다. 데이터베이스가 복제본인 멤버와 리더인 멤버를 판별하는 데 약간의 시간이 걸리기 때문에 잠시 연결이 중단될 수도 있습니다. 일반적으로 장애 복구에는 30초 미만이 걸립니다.

애플리케이션은 데이터베이스의 일시적인 중단을 처리하고, 실패한 데이터베이스 명령에 대한 오류 처리를 구현하며, 임시 interruption.Use IOREDIS, NODEREDIS 또는 기타 선택한 패키지에서 복구하기 위한 재시도 로직을 구현하여 application.For 자세한 내용은 Redis 블로그 게시물에서 오류 감지 및 처리 기능을 참조하세요.

몇 분 동안 데이터베이스를 사용할 수 없거나 연결이 중단되는 일은 예상되지 않습니다. 연결이 되지 않는 시간이 1분 이상 지속되는 경우 세부 정보를 포함한 지원 케이스를 열어 조사할 수 있도록 하세요.

연결 한계

Databases for Redis 배포당 최대 10,000개의 동시 연결을 설정합니다. 이 제한은 Redis 환경 내에서 성능 안정성과 리소스 관리를 보장합니다. 그러나 10,000개의 연결이 모두 클라이언트에 제공되는 것은 아니며, 일부는 배포의 상태와 무결성을 유지하는 작업을 위해 내부적으로 예약되어 있습니다. 연결 제한에 도달한 후 새 연결을 시작하려고 시도하면 오류가 발생합니다. 자세한 내용은 Redis 연결 관리하기를 참조하세요.

HA 및 DR에 대한 책임

다음 정보는 HA 및 DR 계획을 수립하고 지속적으로 실천하는 데 도움이 될 수 있습니다.

백업에서 데이터베이스를 복원하거나 특정 시점 복원을 사용하는 경우 새 연결 문자열로 새 데이터베이스가 만들어집니다. 새 연결 문자열을 사용하려면 기존 워크로드와 프로세스를 조정해야 합니다.

복구된 데이터베이스에는 재해 데이터베이스와 동일한 고객 생성 종속성이 필요할 수도 있습니다. 복구된 지역에 이러한 서비스 및 기타 서비스가 존재하는지 확인합니다:

  • IBM® Key Protect for IBM Cloud®
  • Hyper Protect Crypto Services

데이터베이스를 삭제하면 관련 백업도 삭제된다는 점을 기억하세요. 그러나 삭제된 데이터베이스는 제한된 기간 내에 복구할 수 있습니다. 자세한 내용은 백업 FAQ를 참조하세요.

IBM Cloud 에서 백업을 복사할 수 없으므로 추가 백업을 위해 데이터베이스별 도구를 사용하는 것이 좋습니다. 악의적인 데이터베이스 삭제에 이어 데이터베이스 복구가 필요할 수 있습니다. 데이터베이스에 대한 IAM 액세스를 주의 깊게 관리하면 이 문제에 대한 노출을 줄일 수 있습니다.

각 기능과 관련된 다음 체크리스트는 계획을 세우고 실천하는 데 도움이 될 수 있습니다.

  • 백업 복원
  • 데이터베이스 복원 지역에는 몇 가지 제한 사항이 있습니다. Cloud Databases 백업 관리하기를 읽고 복원 목표를 달성할 수 있는지 확인하세요.
    • 백업의 보존 기간이 요구 사항을 충족하는지 확인합니다.
    • 정기적으로 테스트 복원을 예약하여 실제 복원 시간이 정의된 RTO를 충족하는지 확인합니다. 데이터베이스 크기는 복원 시간에 큰 영향을 미친다는 점을 기억하세요. 대규모 데이터베이스를 관리하기 쉬운 작은 단위로 나누고 사용하지 않는 데이터를 삭제하는 등 복원 시간을 최소화하는 전략을 고려하세요.
    • Key Protect 서비스를 확인합니다.

Databases for Redis 사용에 대한 고객과 IBM Cloud 간의 책임 소유권에 대해 자세히 알아보려면 Cloud Databases 에 대한 책임 공유를 참조하세요.

최신 정보 받기: IBM 알림

고객 워크로드에 영향을 미치는 업데이트는 IBM Cloud 알림을 통해 전달됩니다. 이 서비스와 관련된 계획된 유지 관리, 공지 사항 및 릴리즈 노트에 대한 최신 정보를 확인하려면 모니터링 알림 및 상태 페이지를 참조하세요. 또한 버전 정책 페이지에서 지원 종료 버전 및 날짜에 대한 최신 업데이트를 정기적으로 확인하시기 바랍니다.

추가 안내