비즈니스 연속성 하이브리드 및 멀티 클라우드 패턴

업무상 중요한 시스템에 비즈니스 연속성을 고려하는 주요 동인은 조직에 장애가 발생하거나 그 이후에 우수한 복원력으로 비즈니스 운영을 지속할 수 있도록 돕기 위한 것입니다. 여러 지리적 리전에 걸쳐 시스템 및 데이터를 복제하고 단일 장애점을 방지함으로써 로컬 인프라에 영향을 미치는 자연 재해의 위험을 최소화할 수 있습니다. 다른 장애 시나리오에는 사이버 보안 공격이나 시스템 구성 오류에 이르는 심각한 시스템 오류가 포함됩니다.

장애를 견딜 수 있도록 시스템을 최적화하는 것은 효과적인 비즈니스 연속성을 구축하는 데 필수입니다. 시스템 안정성은 성능, 복원력, 업타임 가용성, 보안, 사용자 환경을 포함하되 이에 국한되지 않는 여러 요인의 영향을 받을 수 있습니다. Google Cloud에서 안정적인 서비스를 설계하고 운영하는 방법에 대한 자세한 내용은 Google Cloud Well-Architected Framework의 안정성 요소와 Google Cloud의 안정성 구성 요소를 참고하세요.

이 아키텍처 패턴은 여러 컴퓨팅 환경에 걸친 애플리케이션의 중복 배포에 의존합니다. 이 패턴에서는 안정성을 높이기 위해 여러 컴퓨팅 환경에 동일한 애플리케이션을 배포합니다. 비즈니스 연속성은 중단 이벤트 후에도 사전 정의된 허용 가능한 수준에서 주요 비즈니스 기능 또는 서비스를 계속할 수 있는 조직의 능력으로 정의할 수 있습니다.

재해 복구(DR)는 비즈니스 연속성의 하위 집합으로 간주되며 중요한 비즈니스 기능을 지원하는 IT 시스템이 중단된 후 가능한 한 빨리 작동하도록 보장하는 데 중점을 둡니다. 일반적으로 DR 전략과 계획은 더 광범위한 비즈니스 연속성 전략을 수립하는 데 도움이 되는 경우가 많습니다. 기술적인 관점에서 재해 복구 전략 수립을 시작할 때 비즈니스 영향 분석에서는 목표 복구 시간(RPO)과 복구 시간 목표(RTO)라는 두 가지 주요 측정항목을 정의해야 합니다. Google Cloud 를 사용하여 재해 복구를 처리하는 방법에 대한 자세한 내용은 재해 복구 계획 가이드를 참고하세요.

RPO 및 RTO 목표 값이 작을수록 최소한의 데이터 손실로 중단되었을 때 서비스를 더 빠르게 복구할 수 있습니다. 하지만 이는 중복 시스템 구축을 의미하기 때문에 비용이 많이 듭니다. 거의 실시간으로 데이터 복제를 수행할 수 있고 오류 발생 후 동일한 규모로 작동하는 중복 시스템은 복잡성, 관리 오버헤드 및 비용을 증가시킵니다.

DR 전략이나 패턴을 선택하는 결정은 비즈니스 영향 분석을 통해 이루어져야 합니다. 예를 들어 금융 서비스 조직의 경우 단 몇 분의 다운타임으로 인해 발생하는 재정적 손실이 DR 시스템 구현 비용을 훨씬 초과할 수 있습니다. 그러나 다른 업계의 기업에서는 상당한 비즈니스 영향 없이 몇 시간 동안 다운타임이 지속될 수 있습니다.

온프레미스 데이터 센터에서 업무상 중요한 시스템을 실행하는 경우 DR 접근방식 중 하나는 다른 리전의 두 번째 데이터 센터에서 대기 시스템을 유지보수하는 것입니다. 그러나 보다 비용 효율적인 접근 방식은 장애 조치 목적으로 퍼블릭 클라우드 기반 컴퓨팅 환경을 사용하는 것입니다. 이러한 접근 방식은 비즈니스 연속성 하이브리드 패턴의 주요 동인입니다. 클라우드는 사용하지 않을 때 일부 DR 인프라를 사용 중지할 수 있기 때문에 비용 측면에서 특히 매력적일 수 있습니다. 더 저렴한 DR 솔루션을 달성하기 위해 클라우드 솔루션을 통해 기업은 RPO 및 RTO 값의 잠재적 증가를 수용할 수 있습니다.

앞의 다이어그램은 클라우드를 온프레미스 환경에 대한 장애 조치 또는 재해 복구 환경으로 사용하는 방법을 보여줍니다.

이러한 패턴을 보다 덜 흔하면서 필수로 요구되는 경우가 적은 방식으로 변형한 패턴이 비즈니스 연속성 멀티 클라우드 패턴입니다. 이 패턴에서 프로덕션 환경은 하나의 클라우드 제공업체를 사용하고 DR 환경은 다른 클라우드 제공업체를 사용합니다. 여러 클라우드 공급업체 전반에 걸쳐 워크로드 복사본을 배포하면 멀티 리전 배포에서 제공하는 것보다 가용성을 높일 수 있습니다.

여러 클라우드에서 DR을 평가하는 것과 리전이 다른 하나의 클라우드 제공업체를 사용할 때는 다음을 포함한 여러 고려사항을 철저히 분석해야 합니다.

• 관리 효율성
• 보안
• 전반적인 실현 가능성
• 비용
  • 둘 이상의 클라우드 제공업체로부터 발생할 수 있는 아웃바운드 데이터 전송 요금은 지속적인 클라우드 간 통신으로 인해 비용이 많이 들 수 있습니다.
  • 데이터베이스를 복제하는 동안 대량의 트래픽이 발생할 수 있습니다.
  • TCO 및 클라우드 간 네트워크 인프라 관리 비용이 듭니다.

규제 요구 사항을 충족하기 위해 데이터를 해당 국가에 보존해야 하는 경우 해당 국가에도 있는 두 번째 클라우드 제공업체를 DR로 사용하는 것이 옵션이 될 수 있습니다. 보조 클라우드 제공업체를 사용할 경우 온프레미스 환경을 사용하여 하이브리드 설정을 구축할 수 있는 옵션이 없다고 가정합니다. 클라우드 솔루션 재설계를 방지하려면 이상적으로 두 번째 클라우드 제공업체가 리전 내에서 필요한 모든 기능과 서비스를 제공해야 합니다.

설계 고려사항

• DR 기대치: 비즈니스가 달성하고자 하는 RPO 및 RTO 목표는 DR 아키텍처와 구축 계획을 이끌어야 합니다.
• 솔루션 아키텍처: 이 패턴을 사용할 경우 DR 기대치를 충족하도록 온프레미스 환경의 기존 기능을 복제해야 합니다. 따라서 클라우드 환경에서 동일한(또는 더 최적화된) 기능과 성능을 제공하기 위해 애플리케이션 재호스팅, 리팩터링 또는 재설계의 타당성과 실행 가능성을 평가해야 합니다.
• 설계 및 구축: 클라우드 환경에서 엔터프라이즈 워크로드를 배포하려면 시작 영역을 구축하는 것이 거의 항상 전제 조건입니다. 자세한 내용은 Google Cloud의 시작 영역 설계를 참고하세요.

• DR 호출: DR 설계 및 프로세스에서는 다음 질문을 고려하는 것이 중요합니다.

  • DR 시나리오를 트리거하는 요인은 무엇인가요? 예를 들어 기본 사이트의 특정 기능이나 시스템 오류에 의해 DR이 트리거될 수 있습니다.
  • DR 환경에 대한 장애 조치는 어떻게 호출되나요? 수동 승인 프로세스인가요 아니면 낮은 RTO 목표를 달성하도록 자동화할 수 있나요?
  • 예상되는 RTO에 맞춰 장애 조치를 호출하려면 시스템 오류 감지 및 알림 메커니즘을 어떻게 설계해야 할까요?
  • 장애가 감지된 후 트래픽은 어떻게 DR 환경으로 다시 라우팅되나요?

  테스트를 통해 이러한 질문에 대한 답을 검증하세요.

• 테스트: DR에 대한 장애 조치를 철저히 테스트하고 평가합니다. RPO 및 RTO 기대치를 충족하는지 확인하세요. 이렇게 하면 필요할 때 더 자신 있게 DR을 호출할 수 있습니다. 프로세스 또는 기술 솔루션에 새로운 변경이나 업데이트가 있을 때마다 테스트를 다시 수행하세요.

• 팀 기술: 환경이 제3자에 의해 관리되지 않는 한, 하나 이상의 기술팀이 클라우드 환경에서 프로덕션 워크로드를 빌드, 운영, 문제 해결할 수 있는 기술과 전문성을 보유하고 있어야 합니다.

장점

비즈니스 연속성을 위해 Google Cloud 를 사용하면 다음과 같은 몇 가지 이점이 있습니다.

• Google Cloud 에는 전 세계적으로 선택할 수 있는 리전이 많기 때문에 이를 사용하여 동일한 대륙 내의 다른 사이트에 데이터를 백업하거나 복제할 수 있습니다. 또한 다른 대륙의 사이트에 데이터를 백업하거나 복제할 수 있습니다.
• Google Cloud 는 이중 리전 또는 멀티 리전 버킷의 Cloud Storage에 데이터를 저장하는 기능을 제공합니다. 데이터가 두 개 이상의 서로 다른 지리적 리전에 중복 저장됩니다. 이중 리전 및 멀티 리전 버킷에 저장된 데이터는 기본 복제를 사용하여 지리적 리전 간에 복제됩니다.
  • 이중 리전 버킷은 비즈니스 연속성과 DR 계획을 지원하기 위해 지리적 중복성을 제공합니다. 또한 더 낮은 RPO로 더 빠르게 복제하기 위해 이중 리전에 저장된 객체는 선택적으로 해당 리전 전체에서 터보 복제를 사용할 수 있습니다.
  • 마찬가지로 멀티 리전 복제는 멀티 리전의 지리적 경계 내에 데이터를 저장하여 여러 리전에 걸쳐 중복성을 제공합니다.
• DR 구축을 위한 자본 비용 및 운영 비용을 줄이기 위해 다음 중 하나 이상의 옵션을 제공합니다.
  • 중지된 VM 인스턴스는 스토리지 비용만 발생하며 VM 인스턴스를 실행하는 것보다 훨씬 저렴합니다. 즉, 수동 대기 시스템의 유지 비용을 최소화할 수 있습니다.
  • Google Cloud 의 종량제 모델을 사용하면 실제로 사용한 스토리지 및 컴퓨팅 용량에 대해서만 비용을 지불합니다.
  • 자동 확장과 같은 탄력성 기능을 사용하면 필요한 만큼 DR 환경을 자동 확장하거나 축소할 수 있습니다

예를 들어 다음 다이어그램은 Compute Engine, Cloud SQL, Cloud Load Balancing과 함께Google Cloud 의 복구 구성요소를 사용하는 온프레미스 환경 (프로덕션)에서 실행되는 애플리케이션을 보여줍니다. 이 시나리오에서는 지속적인 데이터 복제로 더 빠르게 복구할 수 있도록 VM 기반 데이터베이스 또는 Cloud SQL과 같은 Google Cloud 관리형 데이터베이스를 사용하여 데이터베이스가 사전 프로비저닝됩니다. 일반 작업 중 비용을 줄이기 위해 사전 생성된 스냅샷에서 Compute Engine VM을 실행할 수 있습니다. 이렇게 설정하고 장애 이벤트가 발생하면 DNS는 Cloud Load Balancing 외부 IP 주소를 가리켜야 합니다.

클라우드에서 애플리케이션을 작동하려면 웹 및 애플리케이션 VM을 프로비저닝해야 합니다. 목표 RTO 수준과 회사 정책에 따라 DR 호출, 클라우드에서 워크로드 프로비저닝, 트래픽 재라우팅까지의 전체 프로세스를 수동 또는 자동으로 완료할 수 있습니다.

인프라 프로비저닝 속도를 높이고 자동화하려면 코드형 인프라를 관리하는 것이 좋습니다. 지속적 통합 서비스인 Cloud Build를 사용하여 Terraform 매니페스트를 환경에 자동으로 적용할 수 있습니다. 자세한 내용은 Terraform, Cloud Build, GitOps를 사용하여 코드형 인프라 관리를 참조하세요.

권장사항

비즈니스 연속성 패턴을 사용하는 경우, 다음 권장사항을 고려합니다.

• 장애 조치 및 복구 절차와 함께 인프라를 문서화하는 재해 복구 계획을 만듭니다.
• 비즈니스 영향 분석과 식별된 필수 RPO 및 RTO 목표를 기반으로 다음 조치를 고려하세요.
  • Google Cloud 에 데이터를 백업하는 것으로 충분한지 또는 다른 DR 전략 (콜드, 웜, 상시 대기 시스템)을 고려해야 하는지 결정합니다.
  • DR 계획의 구성 요소로 사용할 수 있는 서비스와 제품을 정의합니다.
  • 선택한 DR 전략의 일부로 애플리케이션 및 데이터에 적용 가능한 DR 시나리오를 구성합니다.
• 데이터만 백업할 때는 핸드오버 패턴을 사용하는 것이 좋습니다. 그렇지 않으면 메시 패턴이 기존 환경 네트워크 아키텍처를 복제하는 데 좋은 옵션이 될 수 있습니다.
• 특히 통신이 동시에 처리되는 경우, 서로 다른 환경에서 실행되는 시스템 간 종속 항목을 최소화합니다. 이러한 종속 항목으로 인해 성능과 전반적인 가용성이 저하될 수 있습니다.

• 분할 브레인 문제를 방지하세요. 여러 환경에서 양방향으로 데이터를 복제하는 경우, 분할 브레인 문제에 노출될 수 있습니다. 분할 브레인 문제는 데이터를 양방향으로 복제하는 두 환경에서 서로 통신이 끊길 때 발생합니다. 이러한 분할로 인해 두 환경의 시스템은 다른 환경을 사용할 수 없으며 데이터에 독점적으로 액세스할 수 있습니다. 이로 인해 데이터 수정이 충돌할 수 있습니다. 분할 브레인 문제를 방지하는 두 가지 일반적인 방법은 다음과 같습니다.

  • 세 번째 컴퓨팅 환경을 사용합니다. 이 환경에서는 시스템이 데이터를 수정하기 전에 쿼럼을 확인할 수 있습니다.

  • 연결이 복원된 후 충돌하는 데이터 수정이 조정되도록 허용합니다.

    SQL 데이터베이스를 사용하면 클라이언트가 새 기본 인스턴스 사용을 시작하기 전에 원래 기본 인스턴스에 액세스할 수 없도록 하여 분할 브레인 문제를 방지할 수 있습니다. 자세한 내용은 Cloud SQL 데이터베이스 재해 복구를 참조하세요.

• CI/CD 시스템과 아티팩트 저장소가 단일 장애점이 되지 않도록 합니다. 환경 하나를 사용할 수 없는 경우에도 새 출시를 배포하거나 구성 변경사항을 계속 적용할 수 있어야 합니다.

• 대기 시스템을 사용할 때 모든 워크로드를 이동할 수 있게 합니다. 시스템이 환경 간에 일관성을 유지하도록 모든 워크로드는 이동 가능해야 합니다(애플리케이션에서 지원되고 실행 가능한 경우). 컨테이너와 Kubernetes를 고려하여 이 접근 방식을 달성할 수 있습니다. Google Kubernetes Engine(GKE) Enterprise 버전을 사용하면 빌드 및 작업을 간소화할 수 있습니다.

• 대기 시스템 배포를 CI/CD 파이프라인에 통합합니다. 이러한 통합을 통해 애플리케이션 버전과 구성이 여러 환경에서 일관성을 유지할 수 있습니다.

• 재해 발생 시 사용자를 대기 시스템으로 다시 라우팅할 수 있도록 합리적으로 짧은 TTL(수명) 값으로 DNS를 구성하여 DNS 변경 사항이 빠르게 전파되도록 합니다.

• 아키텍처 및 솔루션 동작에 적합한 DNS 정책 및 라우팅 정책을 선택합니다. 또한 여러 리전의 부하 분산기를 DNS 라우팅 정책과 결합하여 하이브리드 설정을 포함한 다양한 사용 사례에 전역 부하 분산 아키텍처를 생성할 수 있습니다.

• 여러 DNS 제공업체를 사용합니다. 여러 DNS 제공업체를 사용하는 경우 다음과 같은 이점이 있습니다.

  • 애플리케이션 및 서비스의 가용성과 복원력을 향상시킵니다.

  • 여러 제공업체 DNS 구성을 사용하여 온프레미스 및 클라우드 환경 간에 종속 항목이 있는 하이브리드 애플리케이션의 배포 또는 마이그레이션을 간소화합니다.

    Google Cloud 는 다중 DNS 제공업체를 통해 환경을 설정하고 운영하는 데 도움이 되는 octoDNS 기반의 오픈소스 솔루션을 제공합니다. 자세한 내용은 Cloud DNS를 사용하는 다중 제공업체 공개 DNS를 참고하세요.

• 대기 시스템을 사용하여 자동 장애 조치를 만들 때는 부하 분산기를 사용합니다. 부하 분산기 하드웨어가 실패할 수 있다는 점에 유의하세요.

• 이 아키텍처 패턴을 사용할 때 발생하는 일부 시나리오를 지원하려면 하드웨어 부하 분산기 대신 Cloud Load Balancing을 사용합니다. 내부 클라이언트 요청 또는 외부 클라이언트 요청은 가중치 기반 트래픽 분할과 같은 다양한 측정항목을 기반으로 기본 환경이나 DR 환경으로 리디렉션될 수 있습니다. 자세한 내용은 전역 외부 애플리케이션 부하 분산기의 트래픽 관리 개요를 참조하세요.

• Google Cloud 에서 다른 환경으로의 아웃바운드 데이터 전송량이 많은 경우 Cloud Interconnect 또는 Cross-Cloud Interconnect를 사용하는 것이 좋습니다. Cloud Interconnect는 연결 성능을 최적화하는 데 도움이 되며 특정 조건을 충족하는 트래픽에 대한 아웃바운드 데이터 전송 요금을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참고하세요.

• RPO 및 RTO 목표를 포함하여 요구사항을 충족하는 데이터 백업, 복제, 기타 태스크를 용이하게 하려면 Google Cloud Marketplace에서 선호하는 파트너 솔루션을 사용하는 것이 좋습니다.

• DR 호출 시나리오를 테스트하고 평가하여 대상 RTO 값과 비교할 때 재해로부터 애플리케이션이 얼마나 쉽게 복구될 수 있는지 파악합니다.

• 전송 중 통신을 암호화합니다. Google은 민감한 정보를 보호하기 위해 모든 전송 중 통신을 암호화할 것을 권고합니다. 연결 레이어에서 암호화가 필요한 경우 선택한 하이브리드 연결 솔루션에 따라 다양한 옵션을 사용할 수 있습니다. 이러한 옵션에는 VPN 터널, Cloud Interconnect를 통한 HA VPN, Cloud Interconnect용 MACsec이 포함됩니다.