PostgreSQL용 AlloyDB 자세히 살펴보기: 비즈니스 연속성

클라우드에서 데이터베이스를 실행할 때 누릴 수 있는 가장 큰 이점 중 하나는 비즈니스 연속성을 보장할 수 있다는 것입니다. 데이터베이스 맥락에서는 연속성을 데이터베이스 가용성과 데이터 내구성의 조합으로 정의하는 것이 일반적입니다.

AlloyDB는 까다로운 트랜잭션 워크로드를 위한 완전 관리형 PostgreSQL 호환 데이터베이스입니다. 기본적으로 AlloyDB는 엄격한 비즈니스 연속성과 데이터 복원력 관행을 사용합니다. 이에 따라 복잡하고 많은 시간이 걸리는 구성과 관리에 대한 걱정 없이 자동 장애 조치, PITR(point-in-time recovery), 데이터 복제와 같은 기능을 활용할 수 있습니다.

Google Cloud는 비즈니스 연속성의 중요성을 잘 알고 있기 때문에 자체 관리형 배포에서 가장 우려되는 많은 결함 조건을 해결하도록 인프라와 관리형 서비스를 설계했습니다. 기본적으로 Google Cloud 아키텍처 및 인프라는 데이터 손실과 비가용성 이벤트에 대한 강력한 보호를 제공하므로 사용자는 데이터가 항상 안전하며 액세스 가능하다는 점을 믿고 안심할 수 있습니다. 또한 애플리케이션마다 가용성 요구사항이 다르기 때문에 Google Cloud는 사용자가 자체적인 서비스 수준 목표를 충족할 수 있도록 유연성과 제어 기능을 제공하기 위해 노력하고 있습니다.

특히 AlloyDB는 가용성과 안정성이 뛰어난 Google Cloud 인프라를 기반으로 구축되어 높은 수준의 데이터베이스 가용성 및 내구성을 제공할 수 있습니다. AlloyDB에서는 데이터 가용성이 보장되며 어떤 중단이 발생하더라도 신속하고 효율적으로 복구할 수 있습니다.

비가용성 및 데이터 손실 이벤트

업무에 중요한 엔터프라이즈 애플리케이션에는 언제나 데이터베이스의 가용성과 복원력은 물론 내구성 있는 데이터가 필요합니다. 해당 용어를 자세히 살펴보고 이러한 용어와 관련된 비가용성 및 데이터 손실 이벤트를 살펴보겠습니다. 

가용성은 최종 사용자 또는 애플리케이션이 데이터베이스에 액세스하고 데이터 관리 작업을 수행할 수 있는 능력입니다. 애플리케이션 가용성은 보통 데이터베이스 가용성에 의해 좌우됩니다. 데이터베이스가 다운되면 사용자가 로그인할 수 없으며 제품 카탈로그를 확인 또는 주문할 수 없고 관련 제품 및 서비스도 제공받을 수 없습니다.

가장 흔하게 발생하는 비가용성 문제는 인프라 장애입니다. 이러한 장애는 단일 하드웨어 구성요소 실패처럼 경미한 문제에서부터 정전이나 재해와 같이 지역 내 전체 데이터 센터 또는 일부 데이터 센터를 다운시킬 수 있는 보다 보편적인 이벤트에 이르기까지 다양합니다. 또한 애플리케이션 오류로 인해 데이터베이스 시스템을 사용하지 못하게 될 수도 있습니다. 예를 들어 잘못 작성된 쿼리 때문에 전체 테이블이 장시간 잠기거나 구성 실수로 인해 데이터베이스 서버를 사용할 수 없게 될 수 있습니다.

내구성은 데이터를 가져올 때까지 손상 없이 데이터를 유지하는 능력으로, 모든 데이터베이스의 필수 속성입니다. 비가용성 이벤트와 마찬가지로 디스크 장애와 같은 특정 인프라 장애로 인해 데이터 손실 이벤트가 발생할 수 있습니다. 그러나 가장 우려되는 데이터 손실 이벤트로는 테이블을 실수로 삭제하거나 애플리케이션이 레코드를 데이터베이스에 영구 보존하기 전에 손상시키는 등의 사용자 및 애플리케이션 오류가 포함됩니다. 

복원력은 시스템이 발생한 장애로부터 복구하고 정상적인 운영을 복원하는 능력이며 가용성 및 내구성과 밀접한 관련이 있습니다. 가용성과 내구성이 뛰어난 시스템을 구축하려면 중복성 및 내결함성을 도입하여 장애 이벤트로부터 사용자를 보호해야 합니다. 

Google 기술과 AlloyDB 아키텍처로 어떻게 높은 수준의 가용성과 내구성을 달성할 수 있는지 살펴보겠습니다. 

복원력 중심 설계

AlloyDB의 아키텍처는 Google의 기본 스토리지 시스템인 Colossus를 활용합니다. Colossus는 Google 검색 및 Gmail과 같이 업무상 중요한 세계적 규모의 서비스를 이루는 주요 구성요소 중 하나입니다. Colossus는 무한대로 확장되고 높은 내결함성을 갖도록 설계된 분산 파일 시스템입니다. 내결함성은 중복성과 삭제 코딩이라는 두 가지 기법으로 뒷받침됩니다.

Colossus에 사용되는 중복성 기법에서는 데이터를 작은 청크로 분할하여 독립적인 장애 도메인의 여러 서버에 복사합니다. 이 같은 접근 방식으로 네트워크 파티션 등의 비가용성 이벤트 또는 디스크 장애 같은 데이터 손실 이벤트의 영향을 받은 모든 사본을 나머지 사본에서 재구성할 수 있습니다. 삭제 코딩은 청크 내에 추가적인 데이터 중복성을 도입하여 동일한 청크 내의 알려진 블록에서 누락되거나 손상된 데이터를 재생성할 수 있는 기법입니다.

Colossus를 활용하는 것 외에도 AlloyDB의 지능형 스토리지 서비스가 추가적인 내결함성을 지원합니다. 데이터는 영역 장애에 대한 내결함성을 위해 여러 영역에 중복해서 저장됩니다. 또한 Google Cloud 스토리지가 모든 영역 사본에서 중단을 모니터링하여 고가용성을 유지하도록 이를 재구성할 수 있는 기능을 제공합니다. 따라서 치명적인 장애가 발생하더라도 데이터가 안전하며 항상 사용 가능하다고 확신할 수 있습니다. 

아울러 AlloyDB는 Google 가상 머신(VM) 설계를 사용하여 AlloyDB 클러스터에 데이터베이스 인스턴스를 포함한 기본 VM의 라이브 마이그레이션을 지원합니다. Google Cloud는 라이브 마이그레이션을 통해 워크로드를 중단하거나 VM을 재부팅하거나 IP 주소, 메타데이터, 블록 스토리지 데이터, 애플리케이션 상태, 네트워크 설정과 같은 VM의 속성을 수정하지 않고도 유지보수를 수행할 수 있습니다. 덕분에 AlloyDB는 인프라 유지보수, 보안 및 구성 패치 적용, 하드웨어 장애 발생 시에도 가용성을 유지할 수 있습니다. 

가용성과 내구성을 높여주는 부가기능

위에서 다룬 AlloyDB의 구성요소를 통해 이미 높은 수준의 복원력이 제공되지만 업무에 중요한 애플리케이션에서 가용성과 내구성을 향상시키는 추가적인 AlloyDB 기능도 활용할 수 있습니다. 

고가용성 인스턴스

AlloyDB는 유지보수가 포함된 업계 최고의 99.99% 가용성 SLA에 따라 고가용성 인스턴스를 제공합니다. 기본적으로 기본 인스턴스의 가용성이 높으며 노드가 2개 이상인 읽기 풀의 가용성도 높습니다. 

AlloyDB 고가용성 인스턴스의 핵심 기능은 자동 장애 조치입니다. AlloyDB에서 비정상적인 PostgreSQL 인스턴스를 자동으로 감지하고 데이터베이스 크기 및 로드에 관계없이 60초 이내에 서로 다른 영역에 있는 대기 머신으로 장애 조치합니다. 이를 통해 비가용성 이벤트가 발생했을 때 애플리케이션 중단이 최소화됩니다. 

또한 AlloyDB의 고가용성 인스턴스는 인스턴스 크기 조절, 재시작이 필요한 재구성, PostgreSQL 마이너 버전 업그레이드와 같은 서비스 기반 유지보수 작업 등의 사용자 주도 유지보수 작업을 위한 무중단 유지보수 작업을 지원합니다. Google Cloud는 이러한 유지보수 이벤트에 대비하여 현재 인스턴스를 새 인스턴스로 대체하기 전에 새 인스턴스를 준비하고 캐시를 워밍업합니다. 유지보수 이벤트는 기본 인스턴스의 중단이 10초 미만으로 완료되며, 유지보수 작업 중에 읽기 풀이 완전한 작동 상태를 유지합니다.

내부적으로 AlloyDB의 고가용성 인스턴스는 가용성이 높은 애플리케이션을 빌드할 수 있도록 고객에게 제공되는 철저한 검증을 거친 Google Cloud 서비스를 사용합니다. 리전내부 부하 분산기가 머신 간 연결을 원활하게 라우팅하여 애플리케이션이 항상 정상적인 인스턴스에 연결되도록 합니다. 관리형 인스턴스 그룹이 교체 머신을 신속하게 인스턴스화하고 Spanner가 인스턴스 구성을 유지하여 빠르고 안정적인 유지보수 및 수평 확장 작업을 지원합니다.

리전 간 복제

한 클라우드 리전에 있는 여러 데이터 센터에서 동시에 장애가 발생하는 일은 극히 드물지만(일반적으로 화재나 지진 같은 재해 상황에서 발생) AlloyDB는 드물게 발생하는 대규모 이벤트까지 포함한 가능한 모든 장애 시나리오를 계획한다는 원칙을 고수하고 있습니다. 

리전 간 복제를 사용하면 데이터를 기본 클러스터에서 다른 클라우드 리전의 보조 클러스터로 비동기식으로 복제할 수 있습니다. 기본 클러스터에 장애 또는 중단이 발생할 경우 보조 클러스터를 새로운 기본 클러스터로 빠르게 승격할 수 있어 중단을 최소화하면서 애플리케이션을 계속 실행할 수 있습니다.

리전 간 복제 기능은 비동기식으로 작동하므로 기본 클러스터의 쓰기 성능에 영향을 미치지 않습니다. 보조 클러스터가 거의 실시간으로 업데이트를 수신하며 사용자가 지연을 모니터링할 수 있습니다.

백업 및 PITR(Point-in-time-recovery)

데이터 손실은 비즈니스에 큰 차질을 빚을 수 있습니다. 이러한 이유에서 AlloyDB는 중요한 데이터를 보호하기 위한 강력한 백업 및 PITR 기능을 제공합니다. 사용자는 AlloyDB 클러스터의 수동, 자동 또는 지속적 백업을 통해 데이터 손실 이벤트로부터 데이터를 보호할 수 있습니다. 

앞서 언급한 AlloyDB의 지능형 스토리지 서비스로 백업이 오프로드되어 클러스터에 연결된 인스턴스의 읽기 또는 쓰기 성능에 영향을 주지 않고 백업 작업을 수행할 수 있습니다. 스토리지 시스템의 샤딩 특성 덕분에 백업 생성 및 복원을 병렬 처리할 수 있으므로 백업 및 복구 시간이 크게 단축됩니다. 

백업은 클러스터 스토리지와 별개인 Cloud Storage에 저장되며 연간 내구성이 엔터프라이즈 스토리지 시스템에서 가장 높은 99.999999999%(9가 11개)에 달합니다. 이는 매일 백업하는 일반적인 데이터베이스를 손상 없이 수십만 년 동안 실행할 수 있다는 의미입니다. 10,000년 후 백업에 문제가 발생한다면 Google Cloud에 문의해 주세요. 또한 백업은 클러스터 수명 주기와 독립적이므로 실수로 클러스터가 삭제되지 않게 보호해 줍니다.

AlloyDB에서는 백업의 편리한 예약 및 유지를 위해 자동 백업을 제공합니다. 풍부한 맞춤설정 매개변수를 사용하면 백업을 많게는 시간당 1회, 적게는 주 1회까지 수행하고 최대 1년 또는 횟수에 따라 백업을 유지하며 고객 관리 암호화 키(CMEK, Customer Managed Encrypted Key)나 Google의 기본 암호화를 사용하는 등 이 기능을 조직 고유의 니즈에 맞게 조정할 수 있습니다. 

이달 초 Google Cloud는 최대 35일에 이르는 복구 기간 동안 PITR 기능을 제공하는 AlloyDB를 위한 지속적인 백업 및 복구를 정식 버전으로 출시했습니다. 사용 사례로는 데이터 손상을 초래한 오류 직전으로 복원하거나 감사 또는 테스트 및 개발 목적으로 특정 날짜와 시간으로 복원하는 작업이 포함됩니다. 지속적인 백업 및 복구에서는 일일 백업 계획과 트랜잭션 로그의 지속적인 저장이 병행됩니다. 기본적으로 모든 기본 클러스터에는 데이터 보호를 보장하기 위해 14일간의 복구 기간이 포함된 지속적인 백업 계획이 적용됩니다.

백업과 마찬가지로 지속적인 백업 및 복구도 AlloyDB의 지능형 스토리지 시스템으로 관리되므로 인스턴스 성능에 영향을 미치지 않으며 재생 병렬화 기능으로 인해 PostgreSQL의 기존 PITR보다 빠른 PITR을 달성할 수 있습니다. 트랜잭션 로그가 Cloud Storage에 오프로드되어 데이터베이스의 클러스터 스토리지에 영향을 주지 않습니다. 

지속적인 백업 및 복구에 부과되는 요금은 트랜잭션 로그 및 백업에서 사용하는 스토리지를 기준으로 책정됩니다. 처음 7일간의 로그 스토리지 사용은 무료로 제공됩니다. 

AlloyDB를 통한 복원력이 우수한 애플리케이션 빌드

비즈니스에 높은 가용성과 데이터 내구성이 얼마나 중요한지 잘 알고 있습니다. Google Cloud의 인프라 및 관리형 서비스는 비즈니스 연속성을 보장하기 위한 강력한 기반을 제공하며 이를 기반으로 구축된 AlloyDB는 지능형 스토리지 서비스와 추가적인 기능을 통해 가용성과 내구성을 높여줍니다. 이러한 기능을 활용하면 인프라 장애, 데이터 손실 이벤트, 기타 중단이 발생하는 경우에도 업무에 중요한 애플리케이션과 데이터를 사용할 수 있다는 점에서 안심할 수 있습니다.

지금 AlloyDB로 애플리케이션을 빌드하세요. 신규 고객은 AlloyDB를 무료로 사용해 볼 수 있습니다.