이 문서는 Google Cloud의 재해 복구(DR)를 설명하는 시리즈 중 6부입니다. 이 부분에서는 Google Cloud를 사용하여 워크로드를 설계하고 클라우드 인프라 서비스 중단에 대해 복원력이 우수한 구성 요소를 빌드하는 방법을 설명합니다.
시리즈는 다음 세 부분으로 구성됩니다.
- 재해 복구 계획 가이드
- 재해 복구 구성 요소
- 데이터의 재해 복구 시나리오
- 애플리케이션의 재해 복구 시나리오
- 지역별로 제한된 워크로드의 재해 복구 설계
- 클라우드 인프라 서비스 중단의 재해 복구 설계(이 문서)
소개
기업은 워크로드를 퍼블릭 클라우드로 이전할 때 복원력이 우수한 온프레미스 시스템의 빌드를 Google Cloud와 같은 클라우드 제공업체의 하이퍼스케일 인프라로 이해해야 합니다. 이 문서에서는 복구 시간 목표(RTO)와 복구 지점 목표(RPO)와 같은 재해 복구에 대한 업계 표준 개념을 Google Cloud 인프라에 매핑합니다.
이 문서의 안내에서는 매우 높은 서비스 가용성을 실현하기 위한 Google의 주요 원칙 중 하나인 '장애에 대비한 계획 세우기'를 따릅니다. Google Cloud는 매우 안정적인 서비스를 제공하지만 자연 재해, 광섬유 절단, 복잡하고 예측 불가능한 인프라 장애 등의 재해는 언제든지 발생할 수 있으며 이러한 재해는 서비스 중단을 야기합니다. 서비스 중단에 대한 계획을 수립한 Google Cloud 고객은 '기본 제공' DR 메커니즘을 통해 Google Cloud 제품을 사용하여 이러한 불가피한 이벤트가 발생한 상황에서도 예측 가능한 성능을 제공하는 애플리케이션을 빌드할 수 있습니다.
재해 복구에는 소프트웨어 버그나 데이터 손상과 같은 인프라 장애 이상의 광범위한 주제가 포함되므로 포괄적인 엔드 투 엔드 계획을 수립해야 합니다. 그러나 이 문서에서는 전체 DR 계획의 일부인 '클라우드 인프라 중단에 대해 복원력이 우수한 애플리케이션을 설계하는 방법'을 중점적으로 다룹니다. 특히 이 문서에서는 다음을 안내합니다.
- Google Cloud 인프라, 재해 이벤트가 Google Cloud 서비스 중단으로 나타나는 방식, 서비스 중단의 빈도와 범위가 최소화되도록 Google Cloud를 설계하는 방법
- 원하는 안정성 결과에 따라 애플리케이션을 분류하고 설계하는 프레임워크를 제공하는 아키텍처 계획 가이드
- 애플리케이션에 사용할 기본 제공 DR 기능을 제공하는 일부 Google Cloud 제품의 세부 목록
일반적인 DR 계획 및 온프레미스 DR 전략의 구성요소로 Google Cloud를 사용하는 방법에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요. 또한 고가용성은 재해 복구와 밀접하게 관련된 개념이지만 이 문서에서는 다루지 않습니다. 고가용성을 위한 설계에 대한 자세한 내용은 Google Cloud 아키텍처 프레임워크를 참조하세요.
용어에 대한 참고사항: 이 문서에서 가용성은 시간 경과에 따라 유의미한 방식으로 액세스하고 사용할 수 있는 제품의 기능을 의미하고 안정성은 가용성뿐 아니라 내구성 및 정확성 등의 다양한 속성을 의미합니다.
복원력이 우수한 Google Cloud를 설계하는 방법
Google 데이터 센터
기존 데이터 센터는 개별 구성요소의 가용성을 극대화하는 데 의존합니다. Google과 같은 운영자는 클라우드에서 확장 기능을 통해 가상화 기술을 사용하여 여러 구성요소로 서비스를 분산할 수 있으므로 구성요소의 안정성을 월등히 높일 수 있습니다. 즉, 안정성 아키텍처에 대한 사고방식을 온프레미스와 관련하여 우려했던 수많은 세부정보에서 탈피할 수 있습니다. 냉각 및 전력 공급과 같은 구성요소와 관련된 여러 오류 모드에 대해 걱정할 필요 없이 Google Cloud 제품과 해당 제품의 명시된 안정성 측정항목을 중심으로 계획을 세울 수 있습니다. 이러한 측정항목은 기본 인프라 전체의 총 서비스 중단 위험을 반영합니다. 덕분에 인프라 관리보다는 애플리케이션을 설계, 배포, 운영하는 데에만 집중할 수 있습니다.
Google은 현대적인 데이터 센터를 구축하고 운영하는 광범위한 경험을 바탕으로 공격적인 가용성 목표를 충족하도록 인프라를 설계합니다. Google은 데이터 센터 설계 부문의 선두 업체입니다. 전력에서 냉각, 그리고 네트워크에 이르기까지 각 데이터 센터 기술에는 FMEA 계획을 포함하여 자체 중복성 및 완화 기능이 포함되어 있습니다. Google의 데이터 센터는 이러한 다양한 위험 요소를 균형 있게 고려하여 고객에게 Google Cloud 제품의 예상되는 가용성 수준을 일관되게 제공하는 방식으로 구축되었습니다. Google은 자체 경험을 바탕으로 전체 물리적 및 논리적 시스템 아키텍처의 가용성을 모델링하여 데이터 센터 설계의 기대치를 충족시킵니다. Google의 엔지니어들은 이러한 기대치를 충족시키기 위해 운영 측면에서 많은 노력을 하고 있습니다. 일반적으로 실제 측정된 가용성은 여유 있게 설계 목표를 달성합니다.
Google Cloud는 이러한 모든 데이터 센터의 위험을 완화하는 기능을 사용자용 제품에 구현하여 사용자의 설계 및 운영 책임을 덜어줍니다. 따라서 Google Cloud 리전과 영역에 설계된 안정성에 집중할 수 있습니다.
리전과 영역
Google Cloud 제품은 수많은 리전 및 영역에 제공됩니다. 리전은 3개 이상의 영역으로 구성되는 물리적으로 독립된 지리적 위치입니다. 영역은 물리적 인프라와 논리적 인프라 측면에서 서로 독립성이 높은 리전 내의 물리적 컴퓨팅 리소스 그룹을 나타냅니다. 같은 리전의 다른 영역으로의 고대역폭, 낮은 지연 시간 네트워크 연결이 가능합니다. 예를 들어 일본의 asia-northeast1 리전에는 asia-northeast1-a, asia-northeast1-b, asia-northeast1-c의 3개 영역이 있습니다.
Google Cloud 제품은 영역별 리소스, 리전별 리소스, 멀티 리전 리소스로 나뉩니다.
영역별 리소스는 단일 영역 내에서 호스팅됩니다. 특정 영역의 서비스 중단은 해당 영역의 모든 리소스에 영향을 줄 수 있습니다. 예를 들어 Compute Engine 인스턴스는 지정된 단일 영역에서 실행됩니다. 하드웨어 오류로 해당 영역의 서비스가 중단되면 중단 기간 동안에는 Compute Engine 인스턴스를 사용할 수 없습니다.
리전별 리소스는 특정 리전 내의 여러 영역에 중복해서 배포되는 리소스입니다. 이 리소스는 영역별 리소스에 비해 안정성이 더 높습니다.
멀티 리전 리소스는 리전 내 그리고 리전 간에 분산됩니다. 일반적으로 멀티 리전 리소스는 리전별 리소스보다 안정성이 더 높습니다. 그러나 이 수준의 제품은 최적화된 가용성, 성능, 리소스 효율성을 제공합니다. 따라서 사용하려는 각 멀티 리전 제품의 장단점을 이해하는 것이 중요합니다. 이러한 장단점에 대해서는 이 문서의 뒷부분에서 제품별로 설명합니다.
영역과 리전을 활용하여 안정성 확보
Google SRE는 전 세계 컴퓨팅 인프라를 원활하게 활용하는 다양한 기법과 기술을 통해 Gmail 및 Google 검색과 같은 매우 안정적인 글로벌 사용자 제품을 관리하고 확장합니다. 여기에는 글로벌 부하 분산을 사용하여 사용 불가능한 위치의 트래픽을 리디렉션하고 전 세계 수많은 위치에서 여러 복제본을 실행하며 여러 위치에서 데이터를 복제하는 작업이 포함됩니다. Google Cloud 고객은 Cloud Load Balancing, Google Kubernetes Engine, Cloud Spanner와 같은 제품을 통해 동일한 기능을 사용할 수 있습니다.
Google Cloud는 일반적으로 영역 및 리전에 다음과 같은 가용성 수준을 제공하도록 제품을 설계합니다.
| 리소스 | 예시 | 가용성 설계 목표 | 암시적 다운타임 |
|---|---|---|---|
| 영역 | Compute Engine, Persistent Disk | 99.9% | 8.75시간/년 |
| 리전 | Regional Cloud Storage, 복제된 Persistent Disk, 리전별 Google Kubernetes Engine | 99.99% | 52분/년 |
Google Cloud 가용성 설계 목표를 허용되는 수준의 다운타임과 비교하여 적절한 Google Cloud 리소스를 식별합니다. 기존 설계는 애플리케이션의 가용성을 향상시키기 위해 구성요소 수준의 가용성을 개선하는 데 초점을 맞추지만 클라우드 모델은 이 목표를 달성하는 데 필요한 구성요소의 구성에 초점을 맞춥니다. Google Cloud에 포함된 많은 제품이 이 기법을 사용합니다. 예를 들어 Cloud Spanner는 99.999%의 가용성을 제공하기 위해 여러 리전을 구성하는 멀티 리전 데이터베이스를 제공합니다.
구성 없이는 애플리케이션 가용성이 사용 중인 Google Cloud 제품의 가용성을 능가할 수 없으므로 구성은 중요합니다. 실제로 애플리케이션이 절대 실패하지 않는다면 애플리케이션의 가용성은 기본 Google Cloud 제품보다 더 낮습니다. 이 섹션의 나머지 부분에서는 일반적으로 영역 및 리전 제품의 구성을 사용하여 단일 영역 또는 리전에서 제공하는 것보다 더 높은 애플리케이션 가용성을 달성하는 방법을 설명합니다. 다음 섹션에서는 이러한 원칙을 애플리케이션에 적용하기 위한 실무 가이드를 제공합니다.
영역 서비스 중단 범위 계획
일반적으로 인프라 오류가 발생하면 단일 영역에서 실행되는 서비스가 중단될 수 있습니다. 한 리전의 영역은 다른 영역과의 연관성 장애의 위험을 최소화하도록 설계되며 한 영역의 서비스 중단은 일반적으로 동일한 리전의 다른 영역에서 실행되는 서비스에 영향을 주지 않습니다. 서비스 중단 범위가 영역으로만 지정되어 있다고 해서 전제 영역을 사용할 수 없다는 의미는 아니며 이 범위는 단순히 이슈의 경계만 정의합니다. 영역의 서비스 중단은 해당 영역의 특정 리소스에 실질적인 영향을 주지 않을 수 있습니다.
드물지만 단일 리전 내의 여러 영역에서 결국 특정 시점에 서로 상관 관계가 있는 서비스 중단이 발생하게 될 것이라는 점도 중요합니다. 2개 이상의 영역에서 서비스 중단이 발생하면 아래의 리전별 서비스 중단 범위 전략이 적용됩니다.
리전별 리소스는 여러 영역의 구성에서 서비스를 제공하여 영역 서비스 중단을 방지하도록 설계되었습니다. 리전별 리소스를 지원하는 영역 중 하나가 중단되면 리소스는 자동으로 다른 영역에서 사용할 수 있게 됩니다. 자세한 내용을 알아보려면 부록의 제품 기능 설명을 주의 깊게 확인하세요.
Google Cloud는 Compute Engine 가상 머신(VM), Persistent Disk 등의 영역별 리소스만 제공합니다. 영역별 리소스를 사용하려면 여러 영역에 있는 영역별 리소스 간에 장애 조치 및 복구를 설계, 빌드, 테스트하여 자체 리소스 구성을 수행해야 합니다. 다음은 몇 가지 전략입니다.
- 상태 확인에서 영역에 문제가 발생한 것으로 확인되면 Cloud Load Balancing을 사용하여 트래픽을 다른 영역의 가상 머신으로 빠르게 라우팅합니다.
- Compute Engine 인스턴스 템플릿 또는 관리형 인스턴스 그룹을 사용하여 여러 영역에서 동일한 VM 인스턴스를 실행하고 확장합니다.
- 리전 Persistent Disk를 사용하여 리전 내 다른 영역으로 데이터를 동기식으로 복제합니다. 자세한 내용은 리전 PD를 사용하는 고가용성 옵션을 참조하세요.
리전 서비스 중단 범위 계획
리전 서비스 중단은 단일 리전 내 여러 영역에 영향을 미칩니다. 이러한 서비스 중단은 빈도는 낮지만 대규모로 발생하며 자연 재해나 대규모 인프라 오류로 인해 발생할 수 있습니다.
99.99%의 가용성을 제공하도록 설계된 리전 제품의 경우 서비스 중단이 매년 특정 제품에서 발생하는 1시간의 다운타임으로 해석될 수 있습니다. 따라서 이 서비스 중단이 허용되지 않는 경우에는 중요한 애플리케이션에 멀티 리전 DR 계획이 필요할 수 있습니다.
멀티 리전 리소스는 여러 리전에서 서비스를 제공하여 리전 서비스 중단을 방지하도록 설계되었습니다. 위의 설명대로 멀티 리전 제품에는 지연 시간, 일관성, 비용 간 균형이 필요합니다. 일반적인 예시는 동기식 및 비동기식 데이터 복제 간의 균형입니다. 비동기식 복제는 지연 시간은 낮지만 서비스 중단 시 데이터 손실이 발생할 수 있습니다. 자세한 내용을 알아보려면 부록의 제품 기능 설명을 확인하세요.
리전별 리소스를 사용하고 리전 서비스 중단에 대한 우수한 복원력을 유지하려면 여러 리전에 있는 리전별 리소스 간에 장애 조치 및 복구를 설계, 빌드, 테스트하여 자체 리소스 구성을 수행해야 합니다. 리전에 적용할 수 있는 위의 영역 전략 외에 다음을 고려하세요.
- 리전별 리소스는 보조 리전, Cloud Storage와 같은 Multi-Regional Storage 옵션, Anthos와 같은 하이브리드 클라우드 옵션에 데이터를 복제해야 합니다.
- 리전 서비스 중단 완화 기능이 있으면 정기적으로 테스트하세요. 단일 리전 서비스 중단에 강하다고 믿고 있다가 실제 상황에서 그렇지 않다는 것을 알게 되는 것보다 나쁜 것은 거의 없습니다.
Google Cloud의 복원력 및 가용성 접근 방식
Google Cloud는 정기적으로 가용성 설계 목표를 초과 달성하지만 이 강력한 과거 성능이 설계 가능한 최소 가용성이라고 가정해서는 안 됩니다. 대신 애플리케이션 다운타임과 Google Cloud 다운타임이 원하는 결과를 제공하도록 고안된 설계 목표가 애플리케이션의 의도한 안정성을 초과하는 Google Cloud 종속 항목을 선택해야 합니다.
잘 설계된 시스템은 '영역 또는 리전에 1, 5, 10 또는 30분 동안 서비스 중단이 발생하면 어떻게 되나요?'라는 질문에 답변할 수 있습니다. 이 질문을 비롯한 다음 질문들은 여러 레이어에서 고려해야 하는 요소입니다.
- 서비스 중단 시 고객은 어떤 경험을 하게 되나요?
- 서비스 중단이 발생한지 어떻게 알 수 있나요?
- 서비스 중단 시 내 애플리케이션은 어떻게 되나요?
- 서비스 중단 시 내 데이터는 어떻게 되나요?
- 교차 종속 항목으로 인한 서비스 중단 시 내 애플리케이션은 어떻게 되나요?
- 서비스 중단이 해결된 후 복구하려면 누가 어떤 조치를 취해야 하나요?
- 서비스 중단 시 언제까지 누구에게 알림을 전송해야 하나요?
Google Cloud 애플리케이션의 재해 복구 설계에 대한 단계별 가이드
이전 섹션에서는 Google이 클라우드 인프라를 구축하는 방법과 영역 및 리전 서비스 중단에 대처하는 여러 가지 접근 방식을 다뤘습니다.
이 섹션은 원하는 안정성 결과에 따라 구성 원칙을 애플리케이션에 적용하기 위한 프레임워크를 개발하는 데 유용합니다.
1단계: 기존 요구사항 수집하기
첫 번째 단계는 애플리케이션의 가용성 요구사항을 정의하는 것입니다. 대부분의 기업에는 이미 이 분야에 대한 몇 가지 수준의 설계 가이드가 있으며, 이 가이드는 내부적으로 개발되거나 규제 또는 다른 법적 요구사항에서 파생된 것입니다. 이 설계 가이드는 일반적으로 복구 시간 목표(RTO)와 복구 지점 목표(RPO)라는 2가지 주요 측정항목으로 작성됩니다. 비즈니스 관점에서 RTO는 '재해 발생 후 가동 및 실행까지 걸리는 시간'을 의미하고, RPO는 '재해 발생 시 감내할 수 있는 데이터 손실의 양'을 의미합니다.
지금까지 기업에서는 구성요소 오류에서 지진에 이르기까지 광범위한 재해 이벤트에 대해 RTO와 RPO 요구사항을 정의했습니다. 이 방식은 설계자가 전체 소프트웨어 및 하드웨어 스택을 통해 RTO/RPO 요구사항을 매핑해야 했던 온프레미스 환경에서는 적합했습니다. 클라우드에서는 제공업체가 세부정보를 처리하므로 더 이상 해당 세부정보를 사용하여 요구사항을 처리할 필요가 없습니다. 대신 근본적인 원인을 구체화하지 않고 손실 범위(전체 영역 또는 리전)를 기준으로 RTO 및 RPO 요구사항을 정의할 수 있습니다. Google Cloud의 경우 이렇게 하면 영역 서비스 중단, 리전 서비스 중단, 발생 확률이 매우 낮은 멀티 리전의 서비스 중단 등 3가지 시나리오로 요구사항을 간편하게 수집할 수 있습니다.
애플리케이션별로 중요도가 서로 다를 수 있다는 점을 인식하고 있는 대부분의 고객은 구체적인 RTO/RPO 요구사항을 적용할 수 있는 중요도 계층으로 애플리케이션을 분류합니다. RTO/RPO 및 애플리케이션 중요도를 종합하여 다음 질문에 답변하는 것으로 지정된 애플리케이션의 설계 프로세스를 효율화할 수 있습니다.
- 애플리케이션을 같은 리전의 여러 영역에서 실행해야 하나요? 아니면 여러 리전의 여러 영역에서 실행해야 하나요?
- 애플리케이션에 영향을 주는 Google Cloud 제품은 무엇인가요?
다음은 요구사항 수집 실습의 출력 예시입니다.
예시 조직 Co의 애플리케이션 중요도별 RTO 및 RPO:
| 애플리케이션 중요도 | 앱 비율 | 앱 예시 | 영역 서비스 중단 | 리전 서비스 중단 |
|---|---|---|---|---|
| 등급 1
(중요도 가장 높음) |
5% | 일반적으로 실시간 결제 및 전자상거래 매장과 같은 글로벌 또는 외부 고객 대상 애플리케이션입니다. | RTO 0
RPO 0 |
RTO 4시간
RPO 1시간 |
| 등급 2 | 35% | 일반적으로 리전 애플리케이션 또는 CRM이나 ERP와 같은 중요한 내부 애플리케이션입니다. | RTO 4시간
RPO 0 |
RTO 24시간
RPO 4시간 |
| 등급 3
(중요도 가장 낮음) |
60% | 일반적으로 백오피스, 예약, 내부 출장, 회계, 인사와 같은 팀 또는 부서 애플리케이션입니다. | RTO 12시간
RPO 24시간 |
RTO 28일
RPO 24시간 |
2단계: 사용 가능한 제품에 기능 매핑
두 번째 단계는 애플리케이션에서 사용할 Google Cloud 제품의 복원력을 이해하는 것입니다. 대부분의 기업에서는 관련 제품 정보를 검토한 후 제품 기능과 복원력 요구사항 사이의 모든 격차를 수용할 수 있도록 아키텍처를 수정하는 방법에 대한 가이드를 추가합니다. 이 섹션에서는 이 분야의 데이터 및 애플리케이션과 관련된 몇 가지 일반적인 내용과 권장사항을 설명합니다.
앞에서 설명한 것처럼 Google의 DR 지원 제품은 리전 및 영역이라는 두 가지 유형의 서비스 중단 범위를 광범위하게 충족합니다. 부분적 서비스 중단에 대한 DR은 전체 서비스 중단과 동일한 방식으로 계획되어야 합니다. 이렇게 해야 기본적으로 각 시나리오에 적합한 제품의 초기 상위 수준의 매트릭스를 확보할 수 있습니다.
Google Cloud 제품의 일반 기능
(구체적인 제품 기능은 부록 참조)
| 모든 Google Cloud 제품 | 영역 간 자동 복제 기능이 있는 리전 Google Cloud 제품 | 리전 간 자동 복제 기능이 있는 멀티 리전 또는 글로벌 Google Cloud 제품 | |
|---|---|---|---|
| 영역 내 구성요소 오류 | 포함* | 포함 | 포함 |
| 영역 서비스 중단 | 포함되지 않음 | 포함 | 포함 |
| 리전 서비스 중단 | 포함되지 않음 | 포함되지 않음 | 포함 |
* 제품 문서에 구체적으로 명시된 경우를 제외하고 모든 Google Cloud 제품은 구성요소 오류에 대해 우수한 복원력을 발휘합니다. 이러한 시나리오는 제품이 메모리 또는 SSD(Solid State Disk)과 같은 특수 하드웨어에 직접 액세스하거나 정적 매핑을 제공하는 경우에 일반적입니다.
RPO가 제품 선택을 제한하는 방법
대부분의 클라우드 배포에서 데이터 무결성은 아키텍처 측면에서 서비스에 대해 고려해야 할 가장 중요한 요소입니다. 일부 애플리케이션의 RPO 요구사항은 0이므로 서비스 중단 발생 시 데이터 손실이 발생해서는 안 됩니다. 이 경우 일반적으로 데이터를 다른 영역 또는 리전으로 동기식으로 복제해야 합니다. 동기식 복제에서는 비용과 지연 시간이 서로 상쇄되므로 많은 Google Cloud 제품이 영역 간 동기식 복제를 제공하며, 단 리전 간 복제는 단 몇 가지 제품에서만 제공됩니다. 이러한 비용과 복잡성의 상쇄를 통해 애플리케이션 내 다양한 데이터 유형의 RPO 값이 서로 다른 것이 드물지 않다는 것을 알 수 있습니다.
RPO가 0보다 큰 데이터의 경우 애플리케이션은 비동기식 복제를 활용할 수 있습니다. 비동기식 복제는 손실된 데이터를 간편하게 다시 생성할 수 있거나 필요한 경우 골든 데이터 소스에서 복구할 수 있을 때 허용됩니다. 이 옵션은 소량의 데이터 손실을 영역 및 리전의 예상 서비스 중단 기간에 대한 절충으로 받아들일 수 있을 경우에도 적합합니다. 또한 일시적인 서비스 중단 시 영향을 받는 위치에 기록되지만 아직 다른 위치에 복제되지 않은 데이터는 서비스 중단이 해결된 후 일반적으로 사용할 수 있습니다. 즉, 서비스 중단 시 영구적인 데이터 손실 위험은 데이터 액세스 손실 위험보다 낮습니다.
주요 조치: RPO가 반드시 0이어야 하는지, 그리고 그럴 경우 데이터의 일부에 대해 이 조치를 수행할 수 있는지 여부를 결정합니다. 그러면 사용 가능한 DR 지원 서비스 범위가 크게 늘어납니다. Google Cloud에서 RPO 0을 달성한다는 것은 애플리케이션에 주로 리전 제품을 사용한다는 것을 의미하며, 이 경우 기본적으로 영역 범위의 서비스 중단에 대해 우수한 복원력을 발휘하지만 리전 범위의 서비스 중단에는 그렇지 못합니다.
RTO가 제품 선택을 제한하는 방법
클라우드 컴퓨팅의 주요 이점 중 하나는 온디맨드 방식으로 구현할 수 있다는 것이지만, 이는 즉각적인 배포와는 다른 개념입니다. 애플리케이션의 RTO 값은 애플리케이션에서 활용하는 Google Cloud 제품의 통합 RTO와 VM 또는 애플리케이션 구성요소를 재시작하기 위해 엔지니어 또는 SRE가 수행해야 하는 모든 조치를 수용해야 합니다. 분 단위로 측정되는 RTO는 사람의 개입 없이 재해로부터 자동으로 복구되거나 버튼을 누르는 등의 최소한의 단계로 장애 조치되는 애플리케이션을 설계할 수 있다는 것을 의미합니다. 지금까지 이러한 시스템 종류의 비용과 복잡성은 매우 높았지만 부하 분산기와 인스턴스 그룹 같은 Google Cloud 제품을 사용하면 훨씬 더 저렴하고 간편한 방식으로 애플리케이션을 설계할 수 있습니다. 따라서 대부분의 애플리케이션에 대해 자동 장애 조치 및 복구를 고려해야 합니다. 여러 리전에 걸쳐 이러한 종류의 핫(hot) 장애 조치에 사용할 시스템을 설계하는 것은 복잡하고 비용이 많이 들 수 있습니다. 극히 일부의 중요한 서비스에서만 이 기능이 보장됩니다.
대부분의 애플리케이션은 1시간에서 1일 사이의 RTO를 제공합니다. 따라서 애플리케이션의 일부 구성요소는 데이터베이스와 같이 대기 모드에서도 항상 실행되는 반면 실제 재해 발생 시 웹 서버와 같은 다른 구성요소는 수평 확장되는 재해 시나리오에서 웜(warm) 장애 조치를 허용합니다. 이러한 애플리케이션의 경우 수평 확장 이벤트에 대한 자동화를 적극 고려해야 합니다. RTO가 하루 이상인 서비스는 중요도가 가장 낮으며 백업에서 복구하거나 처음부터 새로 만들 수 있습니다.
주요 조치: 리전 장애 조치의 RTO가 반드시 0이어야 하는지, 그리고 그럴 경우 데이터의 일부에 대해 이 조치를 수행할 수 있는지 여부를 결정합니다. 그러면 서비스를 실행하고 관리하는 비용이 변경됩니다.
3단계: 자체 참조 아키텍처 및 가이드 개발
마지막으로 권장되는 단계는 팀이 재해 복구 방식을 표준화하는 데 도움이 되는 기업별 아키텍처 패턴을 빌드하는 것입니다. 대부분의 Google Cloud 고객은 개발팀을 위해 Google Cloud의 두 가지 주요 서비스 중단 시나리오 카테고리에 대한 개별 비즈니스 복원력 기대치를 충족하는 가이드를 제공합니다. 팀은 이 가이드를 활용하여 각 중요도 수준에 적합한 DR 지원 제품을 쉽게 분류할 수 있습니다.
제품 가이드라인 작성
위의 RTO/RPO 예시 표를 다시 살펴보면 기본적으로 각 중요도 등급별로 허용되는 제품을 나열하는 가설 가이드가 있습니다. 기본적으로 특정 제품이 적합하지 않은 것으로 식별된 경우에는 언제든지 영역 간 또는 리전 간 동기화를 사용 설정하기 위해 자체 복제 및 장애 조치 메커니즘을 추가할 수 있습니다. 단, 이 실습은 이 문서 범위에 포함되지 않습니다. 또한 이 표에는 각 제품에 대한 추가 정보를 볼 수 있는 링크가 제공되므로 영역 및 리전 서비스 중단 관리와 관련된 제품의 기능을 이해하는 데 유용합니다.
조직 예시 Co의 샘플 아키텍처 패턴 - 영역 서비스 중단 복원력:
| Google Cloud 제품 | 제품이 예시 조직의 영역 서비스 중단 요구사항을 충족하는지 여부(적절한 제품 구성 포함) | ||
|---|---|---|---|
| 등급 1 | 등급 2 | 등급 3 | |
| Compute Engine | 예 | 예 | 예 |
| Dataflow | 아니요 | 아니요 | 아니요 |
| BigQuery | 아니요 | 아니요 | 예 |
| Google Kubernetes Engine | 예 | 예 | 예 |
| Cloud Storage | 예 | 예 | 예 |
| Cloud SQL | 아니요 | 있음 | 예 |
| Cloud Spanner | 예 | 예 | 예 |
| Cloud Load Balancing | 예 | 예 | 예 |
이 표는 위에 표시된 가상 등급을 기반으로 하는 예시일 뿐입니다.
조직 예시 Co의 샘플 아키텍처 패턴 - 리전 서비스 중단 복원력:
| Google Cloud 제품 | 제품이 예시 조직의 리전 서비스 중단 요구사항을 충족하는지 여부(적절한 제품 구성 포함) | ||
|---|---|---|---|
| 등급 1 | 등급 2 | 등급 3 | |
| Compute Engine | 예 | 예 | 예 |
| Dataflow | 아니요 | 아니요 | 아니요 |
| BigQuery | 아니요 | 아니요 | 예 |
| Google Kubernetes Engine | 예 | 예 | 예 |
| Cloud Storage | 아니요 | 아니요 | 아니요 |
| Cloud SQL | 예 | 예 | 예 |
| Cloud Spanner | 예 | 예 | 예 |
| Cloud Load Balancing | 예 | 예 | 예 |
이 표는 위에 표시된 가상 등급을 기반으로 하는 예시일 뿐입니다.
다음 섹션에서는 이러한 제품의 사용 방법을 보여주기 위해 각 가상 애플리케이션 중요도 수준에 대한 몇 가지 참조 아키텍처를 살펴봅니다. 이는 주요 아키텍처 결정을 설명하기 위해 의도적으로 개략적으로 구성한 설명이며 전체 솔루션 설계를 나타내지 않습니다.
등급 3 아키텍처 예시
| 애플리케이션 중요도 | 영역 서비스 중단 | 리전 서비스 중단 |
|---|---|---|
| 등급 3 (중요도 가장 낮음) |
RTO 12시간 RPO 24시간 |
RTO 28일 RPO 24시간 |
(회색으로 표시된 아이콘은 복구가 사용 설정된 인프라를 나타냅니다.)
이 아키텍처는 기존 클라이언트/서버 애플리케이션을 설명합니다. 내부 사용자는 영구 스토리지용 데이터베이스에 백업되는 컴퓨팅 인스턴스에서 실행 중인 애플리케이션에 연결됩니다.
이 아키텍처는 필요한 것보다 더 높은 RTO 및 RPO 값을 지원한다는 점에 주목해 주세요. 하지만 비용이 많이 발생하거나 신뢰할 수 없는 수동 단계는 추가하지 않는 것이 좋습니다. 예를 들어 야간 백업에서 데이터베이스를 복구하는 경우 24시간의 RPO를 지원할 수 있지만, 이 경우에는 대개 데이터베이스 관리자와 같은 숙련된 직원이 필요합니다. 단, 이러란 직원은 특히 여러 서버가 동시에 영향을 받는 경우에는 가용하지 않을 수 있습니다. Google Cloud의 온디맨드 인프라를 사용하면 큰 비용 부담 없이 이 기능을 빌드할 수 있으므로 이 아키텍처에서는 영역 서비스 중단 시 수동 백업/복원이 아닌 Cloud SQL HA를 사용합니다.
영역 서비스 중단에 대한 주요 아키텍처 결정 - RTO 12시간 및 RPO 24시간
- 내부 부하 분산기는 사용자에게 다른 영역으로의 자동 장애 조치를 허용하는 확장 가능한 액세스 포인트를 제공하는 데 사용됩니다. RTO가 12시간인 경우에도 IP 주소를 수동 변경하거나 DNS 업데이트를 처리하는 데 예상보다 시간이 오래 걸릴 수 있습니다.
- 리전 관리형 인스턴스 그룹은 여러 영역에서 최소한의 리소스로 구성됩니다. 이렇게 하면 비용에 맞게 최적화되지만 백업 영역에서 가상 머신을 빠르게 확장할 수도 있습니다.
- 고가용성 Cloud SQL 구성은 다른 영역으로의 자동 장애 조치를 기능을 제공합니다. 데이터베이스는 Compute Engine 가상 머신에 비해 재생성 및 복원이 훨씬 더 어렵습니다.
리전 서비스 중단에 대한 주요 아키텍처 결정 - RTO 28시간 및 RPO 24시간
- 부하 분산기는 리전 서비스 중단이 발생한 경우에만 리전 2에 구성됩니다. 리전 2의 인프라는 리전 서비스 중단이 발생한 경우에만 사용할 수 있으므로 Cloud DNS는 조정된 수동 리전 장애 조치를 기능을 제공하는 데 사용됩니다.
- 새로운 관리형 인스턴스 그룹은 리전 서비스 중단이 발생한 경우에만 구성됩니다. 이렇게 하면 비용에 맞게 최적화되지만 대부분의 리전 서비스 중단은 짧은 시간 동안 지속되므로 호출되지 않을 가능성이 높습니다. 편의상 다이어그램에는 재배포하는 데 필요한 관련 도구나 필요한 Compute Engine의 복사는 표시되어 있지 않습니다.
- 새 Cloud SQL 인스턴스가 재생성되고 백업에서 데이터가 복원됩니다. 한 리전에 대한 서비스 중단의 장기화 위험은 매우 낮으므로 이는 또 다른 비용 최적화 방법이 될 수 있습니다.
- 멀티 리전 Cloud Storage는 이러한 백업을 저장하는 데 사용됩니다. 이렇게 하면 RTO 및 RPO 내에 자동 영역 및 리전 복원력이 제공됩니다.
등급 2 아키텍처 예시
| 애플리케이션 중요도 | 영역 서비스 중단 | 리전 서비스 중단 |
|---|---|---|
| 등급 2 | RTO 4시간 RPO 0 |
RTO 24시간 RPO 4시간 |
이 아키텍처는 컴퓨팅 인스턴스 시각화 레이어에 연결된 내부 사용자가 있는 데이터 웨어하우스와 백엔드 데이터 웨어하우스를 채우는 데이터 수집 및 변환 레이어를 설명합니다.
이 아키텍처의 일부 개별 구성요소는 해당 등급에 필요한 RPO를 직접 지원하지 않습니다. 하지만 함께 사용되는 방식 때문에 전체 서비스가 RPO를 충족합니다. 이 경우 Dataflow가 영역 제품이므로 영역 서비스 중단 시 데이터 손실을 방지하기 위해 고가용성 설계 권장사항을 따라야 합니다. 그러나 Cloud Storage 레이어는 이 데이터의 골든 소스이며 RPO 0을 지원합니다. 즉, 영역 a에서 서비스 중단이 발생하면 손실된 데이터는 영역 b를 통해 BigQuery로 다시 수집됩니다.
영역 서비스 중단에 대한 주요 아키텍처 결정 - RTO 4시간 및 RPO 0
- 부하 분산기는 사용자에게 다른 영역으로의 자동 장애 조치를 허용하는 확장 가능한 액세스 포인트를 제공하는 데 사용됩니다. RTO가 4시간인 경우에도 IP 주소를 수동 변경하거나 DNS 업데이트를 처리하는 데 예상보다 시간이 오래 걸릴 수 있습니다.
- 데이터 시각화 컴퓨팅 레이어의 리전 관리형 인스턴스 그룹은 여러 영역에서 최소한의 리소스로 구성됩니다. 이렇게 하면 비용에 맞게 최적화되지만 가상 머신을 빠르게 확장할 수도 있습니다.
- 리전 Cloud Storage는 데이터의 초기 수집을 위한 스테이징 레이어로 사용되며, 자동 영역 복원력을 제공합니다.
- Dataflow는 Cloud Storage에서 데이터를 추출하고 BigQuery로 로드하기 전에 변환하는 데 사용됩니다. 영역 서비스 중단이 발생하면 이 스테이트리스(Stateless) 프로세스는 다른 영역에서 다시 시작할 수 있습니다.
- BigQuery는 데이터 시각화 프런트엔드를 위한 데이터 웨어하우스 백엔드를 제공합니다. 영역 서비스 중단이 발생하면 손실된 데이터는 Cloud Storage에서 다시 수집됩니다.
리전 서비스 중단에 대한 주요 아키텍처 결정 - RTO 24시간 및 RPO 4시간
- 각 리전의 부하 분산기는 사용자에게 확장 가능한 액세스 포인트를 제공하는 데 사용됩니다. 리전 2의 인프라는 리전 서비스 중단이 발생한 경우에만 사용할 수 있으므로 Cloud DNS는 조정된 수동 리전 장애 조치를 기능을 제공하는 데 사용됩니다.
- 데이터 시각화 컴퓨팅 레이어의 리전 관리형 인스턴스 그룹은 여러 영역에서 최소한의 리소스로 구성됩니다. 부하 분산기를 다시 구성하기 전에는 이 그룹에 액세스할 수 없지만 그 외의 경우에는 수동 개입이 필요하지 않습니다.
- 리전 Cloud Storage는 데이터의 초기 수집을 위한 스테이징 레이어로 사용됩니다. 이는 RPO 요구사항을 충족하기 위해 두 리전에 동시 로드됩니다.
- Dataflow는 Cloud Storage에서 데이터를 추출하고 BigQuery로 로드하기 전에 변환하는 데 사용됩니다. 리전 서비스 중단이 발생하면 BigQuery가 Cloud Storage의 최신 데이터로 채워집니다.
- BigQuery는 데이터 웨어하우스 백엔드를 제공합니다. 정상 작동 중에는 간헐적으로 새로고침됩니다. 리전 서비스 중단이 발생하면 최신 데이터는 Dataflow를 통해 Cloud Storage에서 다시 수집됩니다.
등급 1 아키텍처 예시
| 애플리케이션 중요도 | 영역 서비스 중단 | 리전 서비스 중단 |
|---|---|---|
| 등급 1 (중요도 가장 높음) |
RTO 0 RPO 0 |
RTO 4시간 RPO 1시간 |
이 아키텍처는 Google Kubernetes Engine에서 실행되는 마이크로서비스 세트에 외부 사용자가 연결되는 모바일 앱 백엔드 인프라를 설명합니다. Cloud Spanner는 실시간 데이터를 위한 백엔드 데이터 스토리지 레이어를 제공하고 이전 데이터는 각 리전의 BigQuery 데이터 레이크로 스트리밍됩니다.
다시 말하자면, 이 아키텍처의 일부 개별 구성요소는 해당 등급에 필요한 RPO를 직접 지원하지 않습니다. 하지만 함께 사용되는 방식 때문에 전체 서비스가 RPO를 충족합니다. 이 경우 BigQuery는 분석 쿼리에 사용됩니다. 각 리전은 Cloud Spanner에서 동시에 공급됩니다.
영역 서비스 중단에 대한 주요 아키텍처 결정 - RTO 0 및 RPO 0
- 부하 분산기는 사용자에게 다른 영역으로의 자동 장애 조치를 허용하는 확장 가능한 액세스 포인트를 제공하는 데 사용됩니다.
- 리전 Google Kubernetes Engine 클러스터는 여러 영역으로 구성된 애플리케이션 레이어에 사용됩니다. 이렇게 하면 각 리전의 RTO가 0이 됩니다.
- 멀티 리전 Cloud Spanner는 데이터 지속성 레이어로 사용되며, 자동 영역 데이터 복원력 및 트랜잭션 일관성을 제공합니다.
- BigQuery는 애플리케이션을 위한 분석 기능을 제공합니다. 각 리전은 Cloud Spanner에서 독립적으로 제공되는 데이터로, 애플리케이션에서 독립적으로 액세스할 수 있습니다.
리전 서비스 중단에 대한 주요 아키텍처 결정 - RTO 4시간 및 RPO 1시간
- 부하 분산기는 사용자에게 다른 리전으로의 자동 장애 조치를 허용하는 확장 가능한 액세스 포인트를 제공하는 데 사용됩니다.
- 리전 Google Kubernetes Engine 클러스터는 여러 영역으로 구성된 애플리케이션 레이어에 사용됩니다. 리전 서비스 중단이 발생하면 대체 리전의 클러스터가 자동으로 확장되어 추가 처리 로드를 처리합니다.
- 멀티 리전 Cloud Spanner는 데이터 지속성 레이어로 사용되며, 자동 리전 데이터 복원력 및 트랜잭션 일관성을 제공합니다. 이는 리전 간 RPO 1시간을 달성하는 데 필요한 핵심 구성요소입니다.
- BigQuery는 애플리케이션을 위한 분석 기능을 제공합니다. 각 리전은 Cloud Spanner에서 독립적으로 제공되는 데이터로, 애플리케이션에서 독립적으로 액세스할 수 있습니다. 이 아키텍처는 BigQuery 구성요소를 보완하여 전체 애플리케이션 요구사항을 충족합니다.
부록: 제품 참조
이 섹션에서는 고객 애플리케이션에서 사장 일반적으로 사용되며 DR 요구사항을 충족하는 데 쉽게 활용할 수 있는 Google Cloud 제품의 아키텍처 및 DR 기능을 설명합니다.
공통된 주제
많은 Google Cloud 제품이 리전 또는 멀티 리전 구성을 제공합니다. 리전 제품은 영역 서비스 중단에 대한 복원력이 우수하고 멀티 리전 및 글로벌 제품은 리전 서비스 중단에 대한 복원력이 우수합니다. 일반적으로 이는 서비스 중단 시 애플리케이션 중단이 최소화된다는 의미입니다. Google은 위의 아키텍처 가이드를 반영하는 몇 가지 일반적인 아키텍처 접근 방식으로 이러한 결과를 얻습니다.
- 중복 배포: 애플리케이션 백엔드 및 데이터 스토리지는 한 리전 내의 여러 영역과 멀티 리전 위치 내의 여러 리전에 걸쳐 배포됩니다.
데이터 복제: 제품은 중복 위치에서 동기식 또는 비동기 복제를 사용합니다.
동기식 복제는 애플리케이션이 제품에 저장된 데이터를 생성하거나 수정하기 위해 API 호출을 수행할 때 제품이 데이터를 여러 위치에 쓴 경우에만 성공 응답을 수신한다는 것을 의미합니다. 동기식 복제를 사용하면 사용 가능한 백엔드 위치 중 하나에서 모든 데이터를 사용할 수 있기 때문에 Google Cloud 인프라 서비스가 중단된 동안에도 모든 데이터에 대한 액세스 권한이 손실되지 않습니다.
이 기법을 사용하면 최대한의 데이터가 보호되지만 지연 시간 및 성능 측면에 영향을 미칠 수 있습니다. 동기식 복제를 사용하는 멀티 리전 제품은 이러한 상충 관계의 영향을 가장 크게 받으며, 일반적으로 지연 시간이 수십 또는 수백 밀리초 단위로 증가합니다.
비동기식 복제는 애플리케이션이 제품에 저장된 데이터를 생성하거나 수정하기 위해 API 호출을 수행할 때 제품이 데이터를 단일 위치에 쓴 경우 성공 응답을 수신한다는 것을 의미합니다. 쓰기 요청 후 제품은 추가 위치에 데이터를 복제합니다.
이 기법은 동기식 복제에 비해 API에서의 대기 시간이 짧고 처리량이 높지만 데이터를 제대로 보호하지 못할 수 있습니다. 복제를 완료하기 전에 데이터를 쓴 위치에 서비스 중단이 발생하면 해당 위치의 서비스 중단이 해결될 때까지 데이터에 액세스할 수 없게 됩니다.
부하 분산으로 서비스 중단 처리: Google Cloud는 소프트웨어 부하 분산을 사용하여 적절한 애플리케이션 백엔드로 요청을 라우팅합니다. DNS 부하 분산과 같은 다른 접근 방식과 달리 이 접근 방식은 시스템 응답 시간을 서비스 중단 시점까지 줄여줍니다. Google Cloud 위치에 서비스 중단이 발생하면 부하 분산기는 해당 위치에 배포된 백엔드가 '비정상'을 전환되었음을 감지하고 대체 위치의 백엔드로 모든 요청을 전달합니다. 그러면 제품은 특정 위치의 서비스가 중단된 동안에도 애플리케이션의 요청을 계속 처리할 수 있습니다. 위치의 서비스 중단이 해결되면 부하 분산기는 해당 위치에서 제품 백엔드의 가용성을 감지하고 이 위치로 트래픽을 다시 보내기 시작합니다.
Compute Engine
Compute Engine은 Google Cloud의 Infrastructure as a Service로, Google의 글로벌 인프라를 사용하여 가상 머신과 관련 서비스를 고객에게 제공합니다.
Compute Engine 인스턴스는 영역별 리소스이므로 영역 서비스 중단 발생 시 인스턴스가 기본으로 제공되지 않습니다. Compute Engine은 단일 영역 내 및 단일 리전 내 여러 영역에서 사전 구성된 인스턴스 템플릿의 추가 VM을 자동으로 확장할 수 있는 관리형 인스턴스 그룹(MIG)입니다. MIG는 영역 손실에 대해 복원력이 우수하고 스테이트리스(Stateless)이지만 구성 및 리소스 계획이 필요한 애플리케이션에 적합합니다. 스테이트리스(Stateless) 애플리케이션의 리전 서비스 중단을 복원하는 데 여러 리전 MIG를 사용할 수 있습니다.
스테이트풀(Stateful) 워크로드가 있는 애플리케이션도 스테이트풀(Stateful) MIG(베타)를 사용할 수 있지만 수평으로 확장되지 않기 때문에 용량 계획 시 특히 주의해야 합니다. 어느 시나리오에서든 Compute Engine 인스턴스 템플릿과 MIG를 올바르게 구성하고 테스트하여 다른 영역으로의 장애 조치가 제대로 작동하는지 사전에 확인하는 것이 중요합니다. 자세한 내용은 위의 아키텍처 패턴 섹션을 참조하세요.
Dataproc
Dataproc은 스트리밍 및 일괄 데이터 처리 기능을 제공합니다. Dataproc은 사용자가 Dataproc 클러스터를 관리할 수 있게 해주는 리전 제어 영역으로 설계되었습니다. 제어 영역은 지정된 리전의 개별 영역과 관계없습니다. 따라서 영역 서비스 중단이 발생해도 새 클러스터 생성 기능을 포함하여 Dataproc API에 대한 액세스 권한은 유지됩니다.
클러스터는 Compute Engine에서 실행됩니다. 클러스터는 영역별 리소스이므로 영역 서비스 중단 발생 시 클러스터를 사용할 수 없거나 클러스터가 삭제됩니다. Dataproc은 클러스터 상태에 대한 스냅샷을 자동으로 만들지 않으므로 영역 서비스 중단으로 인해 데이터가 손실될 수 있습니다. Dataproc은 서비스 내에 사용자 데이터를 유지하지 않습니다. 사용자는 여러 데이터 저장소에 결과를 기록하도록 파이프라인을 구성할 수 있습니다. 단, 데이터 저장소의 아키텍처를 고려하고 필요한 재해 복원력을 갖춘 제품을 선택해야 합니다.
영역에 서비스 중단이 발생하면 다른 영역을 선택하거나 사용 가능한 영역을 자동으로 선택하는 Dataproc의 자동 배치 기능을 사용하여 다른 영역에서 클러스터의 새 인스턴스를 다시 만들 수 있습니다. 클러스터를 사용할 수 있게 되면 데이터 처리가 다시 시작됩니다. 고가용성 모드가 사용 설정된 클러스터를 실행하면 부분 영역 서비스 중단이 마스터 노드와 전체 클러스터에 영향을 줄 가능성이 줄어듭니다.
Dataflow
Dataflow는 스트리밍 및 일괄 파이프라인을 위한 Google Cloud의 완전 관리형 서버리스 데이터 처리 서비스입니다. 기본적으로 Dataflow 작업은 영역별이며 기본 구성에는 영역 서비스가 중단된 동안의 중간 계산 결과가 저장되지 않습니다. 기본 Dataflow 파이프라인의 일반적인 복구 방법은 다른 영역 또는 리전에서 작업을 다시 시작한 후 입력 데이터를 다시 재처리하는 것입니다.
고가용성을 위한 Dataflow 파이프라인 설계
영역 또는 리전 서비스 중단 발생 시 동일한 Pub/Sub 주제 구독을 재사용하여 데이터 손실을 방지할 수 있습니다. Dataflow는 한 번의 정확한 처리를 보장하기 위해 메시지가 대상에 유지되거나 그룹화/기간 설정 작업을 통해 Dataflow의 내구성 있는 파이프라인 상태로 저장된 경우에만 Pub/Sub의 메시지 수신을 확인합니다. 그룹화/기간 설정 작업이 없는 경우 구독을 재사용하여 다른 영역 또는 리전의 다른 Dataflow 작업으로 장애 조치하면 파이프라인 출력 데이터의 데이터가 손실되지 않습니다.
파이프라인에서 그룹화 또는 기간 설정을 사용하는 경우 영역 또는 리전 서비스 중단 후 Pub/Sub의 탐색 기능 또는 Kafka의 재생 기능을 사용하여 데이터 요소가 동일한 계산 결과에 도달하도록 재처리할 수 있습니다. 파이프라인에 사용된 비즈니스 로직이 서비스 중단 전의 데이터와 관계없다면 파이프라인 출력의 데이터 손실을 0개 요소까지 최소화할 수 있습니다. 예를 들어 긴 슬라이드 기간을 사용하거나 전역 기간에 계속 증가하는 카운터가 저장되는 경우와 같이 파이프라인 비즈니스 로직이 서비스 중단 전에 처리된 데이터와 관계있는 경우 Dataflow는 파이프라인 상태에 대한 스냅샷 백업을 제공하는 스냅샷 생성 기능(현재 미리보기 제공 중)을 제공합니다.
BigQuery
BigQuery는 확장성이 뛰어난 서버리스 저비용 클라우드 데이터 웨어하우스로, 비즈니스 민첩성을 제공하도록 설계되었습니다. BigQuery는 사용자 데이터 세트에 대해 2가지의 가용성 관련 구성 옵션을 지원합니다.
단일 리전 구성
단일 리전 구성에서 데이터는 단일 리전 내 두 영역에 중복으로 저장됩니다. BigQuery에 쓴 데이터는 먼저 기본 영역에 기록된 후 보조 영역에 비동기식으로 복제됩니다. 이렇게 하면 리전 내 단일 영역의 사용 불능 상황을 막아줍니다. 기본 영역에 기록되었지만 영역 서비스 중단 발생 시점에 영역에 복제되지 않은 데이터는 서비스 중단이 해결될 때까지 사용할 수 없습니다. 드물지만 영역이 폐기되는 경우 해당 데이터가 영구적으로 손실될 수 있습니다.
멀티 리전(미국/EU) 구성
단일 리전 구성과 마찬가지로 미국/EU 멀티 리전 구성에서 데이터는 한 리전 내 두 영역에 중복으로 저장됩니다. 또한 BigQuery는 두 번째 리전에 데이터의 추가 백업 사본을 보관합니다. 기본 리전에 서비스 중단이 발생하면 보조 리전에서 데이터가 제공됩니다. 복제되지 않은 데이터는 기본 리전이 복원될 때까지 사용할 수 없습니다.
Google Kubernetes Engine
Google Kubernetes Engine(GKE)은 Google Cloud에서 컨테이너화된 애플리케이션의 배포 과정을 간소화하여 관리형 Kubernetes 서비스를 제공합니다. 리전 또는 영역 클러스터 토폴로지 중에서 선택할 수 있습니다.
- 영역 클러스터를 만들 때 GKE는 선택된 영역에 1개의 제어 영역 머신과 동일한 영역 내에 작업자 머신(노드)을 프로비저닝합니다.
- 리전 클러스터의 경우 GKE는 선택된 리전 내 3개 영역에서 3개의 제어 영역 머신을 프로비저닝합니다. 기본적으로 노드는 3개 영역에 걸쳐 있지만 한 영역에서만 프로비저닝된 노드를 사용하여 리전 클러스터를 만들 수 있습니다.
- 멀티 영역 클러스터는 하나의 마스터 머신을 포함하고 있다는 점에서 영역 클러스터와 비슷하지만 여러 영역에 걸쳐 있는 노드를 포괄하는 기능을 추가로 제공합니다.
영역 서비스 중단: 영역 서비스 중단을 방지하려면 리전 클러스터를 사용하세요. 제어 영역과 노드는 한 리전에 있는 3개 영역에 배포됩니다. 영역 서비스 중단은 다른 두 영역에 배포된 제어 영역과 워커 노드에는 영향을 미치지 않습니다.
리전 서비스 중단: 리전 서비스 중단을 완화하려면 여러 리전에 배포해야 합니다. 현재 기본 제공 제품 기능으로 제공되지는 않지만 여러 GKE 고객이 멀티 리전 토폴로지를 채택하고 있으며 이 접근 방식은 수동으로 구현할 수 있습니다. 여러 리전 클러스터를 생성하여 여러 리전에 걸쳐 워크로드를 복제하고 멀티 클러스터 인그레스를 사용하여 이러한 클러스터에 대한 트래픽을 제어할 수 있습니다.
Cloud Key Management Service
Cloud Key Management Service(Cloud KMS)는 확장 가능하고 견고한 암호화 키 리소스 관리를 제공합니다. Cloud KMS는 동기식 복제를 통해 높은 데이터 내구성과 가용성을 제공하는 Cloud Spanner 데이터베이스에 모든 데이터와 메타데이터를 저장합니다.
Cloud KMS 리소스는 단일 리전, 여러 리전 또는 전역에서 만들 수 있습니다.
영역 서비스 중단 발생 시 Cloud KMS는 같은 리전의 다른 영역 또는 다른 리전의 요청을 중단 없이 계속 처리합니다. 데이터는 동기식으로 복제되기 때문에 데이터가 손실되거나 손상되지 않습니다. 영역 서비스 중단이 해결되면 전체 중복성이 복원됩니다.
리전 서비스 중단이 발생한 경우 해당 리전을 다시 사용할 수 있을 때까지 해당 리전의 리전별 리소스는 오프라인 상태가 됩니다. 리전 내에서도 3개 이상의 복제본은 별도의 영역에서 유지관리됩니다. 높은 가용성이 필요한 경우 리소스를 멀티 리전 또는 글로벌 구성에 저장해야 합니다. 멀티 리전 및 전역 구성은 둘 이상의 리전에 데이터를 지리적으로 중복해 저장하고 제공하여 리전 서비스 중단에도 계속 사용할 수 있도록 설계되었습니다.
Cloud ID
Cloud ID 서비스는 여러 리전에 배포되며 동적 부하 분산을 사용합니다. Cloud ID에서는 사용자가 리소스 범위를 선택할 수 없습니다. 특정 영역 또는 리전에서 서비스 중단이 발생하면 트래픽은 다른 영역 또는 리전으로 자동 배포됩니다.
대부분의 경우 영구 데이터는 동기식 복제를 사용하여 여러 리전에서 미러링됩니다. 캐시 또는 수많은 항목에 영향을 미치는 변경사항 등 성능상의 이유로 일부 시스템은 여러 리전에 걸쳐 비동기식으로 복제됩니다. 최신 데이터가 저장되는 기본 리전에 서비스 중단이 발생하면 Cloud ID는 기본 리전을 사용할 수 있을 때까지 다른 위치에서 비활성 데이터를 제공합니다.
Persistent Disk
Persistent Disk는 영역 및 리전 구성에서 사용할 수 있습니다.
영역 Persistent Disk는 단일 영역에서 호스팅됩니다. 디스크의 영역을 사용할 수 없는 경우 영역 서비스 중단이 해결될 때까지 Persistent Disk를 사용할 수 없습니다.
리전 Persistent Disk는 리전의 두 영역 간에 데이터를 동기식으로 복제합니다. 가상 머신의 영역에 서비스 중단이 발생하면 디스크의 보조 영역에 있는 VM 인스턴스에 리전 Persistent Disk를 강제 연결할 수 있습니다. 이 작업을 수행하려면 해당 영역에서 다른 VM 인스턴스를 시작하거나 해당 영역에서 상시 대기 VM 인스턴스를 유지해야 합니다.
Cloud Storage
Cloud Storage는 확장성과 내구성이 우수하며 전 세계적으로 통합된 객체 스토리지입니다. Cloud Storage 버킷은 한 대륙 내 단일 리전, 이중 리전 또는 멀티 리전에 생성할 수 있습니다.
영역에 서비스 중단이 발생하면 사용 불가능한 영역의 데이터는 해당 리전의 다른 위치에서 자동으로 투명하게 제공됩니다. 데이터와 메타데이터는 초기 쓰기부터 여러 영역에 중복으로 저장됩니다. 영역을 사용할 수 없게 되어도 기록된 데이터는 손실되지 않습니다.
리전 서비스 중단이 발생한 경우 해당 리전을 다시 사용할 수 있을 때까지 해당 리전의 리전 버킷은 오프라인 상태가 됩니다. 높은 가용성이 필요한 경우 데이터를 이중 리전 또는 멀티 리전 구성에 저장해야 합니다. 듀얼 리전 및 멀티 리전은 동기식 복제를 사용하여 둘 이상의 리전에 데이터를 지리적으로 중복해 저장하여 리전 서비스 중단에도 계속 사용할 수 있도록 설계되었습니다.
Cloud Storage는 Cloud Load Balancing을 사용하여 이중 리전 버킷 및 여러 리전의 멀티 리전 버킷을 제공합니다. 리전 서비스 중단이 발생해도 제공은 중단되지 않습니다. 지리적 중복성은 비동기식으로 달성되기 때문에 서비스 중단 시 최근 쓴 일부 데이터에 액세스할 수 없으며 해당 리전의 데이터가 물리적으로 파기될 경우 손실될 수 있습니다.
Container Registry
Container Registry는 안전한 비공개 방식으로 Docker 컨테이너 이미지를 저장하는 확장 가능한 호스팅된 Docker 레지스트리를 구현합니다. Container Registry는 HTTP Docker Registry API를 구현합니다.
Container Registry는 기본적으로 이미지 메타데이터를 여러 영역 및 리전에 중복 저장하는 글로벌 서비스입니다. 컨테이너 이미지는 Cloud Storage 멀티 리전 버킷에 저장됩니다. 이 스토리지 전략을 통해 Container Registry는 모든 경우에 대해 영역 서비스 중단 복원력을 제공하고, Cloud Storage에서 여러 리전에 비동기적으로 복제한 모든 데이터에 대해서는 리전 서비스 중단 복원력을 제공합니다.
Pub/Sub
Pub/Sub는 애플리케이션 통합 및 스트림 분석을 위한 메시징 서비스입니다. Pub/Sub 주제는 전역 리소스이므로 모든 Google Cloud 위치에서 해당 주제를 보고 액세스할 수 있습니다. 그러나 특정 메시지는 리소스 위치 정책에 따라 게시자와 가장 가까운 단일 Google Cloud 리전에 저장됩니다. 따라서 하나의 주제에는 Google Cloud 전반의 여러 리전에 저장된 메시지가 있을 수 있습니다. Pub/Sub 메시지 스토리지 정책은 메시지가 저장되는 리전을 제한할 수 있습니다.
영역 서비스 중단: Pub/Sub 메시지가 게시되면 이 메시지는 리전 내의 2개 이상의 영역에 있는 스토리지에 동기식으로 기록됩니다. 따라서 단일 영역을 사용할 수 없게 되어도 고객은 영향을 받지 않습니다.
리전 서비스 중단: 리전 서비스 중단 시 영향을 받는 리전 내에 저장된 메시지에는 액세스할 수 없습니다. 주제 및 구독의 생성 및 삭제와 같은 관리 작업은 멀티 리전 리소스이며 단일 Google Cloud 영역의 서비스 중단에 대한 복원력이 우수합니다. 메시지 스토리지 정책에 따라 1개 이상의 리전을 사용할 수 있고 애플리케이션에 전역 엔드포인트(pubsub.googleapis.com) 또는 여러 리전별 엔드포인트가 사용되는 경우에는 리전 서비스 중단에 대한 게시 작업의 복원력이 우수합니다.
기본적으로 Pub/Sub는 메시지 스토리지 위치를 제한하지 않습니다.
애플리케이션에 메시지 순서 지정이 사용되는 경우 Pub/Sub 팀의 세부 권장사항을 참조하세요. 메시지 순서 지정 보장은 리전별 기준에 따라 제공되며, 전역 엔드포인트를 사용할 경우에는 중단될 수 있습니다.
Cloud Composer
Cloud Composer는 Google Cloud의 관리형 Apache Airflow 구현입니다. Cloud Composer는 사용자가 Cloud Composer 클러스터를 관리할 수 있게 해주는 리전 제어 영역으로 설계되었습니다. 제어 영역은 지정된 리전의 개별 영역과 관계없습니다. 따라서 영역 서비스 중단이 발생해도 새 클러스터 생성 기능을 포함하여 Cloud Composer API에 대한 액세스 권한은 유지됩니다.
클러스터는 Google Kubernetes Engine에서 실행됩니다. 클러스터는 영역별 리소스이므로 영역 서비스 중단 발생 시 클러스터를 사용할 수 없거나 클러스터가 삭제됩니다. 서비스 중단 시점에 실행 중인 워크플로는 완료 전에 중지될 수 있습니다. 즉, 서비스 중단이 발생하면 사용자가 수행하도록 워크플로를 구성한 외부 조치를 포함하여 부분적으로 실행된 워크플로의 상태가 손실됩니다. 워크플로에 따라 외부 데이터 저장소를 수정하는 다단계의 실행 과정 도중에 워크플로가 중지되는 경우와 같이 외부적으로 불일치가 발생할 수 있습니다. 따라서 부분적으로 실행되지 않은 워크플로 상태를 감지하고 부분적 데이터 변경사항을 복구하는 방법 등 Airflow 워크플로를 설계할 때 복구 프로세스를 고려해야 합니다.
영역 서비스 중단 시 Cloud Composer를 사용하여 다른 영역에서 클러스터의 새 인스턴스를 시작할 수 있습니다. 클러스터를 사용할 수 있게 되면 워크플로가 다시 시작됩니다. 환경설정에 따라 다른 영역에서 유휴 복제본 클러스터를 실행하고 영역 서비스 중단 발생 시 해당 복제본으로 전환할 수 있습니다.
Cloud SQL
Cloud SQL은 MySQL, PostgreSQL, SQL Server를 위한 완전 관리형 관계형 데이터베이스 서비스입니다. Cloud SQL은 관리형 Compute Engine 가상 머신을 사용하여 데이터베이스 소프트웨어를 실행합니다. 또한 리전 중복을 위해 고가용성 구성을 제공하므로 영역 서비스 중단으로부터 데이터베이스를 보호합니다. 리전 간 복제본을 프로비저닝하여 리전 서비스 중단으로부터 데이터베이스를 보호할 수 있습니다. 이 제품은 영역 또는 리전 서비스 중단에 대한 복원력이 낮은 영역 옵션도 제공하므로 고가용성 구성, 리전 간 복제본, 또는 둘 다 선택할 때는 주의해야 합니다.
영역 서비스 중단: 고가용성 옵션은 한 리전 내 2개의 별도 영역에 기본 및 대기 VM 인스턴스를 만듭니다. 정상 작동 중에 기본 VM 인스턴스는 모든 요청을 처리하여 기본 및 대기 영역에 동기식으로 복제되는 리전 Persistent Disk에 데이터베이스 파일을 씁니다. 영역 서비스 중단이 기본 인스턴스에 영향을 미치는 경우 Cloud SQL은 Persistent Disk가 대기 VM에 연결되고 트래픽이 다시 라우팅되는 동안 장애 조치를 시작합니다.
이 프로세스 도중 데이터베이스를 초기화해야 하며, 여기에는 트랜잭션 로그에 기록되지만 데이터베이스에는 적용되지 않는 모든 트랜잭션 처리가 포함됩니다. 처리되지 않은 트랜잭션의 수와 유형에 따라 RTO 시간이 늘어날 수 있습니다. 최근 쓰기가 많으면 처리되지 않은 트랜잭션의 백로그가 발생할 수 있습니다. (a) 최근 쓰기 활동이 많거나 (b) 데이터베이스 스키마를 최근 변경한 경우 RTO 시간에 가장 큰 영향을 미칩니다.
마지막으로 영역 서비스 중단이 해결되었으면 수동으로 장애 복구 작업을 트리거하여 기본 영역에서 서비스 제공을 재개할 수 있습니다.
고가용성 옵션에 대한 자세한 내용은 Cloud SQL 고가용성 문서를 참조하세요.
리전 서비스 중단: 리전 간 복제본 옵션은 다른 리전에 있는 기본 인스턴스의 읽기 복제본을 만들어 리전 서비스 중단으로부터 데이터베이스를 보호합니다. 리전 간 복제는 비동기식 복제를 사용하므로 기본 인스턴스가 복제본에서 커밋되기 전에 트랜잭션을 커밋할 수 있습니다. 트랜잭션이 기본 인스턴스에서 커밋되는 시점과 복제본에서 커밋되는 시점 간의 시간 차이를 '복제 지연'이라고 부르며, 이는 모니터링할 수 있습니다. 이 측정항목은 기본 인스턴스에서 복제본으로 전송되지 않은 트랜잭션과 복제본에서 수신했지만 처리되지 않은 트랜잭션을 모두 반영합니다. 리전 서비스 중단 시 복제본으로 전송되지 않은 트랜잭션을 사용할 수 없게 됩니다. 복제본에서 수신했지만 처리하지 않은 트랜잭션은 아래의 설명대로 복구 시간에 영향을 미칩니다.
Cloud SQL은 복제 지연이 누적되지 않으며 가장 높게 지속되는 TPS인 '안전한 TPS(Transaction Per Second)' 한도를 설정하기 위해 복제본이 포함된 구성으로 워크로드를 테스트할 것을 권장합니다. 워크로드가 안전한 TPS 한도를 초과하면 복제 지연이 누적되어 RPO 및 RTO 값에 부정적인 영향을 미칩니다. 일반적으로 복제 지연에 민감한 소규모 인스턴스 구성(vCPU 코어 2개 미만, 디스크 100GB 미만, PD-HDD)은 사용하지 않는 것이 좋습니다.
리전 서비스 중단이 발생하면 읽기 복제본을 수동으로 승격할지 여부를 결정해야 합니다. 승격은 수동 작업인데, 승격 시점에 기본 인스턴스가 지연되어도 승격된 복제본이 새로운 트랜잭션을 허용하는 분할 브레인 시나리오가 발생할 수 있기 때문입니다. 이로 인해 리전 서비스 중단이 해결될 때 문제가 발생할 수 있으며 기본 인스턴스에서 복제본 인스턴스로 절대 전파되지 않는 트랜잭션을 조정해야 합니다. 이 경우 사용자의 요구를 충족하는 데 문제가 되면 Cloud Spanner와 같은 리전 간 동기식 복제 데이터베이스 제품 사용을 고려할 수 있습니다.
사용자가 트리거한 승격 프로세스는 고가용성 구성에서 대기 인스턴스를 활성화하는 것과 유사한 단계를 따릅니다. 읽기 본제본은 트랜잭션 로그를 처리하고 부하 분산기는 트래픽을 리디렉션해야 합니다. 트랜잭션 로그를 처리하면 총 복구 시간이 집계됩니다.
리전 간 복제본 옵션에 대한 자세한 내용은 Cloud SQL 리전 간 복제본 문서를 참조하세요.
Cloud Logging
Cloud Logging은 로그 라우터와 Cloud Logging 스토리지라는 두 가지 주요 부분으로 구성됩니다.
로그 라우터는 스트리밍 로그 이벤트를 처리하고 로그를 Cloud Storage, Pub/Sub, BigQuery 또는 Cloud Logging 스토리지로 전달합니다.
Cloud Logging 스토리지는 로그를 저장 및 쿼리하고 로그의 규정 준수를 관리하는 서비스로, 개발, 규정 준수, 문제 해결, 사전 알림을 포함하여 많은 사용자와 워크플로를 지원합니다.
로그 라우터 및 수신 로그: 영역 서비스 중단 시 Cloud Logging API가 리전의 다른 영역으로 로그를 라우팅합니다. 일반적으로 로그 라우터에서 Cloud Logging, BigQuery 또는 Pub/Sub으로 라우팅하는 로그는 최대한 빠르게 최종 대상에 기록되지만 Cloud Storage로 전송되는 로그는 매시간 버퍼링되고 일괄 기록됩니다.
로그 항목: 영역 또는 리전에서 서비스 중단 발생 시 영향을 받는 영역 또는 리전에서 버퍼링되었지만 내보내기 대상에 기록되지 않은 로그 항목에는 액세스할 수 없습니다. 로그 기반 측정항목은 로그 라우터에서 계산되며 동일한 제약조건이 적용됩니다. 선택된 로그 내보내기 위치로 전달된 로그는 대상 서비스에 따라 복제됩니다. Cloud Logging 스토리지로 내보낸 로그는 리전의 두 영역에 동기식으로 복제됩니다. 다른 대상 유형의 복제 동작은 이 문서의 관련 섹션을 참조하세요. Cloud Storage로 내보낸 로그는 매시간 일괄 처리되고 작성됩니다. 따라서 Cloud Logging 스토리지, BigQuery 또는 Pub/Sub를 사용하여 서비스 중단의 영향을 받는 데이터 양을 최소화하는 것이 좋습니다.
로그 메타데이터: 싱크 및 제외 구성과 같은 메타데이터는 전역적으로 저장되지만 리전별로 캐시되므로 서비스 중단 발생 시 리전 로그 라우터 인스턴스가 작동합니다. 단일 리전 서비스 중단은 리전 외부에는 영향을 미치지 않습니다.
Cloud Spanner
Cloud Spanner는 관계형 시맨틱스를 사용해 확장 가능하고 가용성이 높은 다중 버전이며 동기식으로 복제된 strong consistency를 갖춘 데이터베이스입니다.
리전 Cloud Spanner 인스턴스는 단일 리전의 세 개 영역에 데이터를 동기식으로 복제합니다. 리전 Cloud Spanner 인스턴스에 대한 쓰기는 3개의 모든 복제본에 동기식으로 전송되고 복제본이 2개 이상(2/3의 다수 쿼럼) 쓰기를 커밋한 후 클라이언트에 확인됩니다. 이렇게 하면 최신 쓰기가 유지되고 복제본 2개로 쓰기의 다수 쿼럼을 계속 달성할 수 있으므로 Cloud Spanner가 모든 데이터에 대한 액세스를 제공하여 영역 장애에 대해 복원력이 우수하게 됩니다.
Cloud Spanner 멀티 리전 인스턴스에는 3개 리전에 있는 5개의 영역에 데이터를 동기식으로 복제하는 쓰기 쿼럼이 포함되어 있습니다(기본 최적 리전과 다른 리전 각각에 읽기-쓰기 복제본 2개, 감시 리전에 복제본 1개). 멀티 리전 Cloud Spanner 인스턴스에 대한 쓰기는 복제본이 3개 이상(3/5의 다수 쿼럼) 쓰기를 커밋한 후에 확인됩니다. 영역 또는 리전 장애가 발생하는 경우 쓰기가 클라이언트에 확인될 때 리전 2개의 3개 이상의 영역에서 데이터가 유지되므로 Cloud Spanner는 모든 데이터(최신 쓰기 포함)에 액세스할 수 있고 읽기/쓰기 요청을 처리합니다.
이러한 구성에 대한 자세한 내용은 Cloud Spanner 인스턴스 문서를 참조하고 Cloud Spanner 복제 방식에 대한 자세한 내용은 복제 문서를 참조하세요.