Striim을 사용하여 데이터베이스 마이그레이션 및 복제 설계

이 문서에서는 Striim을 사용하여 데이터베이스 마이그레이션 및 복제를 설계합니다. 이 문서에서는 데이터베이스 마이그레이션 및 지속적 복제와 관련된 아키텍처 개념을 중점적으로 설명합니다. 데이터베이스 설계자 및 데이터베이스 엔지니어는 물론 데이터 소스를 Google Cloud로 마이그레이션하거나 복제하는 데이터 소유자를 위한 것입니다.

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

많은 기업이 클라우드 기반 서비스와 기술을 사용하여 비즈니스 애플리케이션을 구축하여 클라우드 우선 애플리케이션 전략을 세웁니다. 기업은 서비스에 대한 TTM(time to market)을 단축하고 고객 수요 및 시장 상황의 변화에 신속하게 대응합니다. 클라우드 기반 컴퓨팅을 엔드 투 엔드로 최대한 활용하는 비즈니스 애플리케이션은 장기적인 비즈니스 성장에 매우 중요합니다.

기존의 중요 작업용 애플리케이션은 클라우드 마이그레이션에 대한 몇 가지 문제를 제기합니다. 애플리케이션 계층 마이그레이션, 기본 데이터베이스 마이그레이션, 마이그레이션 중에 중단 없는 애플리케이션 액세스 유지 등의 문제입니다.

다양한 마이그레이션 제품 및 서비스가 비즈니스 애플리케이션 계층을 마이그레이션하는 데 도움이 될 수 있지만 비즈니스 애플리케이션을 제공하는 기본 데이터베이스를 마이그레이션하는 것이 가장 어려운 경우가 많습니다.

실제로 클라우드로의 데이터베이스 마이그레이션은 몇 가지 형태를 취할 수 있습니다. 다음 다이어그램은 가장 기본적인 사용 사례를 보여줍니다. 온프레미스 데이터베이스가 클라우드 기반 데이터베이스(이 경우 Cloud Spanner)로 마이그레이션됩니다.

소스에서 Cloud Spanner로 기본 마이그레이션 아키텍처

다음 다이어그램은 애플리케이션 현대화와 함께 여러 데이터베이스를 이동하는 더 복잡한 사용 사례를 보여줍니다.

데이터베이스 마이그레이션 시스템을 사용하여 여러 소스 및 대상 데이터베이스와 관련된 복잡한 마이그레이션의 아키텍처

이 설정에서 두 개의 소스 데이터베이스가 두 개의 대상 데이터베이스로 마이그레이션됩니다. 소스 데이터베이스 중 하나는 Google Kubernetes Engine에서 구현된 현대화된 형식으로 해당 대상 데이터베이스에 액세스하는 애플리케이션에서 액세스합니다. 두 번째 소스 데이터베이스에도 클라이언트가 있습니다(다이어그램에 표시되지 않음).

데이터베이스 마이그레이션 시스템은 Google Cloud에 설치되어 있지만 다른 곳에 마이그레이션 시스템을 설치할 수 있습니다. 예를 들어 마이그레이션 시스템은 보안 상의 이유로 소스 데이터베이스와 동일한 위치에서 실행되어야 할 수 있습니다.

리프트 앤 시프트 및 온라인 데이터베이스 마이그레이션

개략적으로 데이터베이스 마이그레이션의 두 가지 접근 방식은 리프트 앤 시프트 마이그레이션과 온라인 마이그레이션입니다.

리프트 앤 시프트 마이그레이션에서는 일반적으로 소스 데이터베이스를 내보내거나 백업하고 내보낸 파일 또는 백업 파일을 클라우드로 이동한 다음 파일을 가져와서 클라우드에서 실행 중인 대상 데이터베이스 인스턴스로 복원합니다. 새 대상 데이터베이스가 준비되면 비즈니스 애플리케이션이 클라우드에서 실행되고 데이터에 액세스합니다.

리프트 앤 시프트 방식의 단점은 비즈니스 애플리케이션과 데이터베이스 모두에 다운타임이 필요하다는 것입니다. 이 방법을 사용하려면 활동이 적은 기간 동안 마이그레이션을 신중하게 계획해야 합니다. 또한 이 방법은 마이그레이션 중에 비즈니스 애플리케이션을 중지하고 데이터베이스가 클라우드에 복원된 후 다시 시작할 수 있다고 가정합니다. 데이터베이스가 복원된 후 애플리케이션의 모든 테스트가 다운타임에 추가됩니다. 또한 리프트 앤 시프트 방식은 보호, 이동, 저장하고 최종적으로 삭제해야 하는 데이터베이스의 중간 사본을 만듭니다. 이 측면에서는 비용과 관리가 복잡해집니다. 리프트 앤 시프트 접근 방식은 특정 애플리케이션에서 작동할 수 있지만 대부분의 비즈니스에 중요한 애플리케이션의 요구사항은 이러한 비용을 반영하지 않습니다. 따라서 온라인 데이터베이스 마이그레이션이 훨씬 더 좋은 방법입니다.

온라인 마이그레이션 방법은 데이터베이스 성능과 비즈니스 애플리케이션 사용자에게 최소한의 영향을 미칩니다. 온라인 접근 방식을 사용하면 데이터베이스를 클라우드로 지속적으로 마이그레이션하여 소스 및 대상 데이터베이스 모두 몇 달 또는 몇 년 동안 완전히 동기화하면서 새로운 클라우드 기반 데이터베이스의 비즈니스 애플리케이션을 최적화하고 테스트할 수 있습니다.

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

클라우드로의 데이터베이스 마이그레이션에서 마이그레이션이 완료되면 클라우드 데이터베이스가 이제 프로덕션 인스턴스이기 때문에 소스 데이터베이스가 사용 중지됩니다.

일부 사용 사례에서는 Google Cloud에서 다운스트림 처리가 발생되는 동안 원래 데이터베이스 인스턴스가 계속 실행될 수 있습니다. 이 경우 소스 데이터베이스가 Google Cloud에 복제됩니다. 예를 들어 Google Cloud로 이동할 수 없는 기술에 의존하는 데이터베이스에 액세스하는 애플리케이션이 있을 수 있습니다. 동시에 Google Cloud 기술은 분석과 같은 기능(예: BigQuery로 복제)에 사용됩니다. 또 다른 예시는 개인 식별 정보(PII)가 포함된 데이터베이스가 온프레미스 환경에 있어야 하는 반면, 난독화된 PII 정보를 사용하는 다운스트림 처리가 Google Cloud에서 발생하는 경우입니다.

이러한 사용 사례에서는 원본 데이터베이스를 Spanner 또는 BigQuery와 같은 운영 또는 분석 대상에 지속적으로 복제해야 합니다. 소스 데이터베이스는 데이터베이스 마이그레이션과 마찬가지로 종료되지 않습니다.

이기종 데이터베이스의 온라인 데이터베이스 마이그레이션 및 복제는 일반적으로 복잡하며 수개월 또는 수년의 코딩 및 다양한 서비스 통합이 필요합니다. 온라인 데이터베이스 마이그레이션에 대한 보다 현대적이고 효율적인 접근 방식은 Striim과 같은 데이터베이스 마이그레이션 및 통합 시스템을 사용하는 것입니다.

다음 다이어그램은 하나의 소스와 하나의 대상 데이터베이스를 포함하는 Striim 데이터 통합 및 인텔리전스 플랫폼의 기본 배포 아키텍처를 보여줍니다.

Striim을 사용한 기본 마이그레이션 아키텍처

Striim을 사용한 데이터베이스 마이그레이션 및 복제

데이터베이스 마이그레이션 기술을 제공하는 Google 기술 파트너인 Striim은 드래그 앤 드롭 인터페이스를 사용하여 이기종 데이터베이스 간의 지속적인 데이터 이동을 설정하여 온라인 마이그레이션을 단순화합니다. 이러한 Google Cloud로의 마이그레이션을 위해 Striim은 다른 솔루션보다 더 빠르게 배포하고 쉽게 반복할 수 있는 비간섭 스트리밍 추출, 변환, 로드(ETL) 플랫폼을 제공합니다.

비간섭 변경 데이터 캡처(CDC)를 통해 Striim은 소스 트랜잭션 데이터베이스의 속도를 저하시키지 않으면서 실시간 데이터를 추출하므로 다운타임이 전혀 발생하지 않으며 위험이 최소화된 클라우드 데이터베이스 마이그레이션이 가능합니다. 데이터가 이동하는 동안 Striim은 포괄적인 스트리밍 분석 엔진을 사용하여 SQL 쿼리를 통해 데이터를 필터링, 변환, 집계, 보강할 수 있습니다.

온프레미스와 Google Cloud 데이터베이스 간에 데이터를 지속적으로 복제함으로써 Striim은 중요 작업용 애플리케이션이 다운타임 없이 계속 실행되는 온라인 복제를 지원합니다. 또한 기본 제공 지속적 배포 유효성 검사, 고가용성, 장애 조치 기능이 있다면 Striim은 데이터 손실 위험도 최소화합니다.

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

온라인 데이터베이스 마이그레이션 및 지속적 복제는 다양한 업계별 및 기술적(업계 중립적) 문제에 적용할 수 있습니다. 예를 들어 업계별 사용은 클라우드 데이터 서비스와 실시간 데이터를 활용하는 금융 서비스일 수 있습니다. 더 많은 기술 중심의 사용 사례는 보고 데이터베이스의 마이그레이션 또는 운영 데이터베이스의 단계별 마이그레이션일 수 있습니다. Striim을 사용하면 적시에 적절한 형식으로 데이터를 전달하는 지속적 데이터 파이프라인을 제공할 수 있습니다.

이 섹션에서는 Striim을 사용하여 업계별 사용 사례와 두 가지 기술적 사용 사례에서 데이터베이스를 마이그레이션하는 방법을 설명합니다.

금융 기술

금융 기술(fintech) 회사는 빠르고 정확한 데이터가 필요합니다. 예를 들어 은행 고객은 계좌에 게시된 거래 및 새 잔액을 즉시 확인하려고 합니다. 대출자와 대출 기관은 대출 처리 시간을 절약하려고 합니다. 핀테크 회사에서는 Striim을 사용하여 이와 같은 수많은 비즈니스 요구사항을 해결할 수 있습니다.

대출 처리 속도를 빠르게 하는 자동화된 직원 및 소득 확인 서비스를 고려합니다. 이 사용 사례에서 Striim은 다양한 온프레미스 소스의 실시간 데이터를 Google Cloud에 통합합니다. 이 자동화를 통해 고용 확인 절차의 지연을 줄일 수 있습니다. 다음 다이어그램은 이 사용 사례의 아키텍처를 보여줍니다.

Striim을 사용하여 Google Cloud로 데이터를 스트리밍하는 Fintech 사용 사례

이 아키텍처는 Striim의 실시간 스트리밍 데이터 통합을 활용합니다. Striim은 다양한 외부 및 내부 소스의 데이터(예: ADP와 같은 프로세서의 급여, 다른 제공업체의 직원 및 인구통계 데이터)를 지속적으로 수집합니다. 그런 다음 다양한 Google Cloud 서비스에 데이터를 피드합니다. Striim은 로그 기반 CDC를 사용하고, 해당되는 경우 Oracle® GoldenGate 추적 파일에 액세스하여 관계형 데이터베이스에서 데이터를 지속적으로 수집하며 플랫 파일에서도 데이터를 수집합니다. Striim은 집계 및 변환된 데이터를 Cloud Storage에 지속적으로 제공하여 클라우드용으로 구축된 비즈니스 애플리케이션과 서비스를 지원합니다.

오프로딩 보고

일부 기술적 사용 사례에서는 트랜잭션 워크로드와 분석 워크로드 간의 차이가 있습니다. 소스 트랜잭션 데이터베이스의 성능 향상 및 분석 쿼리 반환의 지연 시간 증가로 인해 트랜잭션 데이터베이스에서 분석 쿼리를 실행하는 것은 바람직하지 않습니다.

이러한 차이를 해결하기 위해 트랜잭션 데이터 하위 집합을 Google Cloud에 지속적으로 제공하여 BigQuery에서 추가 분석 및 보고를 실행할 수 있습니다. 다음 다이어그램은 아키텍처의 예시를 보여줍니다.

트랜잭션 데이터베이스와 분석 데이터베이스 간에 워크로드를 분할하는 아키텍처

스트리밍 데이터 파이프라인의 데이터를 변환하고 정규화하는 기능을 통해 Striim은 소스 트랜잭션 데이터의 선택된 하위 집합을 분석 플랫폼에 통합하고 나머지 데이터는 하나 이상의 Google Cloud 데이터 대상으로 계속 이동할 수 있습니다.

단계별 마이그레이션

대기업은 수년 간의 소중한 데이터를 보유한 대규모 온프레미스 데이터베이스를 보유하고 있습니다. 이러한 데이터베이스를 클라우드로 마이그레이션하는 작업은 몇 년이 걸릴 수 있습니다. 기존 데이터베이스를 유지하려면 비용(예를 들어 BigQuery, Cloud Spanner, Pub/Sub와 같은 새로운 클라우드 데이터베이스 기술로 인한 기회를 손실)이 발생합니다.

기존 시스템 유지보수와 최신 클라우드 데이터베이스 기술 활용 사이의 균형을 찾으려면 단계별 접근 방식으로 Striim을 사용하여 데이터 하위집합을 Google Cloud 데이터베이스로 마이그레이션하고 소스 프로덕션 데이터베이스를 계속 실행할 수 있습니다. 또한 소규모 하위 집합으로 시작하여 개발자가 프로덕션 온프레미스 데이터베이스에 영향을 주지 않고 새 클라우드 데이터베이스에서 애플리케이션 계층을 테스트할 수 있습니다.

애플리케이션 계층이 호환되는지 확인한 후 전체 데이터베이스가 마이그레이션될 때까지 마이그레이션하는 하위 집합을 천천히 늘릴 수 있습니다. 이러한 단계별 마이그레이션을 통해 최소한의 다운타임으로 위험을 관리하고 프로덕션 시스템을 마이그레이션할 수 있습니다.

배포 아키텍처

이 섹션의 배포 아키텍처는 데이터베이스 마이그레이션 및 복제의 다양한 사용 사례와 관련된 다양한 데이터베이스, 애플리케이션, 클라우드 서비스를 보여줍니다.

기본 배포 아키텍처

다음 다이어그램은 간단한 배포 아키텍처를 보여줍니다. 소스 데이터베이스 시스템은 클라우드 기반 데이터베이스 시스템인 Cloud Spanner로 마이그레이션됩니다. 이 아키텍처는 이 문서 전체에서 사용되며 지속적 복제와 전체 또는 단계별 마이그레이션 모두에서 작동합니다.

Striim을 사용한 기본 마이그레이션 아키텍처

이 아키텍처에서 소스 데이터베이스 시스템은 클라우드 기반 데이터베이스 시스템(이 경우 Cloud Spanner)으로 마이그레이션됩니다. 데이터베이스 마이그레이션 시스템인 Striim은 두 시스템 모두에 연결되어 소스의 데이터를 대상 데이터베이스 시스템으로 마이그레이션합니다.

중간 정도의 복잡성 배포 아키텍처

다음 다이어그램은 소스 데이터베이스 시스템 두 개가 포함된 아키텍처를 보여줍니다. 이 아키텍처는 이전 아키텍처보다 더 복잡하며 데이터베이스 마이그레이션 및 데이터베이스 복제에 사용할 수 있습니다.

온프레미스 및 클라우드 소스 데이터베이스에서 트랜잭션 및 분석 대상 데이터베이스로 마이그레이션

이 다이어그램은 두 개의 소스 데이터베이스 시스템이 있는 초기 아키텍처를 보여줍니다. 하나의 소스는 마이그레이션해야 하는 퍼블릭 클라우드에서 실행되는 데이터베이스 시스템(S1)입니다. 두 번째 소스는 온프레미스에 남아 있는 온프레미스 데이터 센터에서 실행되는 데이터베이스 시스템(S2)으로 온프레미스 데이터와 후속 변경사항은 분석을 위해 BigQuery에 복제됩니다. 대상 데이터베이스 시스템 두 개가 배포됩니다. 하나는 S1(마이그레이션)에서 데이터를 수신하기 위한 Cloud Spanner이고 다른 하나는 S2에서 데이터를 지속적인 데이터 스트림을 수신하기 위한 BigQuery입니다.

다음 다이어그램은 데이터베이스 마이그레이션이 완료된 후의 배포 아키텍처를 나타냅니다. S1이 종료되고 해당 Cloud Spanner 대상은 더 이상 Striim에 연결되지 않습니다.

마이그레이션이 완료된 후 트랜잭션 데이터베이스가 Striim에서 연결 해제되는 아키텍처

이 시나리오에서는 배포 아키텍처가 반드시 정적인 것은 아니라는 것을 보여줍니다. 일회성 데이터베이스 마이그레이션과 같은 일부 사용 사례에서는 마이그레이션이 완료될 때까지 마이그레이션 시스템을 시스템 또는 서비스에 연결해야 합니다. 다른 사용 사례는 데이터베이스 복제의 경우와 마찬가지로 더 정적입니다. 이 아키텍처는 하나의 아키텍처가 여러 사용 사례를 처리하는 방법을 보여줍니다.

복잡한 배포 아키텍처

이 섹션에서는 대체로 설계된 마이그레이션을 설명합니다. 마이그레이션 후 오류가 발생하여 소스에 대한 처리로 되돌아가야 하는 경우 대체가 필요할 수 있습니다. 대체 설정은 마이그레이션이 역전되면 대상의 변경사항이 소스에 다시 전달되도록 합니다.

이 배포 아키텍처에는 복제 및 마이그레이션이 포함되며, 이 문서에서 설명하는 3가지 아키텍처 중 가장 복잡한 아키텍처입니다.

또한 이 아키텍처는 처리량 증가를 지원하기 위해 Striim이 클러스터링된 환경에서 작동하는 방법을 보여줍니다. 다음 아키텍처의 클러스터는 충분한 용량을 제공하기 위해 세 개의 Compute Engine 인스턴스로 구성됩니다. 각 Compute Engine 인스턴스는 영역 및 인스턴스 장애로부터 보호하기 위해 고가용성을 제공하는 다른 영역에 배치됩니다.

이 경우 온프레미스 데이터 센터에 있는 두 개의 소스 데이터베이스가 클라우드에 복제됩니다. 한 데이터베이스는 Cloud Spanner에 복제되고 다른 데이터베이스는 BigQuery에 복제됩니다. 또한 마이그레이션은 퍼블릭 클라우드의 데이터베이스에서 Cloud SQL 인스턴스로 데이터를 이동합니다.

다음 다이어그램은 마이그레이션이 완료되기 전에 배포 아키텍처를 보여줍니다.

Striim 마이그레이션 시스템을 사용한 여러 소스 및 대상 데이터베이스의 아키텍처

3개의 소스 데이터베이스가 Striim과 연결되어 있고, Striim이 데이터를 3개의 대상 데이터베이스로 마이그레이션하고 복제합니다. 온프레미스 데이터 센터의 두 소스 데이터베이스가 BigQuery 및 Cloud Spanner에 복제되고 클라우드의 소스 데이터베이스가 Cloud SQL로 마이그레이션됩니다.

마이그레이션이 완료되면 Cloud SQL에서 클라우드의 데이터베이스로 흐름이 역전되어 가능한 대체를 준비합니다. 대상의 변경사항을 소스에도 사용할 수 있도록 하려면 원래 마이그레이션 후에 역방향 마이그레이션을 설정해야 합니다.

다음 다이어그램은 잠재적 대체의 구성 변경사항을 보여줍니다.

Striim 마이그레이션 시스템을 사용한 소스 데이터베이스로의 대체 아키텍처입니다.

원래 소스 클라우드 데이터베이스와 Cloud SQL 간에 데이터 흐름 방향이 역전됩니다. 마이그레이션이 완료되고 대체가 필요하지 않으면 Cloud SQL과 온프레미스 데이터 센터의 소스 데이터베이스를 포함한 마이그레이션의 관련 시스템이 연결 해제됩니다.

다음 다이어그램은 이 배포 아키텍처가 지속적인 복제 사용 사례를 지원하는 방법을 보여줍니다.

Striim을 사용하여 두 개의 온프레미스 소스 데이터베이스에서 여러 대상으로 지속적으로 복제하는 아키텍처입니다.

온프레미스 데이터 센터의 두 소스 데이터베이스는 BigQuery 및 Cloud Spanner에 지속적으로 복제됩니다.

이 토론에서 알 수 있듯이 이 배포 아키텍처는 복잡성에 관계없이 다양한 사용 사례를 지원할 수 있습니다. 데이터 이동의 방향이 역전되는 경우와 같이 구성을 동적으로 변경할 수도 있습니다.

이 아키텍처는 증가된 부하 또는 급증을 지원하기 위해 확장할 수도 있습니다.

배포 아키텍처와 마이그레이션 사양의 복잡성

앞의 아키텍처에서 복잡성의 두 가지 측정기준은 다음과 같습니다.

  • Striim에 연결된 데이터베이스 시스템 수
  • 사용 사례가 완료되며 시간 경과에 따른 배포 아키텍처 변경

복잡성은 배포 아키텍처와 상관없이 마이그레이션 사양 자체의 상황에 따라 고려될 수 있습니다.

예를 들어 온프레미스 MySQL 데이터베이스가 클라우드의 MySQL 데이터베이스로 마이그레이션되고 스키마와 데이터가 동일한 경우 마이그레이션 사양은 복사본이므로 간단합니다. 하지만 Oracle 데이터베이스에서 Cloud Spanner 데이터베이스로 마이그레이션하는 경우 소스와 대상 스키마가 다르고 마이그레이션 중에 데이터를 변환해야 하므로 마이그레이션 복잡성이 크게 증가합니다.

다음 표에서는 마이그레이션 사양의 복잡성을 결정하는 방식을 간략히 소개합니다. 기능은 마이그레이션 또는 복제 복잡성 표시와 함께 나열됩니다. 사용 사례 열을 사용하여 요구사항을 평가할 수 있습니다.

기능 유사 다름 사용 사례
소스 및 대상 데이터베이스 시스템 낮은 복잡성 높은 복잡성
소스 및 대상 데이터베이스 스키마 낮은 복잡성 높은 복잡성
소스 및 대상 데이터베이스 데이터 낮은 복잡성 높은 복잡성
데이터 파티션 나누기(있는 경우) 낮은 복잡성 높은 복잡성
데이터 분리 또는 통합 높은 복잡성 높은 복잡성

마이그레이션 복잡성은 구현되는 사용 사례에 따라 달라집니다. 사용 사례의 경우 사용 사례 기능의 낮은 복잡성과 높은 복잡성의 비율에 따라 전반적인 복잡성을 결정할 수 있습니다.

다른 고려 사항은 특히 고급 사용 사례에서 복잡성을 결정하는 데 중요한 역할을 할 수 있습니다. 예:

  • 여러 소스 데이터베이스가 단일 대상 데이터베이스로 통합되나요?
  • 여러 소스 데이터베이스의 데이터가 다시 샤딩 또는 다시 파티션 나누기와 같은 대상 데이터베이스 집합으로 재배포되나요?
  • 대상 시스템에서 잘 선별된 데이터 세트를 제공하기 위해 마이그레이션 중에 데이터가 보강되거나 축소되나요?

사용 사례에 추가하는 각 기능은 복잡성을 증가시키며 Striim과 같은 시스템이 지원합니다.

다음 단계