Google Cloud 인프라 서비스는 전 세계 여러 위치에서 실행됩니다. 이 위치는 클라우드 워크로드를 위한 안정적인 인프라를 설계하기 위한 기본 구성요소인 리전 및 영역이라는 장애 도메인으로 나뉩니다.
장애 도메인은 다른 리소스와 독립적으로 실패할 수 있는 리소스 또는 리소스 그룹입니다. 독립형 Compute Engine VM이 장애 도메인에 해당하는 리소스의 예입니다. Google Cloud 리전 또는 영역은 리소스 그룹으로 구성된 장애 도메인의 예입니다. 애플리케이션을 장애 도메인에 중복해서 배포하면 각 장애 도메인에서 제공되는 것보다 더 높은 수준의 합산된 가용성을 얻을 수 있습니다.
Google Cloud 인프라 안정성 가이드에 포함된 이 문서에서는 Google Cloud의 안정성 구성요소와 이 구성요소가 클라우드 리소스의 가용성에 미치는 영향을 설명합니다.
리전 및 영역
Google Cloud 리전은 독립적인 지리적 위치입니다. 각 Google Cloud 리전에는 여러 영역이 포함되어 있습니다. 한 영역에서 장애가 발생해도 다른 영역의 인프라에 영향을 미칠 가능성이 낮습니다. 글로벌 네트워크 백본이 모든 Google Cloud 영역과 리전에서 지연 시간이 짧은 고대역폭 연결을 제공합니다.
플랫폼 가용성
Google Cloud 인프라는 장애를 허용하고 복구하도록 설계되었습니다. Google은 Google Cloud의 안정성을 유지하고 개선하기 위한 혁신적인 접근 방식에 지속적으로 투자하고 있습니다. Google Cloud 인프라의 다음 기능이 클라우드 워크로드를 위한 안정적인 플랫폼을 제공하는 데 도움이 됩니다.
- 자연 재해와 리전 서비스 중단이 글로벌 서비스에 미치는 영향을 완화해주는 지리적으로 떨어진 리전.
- 단일 장애점을 방지하는 하드웨어 중복 및 복제.
- 유지보수 이벤트 중 리소스 라이브 마이그레이션. 예를 들어 계획된 인프라 유지보수 중에 라이브 마이그레이션을 사용하여 Compute Engine VM을 동일한 영역의 다른 호스트로 이동할 수 있습니다.
- Google Cloud가 실행되는 물리적 인프라와 소프트웨어를 위해 보안을 우선으로 설계된 인프라 기반과 데이터 및 워크로드를 보호하는 운영 보안 제어 기능. 자세한 내용은 Google 인프라 보안 설계 개요를 참조하세요.
- 네트워크 관리에 고급 소프트웨어 정의 네트워킹(SDN) 접근 방식을 사용하는 고성능 백본 네트워크와 확장성이 우수한 일관된 성능을 제공하는 에지 캐싱 서비스.
- 지속적인 모니터링 및 보고. Google Cloud Service Health 대시보드를 사용하여 모든 위치의 Google Cloud 서비스 상태를 볼 수 있습니다.
- 재해 중에도 Google Cloud 서비스 및 내부 비즈니스 운영이 계속 실행되도록 하는 전사적 차원의 연간 재해 복구 테스트(DiRT) 이벤트.
Google Cloud 인프라는 대부분의 고객 워크로드에 다음과 같은 가용성 목표 수준을 지원하도록 설계되었습니다.
| 배포 위치 | 가용성(업타임) 비율(%) | 최대 예상 다운타임 |
|---|---|---|
| 단일 영역 | 9 3개: 99.9% | 한 달(30일) 동안 43.2분 |
| 리전의 다중 영역 | 9 4개: 99.99% | 한 달(30일) 동안 4.3분 |
| 여러 리전 | 9 5개: 99.999% | 한 달(30일) 동안 26초 |
위 표의 가용성 비율은 목표 값입니다. 특정 Google Cloud 서비스의 업타임 서비스수준계약(SLA)은 이 가용성 목표와 다를 수 있습니다. 예를 들어 Bigtable 인스턴스의 업타임 SLA는 클러스터 수, 위치 간 분산, 구성된 라우팅 정책에 따라 달라집니다.
3개 이상의 리전에 클러스터가 있는 Bigtable 인스턴스의 최소 업타임 SLA는 멀티 클러스터 라우팅 정책이 구성된 경우 99.999% 입니다. 그러나 단일 클러스터 라우팅 정책이 구성된 경우 클러스터 수 및 분산에 관계없이 최소 업타임 SLA는 99.9%입니다.
이 섹션의 다이어그램은 클러스터 크기가 다양한 Bigtable 인스턴스와 그에 따른 업타임 SLA의 차이를 보여줍니다.
단일 클러스터
다음 다이어그램은 최소 업타임 SLA가 99.9%인 단일 클러스터 Bigtable 인스턴스를 보여줍니다.
여러 클러스터
다음 다이어그램은 멀티 클러스터 라우팅이 사용되며 단일 리전 내 여러 영역에 있는 멀티 클러스터 Bigtable 인스턴스(최소 업타임 SLA: 99.99%)를 보여줍니다.
여러 클러스터
다음 다이어그램은 멀티 클러스터 라우팅이 사용되며 3개 리전에 있는 멀티 클러스터 Bigtable 인스턴스(최소 업타임 SLA: 99.999%)를 보여줍니다.
인프라 가용성 집계
Google Cloud에서 애플리케이션을 실행하려면 VM 및 데이터베이스와 같은 인프라 리소스를 사용합니다. 이러한 인프라 리소스는 애플리케이션의 인프라 스택을 함께 구성합니다.
다음 다이어그램에서는 Google Cloud의 인프라 스택 예시와 스택의 각 리소스에 대한 가용성 SLA를 보여줍니다.
이 인프라 스택 예시에는 다음 Google Cloud 리소스가 포함됩니다.
- 리전 외부 애플리케이션 부하 분산기에서 사용자 요청을 수신하여 응답합니다.
- 리전 관리형 인스턴스 그룹(MIG)은 리전 외부 애플리케이션 부하 분산기의 백엔드입니다. MIG에는 서로 다른 영역에 있는 Compute Engine VM 두 개가 포함됩니다. 각 VM에서 웹 서버 인스턴스를 호스팅합니다.
- 내부 부하 분산기는 웹 서버와 애플리케이션 서버 인스턴스 간의 커뮤니케이션을 처리합니다.
- 두 번째 리전 MIG는 내부 부하 분산기의 백엔드입니다. 이 MIG에는 다른 영역에 있는 Compute Engine VM 두 개가 포함됩니다. 각 VM에서 애플리케이션 서버 인스턴스를 호스팅합니다.
- HA용으로 구성된 Cloud SQL 인스턴스는 애플리케이션의 데이터베이스입니다. 기본 데이터베이스 인스턴스는 대기 데이터베이스 인스턴스에 비동기적으로 복제됩니다.
앞선 예시와 같은 인프라 스택에서 기대할 수 있는 집계 가용성은 다음 요소에 따라 달라집니다.
Google Cloud SLA
인프라 스택에서 사용하는 Google Cloud 서비스의 업타임 SLA는 스택에서 예상할 수 있는 최소 집계 가용성에 영향을 미칩니다.
다음 표에서는 일부 서비스의 업타임 SLA를 비교합니다.
| 컴퓨팅 서비스 | 월간 업타임 SLA | 1달(30일)의 최대 예상 다운타임 |
|---|---|---|
| Compute Engine VM | 99.9% | 43.2분 |
| 여러 영역의 GKE Autopilot 포드 | 99.9% | 43.2분 |
| Cloud Run 서비스 | 99.95% | 21.6분 |
| 데이터베이스 서비스 | 월간 업타임 SLA | 1달(30일)의 최대 예상 다운타임 |
|---|---|---|
| PostgreSQL용 Cloud SQL 인스턴스(Enterprise 버전) | 99.95% | 21.6분 |
| PostgreSQL용 AlloyDB 인스턴스 | 99.99% | 4.3분 |
| Spanner 멀티 리전 인스턴스 | 99.999% | 26초 |
다른 Google Cloud 서비스의 SLA는 Google Cloud 서비스수준계약을 참조하세요.
앞선 표와 같이 인프라 스택의 계층마다 선택하는 Google Cloud 서비스는 인프라 스택에서 기대할 수 있는 전체 업타임에 직접 영향을 미칩니다. Google Cloud 리소스에 배포된 워크로드의 예상 가용성을 높이려면 다음 섹션의 설명대로 리소스의 중복 인스턴스를 프로비저닝하면 됩니다.
리소스 중복성
리소스 중복성은 동일한 리소스 인스턴스를 2개 이상 프로비저닝하고 그룹의 모든 리소스에 같은 워크로드를 배포하는 것을 의미합니다. 예를 들어 애플리케이션의 웹 계층을 호스팅하기 위해 동일한 여러 Compute Engine VM이 포함된 MIG를 프로비저닝할 수 있습니다.
여러 장애 도메인(예: Google Cloud 영역 2개)에 리소스 그룹을 중복 배포하는 경우 해당 그룹에서 예상할 수 있는 리소스 가용성은 그룹의 각 리소스 업타임 SLA보다 높습니다. 이렇게 가용성이 높은 이유는 그룹의 모든 리소스가 동시에 실패할 확률이 단일 장애 도메인의 리소스가 조정된 실패일 확률보다 낮기 때문입니다.
예를 들어 리소스의 가용성 SLA가 99.9%인 경우 리소스가 실패할 확률은 0.001(1에서 SLA를 뺀 값)입니다. 별도의 장애 도메인에 프로비저닝된 이 리소스의 인스턴스 두 개에 워크로드를 분산하면 두 리소스 모두 동시에 실패할 확률은 0.000001(즉, 0.001 x 0.001)입니다. 이 실패 확률은 두 리소스 그룹에 대해 이론적 가용성 99.9999%로 변환됩니다. 그러나 예상 가능한 실제 가용성은 배포 위치의 목표 가용성으로 제한됩니다. 리소스가 단일 Google Cloud 영역에 있는 경우 99.9%, 멀티 영역 배포의 경우 99.99%, 중복 리소스가 여러 리전에 분산된 경우 99.999%입니다.
스택 깊이
인프라 스택 깊이는 스택에 있는 고유 계층 또는 레이어의 수입니다. 인프라 스택의 계층마다 애플리케이션에 고유한 기능을 제공하는 리소스가 포함되어 있습니다. 예를 들어 3계층 스택의 중간 계층에서는 Compute Engine VM 또는 GKE 클러스터를 사용하여 애플리케이션 서버를 호스팅할 수 있습니다. 인프라 스택의 각 계층은 일반적으로 인접한 계층과 밀접하게 종속됩니다. 즉, 스택의 등급을 사용할 수 없으면 전체 스택을 사용할 수 없게 됩니다.
다음 수식을 사용하여 N등급 인프라 스택의 예상 집계 가용성을 계산할 수 있습니다.
예를 들어 3계층 스택의 모든 등급이 99.9% 가용성을 제공하도록 설계된 경우 스택의 집계 가용성은 약 99.7%(0.999 x 0.999 x 0.999)입니다. 즉, 다중 계층 스택의 집계 가용성은 최소 가용성을 제공하는 등급의 가용성보다 낮습니다.
다음 표와 같이 스택에서 상호 의존적인 계층 수가 증가하면 스택의 집계 가용성은 감소합니다. 표의 예시 스택마다 여러 계층이 있습니다. 쉽게 비교할 수 있도록 모든 계층에서 99.9% 가용성을 제공한다고 가정합니다.
| 등급 | 스택 A | 스택 B | 스택 C |
|---|---|---|---|
| 프런트 엔드 | 99.9% | 99.9% | 99.9% |
| 애플리케이션 계층 | 99.9% | 99.9% | 99.9% |
| 중간 계층 | – | 99.9% | 99.9% |
| 데이터 계층 | – | – | 99.9% |
| 스택 집계 가용성 | 99.8% | 99.7% | 99.6% |
| 1달(30일) 스택의 최대 예상 다운타임 | 86분 | 130분 | 173분 |
설계 고려사항 요약
애플리케이션을 설계할 때 Google Cloud 인프라 스택의 집계 가용성을 고려하세요.
- 인프라 스택에서 각 Google Cloud 리소스 가용성은 스택의 집계 가용성에 영향을 미칩니다. 인프라 스택을 빌드하도록 Google Cloud 서비스를 선택할 때는 서비스의 가용성 SLA를 고려하세요.
- 리소스에서 제공하는 함수(예: 컴퓨팅 또는 데이터베이스)의 가용성을 향상시키려면 리소스의 중복 인스턴스를 프로비저닝하면 됩니다. 중복 리소스가 있는 아키텍처를 설계할 때는 가용성 이점 외에도 운영 복잡성, 지연 시간, 비용에 대한 잠재적 영향을 고려해야 합니다.
- 인프라 스택의 계층 수(즉, 스택 깊이)는 스택의 집계 가용성과 반비례합니다. 스택을 설계하거나 수정할 때 이 관계를 고려하세요.
집계 가용성 계산 예시는 다음 섹션을 참조하세요.
위치 범위
Google Cloud 리소스의 위치 범위는 인프라 장애가 리소스에 영향을 줄 수 있는 범위를 결정합니다. Google Cloud에서 프로비저닝하는 대부분의 리소스는 영역, 리전, 멀티 리전 또는 전역 위치 범위 중 하나를 가집니다.
일부 리소스 유형의 위치 범위는 고정되어 있습니다. 즉, 위치 범위를 선택하거나 변경할 수 없습니다. 예를 들어 Virtual Private Cloud(VPC) 네트워크는 전역 리소스이고 Compute Engine 가상 머신(VM)은 영역별 리소스입니다. 특정 리소스의 경우 리소스를 프로비저닝하는 동안 위치 범위를 선택할 수 있습니다. 예를 들어 Google Kubernetes Engine(GKE) 클러스터를 만들 때 영역 또는 리전별 GKE 클러스터를 만들 수 있습니다.
다음 섹션에서는 위치 범위를 자세히 설명합니다.
영역별 리소스
영역별 리소스는 Google Cloud 리전의 단일 영역 내에 배포됩니다. 다음은 영역 리소스의 예시입니다. 이 목록은 일부일 뿐 모든 내용을 포함하지는 않습니다.
- Compute Engine VM
- 영역 관리형 인스턴스 그룹(MIG)
- 영역 영구 디스크
- 단일 영역 GKE 클러스터
- Filestore 기본 및 영역 인스턴스
- Dataflow 작업
- Cloud SQL 인스턴스
- Compute Engine 기반 Dataproc 클러스터
영역에서 장애가 발생하면 해당 영역 내에서 프로비저닝된 영역별 리소스에 영향을 줄 수 있습니다. 영역은 해당 리전의 다른 영역과의 상관 장애가 발생할 위험을 최소화하도록 설계되었습니다. 한 영역에서 장애가 발생해도 일반적으로 해당 리전의 다른 영역에 있는 리소스에 영향을 주지 않습니다. 또한 영역에서 장애가 발생해도 해당 영역의 모든 인프라를 사용할 수 없게 되는 것은 아닙니다. 영역은 장애가 영향을 미칠 것으로 예상되는 경계를 정의할 뿐입니다.
영역별 리소스를 사용하는 애플리케이션을 영역별 이슈로부터 보호하기 위해 여러 영역 또는 리전에 리소스를 배포하거나 복제할 수 있습니다. 자세한 내용은 Google Cloud에서 워크로드를 위한 안정적인 인프라 설계를 참조하세요.
리전 리소스
리전별 리소스는 리전 내 여러 영역에 중복해서 배포됩니다. 다음은 리전별 리소스의 예시입니다. 이 목록은 일부일 뿐 모든 내용을 포함하지는 않습니다.
- 리전 MIG
- 리전 Cloud Storage 버킷
- 리전 영구 디스크
- 기본(멀티 영역) 구성이 사용된 리전 GKE 클러스터
- VPC 서브넷
- 리전 외부 애플리케이션 부하 분산기
- 리전별 Spanner 인스턴스
- Filestore Enterprise 인스턴스
- Cloud Run 서비스
리전별 리소스는 특정 영역의 이슈에 대한 복원력이 우수합니다. 리전 서비스 중단은 해당 리전 내에 프로비저닝된 일부 또는 모든 리전별 리소스에 영향을 줄 수 있습니다. 이러한 서비스 중단은 자연 재해 또는 대규모 인프라 장애로 인해 발생할 수 있습니다.
멀티 리전 리소스
멀티 리전 리소스는 특정 리전에 분산됩니다. 다음은 멀티 리전 리소스의 예시입니다. 이 목록은 일부일 뿐 모든 내용을 포함하지는 않습니다.
- 이중 리전 및 멀티 리전 Cloud Storage 버킷
- 멀티 리전 Spanner 인스턴스
- 멀티 클러스터(멀티 리전) Bigtable 인스턴스
- Cloud Key Management Service의 멀티 리전 키링
멀티 리전 구성에서 사용할 수 있는 Google 서비스의 전체 목록은 위치별 제공 제품을 참조하세요.
멀티 리전 리소스는 특정 리전 및 영역의 이슈에 대한 복원력이 우수합니다. 여러 리전에서 인프라 중단이 발생하면 영향을 받는 리전에 프로비저닝된 일부 또는 모든 멀티 리전 리소스의 가용성에 영향을 미칠 수 있습니다.
전역 리소스
전역 리소스는 모든 Google Cloud 위치에서 사용할 수 있습니다. 다음은 전역 리소스의 예시입니다. 이 목록은 일부일 뿐 모든 내용을 포함하지는 않습니다.
프로젝트와 연결되어 프로젝트 비용을 지불합니다. Google Cloud 리소스를 폴더 및 프로젝트로 정리하는 방법에 대한 안내 및 권장사항은 Google Cloud 시작 영역의 리소스 계층 구조 결정을 참조하세요.
VPC 네트워크(연결된 경로 및 방화벽 규칙 포함)
Cloud DNS 영역
전역 외부 애플리케이션 부하 분산기
Cloud Key Management Service의 전역 키링
Pub/Sub 주제
Secret Manager의 보안 비밀
전역적으로 사용 가능한 Google 서비스의 전체 목록은 글로벌 제품을 참조하세요.
전역 리소스는 영역 및 리전 이슈에 대한 복원력이 우수합니다. 이러한 리소스는 특정 리전의 인프라에 의존하지 않습니다. Google Cloud에는 글로벌 인프라 중단 위험을 최소화하는 데 도움이 되는 시스템 및 프로세스가 있습니다. 또한 Google에서는 인프라를 지속적으로 모니터링하고 글로벌 서비스 중단 문제를 빠르게 해결합니다.
다음 표에서는 애플리케이션 및 인프라 문제에 대한 영역, 리전, 멀티 리전, 전역 리소스의 상대적 복원력을 요약해서 보여줍니다. 이러한 리소스를 설정하는 데 필요한 작업과 서비스 중단의 영향을 완화하기 위한 권장사항도 설명합니다.
| 리소스 범위 | 탄력성 | 인프라 중단의 영향을 완화하기 위한 권장사항 |
|---|---|---|
| 영역 | 낮음 | 여러 영역 또는 리전에 리소스를 중복 배포합니다. |
| 리전 | 중간 | 여러 리전에 리소스를 중복 배포합니다. |
| 멀티 리전 또는 전역 | 높음 | 변경사항을 신중하게 관리하고 가능한 경우 심층 방어 대체를 사용합니다. 자세한 내용은 전역 리소스 중단 위험 관리 권장사항을 참조하세요. |
전역 리소스 중단 위험 관리 권장사항
영역 및 리전 서비스 중단에 대한 전역 리소스의 복원력을 활용하려면 아키텍처에서 특정 전역 리소스를 사용하는 것이 좋습니다. Google은 전역 리소스 중단의 위험을 관리하기 위해 다음과 같은 방법을 권장합니다.
전역 리소스 변경사항의 신중한 관리
전역 리소스는 물리적 장애에 대한 복원력이 우수합니다. 이러한 리소스 구성 범위는 전역으로 지정됩니다. 따라서 단일 전역 리소스를 설정하고 구성하는 것이 여러 리전 리소스를 작업하는 것보다 쉽습니다. 그러나 전역 리소스 구성에서 중요한 오류로 인해 단일 장애점(SPOF)이 될 수 있습니다. 예를 들어 전역 부하 분산기를 지리적으로 분산된 애플리케이션의 프런트엔드로 사용할 수 있습니다. 전역 부하 분산기는 이러한 애플리케이션에 적합한 경우가 많습니다. 하지만 부하 분산기 구성에서 오류가 발생하면 모든 지역에서 사용할 수 없게 될 수 있습니다. 이러한 위험을 방지하려면 전역 리소스에 대한 구성 변경사항을 신중하게 관리해야 합니다. 자세한 내용은 전역 리소스 변경사항 제어를 참조하세요.
리전별 리소스를 심층 방어 대체로 사용
특히 높은 가용성 요구사항이 있는 애플리케이션의 경우 리전 심층 방어 대체를 통해 글로벌 리소스 중단의 영향을 최소화할 수 있습니다. 전역 부하 분산기가 프런트엔드로 있는 지리적으로 분산된 애플리케이션을 예로 들어보겠습니다. 전역 부하 분산기가 전역 서비스 중단의 영향을 받더라도 애플리케이션에 계속 액세스할 수 있도록 하려면 리전 부하 분산기를 배포하면 됩니다. 전역 부하 분산기를 선호하지만 전역 부하 분산기를 사용할 수 없는 경우 가장 가까운 리전 부하 분산기로 장애 조치하도록 클라이언트를 구성할 수 있습니다.
영역별, 리전별, 전역 리소스가 있는 아키텍처 예시
다음 다이어그램과 같이 클라우드 토폴로지에 영역별, 리전별, 전역 리소스의 조합이 포함될 수 있습니다. 다음 다이어그램은 Google Cloud에 배포된 다중 계층 애플리케이션의 아키텍처 예시를 보여줍니다.
앞의 다이어그램처럼 전역 외부 HTTP/S 부하 분산기가 클라이언트 요청을 수신합니다. 부하 분산기는 2개의 Compute Engine VM이 있는 리전 MIG인 백엔드에 요청을 배포합니다. VM에서 실행되는 애플리케이션은 Cloud SQL 데이터베이스에서 데이터를 읽고 씁니다. 데이터베이스가 HA용으로 구성됩니다. 데이터베이스의 기본 및 대기 인스턴스는 별도의 영역에 프로비저닝되고 기본 데이터베이스는 대기 데이터베이스에 동기식으로 복제됩니다. 또한 데이터베이스는 Cloud Storage의 멀티 리전 버킷에 자동으로 백업됩니다.
다음 표에는 이전 아키텍처의 Google Cloud 리소스와 영역 및 리전 서비스 중단에 대한 각 리소스의 복원력이 요약되어 있습니다.
| 리소스 | 서비스 중단에 대한 복원력 |
|---|---|
| VPC 네트워크 | VPC 네트워크(연결된 라우터와 방화벽 규칙 포함)는 전역 리소스입니다. 영역 및 리전 서비스 중단에 대한 복원력이 우수합니다. |
| 서브넷 | VPC 서브넷은 리전별 리소스입니다. 영역 서비스 중단에 대한 복원력이 우수합니다. |
| 전역 외부 HTTP(S) 부하 분산기 | 전역 외부 HTTP/S 부하 분산기는 영역 및 리전 서비스 중단에 대한 복원력이 우수합니다. |
| 리전 MIG | 리전 MIG는 영역 서비스 중단에 대한 복원력이 우수합니다. |
| Compute Engine VM | Compute Engine VM은 영역별 리소스입니다. 영역 서비스 중단이 발생하면 개별 Compute Engine VM이 영향을 받을 수 있습니다. 하지만 부하 분산기의 백엔드는 독립형 VM이 아닌 리전 MIG이므로 애플리케이션이 요청을 계속 처리할 수 있습니다. |
| Cloud SQL 인스턴스 | 이 아키텍처의 Cloud SQL 배포는 HA용으로 구성됩니다. 즉, 배포에 데이터베이스 인스턴스의 기본-대기 쌍이 포함됩니다. 기본 데이터베이스는 리전 영구 디스크를 사용하여 대기 데이터베이스에 동기식으로 복제됩니다.
|
| 멀티 리전 Cloud Storage 버킷 | 멀티 리전 Cloud Storage 버킷에 저장된 데이터는 단일 리전 서비스 중단에 대한 복원력이 우수합니다. |
| 영구 디스크 | 영구 디스크는 영역별 또는 리전별 리소스일 수 있습니다. 리전 영구 디스크는 영역 서비스 중단에 대한 복원력이 우수합니다. 리전 서비스 중단으로 인한 복구를 대비하기 위해 영구 디스크의 스냅샷을 예약하고 멀티 리전 Cloud Storage 버킷에 스냅샷을 저장할 수 있습니다. |