이 문서는 Google Cloud의 재해 복구(DR)에 대해 설명하는 시리즈 중 1부입니다. 이 파트는 DR 계획을 설계 및 구현하기 위해 알아야 할 사항인 DR 계획 프로세스에 대한 개요를 제공합니다. 후속 파트에서는 Google Cloud에 대한 구현 사례를 통해 DR 사용 사례를 논의합니다.
이 시리즈는 다음 문서로 구성됩니다.
- 재해 복구 계획 가이드(본 문서)
- 재해 복구 구성 요소
- 데이터의 재해 복구 시나리오
- 애플리케이션의 재해 복구 시나리오
- 지역별로 제한된 워크로드의 재해 복구 설계
- 재해 복구 사용 사례: 지역별로 제한된 데이터 분석 애플리케이션
- 클라우드 인프라 서비스 중단의 재해 복구 설계
소개
서비스 중단 이벤트는 언제든 발생할 수 있습니다. 네트워크가 중단되거나, 최신 애플리케이션 푸시로 인해 심각한 버그가 발생하거나, 자연 재해를 직접 겪는 경우도 있습니다. 사고가 발생하면 견고하고 타겟팅되었으며 철저한 테스트를 거친 재해 복구 계획의 중요성이 드러납니다.
잘 설계되고 테스트된 DR 계획을 통해 재해 발생 시 비즈니스 수익에 미치는 영향을 최소화할 수 있습니다. DR 요구사항에 관계없이 Google Cloud는 사용자에게 적합한 솔루션을 빌드 또는 확장하는 데 사용할 수 있는 강력하고 유연하며 경제적인 제품 및 기능을 제공합니다.
DR 계획 기초
DR은 비즈니스 연속성 계획의 하위 집합입니다. DR 계획은 두 가지 주요 측정항목을 정의하는 비즈니스 영향 분석으로 시작됩니다.
- 복구 시간 목표(RTO)는 애플리케이션이 오프라인 상태로 있을 수 있는 최대 허용 시간을 말합니다. 이 값은 일반적으로 더 큰 서비스수준계약(SLA)의 일부로 정의됩니다.
- 복구 지점 목표(RPO)는 심각한 문제로 인해 애플리케이션으로부터 데이터 손실 상태가 지속되는 최대 허용 시간입니다. 이 측정항목은 데이터가 사용되는 방식에 따라 달라집니다. 예를 들어 자주 수정되는 사용자 데이터의 RPO는 몇 분에 불과할 수 있습니다. 반면 중요도가 낮고 자주 수정되지 않는 데이터의 RPO는 몇 시간일 수 있습니다. 이 측정항목은 기간만 설명하고 손실된 데이터의 양이나 품질은 취급하지 않습니다.
일반적으로 RTO 및 RPO 값이 작을수록(즉, 애플리케이션이 중단으로부터 더 빠르게 복구되어야 할수록) 애플리케이션의 실행 비용이 증가합니다. 다음 그래프는 RTO/RPO에 대한 비용의 비율을 보여줍니다.
RTO 및 RPO 값이 작을수록 복잡성이 커지기 때문에 이에 대한 관리 오버헤드는 유사한 곡선을 따릅니다. 고가용성 애플리케이션을 사용하려면 물리적으로 분리된 두 데이터 센터 간의 배포를 관리하고 복제 등을 관리해야 합니다.
RTO 및 RPO 값은 일반적으로 SLA의 핵심 측정 요소인 서비스 수준 목표(SLO)로 롤업됩니다. SLA와 SLO는 종종 함께 사용됩니다. SLA는 제공할 서비스, 지원 방법, 시간, 위치, 비용, 성과, 처벌 및 관련 당사자의 책임을 명시하는 전체 계약입니다. SLO는 가용성, 처리량, 빈도, 응답 시간 또는 품질과 같은 구체적이고 측정 가능한 SLA 특성입니다. SLA에는 많은 SLO가 포함될 수 있습니다. RTO와 RPO는 측정 가능하며 SLO로 간주되어야 합니다.
SLO 및 SLA에 대한 상세 설명은 Google 사이트 안정성 엔지니어링 페이지를 참조하세요.
고가용성(HA)에 대한 아키텍처를 계획하고 있을 수도 있습니다. HA가 DR과 완전히 겹치는 것은 아니지만 RTO 및 RPO 값을 고려할 때 HA를 고려해야 하는 경우가 많습니다. HA는 일반적인 정상 기간보다 더 높은 수준의 운영 성능(대개 업타임)을 보장하도록 지원합니다. Google Cloud에서 프로덕션 워크로드를 실행할 때 전역으로 분산된 시스템을 사용하여 한 리전에서 문제가 발생할 경우, 애플리케이션의 가용성이 저하되더라도 계속 서비스를 제공할 수 있습니다. 기본적으로 이 애플리케이션은 DR 계획을 실행합니다.
Google Cloud를 선택해야 하는 이유
Google Cloud는 온프레미스에서 RTO 및 RPO 요구사항을 충족할 때 RTO 및 RPO와 관련된 비용을 크게 줄일 수 있습니다. 예를 들어 기존의 DR 계획에서는 다음과 같은 다양한 요구사항을 고려해야 합니다.
- 용량: 필요에 따라 확장할 수 있는 충분한 리소스를 확보합니다.
- 보안: 물리적 보안을 제공하여 애셋을 보호합니다.
- 네트워크 인프라: 방화벽과 부하 분산기와 같은 소프트웨어 구성요소를 포함합니다.
- 지원: 숙련된 기술자가 유지관리를 수행하고 문제를 해결할 수 있도록 합니다.
- 대역폭: 최대 부하에 적합한 대역폭을 구상합니다.
- 시설: 장비 및 전원을 포함한 물리적인 인프라를 확보합니다.
Google Cloud는 세계적 수준의 프로덕션 플랫폼에서 고도로 관리되는 솔루션을 제공함으로써 이러한 복잡한 요소의 대부분 또는 전부를 우회하여 해당 프로세스에서 많은 비즈니스 비용을 제거할 수 있도록 지원합니다. 또한 Google Cloud는 관리 단순성에 초점을 맞추고 있으므로 복잡한 애플리케이션 관리 비용도 절감됩니다.
Google Cloud는 DR 계획과 관련된 다음과 같은 몇 가지 기능을 제공합니다.
- 글로벌 네트워크. Google은 세계에서 가장 큰 최첨단 컴퓨터 네트워크 중 하나를 보유하고 있습니다. Google 백본 네트워크는 고급 소프트웨어 정의 네트워킹 및 에지 캐싱 서비스를 사용하여 빠르고 일관성 있으며 확장 가능한 성능을 제공합니다.
- 중복화. 전 세계의 여러 상호 접속 지점(PoP)은 강력한 중복성을 의미합니다. 데이터는 여러 위치에 있는 스토리지 기기 간에 자동으로 미러링됩니다.
- 확장성. Google Cloud는 트래픽이 급증하더라도 다른 Google 제품(예: Google 검색 및 Gmail)과 마찬가지로 확장될 수 있도록 설계되었습니다. App Engine, Compute Engine 자동 확장 처리, Datastore와 같은 관리형 서비스는 필요에 따라 애플리케이션 크기를 늘리고 줄일 수 있도록 자동 확장 기능을 제공합니다.
- 보안. Google 보안 모델은 15년 이상의 경험을 바탕으로 Gmail 및 Google Workspace와 같은 Google 애플리케이션에서 고객을 안전하게 보호하는 데 중점을 둡니다. 또한 Google의 사이트 안정성 엔지니어링팀은 고가용성을 보장하고 플랫폼 리소스 남용을 방지합니다.
- 규정 준수. Google은 정기적으로 독립적인 제3자 감사를 받아 Google Cloud가 보안, 개인정보 보호, 규정 준수 규정, 권장사항을 지키는지 확인합니다. Google Cloud는 ISO 27001, SOC 2/3, PCI DSS 3.0과 같은 인증을 준수합니다.
DR 패턴
DR 패턴은 콜드, 웜, 핫으로 분류됩니다. 이러한 패턴은 문제가 발생했을 때 시스템이 얼마나 빨리 복구될 수 있는지를 나타냅니다. 예를 들어 운전을 하다가 자동차 타이어에 구멍이 난다면 어떻게 할 것인가로 유추해 볼 수 있습니다.
펑크 난 타이어를 취급하는 방법은 준비 상태에 따라 다릅니다.
- 콜드: 스페어 타이어가 없으므로 다른 사람에게 전화를 걸어 새 타이어를 가지고 오라고 부탁하고 교체해야 합니다. 수리를 위해 도움을 받을 때까지 이동이 중단됩니다.
- 웜: 차에 스페어 타이어와 교체용 키트가 있고 이를 사용하여 운전할 수 있습니다. 그러나 문제를 해결하려면 가던 길을 중단해야 합니다.
- 핫: 런플랫 타이어가 있습니다. 속도를 약간 줄여야 할 수도 있지만 이동하는 데 있어 즉각적인 영향은 없습니다. 결국에는 문제를 해결해야 하겠지만 타이어는 운전을 계속할 수 있을 정도로 구동합니다.
자세한 DR 계획 작성
이 섹션에서는 DR 계획을 생성하는 방법에 대한 권장사항을 제공합니다.
복구 목표에 따라 설계
DR 계획을 설계할 때는 애플리케이션 및 데이터 복구 기술을 결합하여 더 큰 그림을 그려야 합니다. 여기서 일반적인 방법은 RTO 및 RPO 값과 이러한 값을 충족하기 위해 채택할 수 있는 DR 패턴을 살펴보는 것입니다. 예를 들어 과거의 규정 준수 중심의 데이터의 경우 데이터에 빠르게 액세스할 필요가 없으므로 RTO 값이 크고 콜드 DR 패턴이 적합했습니다. 그러나 온라인 서비스에서 중단이 발생하는 경우 가능한 한 빨리 고객 관련 애플리케이션과 데이터 부분을 모두 복구할 수 있어야 합니다. 그런 경우에는 핫 패턴이 더 적절할 것입니다. 일반적으로 업무상 중요하지 않은 이메일 알림 시스템은 웜 패턴의 대상일 수 있습니다.
Google Cloud를 사용하여 일반적인 DR 시나리오를 해결하는 방법은 애플리케이션 복구 시나리오를 참조하세요. 이러한 시나리오는 다양한 사용 사례에 대한 타겟팅된 DR 전략을 제공하고 각 사례에 대한 Google Cloud 구현 예시를 제공합니다.
엔드 투 엔드 복구를 위한 설계
단순히 데이터를 백업하거나 보관처리하는 것만으로는 충분하지 않습니다. DR 계획이 백업에서 복원, 정리까지 전체 복구 프로세스를 처리하는지 확인합니다. DR 데이터 및 복구에 대한 관련 문서에서 이를 논의합니다.
태스크 구체화
재해 복구 계획을 실행할 때 각 단계의 의미를 추측하느라 시간을 끌 필요가 없습니다. DR 계획에 대한 각 태스크를 하나 이상의 구체적이고 모호하지 않은 명령 또는 작업으로 구성합니다. 예를 들어 '복원 스크립트 실행'은 너무 일반적입니다. 반면 'Bash를 열고 /home/example/restore.sh 실행'은 정확하고 구체적입니다.
제어 조치 구현
제어 장치를 추가하여 재해 발생을 방지하고 문제가 발생하기 전에 이를 탐지합니다. 예를 들어 삭제 파이프라인과 같은 데이터 파괴 흐름이 예기치 않은 스파이크 또는 기타 비정상적인 활동을 나타내는 경우 경고를 보내는 모니터를 추가합니다. 또한 이 모니터는 특정 삭제 임계값에 도달하면 파이프라인 프로세스를 종료하여 치명적인 상황을 방지할 수도 있습니다.
소프트웨어 준비
DR 계획의 일부는 자신이 의존하고 있는 소프트웨어가 복구 이벤트에 대비할 수 있는지 확인하는 것입니다.
소프트웨어 설치가 가능한지 확인
애플리케이션 소프트웨어를 소스 또는 사전 구성된 이미지로부터 설치할 수 있는지 확인합니다. Google Cloud에 배포할 소프트웨어의 라이선스가 적절한지 확인합니다. 소프트웨어에 대한 안내는 공급업체에 문의하세요.
필요한 Compute Engine 리소스를 복구 환경에서 사용할 수 있는지 확인합니다. 이를 위해서는 인스턴스를 사전 할당하거나 예약해야 합니다.
복구를 위한 지속적 배포 설계
애플리케이션을 배포할 때 지속적인 배포(CD) 도구 집합은 필수 구성요소입니다. 복구 계획의 일부로, 복구 환경에서 아티팩트를 배포할 위치를 고려해야 합니다. CD 환경 및 아티팩트를 호스팅할 위치를 계획하고 재해 발생시 사용할 수 있고 작동할 수 있어야 합니다.
보안 및 규정 준수 관리 구현
DR 계획을 설계할 때 보안이 중요합니다. 프로덕션 환경에서 사용하는 것과 동일한 제어 기능을 복구된 환경에 적용해야 합니다. 규정 준수 규정은 복구된 환경에서도 적용됩니다.
DR 및 프로덕션 환경에 대해 동일하게 보안 구성
네트워크 제어가 소스 프로덕션 환경에서 사용하는 것과 동일한 분리 및 차단 기능을 제공하는지 확인합니다. 공유 VPC 및 방화벽을 구성하여 배포에 대한 중앙 집중식 네트워킹 및 보안 제어를 설정하고 서브넷을 구성하고 인바운드 및 아웃바운드 트래픽을 제어하는 방법을 확인합니다. 서비스 계정을 사용하여 Google Cloud APIs에 액세스하는 애플리케이션에 대한 최소 권한을 구현하는 방법을 이해합니다. 방화벽 규칙의 일부로 서비스 계정을 사용해야 합니다.
본 프로덕션 환경에 있는 것과 동일한 액세스 권한을 사용자에게 부여해야 합니다. 다음 목록에는 환경 사이에서 권한을 동기화하는 방법에 대해 설명합니다.
프로덕션 환경이 Google Cloud인 경우 DR 환경에서 IAM 정책을 복제하는 것은 간단합니다. Terraform 같은 코드형 인프라(IaC) 도구를 사용하여 IAM 정책을 프로덕션에 배포할 수 있습니다. 그런 다음 같은 도구를 사용하여 DR 환경 준비 프로세스의 일부로 DR 환경의 해당 리소스에 정책을 결합할 수 있습니다.
프로덕션 환경이 온프레미스인 경우, 네트워크 관리자 및 감사자 역할과 같은 기능 역할을 적절한 IAM 역할이 있는 IAM 정책에 매핑합니다. IAM 문서에는 몇 가지 기능 역할 구성이 있습니다. 예를 들어 네트워킹 및 감사 로깅 기능 역할 생성에 대한 문서를 참조하세요.
제품에 적절한 사용 권한을 부여하려면 IAM 정책을 구성해야 합니다. 예를 들어 특정 Cloud Storage 버킷에 대한 액세스를 제한하려 할 수 있습니다.
프로덕션 환경이 다른 클라우드 제공업체인 경우 다른 제공업체의 IAM 정책에 있는 권한을 Google Cloud IAM 정책에 매핑합니다.
DR 보안 확인
DR 환경에 대한 사용 권한을 구성한 후에는 모든 것을 테스트해야 합니다. 테스트 환경을 만듭니다. Terraform과 같은 IaC 도구를 사용하여 테스트 환경에 Google Cloud 정책을 배포합니다. 사용자에게 부여한 권한이 사용자에게 온프레미스에서 부여한 권한과 일치하는지 확인합니다.
사용자가 DR 환경에 액세스할 수 있는지 확인
재해가 발생할 때까지 기다리지 말고 사용자가 DR 환경에 액세스할 수 있는지 확인해야 합니다. 사용자, 개발자, 운영자, 데이터 과학자, 보안 관리자, 네트워크 관리자 및 조직의 다른 역할에 대한 적절한 액세스 권한을 부여했는지 확인합니다. 대체 ID 시스템을 사용하는 경우 계정이 Cloud ID 계정과 동기화되었는지 확인합니다. DR 환경이 잠시 동안 프로덕션 환경으로 사용되므로 DR 환경에 액세스해야 하는 사용자들은 로그인하여 인증 문제를 해결하게 합니다. DR 환경에 로그인하는 사용자를 구현하는 일반 DR 테스트의 일부로 통합합니다.
시작하는 가상 머신(VM)에 대한 SSH 액세스 권한을 가진 사용자를 중앙에서 관리하려면 DR 환경을 구성하는 Google Cloud 프로젝트에서 OS 로그인 기능을 사용 설정합니다.
사용자 교육
사용자는 로그인, VM 액세스 등과 같은 프로덕션 환경에서 작업을 수행하는 데 사용되는 Google Cloud에서 작업을 수행하는 방법을 이해해야 합니다. 테스트 환경을 사용하여 사용자에게 시스템 보안을 보호할 수 있는 방법으로 이러한 작업을 수행하는 방법을 교육합니다.
DR 환경이 규정 준수 요구사항을 충족하는지 확인
액세스 권한이 필요한 사용자만 DR 환경에 액세스할 수 있는지 확인합니다. PII 데이터가 수정되고 암호화되었는지 확인합니다. 프로덕션 환경에서 정기적인 침투 테스트를 수행하는 경우 해당 범위의 일부로 DR 환경을 포함시키고 DR 환경을 설정하여 정기적인 테스트를 수행해야 합니다.
DR 환경을 사용하는 동안 수집한 모든 로그가 프로덕션 환경의 로그 보관 파일에 백필됐는지 확인합니다. 마찬가지로 DR 환경의 일부로 Cloud Logging을 통해 수집된 감사 로그를 주 로그 싱크 보관 파일에 내보낼 수 있는지 확인합니다. 내보내기 싱크 기능을 사용합니다. 애플리케이션 로그의 경우 온프레미스 로깅 및 모니터링 환경의 미러링 항목을 생성합니다. 프로덕션 환경이 다른 클라우드 제공업체인 경우 해당 제공업체의 로깅 및 모니터링을 동등한 Google Cloud 서비스에 매핑합니다. 프로덕션 환경으로 입력을 포맷하는 프로세스가 있습니다.
일상적인 백업 루틴의 일부로 Cloud Storage 사용
백업을 저장하려면 Cloud Storage를 사용합니다. 백업이 포함된 버킷에 적절한 사용 권한이 적용되었는지 확인합니다.
비밀을 적절하게 관리
Google Cloud를 사용하여 키/비밀번호 관리 서비스(KMS)를 호스팅하여 애플리케이션 수준의 보안 비밀과 키를 관리합니다. Cloud KMS 또는 HashiCorp Vault와 같은 타사 솔루션을 Spanner 또는 Cloud Storage와 같은 Google Cloud 백엔드와 함께 사용할 수 있습니다.
복구된 데이터를 프로덕션 데이터처럼 처리
프로덕션 데이터에 적용하는 보안 제어가 복구된 데이터에도 적용되었는지 확인합니다. 즉, 동일한 권한, 암호화, 감사 요구사항이 모두 적용되어야 합니다.
백업이 있는 위치와 데이터를 복원하도록 승인된 사용자를 파악합니다. 재해 복구 후 복구 프로세스가 감사 가능한지 확인합니다. 백업 데이터에 액세스할 수 있는 사용자와 복구를 수행한 사용자를 표시할 수 있는지 확인합니다.
재해 복구 계획이 제대로 작동하는지 확인
재해가 발생할 경우 DR 계획이 의도한 대로 작동하는지 확인하세요.
2개 이상의 데이터 복구 경로 유지
재해가 발생할 경우 Google Cloud 연결 방법을 사용할 수 없게 될 수도 있습니다. Google Cloud에 액세스할 수 있는 다른 방법을 구현하여 데이터를 Google Cloud로 전송할 수 있도록 합니다. 백업 경로가 작동하는지 정기적으로 테스트합니다.
정기적으로 계획 테스트
DR 계획을 만든 후에는 정기적으로 테스트하여 문제가 발생했는지 확인하고 그에 따라 계획을 조정합니다. Google Cloud를 사용하면 최소한의 비용으로 복구 시나리오를 테스트할 수 있습니다. 테스트에 도움이 되도록 다음을 구현하는 것이 좋습니다.
- 인프라 프로비저닝 자동화. Terraform과 같은 IaC 도구를 사용하여 VM 인스턴스 및 기타 Google Cloud 인프라의 프로비저닝을 자동화할 수 있습니다. 온프레미스에서 프로덕션 환경을 실행 중인 경우 오류가 감지되면 DR 프로세스를 시작하고 적절한 복구 작업을 트리거할 수 있는 모니터링 프로세스가 있는지 확인해야 합니다.
- Cloud Logging 및 Cloud Monitoring을 사용하여 테스트를 모니터링하고 디버그합니다. Google Cloud에는 API 호출을 통해 액세스할 수 있는 우수한 로깅 및 모니터링 도구가 있으므로, 측정항목에 대응하여 복구 시나리오 배포를 자동화할 수 있습니다. 테스트 설계 시 적절한 복구 작업을 트리거할 수 있는 적절한 모니터링 및 알림이 있는지 확인합니다.
앞에서 언급한 테스트를 수행합니다.
- 권한 및 사용자 액세스가 프로덕션 환경에서처럼 DR 환경에서도 작동하는지 테스트합니다.
- DR 환경에서 침투 테스트를 수행합니다.
- Google Cloud에 대한 일반 액세스 경로가 작동하지 않는 테스트를 수행합니다.
다음 단계
- Google Cloud 지역 및 리전에 대해 알아보기
- 이 DR 시리즈의 다른 문서 읽어보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기