애플리케이션의 재해 복구 시나리오

Last reviewed 2024-08-05 UTC

이 문서는 Google Cloud의 재해 복구(DR)를 설명하는 시리즈 중 하나입니다. 이 파트에서는 애플리케이션의 일반 재해 복구 시나리오를 살펴봅니다.

시리즈는 다음 세 부분으로 구성됩니다.

소개

이 문서에서는 애플리케이션이 재해 이벤트 시 얼마나 손쉽게 복구될 수 있는지 나타내는 DR 패턴을 기준으로 애플리케이션의 DR 시나리오를 구성합니다. DR 구성요소 문서에서 설명한 개념을 사용하여 복구 목표에 알맞은 엔드 투 엔드 DR 계획을 구현하는 방법을 설명합니다.

시작하려면 복구 목표와 아키텍처에 대한 생각이 DR 계획에 어떤 직접적인 영향이 있는지 보여 주는 몇 가지 일반적인 워크로드를 고려해 보세요.

일괄 처리 워크로드

일괄 처리 워크로드는 대체로 주요 업무의 핵심이 아니기 때문에 업타임을 극대화하기 위해 고가용성(HA) 아키텍처를 설계하는 비용을 발생시킬 필요가 없습니다. 따라서 일반적으로 일괄 처리 워크로드가 중단을 해결할 수 있습니다. 이러한 유형의 워크로드는 스팟 VM 및 선점형 VM 인스턴스와 같은 비용 효율적인 제품을 활용할 수 있습니다. 선점형 VM 인스턴스는 일반 인스턴스보다 훨씬 더 낮은 가격으로 만들고 실행할 수 있습니다. 하지만 Compute Engine이 다른 작업을 위해 이러한 리소스에 액세스해야 하는 경우 이러한 인스턴스를 사전에 중지하거나 삭제할 수 있습니다.

처리 작업의 일부로 정기적인 체크포인트를 구현하면 새 VM 시작 시 처리 작업을 장애 지점부터 다시 시작할 수 있습니다. Dataproc을 사용하는 경우, 선점형 워커 노드를 실행하는 프로세스는 관리형 인스턴스 그룹에서 관리됩니다. 이 패턴은 대체 VM이 계속 처리되기를 잠시 동안 기다리는 웜 패턴으로 간주될 수 있습니다.

전자 상거래 사이트

전자 상거래 사이트에서 애플리케이션의 일부분이 더 큰 RTO 값을 가질 수 있습니다. 예를 들어 실제 구매 파이프라인의 가용성이 높아야 하지만 주문 알림을 고객에게 보내는 이메일 프로세스는 몇 시간 정도 지연될 수 있습니다. 구매에 대해 고객이 알고 있으므로 확인 이메일을 기대하지만 알림이 프로세스의 중요한 부분은 아닙니다. 이 패턴은 핫 (구매) 패턴과 웜/콜드 (알림) 패턴을 혼합한 것입니다.

애플리케이션의 트랜잭션 부분에는 최소한의 RTO 값과 높은 업타임이 필요합니다. 따라서 애플리케이션의 해당 부분에 대한 가용성을 극대화하는 HA를 사용합니다. 이 접근 방법은 핫 패턴으로 간주될 수 있습니다.

전자상거래 시나리오는 동일한 애플리케이션 안에 어떻게 여러 다른 RTO 값이 있을 수 있는지 보여 줍니다.

동영상 스트리밍

동영상 스트리밍 솔루션에는 검색 경험에서부터 실제 사용자에게 콘텐츠를 스트리밍할 때까지 높은 가용성이 요구되는 구성요소가 여러 개 있습니다. 또한 만족스러운 사용자 경험을 제공하기 위해서는 시스템의 지연 시간이 낮아야 합니다. 솔루션의 한 측면이라도 만족스러운 경험을 제공하지 못하면 공급업체는 물론 고객에게 부정적인 영향을 줍니다. 더 나아가 오늘날의 고객들은 경쟁 제품으로 돌아설 수 있습니다.

이 시나리오의 경우 HA 아키텍처가 반드시 필요하고 RTO 값이 작아야 합니다. 이 시나리오에서는 재해가 발생할 경우 영향을 최소화할 수 있도록 애플리케이션 아키텍처 전반에서 핫 패턴이 필요합니다.

온프레미스 프로덕션을 위한 DR 및 HA 아키텍처

이 섹션에서는 애플리케이션이 온프레미스로 실행되고 DR 솔루션이 Google Cloud에 있는 경우에 세 가지 패턴(콜드, 웜, 핫)을 구현하는 방법을 살펴봅니다.

콜드 패턴: Google Cloud로 복구

콜드 패턴에서는 DR Google Cloud 프로젝트에서 복구 시나리오를 사용할 수 있는 만큼 최소한의 리소스가 있습니다. 프로덕션 환경에서 프로덕션 워크로드를 실행하지 못하게 만드는 문제가 발생하면 장애 조치 전략을 통해 Google Cloud에서 프로덕션 환경의 미러링을 시작해야 합니다. 그러면 클라이언트가 DR 환경에서 서비스를 사용하기 시작합니다.

이 섹션에서는 이 패턴의 예를 살펴봅니다. 이 예시에서 Cloud Interconnect는 Google Cloud에 대한 연결을 제공하도록 자체 관리형(Google Cloud 외부) VPN 솔루션으로 구성됩니다. 데이터는 프로덕션 환경의 일부로 Cloud Storage에 복사됩니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Cloud DNS
  • Cloud Interconnect
  • 자체 관리형 VPN 솔루션
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

이 예시 아키텍처를 다이어그램으로 나타내면 다음과 같습니다.

프로덕션이 온프레미스일 때 콜드 패턴의 아키텍처

다음 단계는 환경을 구성하는 방법에 대한 간략한 개요입니다.

  1. VPC 네트워크를 만듭니다.
  2. 온프레미스 네트워크와 Google Cloud 네트워크 간에 연결을 구성합니다.
  3. 데이터 백업을 위해 타겟으로 Cloud Storage 버킷을 만듭니다.
  4. 서비스 계정을 만듭니다.
  5. IAM 정책을 만들어 버킷과 버킷의 객체에 액세스할 수 있는 사람을 제한합니다. 이 목적을 위해 특수하게 만든 서비스 계정을 포함합니다. 또한 연산자 또는 시스템 관리자에 대한 정책에 사용자 계정 또는 그룹을 추가하여 이 모든 ID에 관련 권한을 부여합니다. Cloud Storage에 액세스할 수 있는 권한에 대한 자세한 내용은 Cloud Storage에 대한 IAM 권한을 참조하세요.
  6. 서비스 계정 명의 도용을 사용하여 로컬 Google Cloud 사용자 (또는 서비스 계정)가 이전에 만든 서비스 계정을 가장할 수 있는 액세스 권한을 부여합니다. 또는 이 목적으로만 사용할 새 사용자를 만들 수 있습니다.
  7. 타겟 버킷에서 파일을 업로드 및 다운로드할 수 있는지 테스트합니다.
  8. 데이터-전송 스크립트를 만듭니다.
  9. 스크립트를 실행할 예약 작업을 만듭니다. Linux crontab 및 Windows 작업 스케줄러와 같은 도구를 사용할 수 있습니다.

  10. 프로덕션 환경의 각 서버에 대해 구성된 커스텀 이미지를 만듭니다. 각 이미지는 온프레미스 이미지와 동일하게 구성되어야 합니다.

    데이터베이스 서버의 커스텀 이미지 구성의 일부로 Cloud Storage 버킷에서 인스턴스로 최신 백업을 자동 복사한 후 복원 프로세스를 호출할 시작 스크립트를 만듭니다.

  11. 인터넷 연결 웹 서비스를 가리키도록 Cloud DNS를 구성합니다.

  12. 이전에 구성한 커스텀 이미지를 사용하여 Google Cloud 네트워크에서 애플리케이션 서버를 만들 Deployment Manager 템플릿을 만듭니다. 이 템플릿에서 필요한 해당 방화벽 규칙도 설정해야 합니다.

커스텀 이미지의 애플리케이션 버전이 온프레미스와 동일하도록 프로세스를 구현해야 합니다. 표준 업그레이드 주기의 일부로 업그레이드를 커스텀 이미지에 통합하고, Deployment Manager 템플릿에 최신 커스텀 이미지가 사용되는지 확인하세요.

장애 조치 프로세스 및 다시 시작 후 작업

재해가 발생하면 Google Cloud에서 실행 중인 시스템으로 복구할 수 있습니다. 이렇게 하려면 생성된 Cloud Deployment Manager 템플릿을 사용해 복구 환경을 만들기 위한 복구 프로세스를 시작합니다. 복구 환경의 인스턴스가 프로덕션 트래픽을 수용할 준비가 되면 Google Cloud의 웹 서버를 가리키도록 DNS를 조정합니다.

일반적인 복구 순서는 다음과 같습니다.

  1. Deployment Manager 템플릿을 사용하여 Google Cloud에서 배포를 만듭니다.
  2. 백업 파일 복구를 위한 데이터베이스 시스템의 안내를 따라 Cloud Storage에 있는 최신 데이터베이스 백업을 Google Cloud에서 실행 중인 데이터베이스 서버에 적용합니다.
  3. Cloud Storage의 최신 트랜잭션 로그를 적용합니다.
  4. 복구된 환경에서 사용자 시나리오를 시뮬레이션하여 애플리케이션이 예상대로 작동하는지 테스트합니다.
  5. 테스트가 성공하면 Google Cloud의 웹 서버를 가리키도록 Cloud DNS를 구성합니다. 예를 들어 부하 분산기에서 사용되는 여러 웹 서버와 함께 Google Cloud 부하 분산기에서 사용되는 Anycast IP 주소를 사용할 수 있습니다.

다음 다이어그램은 복구된 환경을 보여줍니다.

프로덕션이 온프레미스일 때 복구를 위한 콜드 패턴의 구성

프로덕션 환경이 다시 온프레미스로 실행되고 환경에서 프로덕션 워크로드를 지원할 수 있으면 Google Cloud 복구 환경으로 장애 조치를 위해 따른 단계를 반대로 수행합니다. 프로덕션 환경으로 돌아가기 위한 일반적인 시퀀스는 다음과 같습니다.

  1. Google Cloud에서 실행 중인 데이터베이스를 백업합니다.
  2. 프로덕션 환경에 백업 파일을 복사합니다.
  3. 프로덕션 데이터베이스 시스템에 백업 파일을 적용합니다.
  4. Google Cloud의 애플리케이션으로의 연결을 방지합니다. 예를 들어 전역 부하 분산기로의 연결을 방지합니다. 이 시점부터 프로덕션 환경 복원이 마칠 때까지 애플리케이션을 사용할 수 없습니다.
  5. 트랜잭션 로그 파일을 프로덕션 환경에 복사하고 데이터베이스 서버에 적용합니다.
  6. 온프레미스 웹 서비스를 가리키도록 Cloud DNS를 구성합니다.
  7. Cloud Storage에 데이터를 복사하기 위해 준비했던 프로세스가 예상대로 작동하는지 확인합니다.
  8. 배포를 삭제합니다.

웜 대기: Google Cloud로 복구

웜 패턴은 보통 HA를 완전히 구성하지 않고도 RTO 및 RPO 값을 가능한 한 작게 유지하기 위해 구현됩니다. RTO 및 RPO 값이 작을수록 두 환경에서 나오는 트래픽을 지원할 수 있는 완전한 중복 환경에 접근할 때 비용이 올라갑니다. 따라서 DR 시나리오에 대해 웜 패턴을 구현하면 예산과 가용성 간에 적절한 균형을 맞출 수 있습니다.

이 방법의 예시는 자체 관리형 VPN 솔루션으로 구성된 Cloud Interconnect를 사용하여 Google Cloud에 대한 연결을 제공하는 것입니다. 다계층 애플리케이션은 Google Cloud에서 최소한의 복구 모음을 사용해 온프레미스로 실행됩니다. 복구 모음은 Google Cloud의 운영 데이터베이스 서버 인스턴스로 구성됩니다. 이 인스턴스는 항상 실행되어야만 비동기 또는 일부 동기 복제 기술을 통해 복제된 트랜잭션을 수신할 수 있습니다. 비용을 줄이기 위해 데이터베이스 서비스를 실행할 수 있는 가장 작은 머신 유형에서 데이터베이스를 실행할 수 있습니다. 오래 실행되는 인스턴스를 사용할 수 있기 때문에 지속 사용 할인이 적용됩니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Cloud DNS
  • Cloud Interconnect
  • 자체 관리형 VPN 솔루션
  • Compute Engine
  • Deployment Manager

Compute Engine 스냅샷이 이전 상태로 롤백할 수 있는 백업을 만드는 방법을 제공합니다. 프로덕션 웹과 애플리케이션 서버에 업데이트된 웹페이지와 애플리케이션 바이너리에 자주 작성되기 때문에 스냅샷이 이 예시에 사용됩니다. 이 업데이트는 참조 웹 서버와 Google Cloud의 애플리케이션 서버 인스턴스에 주기적으로 복제됩니다. 참조 서버는 프로덕션 트래픽을 받아들이지 않고 스냅샷을 만드는 데 사용됩니다.

다음 다이어그램은 이 접근 방식을 구현하는 아키텍처를 보여 줍니다. 다이어그램에 복제 대상은 나와 있지 않습니다.

프로덕션이 온프레미스일 때 웜 패턴의 아키텍처

다음 단계는 환경을 구성하는 방법에 대한 간략한 개요입니다.

  1. VPC 네트워크를 만듭니다.
  2. 온프레미스 네트워크와 Google Cloud 네트워크 간에 연결을 구성합니다.
  3. 온프레미스 서버를 Google Cloud VM 인스턴스에 복제합니다. 한 가지 옵션은 파트너 솔루션을 사용하는 것입니다. 상황에 따라 사용하는 방법이 다릅니다.
  4. Google Cloud에서 온프레미스 데이터베이스 서버와 구성이 동일한 데이터베이스 서버의 커스텀 이미지를 만듭니다.
  5. 웹 서버와 애플리케이션 서버 인스턴스의 스냅샷을 만듭니다.
  6. 이전에 만든 커스텀 이미지를 사용하여 Google Cloud에서 데이터베이스 인스턴스를 시작합니다. 온프레미스 프로덕션 데이터베이스에서 복제된 데이터를 허용할 수 있는 가장 작은 머신 유형을 사용합니다.
  7. 데이터베이스와 트랜잭션 로그에 대한 Google Cloud 데이터베이스 인스턴스에 영구 디스크를 연결합니다.
  8. 데이터베이스 소프트웨어의 안내를 따라 온프레미스 데이터베이스 서버와 Google Cloud에 있는 데이터베이스 서버 간에 복제를 구성합니다.
  9. 데이터베이스 인스턴스에 연결된 영구 디스크에서 자동 삭제 플래그를 no-auto-delete로 설정합니다.
  10. Google Cloud에 있는 데이터베이스 인스턴스의 영구 디스크에 대한 일반 스냅샷을 만들도록 예약된 작업을 구성합니다.
  11. 필요에 따라 웹 서버와 애플리케이션 서버의 용량을 보장하기 위해 예약을 만듭니다.
  12. 스냅샷에서 인스턴스를 만들고 영구 디스크의 스냅샷을 촬영하는 프로세스를 테스트합니다.
  13. 이전에 만든 스냅샷을 사용하여 웹 서버와 애플리케이션 서버의 인스턴스를 만듭니다.
  14. 해당 온프레미스 서버가 업데이트될 때마다 웹 애플리케이션과 애플리케이션 서버에 업데이트를 복사하는 스크립트를 만듭니다. 스크립트를 작성하여 업데이트된 서버의 스냅샷을 만듭니다.
  15. 온프레미스에서 인터넷 연결 웹 서비스를 가리키도록 Cloud DNS를 구성합니다.

장애 조치 프로세스 및 다시 시작 후 작업

장애 조치를 관리하려면 일반적으로 모니터링 및 알림 시스템을 사용해 자동화된 장애 조치 프로세스를 호출합니다. 온프레미스 애플리케이션에서 장애 조치가 필요할 경우 프로덕션 트래픽을 받아들일 수 있도록 Google Cloud에서 데이터베이스 시스템을 구성합니다. 웹 및 애플리케이션 서버의 인스턴스도 시작합니다.

다음 다이어그램은 Google Cloud에서 프로덕션 워크로드를 지원할 수 있도록 Google Cloud로 장애 조치 후 구성을 보여 줍니다.

프로덕션이 온프레미스일 때 복구를 위한 웜 패턴의 구성

일반적인 복구 순서는 다음과 같습니다.

  1. 프로덕션 부하를 처리할 수 있도록 데이터베이스 인스턴스의 크기를 조절합니다.
  2. Google Cloud의 웹 서버와 애플리케이션 스냅샷을 사용하여 새로운 웹 서버와 애플리케이션 인스턴스를 만듭니다.
  3. 복구된 환경에서 사용자 시나리오를 시뮬레이션하여 애플리케이션이 예상대로 작동하는지 테스트합니다.
  4. 테스트가 성공하면 Google Cloud의 웹 서비스를 가리키도록 Cloud DNS를 구성합니다.

프로덕션 환경이 다시 온프레미스로 실행되고 프로덕션 워크로드를 지원할 수 있으면 Google Cloud 복구 환경으로 장애 조치를 수행한 단계를 역순으로 수행합니다. 프로덕션 환경으로 돌아가기 위한 일반적인 시퀀스는 다음과 같습니다.

  1. Google Cloud에서 실행 중인 데이터베이스를 백업합니다.
  2. 프로덕션 환경에 백업 파일을 복사합니다.
  3. 프로덕션 데이터베이스 시스템에 백업 파일을 적용합니다.
  4. Google Cloud의 애플리케이션으로의 연결을 방지합니다. 이렇게 하는 방법 중 하나는 방화벽 규칙을 수정하여 웹 서버로의 연결을 방지하는 것입니다. 이 시점부터 프로덕션 환경 복원이 마칠 때까지 애플리케이션을 사용할 수 없습니다.
  5. 트랜잭션 로그 파일을 프로덕션 환경에 복사하고 데이터베이스 서버에 적용합니다.
  6. 프로덕션 환경에서 사용자 시나리오를 시뮬레이션하여 예상대로 애플리케이션이 작동하는지 테스트합니다.
  7. 온프레미스 웹 서비스를 가리키도록 Cloud DNS를 구성합니다.
  8. Google Cloud에서 실행 중인 웹 서버와 애플리케이션 서버 인스턴스를 삭제합니다. 참조 서버는 실행 중인 상태로 둡니다.
  9. Google Cloud의 데이터베이스 서버 크기를 온프레미스 프로덕션 데이터베이스에서 복제된 데이터를 허용할 수 있는 최소 인스턴스 크기로 다시 조절합니다.
  10. 데이터베이스 소프트웨어의 안내를 따라 온프레미스 데이터베이스 서버와 Google Cloud에 있는 데이터베이스 서버 간에 복제를 구성합니다.

온프레미스 및 Google Cloud의 핫 HA

RTO 및 RPO 값이 작으면 프로덕션 환경과 Google Cloud에서 동시에 HA를 실행하여 이를 달성할 수 있습니다. 이 접근 방식에서는 온프레미스 및 Google Cloud가 모두 프로덕션 트래픽을 지원하므로 핫 패턴이 제공됩니다.

웜 패턴과의 주된 차이는 두 환경의 리소스가 프로덕션 모드에서 실행되고 프로덕션 트래픽을 지원한다는 것입니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • 관리형 인스턴스 그룹
  • Cloud Monitoring
  • Cloud Load Balancing

이 예제 아키텍처를 다이어그램으로 나타내면 다음과 같습니다. 이 아키텍처를 구현하면 재해 발생 시 최소한의 간섭을 요하는 DR 계획이 마련됩니다.

프로덕션이 온프레미스일 때 핫 패턴의 아키텍처

다음 단계는 환경을 구성하는 방법에 대한 간략한 개요입니다.

  1. VPC 네트워크를 만듭니다.
  2. 온프레미스 네트워크와 Google Cloud 네트워크 간에 연결을 구성합니다.
  3. Google Cloud에서 온프레미스 프로덕션 환경의 각 서버에 대해 구성된 커스텀 이미지를 만듭니다. 각 Google Cloud 이미지는 온프레미스와 구성이 동일해야 합니다.

  4. 데이터베이스 소프트웨어의 안내를 따라 온프레미스 데이터베이스 서버와 Google Cloud에 있는 데이터베이스 서버 간에 복제를 구성합니다.

    많은 데이터베이스 시스템에서는 복제 구성 시 쓰기 가능한 데이터베이스 인스턴스를 하나만 허용합니다. 따라서 데이터베이스 복제본 중 하나가 읽기 전용 서버로 작동하는지 확인해야 할 수도 있습니다.

  5. 애플리케이션 서버와 웹 서버에 대한 이미지를 사용하는 개별 인스턴스 템플릿을 만듭니다.

  6. 애플리케이션과 웹 서버에 대한 지역별 관리형 인스턴스 그룹을 구성합니다.

  7. Cloud Monitoring을 사용하여 상태 확인을 구성합니다.

  8. 이전에 구성한 지역별 관리형 인스턴스 그룹을 사용하여 부하 분산을 구성합니다.

  9. 예약된 작업을 구성하여 영구 디스크의 일반 스냅샷을 만듭니다.

  10. 온프레미스 환경과 Google Cloud 환경 사이에서 트래픽을 배포하도록 DNS 서비스를 구성합니다.

이 하이브리드 접근 방식을 사용할 경우, 두 프로덕션 환경에 가중치가 부여된 라우팅을 지원하는 DNS 서비스를 사용해야만 두 환경에서 동일한 애플리케이션을 지원할 수 있습니다.

환경의 일부에서만 발생할 수 있는 오류(부분적 오류)에 대해 시스템을 설계해야 합니다. 그러한 경우 트래픽을 다른 백업 환경의 동일한 서비스로 라우팅해야 합니다. 예를 들어 온프레미스 웹 서버를 사용할 수 없게 되면 해당 환경으로 DNS 라우팅을 중지할 수 있습니다. DNS 서비스에서 상태 확인을 지원할 경우 상태 확인을 통해 환경 중 하나의 웹 서버에 연결할 수 없다고 확인되면 이러한 조치가 자동으로 이루어집니다.

쓰기 가능한 인스턴스가 단 하나만 허용되는 데이터베이스 시스템을 사용하는 중에 원래 쓰기 가능한 데이터베이스와 읽기 복제본 간에 하트비트 연결이 끊겼을 때 데이터베이스 시스템에서 읽기 전용 복제본을 쓰기 가능한 기본 복제본으로 자동 승격하는 경우가 많습니다. 재해 후 개입해야 하는 경우에 대비해 데이터베이스 복제의 이러한 측면을 이해하고 있어야 합니다.

Google Cloud의 커스텀 VM 이미지의 애플리케이션 버전이 온프레미스와 동일하도록 프로세스를 구현해야 합니다. 표준 업그레이드 주기의 일부로 업그레이드를 커스텀 이미지에 통합하고, Deployment Manager 템플릿에 최신 커스텀 이미지가 사용되는지 확인하세요.

장애 조치 프로세스 및 다시 시작 후 작업

핫 시나리오에 대해 여기 설명한 구성에서는 재해가 두 환경 중 하나를 사용할 수 없음을 의미합니다. 웜 또는 콜드 시나리오에서처럼 두 번째 환경으로 데이터나 처리를 이동해야 하는 방식의 장애 조치 프로세스가 존재하지 않습니다. 그러나 다음과 같은 구성 변경사항을 처리해야 할 수도 있습니다.

  • DNS 서비스가 상태 확인 오류를 기반으로 트래픽의 경로를 자동으로 변경하지 않으면 여전히 작동 중인 시스템으로 트래픽을 전송하도록 수동으로 DNS 라우팅을 구성해야 합니다.
  • 데이터베이스 시스템이 오류 발생 시 읽기 전용 복제본을 쓰기 가능한 기본 복제본으로 자동 승격하지 않으면 개입하여 복제본이 승격되도록 해야 합니다.

두 번째 환경이 다시 실행되고 프로덕션 트래픽을 처리할 수 있으면 데이터베이스를 다시 동기화해야 합니다. 두 환경에서 프로덕션 워크로드가 지원되므로 어떤 데이터베이스가 기본인지 변경하기 위해 추가 조치를 취할 필요가 없습니다. 데이터베이스가 동기화된 후에는 DNS 설정을 조정하여 양쪽 환경에서 프로덕션 트래픽이 다시 배포되도록 허용할 수 있습니다.

Google Cloud의 프로덕션을 위한 DR 및 HA 아키텍처

Google Cloud에서 프로덕션 워크로드를 위해 애플리케이션 아키텍처를 설계할 때 플랫폼의 HA 기능이 DR 아키텍처에 직접적인 영향을 줍니다.

백업 및 DR 서비스는 클라우드 및 하이브리드 워크로드를 백업하고 복구하기 위한 중앙 집중식 클라우드 네이티브 솔루션입니다. 빠른 데이터 복구를 제공하고 중요한 비즈니스 운영을 신속하게 재개할 수 있도록 지원합니다.

Google Cloud의 애플리케이션 시나리오에 백업 및 DR 서비스를 사용하는 방법에 관한 자세한 내용은 다음을 참고하세요.

콜드: 복구 가능한 애플리케이션 서버

단일 활성 서버 인스턴스가 필요한 콜드 장애 조치 시나리오에서는 인스턴스 하나만 디스크에 작성해야 합니다. 온프레미스 환경에서는 활성/수동 클러스터를 사용하는 경우가 많습니다. Google Cloud에서 프로덕션 환경을 실행하는 경우 하나의 인스턴스만 실행하는 관리형 인스턴스 그룹에 VM을 만들 수 있습니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Compute Engine
  • 관리형 인스턴스 그룹

이 콜드 장애 조치 시나리오는 다음 예시 아키텍처 이미지를 참조하세요.

프로덕션이 Google Cloud에 있을 때 복구를 위한 콜드 패턴의 구성

다음 단계는 이 콜드 장애 조치 시나리오를 구성하는 방법을 간략하게 설명합니다.

  1. VPC 네트워크를 만듭니다.
  2. 애플리케이션 웹 서비스로 구성된 커스텀 VM 이미지를 만듭니다.
    1. 애플리케이션 서비스에서 처리되는 데이터가 연결된 영구 디스크에 작성되도록 VM을 구성합니다.
  3. 연결형 영구 디스크에서 스냅샷을 만듭니다.
  4. 웹 서버의 커스텀 VM 이미지를 참조하는 인스턴스 템플릿을 만듭니다.
    1. 최신 스냅샷에서 영구 디스크를 만들고 디스크를 마운트하도록 시작 스크립트를 구성합니다. 이 스크립트는 디스크의 최신 스냅샷을 가져올 수 있어야 합니다.
  5. 인스턴스 템플릿을 참조하는 대상 크기로 관리형 인스턴스 그룹과 상태 점검을 만듭니다.
  6. 예약 작업을 만들어 영구 디스크의 정기 스냅샷을 만듭니다.
  7. 외부 애플리케이션 부하 분산기를 구성합니다.
  8. 서비스 실패 시 알림을 보내도록 Cloud Monitoring을 사용하여 알림을 구성합니다.

이 콜드 장애 조치 시나리오에서는 Google Cloud에서 제공되는 HA 기능을 활용합니다. VM이 실패하면 관리형 인스턴스 그룹에서 VM을 자동으로 다시 만들려고 시도합니다. 이 장애 조치 단계를 시작하지 않아도 됩니다. 외부 애플리케이션 부하 분산기에서는 대체 VM이 필요하더라고 애플리케이션 서버 앞에 동일한 IP 주소가 사용됩니다. 인스턴스 템플릿과 커스텀 이미지가 있기 때문에 대체 VM이 대체하는 인스턴스와 동일하게 구성됩니다.

RPO는 마지막 만든 스냅샷에 의해 결정됩니다. 스냅샷을 자주 만들수록 RPO 값이 작아집니다.

관리형 인스턴스 그룹에서 세부적인 HA를 제공합니다. 관리형 인스턴스 그룹은 애플리케이션 또는 VM 레벨에서 오류에 대처하는 방법을 제공합니다. 이러한 시나리오가 발생하더라도 수동으로 개입하지 않습니다. 대상 크기를 1로 설정하면 관리형 인스턴스 그룹에서 실행되고 트래픽을 처리하는 활성 인스턴스가 하나만 생깁니다.

영구 디스크는 영역별로 다르기 때문에 영역별 오류가 발생하면 스냅샷을 사용하여 디스크를 다시 만들어야 합니다. 또한 스냅샷은 여러 리전 간에 사용할 수 있으므로 동일한 리전으로 디스크를 복원하듯이 다른 리전으로 디스크를 복원할 수 있습니다.

드물지만 영역별 오류가 발생하면 다음 섹션에 설명된 대로 복구하도록 수동으로 조치를 취해야 합니다.

장애 조치 프로세스

VM이 실패하면 관리형 인스턴스 그룹에서 동일한 영역에 VM을 자동으로 다시 만들려고 시도합니다. 인스턴스 템플릿의 시작 스크립트가 최신 스냅샷에서 영구 디스크를 만들어 새 VM에 연결합니다.

그러나 영역 오류가 발생해도 크기가 1인 관리형 인스턴스 그룹은 복구되지 않습니다. 영역에 오류가 발생하면 서비스가 실패하고 다른 영역에 수동으로 인스턴스 그룹을 만들 때 Cloud Monitoring 알림 또는 기타 모니터링 플랫폼에 대응해야 합니다.

이 구성의 변형은 영역 영구 디스크 대신 리전 영구 디스크를 사용하는 것입니다. 이 접근 방식을 사용하면 스냅샷을 사용하여 영구 디스크를 복구 단계의 일부로 복원하지 않아도 됩니다. 그러나 이 방법으로 바꾸면 저장용량이 두 배 더 소모되고 이에 맞게 예산을 책정해야 합니다.

예산과 RTO 및 RPO 값에 따라 접근방식을 선택합니다.

웜: 정적 사이트 장애 조치

Compute Engine 인스턴스가 실패하면 Cloud Storage 기반 정적 사이트를 대기 상태로 설정해 서비스 중단을 완화할 수 있습니다. 이 패턴은 웹 애플리케이션이 대체로 정적인 경우에 적합합니다.

이 시나리오에서는 기본 애플리케이션이 Compute Engine 인스턴스에서 실행됩니다. 이러한 인스턴스가 관리형 인스턴스 그룹으로 그룹화되고, 인스턴스 그룹은 HTTP 부하 분산기의 백엔드 서비스로 작동합니다. HTTP 부하 분산기에서 부하 분산기 구성, 각 인스턴스 그룹의 구성, 각 인스턴스의 상태에 따라서 수신되는 트래픽을 인스턴스로 안내합니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

이 예시 아키텍처를 다이어그램으로 나타내면 다음과 같습니다.

프로덕션이 Google Cloud에 있을 때 정적 사이트로의 웜 장애 조치를 위한 아키텍처

다음 단계는 이 시나리오를 구성하는 방법에 대한 간략한 개요입니다.

  1. VPC 네트워크를 만듭니다.
  2. 애플리케이션 웹 서비스로 구성된 커스텀 이미지를 만듭니다.
  3. 웹 서버에 대한 이미지를 사용하는 인스턴스 템플릿을 만듭니다.
  4. 웹 서버에 대한 관리형 인스턴스 그룹을 구성합니다.
  5. Monitoring을 사용하여 상태 확인을 구성합니다.
  6. 이전에 구성한 관리형 인스턴스 그룹을 사용하여 부하 분산을 구성합니다.
  7. Cloud Storage 기반 정적 사이트를 만듭니다.

프로덕션 구성에서 Cloud DNS는 이 기본 애플리케이션을 가리키도록 구성되고, 대기 정적 사이트는 휴면 상태입니다. Compute Engine 애플리케이션의 작동이 중지되면 이 정적 사이트를 가리키도록 Cloud DNS를 구성하면 됩니다.

장애 조치 프로세스

애플리케이션 서버나 서버의 작동이 중지될 경우 복구 시퀀스는 정적 웹사이트를 가리키도록 Cloud DNS를 구성하는 것입니다. 다음 다이어그램은 복구 모드의 아키텍처를 보여줍니다.

프로덕션이 Google Cloud에 있을 때 정적 사이트로 장애 조치 후 구성

애플리케이션 Compute Engine 인스턴스가 다시 실행되고 프로덕션 작업 부하를 지원할 수 있으면 복구 단계를 반대로 수행합니다. 즉, 인스턴스를 향하는 부하 분산기를 가리키도록 Cloud DNS를 구성합니다.

또는 Persistent Disk 비동기 복제를 사용할 수 있습니다. 리전 간 활성-수동 DR을 위해 낮은 복구 지점 목표 (RPO)와 낮은 복구 시간 목표 (RTO)가 있는 블록 스토리지 복제를 제공합니다. 이 스토리지 옵션을 사용하면 워크로드 수준이 아닌 인프라 수준에서 Compute Engine 워크로드의 복제를 관리할 수 있습니다.

핫: HA 웹 애플리케이션

프로덕션 환경이 Google Cloud에서 실행 중일 때의 핫 패턴은 제대로 설계된 HA 배포를 설정하는 것입니다.

이 패턴은 다음과 같은 DR 구성 요소를 사용합니다.

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

이 예시 아키텍처를 다이어그램으로 나타내면 다음과 같습니다.

Google Cloud에 있을 때 핫 패턴의 아키텍처

이 시나리오에서는 Google Cloud에서 제공되는 HA 기능을 활용합니다. 재해 발생 시 장애 조치 단계가 자동으로 발생하므로, 장애 조치 단계를 시작하지 않아도 됩니다.

다이어그램에서 볼 수 있듯이 아키텍처에서 전역 부하 분산 및 Cloud SQL과 더불어 리전별 관리형 인스턴스 그룹이 사용됩니다. 여기 나와 있는 예시에서는 리전별 관리형 인스턴스 그룹이 사용되므로 인스턴스가 3개 영역에 걸쳐 배포됩니다.

이 접근 방식에서는 세부적인 HA를 얻을 수 있습니다. 리전별 관리형 인스턴스 그룹의 경우 애플리케이션, 인스턴스 또는 영역 레벨에서 오류에 대응하는 메커니즘을 제공하며, 이러한 시나리오가 발생하더라도 수동으로 개입할 필요가 없습니다.

애플리케이션 레벨 복구를 처리하려면 관리형 인스턴스 그룹을 설정하는 과정의 일환으로 해당 그룹의 인스턴스에서 서비스가 제대로 실행되고 있는지 확인하는 HTTP 상태 확인을 구성합니다. 상태 확인을 통해 서비스가 인스턴스에서 실패했음이 확인되면 그룹에서 해당 인스턴스를 자동으로 다시 만듭니다.

Google Cloud에서 확장 가능하고 복원력이 우수한 애플리케이션을 빌드하는 방법에 관한 자세한 내용은 확장 가능하고 복원력이 우수한 앱 패턴 을 참고하세요.

다음 단계