Google Cloud 리전 간 마이그레이션: Google Cloud에서 복원력이 우수한 단일 리전 환경 설계

Last reviewed 2023-12-08 UTC

Google Cloud에서 복원력이 우수한 단일 리전 환경을 설계하는 데 도움을 주기 위한 문서입니다. 이 문서는 단일 리전 환경을 마이그레이션하려는 경우 또는 미래의 마이그레이션 기회를 평가하고 그 결과가 어떨지 살펴보고 싶은 경우에 유용합니다.

이 문서는 다음 시리즈의 일부입니다.

이 문서에서는 Google Cloud에서 복원력이 우수한 단일 리전 환경을 설계하는 방법에 대한 안내를 제공하고 다음 아키텍처 구성요소를 중점적으로 다룹니다.

이 문서의 지침은 단일 리전 환경을 설계하고 구현한다고 가정하고 작성되었습니다. 지금 단일 리전 환경을 사용하는 경우 향후 멀티 리전 환경으로 마이그레이션할 수 있습니다. 향후 영역 및 단일 리전 환경을 멀티 리전 환경으로 마이그레이션하고 발전시키려는 경우 Google Cloud 리전 간 마이그레이션: 시작하기를 참조하세요.

다양한 배포 원형 속성

Google Cloud는 전 세계 여러 리전에서 서비스를 제공합니다. 각 리전은 영역이라는 배포 영역으로 구성된 물리적으로 독립된 지리적 영역입니다. Google Cloud 리전 및 영역에 대한 자세한 내용은 지역 및 위치를 참조하세요.

Google Cloud 환경을 설계할 때는 신뢰성 및 운영 오버헤드 증가를 위해 다음 배포 원형 중에서 선택할 수 있습니다.

  • 영역 원형: Google Cloud 리소스를 리전 내 단일 영역에서 프로비저닝하고 사용 가능한 경우 영역 서비스를 사용합니다. 영역 서비스를 사용할 수 없으면 리전 서비스를 사용합니다.
  • 단일 리전 원형: 리전 내 여러 영역에서 Google Cloud 리소스를 프로비저닝하고 가능한 경우 리전 서비스를 사용합니다.
  • 멀티 리전 archetype: 여러 리전의 여러 영역에서 Google Cloud 리소스를 프로비저닝합니다. 영역별 리소스는 각 리전의 영역 하나 이상에서 프로비저닝됩니다.

앞의 배포 원형마다 서로 다른 신뢰성 속성이 있으며 이러한 원형을 사용하여 환경에서 필요한 신뢰성 보장을 제공할 수 있습니다. 예를 들어 멀티 리전 환경은 단일 리전 또는 영역 환경에 비해 리전 서비스 중단의 영향을 덜 받을 가능성이 더 높습니다. 각 아키텍처 원형의 신뢰성 속성에 대한 자세한 내용은 영역과 리전을 활용하여 신뢰성 확보 및 Google Cloud 인프라 신뢰성 가이드를 참조하세요.

이러한 배포 원형을 기반으로 환경을 설계, 구현, 운영하려면 각 원형의 비용과 복잡성 속성으로 인해 다른 수준의 노력이 필요합니다. 예를 들어 리전 또는 멀티 리전 환경에 비해 영역 환경을 저렴하고 쉽게 설계, 구현, 운영할 수 있습니다. 서로 다른 리전에 있는 워크로드, 데이터, 프로세스를 조정하기 위해 관리해야 하는 추가 오버헤드로 인해 영역 환경에 대한 노력과 비용이 낮아질 수 있습니다.

다음 표에는 리소스 분산, 신뢰성 속성, 각 아키텍처 원형의 복잡성이 요약되어 있습니다. 또한 각 항목을 기반으로 환경을 설계하고 구현하는 데 필요한 노력도 설명합니다.

아키텍처 원형 이름 리소스 분산 억제 대상 설계 복잡성
영역 환경 단일 영역에서 리소스 장애 단일 영역 내에서 조정 필요
단일 리전 환경 단일 리전의 여러 영역에서 리소스 장애, 영역 서비스 중단 단일 리전의 여러 영역에서 조정 필요
멀티 리전 환경 여러 리전의 여러 영역에서 리소스 장애, 영역 서비스 중단, 리전 서비스 중단, 멀티 리전 서비스 중단 여러 리전의 여러 영역에서 조정 필요

환경 배포 원형 선택

니즈에 가장 적합한 아키텍처 원형을 선택하려면 다음을 수행합니다.

  1. 대비하려는 장애 모델을 정의합니다.
  2. 배포 원형을 평가하여 니즈에 가장 적합한 원형을 결정합니다.

장애 모델 정의

장애 모델을 정의하려면 다음 질문을 고려하세요.

  • 환경의 어떤 구성요소에 장애 모델이 필요한가요? Google Cloud에 프로비저닝하거나 배포하는 모든 항목에 장애 모델을 적용할 수 있습니다. 장애 모델을 개별 항목에 적용하거나 전체 영역 또는 리전의 모든 리소스에 적용할 수 있음 워크로드, 데이터, 프로세스, 모든 Google Cloud 리소스와 같은 소중한 모든 항목에 장애 모델을 적용하는 것이 좋습니다.
  • 이러한 구성요소에 대한 고가용성, 비즈니스 연속성, 재해 복구 요구사항은 무엇인가요? 환경의 각 구성요소에는 해당 구성요소에 허용되는 서비스 수준과 자체 재해 복구 요구사항을 정의하는 자체 서비스 수준 목표(SLO)가 있을 수 있습니다. 예를 들어 Compute Engine SLA는 99.5%를 초과하는 월간 업타임을 달성해야 하는 경우 단일 리전의 여러 영역에서 인스턴스를 프로비저닝해야 함을 나타냅니다. 자세한 내용은 재해 복구 계획 가이드를 참조하세요.
  • 얼마나 많은 장애 모델을 정의해야 하나요? 일반적인 환경에서는 모든 구성요소가 같은 신뢰성 보장을 제공할 필요는 없습니다. 높은 업타임과 더 강력한 복원력을 보장하는 경우 일반적으로 더 많은 노력과 리소스를 투입해야 합니다. 장애 모델을 정의할 때는 모든 구성요소에 대해 단 하나만이 아니라 각 구성요소에 여러 장애 모델을 정의하는 접근 방법을 고려하는 것이 좋습니다. 예를 들어 비즈니스에 중요한 워크로드는 일반적으로 안정성이 더 높아야 하지만, 다른 덜 중요한 워크로드에는 안정성 보상 수준이 낮아질 수 있습니다.
  • 장애로부터 보호하려면 장애 모델에 얼마나 많은 리소스가 필요하나요? 정의한 장애 모델로부터 보호하기 위해 보호 메커니즘과 자동화 프로세스를 설계, 프로비저닝, 구성하는 사람들이 시간과 비용과 같은 리소스를 투입합니다. 정의한 각 장애 모델에 대해 보호해야 하는 리소스 수를 평가하는 것이 좋습니다.
  • 장애 발생 여부를 어떻게 감지하나요? 장애가 발생했거나 곧 발생할 것을 감지하는 능력은 중요합니다. 이를 통해 신속하게 완화, 복구, 조정 프로세스를 시작할 수 있기 때문입니다. 예를 들어 Google Cloud Observability를 구성하여 성능 저하에 대한 알림을 받을 수 있습니다.
  • 정의하려는 장애 모델을 테스트하려면 어떻게 해야 하나요? 장애 모델을 정의하면 모델을 대상으로 하는 장애로부터 효과적으로 보호하고 있는지 확인하기 위해 각 모델을 지속적으로 테스트하는 방법을 고려하는 것이 좋습니다. 예를 들어 환경에 장애를 삽입하거나, 장애를 감당할 수 있는 환경 역량을 평가하기 위해 카오스 엔지니어링을 채택할 수 있습니다.
  • 특정 장애 모델이 발생할 경우 미치는 영향은 무엇인가요? 장애가 비즈니스에 미칠 수 있는 영향을 이해하려면 각 장애 모델에 대해 모델이 대비하려고 하는 각 장애의 결과를 예측해야 합니다. 이러한 이해는 개발자와 프로세스에서 가장 중요한 구성요소를 먼저 처리하도록 우선순위와 복구 순서를 설정하는 데 유용합니다.
  • 정의한 장애 모델에서 장애가 얼마나 오래 지속될 것으로 예상하나요? 장애 기간은 완화 및 복구 계획에 큰 영향을 미칠 수 있습니다. 따라서 장애 모델을 정의할 때 장애가 지속될 수 있는 시간을 고려하는 것이 좋습니다. 장애가 지속될 수 있는 시간을 고려할 때는 장애를 식별하고 장애를 조정하며 장애가 생긴 리소스를 복원하는 데 걸리는 시간도 고려하세요.

장애 모델에 대한 추가 고려사항과 안정적인 재해 복구 계획을 설계하는 방법은 클라우드 인프라 서비스 중단의 재해 복구 설계를 참조하세요.

배포 원형 평가

방지하려는 장애 모델을 정의한 후에는 배포 archetype을 평가하여 니즈에 가장 적합한 것을 결정합니다. 배포 원형을 평가할 때는 다음 질문을 고려하세요.

  • 필요한 배포 원형은 몇 개인가요? 모든 환경에 맞는 아키텍처 원형 하나만 선택할 필요는 없습니다. 대신 정의된 장애 모델에 대비하는 데 필요한 안정성 보장에 따라 여러 배포 archetype을 선택하는 하이브리드 방식을 구현할 수 있습니다. 예를 들어 영역 환경이 필요한 모델과 리전 환경이 필요한 모델 두 개를 정의했다면 각 장애 모델로부터 보호하기 위해 별도의 배포 archetype을 선택해야 할 수 있습니다. 배포 원형을 여러 개 선택하는 경우 여러 환경 설계, 구현, 운영에 대한 복잡성 증가 가능성을 평가하는 것이 좋습니다.
  • 배로 원형을 기반으로 환경을 설계하고 구현하는 데 얼마나 많은 리소스가 필요한가요? 모든 종류의 환경을 설계하고 구현하려면 리소스와 노력이 필요합니다. 선택한 원형을 기반으로 각 환경을 설계 및 구현하기 위해 필요하다고 생각하는 리소스 수를 평가하는 것이 좋습니다. 필요한 리소스 수를 완벽하게 이해하면 각 아키텍처 archetype에서 제공하는 안정성 보장과, 해당 archetype의 설계, 구현, 운영 환경의 복잡성 비용 간의 균형을 맞출 수 있습니다.
  • 아키텍처 원형 하나를 기반으로 하는 환경을 다른 원형을 기반으로 하는 환경으로 마이그레이션하려고 하나요? 향후에 워크로드, 데이터, 프로세스를 Google Cloud 환경 하나에서 다른 Google Cloud 환경으로 마이그레이션할 수 있습니다. 예를 들어 영역 환경에서 리전 환경으로 마이그레이션할 수 있습니다.
  • 설계하고 개발 중인 환경이 비즈니스에 얼마나 중요하나요? 비즈니스에 중요한 환경에는 더 많은 신뢰성 보장이 필요할 수 있습니다. 예를 들어 업무상 중요한 워크로드, 데이터, 프로세스에 멀티 리전 환경을 설계 및 구현하고 덜 중요한 워크로드, 데이터, 프로세스에는 영역 또는 리전 환경을 설계하도록 선택할 수 있습니다.
  • 특정 아키텍처 원형에서 제공하는 기능이 특정 환경에 필요하나요? 각 아키텍처 원형에서 제공하는 신뢰성 보장 외에도 원형에서 서로 다른 확장성, 지리적 근접성, 지연 시간, 데이터 지역 보장을 제공합니다. 환경의 배포 원형을 선택할 때 이러한 보장을 고려하는 것이 좋습니다.

앞선 안내에 따라 정의한 장애 모드의 기술적 측면과 함께 규제, 지역, 주권 요구사항과 같은 비기능적 요구사항을 고려하는 것이 좋습니다. 이러한 요구사항으로 인해 사용할 수 있는 옵션이 제한될 수 있습니다. 예를 들어 특정 리전을 사용해야 하는 규제 기관 요구사항을 충족해야 하는 경우 단일 리전 환경이나 해당 리전 내 영역 환경을 설계하고 구현해야 합니다.

환경에 맞는 Google Cloud 리전 선택

단일 리전 환경을 설계할 때는 각 환경의 요구사항에 가장 적합한 리전을 결정해야 합니다. 다음 섹션에서는 선택 기준에 대한 두 가지 카테고리를 설명합니다.

  • 기능 기준. 이러한 기준은 특정 리전에서 제공하는 Google Cloud 제품, 특정 리전이 Google Cloud 외부의 사용자와 기타 환경에 대한 지연 시간과 지리적 근접성을 충족하는지 여부에 대한 기준입니다. 예를 들어 워크로드 및 데이터에 사용자 또는 Google Cloud 외부의 다른 환경에 대한 지연 시간 요구사항이 있는 경우, 지연 기간을 최소화하기 위해서 사용자 또는 다른 환경과 가장 가까운 리전을 선택해야 할 수 있습니다.
  • 비기능 기준. 이러한 기준은 특정 리전과 관련된 제품 가격, 탄소 발자국 요구사항, 비즈니스에 적용되는 필수 요구사항 및 규정에 대한 기준입니다. 예를 들어 은행 및 공공 부문과 같이 규제가 심한 시장에는 데이터 및 워크로드 지역, 클라우드 제공업체 인프라를 다른 고객과 공유하는 방식에 대한 매우 엄격하고 구체적인 요구사항이 있습니다.

지금 특정 Google Cloud 리전을 선택하면 나중에 다른 리전이나 멀티 리전 환경으로 마이그레이션할 수 있습니다. 향후에 다른 리전으로 마이그레이션하려는 경우 Google Cloud 리전 간 마이그레이션: 시작하기를 참조하세요.

기능 기준 평가

기능 기준을 평가하려면 다음 질문을 고려하세요.

  • 지리적 근접성 요구사항은 무엇인가요? Google Cloud 리전을 선택할 때 워크로드, 데이터, 프로세스를 온프레미스 환경과 같은 Google Cloud 외부의 사용자나 환경 근처에 배치해야 할 수 있습니다. 예를 들어 특정 지역에 집중된 사용자층을 타겟팅하는 경우 특정 지역에 가장 가까운 Google Cloud 리전을 선택하는 것이 좋습니다. 지리적 근접성 요구사항에 가장 적합한 Google Cloud 리전을 선택하면 환경에서 Google Cloud 외부의 사용자와 환경에서 들어오는 요청에 대한 짧은 지연 시간과 짧은 반응 시간을 보장할 수 있습니다. Google Cloud 지연 시간 대시보드와 같은 도구와 GCPing 및 Google Cloud 리전 선택 도구와 같은 비공식 도구를 사용하면 Google Cloud 리전의 지연 시간 특성을 대략적으로 파악할 수 있습니다. 하지만 지연 시간 속성이 요구사항, 워크로드, 데이터, 프로세스에 적합한지 평가하려면 포괄적인 평가를 수행하는 것이 좋습니다.
  • 사용하려는 리전에서 필요한 제품을 제공하고 있나요? 각 Google Cloud 리전에서 사용할 수 있는 제품과 환경을 설계하고 구현하는 데 필요한 서비스를 제공하는 리전을 평가하는 것이 좋습니다. 각 리전에서 사용할 수 있는 제품과 가용성 타임라인에 대한 자세한 내용은 Cloud 위치를 참조하세요. 또한 일부 제품은 사용 가능한 모든 리전에서 일부 기능을 제공하지 않을 수 있습니다. 예를 들어 Compute Engine에 사용 가능한 리전과 영역은 특정 Google Cloud 리전에서 특정 머신 유형을 제공합니다. 각 제품이 각 리전에서 제공하는 기능에 대한 자세한 내용은 제품 문서를 참조하세요.
  • 각 Google Cloud 리전에 필요한 리소스가 리전당 할당량 한도 이내인가요? Google Cloud는 할당량을 사용해서 사용 가능한 공유 Google Cloud 리소스의 양을 제한합니다. 일부 할당량은 전역이며 Google Cloud의 모든 위치에서 리소스 사용량에 적용되지만 다른 할당량은 리전 또는 영역별이며 특정 Google Cloud 리전의 리소스 사용량에 적용됩니다. 예를 들어 만들 수 있는 가상 머신 수와 같은 최대 Compute Engine 리소스 사용 할당량은 리전 할당량입니다. 할당량 및 할당량 증가 방법에 대한 자세한 내용은 할당량 작업을 참조하세요.

비기능적 기준 평가

비기능적 기준을 평가하려면 다음 질문을 고려하세요.

  • 낮은 탄소 발자국을 선호하나요? Google Cloud는 Google Cloud 리전의 지속 가능성과 Google Cloud의 무탄소 에너지에 지속적으로 투자하고 있으며 모든 클라우드 리전의 무탄소 에너지를 위해 노력하고 있습니다. Google Cloud 리전들의 탄소 발자국은 다릅니다. 각 Google Cloud 리전의 탄소 발자국과 무탄소 에너지를 위치 전략에 통합하는 방법에 대한 자세한 내용은 Google Cloud 리전의 무탄소 에너지를 참조하세요.
  • 환경에서 특정 규정을 충족해야 하나요? 정부, 국가, 초국가 기구는 은행 및 공공 부문과 같은 특정 시장 및 비즈니스 분야를 엄격하게 규제합니다. 이러한 규정은 워크로드, 데이터, 프로세스가 특정 지리적 리전에만 있도록 요구할 수 있습니다. 예를 들어 민감한 정보 및 클라우드에서 실행되는 워크로드에 대한 특정 수준의 제어와 투명성을 보장하기 위해 환경에서 데이터, 운영, 소프트웨어 주권 요구사항을 준수해야 할 수 있습니다. 환경에 Google Cloud 리전을 선택할 때 현재 및 예정된 규제 기관 요구사항을 평가하고 규제 기관 요구사항에 가장 적합한 Google Cloud 리전을 선택하는 것이 좋습니다.

단일 리전 환경 설계 및 빌드

단일 리전 환경을 설계하려면 다음을 수행합니다.

  1. Google Cloud에서 기반 구축
  2. 컴퓨팅 리소스를 프로비저닝하고 구성합니다.
  3. 데이터 스토리지 리소스를 프로비저닝하고 구성합니다.
  4. 데이터 분석 리소스를 프로비저닝하고 구성합니다.

환경을 설계할 때 다음과 같은 일반적인 설계 원칙을 고려하세요.

  • 리전별 리소스를 프로비저닝합니다. 다양한 Google Cloud 제품은 한 리전의 여러 영역에서 리소스를 프로비저닝할 수 있습니다. 가능하면 영역별 리소스 대신 리전별 리소스를 프로비저닝하는 것이 좋습니다. 이론적으로는 한 리전의 여러 영역에서 영역별 리소스를 프로비저닝하고 직접 관리하여 더 높은 신뢰성을 달성할 수 있습니다. 하지만 이 구성에서는 Google Cloud 서비스 기반이 되는 Google 인프라의 모든 신뢰성 기능을 최대한 활용하지 못합니다.
  • 장애 모델 가정에서 예상한 대로 환경이 작동하는지 확인합니다. 단일 리전 환경을 설계 및 구현할 때는, 프로덕션 환경의 일부로서 해당 환경을 승급하기 전에 고려 중인 장애 모델에 대비하기 위한 요구사항을 충족하는지 확인하는 것이 좋습니다. 예를 들어 영역 서비스 중단을 시뮬레이션하여 단일 리전 환경이 최소한의 중단으로 존속할 수 있는지 확인할 수 있습니다.

안정적인 단일 및 멀티 리전 환경을 설계하기 위한 보다 일반적인 설계 원칙과 Google이 리전 및 멀티 리전 서비스로 안정성을 더 높이는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단을 위한 재해 복구 설계: 일반적인 주제를 참조하세요.

Google Cloud에서 기반 구축

단일 리전 환경 기반을 빌드하려면 Google Cloud로 마이그레이션: 기반 빌드를 참조하세요. 이 문서의 안내는 워크로드, 데이터, 프로세스를 Google Cloud로 마이그레이션을 위한 기반 빌드를 목표로 하지만 단일 리전 환경 기반을 빌드하는 데도 적용될 수 있습니다. 먼저 해당 문서를 읽어보신 후 이 문서를 계속 읽는 것을 권합니다.

Google Cloud에서 기반을 빌드한 후에는 보안 제어 및 경계를 설계하고 구현합니다. 이러한 보안 조치는 워크로드, 데이터, 프로세스가 각각의 리전 내에 있도록 보장하는 데 도움이 됩니다. 또한 보안 조치는 버그, 잘못된 구성, 악의적인 공격으로 인해 리소스가 다른 리전에 유출되지 않도록 방지하는 데에도 도움이 됩니다.

컴퓨팅 리소스 프로비저닝 및 구성

단일 리전 환경 기반을 빌드한 후에는 컴퓨팅 리소스를 프로비저닝하고 구성합니다. 다음 섹션에서는 리전 배포를 지원하는 Google Cloud 컴퓨팅 제품을 설명합니다.

Compute Engine

Compute Engine은 Google Cloud의 Infrastructure as a Service로, Google의 글로벌 인프라를 사용하여 가상 머신과 관련 서비스를 고객에게 제공합니다.

Compute Engine 리소스는 영역별 리소스(예: 가상 머신 또는 영역 Persistent Disk), 리전별 리소스(예: 고정 외부 IP 주소) 또는 전역 리소스(예: Persistent Disk 스냅샷)입니다. Compute Engine에서 지원하는 영역별, 리전별, 전역 리소스에 대한 자세한 내용은 전역, 리전별, 영역별 리소스를 참조하세요.

물리적 리소스의 유연성과 리소스 관리를 개선하기 위해 Compute Engine은 물리적 리소스에서 영역을 분리합니다. 이 추상 및 내포된 의미에 대한 자세한 내용은 영역 및 클러스터를 참조하세요.

Compute Engine을 사용하는 환경의 안정성을 높이려면 다음을 고려해 보시기 바랍니다.

  • 리전 관리형 인스턴스 그룹(MIG). Compute Engine 가상 머신은 영역별 리소스이므로 영역 서비스 중단 시 사용 불가능합니다. 이 문제를 완화하기 위해 Compute Engine에서는 수요 및 리전 가용성에 따라 한 리전의 여러 영역에서 가상 머신을 자동으로 프로비저닝하는 리전 MIG를 만들 수 있습니다. 워크로드가 스테이트풀(Stateful)하면 리전 스테이트풀(Stateful) MIG를 만들어 스테이트풀(Stateful) 데이터와 구성을 보존할 수도 있습니다. 리전 MIG에서는 영역 장애를 시뮬레이션할 수 있습니다. 리전 MIG를 사용할 때의 영역 장애 시뮬레이션에 대한 자세한 내용은 리전 MIG의 영역 서비스 중단 시뮬레이션을 참조하세요. 리전 MIG와 다른 배포를 비교하는 방법은 워크로드에 맞는 Compute Engine 배포 전략 선택을 참조하세요.
  • 목표 분산 형태. 리전 MIG는 대상 배포 형태에 따라 가상 머신을 배포합니다. 가상 머신 배포가 한 리전의 두 영역 간의 장치 2개 이상에서 다르지 않도록 보장하려면 리전 MIG를 만들 때 EVEN 배포 형태를 선택하는 것이 좋습니다. 대상 배포 형태 간의 차이에 대한 자세한 내용은 형태 비교를 참조하세요.
  • 인스턴스 템플릿. 프로비저닝할 가상 머신을 정의하기 위해 MIG는 인스턴스 템플릿이라고 하는 전역 리소스 유형을 사용합니다. 인스턴스 템플릿이 전역 리소스이지만 영역별 또는 리전별 리소스를 참조할 수 있습니다. 인스턴스 템플릿을 만들 때 가능하면 영역별 리소스보다 리전별 리소스를 참조하는 것이 좋습니다. 영역별 리소스를 사용하는 경우 영역별 리소스 사용 영향을 평가하는 것이 좋습니다. 예를 들어 지정된 영역에서만 사용할 수 있는 Persistent Disk 볼륨을 참조하는 인스턴스 템플릿을 만드는 경우 다른 영역에서는 Persistent Disk 볼륨을 사용할 수 없으므로 다른 영역에서 해당 템플릿을 사용할 수 없습니다.
  • 부하 분산 및 확장 구성. Compute Engine은 Compute Engine 인스턴스 간의 트래픽 부하 분산을 지원하며 수요에 따라 자동으로 가상 머신을 추가하거나 MIG에서 삭제하는 자동 확장을 지원합니다. 환경의 신뢰성과 유연성을 높이고 자체 관리형 솔루션의 관리 부담을 방지하려면 부하 분산과 자동 확장을 구성하는 것이 좋습니다. Compute Engine에서 부하 분산과 자동 확장을 구성하는 방법에 대한 자세한 내용은 부하 분산 및 확장을 참조하세요.
  • 리소스 예약 구성. 필요할 때 환경에 필요한 리소스가 있도록 보장하려면 리소스 예약을 구성하여 영역 Compute Engine 리소스 용량을 확보하는 것이 좋습니다. 예를 들어 영역 서비스 중단이 발생하면 서비스 중단으로 인해 사용할 수 없는 용량을 상쇄하기 위해 다른 영역에서 가상 머신을 프로비저닝하여 필요한 용량을 제공해야 할 수 있습니다. 리소스 예약은 추가 가상 머신을 프로비저닝하는 데 사용할 수 있는 리소스를 보장합니다.
  • 영역 DNS 이름 사용. 리전 간 서비스 중단 위험이 완화되도록 영역 DNS 이름을 사용하여 사용자 환경에서 DNS 이름을 사용하는 가상 머신을 고유하게 식별하는 것이 좋습니다. Google Cloud는 기본적으로 Compute Engine 가상 머신에 영역 DNS 이름을 사용합니다. Compute Engine 내부 DNS 작동 방식에 대한 자세한 내용은 내부 DNS를 참조하세요. 향후 리전 간 마이그레이션을 용이하게 하고 구성을 더욱 유지보수 가능하게 하려면 나중에 변경할 수 있는 구성 매개변수로 영역 DNS 이름을 사용하는 것이 좋습니다.
  • 적절한 스토리지 옵션 선택. Compute Engine은 Persistent Disk 볼륨 및 로컬 솔리드 스테이트 드라이브(SSD)와 같은 가상 머신의 여러 스토리지 옵션을 지원합니다.
    • Persistent Disk 볼륨은 여러 물리적 디스크에 분산되어 있지만 가상 머신과는 독립된 위치에 있습니다. 영구 디스크는 영역 또는 리전 리소스일 수 있습니다. 영역 영구 디스크는 데이터를 단일 영역에 저장하는 반면 리전 영구 디스크는 데이터를 서로 다른 두 영역에서 복제합니다. 단일 리전 환경의 스토리지 옵션을 선택하는 경우 리전 영구 디스크를 선택하는 것이 좋습니다. 리전 영구 디스크는 영역 장애가 발생하면 장애 조치 옵션을 제공하기 때문입니다. 리전 영구 디스크를 사용할 때 영역 장애에 대처하는 방법에 대한 자세한 내용은 리전 Persistent Disk를 사용하는 고가용성 옵션 및 리전 Persistent Disk 장애 조치를 참조하세요.
    • 로컬 SSD는 처리량이 높지만 인스턴스가 중지되거나 삭제될 때까지만 데이터를 저장합니다. 따라서 로컬 SSD는 임시 데이터, 캐시, 다른 방법으로 재구성할 수 있는 데이터를 저장하는 데 적합합니다. 영구 디스크는 물리적 디스크와 같이 가상 머신에서 액세스할 수 있는 내구성이 우수한 스토리지 기기입니다.
  • 데이터 보호를 위한 메커니즘을 설계 및 구현. 단일 리전 환경을 설계할 때는 영역, 리전 또는 멀티 리전 장애, 악의적인 제3자의 고의적인 공격 등의 부정적인 이벤트가 있는 경우 데이터를 보호하는 자동화된 메커니즘을 사용하는 것이 좋습니다. Compute Engine은 데이터를 보호하기 위한 여러 가지 옵션을 제공합니다. 이러한 데이터 옵션 기능을 데이터 보호 프로세스를 설계 및 구현하기 위한 구성 요소로 사용할 수 있습니다.

GKE

GKE를 사용하면 Kubernetes에서 컨테이너화된 워크로드를 배포, 관리, 확장할 수 있습니다. GKE는 Compute Engine을 기반으로 빌드되므로 Compute Engine에 대한 이전 섹션의 권장사항이 GKE에도 부분적으로 적용됩니다.

GKE를 사용하는 환경의 신뢰성을 높이려면 다음 설계 포인트와 GKE 기능을 고려하세요.

  • 리전 GKE 클러스터를 사용하여 가용성 높이기. GKE는 필요한 클러스터 유형에 따라 클러스터에 다양한 가용성 유형을 지원합니다. GKE 클러스터에는 영역 또는 리전 컨트롤 플레인과 단일 영역이나 단일 리전 내 여러 영역에서 실행되는 노드가 있을 수 있습니다. 또한 클러스터 유형에 따라 서로 다른 서비스수준계약(SLA)이 제공됩니다. 환경 신뢰성을 높이려면 리전 클러스터를 선택하는 것이 좋습니다 GKE Autopilot 기능을 사용하는 경우 리전 클러스터만 프로비저닝할 수 있습니다.
  • 멀티 클러스터 환경 고려. 여러 GKE 클러스터를 배포하면 환경의 유연성과 가용성 속성이 증가하지만 복잡성도 증가합니다. 예를 들어 GKE 클러스터를 만들 때만 사용 설정할 수 있는 새로운 GKE 기능을 사용해야 하는 경우, 멀티 클러스터 환경에 새 GKE 클러스터를 추가한 후 클러스터에 워크로드를 배포하고 이전 클러스터를 폐기함으로써 다운타임을 방지하고 마이그레이션의 복잡성을 줄일 크수 있습니다. 멀티 클러스터 GKE 환경의 이점에 대한 자세한 내용은 멀티 클러스터 사용 사례를 참조하세요. Google Cloud는 복잡한 마이그레이션을 간소화하기 위해 GKE 클러스터 그룹, 해당 인프라, 이러힌 클러스터에 배포되는 워크로드를 관리하는 기능 집합인 Fleet 관리를 제공합니다.
  • Backup for GKE 설정. Backup for GKE는 소스 GKE 클러스터의 워크로드 구성과 볼륨을 백업하고 대상 GKE 클러스터에 복원하는 데 사용되는 리전별 서비스입니다. 워크로드 구성과 데이터가 손실되지 않도록 보호하려면 Backup for GKE를 사용 설정하고 구성하는 것이 좋습니다. 자세한 내용은 Backup for GKE 개요를 참조하세요.

Cloud Run

Cloud Run은 컨테이너화된 워크로드를 실행하기 위한 관리형 컴퓨팅 플랫폼입니다 Cloud Run은 서비스를 사용하여 워크로드를 실행할 수 있는 인프라를 제공합니다. Cloud Run 서비스는 리전별 리소스이며, 서비스는 리전에 있는 여러 영역 간에 복제됩니다. Cloud Run 서비스를 배포하면 리전을 선택할 수 있습니다 그런 다음 Cloud Run에서 서비스 인스턴스를 배포할 리전 내에서 영역을 자동으로 선택합니다. Cloud Run은 서비스 인스턴스에서 트래픽을 자동으로 분산하고 영역 서비스 중단의 영향을 크게 완화하도록 설계되었습니다.

VMware Engine

VMware Engine은 Google Cloud에서 VMware 플랫폼을 실행할 수 있게 해주는 완전 관리형 서비스입니다. VMware Engine을 사용하는 환경의 신뢰성을 높이려면 다음을 수행하는 것이 좋습니다.

  • 멀티 노드 VMware Engine 프라이빗 클라우드를 프로비저닝합니다. VMware Engine은 프라이빗 클라우드라고 하는 격리된 VMware 스택 프로비저닝을 지원하며 프라이빗 클라우드를 구성하는 모든 노드는 같은 리전에 있습니다. 프라이빗 클라우드 노드는 격리된 전용 베어메탈 하드웨어 노드에서 실행되며 단일 장애점이 제거되도록 구성됩니다. VMware Engine은 단일 노드 프라이빗 클라우드를 지원하지만 개념 증명과 테스트 목적으로만 단일 노드 프라이빗 클라우드를 사용하는 것이 좋습니다. 프로덕션 환경에서는 기본 멀티 노드 프라이빗 클라우드를 사용하는 것이 좋습니다.
  • VMware Engine 확장된 프라이빗 클라우드를 프로비저닝합니다. 확장된 프라이빗 클라우드는 노드가 리전 내 영역에서 분산되는 멀티 노드 프라이빗 클라우드입니다. 확장된 프라이빗 클라우드는 영역 서비스 중단으로부터 환경을 보호합니다.

VMware Engine의 고가용성 및 중복 기능에 대한 자세한 내용은 가용성 및 중복성을 참조하세요.

데이터 스토리지 리소스 프로비저닝 및 구성

단일 리전 환경의 컴퓨팅 리소스를 프로비저닝하고 구성한 후에는 데이터를 저장하고 관리하도록 리소스를 프로비저닝하고 구성합니다. 다음 섹션에서는 리전 구성과 멀티 리전 구성을 지원하는 Google Cloud 데이터 스토리지 및 관리 제품을 설명합니다.

Cloud Storage

Cloud Storage는 데이터를 보관하는 기본 컨테이너인 버킷에 변경할 수 없는 데이터 조각인 객체를 저장하는 서비스입니다. 버킷을 만들 때 가용성, 규제, 기타 요구사항에 가장 적합한 버킷 위치 유형을 선택합니다. 위치 유형마다 서로 다른 가용성이 보장됩니다. 장애 및 서비스 중단으로부터 데이터를 보호하기 위해 Cloud Storage는 리전 위치 유형을 가지는 버킷에 대해서는 최소 2개 영역에, 이중 리전 위치 유형을 가지는 버켓에 대해서는 2개 리전에, 멀티 리전 위치 유형을 가지는 버킷에 대해서는 2개 이상의 리전에서 데이터를 중복화합니다. 예를 들어 영역 서비스 중단이 발생했을 때 Cloud Storage 버킷을 사용할 수 있게 해야 하는 경우에는 리전 위치 유형으로 프로비저닝하면 됩니다.

Cloud Storage에 저장된 데이터의 재해 메커니즘을 설계하는 방법과 Cloud Storage가 영역 및 리전 서비스 중단에 미치는 영향에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계: 스토리지를 참조하세요.

Filestore

Filestore는 Compute Engine 인스턴스, GKE 클러스터, 온프레미스 머신에 연결할 수 있는 Google Cloud의 완전 관리형 파일 서버를 제공합니다. Filestore는 여러 서비스 등급을 제공합니다. 각 등급은 고유한 가용성, 확장성, 성능, 용량, 데이터 복구 기능을 제공합니다. Filestore 인스턴스를 프로비저닝할 때는 엔터프라이즈 등급을 선택하는 것이 좋습니다. 한 리전의 여러 영역에 걸쳐 고가용성 및 데이터 중복화를 지원하기 때문입니다. 다른 티어에 있는 인스턴스는 영역별 리소스입니다.

Bigtable

Bigtable은 대규모 분석 및 운영 워크로드를 위한 확장성이 뛰어난 완전 관리형 고성능 데이터베이스 서비스입니다. Bigtable 인스턴스는 영역별 리소스입니다. 인스턴스 신뢰성을 높이려면 같은 리전 내 여러 영역에서 또는 여러 리전에서 Bigtable이 데이터를 복제하도록 구성하면 됩니다. 복제가 사용 설정된 경우 서비스 중단이 발생하면 Bigtable은 데이터를 복제한 다른 사용 가능한 인스턴스로 요청을 자동으로 실패합니다.

Bigtable에서 복제가 작동하는 방식에 대한 자세한 내용은 복제 정보 및 클라우드 인프라 서비스 중단의 재해 복구 설계: Bigtable을 참조하세요.

Firestore

Firestore는 Firebase 및 Google Cloud의 모바일, 웹, 서버 개발에 사용되는 유연하고 확장 가능한 데이터베이스입니다. Firestore 데이터베이스를 프로비저닝할 때 해당 위치를 선택합니다. 위치는 멀티 리전 또는 리전별일 수 있으며 서로 다른 신뢰성을 보장합니다. 데이터베이스에 리전 위치가 있으면 한 리전 내 여러 영역에서 데이터를 복제합니다. 멀티 리전 데이터베이스는 리전 2개 이상에서 데이터를 복제합니다.

Firestore에서 복제가 작동하는 방식과 Firestore가 영역 및 리전 서비스 중단에 대응하는 방법에 자세한 내용은 Firestore 위치 및 클라우드 인프라 서비스 중단의 재해 복구 설계 Firestore를 참조하세요.

Memorystore

Memorystore를 사용하면 확장 가능하고 안전하며 가용성이 높은 인메모리 데이터 스토리지 서비스를 구성할 수 있습니다. Memorystore는 Redis 및 Memcached용 데이터 백엔드를 지원합니다.

Redis용 Memorystore 인스턴스를 프로비저닝할 때 해당 인스턴스의 서비스 등급을 선택합니다. Redis용 Memorystore는 여러 인스턴스 서비스 등급을 지원하며 등급마다 고유한 가용성, 노드 크기, 대역폭 기능을 제공합니다. Redis용 Memorystore 인스턴스를 프로비저닝할 때는 표준 등급 또는 읽기 복제본이 있는 표준 등급을 선택하는 것이 좋습니다. 이 두 등급의 Memorystore 인스턴스는 한 리전 내 여러 영역에서 데이터를 자동으로 복제합니다. Redis용 Memorystore에서 고가용성을 달성하는 방법에 대한 자세한 내용은 Redis용 Memorystore의 고가용성을 참조하세요.

Memorystore for Memcached 인스턴스를 프로비저닝할 때는 다음을 고려하세요.

  • 영역 선택. Memorystore for Memcached 인스턴스 프로비저닝할 때 인스턴스를 배포할 리전을 선택합니다. 그런 다음 인스턴스 노드를 배포할 리전 내에서 영역을 선택하거나 Memorystore for Memcached가 여러 영역에 노드를 자동으로 배포하도록 할 수 있습니다. 인스턴스를 최적으로 배치하고 같은 영역 내에 모든 노드 배치와 같은 프로비저닝 문제를 방지하려면 Memorystore for Memcached가 한 리전 내 여러 영역에 노드를 자동으로 분산하도록 하는 것이 좋습니다.
  • 영역에서 데이터 복제. Memorystore for Memcached 인스턴스는 여러 영역 또는 리전에서 데이터를 복제하지 않습니다. 영역 또는 리전 중단이 있을 때 Memorystore for Memcached 인스턴스의 작동 방법은 클라우드 인프라 중단에 대한 재해 복구 설계: Memorystore for Memcached를 참조하세요.

Spanner

Spanner는 무제한 확장, strong consistency, 최대 99.999% 가용성을 지원하는 완전 관리형 관계형 데이터베이스입니다. Spanner를 사용하려면 Spanner 인스턴스를 프로비저닝합니다. Spanner 인스턴스를 프로비저닝할 때는 다음을 고려합니다.

  • 인스턴스 구성. 인스턴스 구성은 Spanner 인스턴스에서 데이터베이스의 지리적 위치와 복제를 정의합니다. Spanner 인스턴스를 만들 때 이를 리전 또는 멀티 리전으로 구성합니다.
  • 복제. Spanner는 바이트 수준의 자동 복제를 지원하며 가용성, 신뢰성, 확장성 니즈에 따라 복제본 생성을 지원합니다. 리전 및 환경에 걸쳐서 복제본을 배포할 수 있습니다. 리전 구성이 포함된 Spanner 인스턴스는 리전 내 영역마다 읽기-쓰기 복제본 하나를 유지합니다. 멀티 리전 구성이 포함된 인스턴스는 여러 리전 간의 여러 영역에 데이터를 복제합니다.
  • 인스턴스 이동. Spanner를 사용하면 다운타임이 발생하거나 이동 중 트랜잭션 보장을 방해하지 않고도 한 인스턴스 구성에서 다른 인스턴스 구성으로 인스턴스를 이동할 수 있습니다.

Spanner 복제와 Spanner에서 영역 및 리전 서비스 중단에 대응하는 방법에 대한 자세한 내용은 Spanner 복제 및 클라우드 인프라 서비스 중단의 재해 복구 설계: Spanner를 참조하세요.

데이터 분석 리소스 프로비저닝 및 구성

단일 리전 환경의 데이터 스토리지 리소스를 프로비저닝하고 구성한 후에는 데이터 분석 리소스를 프로비저닝하고 구성합니다. 다음 섹션에서는 리전 구성을 지원하는 Google Cloud 데이터 분석 제품을 설명합니다.

BigQuery

BigQuery는 머신러닝, 지리정보 분석, 비즈니스 인텔리전스와 같은 기본 제공 기능으로 데이터를 관리하고 분석하는 데 도움이 되는 완전 관리형 엔터프라이즈 데이터 웨어하우스입니다.

BigQuery에서 데이터에 대한 액세스를 구성하고 제어하려면 데이터 세트라고 하는 최상위 수준의 컨테이너를 프로비저닝합니다. BigQuery 데이터 세트를 프로비저닝할 때는 다음을 고려하세요.

  • 데이터 세트 위치. 데이터를 저장할 BigQuery 위치를 선택하려면 데이터 세트 위치를 구성합니다. 위치는 리전 또는 멀티 리전일 수 있습니다. 두 위치 모두 BigQuery는 선택한 위치 내의 두 영역에 데이터 복사본을 저장합니다. 데이터 세트를 만든 후에는 데이터 세트 위치를 변경할 수 없습니다.
  • 재해 복구 계획하기. BigQuery는 리전 서비스이며 컴퓨팅과 데이터를 위해 영역 장애를 자동으로 처리합니다. 그러나 리전 서비스 중단과 같이 직접 계획해야 하는 특정 시나리오가 있습니다. 환경을 설계할 때 이러한 시나리오를 고려하는 것이 좋습니다.

BigQuery 재해 복구 계획과 기능에 대한 자세한 내용은 BigQuery 문서의 신뢰성 이해: 재해 계획과 클라우드 인프라 서비스 중단의 재해 복구 설계: BigQuery를 참조하세요.

Dataproc

Dataproc은 일괄 처리, 쿼리, 스트리밍, 머신러닝에 오픈소스 데이터 도구를 사용할 수 있게 해주는 관리형 서비스입니다. Dataproc은 Compute Engine을 기반으로 빌드되므로 Compute Engine에 대한 이전 섹션의 권장사항이 부분적으로 Dataproc에도 적용됩니다.

Dataproc을 사용하려면 Dataproc 클러스터를 만듭니다. Dataproc 클러스터는 영역별 리소스입니다. Dataproc 클러스터를 만들 때 다음 사항을 고려하세요.

  • 자동 영역 배치. 클러스터를 만들 때 클러스터 노드를 프로비저닝할 리전 내에서 영역을 지정하거나 Dataproc 자동 영역 배치 기능을 사용하여 영역을 자동으로 선택할 수 있습니다. 리전 내 클러스터 노드 영역 배치를 미세 조정해야 하는 경우가 아니라면 자동 영역 배치를 사용하는 것이 좋습니다.
  • 고가용성 모드. 클러스터를 만들 때 고가용성 모드를 사용 설정할 수 있습니다. 클러스터를 만든 후에는 고가용성 모드를 사용 설정할 수 없습니다. 단일 조정자 노드의 장애 또는 부분적인 영역 서비스 중단에 대한 클러스터 복원력이 우수해야 하는 경우 고가용성 모드를 사용 설정하는 것이 좋습니다. 고가용성 Dataproc 클러스터는 영역별 리소스입니다.

Dataproc이 영역 및 리전 서비스 중단에 대처하는 방법과 장애 발생 시 Dataproc 클러스터의 안정성을 높이는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계: Dataproc을 참조하세요.

Dataflow

Dataflow는 스트림 및 일괄 데이터 처리 파이프라인을 실행하는 데 사용되는 완전 관리형 서비스입니다. Dataflow를 사용하려면 Dataflow 파이프라인을 만듭니다. 그러면 Dataflow가 이러한 노드의 인스턴스인 작업을 워커 노드에서 실행합니다. Dataflow 리소스를 사용할 때 작업은 영역별 리소스이므로 다음을 고려해야 합니다.

  • 리전 엔드포인트. 작업을 만들 때 Dataflow를 사용하려면 리전 엔드포인트를 구성해야 합니다. 작업의 리전 엔드포인트를 구성하면 컴퓨팅 및 데이터 리소스 배치를 특정 리전으로 제한할 수 있습니다.
  • 영역 배치. Dataflow는 작업 유형에 따라 리전 내 모든 영역에 또는 리전 내 최적 영역에 워커 노드를 자동으로 배포합니다. Dataflow를 사용하면 모든 워커 노드를 리전 내 같은 영역에 배치하여 워커 노드의 영역 배치를 재정의할 수 있습니다. 영역 서비스 중단으로 인한 문제를 완화하려면 워커 노드를 특정 영역에 배치해야 하는 경우가 아니라면 Dataflow에서 최적의 영역 배치를 자동으로 선택하도록 하는 것이 좋습니다.

Dataproc이 영역 및 리전 서비스 중단에 대처하는 방법과 장애 발생 시 Dataproc 클러스터의 안정성을 높이는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계: Dataflow을 참조하세요.

Pub/Sub

Pub/Sub은 메시지 생성 서비스를 메시지 처리 서비스와 분리하는 확장 가능한 비동기 메시지 서비스입니다. Pub/Sub은 메시지를 주제별로 정리합니다. 게시자(메시지를 생성하는 서비스)는 주제로 메시지를 전송하고, 구독자는 주제에서 메시지를 수신합니다. Pub/Sub은 각 메시지를 단일 리전에 저장하고 해당 리전 내 영역 최소 2개 이상에 복제합니다. 자세한 내용은 Pub/Sub 아키텍처 개요를 참조하세요.

Pub/Sub 환경을 구성할 때 다음을 고려하세요.

  • 전역 및 리전 엔드포인트. Pub/Sub은 메시지를 게시하기 위한 전역 및 리전 엔드포인트를 지원합니다. 게시자가 메시지를 전역 엔드포인트로 보내면 Pub/Sub에서 해당 메시지를 처리할 가장 가까운 리전을 자동으로 선택합니다. 프로듀서가 리전 엔드포인트로 메시지를 보내면 Pub/Sub가 해당 리전에서 메시지를 처리합니다.
  • 메시지 저장용량 정책. Pub/Sub을 사용하면 요청 출처와 게시자가 메시지를 게시하는 데 사용한 엔드포인트에 관계없이 Pub/Sub에서 메시지를 처리하고 저장하는 위치를 제한하도록 메시지 스토리지 정책을 구성할 수 있습니다. 메시지가 단일 리전 환경을 벗어나지 않도록 메시지 스토리지 정책을 구성하는 것이 좋습니다.

Pub/Sub에서 영역 및 리전 서비스 중단을 처리하는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계: Pub/Sub을 참조하세요.

단일 리전 환경에 맞게 워크로드 조정

환경 프로비저닝과 구성을 완료하면 영역 및 리전 장애에 대한 워크로드 복원력이 더 우수해지도록 하는 방법을 고려해야 합니다. 각 워크로드마다 자체 가용성 및 안정성 요구사항과 속성이 있을 수 있지만 몇 가지 적용 가능한 설계 원칙과 발생할 가능성이 높지 않은 영역 및 리전 장애 이벤트에서 전반적인 복구 상태를 개선하기 위해 채택할 수 있는 전략이 있습니다. 워크로드를 설계하고 구현할 때 다음을 고려하세요.

  • 사이트 안정성 엔지니어링(SRE) 관행 및 원칙 구현. 자동화 및 광범위한 모니터링은 SRE의 핵심 원칙의 일부입니다. Google Cloud는 SRE를 구현하기 위한 도구와 전문 서비스를 제공하여 환경의 복원력과 신뢰성을 높이고 반복 업무를 줄입니다.
  • 확장성과 복원력을 고려한 설계. 클라우드 환경을 대상으로 하는 워크로드를 설계할 때는 워크로드가 준수해야 하는 고유한 요구사항에 대한 확장성과 복원력을 고려하는 것이 좋습니다. 이러한 종류의 설계에 대한 자세한 내용은 확장 가능하고 복원력이 우수한 앱 패턴을 참조하세요.
  • 클라우드 인프라 서비스 중단 복구 설계. Google Cloud 가용성 보장은 Google Cloud 서비스수준계약에 정의되어 있습니다. 드물게 영역 또는 리전에 장애가 발생하는 경우 영역 및 리전 장애에 대한 복원력이 우수하도록 워크로드를 설계하는 것이 좋습니다.
  • 부하 차단 및 단계적 성능 저하 구현. 클라우드 인프라 장애가 있거나 워크로드의 다른 종속 항목에 장애가 있는 경우 워크로드의 복원력이 우수하도록 워크로드를 설계하는 것이 좋습니다. 장애가 생기더라도 워크로드는 일정하고 잘 정의된 기능을 유지해야 하며(단계적 성능 저하), 과부하 조건에 접근하는 동안 부하의 일정 부분을 줄여나갈 수 있어야 합니다(부하 차단).
  • 정기 유지보수 계획. 배포 프로세스와 운영 프로세스를 설계할 때는 환경의 정기 유지보수의 일부로 수행해야 하는 모든 활동도 고려하는 것이 좋습니다. 정기 유지보수에는 워크로드와 종속 항목에 업데이트 및 구성 변경사항 적용과 같은 활동과 이러한 활동이 환경 가용성에 미치는 영향이 포함되어야 합니다. 예를 들어 Compute Engine 인스턴스에 대한 호스트 유지보수 정책을 구성할 수 있습니다.
  • 테스트 기반 개발 방식을 채택. 워크로드를 설계할 때 워크로드가 모든 부분에서 의도한 대로 동작하도록 테스트 기반 개발 접근 방식을 채택하는 것이 좋습니다. 예를 들어 워크로드 및 클라우드 인프라가 필요한 기능적, 비기능, 보안 요구사항을 충족하는지 테스트할 수 있습니다.

다음 단계

참여자

저자:

기타 참여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.