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

Last reviewed 2023-12-08 UTC

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

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

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

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

다른 배포 archetype의 속성

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

Google Cloud 환경을 설계할 때 안정성과 운영 오버헤드를 순서대로 보여주는 다음 배포 archetype 중에서 선택할 수 있습니다.

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

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

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

다음 표에는 리소스 분포, 안정성 속성, 각 아키텍처 archetype의 복잡성이 요약되어 있습니다. 또한 각 환경을 기반으로 환경을 설계하고 구현하는 데 필요한 작업도 설명합니다.

아키텍처 archetype 이름 리소스 배포 저항에 도움이 됨 설계 복잡성
영역 환경 단일 영역 리소스 장애 단일 영역 내에서 조정 필요
단일 리전 환경 단일 리전의 여러 영역 리소스 장애, 영역 서비스 중단 단일 리전의 여러 영역 간에 조정 필요
멀티 리전 환경 여러 영역 간, 여러 리전 간 리소스 장애, 영역 서비스 중단, 리전 서비스 중단, 멀티 리전 서비스 중단 여러 영역 간, 여러 리전에 대한 조정 필요

환경의 배포 archetype 선택

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

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

장애 모델 정의

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

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

장애 모델 및 안정적인 재해 복구 계획을 설계하는 방법에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계를 참조하세요.

배포 archetype 평가

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

  • 배포 archetype이 몇 개 필요한가요? 모든 환경에 적합한 아키텍처 archetype을 하나만 선택할 필요는 없습니다. 대신 정의된 장애 모델에 대비하는 데 필요한 안정성 보장에 따라 여러 배포 archetype을 선택하는 하이브리드 방식을 구현할 수 있습니다. 예를 들어 영역 환경이 필요한 모델과 리전 환경이 필요한 모델 두 개를 정의했다면 각 장애 모델로부터 보호하기 위해 별도의 배포 archetype을 선택해야 할 수 있습니다. 여러 배포 archetype을 선택하는 경우 여러 환경의 설계, 구현, 운영의 복잡성 증가를 평가하는 것이 좋습니다.
  • 배포 archetype을 기반으로 환경을 설계하고 구현하는 데 필요한 리소스 수는 몇 개인가요? 모든 종류의 환경을 설계하고 구현하려면 리소스와 노력이 필요합니다. 선택한 archetype을 기반으로 각 환경을 설계하고 구현하기 위해 필요한 리소스 수를 평가하는 것이 좋습니다. 필요한 리소스 수를 완벽하게 이해하면 각 아키텍처 archetype에서 제공하는 안정성 보장과, 해당 archetype의 설계, 구현, 운영 환경의 복잡성 비용 간의 균형을 맞출 수 있습니다.
  • 한 아키텍처 archetype을 기반으로 하는 환경을 다른 archetype을 기반으로 하는 환경으로 마이그레이션할 것으로 예상하나요? 향후 Google Cloud 환경 하나에서 다른 Google Cloud 환경으로 워크로드, 데이터, 프로세스를 마이그레이션할 수 있습니다. 예를 들어 영역 환경에서 리전 환경으로 마이그레이션할 수 있습니다.
  • 설계 및 구현하는 환경이 업무상 얼마나 중요한가요? 비즈니스에 중요한 환경에서는 안정성이 더 보장되어야 할 수 있습니다. 예를 들어 업무상 중요한 워크로드, 데이터, 프로세스에 멀티 리전 환경을 설계 및 구현하고 덜 중요한 워크로드, 데이터, 프로세스에는 영역 또는 리전 환경을 설계하도록 선택할 수 있습니다.
  • 특정 환경에 특정 아키텍처 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 지연 시간 대시보드와 같은 도구와 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) 데이터 및 구성을 보존하기 위해 리전 스테이트풀(Stateful) MIG를 만들 수도 있습니다. 리전 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은 영구 디스크 볼륨 및 로컬 솔리드 스테이트 드라이브(SSD)와 같은 가상 머신의 여러 스토리지 옵션을 지원합니다.
    • Persistent Disk 볼륨은 여러 물리적 디스크에 분산되며 가상 머신과는 별개의 위치에 있습니다. 영구 디스크는 영역 또는 리전 리소스일 수 있습니다. 영역 영구 디스크는 단일 영역에 데이터를 저장하고 리전 영구 디스크는 두 개 영역에 데이터를 복제합니다. 단일 리전 환경에서 스토리지 옵션을 선택할 때는 영역 장애가 있으면 장애 조치 옵션이 제공되므로 리전 영구 디스크를 선택하는 것이 좋습니다. 리전 영구 디스크를 사용할 때 영역 장애에 대처하는 방법에 대한 자세한 내용은 리전 영구 디스크를 사용하는 고가용성 옵션 및 리전 영구 디스크 장애 조치를 참조하세요.
    • 로컬 SSD는 높은 처리량을 갖지만 인스턴스가 중지 또는 삭제될 때까지만 데이터를 저장합니다. 따라서 로컬 SSDS는 다른 방법으로 재구성할 수 있는 임시 데이터, 캐시, 데이터를 저장하는 데 적합합니다. 영구 디스크는 가상 머신이 물리적 디스크와 같이 액세스할 수 있는 내구성이 있는 스토리지 기기입니다.
  • 데이터 보호를 위한 메커니즘을 설계 및 구현. 단일 리전 환경을 설계할 때는 영역, 리전 또는 멀티 리전 장애, 악의적인 제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 환경으로 마이그레이션을 참조하세요. 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 데이터베이스를 프로비저닝할 때 해당 위치를 선택합니다. 위치는 멀티 리전 또는 리전일 수 있으며 다른 안정성 보장을 제공합니다. 데이터베이스에 리전 위치가 있으면 리전 내 여러 영역에 데이터를 복제합니다. 멀티 리전 데이터베이스는 두 개 이상의 리전에 데이터를 복제합니다.

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

Memorystore

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

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

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를 참조하세요.

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는 각 메시지를 단일 리전에 저장하고, 해당 리전 내의 최소 두 개 이상의 영역에 복제합니다. 자세한 내용은 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에 로그인하세요.