리전 Persistent Disk는 Compute Engine에서 고가용성(HA) 서비스를 구현할 수 있는 스토리지 옵션입니다. 리전 Persistent Disk는 같은 리전의 두 영역 간에 데이터를 동기식으로 복제하고 영역 오류 최대 1회까지 디스크 데이터의 HA를 보장합니다.
이 문서에서는 리전 Persistent Disk를 사용하여 HA 서비스를 빌드하는 방법을 설명합니다.
리전 Persistent Disk를 사용하여 고가용성 서비스 빌드
이 섹션에서는 리전 Persistent Disk를 사용하여 HA 서비스를 빌드하는 방법을 설명합니다.
설계 고려사항
HA 서비스 설계를 시작하기 전에 애플리케이션, 파일 시스템, 운영체제의 특성을 이해해야 합니다. 이러한 특성은 설계의 기초가 되며 다양한 접근법을 배제할 수 있습니다. 예를 들어 애플리케이션이 애플리케이션 수준 복제를 지원하지 않는 경우 해당되는 일부 설계 옵션을 적용할 수 없습니다.
마찬가지로 애플리케이션, 파일 시스템 또는 운영체제가 비정상 종료에 대한 내결함성을 갖추고 있지 않은 경우 리전 영구 디스크나 심지어 영역 영구 디스크 스냅샷도 사용하지 못할 수 있습니다. 비정상 종료에 대한 내결함성이란 비정상 종료 전에 영구 디스크에 이미 커밋된 데이터를 손실하거나 손상시키지 않고 갑작스러운 종료로부터 복구하는 기능을 말합니다.
고가용성을 위해 설계할 때 다음 사항을 고려하세요.
- 애플리케이션 및 디스크 쓰기 성능에 리전 영구 디스크 또는 기타 솔루션을 사용하는 효과
- 서비스 복구 시간 목표. 영역 장애로부터 서비스를 복구해야 하는 속도와 SLA 요구 사항을 이해합니다.
- 복원력이 우수하고 안정적인 서비스 아키텍처를 구축하는 비용
비용 측면에서 동기식 및 비동기식 애플리케이션 복제에 사용할 수 있는 옵션은 다음과 같습니다.
데이터베이스와 VM의 두 인스턴스를 사용합니다. 이 경우 다음 항목에 따라 총 비용이 결정됩니다.
- VM 인스턴스 비용
- 영구 디스크 비용
- 애플리케이션 복제 유지 비용
리전 영구 디스크에 단일 VM을 사용합니다. 리전 영구 디스크에서 가용성을 높이려면 동일한 VM 인스턴스와 영구 디스크 구성요소를 사용하되 리전 영구 디스크도 포함합니다. 리전 영구 디스크는 두 영역에서 복제되기 때문에 영역 영구 디스크에 비해 바이트당 비용이 두 배입니다.
하지만 리전 영구 디스크를 사용하면 애플리케이션 복제를 유지할 필요 없이 데이터가 자동으로 두 개의 복제본으로 복제되므로 유지보수 비용이 줄어들 수 있습니다.
장애 조치가 필요하기 전에는 두 번째 VM을 시작하지 않습니다. VM을 상시 대기 인스턴스로 유지하지 않고 대신 장애 조치 중 온디맨드 방식으로만 백업 VM을 시작하면 호스트 비용을 더 줄일 수 있습니다.
비용, 성능, 복원력 비교
다음 표에서는 다양한 서비스 아키텍처의 비용, 성능, 복원력을 비교하여 보여줍니다.
| HA 서비스 아키텍처 |
영역 영구 디스크 스냅샷 |
애플리케이션 수준 동기 |
애플리케이션 수준 비동기 |
리전 영구 디스크를 사용하는 HA 솔루션 |
|---|---|---|---|---|
| 애플리케이션, VM, 영역 장애로부터 보호1 | ||||
| 애플리케이션 손상 완화(예: 애플리케이션 비정상 종료 시 내결함성이 부족한 경우) | 2 | 2 | ||
| 비용 | $ |
$$
|
$$
|
$1.5x - $$
|
| 애플리케이션 성능 |
|
|
|
|
| RPO 요구 사항이 낮은 애플리케이션에 적합(데이터 손실에 대한 내결함성이 매우 낮음) |
|
|
|
|
| 재해 발생 시 스토리지 복구 시간4 |
|
|
|
|
1 리전 영구 디스크나 스냅샷을 사용하여 장애 및 손상을 방지하고 완화할 수 없습니다. 애플리케이션, 파일 시스템, 기타 소프트웨어 구성요소가 일관되게 비정상 종료되거나 작업이 정지되어야 합니다.
2 일부 애플리케이션 복제는 일부 애플리케이션 손상을 완화합니다. 예를 들어 MySQL 기본 애플리케이션이 손상되어도 복제본 VM 인스턴스는 손상되지 않습니다. 자세한 내용은 애플리케이션 문서를 참조하세요.
3 데이터 손실은 영구 스토리지에 커밋된 데이터의 복구 불가능한 손실을 의미합니다. 여전히 커밋되지 않은 모든 데이터가 손실됩니다.
4 장애 조치 성능에는 파일 시스템 검사, 애플리케이션 복구, 장애 조치 후 로드가 포함되지 않습니다.
리전 영구 디스크를 사용하여 HA 데이터베이스 서비스 구축
이 섹션에서는 리전 영구 디스크와 Compute Engine을 사용하여 스테이트풀(Stateful) 데이터베이스 서비스(MySQL, Postgres 등)에 사용되는 HA 솔루션 빌드에 대한 고급 개념을 설명합니다.
Google Cloud에서 광범위한 서비스 중단이 발생하면(예: 전체 리전을 사용할 수 없게 되는 경우) 애플리케이션을 사용하지 못하게 될 수 있습니다. 니즈에 따라 더 높은 가용성을 얻도록 리전 간 복제 기법을 사용하는 것이 좋습니다.
데이터베이스 HA 구성에는 일반적으로 VM 인스턴스가 두 개 이상 있습니다. 이러한 VM 인스턴스는 관리형 인스턴스 그룹 하나 이상에 속한 것이 좋습니다.
- 기본 영역의 기본 VM 인스턴스
- 보조 영역의 대기 VM 인스턴스
기본 VM 인스턴스에는 두 개 이상의 영구 디스크(부팅 디스크와 리전 영구 디스크)가 있습니다. 리전 영구 디스크에는 중단 시 다른 영역에 보존해야 하는 데이터베이스 데이터 및 기타 변경 가능한 데이터가 포함됩니다.
예를 들어 운영체제 업그레이드로 인해 대기 VM 인스턴스에서 구성 관련 중단을 복구하려면 별도의 부팅 디스크가 필요합니다. 장애 조치 중에는 부팅 디스크를 다른 VM에 강제로 연결할 수 없습니다.
기본 VM 인스턴스와 대기 VM 인스턴스는 상태 확인 신호에 따라 트래픽이 기본 VM으로 전송되는 부하 분산기를 사용하도록 구성됩니다. 이 구성은 상시 대기라고도 합니다. 데이터 재해 복구 시나리오는 개발자의 시나리오에 더 적합할 수 있는 기타 장애 조치 구성을 설명합니다.
데이터베이스 복제 문제
다음 표에는 애플리케이션 동기화 또는 반동기 복제(예: MySQL)의 설정 및 관리와 관련된 몇 가지 일반적인 도전과제와 함께, 이러한 복제가 리전 영구 디스크의 블록 복제와 어떻게 다른지가 나와 있습니다.
| 도전과제 | 애플리케이션 동기 또는 반동기 복제 |
리전 영구 디스크의 블록 복제 |
|---|---|---|
| 기본 복제본과 장애 조치 복제본 간의 안정적인 복제 유지 | 오류 발생 및 VM 인스턴스의 HA 모드 종료의 원인은 다양합니다.
|
스토리지 오류는 리전 영구 디스크에 의해 처리됩니다. 이는 디스크 성능의 변동 가능성을 제외하고 애플리케이션에서 투명하게 발생합니다. 애플리케이션 또는 VM 문제를 표시하고 장애 조치를 트리거하려면 사용자 정의 상태 확인이 있어야 합니다. |
| 엔드 투 엔드 장애 조치 시간이 예상보다 깁니다. | 장애 조치 작업에 소요되는 시간에 상한이 없습니다. 모든 트랜잭션이 재실행되기를 기다리는 단계(위의 2단계)가 데이터베이스의 스키마와 로드에 따라 제멋대로 길어질 수 있습니다. | 리전 영구 디스크는 동기 복제를 제공하므로 장애 조치 시간은 다음 지연 시간의 합계로 제한됩니다.
|
| 분할 브레인 | 분할 브레인을 방지하려면 두 방식 모두 한 번에 기본 인스턴스 하나만 있도록 프로비저닝해야 합니다. | |
상태 점검
부하 분산기에서 사용하는 상태 점검은 상태 점검 에이전트에 의해 구현됩니다. 상태 점검 에이전트는 두 가지 용도로 사용됩니다.
- 상태 점검 에이전트는 VM 인스턴스를 모니터링하고 부하 분산기와 통신하여 트래픽을 전송하기 위해 기본 및 보조 VM 내에 상주합니다. 인스턴스 그룹으로 구성된 경우에 가장 잘 작동합니다.
- 상태 점검 에이전트는 애플리케이션별 리전 제어 영역과 동기화되며 제어 영역 동작에 따라 장애 조치를 결정합니다. 제어 영역은 상태를 모니터링하는 VM 인스턴스와 다른 영역에 있어야 합니다.
상태 점검 에이전트 자체는 내결함성이 있어야 합니다. 예를 들어 제어 영역을 따르는 이미지의 알림은 us-central1-a 영역에 있는 기본 VM 인스턴스와 구분되는 반면 대기 VM은 us-central1-f 영역에 상주합니다.
다음 단계
- 리전 Persistent Disk 볼륨 만들기 및 관리 방법 알아보기
- Google Cloud에서 확장 가능하고 복원력이 우수한 웹 애플리케이션 빌드 방법 알아보기
- 재해 복구 계획 가이드 검토