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

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

시리즈는 다음과 같이 구성됩니다.

소개

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

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

일괄 처리 작업 부하

일괄 처리 작업 부하는 주요 업무에 핵심이 되지 않기 때문에 가동시간을 극대화하기 위해 HA 아키텍처를 설계하는 비용을 발생시킬 필요가 없습니다. 일반적으로 일괄 처리 작업 부하는 중단을 해결할 수 있습니다. 이러한 유형의 작업 부하는 선점형 VM 인스턴스 같은 비용 효율적인 제품을 활용할 수 있습니다. 선점형 VM 인스턴스는 일반 인스턴스보다 훨씬 더 낮은 가격으로 만들고 실행할 수 있습니다. 하지만 다른 작업 때문에 리소스에 액세스해야 하는 경우 Compute Engine에서 인스턴스를 종료(선점)할 수 있으며, 실행 후 24시간 안에 종료됩니다.

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

전자 상거래 사이트

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

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

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

동영상 스트리밍

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

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

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

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

콜드 패턴: GCP로 복구

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

이 섹션에서는 이 패턴의 예를 살펴봅니다. 이 예시에서 Cloud Interconnect는 GCP에 연결할 수 있도록 Cloud VPN으로 구성됩니다. 데이터는 프로덕션 환경의 일부로 Cloud Storage에 복사됩니다.

DR 구성요소:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

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

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

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

  1. VPC 네트워크를 만듭니다.
  2. 온프레미스 네트워크와 GCP 네트워크 간에 연결을 구성합니다.
  3. 데이터 백업을 위한 타겟으로 Cloud Storage 버킷을 만듭니다.
  4. 전용 서비스 계정을 위한 서비스 계정 키를 생성합니다. 이 파일은 사용자 인증 정보를 자동화된 스크립트에 전달하는 데 사용됩니다.
  5. 데이터베이스 백업을 업로드하는 스크립트를 실행할 온프레미스 머신에 서비스 계정 키를 복사합니다. 이는 데이터베이스 서버일 수 있지만 보안 정책으로 인해 데이터베이스 서버에 추가 소프트웨어를 설치하지 못할 수도 있습니다.

  6. IAM 정책을 만들어 버킷과 버킷 객체에 액세스할 수 있는 사람을 제한합니다. 이 목적을 위해 특수하게 만든 서비스 계정을 포함합니다. 또한 연산자 또는 시스템 관리자에 대한 정책에 사용자 계정 또는 그룹을 추가하여 이 모든 ID에 관련 권한을 부여합니다. Cloud Storage에 액세스하기 위한 권한에 대한 자세한 내용은 gsutil 명령어에 대한 IAM 권한을 참조하세요.

  7. 타겟 버킷에서 파일을 업로드 및 다운로드할 수 있는지 테스트합니다.

  8. 데이터-전송 스크립트를 만듭니다.

  9. 스크립트를 실행할 예약 작업을 만듭니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

웜 대기: GCP로 복구

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

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

DR 구성요소:

  • Cloud DNS
  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Deployment Manager

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

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

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

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

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

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

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

다음 다이어그램은 GCP에서 프로덕션 작업 부하를 지원할 수 있도록 GCP로 장애 조치 후 구성을 보여 줍니다.

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

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

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

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

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

온프레미스 및 GCP 전체의 핫 HA

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

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

DR 구성요소:

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

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

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

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

  1. VPC 네트워크를 만듭니다.
  2. 온프레미스 네트워크와 GCP 네트워크 간에 연결을 구성합니다.
  3. GCP에서 온프레미스 프로덕션 환경의 각 서버에 대해 구성된 커스텀 이미지를 만듭니다. 각 GCP 이미지는 온프레미스와 구성이 동일해야 합니다.
  4. 데이터베이스 소프트웨어의 안내를 따라 온프레미스 데이터베이스 서버와 GCP에 있는 데이터베이스 서버 간에 복제를 구성합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GCP에서 프로덕션을 위한 DR 및 HA 아키텍처

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

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

단일 서버 인스턴스만 필요한 콜드 시나리오에서는 디스크에 하나의 인스턴스만 쓰면 됩니다. 온프레미스에서는 주로 활성/비활성 클러스터로 이와 같이 할 수 있습니다. 반대로 GCP에서 프로덕션 환경을 실행하는 경우, 서버 인스턴스가 관리형 인스턴스 그룹의 일부이고 해당 그룹이 내부 부하 분산 서비스의 백엔드 서비스로 사용됩니다.

DR 구성요소:

  • Compute Engine
  • GCP 내부 부하 분산

이 예제 아키텍처를 다이어그램으로 나타내면 다음과 같습니다. 보통 외부 클라이언트가 애플리케이션에 직접 연결되는 것이 아니라 애플리케이션 앞에 프록시나 웹 애플리케이션이 있기 때문에 클라이언트 연결은 다이어그램에 나와 있지 않습니다.

프로덕션이 GCP에 있을 때 콜드 패턴의 아키텍처

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

  1. VPC 네트워크를 만듭니다.
  2. 애플리케이션 서비스로 구성된 커스텀 이미지를 만듭니다. 이미지의 일부로 다음과 같이 구성합니다.

    1. 애플리케이션 서비스에서 처리되는 데이터가 연결형 영구 디스크에 작성되도록 서버를 구성합니다.
    2. 연결형 영구 디스크에서 스냅샷을 만듭니다.
    3. 최신 스냅샷에서 영구 디스크를 만들고 디스크를 마운트하도록 시작 스크립트를 구성합니다. 이 스크립트는 디스크의 최신 스냅샷을 가져올 수 있어야 합니다.
  3. 이미지를 사용하는 인스턴스 템플릿을 만듭니다.

  4. 이전에 만든 인스턴스 템플릿을 사용하여 타겟 크기 1로 지역별 관리형 인스턴스 그룹을 구성합니다.

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

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

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

이 시나리오에서는 GCP에서 제공되는 HA 기능 중 일부를 활용합니다. 재해 발생 시 장애 조치 단계가 자동으로 발생하므로, 장애 조치 단계를 시작하지 않아도 됩니다. 내부 부하 분산기에서는 대체 인스턴스가 필요하더라도 애플리케이션 서버를 향하도록 하는 데 동일한 IP 주소가 사용됩니다. 인스턴스 템플릿과 커스텀 이미지가 있기 때문에 대체 인스턴스가 대체하는 인스턴스와 똑같이 구성됩니다.

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

지역별 관리형 인스턴스 그룹에서 세부적인 HA를 제공합니다. 애플리케이션, 인스턴스 또는 영역 레벨에서 오류에 대응하는 메커니즘을 제공합니다. 이러한 시나리오가 발생하더라도 수동으로 개입할 필요가 없습니다. 대상 크기를 1로 설정하면 인스턴스가 항상 하나만 실행됩니다.

영구 디스크는 영역별로 다르기 때문에 영역별 오류가 발생할 경우 디스크를 다시 만들기 위해 스냅샷이 필요합니다. 스냅샷은 지역 전체에서도 제공되므로 동일한 지역으로 디스크를 복원하는 것만큼 쉽게 다른 지역으로 디스크를 복원할 수 있습니다.

장애 조치 프로세스

이 시나리오에서는 영역별 오류가 발생할 경우 지역별 인스턴스 그룹이 같은 지역의 다른 영역에서 대체 인스턴스를 실행합니다. 최신 스냅샷에서 새로운 영구 디스크가 만들어지고 새 인스턴스에 연결됩니다. 이 상태를 다이어그램으로 나타내면 다음과 같습니다.

프로덕션이 GCP에 있을 때 복구를 위한 콜드 패턴의 아키텍처

이 구성은 다음과 같이 변형될 수 있습니다.

  • 영역별 영구 디스크 대신 지역별 영구 디스크를 사용합니다. 이 접근 방식을 사용하면 스냅샷을 사용하여 영구 디스크를 복구 단계의 일부로 복원하지 않아도 됩니다. 그러나 이 방법으로 바꾸면 저장용량이 두 배 더 소모되고 이에 맞게 예산을 책정해야 합니다.
  • 지역별 관리형 인스턴스 그룹 대신 관리형 인스턴스 그룹을 사용하고, 실패한 인스턴스와 동일한 영역에서 시작된 대체 인스턴스에 영구 디스크를 연결합니다. 이 시나리오에서는 영구 디스크의 자동 삭제 설정을 no-auto-delete로 구성해야 합니다.

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

웜: 정적 사이트 장애 조치

Compute Engine 인스턴스가 실패하면 Cloud Storage 기반 정적 사이트를 대기 상태로 설정해 서비스 중단을 완화할 수 있습니다. 정적 사이트 사용은 웹 애플리케이션이 대체로 정적인 경우에 사용할 수 있는 옵션입니다. 이 시나리오에서는 기본 애플리케이션이 Compute Engine 인스턴스에서 실행됩니다. 이 인스턴스가 관리형 인스턴스 그룹으로 그룹화되고, 인스턴스 그룹이 HTTP 부하 분산기의 백엔드 서비스 역할을 합니다. HTTP 부하 분산기에서 부하 분산기 구성, 각 인스턴스 그룹의 구성, 각 인스턴스의 상태에 따라서 수신되는 트래픽을 인스턴스로 안내합니다.

DR 구성요소:

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

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

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

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

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

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

장애 조치 프로세스

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

프로덕션이 GCP에 있을 때 정적 사이트로 장애 조치 후 아키텍처

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

핫: HA 웹 애플리케이션

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

DR 구성요소:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

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

프로덕션이 GCP에 있을 때 핫 패턴의 아키텍처

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

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

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

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

GCP에서 HA 웹 애플리케이션을 구성하는 한 가지 방법에 대한 자세한 단계는 Scalable and resilient web application on GCP를 참조하세요.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...