활성-비활성 설정의 재해 복구 전략

이 문서에서는 의 OpenShift 배포 환경에서 재해 발생 시 다운타임을 최소화하고 빠르게 복구할 수 있도록 활성-비활성 재해 복구를 Google Cloud 계획하고 구현하는 방법을 설명합니다. 또한 데이터 백업, 코드 기반 구성 관리, 보안 비밀 처리에 관한 권장사항을 제공하여 재해 발생 시 애플리케이션을 신속하게 복구할 수 있도록 지원합니다.

이 문서는 에 배포된 Red Hat OpenShift Container Platform에서 애플리케이션의 가용성 및 복원력을 유지할 책임을 맡은 시스템 관리자, 클라우드 설계자, 애플리케이션 개발자를 대상으로 합니다. Google Cloud

이 문서는 장애 발생 시 워크로드의 고가용성을 유지하고 신속하게 복구할 수 있도록 하는 애플리케이션 수준 전략에 중점을 두는 시리즈의 일부입니다. 이 문서에서는 사용자가 이미 재해 복구 권장사항 을 읽었다고 가정합니다. 이 시리즈의 문서는 다음과 같습니다.

재해 복구 아키텍처

활성-비활성 DR에서는 보조 리전을 대기 상태로 유지하며, 재해 발생 시에만 활성화됩니다. 데이터가 지속적으로 복제되는 활성-대기 구성과 달리, 이 전략은 Cloud Storage에 저장된 주기적 백업에 의존하며, 장애 조치 시 인프라가 프로비저닝되고 데이터가 복원됩니다. OpenShift 데이터 보호 API(OADP)와 통합된 Velero와 같은 도구를 사용하여 주기적으로 백업을 수행할 수 있습니다. 이 접근 방식은 비용을 최소화하므로, 복구 시간이 다소 길어도 되는 애플리케이션에 적합합니다. 또한 이 방식은 조직이 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 보다 유연하게 설정하고 조정할 수 있도록 지원합니다.

활성-비활성 DR 시나리오에서는 데이터가 대기 리전에 정기적으로 백업되지만, 실시간으로 복제되지는 않습니다. 인프라는 장애 조치 프로세스의 일부로 프로비저닝되며, 데이터는 최신 백업본에서 복원됩니다. Velero 오픈소스 프로젝트를 기반으로 한 OpenShift 데이터 보호 API(OADP)를 사용하여 정기적으로 백업을 수행할 수 있습니다. 이 백업을 버전 관리 기능이 사용 설정된 Cloud Storage 버킷에 저장하는 것이 좋습니다. 재해 발생 시 OADP를 사용하여 클러스터의 콘텐츠를 복원할 수 있습니다. 이 접근 방식은 지속적인 비용을 최소화하지만 활성-대기 구성에 비해 RTO가 길어지고 RPO가 높아질 수 있습니다. 이 구성은 복구 시간 목표가 더 긴 애플리케이션에 적합합니다.

다음 다이어그램은 활성-비활성 배포와 장애 조치 프로세스를 보여줍니다.

장애 조치 프로세스

장애 조치 프로세스는 다음과 같습니다.

  1. 모니터링된 서비스를 사용할 수 없게 되면 DR 이벤트가 트리거됩니다.
  2. 파이프라인이 DR 리전에 인프라를 자동으로 프로비저닝합니다.
  3. 새 OpenShift 클러스터가 프로비저닝됩니다.
  4. OADP를 통해 최신 백업에서 애플리케이션 데이터, 보안 비밀, 객체가 복원됩니다.
  5. Cloud DNS 레코드가 DR 리전의 부하 분산기를 가리키도록 업데이트됩니다.

위의 다이어그램에 표시된 것처럼 두 개의 개별 OpenShift 리전 클러스터가 서로 다른 Google Cloud 리전(us-central1, europe-west1 등)에 배포됩니다. 각 클러스터는 리전 내에서 고가용성을 유지해야 하며 중복성 확보를 위해 여러 영역을 사용해야 합니다.

활성-비활성 DR 시나리오의 구성요소 설명

이 아키텍처는 다음 구성으로 이루어져 있습니다.

  • 기본 리전(리전 A): 프로덕션 트래픽을 처리하는 완전한 OpenShift 클러스터가 포함되어 있습니다.
  • 보조 리전(리전 B): 처음에는 최소한의 리소스(VPC 및 서브넷)가 포함됩니다. 장애 조치 시 인프라(Compute Engine 인스턴스 및 OCP)가 프로비저닝됩니다.
  • 백업 스토리지: Google Cloud Storage 버킷은 주기적 백업을 저장합니다(애플리케이션 오브젝트를 위한 OADP 또는 Velero 백업뿐만 아니라 PV 및 데이터베이스 백업도 포함). 버킷에는 버전 관리와 교차 리전 복제를 사용하는 것이 좋습니다.
  • 구성 관리: Git 저장소는 코드형 인프라(IaC, 예: Terraform)와 Kubernetes 또는 OpenShift 매니페스트(GitOps용)를 저장합니다.
  • 백업 도구: 기본 클러스터에 구성된 OADP(Velero)는 Cloud Storage에 예약 백업을 수행합니다.
  • 조정: 스크립트 또는 자동화 도구가 장애 조치 중 인프라 프로비저닝 및 복원 프로세스를 트리거합니다.

사용 제품

사용 사례

활성-비활성 DR은 다음과 같은 사용 사례에 권장됩니다.

  • 더 긴 RTO(예: 수분~수시간)를 허용할 수 있는 애플리케이션
  • 비용 최적화가 중요한 환경으로, 지속적으로 실행되는 대기 클러스터의 비용이 금지되는 경우. 지속 비용의 주요 부분은 컴퓨팅 인스턴스 실행이 아니라 객체 스토리지 사용에 해당합니다.
  • 개발, 테스트 또는 중요도가 낮은 프로덕션 워크로드
  • 복구 시간이 덜 중요하게 작용하는 보관 또는 일괄 처리 시스템

설계 고려사항

이 섹션에서는 이 참조 아키텍처를 사용하여 보안, 신뢰성, 운영 효율성, 비용, 성능 관련 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려해야 하는 설계 요소, 권장사항, 설계 권장사항을 설명합니다.

코드 기반 애플리케이션 구성 (GitOps)

모든 클러스터 및 애플리케이션 구성을 Git 저장소에 저장하기 위해 GitOps 접근 방식을 채택하는 것이 좋습니다. 이 접근 방식은 다른 클러스터에서 안정적으로 실행 중인 것으로 확인된 상태로 동기화할 수 있게 함으로써 DR 시나리오에서 빠른 복구를 가능하게 합니다. 백업을 통해 런타임 상태의 스냅샷을 확보할 수 있지만 재해 발생 후 애플리케이션 로직, 매니페스트, 인프라 정의를 신속하게 다시 배포할 수 있는 신뢰할 수 있는 방법 또한 필요합니다.

OpenShift GitOps 운영자 사용

OpenShift GitOps 운영자(Argo CD 기반)는 OpenShift 환경 내에서 GitOps 패턴을 직접 구현할 수 있도록 Red Hat이 지원하는 방식을 제공합니다. 이 운영자는 선택한 구성을 클러스터 상태와 지속적으로 조정하는 프로세스를 자동화하고 해당 구성을 Git 저장소에 저장합니다.

OpenShift GitOps 운영자의 컨트롤러는 클러스터 상태가 해당 저장소에 정의된 구성과 일치하도록 지속적으로 보장합니다. 리소스가 변경되거나 누락되면 자동으로 이를 조정합니다. 자세한 내용은 Red Hat OpenShift GitOps 정보를 참조하세요.

DR 시나리오 실행

재해가 발생한 경우 다음을 수행합니다.

  • 다른 리전에 새로운 OpenShift 클러스터를 설정합니다.
  • OpenShift GitOps 운영자를 설치합니다.
  • Git 저장소를 참조하는 동일한 애플리케이션 매니페스트를 적용합니다.

이 연산자는 클러스터 상태를 저장소와 일치하도록 동기화하며, 코드에 정의된 배포, 서비스, 경로, 운영자 및 기타 리소스를 신속하게 다시 배포합니다.

DR 중 문제가 발생하지 않도록 다음을 수행하는 것이 좋습니다.

  • Git 저장소에서 엄격한 브랜칭 및 태그 지정 전략을 유지하여 DR에 적합한 안정적인 구성을 식별할 수 있도록 합니다.
  • DR 클러스터가 Git 저장소에 액세스할 수 있는 네트워크 연결과 적절한 권한을 가지고 있는지 확인합니다.
  • 장애 조치 중 수동 개입을 방지하기 위해 모든 리소스 유형(예: 인프라 구성요소, 애플리케이션 워크로드, 구성)을 코드로 포함합니다.

방화벽 규칙

트래픽 흐름을 제어하고 보안을 강화하기 위해 두 클러스터에 일관되게 적용할 수 있는 통합 방화벽 정책을 정의합니다.

최소 권한 원칙을 따릅니다. 즉, 애플리케이션 기능에 필요한 트래픽만 허용하도록 인바운드 및 아웃바운드 트래픽을 제한합니다.

배포

이 참조 아키텍처를 기반으로 토폴로지를 배포하는 방법은 Red Hat 문서를 참조하세요.

다음 단계