플랫폼 가용성에 설명된 대로 Google Cloud 인프라는 단일 영역에 배포된 워크로드에 대해 99.9%의 목표 가용성을 지원하도록 설계되었습니다. 목표 가용성은 다중 영역 배포의 경우 99.99%이고 멀티 리전 배포의 경우 99.999%입니다. Google Cloud 인프라 안정성 가이드 중 이 문서에서는 배포 안내와 아키텍처 예시 그리고 리소스, 영역 및 리전 수준의 오류로부터 워크로드를 보호하는 데 도움이 되는 디자인 기술을 제공합니다.
단일 장애점 방지하기
애플리케이션은 일반적으로 특정 기능을 수행하도록 설계된 여러 개의 독립적인 구성요소로 구성되어 있습니다. 이러한 구성요소는 일반적으로 구성요소가 수행하는 기능 및 다른 구성요소와의 관계에 따라 여러 계층으로 분류됩니다. 예를 들어 콘텐츠 제공 애플리케이션에는 부하 분산기 및 웹 서버가 포함된 웹 계층, 애플리케이션 서버 클러스터가 포함된 앱 계층, 지속성을 위한 데이터 계층이 포함될 수 있습니다. 이 애플리케이션 스택의 모든 구성요소에 단일 인프라 리소스가 사용될 경우 해당 리소스 오류가 전체 스택의 가용성에 영향을 줄 수 있습니다. 예를 들어 앱 계층이 단일 VM에서 실행되고 VM이 충돌하면 실질적으로 전체 스택을 사용하지 못합니다. 이러한 구성요소를 단일 장애점(SPOF)이라고 부릅니다.
애플리케이션 스택에는 SPOF가 둘 이상 포함될 수 있습니다. 다음 다이어그램에 표시된 다중 계층 애플리케이션 스택을 참조하세요.
위 다이어그램에 표시된 것처럼 이 아키텍처 예시에는 단일 부하 분산기, 2개의 웹 서버, 단일 앱 서버, 단일 데이터베이스가 포함되어 있습니다. 이 예시에서는 부하 분산기, 앱 서버 및 데이터베이스가 SPOF에 해당합니다. 이러한 구성요소에 오류가 발생하면 애플리케이션에 대한 사용자 요청이 실패할 수 있습니다.
애플리케이션 스택에서 SPOF를 없애려면 여러 위치에 리소스를 분산하고 중복된 리소스를 배포합니다.
리소스 분산 및 종속성 만들기
애플리케이션의 안정성 요구사항에 따라 다음 배포 아키텍처 중에서 선택할 수 있습니다.
| 아키텍처 | 워크로드 권장사항 |
|---|---|
| 멀티 리전 | 리테일 및 소셜 미디어 애플리케이션과 같이 비즈니스 관련 중요도가 높고 고가용성이 필수적인 워크로드 |
| 다중 영역 | 영역 중단에 대해서는 복원력이 필요하지만 리전 중단으로 인한 다운타임은 어느 정도 견딜 수 있는 워크로드 |
| 단일 영역 | 다운타임을 견딜 수 있거나 필요 시 최소한의 노력으로 다른 위치에 배포할 수 있는 워크로드 |
비용, 지연 시간, 운영 고려사항
중복 리소스로 분산 아키텍처를 설계할 때는 애플리케이션의 가용성 요구사항 외에도 운영 복잡성, 지연 시간 및 비용에 대한 효과를 고려해야 합니다.
분산 아키텍처에서는 많은 수의 리소스를 프로비저닝하고 관리합니다. 교차 위치 네트워크 트래픽은 볼륨이 더 높습니다. 또한 더 많은 데이터를 저장하고 복제합니다. 따라서 분산 아키텍처의 클라우드 리소스 비용이 더 높고 배포 운영이 더 복잡합니다. 비즈니스 관련 중요도가 높은 애플리케이션의 경우에는 비용 및 운영 복잡성이 증가하더라도 분산 아키텍처의 가용성 이점이 더 중요할 수 있습니다.
비즈니스 관련 중요도가 높지 않은 애플리케이션의 경우에는 분산 아키텍처가 제공하는 고가용성 이점이 반드시 필요하지 않을 수 있습니다. 일부 애플리케이션은 가용성보다 다른 요구사항이 더 중요할 수 있습니다. 예를 들어 일괄 컴퓨팅 애플리케이션은 낮은 지연 시간과 VM 간의 높은 대역폭 네트워크 연결이 필요합니다. 이러한 애플리케이션에는 단일 영역 아키텍처가 적합할 수 있고, 데이터 전송 비용을 줄이는 데에도 도움이 될 수 있습니다.
배포 아키텍처
이 섹션에서는 Google Cloud에서 워크로드 인프라를 빌드하기 위해 다음과 같은 아키텍처 옵션을 보여줍니다.
단일 영역 배포
다음 다이어그램은 각 구성요소에서 수행되는 기능의 가용성을 더 높이기 위해 모든 계층에 중복성이 있는 단일 영역 애플리케이션 아키텍처를 보여줍니다.
위 다이어그램에 표시된 것처럼 이 아키텍처 예시에는 다음 구성요소가 포함되어 있습니다.
- 사용자 요청을 수신하고 대응하기 위한 리전별 외부 HTTP/S 부하 분산기
- HTTP/S 부하 분산기에 대한 백엔드로 사용되는 영역별 관리형 인스턴스 그룹(MIG). MIG에는 2개의 Compute Engine VM이 포함되어 있습니다. 각 VM은 웹 서버의 인스턴스를 호스팅합니다.
- 웹 서버와 앱 서버 인스턴스 간의 커뮤니케이션을 처리하기 위한 내부 부하 분산기
- 내부 부하 분산기에 대한 백엔드로 사용되는 두 번째 영역별 MIG. 이 MIG에는 2개의 Compute Engine VM이 포함되어 있습니다. 각 VM은 애플리케이션 서버의 인스턴스를 호스팅합니다.
- 애플리케이션이 데이터를 쓰고 읽는 Cloud SQL 데이터베이스 인스턴스(Enterprise 버전)입니다. 이 데이터베이스는 동일 영역에 있는 두 번째 Cloud SQL 데이터베이스 인스턴스에 수동으로 복제됩니다.
집계 가용성: 단일 영역 배포
다음 표에서는 앞선 단일 영역 아키텍처 다이어그램의 각 등급 가용성을 보여줍니다.
| 리소스 | SLA |
|---|---|
| 외부 부하 분산기 | 99.99% |
| 웹 계층: 단일 영역의 Compute Engine VM | 99.9% |
| 내부 부하 분산기 | 99.99% |
| 애플리케이션 계층: 단일 영역의 Compute Engine VM | 99.9% |
| Cloud SQL 인스턴스(Enterprise 버전) | 99.95% |
앞선 표에 나열된 Google Cloud 인프라 리소스에서 다음 집계 가용성 및 최대 월간 예상 다운타임을 제공할 수 있습니다.
- 집계 가용성: 0.9999 x 0.999 x 0.9999 x 0.999 x 0.9995 = 99.73%
- 최대 월간 예상 다운타임: 약 1시간 57분
이 계산에서는 앞선 아키텍처 다이어그램에 표시된 인프라 리소스만 고려합니다. Google Cloud에서 애플리케이션 가용성을 평가하려면 다음과 같은 다른 요소도 고려해야 합니다.
- 애플리케이션 내부 설계
- 애플리케이션, 종속 항목, Google Cloud 인프라를 빌드, 배포, 유지보수하는 데 사용되는 DevOps 프로세스 및 도구
자세한 내용은 애플리케이션 안정성에 영향을 미치는 요소를 참조하세요.
중단 효과 및 복구 안내
단일 영역 배포 아키텍처에서 구성요소가 실패할 경우 각 계층에서 최소한 하나 이상의 구성요소가 작동하고 용량이 적합하면 애플리케이션이 요청을 처리할 수 있습니다. 예를 들어 웹 서버 인스턴스가 실패하면 부하 분산기가 사용자 요청을 다른 웹 서버 인스턴스로 전달합니다. 웹 서버 또는 앱 서버 인스턴스를 호스팅하는 VM이 충돌하면 MIG 덕분에 새 VM이 자동으로 생성됩니다. 데이터베이스가 충돌하면 두 번째 데이터베이스를 수동으로 활성화하고 데이터베이스에 연결하도록 앱 서버 인스턴스를 업데이트해야 합니다.
영역 중단 또는 리전 중단은 Compute Engine VM과 단일 영역 배포의 Cloud SQL 데이터베이스 인스턴스에 영향을 줍니다. 리전별 리소스이기 때문에 영역 중단이 이 아키텍처의 부하 분산기에 영향을 주지 않습니다. 그러나 사용 가능한 백엔드가 없기 때문에 부하 분산기가 트래픽을 분산할 수 없습니다. 영역 중단이 발생하면 Google이 중단을 해결할 때까지 기다린 후 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.
다음 섹션에서는 여러 영역 간에 리소스를 분산하기 위해 사용할 수 있고, 영역 중단에 대한 애플리케이션 복원력을 향상시키는 데 도움이 되는 아키텍처 접근 방식에 대해 설명합니다.
다중 영역 배포
단일 영역 배포의 경우 영역 중단이 발생하면 문제가 해결될 때까지 애플리케이션이 요청을 처리하지 못할 수 있습니다. 영역 중단에 대한 애플리케이션 복원력을 향상시키기 위해서는 둘 이상의 영역 간에 Compute Engine VM과 같은 여러 영역별 리소스 인스턴스를 프로비저닝할 수 있습니다. Cloud Storage 버킷과 같이 리전 범위 리소스를 지원하는 서비스의 경우 리전별 리소스를 배포할 수 있습니다.
다음 다이어그램은 고가용성 교차 영역 아키텍처를 보여줍니다. 여기에는 두 영역 간에 분산된 각 애플리케이션 스택 계층에 구성요소가 포함되어 있습니다.
위 다이어그램에 표시된 것처럼 이 아키텍처 예시에는 다음 구성요소가 포함되어 있습니다.
- 리전별 외부 HTTP/S 부하 분산기가 사용자 요청을 수신하고 대응합니다.
- 리전별 MIG는 HTTP/S 부하 분산기의 백엔드입니다. MIG에는 서로 다른 영역에 있는 2개의 Compute Engine VM이 포함됩니다. 각 VM은 웹 서버의 인스턴스를 호스팅합니다.
- 내부 부하 분산기는 웹 서버와 앱 서버 인스턴스 간의 커뮤니케이션을 처리합니다.
- 두 번째 리전별 MIG는 TCP 부하 분산기의 백엔드입니다. 이 MIG에는 다른 영역에 있는 2개의 Compute Engine VM이 포함됩니다. 각 VM은 앱 서버의 인스턴스를 호스팅합니다.
- HA에 구성된 Cloud SQL 인스턴스(Enterprise 버전)는 애플리케이션의 데이터베이스입니다. 기본 데이터베이스 인스턴스는 대기 데이터베이스 인스턴스에 비동기적으로 복제됩니다.
집계 가용성: 멀티 영역 배포
다음 표에서는 앞선 이중 영역 아키텍처 다이어그램의 각 등급 가용성을 보여줍니다.
| 리소스 | SLA |
|---|---|
| 외부 부하 분산기 | 99.99% |
| 웹 계층: 개별 영역의 Compute Engine VM | 99.99% |
| 내부 부하 분산기 | 99.99% |
| 애플리케이션 계층: 개별 영역의 Compute Engine VM | 99.99% |
| Cloud SQL 인스턴스(Enterprise 버전) | 99.95% |
앞선 표에 나열된 Google Cloud 인프라 리소스에서 다음 집계 가용성 및 최대 월간 예상 다운타임을 제공할 수 있습니다.
- 집계 가용성: 0.9999 x 0.9999 x 0.9999 x 0.9999 x 0.9995 = 99.91%
- 최대 월간 예상 다운타임: 약 39분
이 계산에서는 앞선 아키텍처 다이어그램에 표시된 인프라 리소스만 고려합니다. Google Cloud에서 애플리케이션 가용성을 평가하려면 다음과 같은 다른 요소도 고려해야 합니다.
- 애플리케이션 내부 설계
- 애플리케이션, 종속 항목, Google Cloud 인프라를 빌드, 배포, 유지보수하는 데 사용되는 DevOps 프로세스 및 도구
자세한 내용은 애플리케이션 안정성에 영향을 미치는 요소를 참조하세요.
중단 효과 및 복구 안내
이중 영역 배포에서는 구성요소가 실패할 경우 각 계층에서 최소한 하나 이상의 구성요소가 작동하고 용량이 적합하면 애플리케이션이 요청을 처리할 수 있습니다. 예를 들어 웹 서버 인스턴스가 실패하면 부하 분산기가 사용자 요청을 다른 영역의 웹 서버 인스턴스로 전달합니다. 웹 서버 또는 앱 서버 인스턴스를 호스팅하는 VM이 충돌하면 MIG 덕분에 새 VM이 자동으로 생성됩니다. 기본 Cloud SQL 데이터베이스가 충돌하면 Cloud SQL이 대기 데이터베이스 인스턴스로 자동으로 장애 조치됩니다.
다음 다이어그램은 이전 다이어그램과 동일한 아키텍처와 애플리케이션 가용성에 대한 영역 중단의 효과를 보여줍니다.
위 다이어그램에 표시된 것처럼 영역 중 하나에서 중단이 발생할 경우에는 리전별 리소스이기 때문에 이 아키텍처의 부하 분산기가 영향을 받지 않습니다. 영역 중단은 개별 Compute Engine VM과 Cloud SQL 데이터베이스 인스턴스 중 하나에 영향을 줄 수 있습니다. 그러나 VM이 리전별 MIG에 있고 Cloud SQL 데이터베이스가 HA용으로 구성되었기 때문에 애플리케이션의 가용성 및 응답성이 유지됩니다. MIG는 새 VM을 자동으로 생성하면서 구성된 VM 수를 최소한으로 유지하도록 보장합니다. 기본 Cloud SQL 데이터베이스 인스턴스가 영역 중단의 영향을 받는 경우 Cloud SQL이 다른 영역의 대기 인스턴스로 자동으로 장애 조치합니다. Google에서 중단이 해결된 후에는 배포된 모든 영역에서 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.
이 아키텍처의 두 영역 모두 중단이 발생하면 애플리케이션을 사용할 수 없습니다. 리전 전체 중단이 발생하지 않는 한 부하 분산기를 계속 사용할 수 있습니다. 그러나 사용 가능한 백엔드가 없기 때문에 부하 분산기가 트래픽을 분산할 수 없습니다. 다중 영역 중단 또는 리전 중단이 발생하면 Google에서 중단이 해결될 때까지 기다린 후 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.
다음 섹션에서는 다중 영역 중단 및 리전 중단으로부터 애플리케이션을 보호하기 위한 아키텍처 옵션을 보여줍니다.
리전별 부하 분산이 포함된 멀티 리전 배포
단일 영역 또는 다중 영역 배포에서는 리전 중단이 발생할 경우 문제가 해결될 때까지 애플리케이션이 요청을 처리할 수 없습니다. 리전 중단으로부터 애플리케이션을 보호하려면 둘 이상의 리전에 Google Cloud 리소스를 분산할 수 있습니다.
다음 다이어그램은 가용성이 높은 교차 리전 아키텍처를 보여줍니다. 여기에는 다중 리전에 분산된 애플리케이션 스택의 각 계층에 있는 구성요소가 포함됩니다.
위 다이어그램에 표시된 것처럼 이 아키텍처 예시에는 다음 구성요소가 포함되어 있습니다.
- 트래픽을 2개의 Google Cloud 리전으로 전달하는 라우팅 정책이 포함된 공개 Cloud DNS 영역
- 사용자 요청을 수신 및 대응하기 위한 각 리전의 리전별 외부 HTTP/S 부하 분산기
- 각 리전별 HTTP/S 부하 분산기의 백엔드는 리전별 MIG입니다. 각 MIG에는 서로 다른 영역에 있는 2개의 Compute Engine VM이 포함되어 있습니다. 이러한 각 VM은 웹 서버 인스턴스를 호스팅합니다.
- 각 리전의 내부 부하 분산기는 웹 서버 인스턴스와 앱 서버 인스턴스 사이의 커뮤니케이션을 처리합니다.
- 리전별 MIG의 두 번째 쌍은 내부 부하 분산기의 백엔드입니다. 이러한 각 MIG에는 서로 다른 영역에 있는 2개의 Compute Engine VM이 포함되어 있습니다. 각 VM은 앱 서버의 인스턴스를 호스팅합니다.
- 애플리케이션은 멀티 리전 Spanner 인스턴스에 대해 데이터를 읽고 씁니다. 이 아키텍처(
eur5)에 사용된 멀티 리전 구성에는 4개의 읽기-쓰기 복제본이 포함되어 있습니다. 읽기-쓰기 복제본은 두 리전 간에 그리고 개별 영역에서 동일하게 프로비저닝됩니다. 멀티 리전 Spanner 구성에는 또한 세 번째 리전의 감시 복제본이 포함됩니다.
집계 가용성: 리전별 부하 분산이 포함된 멀티 리전 배포
앞선 다이어그램에 표시된 멀티 리전 배포에서 부하 분산기와 VM은 두 리전에 중복 프로비저닝됩니다. DNS 영역은 전역 리소스이고 Spanner 인스턴스는 멀티 리전 리소스입니다.
이 아키텍처에 표시된 Google Cloud 인프라의 집계 가용성을 계산하려면 먼저 각 리전의 리소스 집계 가용성을 계산한 후 여러 리전에 걸쳐 있는 리소스를 고려해야 합니다. 다음 절차를 따르세요.
- 리전별 인프라 리소스의 집계 가용성을 계산합니다. 즉, DNS 리소스와 데이터베이스 리소스를 제외합니다.
리소스 및 SLA SLA 외부 부하 분산기 99.99% 웹 계층: 개별 영역의 Compute Engine VM 99.99% 내부 부하 분산기 99.99% 애플리케이션 계층: 개별 영역의 Compute Engine VM 99.99% 리전별 집계 가용성: 0.9999 x 0.9999 x 0.9999 x 0.9999 = 99.96%
부하 분산기와 Compute Engine VM의 이중 리전 중복성을 고려하여 인프라 리소스의 집계 가용성을 계산합니다.
이론적 가용성은 1-(1-0.9996)(1-0.9996) = 99.999984%입니다. 하지만 예상 가능한 실제 가용성은 멀티 리전 배포의 대상 가용성(99.999%)으로 제한됩니다.
Cloud DNS 및 Spanner 리소스를 포함한 모든 인프라 리소스의 집계 가용성을 계산합니다.
- 집계 가용성: 0.99999 x 1 x 0.99999 = 99.998%
- 최대 월간 예상 다운타임: 약 52초
이 계산에서는 앞선 아키텍처 다이어그램에 표시된 인프라 리소스만 고려합니다. Google Cloud에서 애플리케이션 가용성을 평가하려면 다음과 같은 다른 요소도 고려해야 합니다.
- 애플리케이션 내부 설계
- 애플리케이션, 종속 항목, Google Cloud 인프라를 빌드, 배포, 유지보수하는 데 사용되는 DevOps 프로세스 및 도구
자세한 내용은 애플리케이션 안정성에 영향을 미치는 요소를 참조하세요.
중단 효과 및 복구 안내
이 멀티 리전 배포의 구성요소가 실패하지만 각 계층에 작동 중이고 적절한 용량의 구성요소가 1개 이상 있으면 애플리케이션이 계속 작동합니다. 예를 들어 웹 서버 인스턴스가 실패하면 리전별 외부 HTTP/S 부하 분산기가 사용자 요청을 리전의 다른 웹 서버 인스턴스로 전달합니다. 마찬가지로 앱 서버 인스턴스 중 하나가 충돌하면 내부 부하 분산기가 다른 앱 서버 인스턴스에 요청을 전송합니다. VM이 충돌할 경우 MIG는 새 VM을 자동으로 생성하면서 구성된 VM 수를 최소한으로 유지하도록 보장합니다.
리전별 리소스이고 영역 중단에 대해 복원력이 잇기 때문에 단일 영역에서 발생하는 중단은 부하 분산기에 영향을 주지 않습니다. 영역 중단은 개별 Compute Engine VM에 영향을 줄 수 있습니다. 그러나 VM이 리전별 MIG의 일부이기 때문에 웹 서버 및 앱 서버 인스턴스를 계속 사용할 수 있습니다. MIG는 새 VM을 자동으로 생성하면서 구성된 VM 수를 최소한으로 유지하도록 보장합니다. 이 아키텍처의 Spanner 인스턴스에는 영역 중단에 대해 복원력이 있는 멀티 리전 구성이 사용됩니다.
Spanner에서 멀티 리전 복제가 작동하는 방식에 대한 자세한 내용은 리전별 및 멀티 리전 구성과 Spanner 멀티 리전 구성 설명을 참조하세요.
다음 다이어그램은 이전 다이어그램과 동일한 멀티 리전 아키텍처와 애플리케이션 가용성에 대한 단일 리전 중단 효과를 보여줍니다.
위 다이어그램에 표시된 것처럼 어느 한 리전의 두 영역 모두에서 중단이 발생하면 독립적인 애플리케이션 스택이 각 리전에 배포되기 때문에 애플리케이션이 사용 가능한 상태로 유지됩니다. DNS 영역은 중단의 영향을 받지 않는 리전으로 사용자 요청을 전달합니다. 멀티 리전 Spanner 인스턴스는 리전 중단에 대해 복원력이 있습니다. Google에서 중단이 해결된 후에는 중단이 발생한 리전에서 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.
이 아키텍처에서 두 리전에 중단이 발생하면 애플리케이션이 사용 불가능한 상태가 됩니다. Google에서 중단이 해결될 때까지 기다려야 합니다. 그런 후 배포된 모든 리전에서 애플리케이션이 예상한 대로 작동하는지 확인합니다.
멀티 리전 배포의 경우에는 리전별 부하 분산기를 사용하는 대신 전역 부하 분산기 사용을 고려할 수 있습니다. 다음 섹션에서는 전역 부하 분산기를 사용하는 멀티 리전 배포를 보여주고 이 접근 방식의 이점과 위험에 대해 설명합니다.
글로벌 부하 분산이 포함된 멀티 리전 배포
다음 다이어그램은 리전별 부하 분산기 대신 전역 부하 분산기를 사용하는 대체 멀티 리전 배포를 보여줍니다.
앞의 다이어그램에 표시된 것처럼 이 아키텍처는 전역 외부 HTTP/S 부하 분산기(Cloud CDN 사용)를 사용하여 사용자 요청을 수신하고 대응합니다. 부하 분산기의 각 전달 규칙에는 단일 외부 IP 주소가 사용됩니다. 각 리전에 대해 개별 DNS 레코드를 구성할 필요가 없습니다. 전역 외부 HTTP/S 부하 분산기에 대한 백엔드는 2개의 리전별 MIG입니다. 부하 분산기는 사용자에게 가장 가까운 리전으로 요청을 라우팅합니다.
이 아키텍처의 다른 모든 구성요소는 리전별 부하 분산이 포함된 멀티 리전 배포에 표시된 아키텍처와 동일합니다.
멀티 리전 배포를 위한 전역 부하 분산의 이점과 위험
여러 리전 간에 분산된 애플리케이션으로 외부 트래픽을 부하 분산하려면 전역 부하 분산 장치 또는 여러 리전별 부하 분산 장치를 사용할 수 있습니다.
다음은 전역 부하 분산기를 사용하는 아키텍처의 이점입니다.
- 단일 부하 분산기만 관리하면 됩니다.
- 전역 부하 분산기는 단일 Anycast IP 주소를 사용하여 Google Cloud 리전 간에 부하 분산을 제공합니다.
- 전역 부하 분산기는 리전 중단에 대해 복원력이 있으며 자동 교차 리전 장애 조치 기능을 제공합니다.
- 전역 부하 분산기는 배포 복원력을 강화하는 데 도움이 되는 다음 기능을 지원합니다.
- Cloud CDN을 사용하는 에지 캐싱
- 내구성이 높은 Cloud Storage 버킷을 백엔드로 사용하는 기능
- Google Cloud Armor 보안 정책
다음은 전역 부하 분산기를 사용하는 아키텍처의 위험 요소입니다.
- 전역 부하 분산기 구성이 잘못되었으면 사용자가 애플리케이션을 사용하지 못할 수 있습니다. 예를 들어 전역 부하 분산기의 프런트엔드를 업데이트하는 동안 전달 규칙을 실수로 삭제하면 부하 분산기에서 사용자 요청 수신이 중지됩니다. 리전 중 하나에 있는 리전별 부하 분산기가 구성 오류의 영향을 받는 경우에도 다른 리전의 부하 분산기가 계속 작동할 수 있기 때문에 리전별 부하 분산기를 사용하는 멀티 리전 아키텍처의 경우에 이러한 위험 요소의 효과가 낮아집니다.
- 전역 리소스에 영향을 주는 인프라 중단은 전역 부하 분산기를 사용 불가능하게 만들 수 있습니다.
이러한 위험을 해결하려면 전역 부하 분산기를 신중하게 변경하고 가능한 경우 심층 방어 대체 수단을 사용하도록 고려해야 합니다. 자세한 내용은 전역 리소스 중단 위험 관리 권장사항을 참조하세요.
집계 가용성: 글로벌 부하 분산이 포함된 멀티 리전 배포
앞선 다이어그램에 표시된 멀티 리전 배포에서 VM 및 내부 부하 분산기는 두 리전에 중복 배포됩니다. 외부 부하 분산기는 전역 리소스이고 Spanner 인스턴스는 멀티 리전 리소스입니다.
이 배포의 집계 가용성을 계산하려면 먼저 각 리전의 리소스 집계 가용성을 계산한 후 여러 리전에 걸쳐 있는 리소스를 고려합니다.
- 외부 부하 분산기와 데이터베이스를 제외하고 리전별 인프라 리소스의 집계 가용성을 계산합니다.
리소스 SLA 웹 계층: 개별 영역의 Compute Engine VM 99.99% 내부 부하 분산기 99.99% 웹 계층: 개별 영역의 Compute Engine VM 99.99% 리전별 집계 가용성: 0.9999 x 0.9999 x 0.9999 = 99.97%
내부 부하 분산기와 Compute Engine VM의 이중 리전 중복성을 고려하여 인프라 리소스의 집계 가용성을 계산합니다.
이론적 가용성은 1-(1-0.9997)(1-0.9997) = 99.999991%입니다. 하지만 예상 가능한 실제 가용성은 멀티 리전 배포의 대상 가용성(99.999%)으로 제한됩니다.
전역 부하 분산기 및 Spanner 리소스를 포함한 모든 인프라 리소스의 집계 가용성을 계산합니다.
- 집계 가용성: 0.99999 x 0.9999 x 0.99999 = 99.988%
- 최대 월간 예상 다운타임: 약 5분 11초
이 계산에서는 앞선 아키텍처 다이어그램에 표시된 인프라 리소스만 고려합니다. Google Cloud에서 애플리케이션 가용성을 평가하려면 다음과 같은 다른 요소도 고려해야 합니다.
- 애플리케이션 내부 설계
- 애플리케이션, 종속 항목, Google Cloud 인프라를 빌드, 배포, 유지보수하는 데 사용되는 DevOps 프로세스 및 도구
자세한 내용은 애플리케이션 안정성에 영향을 미치는 요소를 참조하세요.
중단 효과 및 복구 안내
이 아키텍처의 구성요소가 실패하면 적절한 용량의 작동 중인 구성요소가 각 계층에 1개 이상 있는 경우 애플리케이션이 계속 작동합니다. 예를 들어 웹 서버 인스턴스가 실행하면 전역 외부 HTTP/S 부하 분산기가 사용자 요청을 다른 웹 서버 인스턴스로 전달합니다. 앱 서버 인스턴스가 충돌하면 내부 부하 분산기가 요청을 다른 앱 서버 인스턴스에 전송합니다. VM이 충돌할 경우 MIG는 새 VM을 자동으로 생성하면서 구성된 VM 수를 최소한으로 유지하도록 보장합니다.
리전에서 영역 중 하나 이상에 중단이 발생할 경우 부하 분산기가 영향을 받지 않습니다. 전역 외부 HTTP/S 부하 분산기가 영역 및 리전 중단에 대해 복원력을 갖습니다. 내부 부하 분산기는 리전별 리소스이며, 영역 중단에 대해 복원력을 갖습니다. 영역 중단은 개별 Compute Engine VM에 영향을 줄 수 있습니다. 그러나 VM이 리전별 MIG의 일부이기 때문에 웹 서버 및 앱 서버 인스턴스를 계속 사용할 수 있습니다. MIG는 새 VM을 자동으로 생성하면서 구성된 VM 수를 최소한으로 유지하도록 보장합니다. 이 아키텍처의 Spanner 인스턴스에는 영역 중단에 대해 복원력이 있는 멀티 리전 구성이 사용됩니다.
다음 다이어그램은 이전 다이어그램과 동일한 멀티 리전 아키텍처와 애플리케이션 가용성에 대한 단일 리전 중단 효과를 보여줍니다.
위 다이어그램에 표시된 것처럼 어느 한 리전의 두 영역 모두에서 중단이 발생하면 독립적인 애플리케이션 스택이 각 리전에 배포되기 때문에 애플리케이션이 사용 가능한 상태로 유지됩니다. 전역 외부 HTTP/S 부하 분산기가 해당 중단의 영향을 받지 않는 리전의 애플리케이션으로 사용자 요청을 라우팅합니다. 멀티 리전 Spanner 인스턴스는 리전 중단에 대해 복원력이 있습니다. Google에서 중단이 해결된 후에는 중단이 발생한 리전에서 애플리케이션이 예상한 대로 작동하는지 확인해야 합니다.
Spanner에서 멀티 리전 복제가 작동하는 방식에 대한 자세한 내용은 리전별 및 멀티 리전 구성과 Spanner 멀티 리전 구성 설명을 참조하세요.
이 아키텍처에서 두 리전에 중단이 발생하면 애플리케이션이 사용 불가능한 상태가 됩니다. 전역 외부 HTTP/S 부하 분산기를 사용할 수 있지만 사용 가능한 백엔드가 없기 때문에 트래픽을 분산할 수 없습니다. Google에서 중단이 해결될 때까지 기다려야 합니다. 그런 후 배포된 모든 리전에서 애플리케이션이 예상한 대로 작동하는지 확인합니다.
멀티 리전 배포는 가장 중요한 비즈니스 애플리케이션의 고가용성을 보장하는 데 도움이 될 수 있습니다. 여러 리전에 애플리케이션을 배포하는 것 외에도 오류 이벤트 중에 비즈니스 연속성을 보장하기 위해서는 추가적인 단계를 고려해야 합니다. 예를 들어 모든 리전에서 충분한 용량이 예약되도록 또는 긴급 자동 확장과 관련된 위험을 허용 가능한 수준으로 유지할 수 있도록 용량 계획을 수행해야 합니다. 또한 DR 테스트, 사고 관리, 사고 후 애플리케이션 상태 확인, 회고 분석 수행을 위한 운영 방침을 구현해야 합니다.