멀티 클라우드 데이터베이스 관리: 아키텍처, 사용 사례, 권장사항

이 문서에서는 멀티 클라우드 데이터베이스 관리를 위한 배포 아키텍처, 사용 사례, 권장사항에 대해 설명합니다. 이 문서는 멀티 클라우드 내에서 또는 멀티 클라우드 간에 스테이트풀(Stateful) 애플리케이션을 설계하고 구현하는 설계자 및 엔지니어를 대상으로 합니다.

데이터베이스에 액세스하는 멀티 클라우드 애플리케이션 아키텍처는 사용 사례에 따라 달라집니다. 단일 스테이트풀(Stateful) 애플리케이션 아키텍처로 모든 멀티클라우드 사용 사례를 지원할 수는 없습니다. 예를 들어 클라우드 버스팅 사용 사례의 최적 데이터베이스 솔루션은 멀티 클라우드 환경에서 동시에 실행되는 애플리케이션의 최적 데이터베이스 솔루션과 다릅니다.

Google Cloud와 같은 퍼블릭 클라우드에는 특정 멀티클라우드 사용 사례에 맞는 여러 가지 데이터베이스 기술이 있습니다. 단일 퍼블릭 클라우드 내에서 여러 리전에 애플리케이션을 배포할 때 한 가지 옵션은 Spanner와 같이 퍼블릭 클라우드, 제공자 관리, 다중 리전 특성을 갖는 데이터베이스를 사용하는 것입니다. 퍼블릭 클라우드 간에 이동 가능하도록 애플리케이션을 배포하려면 PostgreSQL과 같이 플랫폼에 독립적인 데이터베이스가 더 나은 선택일 수 있습니다.

이 문서에서는 스테이트풀(Stateful) 데이터베이스 애플리케이션에 대한 정의를 소개하고 멀티클라우드 데이터베이스 사용 사례 분석을 제공합니다. 그런 후 사용 사례를 기준으로 멀티 클라우드 배포 아키텍처에 대한 자세한 데이터베이스 시스템 분류를 제공합니다.

또한 이 문서에서는 적합한 데이터베이스 기술을 선택하기 위해 중요한 결정 사항을 설명하는 데이터베이스 선택을 위한 결정 트리를 보여줍니다. 멀티 클라우드 데이터베이스 관리를 위한 권장사항에 대한 논의를 마칩니다.

핵심 용어 및 정의

이 섹션에서는 용어를 제공하고 이 문서에서 사용되는 일반적인 스테이트풀(Stateful) 데이터베이스 애플리케이션을 정의합니다.

용어

• 퍼블릭 클라우드. 퍼블릭 클라우드는 고객이 프로덕션 워크로드 실행을 위해 사용할 수 있는 멀티 테넌트 인프라(일반적으로 전역) 및 서비스를 제공합니다. Google Cloud는 GKE, GKE Enterprise, 관리형 데이터베이스를 포함하여 여러 관리형 서비스를 제공하는 퍼블릭 클라우드입니다.
• 하이브리드 클라우드. 하이브리드 클라우드는 퍼블릭 클라우드가 하나 이상의 온프레미스 데이터 센터와 조합된 형태입니다. 하이브리드 클라우드 고객은 온프레미스 서비스를 퍼블릭 클라우드에서 제공되는 추가적인 서비스와 조합할 수 있습니다.
• 멀티 클라우드. 멀티클라우드는 여러 퍼블릭 클라우드와 온프레미스 데이터 센터가 조합된 형태입니다. 하이브리드 클라우드는 멀티클라우드의 하위 집합입니다.
• 배포 위치. 인프라 위치는 애플리케이션 및 데이터베이스를 포함하여 워크로드를 배포하고 실행할 수 있는 물리적 위치입니다. 예를 들어 Google Cloud에서 배포 위치는 영역과 리전입니다. 추상적인 수준에서 퍼블릭 클라우드 리전 또는 영역과 온프레미스 데이터 센터가 배포 위치입니다.

스테이트풀(Stateful) 데이터베이스 애플리케이션

멀티클라우드 사용 사례를 정의하기 위해 이 문서에서는 다음 다이어그램에 표시된 것처럼 일반적인 스테이트풀(Stateful) 데이터베이스 애플리케이션 아키텍처가 사용되었습니다.

이 다이어그램은 다음 구성요소를 보여줍니다.

• 데이터베이스. 데이터베이스는 단일 인스턴스, 멀티 인스턴스, 분산 데이터베이스일 수 있으며, 컴퓨팅 노드에 배포되거나 클라우드 관리형 서비스로 제공될 수 있습니다.
• 애플리케이션 서비스. 이러한 서비스는 비즈니스 논리를 구현하는 애플리케이션으로 결합됩니다. 애플리케이션 서비스는 다음 중 하나일 수 있습니다.
  • Kubernetes의 마이크로서비스
  • 하나 이상의 가상 머신에서 실행되는 대략적으로 분할된 프로세스
  • 하나의 대형 가상 머신에서 실행되는 모놀리식 애플리케이션
  • Cloud Run 함수 또는 Cloud Run의 서버리스 코드 일부 애플리케이션 서비스는 데이터베이스에 액세스할 수 있습니다. 각 애플리케이션 서비스를 여러 번 배포하는 것이 가능합니다. 애플리케이션 서비스의 각 배포가 애플리케이션 서비스의 인스턴스에 해당합니다.
• 애플리케이션 클라이언트. 애플리케이션 클라이언트는 애플리케이션 서비스에서 제공되는 기능에 액세스합니다. 애플리케이션 클라이언트는 다음 중 하나일 수 있습니다.
  • 머신, 노트북, 휴대전화에서 코드가 실행되는 배포된 클라이언트
  • 브라우저에서 클라이언트 코드가 실행되는 배포되지 않은 클라이언트. 애플리케이션 클라이언트 인스턴스는 항상 하나 이상의 애플리케이션 서비스 인스턴스에 액세스합니다.

멀티클라우드 데이터베이스에 대해 토론할 때 스테이트풀(Stateful) 애플리케이션을 아키텍처 측면에서 추상화하는 데에는 데이터베이스, 애플리케이션 서비스, 애플리케이션 클라이언트가 포함됩니다. 애플리케이션 구현에서 사용되는 운영체제 또는 프로그래밍 언어와 같은 요소는 서로 다를 수 있습니다. 하지만 이러한 세부정보는 멀티클라우드 데이터베이스 관리에 영향을 주지 않습니다.

데이터 스토리지 서비스로 사용되는 큐 및 파일

애플리케이션 서비스는 여러 가지 지속성 리소스를 사용하여 데이터를 유지할 수 있습니다. 이러한 리소스에는 데이터베이스, 큐 및 파일이 포함됩니다. 각 지속성 리소스는 해당 모델에 맞게 특화된 스토리지 데이터 모델 및 액세스 패턴을 제공합니다. 큐, 메시징 시스템, 파일 시스템이 애플리케이션에 사용되지만 다음 섹션에서는 데이터베이스에 대해 특히 자세히 설명합니다.

배포 위치, 상태 공유, 멀티클라우드 데이터베이스에 대한 동기 및 비동기 복제와 같은 요소들에 대한 고려사항은 큐 및 파일에도 동일하게 적용됩니다. 하지만 이러한 주제는 이 문서의 범위를 벗어납니다.

네트워킹

다음 다이어그램에 다시 표시된 일반적인 스테이트풀(Stateful) 애플리케이션의 아키텍처에서 구성요소 사이의 각 화살표는 애플리케이션 서비스에 액세스하는 애플리케이션 클라이언트와 같이 네트워크 연결에 대한 통신 관계를 나타냅니다.

연결은 영역 내부에 있거나 영역, 리전, 클라우드 사이에 있을 수 있습니다. 연결은 모든 배포 위치 조합 간에 존재할 수 있습니다. 멀티클라우드 환경에서 클라우드 간 네트워킹은 중요한 고려사항이며 여러 가지 옵션을 사용할 수 있습니다. 클라우드 간 네트워킹에 대한 자세한 내용은 Google Cloud에 연결: 네트워킹 옵션 설명을 참고하세요.

이 문서의 사용 사례에서는 다음과 같이 가정합니다.

• 클라우드 간에 보안 네트워크 연결이 설정되어 있습니다.
• 데이터베이스 및 해당 구성요소가 서로 통신할 수 있습니다.

비기능적인 관점에서 네트워크 크기 즉, 처리량과 지연 시간은 데이터베이스 지연 시간 및 처리량에 영향을 줄 수 있습니다. 기능적인 관점에서 네트워킹은 일반적으로 영향을 주지 않습니다.

멀티 클라우드 데이터베이스 사용 사례

이 섹션에서는 멀티클라우드 데이터베이스 관리 중에서 몇 가지 가장 일반적인 사용 사례를 보여줍니다. 이러한 사용 사례에서는 클라우드와 데이터베이스 노드 간에 보안 네트워크 연결이 설정되어 있다고 가정합니다.

애플리케이션 마이그레이션

멀티클라우드 데이터베이스 관리 측면에서 애플리케이션 마이그레이션은 현재 클라우드로부터 대상 클라우드로의 애플리케이션, 모든 애플리케이션 서비스, 데이터베이스의 마이그레이션을 의미합니다. 기업은 클라우드 제공업체와의 경쟁 상황을 방지하거나 기술을 현대화하거나, 총소유비용(TCO)을 낮추는 등의 여러 이유로 애플리케이션 마이그레이션을 결정할 수 있습니다.

애플리케이션 마이그레이션의 목적은 마이그레이션 완료 후 현재 클라우드에서 프로덕션을 중지하고 대상 클라우드에서 프로덕션을 계속하는 것입니다. 애플리케이션 서비스는 대상 클라우드에서 실행되어야 합니다. 서비스 구현을 위해서는 리프트 앤 시프트 접근 방법을 사용할 수 있습니다. 이 접근 방법에서는 대상 클라우드에 동일한 코드가 배포됩니다. 서비스 구현을 위해 대상 클라우드에서 사용 가능한 최신 클라우드 기술을 사용할 수 있습니다.

데이터베이스 관점에서는 애플리케이션 마이그레이션에 대해 다음과 같은 대체 옵션을 고려합니다.

• 데이터베이스 리프트 앤 시프트: 대상 클라우드에서 동일한 데이터베이스 엔진을 사용할 수 있으면 데이터베이스를 리프트 앤 시프트하여 대상 클라우드에서 동일한 배포를 만들 수 있습니다.
• 데이터베이스 리프트 및 상응하는 관리형 대상으로의 이동: 대상 클라우드가 제공하는 경우에는 동일한 데이터베이스 엔진의 관리형 버전으로 자체 관리형 데이터베이스를 마이그레이션할 수 있습니다.
• 데이터베이스 현대화: 각 클라우드마다 서로 다른 데이터베이스 기술이 제공됩니다. 클라우드 제공업체에서 관리되는 데이터베이스는 더 엄격한 서비스수준계약(SLA), 확장성, 자동 재해 복구와 같은 이점이 있을 수 있습니다.

배포 전략에 관계없이 데이터베이스 마이그레이션은 현재 클라우드에서 대상 클라우드로 데이터를 이동해야 하기 때문에 시간이 오래 걸리는 프로세스입니다. 다운타임이 발생하는 내보내기 및 가져오기 접근 방법을 따라야 할 수 있지만 다운타임이 없거나 최소한으로만 발생하는 마이그레이션이 선호됩니다. 이 접근 방식은 애플리케이션 다운타임을 최소화하고 기업 및 고객에 대해서도 최소한의 영향을 줍니다. 그러나 전환 시 초기 로드, 진행 중인 복제, 모니터링, 세부 유효성 검사, 동기화가 필요하므로 일반적으로 더 복잡한 마이그레이션 설정이 필요합니다. 대체 시나리오를 지원하려면 대상 데이터베이스로 전환한 후 변경사항을 소스 데이터베이스로 다시 동기화하는 역 복제 메커니즘을 구현해야 합니다.

재해 복구

재해 복구는 리전에서 서비스 중단 기간 동안 애플리케이션에 서비스를 계속 제공할 수 있게 해주는 애플리케이션 기능입니다. 재해 복구를 보장하기 위해서는 애플리케이션을 최소 2개 이상의 리전에 배포하고 언제든지 실행되도록 준비해야 합니다. 프로덕션에서 애플리케이션은 기본 리전에서 실행됩니다. 하지만 서비스 중단이 발생하면 보조 리전이 기본 리전이 됩니다. 다음은 재해 복구에서 준비되는 여러 모델을 보여줍니다.

• 핫 대기. 애플리케이션이 2개 이상의 리전(기본 및 보조)에 배포되고 애플리케이션이 모든 리전에서 완전히 작동합니다. 기본 리전이 실패하면 보조 리전의 애플리케이션이 즉시 애플리케이션 클라이언트 트래픽을 처리합니다.
• 콜드 대기. 애플리케이션이 기본 리전에서 실행되지만 보조 리전에서 시작하도록 준비됩니다(실행되지는 않음). 기본 리전이 실패하면 애플리케이션이 보조 리전에서 시작됩니다. 애플리케이션이 실행되어 애플리케이션 클라이언트에 모든 애플리케이션 서비스를 제공할 때까지 애플리케이션 서비스 중단이 발생합니다.
• 대기 없음. 이 모델에서는 애플리케이션 코드가 배포할 수 있도록 준비되지만 보조 리전에 아직 배포되지 않으며, 따라서 어떠한 배포된 리소스도 사용하지 않습니다. 기본 리전에 서비스 중단이 발생하면 애플리케이션의 첫 번째 배포가 보조 리전에 있어야 합니다. 이 배포에서는 애플리케이션이 콜드 대기와 동일한 상태로 유지됩니다. 즉, 시작 과정을 거쳐야 합니다. 이 접근 방법에서는 클라우드 리소스 생성을 포함하는 애플리케이션 배포가 먼저 수행되어야 하기 때문에 콜드 대기 사례보다 애플리케이션 서비스 중단이 더 길어집니다.

데이터베이스 관점에서 이전 목록에서 설명한 준비 모델은 다음 데이터베이스 접근 방법에 해당합니다.

• 트랜잭션 동기화 데이터베이스. 이 데이터베이스는 핫 대기 모델에 해당합니다. 기본 리전의 모든 트랜잭션이 보조 리전의 동기화 조정으로 커밋됩니다. 서비스 중단 기간 동안 보조 리전이 기본 리전이 되면 데이터베이스가 일관적으로 유지되고 즉시 제공됩니다. 이 모델에서 복구 지점 목표(RPO) 및 복구 시간 목표(RTO)는 모두 0입니다.
• 비동기 복제 데이터베이스. 이 데이터베이스는 또한 핫 대기 모델에 해당합니다. 주 리전에서 보조 리전으로의 데이터베이스 복제가 비동기적이기 때문에 기본 리전이 실패할 경우 일부 트랜잭션이 보조 리전으로 복제될 수 있습니다. 보조 리전의 데이터베이스가 프로덕션 로드용으로 준비되지만 최신 데이터를 포함하지 않을 수 있습니다. 따라서 애플리케이션에서 복구할 수 없는 트랜잭션 손실이 발생할 수 있습니다. 이러한 위험 때문에 이 접근 방법은 RTO가 0이지만 RPO가 0보다 큽니다.
• 유휴 데이터베이스. 이 데이터베이스는 콜드 대기 모델에 해당합니다. 데이터베이스가 데이터 없이 생성됩니다. 기본 리전이 실패하면 데이터를 유휴 데이터베이스에 로드해야 합니다. 이 작업을 사용 설정하려면 정규 백업을 기본 리전에서 수행하고 보조 리전으로 전송해야 합니다. 데이터베이스 엔진이 지원하는 대상에 따라 전체 또는 증분 백업이 수행될 수 있습니다. 어느 경우든 데이터베이스가 다시 마지막 백업으로 설정되고 애플리케이션 관점에서 기본 리전에 비해 많은 트랜잭션이 손실될 수 있습니다. 이 접근 방법은 비용 효율적일 수 있지만 데이터베이스 상태가 업데이트되지 않아 마지막으로 사용 가능한 백업 이후 모든 트랜잭션이 손실될 수 있는 위험으로 인해 값이 완화됩니다.
• 데이터베이스 없음. 이 모델은 대기 없음 사례에 해당합니다. 보조 리전에 데이터베이스가 설치되지 않고 기본 리전이 실패하면 데이터베이스를 만들어야 합니다. 유휴 데이터베이스 사례에서와 같이 데이터베이스가 생성된 후 애플리케이션에 제공되기 전에 데이터가 로드되어야 합니다.

이 문서에서 설명하는 재해 복구 접근 방법은 기본 및 보조 리전 대신 기본 및 보조 클라우드가 사용되는 경우에도 적용됩니다. 주요 차이점은 클라우드 사이의 네트워크 이기종성으로 인해 클라우드 내 리전 간의 네트워크 거리에 비해 클라우드간 지연 시간이 늘어날 수 있다는 것입니다. 다른 불일치는 클라우드 제공업체의 관리형 데이터베이스에서 제공되는 다양한 기능과 기본 설정으로 인해 발생할 수 있습니다.

전체 클라우드 실패 가능성은 리전 실패 가능성보다 낮습니다. 하지만 이 방식은 여전히 2개 클라우드에 애플리케이션을 배포해야 하는 기업의 경우에 유용합니다. 이 접근 방법은 기업을 장애로부터 보호하거나 비즈니스 또는 산업 규정을 준수하는 데 도움을 줄 수 있습니다.

또 다른 재해 복구 접근 방법은 기본 및 보조 리전과 기본 및 보조 클라우드를 사용하는 것입니다. 이 접근 방법의 경우 기업이 장애 상황을 해결하기 위해 최적의 재해 복구 프로세스를 선택할 수 있습니다. 애플리케이션 실행을 위해 서비스 중단 심각도에 따라 보조 리전 또는 보조 클라우드를 사용할 수 있습니다.

클라우드 버스팅

클라우드 버스팅은 서로 다른 배포 위치 간 애플리케이션 클라이언트 트래픽의 확장을 지원하는 구성을 의미합니다. 애플리케이션 버스팅은 용량 수요가 증가하고 보조 위치가 추가적인 용량을 제공할 때 발생합니다. 기본 위치가 일반 트래픽을 지원하고, 보조 위치는 애플리케이션 클라이언트 트래픽이 기본 위치가 지원할 수 있는 범위를 넘어 증가할 경우를 대비하여 추가 용량을 제공할 수 있습니다. 기본 및 보조 위치 모두 애플리케이션 서비스 인스턴스가 배포됩니다.

클라우드 버스팅은 한 클라우드가 기본 클라우드이고 두 번째 클라우드가 보조 클라우드인 클라우드 환경에서 구현됩니다. 퍼블릭 클라우드에서 탄력적인 클라우드 컴퓨팅 리소스를 사용하여 온프레미스 데이터 센터에서 제한된 개수의 컴퓨팅 리소스를 증분하기 위해 하이브리드 클라우드 컨텍스트에서 사용됩니다.

데이터베이스 지원을 위해 다음 옵션이 제공됩니다.

• 기본 위치 배포. 이 배포에서 데이터베이스는 기본 위치에만 배포되고 보조 위치에 배포되지 않습니다. 애플리케이션 버스팅이 발생하면 보조 위치의 애플리케이션이 기본 위치의 데이터베이스에 액세스합니다.
• 기본 및 대기 위치 배포. 이 배포는 기본 및 보조 위치를 모두 지원합니다. 데이터베이스 인스턴스는 두 위치 모두에 배포되고 특히 버스팅의 경우 해당 위치의 애플리케이션 서비스 인스턴스에 의해 액세스됩니다. 클라우드 내부 및 클라우드 간 재해 복구에서와 같이 2개의 데이터베이스가 트랜잭션 방식으로 동기화되거나 비동기적으로 동기화될 수 있습니다. 비동기식 동기화의 경우 지연 시간이 발생할 수 있습니다. 표준 위치에서 업데이트가 수행될 경우 이러한 업데이트가 기본 위치로 다시 전파되어야 합니다. 두 위치 모두 동시 업데이트가 발생될 수 있으므로 충돌 해결이 구현되어야 합니다.

클라우드 버스팅은 하이브리드 클라우드에서 온프레미스 데이터 센터의 용량 증가를 위한 일반적인 사용 사례입니다. 이것은 데이터를 한 국가 내에 유지해야 할 때 퍼블릭 클라우드 간에 사용될 수 있는 접근 방법이기도 합니다. 퍼블릭 클라우드에 한 국가에 하나의 리전만 포함되는 경우 동일 국가의 다른 퍼블릭 클라우드의 리전으로 버스팅이 발생할 수 있습니다. 이 접근 방법은 퍼블릭 클라우드 리전에서 리소스 제약조건을 해결하면서 해당 국가 내에 데이터가 유지되도록 보장합니다.

동급 최고의 클라우드 서비스 사용

일부 애플리케이션은 단일 클라우드에서 제공되지 않는 특별한 클라우드 서비스 및 제품이 필요합니다. 예를 들어 애플리케이션이 한 클라우드에서 비즈니스 데이터에 대해 비즈니스 논리 처리를 수행하고 다른 클라우드에서 비즈니스 데이터 분석을 수행할 수 있습니다. 이 사용 사례에서 애플리케이션의 비즈니스 논리 처리 부분과 분석 부분은 서로 다른 클라우드에 배포됩니다.

데이터 관리 관점에서 이 사용 사례는 다음과 같습니다.

• 파티션을 나눈 데이터. 애플리케이션의 각 부분에는 고유 데이터베이스(개별 파티션)가 포함되며, 이러한 데이터베이스 중 어느 것도 서로 직접 연결되지 않습니다. 데이터를 관리하는 애플리케이션은 두 데이터베이스(파티션)에 제공되어야 하는 데이터를 두 번 기록합니다.
• 비동기 복제 데이터베이스. 한 클라우드의 데이터가 다른 클라우드에서 제공되어야 하는 경우 비동기 복제 관계가 적합할 수 있습니다. 예를 들어 분석 애플리케이션에 비즈니스 애플리케이션에 대해 동일한 데이터 세트 또는 데이터 세트의 일부가 필요한 경우 후자가 클라우드 간에 복제됩니다.
• 트랜잭션 동기화 데이터베이스. 이러한 종류의 데이터베이스는 애플리케이션의 양쪽 부분에 데이터를 제공할 수 있게 해줍니다. 각 애플리케이션의 각 업데이트는 트랜잭션적으로 일관성이 있으며, 두 데이터베이스(파티션)에 즉시 제공됩니다. 트랜잭션적으로 동기화된 데이터베이스는 실제로 단일 분산 데이터베이스로 작동합니다.

분산 서비스

분산 서비스는 2개 이상의 배포 위치에서 배포 및 실행됩니다. 모든 서비스 인스턴스를 모든 배포 위치에 배포하는 것이 가능합니다. 또는 일부 서비스를 모든 위치에 배포하고, 하드웨어 가용성 또는 예상되는 제한된 로드와 같은 요소에 따라 위치 중 하나에만 일부를 배포할 수 있습니다.

트랜잭션적으로 동기화된 데이터베이스의 데이터는 모든 위치에서 일관성이 있습니다. 따라서 이러한 데이터베이스는 서비스 인스턴스를 모든 배포 위치에 배포하기에 가장 좋은 옵션입니다.

비동기적으로 복제된 데이터베이스를 사용하는 경우 동일한 데이터 항목이 2개의 배포 위치에서 동시에 수정될 위험이 있습니다. 2개의 충돌하는 변경사항 중 최종 일관성 상태인 것을 확인하기 위해 충돌 해결 전략을 구현해야 합니다. 충돌 해결 전략을 구현할 수 있지만 항상 간단하지는 않으며 데이터를 일관성 상태로 복원하기 위해 수동 개입이 필요한 경우도 있습니다.

분산 서비스 재배치 및 장애 조치

전체 클라우드 리전이 실패하면 재해 복구가 시작됩니다. 리전 또는 전체 애플리케이션이 아니라 스테이트풀(Stateful) 데이터베이스 애플리케이션의 단일 서비스가 실패할 경우 서비스를 복구하고 다시 시작해야 합니다.

재해 복구에 대한 초기 접근 방법은 실패한 서비스를 원래 배포 위치에서 다시 시작하는 것입니다(그대로 다시 시작 접근 방법). Kubernetes와 같은 기술은 해당 구성을 기준으로 서비스를 자동으로 다시 시작합니다.

하지만 이러한 그대로 다시 시작이 성공적이지 않은 경우의 대안은 보조 위치에서 서비스를 다시 시작하는 것입니다. 서비스는 기본 위치에서 보조 위치로 장애 조치됩니다. 애플리케이션이 분산 서비스의 집합으로 배포되면 단일 서비스의 장애 조치가 동적으로 수행될 수 있습니다.

데이터베이스 관점에서 원래 배포 위치에서 서비스를 다시 시작할 때는 특별한 데이터베이스 배포가 필요하지 않습니다. 서비스가 대체 배포 위치로 이동되고 서비스가 데이터베이스에 액세스하면 이 문서 앞 부분의 분산 서비스에서 설명한 동일한 준비 모델이 적용됩니다.

서비스가 임시 기준으로 다시 배치되고, 다시 배치하는 동안 기업에서 더 높은 지연 시간이 허용되는 경우 서비스가 배포 위치 간의 데이터베이스에 액세스할 수 있습니다. 서비스가 다시 배치되더라도 원래 배포 위치에서와 동일한 방법으로 데이터베이스에 계속 액세스합니다.

컨텍스트별 배포

일반적으로 모든 애플리케이션 클라이언트를 지원하는 단일 애플리케이션 배포에는 모든 애플리케이션 서비스 및 데이터베이스가 포함됩니다. 하지만 예외적인 사용 사례가 있습니다. 단일 애플리케이션 배포는 특정 기준에 따라 클라이언트의 일부만 지원할 수 있습니다. 즉, 2개 이상의 애플리케이션 배포가 필요합니다. 각 배포가 서로 다른 클라이언트 일부를 지원하고, 모든 배포가 함께 모든 클라이언트를 지원합니다.

컨텍스트별 배포의 예시 사용 사례는 다음과 같습니다.

• 모든 소형 테넌트에 대해 하나의 애플리케이션이 배포되고, 10개 단위의 중간 테넌트에 대해 또 다른 애플리케이션이 하나 배포되고, 각 프리미엄 테넌트마다 하나의 애플리케이션이 배포되는 멀티 테넌트 애플리케이션을 배포하는 경우
• 비즈니스 고객 및 정부 고객과 같이 개별 고객에 대한 요구가 있는 경우
• 개발, 스테이징, 프로덕션 환경을 구분해야 하는 경우

데이터베이스 관점에서 일대일 배포 전략으로 각 애플리케이션 배포에 대해 하나의 데이터베이스를 배포할 수 있습니다. 다음 다이어그램에 표시된 것처럼 이 전략은 각 배포에 고유 데이터 세트가 포함되기 때문에 파티션을 나눈 데이터가 생성되는 직관적인 접근 방법입니다.

앞의 다이어그램은 다음을 보여줍니다.

• 애플리케이션의 3개 배포가 포함된 설정
• 각 데이터 세트에는 고유한 해당 데이터베이스가 포함됩니다.
• 배포 간에는 데이터가 공유되지 않습니다.

많은 경우에 일대일 배포가 가장 적합한 전략이지만, 대안이 존재합니다.

멀티테넌시의 경우 테넌트가 다시 배치될 수 있습니다. 소형 테넌트가 중간 테넌트로 전환될 수 있으며, 다른 애플리케이션에 다시 배치되어야 할 수 있습니다. 이 경우 개별 데이터베이스 배포 시 데이터베이스 마이그레이션이 필요합니다. 분산 데이터베이스가 배포되고 동시에 모든 배포에서 사용되는 경우 모든 테넌트 데이터가 단일 데이터베이스 시스템에 상주합니다. 따라서 데이터베이스 간에 테넌트를 이동할 때는 데이터베이스 마이그레이션이 필요하지 않습니다. 다음 다이어그램은 이 종류의 데이터베이스 예시를 보여줍니다.

앞의 다이어그램은 다음을 보여줍니다.

• 3개의 애플리케이션 배포
• 배포가 모두 단일 분산 데이터베이스를 공유합니다.
• 애플리케이션이 각 배포의 모든 데이터에 액세스할 수 있습니다.
• 데이터 파티션 나누기는 구현되지 않습니다.

기업이 수명 주기 작업 중 테넌트를 자주 다시 배치하는 경우 데이터베이스 복제가 유용한 대안이 될 수 있습니다. 이 방식에서 테넌트 데이터는 테넌트 마이그레이션 전 데이터베이스 간에 복제됩니다. 이 경우 서로 다른 애플리케이션 배포에 대해 독립적인 데이터베이스가 사용되고 테넌트 마이그레이션 이전 및 중간에 복제를 위해서만 즉시 설정됩니다. 다음 다이어그램은 테넌트 마이그레이션 동안 두 애플리케이션 배포 사이의 일시적인 복제를 보여줍니다.

앞의 다이어그램은 각각 해당 배포와 연관된 데이터를 보유하고 있는 3개의 개별 데이터베이스가 포함된 애플리케이션의 3개 배포를 보여줍니다. 한 데이터베이스에서 다른 데이터베이스로 데이터를 마이그레이션하기 위해 일시적인 데이터베이스 마이그레이션을 설정할 수 있습니다.

애플리케이션 이동성

애플리케이션 이동성은 서로 다른 배포 위치, 특히 서로 다른 클라우드에 애플리케이션을 배포할 수 있게 해줍니다. 이러한 이동성은 애플리케이션 마이그레이션 준비를 위해 마이그레이션과 관련된 재설계 또는 추가적인 애플리케이션 개발을 수행할 필요 없이 언제든지 애플리케이션을 마이그레이션할 수 있게 해줍니다.

애플리케이션 이동성을 보장하기 위해서는 이 섹션의 뒷 부분에서 설명하는 다음 접근 방법 중 하나를 사용해야 합니다.

• 시스템 기반 이동성
• API 호환성
• 기능 기반 이동성

시스템 기반 이동성에는 모든 가능한 배포에서 사용되는 동일한 기술적 구성요소가 사용됩니다. 시스템 기반 이동성을 보장하기 위해서는 각 기술을 모든 잠재적인 배포 위치에서 사용할 수 있어야 합니다. 예를 들어 PostgreSQL과 같은 데이터베이스가 후보인 경우 예상되는 기간 동안 모든 잠재적인 배포 위치에서 가용성이 확인되어야 합니다. 프로그래밍 언어 및 인프라 기술과 같은 다른 모든 기술의 경우도 마찬가지입니다. 다음 다이어그램에 표시된 것처럼 이 접근 방법은 기술을 기반으로 모든 배포 위치 간에 일반적인 기능 집합을 설정합니다.

앞의 다이어그램은 애플리케이션에서 배포된 모든 위치에 정확히 동일한 데이터베이스 시스템이 요구되는 이동성 애플리케이션 배포를 보여줍니다. 각 위치에 동일한 데이터베이스 시스템이 사용되기 때문에 애플리케이션이 이동 가능합니다. 애플리케이션에서는 배포 간에 정확히 동일한 데이터베이스 시스템이 사용되도록 예상될 수 있습니다. 따라서 정확히 동일한 데이터베이스 시스템 인터페이스 및 동작이 간주될 수 있습니다.

데이터베이스 맥락의 API 호환성 시스템에서 클라이언트는 특정 데이터베이스 액세스 라이브러리(예: MySQL 클라이언트 라이브러리)를 사용하여 클라우드 환경에서 제공되는 모든 호환되는 구현에 연결될 수 있도록 보장합니다. 다음 다이어그램은 API 호환성을 보여줍니다.

위 다이어그램은 데이터베이스 시스템 대신 데이터베이스 시스템 API를 기반으로 애플리케이션 이동성을 보여줍니다. 데이터베이스 시스템이 각 위치에서 서로 다를 수 있지만 API가 동일하고 동일한 기능을 노출합니다. 기본 데이터베이스 시스템이 서로 다른 데이터베이스 기술이더라도 각 위치에서 API가 동일하다고 간주할 수 있기 때문에 애플리케이션에 이동성이 있습니다.

기능 기반 이동성에서는 서로 다른 클라우드에서 동일한 기능을 제공하는 서로 다른 기술이 사용될 수 있습니다. 예를 들어 데이터베이스 사용을 관계형 모델로 제한할 수 있습니다. 모든 관계형 데이터베이스 시스템이 애플리케이션을 지원할 수 있기 때문에 애플리케이션의 이동성에 영향을 주지 않고도 서로 다른 버전의 서로 다른 데이터베이스 시스템을 서로 다른 클라우드에서 사용할 수 있습니다. 기능 기반 이동성의 단점은 모든 관계형 데이터베이스 시스템이 지원하는 데이터베이스 모델의 일부만 사용할 수 있다는 것입니다. 모든 클라우드와 호환되는 데이터베이스 시스템 대신 데이터베이스 모델을 사용해야 합니다. 다음 다이어그램은 기능 기반 이동성의 예시 아키텍처를 보여줍니다.

앞의 다이어그램에 표시된 것처럼 데이터베이스 시스템 API와 데이터베이스 시스템은 각 위치에서 다를 수 있습니다. 이동성을 보장하기 위해 애플리케이션은 각 데이터베이스 시스템 및 각 위치에서 제공되는 각 API의 일부만 사용해야 합니다. 일반적으로 각 데이터베이스 시스템의 일부만 각 위치에 제공되기 때문에 애플리케이션이 해당 일부로 사용을 제한해야 합니다.

이 섹션에서 모든 옵션에 대해 이동성을 보장하기 위해서는 전체 아키텍처를 모든 대상 위치에 지속적으로 배포해야 합니다. 모든 단위 및 시스템 테스트 사례를 이러한 배포에 대해 실행해야 합니다. 이것들은 조기 감지 및 처리가 필요한 인프라 및 기술 상의 변경사항에 대해 필수적인 요구사항입니다.

공급업체 종속성 방지

공급업체 종속성(록인, Lock-In) 방지는 특정 기술 및 공급업체에 종속될 위험을 완화하는 데 도움을 줍니다. 이것은 표면적으로 애플리케이션 이동성과 비슷합니다. 공급업체 종속성 방지는 클라우드 서비스뿐만 아니라 사용되는 모든 기술에 적용됩니다. 예를 들어 MySQL이 데이터베이스 시스템으로 사용되고 클라우드의 가상 머신에 설치된 경우 클라우드 관점에서 종속성이 없지만 MySQL에 대한 종속성이 존재합니다. 클라우드 간 이동성이 있는 애플리케이션은 클라우드와 다른 공급업체에서 제공되는 기술에 따라 달라질 수 있습니다.

공급업체 종속성을 방지하기 위해서는 모든 기술이 대체 가능해야 합니다. 따라서 애플리케이션 구현 방법에 영향을 주지 않고 각 애플리케이션 서비스를 서로 다른 기술 기반에 구현할 수 있도록 모든 애플리케이션 기능에 대한 철저하고 구조적인 추상화가 필요합니다. 데이터베이스 관점에서 이러한 추상화는 데이터베이스 모델 사용을 특정 데이터베이스 관리 시스템으로부터 구분하는 방식으로 수행될 수 있습니다.

기존 프로덕션 데이터베이스 관리 시스템

많은 멀티클라우드 애플리케이션이 설계 중 데이터베이스 시스템으로 개발되지만 많은 기업들은 멀티클라우드 애플리케이션을 애플리케이션 현대화 노력의 일환으로 개발합니다. 이러한 애플리케이션은 새롭게 설계 및 구현된 애플리케이션이 기존 데이터베이스에 액세스한다는 가정으로 개발됩니다.

기존 데이터베이스를 현대화 과정에 포함시키지 않는 데에는 많은 이유가 있습니다. 다른 데이터베이스 시스템에서 제공되지 않는 특정 기능이 사용될 수 있습니다. 이미 한 기업의 데이터베이스에 복잡하게 잘 설정된 관리 프로세스가 포함되어 있어서 이를 다른 시스템으로 이동하는 것이 실용적이거나 경제적이지 않을 수 있습니다. 또는 기업에서 먼저 애플리케이션 현대화를 선택한 후 데이터베이스 현대화를 뒤늦게 선택할 수도 있습니다.

기업에 기존 데이터베이스 시스템이 사용되는 경우 멀티클라우드 애플리케이션 설계자는 이것이 유일한 데이터베이스로 사용될지 또는 다른 배포 위치에 다른 데이터베이스 시스템을 추가해야 할지 결정해야 합니다. 예를 들어 데이터베이스가 온프레미스에서 사용되고 애플리케이션을 Google Cloud에서 실행해야 할 경우 Google Cloud에 배포되는 애플리케이션 서비스가 온프레미스 데이터베이스에 액세스하는지 여부를 고려해야 합니다. 또는 보조 데이터베이스를 Google Cloud에 배포하고 로컬로 실행되는 애플리케이션 서비스에 사용해야 하는지 고려해야 합니다.

보조 데이터베이스가 Google Cloud에 배포될 경우 사용 사례는 클라우드 버스팅 또는 분산 서비스에 설명된 사용 사례와 동일할 수 있습니다. 어느 경우든 이 섹션의 설명과 동일한 데이터베이스 논의가 적용됩니다. 하지만 이것은 동기화 및 복제와 같은 기존의 온프레미스 데이터베이스가 지원할 수 있는 위치 간 기능으로 제한됩니다.

배포 패턴

이 문서에서 설명하는 사용 사례는 데이터베이스 관점에서 한 가지 일반적인 질문을 제기합니다. 데이터베이스가 1개를 초과하는 배포 위치에 있다면 이들 사이의 관계는 어떻게 될까요?

다음 섹션에서 설명하는 이들 사이의 주요 관계(배포 패턴)는 다음과 같이 분류됩니다.

• 데이터베이스 간 종속성을 제외한 파티션 나누기
• 비동기 단방향 복제
• 충돌 해결을 포함하는 양방향 복제
• 완전한 활성-활성 동기화 분산 시스템

이 문서의 각 사용 사례는 네 가지 배포 패턴 중 하나 이상에 매핑될 수 있습니다.

다음 설명에서는 클라이언트가 애플리케이션 서비스에 직접 액세스한다고 가정합니다. 사용 사례에 따라 다음 다이어그램에 표시된 것처럼 클라이언트 액세스를 애플리케이션으로 동적으로 연결하기 위해 부하 분산기가 필요할 수 있습니다.

위 다이어그램에서는 클라우드 부하 분산기가 클라우드 호출을 사용 가능한 위치 중 하나로 연결합니다. 부하 분산기는 부하 분산 정책이 적용되고 클라이언트가 해당 애플리케이션 및 데이터베이스의 올바른 위치에 연결되도록 보장합니다.

데이터베이스 간 종속성을 제외한 파티션 나누기

이 배포 패턴은 이 문서에서 설명하는 모든 패턴 중 가장 단순한 형태입니다. 각 위치 또는 클라우드에 데이터베이스가 있고, 데이터베이스에는 서로 종속되지 않은 파티션을 나눈 데이터 세트가 있습니다. 데이터 항목은 단 하나의 데이터베이스에만 저장됩니다. 각 데이터 파티션은 고유 데이터베이스에 있습니다. 이 패턴의 예시는 데이터 세트가 하나 또는 다른 데이터베이스에 있는 멀티 테넌트 애플리케이션입니다. 다음 다이어그램은 2개의 완전히 파티션을 나눈 애플리케이션을 보여줍니다.

이전 다이어그램에 표시된 것처럼 애플리케이션이 2개 위치에 배포되고, 각 위치는 전체 데이터 세트의 파티션을 담당합니다. 각 데이터 항목은 위치 중 하나에만 존재하여, 둘 사이의 복제 없이 파티션을 나눈 데이터 세트를 보장합니다.

파티션을 나눈 데이터 세트의 대체 배포 패턴에서 데이터 세트는 완전히 분할되지만 여전히 동일한 데이터베이스 내에 저장되어 있습니다. 모든 데이터 세트를 포함하는 데이터베이스는 하나 뿐입니다. 데이터 세트가 동일한 데이터베이스 내에 저장되지만 데이터 세트는 완전히 분리되어 있으며(파티션 나누기) 하나를 변경해도 다른 하나에 영향을 주지 않습니다. 다음 다이어그램은 단일 데이터베이스를 공유하는 2개의 애플리케이션을 보여줍니다.

앞의 다이어그램은 다음을 보여줍니다.

• 첫 번째 위치에 있는 공통 데이터베이스를 공유하는 2개의 애플리케이션 배포
• 데이터 세트가 분할되지 않았기 때문에 각 애플리케이션이 배포에 있는 모든 데이터에 액세스할 수 있습니다.

비동기 단방향 복제

이 배포 패턴은 하나 이상의 보조 데이터베이스에 복제되는 기본 데이터베이스를 포함합니다. 보조 데이터베이스는 읽기 액세스에 사용할 수 있지만 애플리케이션은 잠재적인 복제 지연을 고려해야 합니다. 이 패턴의 예시는 특정 사용 사례의 최적 데이터베이스가 기본 데이터베이스로 사용되고 보조 데이터베이스가 분석용으로 사용되는 경우입니다. 다음 다이어그램은 단방향으로 복제된 데이터베이스에 액세스하는 2개의 애플리케이션을 보여줍니다.

앞의 다이어그램에 표시된 것처럼 2개 데이터베이스 중 하나가 다른 하나의 복제본입니다. 다이어그램의 화살표는 복제 방향을 나타냅니다. 위치 1에 있는 데이터베이스 시스템의 데이터는 위치 2에 있는 데이터베이스 시스템으로 복제됩니다.

충돌 해결을 포함하는 양방향 복제

이 배포 패턴에는 서로 비동기적으로 복제되는 2개의 기본 데이터베이스가 포함됩니다. 동일한 기본 키와 같은 동일한 데이터가 각 데이터베이스에 동시에 기록되면 쓰기-쓰기 충돌이 발생할 수 있습니다. 이러한 위험 때문에 복제 중 마지막 상태가 무엇인지 확인할 수 있도록 충돌 확인이 준비되어 있어야 합니다. 이 패턴은 쓰기-쓰기 충돌 가능성이 드문 상황에서 사용될 수 있습니다. 다음 다이어그램은 양방향으로 복제된 데이터베이스에 액세스하는 2개의 애플리케이션을 보여줍니다.

앞의 다이어그램에 표시된 것처럼 각 데이터베이스가 서로 상대되는 데이터베이스에 복제됩니다. 다이어그램에서 2개의 개별 파란색 화살표로 표시된 것처럼 2개의 복제가 서로 독립적입니다. 2개의 복제가 독립적이기 때문에 우연히 동일한 데이터 항목이 각 애플리케이션에서 변경되고 동시에 복제된다면 충돌이 발생할 수 있습니다. 이 경우 충돌 해결이 수행되어야 합니다.

완전한 활성-활성 동기화 분산 시스템

이 배포 패턴에는 활성-활성 (또한 기본-기본) 설정을 갖는 단일 데이터베이스가 포함됩니다. 활성-활성 설정에서 모든 기본 데이터베이스의 데이터 업데이트는 트랜잭션적으로 일관성이 있고 비동기적으로 복제됩니다. 이 패턴의 예시 사용 사례는 분산형 계산입니다. 다음 다이어그램은 완전 동기화된 기본-기본 데이터베이스에 액세스하는 2개의 애플리케이션을 보여줍니다.

앞의 다이어그램에 표시된 것처럼 이 구성에서는 각 애플리케이션이 지연 시간 또는 충돌 위험 없이 마지막으로 일관된 상태에 항상 액세스합니다. 한 데이터베이스의 변경사항은 다른 데이터베이스에 즉시 제공됩니다. 트랜잭션 커밋 변경이 발생할 때 모든 변경사항이 두 데이터베이스 모두에 반영됩니다.

데이터베이스 시스템 분류

이 문서에서 설명된 배포 패턴이 모든 데이터베이스 관리 시스템에 동일하게 잘 사용될 수는 없습니다. 사용 사례에 따라 하나의 배포 패턴 또는 데이터베이스 시스템 일부와의 데이터베이스 패턴 조합을 구현하는 것만 가능할 수 있습니다.

다음 섹션에서는 여러 데이터베이스 시스템을 분류하고 4개 배포 패턴에 어떻게 매핑되는지를 보여줍니다.

데이터 모델, 내부 아키텍처, 배포 모델, 트랜잭션 유형과 같은 다른 측정기준에 따라 데이터베이스를 분류하는 것이 가능합니다. 다음 섹션에서는 멀티클라우드 데이터베이스 관리 목적에 따라 두 가지 측정기준이 사용됩니다.

• 배포 아키텍처. 데이터베이스 관리 시스템이 클라우드 리소스에 배포되는 방식을 나타내는 아키텍처입니다(예: Compute Engine 또는 클라우드 관리).
• 분산 모델. 데이터베이스 시스템에서 지원되는 분산 모델입니다(예: 단일 인스턴스 또는 완전 분산형).

이러한 2가지 측정기준은 멀티 클라우드 사용 사례 맥락에서 가장 관련이 있으며 멀티 클라우드 데이터베이스 사용 사례에서 파생된 4가지 배포 패턴을 지원할 수 있습니다. 인기 있는 분류는 데이터베이스 관리 시스템에서 지원되는 데이터 모델을 기반으로 합니다. 일부 시스템은 모델을 하나만 지원합니다(예: 그래프 모델). 다른 시스템은 동시에 여러 개의 데이터 모델을 지원합니다(예: 관계형 및 문서 모델). 하지만 멀티 클라우드 애플리케이션이 해당 멀티 클라우드 배포에 대해 어떤 데이터 모델도 사용할 수 있기 때문에 멀티 클라우드 데이터베이스 관리 맥락에서는 이러한 분류가 관련성이 없습니다.

배포 아키텍처별 데이터베이스 시스템

멀티 클라우드 데이터베이스 관리에는 데이터베이스 관리 시스템에 대한 배포 아키텍처의 4가지 기본 클래스가 포함됩니다.

• 기본 제공 클라우드 데이터베이스. 기본 제공 클라우드 데이터베이스는 클라우드 기술을 지원하도록 설계, 빌드, 최적화됩니다. 예를 들어 일부 데이터베이스 시스템은 Kubernetes를 해당 구현 플랫폼으로 사용하고 Kubernetes 기능을 사용합니다. CockroachDB 및 YugaByte는 이러한 종류의 데이터베이스 예시입니다. 이러한 데이터베이스는 Kubernetes를 지원하는 모든 클라우드에 배포될 수 있습니다.
• 클라우드 제공업체 관리형 데이터베이스. 클라우드 제공업체 관리형 데이터베이스는 특정 클라우드 제공업체 관련 기술을 기반으로 하며 특정 클라우드 제공업체에서 관리되는 데이터베이스 서비스입니다. Spanner, Bigtable, PostgreSQL용 AlloyDB는 이러한 종류의 데이터베이스 예시입니다. 클라우드 제공업체 관리형 데이터베이스는 클라우드 제공업체의 클라우드에서만 사용할 수 있고 다른 곳에서 설치하고 실행할 수 없습니다. 하지만 PostgreSQL용 AlloyDB는 PostgreSQL과 완전히 호환됩니다.
• 클라우드 이전 데이터베이스. 클라우드 이전 데이터베이스는 오래 전의 클라우드 기술 개발 전에 존재했으며 일반적으로 베어메탈 하드웨어 및 가상 머신(VM)에서 실행되었습니다. PostgreSQL, MySQL, SQL Server는 이러한 종류의 데이터베이스 예시입니다. 이러한 시스템은 필요한 VM 또는 베어메탈 하드웨어를 지원하는 모든 클라우드에서 실행될 수 있습니다.
• 클라우드 파트너 관리형 데이터베이스. 일부 퍼블릭 클라우드에는 고객 데이터베이스를 퍼블릭 클라우드에 설치하고 관리하는 데이터베이스 파트너가 포함되어 있습니다. 이러한 이유로 고객은 이러한 데이터베이스를 직접 관리할 필요가 없습니다. MongoDB Atlas 및 MariaDB는 이러한 종류의 데이터베이스 예시입니다.

이러한 기본 범주에는 몇 가지 변형이 존재합니다. 예를 들어 클라우드용으로 빌드된 데이터베이스를 구현하는 데이터베이스 공급업체는 해당 공급업체 제공 클라우드에서 클라우드용으로 빌드된 기술 설치 및 관리 오퍼링을 고객들에게 제공할 수 있습니다. 이 접근 방법은 데이터베이스를 단일 서비스만으로 지원하는 퍼블릭 클라우드를 제공하는 공급업체와 동일합니다.

클라우드 이전 데이터베이스는 컨테이너에 있을 수 있으며 Kubernetes 클러스터에 배포될 수 있습니다. 하지만 이러한 데이터베이스는 확장, 멀티 서비스, 멀티 Pod 배포와 같은 Kubernetes 특정 기능을 사용하지 않습니다.

데이터베이스 제공업체는 동시에 둘 이상의 퍼블릭 클라우드 제공업체와 협력하여 2개 이상의 퍼블릭 클라우드에서 클라우드 파트너 관리형 데이터베이스로 데이터베이스를 제공할 수 있습니다.

분산 모델별 데이터베이스 시스템

데이터베이스의 아키텍처에서 분산 모델에 따라 여러 데이터베이스 관리 시스템이 구현됩니다. 데이터베이스 모델은 다음과 같습니다.

• 단일 인스턴스. 단일 데이터베이스 인스턴스는 하나의 VM 또는 하나의 컨테이너에서 실행되고 중앙화된 시스템으로 작동합니다. 이 시스템은 모든 데이터베이스 액세스를 관리합니다. 단일 인스턴스를 다른 인스턴스에 연결할 수 없기 때문에 데이터베이스 시스템이 복제를 지원하지 않습니다.
• 멀티 인스턴스 활성-수동. 이 일반적인 아키텍처에서는 여러 데이터베이스 인스턴스가 하나로 연결됩니다. 가장 일반적인 연결은 하나의 인스턴스가 두 인스턴스를 모두 지원하고 쓰기 및 읽기를 수행하는 활성 데이터베이스 인스턴스인 활성-수동 관계입니다. 하나 이상의 수동 시스템은 읽기 전용이며 기본 데이터베이스에서 동기적 또는 비동기적으로 모든 데이터베이스 변경사항을 수신합니다. 수동 시스템은 읽기 액세스를 제공할 수 있습니다. 활성-수동은 기본-보조 또는 소스-레플리카라고도 합니다.
• 멀티 인스턴스 활성-활성. 비교적 일반적이지 않은 이 아키텍처에서 각 인스턴스는 활성 인스턴스입니다. 이 경우에 각 인스턴스는 읽기 및 쓰기 트랜잭션을 수행하고 데이터 일관성을 제공할 수 있습니다. 이러한 이유로 데이터 비일관성을 방지하기 위해 모든 인스턴스가 항상 동기화됩니다.
• 충돌 해결이 포함된 멀티 인스턴스 활성-활성. 이것도 또한 비교적 덜 일반적인 시스템입니다. 각 인스턴스가 읽기 및 쓰기 액세스용으로 제공되지만 데이터베이스가 비동기 모드로 동기화됩니다. 동시 데이터 항목에 대한 동시 업데이트가 허용되어 비일관적인 상태로 이어집니다. 충돌 해결 정책으로 마지막 일관성 상태가 무엇인지 결정해야 합니다.
• 멀티 인스턴스 샤딩. 샤딩은 분리된 데이터 파티션 관리를 기반으로 합니다. 개별 데이터베이스 인스턴스가 각 파티션을 관리합니다. 시간 경과에 따라 더 많은 샤드를 추가할 수 있기 때문에 이러한 배포는 확장 가능합니다. 하지만 모든 시스템에서 이 기능이 지원되지는 않기 때문에 샤드 간 쿼리가 가능하지 않을 수 있습니다.

이 섹션에서 설명된 모든 배포 모델은 샤딩을 지원할 수 있으며, 샤딩된 시스템일 수 있습니다. 하지만 모든 시스템이 샤딩 옵션을 제공하도록 설계되지는 않습니다. 샤딩은 확장성 개념이며 일반적으로 멀티 클라우드 환경의 아키텍처 데이터베이스 선택과 관련이 없습니다.

배포 모델은 클라우드 및 파트너 관리형 데이터베이스에 대해 다릅니다. 이러한 데이터베이스가 클라우드 제공업체의 아키텍처와 연결되기 때문에 이러한 시스템은 다음 배포 위치를 기반으로 아키텍처를 구현합니다.

• 영역 시스템. 영역 관리형 데이터베이스 시스템은 영역에 연결됩니다. 영역을 사용할 수 있으면 데이터베이스 시스템도 사용할 수 있습니다. 하지만 영역을 사용할 수 없으면 데이터베이스에 액세스할 수 없습니다.
• 리전 시스템. 리전 관리형 데이터베이스는 리전에 연결되며 하나 이상의 영역에 액세스할 수 있을 때 액세스할 수 있습니다. 임의의 영역 조합은 액세스가 불가능할 수 있습니다.
• 리전 간 시스템. 리전 간 시스템은 2개 이상의 리전에 연결되며 하나 이상의 리전을 사용할 수 있을 때 올바르게 작동합니다.

또한 기업에서 사용하려는 모든 클라우드에 데이터베이스를 설치할 수 있는 경우에는 교차 리전 시스템이 교차 클라우드 시스템을 지원할 수 있습니다.

이 섹션에서 설명하는 관리형 데이터베이스 아키텍처에 대한 다른 가능한 대안이 있습니다. 리전 시스템은 2개 영역 간에 디스크를 공유할 수 있습니다. 두 영역 중 하나가 액세스할 수 없게 되면 데이터베이스 시스템이 남은 영역에서 계속 실행될 수 있습니다. 하지만 중단이 두 영역에 모두 영향을 주면 다른 영역이 완전 온라인 상태인 경우에도 데이터베이스 시스템이 사용할 수 없게 됩니다.

배포 패턴에 데이터베이스 시스템 매핑

다음 표에서는 이 문서에 설명된 배포 패턴 및 배포 아키텍처가 서로 어떻게 연관되어 있는지를 설명합니다. 각 필드에서는 배포 패턴 및 배포 아키텍처를 기준으로 가능한 조합을 위해 필요한 조건을 설명합니다.

배포 아키텍처	배포 패턴
	데이터베이스 간 종속성을 제외한 파티션 나누기	비동기 단방향 복제	충돌 해결을 포함하는 양방향 복제	완전한 활성-활성 동기화 분산 시스템
기본 제공 클라우드 데이터베이스	데이터베이스 시스템에서 사용되는 기본 제공되는 클라우드 기술을 제공하는 모든 클라우드에서 사용 가능합니다. 동일한 데이터베이스를 사용할 수 없으면 다른 데이터베이스 시스템을 사용할 수 있습니다.	복제를 제공하는 클라우드 데이터베이스	양방향 복제를 제공하는 클라우드 데이터베이스	기본-기본 동기화를 제공하는 클라우드 데이터베이스
클라우드 제공업체 관리형 데이터베이스	데이터베이스 시스템은 클라우드마다 다를 수 있습니다.	복제본은 클라우드 제공업체 관리형 데이터베이스일 필요가 없습니다(배포 패턴에서 데이터베이스 마이그레이션 기술의 역할 참조).	데이터베이스가 양방향 복제를 제공하는 경우 클라우드 사이가 아니라 클라우드 내에만 있으면 됩니다.	데이터베이스가 기본-기본 동기화를 제공하는 경우 클라우드 사이가 아니라 클라우드 내에만 있으면 됩니다.
클라우드 이전 데이터베이스	데이터베이스 시스템이 동일하거나 각 클라우드마다 다를 수 있습니다.	복제는 여러 클라우드 간에 가능합니다.	데이터베이스 시스템이 양방향 복제 및 충돌 해결을 제공합니다.	데이터베이스 시스템이 기본-기본 동기화를 제공합니다.
클라우드 파트너 관리형 데이터베이스	데이터베이스 시스템은 클라우드마다 다를 수 있습니다. 파트너가 모든 필수 클라우드에서 관리형 데이터베이스를 제공하는 경우 동일한 데이터베이스를 사용할 수 있습니다.	복제본은 클라우드 제공업체 관리형 데이터베이스일 필요가 없습니다. 파트너가 모든 필수 클라우드에서 관리형 데이터베이스를 제공하는 경우 동일한 데이터베이스를 사용할 수 있습니다.	데이터베이스 시스템이 양방향 복제 및 충돌 해결을 제공합니다.	데이터베이스 시스템이 기본-기본 동기화를 제공합니다.

데이터베이스 시스템이 기본 제공 복제를 제공하지 않으면 대신 데이터베이스 복제 기술을 사용할 수 있습니다. 자세한 내용은 배포 패턴에서 데이터베이스 마이그레이션 기술의 역할을 참조하세요.

다음 표에서는 배포 패턴과 배포 모델의 관계를 보여줍니다. 각 필드에서는 배포 패턴 및 배포 모델에 따라 사용 가능한 조합의 조건을 보여줍니다.

배포 모델	배포 패턴
	데이터베이스 간 종속성을 제외한 파티션 나누기	비동기 단방향 복제	충돌 해결을 포함하는 양방향 복제	완전한 활성-활성 동기화 분산 시스템
단일 인스턴스	관련된 클라우드에서 동일 또는 다른 데이터베이스 시스템에서 사용 가능합니다.	해당 없음	해당 사항 없음	해당 없음
멀티 인스턴스 활성-수동	관련된 클라우드에서 동일 또는 다른 데이터베이스 시스템에서 사용 가능합니다.	클라우드 간에 복제가 가능합니다.	클라우드 간에 복제가 가능합니다.	해당 없음
멀티 인스턴스 활성-활성	관련된 클라우드에서 동일 또는 다른 데이터베이스 시스템에서 사용 가능합니다.	해당 없음	해당 없음	동기화는 클라우드 간에 가능합니다.
충돌 해결이 포함된 멀티 인스턴스 활성-활성	관련된 클라우드에서 동일 또는 다른 데이터베이스 시스템에서 사용 가능합니다.	해당 없음	해당 없음	양방향 복제가 클라우드 간에 가능한 경우에 적용됩니다.

기본 데이터베이스 기술을 기반으로 추가적인 추상화를 더하는 배포 모델의 일부 구현에는 활성-활성 시스템인 Postgres-BDR과 같은 배포 모델이 기본 제공되지 않습니다. 이러한 시스템은 앞의 표에서 해당 카테고리에 포함되어 있습니다. 멀티클라우드 관점에서 배포 모델의 구현 방법은 관련이 없습니다.

데이터베이스 마이그레이션 및 복제

사용 사례에 따라 기업은 하나의 배포 위치에서 다른 위치로 데이터베이스를 마이그레이션해야 할 수 있습니다. 또는 다운스트림 처리의 경우 데이터베이스의 데이터를 다른 위치에 복제해야 할 수 있습니다. 다음 섹션에서는 데이터베이스 마이그레이션 및 데이터베이스 복제에 대해 더 자세히 설명합니다.

데이터베이스 마이그레이션

데이터베이스 마이그레이션은 데이터베이스를 하나의 배포 위치에서 다른 위치로 이동할 때 사용됩니다. 예를 들어 온프레미스 데이터 센터에서 실행되는 데이터베이스를 대신 클라우드에서 실행되도록 마이그레이션할 수 있습니다. 마이그레이션이 완료된 후에는 데이터베이스가 온프레미스 데이터 센터에서 종료됩니다.

데이터베이스 마이그레이션에 대한 기본 접근 방법은 다음과 같습니다.

• 리프트 앤 시프트. 데이터베이스 인스턴스를 실행하는 VM 및 디스크가 현재 상태 그대로 대상 환경에 복사됩니다. 복사된 후 작동이 시작되고 마이그레이션이 완료됩니다.
• 내보내기, 가져오기, 백업, 복원. 이 접근 방법은 모두 데이터베이스 시스템 기능을 사용하여 데이터베이스를 외부화하고 이를 대상 위치에서 다시 만듭니다. 내보내기/가져오기는 일반적으로 ASCII 형식을 기반으로 하며, 백업 및 복원은 바이너리 형식을 기반으로 합니다.
• 제로 다운타임 마이그레이션. 이 접근 방법에서는 애플리케이션 시스템이 소스 시스템을 액세스하는 동안에 데이터베이스가 마이그레이션됩니다. 초기 로드 후에는 변경 데이터 캡처(CDC) 기술을 사용하여 소스에서 대상 데이터베이스로 변경사항이 전달됩니다. 애플리케이션에서는 소스 데이터베이스 시스템에서 중지된 시간부터 마이그레이션이 완료된 후 대상 데이터베이스 시스템에서 다시 시작되는 시간까지 다운타임이 발생합니다.

데이터베이스 마이그레이션은 데이터베이스가 한 클라우드에서 다른 클라우드로 또는 한 종류의 데이터베이스 엔진에서 다른 종류로 이동되는 멀티클라우드 사용 사례와 관련이 있습니다.

데이터베이스 마이그레이션은 다각적인 프로세스입니다. 자세한 내용은 데이터베이스 마이그레이션: 개념 및 원칙(1부)과 데이터베이스 마이그레이션: 개념 및 원칙(2부)을 참조하세요.

내보내기 및 가져오기, 백업 및 복원, 기본 제공되는 복제 프로토콜 등 기본 제공되는 데이터베이스 기술을 사용하여 데이터베이스 마이그레이션을 수행할 수 있습니다. 소스 및 대상 시스템이 다른 데이터베이스 시스템인 경우에는 마이그레이션 기술이 데이터베이스 마이그레이션에 가장 적합한 옵션입니다. Database Migration Service, Striim, Debezium은 데이터베이스 마이그레이션 기술의 예시입니다.

데이터베이스 복제

데이터베이스 복제는 데이터베이스 마이그레이션과 비슷합니다. 하지만 데이터베이스 복제 중에는 소스 데이터베이스 시스템이 그대로 유지되고 모든 변경사항이 대상 데이터베이스로 전달됩니다.

데이터베이스 복제는 소스 데이터베이스에서 대상 데이터베이스로 변경사항을 전송하는 지속적인 프로세스입니다. 이 프로세스가 비동기적이면 짧은 지연 시간 후에 변경사항이 대상 데이터베이스에 도착합니다. 프로세스가 동기적이면 소스 시스템의 변경사항이 동시에 대상 시스템으로 그리고 동일한 트랜잭션으로 전송됩니다.

소스를 대상 데이터베이스로 복제하는 것 외에도 일반적인 방법은 소스 데이터베이스에서 대상 분석 시스템으로 데이터를 복제하는 것입니다.

데이터베이스 마이그레이션과 마찬가지로 복제 프로토콜을 사용할 수 있는 경우 기본 제공되는 데이터베이스 기술을 데이터베이스 복제에 사용할 수 있습니다. 기본 제공되는 복제 프로토콜이 없으면 Striim 또는 Debezium과 같은 복제 기술을 사용할 수 있습니다.

복제 패턴에서 데이터베이스 마이그레이션 기술의 역할

비동기(이기종) 복제와 같이 배포 패턴에서 다른 데이터베이스 시스템이 사용될 때는 복제를 사용 설정하기 위한 기본 제공되는 데이터베이스 기술을 일반적으로 사용할 수 없습니다. 대신 이러한 종류의 복제를 사용 설정하도록 데이터베이스 마이그레이션 기술을 배포할 수 있습니다. 이러한 마이그레이션 시스템 일부는 또한 양방향 복제를 구현합니다.

배포 패턴에 데이터베이스 시스템 매핑의 표 1 또는 표 2에서 '해당 없음'으로 표시된 조합으로 사용되는 데이터베이스 시스템에 대해 데이터베이스 마이그레이션 또는 복제 기술을 사용할 수 있으면 이를 데이터베이스 복제에 사용하는 것이 가능할 수 있습니다. 다음 다이어그램은 마이그레이션 기술을 사용하는 데이터베이스 복제 접근 방법을 보여줍니다.

앞의 다이어그램에서 위치 1의 데이터베이스는 위치 2의 데이터베이스에 복제됩니다. 직접 데이터베이스 시스템 복제 대신 마이그레이션 서버가 복제 구현을 위해 배포됩니다. 이 접근 방법은 구현에 빌드된 데이터베이스 복제 기능이 없고 복제 구현을 위해 데이터베이스 시스템과 별개의 시스템을 사용해야 하는 데이터베이스 시스템에 사용됩니다.

멀티 클라우드 데이터베이스 선택

데이터베이스 시스템 분류와 조합된 멀티 클라우드 데이터베이스 사용 사례는 특정 사용 사례에 가장 적합한 데이터베이스를 결정하는 데 도움을 줍니다. 예를 들어 애플리케이션 이동성의 사용 사례를 구현하기 위해서는 두 가지 옵션이 있습니다. 첫 번째 옵션은 모든 클라우드에서 동일한 데이터베이스 엔진을 사용할 수 있도록 하는 것입니다. 이 접근 방법은 시스템 이동성을 보장합니다. 두 번째 옵션은 모든 클라우드에서 동일한 데이터 모델 및 쿼리 인터페이스를 사용할 수 있도록 하는 것입니다. 데이터베이스 시스템이 다를 수 있지만 이동성은 기능적 인터페이스로 제공됩니다.

다음 섹션의 결정 트리는 이 문서의 멀티클라우드 데이터베이스 사용 사례에 대한 의사 결정 기준을 보여줍니다. 결정 트리는 각 사용 사례에 대해 고려할 최적의 데이터베이스를 제안합니다.

기존 데이터베이스 시스템의 권장사항

데이터베이스 시스템이 프로덕션에 있으면 이를 유지 또는 교체할지를 결정해야 합니다. 다음 다이어그램은 결정 프로세스에서 필요한 질문을 보여줍니다.

결정 트리의 질문과 답변은 다음과 같습니다.

• 데이터베이스 시스템이 프로덕션에 있나요?
  • 데이터베이스 시스템이 프로덕션에 없으면 데이터베이스 시스템을 선택합니다 (멀티클라우드 데이터베이스 관리 결정으로 건너뛰기).
  • 데이터베이스 시스템이 프로덕션에 있으면 이를 유지해야 하는지 여부를 평가합니다.
• 데이터베이스 시스템이 프로덕션에 있으면 이를 유지해야 하는지 여부를 평가합니다.
  • 데이터베이스 시스템을 유지해야 할 경우에는 해당 결정을 내리고 결정 프로세스가 완료됩니다.
  • 데이터베이스 시스템을 변경하거나 결정을 아직 내려야 하는 경우, 데이터베이스 시스템을 선택합니다 (멀티클라우드 데이터베이스 관리 결정으로 건너뛰기).

멀티 클라우드 데이터베이스 관리 결정

다음 결정 트리는 멀티 위치 데이터베이스 요구사항 (멀티 클라우드 데이터베이스 배포 포함)에 따른 사용 사례에 대한 것입니다. 여기에서는 의사 결정 기준의 기초로 배포 패턴이 사용됩니다.

결정 트리의 질문과 답변은 다음과 같습니다.

• 교차 데이터베이스 종속성 없이 데이터가 서로 다른 데이터베이스에서 분할되나요?
  • 그렇다면 동일한 또는 서로 다른 데이터베이스 시스템을 각 위치에 대해 선택할 수 있습니다.
  • 그렇지 않으면 다음 질문으로 진행합니다.
• 비동기 단방향 복제가 필요한가요?
  • 그렇다면 데이터베이스 복제 시스템이 허용되는지 확인합니다.
    • 그렇다면 복제 시스템과 호환되는 동일한 또는 서로 다른 데이터베이스 시스템을 선택합니다.
    • 그렇지 않으면 활성-수동 배포 모델을 구현할 수 있는 데이터베이스 시스템을 선택합니다.
    • 그렇지 않으면 다음 질문으로 진행합니다.
• 동기화된 인스턴스가 있는 데이터베이스 시스템을 선택합니다.
  • 충돌 해결이 허용되나요?
    • 그렇다면 양방향 복제 데이터베이스 시스템 또는 활성-활성 데이터베이스 시스템을 선택합니다.
    • 그렇지 않으면 활성-활성 시스템을 선택합니다.

하나 이상의 멀티클라우드 사용 사례가 구현된 경우 기업은 모든 사용 사례를 지원하도록 하나의 데이터베이스 시스템을 사용할지 아니면 다중 데이터베이스 시스템을 사용할지를 결정해야 합니다.

기업이 하나의 데이터베이스 시스템을 사용하여 모든 사용 사례를 지원하려는 경우에는 최적 동기화의 시스템이 최적 옵션입니다. 예를 들어 동기화된 인스턴스와 함께 단방향 복제가 필요한 경우 최적 옵션은 동기화된 인스턴스입니다.

동기화 품질의 계층(낮음부터 최적까지)은 분할, 단방향 복제, 양방향 복제, 완전 동기화 복제입니다.

배포 권장사항

이 섹션에서는 멀티클라우드 애플리케이션 마이그레이션 또는 개발을 위해 데이터베이스를 선택할 때 따라야 할 권장사항에 대해 설명합니다.

기존 데이터베이스 관리 시스템

특정 사용 사례에 따라 필요하지 않다면 데이터베이스를 유지하고 변경하지 않는 것이 좋을 수 있습니다. 기존에 설정된 데이터베이스 관리 시스템이 있고 효과적인 개발, 운영, 유지보수 프로세스가 있는 기업의 경우에는 변경을 방지하는 것이 가장 좋을 수 있습니다.

클라우드에서 데이터베이스 시스템이 필요하지 않은 클라우드 버스팅 사용 사례는 데이터베이스 변경이 필요하지 않을 수 있습니다. 또 다른 사용 사례는 동일한 클라우드 내의 다른 배포 위치 또는 또 다른 클라우드로의 비동기 복제입니다. 이러한 사용 사례의 경우에는 데이터베이스에 액세스할 때 벤치마크를 구현하고 교차 위치 통신과 지연 시간이 애플리케이션 요구사항을 충족시키는지 확인하는 것이 좋습니다.

Kubernetes 서비스로 사용되는 데이터베이스 시스템

기업이 StatefulSets를 기준으로 Kubernetes 내에서 데이터베이스 시스템을 서비스로 실행하길 원하는 경우 다음 요소를 고려해야 합니다.

• 데이터베이스가 애플리케이션에 필요한 데이터베이스 모델을 제공하는 경우
• Kubernetes 서비스와 같은 데이터베이스 시스템에서 운영화가 구현되는 방법을 결정하는 비기능적 요소(예: 확장 수행 방법(수직 확장 및 축소), 백업 및 복원 관리 방법, 시스템에서 모니터링이 제공되는 방법). Kubernetes 기반 데이터베이스 시스템의 요구사항 이해를 돕기 위해 기업은 데이터베이스 사용 경험을 비교 기준으로 사용해야 합니다.
• 고가용성 및 재해 복구. 고가용성을 제공하기 위해서는 리전 내 영역이 실패할 때 시스템이 계속 작동되어야 합니다. 데이터베이스를 한 영역에서 다른 영역으로 빠르게 장애 조치할 수 있어야 합니다. 최적 사례 시나리오에서 데이터베이스는 제로 RTO 및 RPO를 위해 완전히 동기화된 각 영역에서 실행되는 인스턴스를 포함합니다.
• 리전(또는 클라우드) 장애를 해결하기 위한 재해 복구. 이상적인 시나리오의 경우 데이터베이스는 제로 RPO 및 RTO로 보조 리전에서 계속 작동합니다. 덜 이상적인 시나리오에서는 보조 리전의 데이터베이스가 기본 데이터베이스의 모든 트랜잭션을 완전히 따라잡지 못할 수 있습니다.

Kubernetes 내에서 데이터베이스를 실행하는 최적 방법을 결정하기 위해서는 특히 시스템을 Kubernetes 외부의 프로덕션 시스템과 비교해야 할 경우, 전체 데이터베이스 평가가 좋은 접근 방법입니다.

Kubernetes 독립 데이터베이스 시스템

Kubernetes에서 서비스로 구현된 애플리케이션의 경우 Kubernetes에서 데이터베이스가 항상 동시에 실행될 필요는 없습니다. 기존에 설정된 프로세스, 기업 내 제품 지식, 비가용성 등 Kubernetes 외부에서 데이터베이스 시스템을 실행해야 할 이유는 다양합니다. 클라우드 제공업체 및 클라우드 파트너 관리형 데이터베이스 모두 이 카테고리에 적합합니다.

Compute Engine에서 데이터베이스를 실행하는 것도 마찬가지로 가능합니다. 데이터베이스 시스템을 선택할 때는 애플리케이션의 모든 요구사항이 충족되는지 확인하기 위해 전체 데이터베이스 평가를 수행하는 것이 좋은 방법입니다.

애플리케이션 설계 관점에서 연결 풀링은 중요한 설계 고려사항입니다. 데이터베이스에 액세스하는 애플리케이션 서비스는 연결 풀을 내부적으로 사용할 수 있습니다. 연결 풀 사용은 효율성 증가 및 지연 시간 감소에 좋습니다. 초기화를 수행할 필요 없이 대신 풀에서 요청을 수행하고 연결이 생성될 때까지 기다릴 필요도 없습니다. 애플리케이션 서비스 인스턴스를 추가하여 애플리케이션이 수직 확장될 경우 각 인스턴스가 연결 풀을 만듭니다. 권장사항을 따르면 각 풀이 최소 연결 집합을 미리 만듭니다. 애플리케이션 확장을 위해 다른 애플리케이션 서비스 인스턴스가 생성될 때마다 데이터베이스에 연결이 추가됩니다. 설계 관점에서는 데이터베이스가 무제한 연결을 지원할 수 없기 때문에 오버로드를 방지하도록 연결 추가를 관리해야 합니다.

최적 데이터베이스 시스템과 데이터베이스 시스템 이동성 비교

데이터베이스 시스템을 선택할 때는 기업이 애플리케이션의 요구사항을 해결하기에 가장 적합한 데이터베이스 시스템을 선택하는 것이 일반적입니다. 멀티 클라우드 환경에서는 각 클라우드에서 최적 데이터베이스를 선택할 수 있고, 이를 사용 사례에 따라 서로 연결할 수 있습니다. 이러한 시스템이 서로 다르면 단방향이나 양방향 모두 복제에 상당한 노력이 필요합니다. 최적 시스템을 사용하는 이점이 이를 구현하는 데 필요한 노력보다 더 큰 경우에는 이러한 접근 방식도 타당할 수 있습니다.

하지만 좋은 방법은 모든 필요한 클라우드에서 제공되는 데이터베이스 시스템에 대해 접근 방법을 고려하고 동시에 평가하는 것입니다. 이러한 데이터베이스는 최적 옵션처럼 이상적이지 않을 수 있지만 이러한 시스템을 구현, 운영, 유지보수하는 것이 훨씬 쉬울 수 있습니다.

동시 데이터베이스 시스템 평가는 두 데이터베이스 시스템 모두의 장점과 단점을 표시하고 선택을 위한 확실한 기초를 제공합니다.

기본 제공 및 외부 데이터베이스 시스템 복제 비교

모든 배포 위치(영역, 리전, 클라우드)에서 데이터베이스 시스템을 필요로 하는 사용 사례의 경우 복제가 중요한 기능입니다. 복제는 비동기, 양방향, 완전 동기 활성-활성 복제일 수 있습니다. 데이터베이스 시스템은 이 모든 복제 형식을 지원하지 않습니다.

시스템 구현 복제의 일부로 복제를 지원하지 않는 시스템의 경우 Striim과 같은 시스템을 사용하여 아키텍처를 보완할 수 있습니다 (데이터베이스 마이그레이션 참고).

최적의 방법은 대체 데이터베이스 관리 시스템을 평가하여 복제가 기본 제공되는 시스템 또는 복제 기술이 필요한 시스템의 장점 및 단점을 확인하는 것입니다.

이 경우에는 타사 클래스 기술도 필요한 역할을 담당합니다. 이 클래스는 복제를 제공하기 위해 기존 데이터베이스 시스템에 부가기능을 제공합니다. 한 가지 예시는 MariaDB Galera Cluster입니다. 평가 프로세스에서 허용될 경우 이러한 시스템을 평가하는 것이 좋은 방법입니다.

다음 단계

• 하이브리드 및 멀티 클라우드 패턴과 권장사항 알아보기
• 다른 클라우드 서비스와 Google Cloud의 연결 패턴 읽어보기
• Google Cloud에서 하이브리드 및 멀티 클라우드 배포를 위한 모니터링 및 로깅 아키텍처 알아보기
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.

참여자

저자: 알렉스 카시우 | 솔루션 설계자