재해 복구 계획 가이드

이 문서는 Google Cloud Platform(GCP)의 재해 복구(DR)를 설명하는 여러 파트로 구성된 시리즈 중 첫 번째 파트입니다. 이 파트는 DR 계획을 설계 및 구현하기 위해 알아야 할 사항인 DR 계획 프로세스에 대한 개요를 제공합니다. 후속 파트에서는 GCP에 대한 구현 사례를 통해 특정 재해 복구 활용 사례를 논의합니다.

시리즈는 다음 세 파트로 구성됩니다.

소개

서비스 중단 이벤트는 언제든 발생할 수 있습니다. 네트워크가 중단되거나, 최신 애플리케이션 푸시로 인해 심각한 버그가 발생하거나, 언젠가는 자연 재해와 맞서야 하는 경우도 있습니다. 사고가 발생하면 견고하고 타겟팅된, 철저한 테스트를 거친 재해 복구 계획의 중요성이 드러납니다.

잘 설계되고 테스트된 DR 계획을 통해 재해 발생 시 비즈니스 수익에 미치는 영향을 최소화할 수 있습니다. DR 요구 사항에 관계없이 Google Cloud Platform(GCP)은 사용자에게 적합한 솔루션을 빌드 또는 확장하는 데 사용할 수 있는 강력하고 유연하며 경제적인 제품 및 기능을 제공합니다.

재해 복구 계획 기초

DR은 비즈니스 연속성 계획의 하위 집합입니다. DR 계획은 두 가지 주요 측정항목을 정의하는 비즈니스 영향 분석으로 시작됩니다.

  • 애플리케이션이 오프라인 상태일 수 있는 최대 허용 기간인 복구 시간 목표(RTO)입니다. 이 값은 일반적으로 더 큰 서비스수준계약(SLA)의 일부로 정의됩니다.
  • 복구 지점 목표(RPO)는 주요 문제로 인해 애플리케이션에서 데이터가 손실될 수 있는 최대 허용 기간입니다. 이 측정항목은 데이터가 사용되는 방식에 따라 달라집니다. 예를 들어, 자주 수정되는 사용자 데이터의 RPO는 몇 분일 수 있습니다. 반면 중요도가 낮고 자주 수정되지 않는 데이터의 RPO가 몇 시간일 수 있습니다. 이 측정항목은 기간만 설명하고 손실된 데이터의 양이나 품질은 취급하지 않습니다.

일반적으로 RTO 및 RPO 값이 작을수록(즉, 애플리케이션이 중단으로부터 더 빠르게 복구되어야 할수록) 애플리케이션의 실행 비용이 증가합니다. 다음 그래프는 RTO/RPO에 대한 비용의 비율을 보여줍니다.

Graph showing that small RTO/RPO maps to high cost.

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는 일반적으로 정상 기간보다 높은 기간 동안 합의된 수준의 운영 성능(대개 가동시간)을 보장하도록 지원합니다. GCP에서 프로덕션 워크로드를 실행할 때 GCP를 사용하여 한 지역에서 문제가 발생할 경우, 애플리케이션의 가용성이 저하되더라도 계속 서비스를 제공할 수 있습니다. 기본적으로 이 애플리케이션은 DR 계획을 실행합니다.

GCP를 사용하는 이유

GCP는 전제에서 RTO 및 RPO 요구사항을 충족하는 것에 비해 RTO 및 RPO와 관련된 비용을 크게 절감할 수 있습니다. 예를 들어, 기존의 DR 계획에서는 다음과 같은 다양한 요구 사항을 고려해야 합니다.

  • 용량: 필요에 따라 확장할 수 있는 충분한 리소스를 확보합니다.
  • 보안: 물리적 보안을 제공하여 자산을 보호합니다.
  • 네트워크 인프라: 방화벽과 부하 분산기와 같은 소프트웨어 구성요소를 포함합니다.
  • 지원: 숙련된 기술자가 유지관리를 수행하고 문제를 해결할 수 있도록 합니다.
  • 대역폭: 최대 부하에 적합한 대역폭을 구상합니다.
  • 시설: 장비 및 전원을 포함한 물리적인 인프라를 확보합니다.

GCP는 세계적 수준의 프로덕션 플랫폼에서 고도로 관리되는 솔루션을 제공함으로써 이러한 복잡한 요소의 대부분 또는 전부를 우회하여 해당 프로세스에서 많은 비즈니스 비용을 제거할 수 있도록 지원합니다. 또한 GCP는 관리 단순성에 초점을 맞추고 있으므로 복잡한 애플리케이션 관리 비용도 절감됩니다.

GCP는 DR 계획과 관련된 다음과 같은 몇 가지 기능을 제공합니다.

  • 글로벌 네트워크. Google은 세계에서 가장 크고 진보화된 컴퓨터 네트워크 중 하나를 보유하고 있습니다. 수천 킬로미터 길이의 광섬유 케이블로 연결된 Google 백본 네트워크는 소프트웨어로 정의된 고급 네트워킹을 사용하며, 빠른 속도, 일관된 성능, 확장성을 제공하는 에지 캐싱 서비스를 지원합니다.
  • 중복화. 전 세계의 여러 상호 접속 지점(PoP)은 강력한 중복성을 의미합니다. 데이터는 여러 위치에 있는 저장 장치 간에 자동으로 미러링됩니다.
  • 확장성. GCP는 트래픽이 급증하더라도 다른 Google 제품(예: Google 검색 및 Gmail)과 마찬가지로 확장될 수 있도록 설계되었습니다. App Engine, Compute Engine 자동 확장 처리, Cloud Datastore와 같은 관리형 서비스는 필요에 따라 애플리케이션을 확장 또는 축소할 수 있는 자동 확장 기능을 제공합니다.
  • 보안. Google 보안 모델은 15년 이상의 노하우를 바탕으로 Gmail 및 G Suite와 같은 Google 애플리케이션에서 고객을 보호하는 데 유용합니다. 또한 Google의 사이트 안정성 엔지니어링팀은 고가용성을 보장하고 플랫폼 리소스 남용을 방지합니다.
  • 규정 준수. Google에서는 GCP가 보안, 개인 정보 보호, 규정 준수 규제와 권장사항에 부합하는지 확인하기 위해 정기적으로 독립적인 제3자 감사를 수행합니다. GCP는 ISO 27001, SOC 2/3, PCI DSS 3.0과 같은 인증을 준수합니다.

DR 패턴

DR 패턴은 콜드, 웜, 핫으로 간주됩니다. 이러한 패턴은 문제가 발생했을 때 시스템이 얼마나 빨리 복구될 수 있는지를 나타냅니다. 예를 들어 운전해서 자동차 타이어에 구멍을 낸다면 어떻게 할 것인가로 유추할 수 있습니다.

3 photos of car flat-tire scenarios: no spare; a spare with tools; a run-flat tire.

펑크 난 타이어를 취급하는 방법은 준비 상태에 따라 다릅니다.

  • 콜드: 스페어 타이어가 없으므로 다른 사람에게 전화를 걸어 새 타이어를 가지고 오라고 부탁하고 교체해야 합니다. 수리를 위해 도움을 받을 때까지 여행이 중단됩니다.
  • 웜: 차에 스페어 타이어와 교체용 키트가 있고 이를 사용하여 운전할 수 있습니다. 그러나 문제를 해결하려면 여행을 중단해야 합니다.
  • 핫: 런 플랫 타이어가 있습니다. 속도를 약간 줄여야 할 수도 있지만, 여행에 즉각적인 영향은 없습니다. 문제를 해결해야 하지만, 타이어는 운전을 계속할 수 있을 정도로 구동합니다.

자세한 DR 계획 작성

이 섹션에서는 DR 계획을 생성하는 방법에 대한 권장 사항을 제공합니다.

복구 목표에 따라 설계

DR 계획을 설계할 때는 애플리케이션 및 데이터 복구 기술을 결합하여 더 큰 그림을 그려야 합니다. 이를 수행하는 일반적인 방법은 RTO 및 RPO 값과 이러한 값을 충족하기 위해 채택할 수 있는 DR 패턴을 살펴보는 것입니다. 예를 들어 과거의 규정 준수 중심의 데이터의 경우 데이터에 빠르게 액세스할 필요가 없으므로 RTO 값이 크고 콜드 DR 패턴이 적합했습니다. 그러나 온라인 서비스에서 중단이 발생하는 경우 가능한 한 빨리 고객 관련 애플리케이션과 데이터 부분을 모두 복구할 수 있어야 합니다. 그런 경우에는 핫 패턴이 더 적절할 것입니다. 일반적으로 업무상 중요하지 않은 이메일 알림 시스템은 핫 패턴의 대상일 수 있습니다.

GCP를 사용하여 일반적인 DR 시나리오를 해결하는 방법에 대한 지침은 애플리케이션 복구 시나리오를 검토합니다. 이러한 시나리오는 다양한 사용 사례에 대한 대상 DR 전략을 제공하고 GCP에 대한 각 구현 사례를 제공합니다.

엔드 투 엔드 복구를 위한 설계

단순히 데이터를 백업하거나 보관처리하는 것만으로는 충분하지 않습니다. DR 계획이 백업에서 복원, 정리까지 전체 복구 프로세스를 처리하는지 확인합니다. DR 데이터 및 복구에 대한 관련 문서에서 이를 논의합니다.

작업 구체화

재해 복구 계획을 실행할 때 각 단계가 무엇을 의미하는지 추측할 필요가 없습니다. DR 계획에 대한 각 작업을 하나 이상의 구체적이고 모호하지 않은 명령 또는 작업으로 구성합니다. 예를 들어 '복원 스크립트 실행'은 너무 일반적입니다. 반면 'Bash를 열고 /home/example/restore.sh 실행'은 정확하고 구체적입니다.

제어 조치 구현

제어 장치를 추가하여 재해 발생을 방지하고 문제가 발생하기 전에 이를 탐지합니다. 예를 들어 삭제 파이프 라인과 같은 데이터 파괴 흐름이 예기치 않은 스파이크 또는 기타 비정상적인 활동을 나타내는 경우 경고를 보내는 모니터를 추가합니다. 또한 이 모니터는 특정 삭제 임계값에 도달하면 파이프라인 프로세스를 종료하여 치명적인 상황을 방지할 수도 있습니다.

소프트웨어 준비

DR 계획의 일부는 의존하는 소프트웨어가 복구 이벤트에 대비할 수 있는지 확인하는 것입니다.

소프트웨어 설치 여부 확인

애플리케이션 소프트웨어를 소스 또는 미리 구성된 이미지에서 설치할 수 있는지 확인합니다. GCP에 배포할 소프트웨어에 대한 라이선스가 적절한지 확인합니다. 자세한 내용은 소프트웨어 공급업체에 문의하세요.

복구를 위한 지속적인 구축 설계

애플리케이션을 배포할 때 지속적인 배포(CD) 도구 집합은 필수 구성요소입니다. 복구 계획의 일부로, 복구 환경에서 아티팩트를 배포할 위치를 고려해야 합니다. CD 환경 및 아티팩트를 호스팅할 위치를 계획하고 재난 발생시 사용할 수 있고 작동할 수 있어야 합니다.

보안 및 규정 준수 관리 구현

DR 계획을 설계할 때 보안이 중요합니다. 프로덕션 환경에서 사용하는 것과 동일한 제어 기능을 복구된 환경에 적용해야 합니다. 규정 준수 규정은 복구된 환경에서도 적용됩니다.

DR 및 프로덕션 환경에 대해 동일하게 보안 구성

네트워크 제어가 소스 프로덕션 환경에서 사용하는 것과 동일한 분리 및 차단 기능을 제공하는지 확인합니다. Shared VPCGCP 방화벽을 구성하여 배포에 대한 중앙 집중식 네트워킹 및 보안 제어를 설정하고 서브넷을 구성하고 인바운드 및 아웃바운드 트래픽을 제어하는 방법을 살펴봅니다. 서비스 계정을 사용하여 GCP API에 액세스하는 애플리케이션에 대한 최소 권한을 구현하는 방법을 이해합니다. 방화벽 규칙의 일부로 서비스 계정을 사용해야 합니다.

본 프로덕션 환경에 있는 것과 동일한 액세스 권한을 사용자에게 부여해야 합니다. 다음 목록에는 환경 사이에서 권한을 동기화하는 방법에 대해 설명합니다.

  • 프로덕션 환경이 GCP인 경우, DR 환경에서 IAM 정책을 복제하는 것은 간단합니다. 인프라를 코드(IAC) 방법으로 사용하고 Cloud Deployment Manager와 같은 도구를 사용하여 Cloud IAM 정책을 프로덕션에 배포할 수 있습니다. 그런 다음 같은 도구를 사용하여 DR 환경 준비 프로세스의 일부로 DR 환경의 해당 리소스에 정책을 바인딩할 수 있습니다.

  • 프로덕션 환경이 온프레미스인 경우, 네트워크 관리자 및 감사자 역할과 같은 기능 역할을 적절한 IAM 역할이 있는 IAM 정책에 매핑합니다. IAM 문서에는 몇 가지 기능 역할 구성이 있습니다. 예를 들어, 네트워킹감사 로깅 기능 역할 생성에 대한 문서가 있습니다.

  • 제품에 적절한 사용 권한을 부여하려면 IAM 정책을 구성해야 합니다. 예를 들어, 특정 Cloud Storage 버킷에 대한 액세스를 제한하려 할 수 있습니다.

  • 프로덕션 환경이 다른 클라우드 공급자인 경우, 공급자의 IAM에 있는 권한을 GCP IAM 정책에 매핑합니다. 예를 들어 프로덕션 환경이 AWS인 경우, 자세한 내용은 GCP for AWS Professionals: Management를 참조하세요.

DR 보안 확인

DR 환경에 대한 사용 권한을 구성한 후에는 모든 것을 테스트해야 합니다. 테스트 환경을 만듭니다. Cloud Deployment Manager와 같은 도구를 사용하는 IAC 방법을 사용하여 IAM 정책을 테스트 환경에 배포합니다. 사용자에게 부여한 액세스 권한이 사용자가 온프레미스에서 부여한 것과 동일한 권한을 부여하는지 확인합니다.

사용자가 DR 환경에 로그인할 수 있는지 확인

마찬가지로 사용자가 DR 환경에 액세스할 수 있는지 확인하기 전에 재해가 발생할 때까지 기다리지 않습니다. 사용자, 개발자, 운영자, 데이터 과학자, 보안 관리자, 네트워크 관리자 및 조직의 다른 역할에 대한 적절한 액세스 권한을 부여했는지 확인합니다. 대체 ID 시스템을 사용하는 경우 계정이 Cloud ID 계정과 동기화되었는지 확인합니다. DR 환경은 잠시 동안 프로덕션 환경이 될 것이므로 DR 환경에 액세스해야 하는 사용자에게 로그인하여 인증 문제를 해결합니다. DR 환경에 로그인하는 사용자를 구현하는 일반 DR 테스트의 일부로 통합합니다.

시작하는 가상 머신(VM)에 대한 SSH 액세스 권한을 가진 사용자를 중앙에서 관리하려면 DR 환경을 구성하는 GCP 프로젝트에서 OS 로그인 기능을 사용 설정합니다.

사용자 교육

사용자는 로그인, VM 액세스 등과 같은 프로덕션 환경에서 작업을 수행하는 데 사용되는 GCP에서 작업을 수행하는 방법을 이해해야 합니다. 테스트 환경을 사용하여 사용자에게 시스템 보안을 보호할 수 있는 방법으로 이러한 작업을 수행하는 방법을 교육합니다.

DR 환경이 규정 준수 요구 사항을 충족하는지 확인

액세스 권한이 필요한 사용자만 DR 환경에 액세스할 수 있는지 확인합니다. PII 데이터가 수정되고 암호화되었는지 확인합니다. 프로덕션 환경에서 정기적인 침투 테스트를 수행하는 경우 해당 범위의 일부로 DR 환경을 포함시키고 DR 환경을 설정하여 정기적인 테스트를 수행해야 합니다.

DR 환경을 사용하는 동안 수집한 모든 로그가 프로덕션 환경의 로그 보관 파일에 백필됐는지 확인합니다. 마찬가지로 DR 환경의 일부로 Stackdriver를 통해 수집된 감사 로그를 주 로그 싱크 보관 파일에 내보낼 수 있는지 확인합니다. 내보내기 싱크 기능을 사용합니다. 애플리케이션 로그의 경우 온프레미스 로깅 및 모니터링 환경의 미러를 생성합니다. 프로덕션 환경이 다른 클라우드 공급자인 경우 해당 공급자의 로깅 및 모니터링을 동등한 GCP 서비스에 매핑합니다. 프로덕션 환경으로 입력을 포맷하는 프로세스가 있습니다.

일상적인 백업 루틴의 일부로 Cloud Storage 사용

백업을 저장하려면 Cloud Storage를 사용합니다. 백업이 포함된 버킷에 적절한 권한이 적용되었는지 확인합니다.

비밀을 적절하게 관리

GCP를 사용하여 키/비밀번호 관리 서비스(KMS)를 호스팅하여 애플리케이션 레벨 비밀번호와 키를 관리합니다. Cloud KMS 또는 HashiCorp Vault와 같은 타사 솔루션을 Cloud Spanner 또는 Cloud Storage와 같은 GCP 백엔드와 함께 사용할 수 있습니다.

복구된 데이터를 프로덕션 데이터처럼 처리

프로덕션 데이터에 적용하는 보안 제어가 복구된 데이터에도 적용되었는지 확인합니다. 즉, 동일한 권한, 암호화, 감사 요구 사항이 모두 적용되어야 합니다.

백업이 있는 위치와 데이터를 복원하도록 승인된 사용자를 파악합니다. 재해 복구 후 복구 프로세스가 감사 가능한지 확인합니다. 백업 데이터에 액세스할 수 있는 사용자와 복구를 수행한 사용자를 표시할 수 있는지 확인합니다.

재해 복구 계획이 제대로 작동하는지 확인

재해가 발생하면 모든 것이 의도대로 작동하는지 확인하여 계획을 세우는 것이 좋습니다.

둘 이상의 데이터 복구 경로 유지

재해가 발생할 경우 GCP 연결 방법을 사용할 수 없게 될 수도 있습니다. GCP에 액세스할 수 있는 다른 방법을 구현하여 데이터를 GCP로 전송할 수 있도록 합니다. 백업 경로가 작동하는지 정기적으로 테스트합니다.

정기적으로 계획 테스트

재해 복구 계획이 수립된 후에는 정기적으로 테스트하여 발생하는 문제를 기록하고 관련하여 계획을 조정합니다. GCP를 사용하면 최소한의 비용으로 복구 시나리오를 테스트할 수 있습니다. 테스트에 도움이 되도록 다음을 실행하는 것이 좋습니다.

  • 배포 관리자를 사용하여 인프라 프로비저닝을 자동화합니다. Cloud Deployment Manager를 사용하여 VM 인스턴스와 기타 GCP 인프라의 프로비저닝을 자동화할 수 있습니다. 온프레미스에서 프로덕션 환경을 실행 중인 경우, 오류가 감지되면 DR 프로세스를 시작하고 적절한 복구 작업을 트리거할 수 있는 모니터링 프로세스가 있는지 확인해야 합니다.
  • Stackdriver Logging 및 Stackdriver Monitoring을 사용하여 테스트를 모니터링하고 디버그합니다. GCP에는 API 호출을 통해 액세스할 수 있는 우수한 로깅 및 모니터링 도구가 있으므로, 측정항목에 대응하여 복구 시나리오 배포를 자동화할 수 있습니다. 테스트 설계 시 적절한 복구 작업을 트리거할 수 있는 적절한 모니터링 및 알림이 있는지 확인합니다.
  • 앞에서 언급한 테스트를 수행합니다.

    • 권한 및 사용자 액세스가 프로덕션 환경에서 작동하는 것처럼 DR 환경에서 작동하는지 테스트합니다.
    • DR 환경에서 침투 테스트를 수행합니다.
    • GCP에 대한 일반 액세스 경로가 작동하지 않는 테스트를 수행합니다.

다음 단계

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

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