데이터 파이프라인 마이그레이션
이 문서에서는 데이터 웨어하우스로 데이터를 로드하는 업스트림 데이터 파이프라인을 마이그레이션하는 방법을 설명합니다. 이 문서를 통해 데이터 파이프라인 정의, 파이프라인에 사용할 수 있는 절차 및 패턴, 데이터 웨어하우스 마이그레이션에 사용할 수 있는 마이그레이션 옵션 및 기술을 더 잘 이해할 수 있습니다.
데이터 파이프라인이란 무엇인가요?
컴퓨팅에서 데이터 파이프라인은 일련의 연결된 처리 단계를 통해 데이터를 처리하는 애플리케이션 유형입니다. 일반적인 개념으로 데이터 파이프라인은 예를 들어 정보 시스템 간 데이터 전송, 추출, 변환, 로드(ETL), 데이터 보강, 실시간 데이터 분석에 적용할 수 있습니다. 일반적으로 데이터 파이프라인은 실행 시 데이터를 실행하고 처리하는 일괄 프로세스 또는 파이프라인에 사용할 수 있게 되면 데이터를 지속적으로 실행하고 처리하는 스트리밍 프로세스로 운영됩니다.
데이터 웨어하우징과 관련하여 데이터 파이프라인은 일반적으로 트랜잭션 시스템에서 데이터를 읽고 변환을 적용한 다음 데이터 웨어하우스에 데이터를 쓰는 데 사용됩니다. 각 변환은 함수로 설명되며, 특정한 함수의 입력은 이전 함수의 출력입니다. 이러한 연결된 기능을 그래프라고 하며 이 그래프를 Directed Acyclic Graph(DAG)라고 합니다. 이 그래프는 (소스에서 대상으로의) 방향을 따르며, 비순환적입니다(함수의 입력이 DAG에서 다른 함수 다운스트림의 출력에 종속될 수 없음). 즉, 루프가 허용되지 않습니다. 그래프의 각 노드는 함수이며, 각 에지는 하나의 함수에서 다음 함수로 이동하는 데이터를 나타냅니다. 초기 함수는 소스이거나 소스 데이터 시스템에 대한 연결입니다. 최종 함수는 싱크 또는 대상 데이터 시스템에 대한 연결입니다.
데이터 파이프라인과 관련하여 소스는 일반적으로 트랜잭션 시스템(예: RDBMS)이며 싱크는 데이터 웨어하우스에 연결됩니다. 이러한 유형의 그래프를 데이터 흐름 DAG라고합니다. 또한 DAG를 사용하여 데이터 파이프라인과 다른 시스템 간의 데이터 이동을 조정할 수도 있습니다. 이러한 사용법을 조정 또는 제어 흐름 DAG라고 합니다.
데이터 파이프라인을 마이그레이션하는 경우
사용 사례를 BigQuery로 마이그레이션할 때 오프로드 또는 완전히 마이그레이션하도록 선택할 수 있습니다.
한편 사용 사례를 오프로드할 때 업스트림 데이터 파이프라인을 사전에 마이그레이션할 필요가 없습니다. 먼저 기존 데이터 웨어하우스에서 BigQuery로 사용 사례 스키마와 데이터를 마이그레이션합니다. 그런 다음 데이터를 동기화된 상태로 유지하기 위해 이전 데이터 웨어하우스에서 새로운 데이터 웨어하우스로의 증분 복사본을 설정합니다. 마지막으로 스크립트, 쿼리, 대시보드, 비즈니스 애플리케이션과 같은 다운스트림 프로세스를 마이그레이션하고 유효성을 검사합니다.
이 시점에 업스트림 데이터 파이프라인은 변경되지 않고 여전히 기존 데이터 웨어하우스에 데이터를 쓰고 있습니다. 오프로드된 사용 사례를 마이그레이션 백로그에 다시 포함하여 후속 반복에서 완전히 마이그레이션할 수 있습니다.
반면, 사용 사례를 완전히 마이그레이션하면 사용 사례에 필요한 업스트림 데이터 파이프라인이 Google Cloud로 마이그레이션됩니다. 전체 마이그레이션을 수행하려면 먼저 사용 사례를 오프로드해야 합니다. 전체 마이그레이션 후에는 데이터가 BigQuery로 직접 수집되므로 온프레미스 데이터 웨어하우스에서 해당 레거시 테이블을 지원 중단할 수 있습니다.
반복하는 동안 다음 옵션 중 하나를 선택할 수 있습니다.
- 사용 사례만 오프로드합니다.
- 이전에 오프로드된 사용 사례를 완전히 마이그레이션합니다.
- 사용 사례를 먼저 동일한 반복에서 오프로드하여 처음부터 완전히 마이그레이션합니다.
모든 사용 사례가 완전히 마이그레이션되면 기존 웨어하우스를 끄도록 선택할 수 있습니다. 이는 오버헤드와 비용을 줄이는 데 중요한 단계입니다.
데이터 파이프라인을 마이그레이션하는 방법
이 문서의 나머지 부분에서는 사용할 방식과 절차 및 사용할 기술을 포함하여 데이터 파이프라인을 마이그레이션하는 방법에 대해 설명합니다. 옵션은 기존 데이터 파이프라인을 용도 변경하여(BigQuery에 로드하도록 리디렉션하여) Google Cloud 관리형 서비스를 활용하기 위해 데이터 파이프라인을 다시 작성하는 것까지 다양합니다.
데이터 파이프라인의 절차 및 패턴
데이터 파이프라인을 사용하여 많은 절차와 패턴을 실행할 수 있습니다. 이 파이프라인은 데이터 웨어하우징에서 가장 일반적으로 사용됩니다. 일괄 데이터 파이프라인 또는 스트리밍 데이터 파이프라인이 있을 수 있습니다. 일괄 데이터 파이프라인은 일정 기간 동안(예: 하루에 한 번) 수집된 데이터에서 실행됩니다. 스트리밍 데이터 파이프라인은 운영체제에서 생성되는 실시간 이벤트(예: 온라인 트랜잭션 처리(OLTP) 데이터베이스에서 생성되는 CDC 행 변경)를 처리합니다.
추출, 변환, 로드(ETL)
데이터 웨어하우징과 관련하여 데이터 파이프라인은 종종 추출, 변환, 로드(ETL) 절차를 실행합니다. ETL 기술은 데이터 웨어하우스 외부에서 실행되므로 데이터 웨어하우스의 리소스는 데이터를 준비하고 변환하는 대신 동시 쿼리에 주로 사용할 수 있습니다. 데이터 웨어하우스 외부에서 실행되는 변환의 한 가지 단점은 변환을 표현하기 위해 추가 도구 및 언어(SQL 이외의 언어)를 학습해야 한다는 것입니다.
다음 다이어그램은 일반적인 ETL 절차를 보여줍니다.
그림 1. 일반적인 ETL 절차
일반적인 ETL 데이터 파이프라인은 하나 이상의 소스 시스템에서 데이터를 가져옵니다. 사용할 수 없는 시스템과 같은 문제로 인한 오류를 피하기 위해 가능한 한 적은 수의 시스템이 이상적입니다. 그런 다음 파이프라인은 데이터 정리, 비즈니스 규칙 적용, 데이터 무결성 검사, 집계 또는 분리를 포함하여 일련의 변환을 수행합니다. 자세한 정보는 실제 ETL주기를 참조하세요.
일반적으로 여러 개의 데이터 파이프라인이 있습니다. 첫 번째 파이프라인은 소스 시스템에서 데이터 웨어하우스로 데이터를 복사하는 데 중점을 둡니다. 후속 파이프라인은 비즈니스 로직을 적용하고 특정 비즈니스 단위 또는 비즈니스에 중점을 둔 데이터 웨어하우스의 하위 세트인 다양한 데이터 마트에서 사용하기 위해 데이터를 변환합니다.
여러 데이터 파이프라인이 있는 경우 이를 조정해야 합니다. 아래 다이어그램은 이러한 조정 프로세스를 보여줍니다.
그림 2. 여러 데이터 파이프라인의 조정 프로세스
다이어그램에서 각 데이터 파이프라인은 조정 DAG의 하위 DAG로 간주됩니다. 각 조정 DAG는 예를 들어 비즈니스 분석가가 대시보드 또는 보고서를 실행할 수 있도록 비즈니스 단위를 위한 데이터를 준비하는 것처럼 더 큰 목표에 맞게 여러 데이터 파이프라인을 포함합니다.
추출, 로드, 변환(ELT)
ELT는 ETL의 대안입니다. ELT를 사용하면 데이터 파이프라인이 두 부분으로 나뉩니다. 먼저 ELT 기술이 소스 시스템에서 데이터를 추출하여 데이터 웨어하우스에 로드합니다. 둘째, 데이터 웨어하우스 위에 있는 SQL 스크립트가 변환을 수행합니다. 이 방식의 장점은 SQL을 사용하여 변환을 표현할 수 있다는 것입니다. 단점은 동시 쿼리에 필요한 데이터 웨어하우스 리소스를 소비할 수 있다는 것입니다. 이러한 이유로 ELT 배치는 종종 데이터 웨어하우스의 시스템 리소스에 대한 수요가 적을 때 야간(또는 사용량이 많지 않은 시간)에 실행됩니다.
다음 다이어그램은 일반적인 ELT 절차를 보여줍니다.
그림 3. 일반적인 ELT 절차
ELT 방식을 채택할 때는 추출을 분리하여 하나의 DAG로, 변환을 자체 DAG로 분리하는 것이 일반적입니다. 데이터는 데이터 웨어하우스에 한 번 로드된 후 여러 번 변환되어 보고 등에서 다운 스트림에 사용되는 다른 테이블을 작성합니다. 이러한 DAG는 다시 더 큰 조정 DAG에서 하위 DAG가 됩니다(ETL 섹션에 표시됨).
혼잡한 온프레미스 데이터 웨어하우스에서 클라우드로 데이터 파이프라인을 마이그레이션할 때 BigQuery와 같은 클라우드 데이터 웨어하우스 시스템은 대규모 병렬 데이터 처리 기술이라는 점을 기억해야 합니다. 실제로 BigQuery의 경우 ELT에 대한 수요 증가와 동시 쿼리를 지원하기 위해 더 많은 리소스를 구입할 수 있습니다. 자세한 내용은 쿼리 성능 최적화 소개를 참조하세요.
추출 및 로드(EL)
추출 및 로드(EL) 절차를 그 자체로 사용하거나 이후에 변환을 수행할 수 있으며 이 경우 ELT가 됩니다. EL은 이 작업을 수행하는 여러 개의 자동화된 서비스를 사용할 수 있으므로 자체 수집 데이터 파이프라인을 만들 필요가 없기 때문에 별도로 설명합니다. 자세한 내용은 BigQuery Data Transfer Service를 참조하세요.
변경 데이터 캡처(CDC)
변경 데이터 캡처(CDC)는 데이터 변경사항을 추적하는 데 사용되는 여러 소프트웨어 디자인 패턴 중 하나입니다. 데이터 웨어하우스는 시간이 지남에 따라 다양한 소스 시스템의 데이터 및 변경사항을 수집하고 추적하는 데 사용되므로 데이터 웨어하우징에 자주 사용됩니다.
다음 다이어그램은 CDC가 ELT와 작동하는 방식의 예시를 보여줍니다.
그림 4. CDC가 ELT와 작동하는 방식.
다운스트림을 변경하기 전에 원본 레코드를 저장하려고 하므로 CDC는 ELT와 잘 작동합니다.
EL 부분을 발생시키기 위해 Datastream과 같은 CDC 소프트웨어 또는 Debezium과 같은 오픈소스 도구를 사용하고 Dataflow를 사용해서 레코드를 BigQuery에 작성하여 데이터베이스 로그를 처리할 수 있습니다. 그런 다음 추가 변환을 적용하기 전에 SQL 쿼리를 사용하여 최신 버전을 확인할 수 있습니다. 예를 들면 다음과 같습니다.
WITH ranked AS (
SELECT
*,
ROW_NUMBER() OVER (
PARTITION BY RECORD KEY
ORDER BY EVENT TIMESTAMP DESC
) AS rank
FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1
새 데이터 파이프라인을 리팩토링하거나 생성하려면 ELT 프로시저로 적용된 CDC 패턴 사용을 고려하세요. 이 방식을 사용하면 예를 들어 데이터 변경 업스트림의 전체 내역을 확보하고 책임을 효과적으로 분리할 수 있습니다.
- 소스 시스템 팀은 로그의 가용성 및 데이터 이벤트 공개를 보장합니다.
- 데이터 플랫폼 팀은 원본 레코드의 수집 대조에 데이터 웨어하우스의 타임스탬프가 포함되도록 합니다.
- 데이터 엔지니어링 및 분석 팀은 데이터 마트를 채우기 위해 일련의 변환을 예약합니다.
운영 데이터 파이프라인을 통한 피드백 루프
운영 데이터 파이프라인은 데이터 웨어하우스에서 데이터를 가져오고, 필요한 경우 데이터를 변환하며, 결과를 운영체제에 기록하는 데이터 처리 파이프라인입니다.
운영체제는 OLTP 데이터베이스, 고객 관계 관리(CRM) 시스템, 제품 카탈로그 관리(PCM) 시스템과 같은 조직의 일상적인 트랜잭션을 처리하는 시스템을 나타냅니다. 이러한 시스템은 종종 데이터 소스 역할을 하기 때문에 운영 데이터 파이프라인은 피드백 루프 패턴을 구현합니다.
아래 다이어그램은 운영 데이터 파이프라인 패턴을 보여줍니다.
그림 5. 운영 데이터 파이프라인의 패턴
다음 예시는 제품 가격을 PCM 시스템에 쓰는 운영 데이터 파이프라인을 설명합니다. PCM 시스템은 색상, 판매 경로, 가격, 계절성과 같은 판매 관련 제품 정보에 대한 권한이 있는 시스템입니다. 데이터의 엔드 투 엔드 흐름은 다음과 같습니다.
- 가격 관련 데이터는 여러 소스에서 제공됩니다. 이 데이터에는 PCM의 리전별 현재 가격, 타사 서비스의 경쟁사 가격, 수요 예측 및 내부 시스템의 공급업체 안정성 등이 포함될 수 있습니다.
- ETL 파이프라인은 소스에서 데이터를 가져와서 변환한 후 결과를 데이터 웨어하우스에 씁니다. 이 경우 변환은 PCM의 각 제품에 대해 최적의 기본 가격을 생성한다는 목표로 모든 소스를 포함하는 복잡한 계산입니다.
- 마지막으로 운영 파이프라인은 데이터 웨어하우스에서 기본 가격을 가져와서 계절별 이벤트 가격을 조정하기 위해 간단한 변환을 수행하고 최종 가격을 다시 PCM에 씁니다.
그림 6. 제품 가격을 PCM 시스템에 쓰는 운영 데이터 파이프라인
운영 데이터 파이프라인은 다운스트림 프로세스의 유형인 반면, ETL, ELT 또는 CDC를 구현하는 데이터 파이프라인은 업스트림 프로세스입니다. 그렇지만 두 가지를 구현하는 데 사용되는 도구가 중복될 수 있습니다. 예를 들면 Dataflow를 사용하여 모든 데이터 처리 DAG를 정의하고 실행하고, GoogleSQL을 사용하여 BigQuery 내에서 실행되는 변환을 정의하고, Cloud Composer를 사용하여 데이터의 엔드 투 엔드 흐름을 조정할 수 있습니다.
마이그레이션 방식 선택
이 섹션에서는 데이터 파이프라인을 마이그레이션하기 위해 채택할 수 있는 다양한 방식에 대해 설명합니다.
데이터 파이프라인을 BigQuery에 쓰도록 리디렉션
다음 조건에서 사용하는 기술이 기본 제공 BigQuery 싱크(쓰기 커넥터)를 제공하는지 여부를 고려할 수 있습니다.
- 기존 데이터 웨어하우스가 ETL 절차를 실행하는 데이터 파이프라인에 의해 공급됩니다.
- 데이터가 데이터 웨어하우스에 저장되기 전에 변환 로직이 실행됩니다.
독립 소프트웨어 공급업체(ISV)가 다음을 포함한 BigQuery 커넥터를 사용하여 데이터 처리 기술을 제공합니다.
- Informatica: BigQuery connector guide
- Talend: Writing data in BigQuery
데이터 파이프라인 기술이 BigQuery에 대한 데이터 수집을 지원하지 않는 경우, 나중에 BigQuery에서 수집한 파일에 데이터를 임시로 쓰는 이 방법의 변형을 사용하는 것이 좋습니다.
그림 7. BigQuery에 데이터를 쓰는 데이터 파이프라인의 마지막 기능을 다시 작성하거나 재구성합니다.
개략적으로, 관련된 작업은 BigQuery에 데이터를 쓰는 데이터 파이프라인의 마지막 기능인 다시 쓰기 또는 재구성과 관련이 있습니다. 하지만 추가 변경 또는 새로운 작업이 필요할 수 있는 여러 가지 옵션이 있습니다. 예를 들면 다음과 같습니다.
기능
- 데이터 매핑: 대상 데이터베이스 테이블 스키마가 변경될 수 있으므로 이러한 매핑을 재구성해야 할 수도 있습니다.
- 측정항목 유효성 검사: 스키마와 쿼리가 모두 변경될 수 있으므로 기록 보고서와 새 보고서에 대하여 유효성 검사를 모두 수행해야 합니다.
비기능
- 온프레미스에서 BigQuery로 아웃바운드 데이터 전송을 허용하도록 방화벽을 구성해야 할 수 있습니다.
- 아웃바운드 데이터 전송을 수용하려면 추가 대역폭을 만들기 위해 네트워크 변경이 필요할 수 있습니다.
파일을 중간 수단으로 사용하여 데이터 파이프라인 리디렉션
기존 온프레미스 데이터 파이프라인 기술이 Google API를 지원하지 않거나 사용자가 Google API 사용이 제한된 경우 파일을 BigQuery에 도달하기 위한 중간 수단으로 사용할 수 있습니다.
이 방법은 리디렉션 방법과 유사하지만 BigQuery에 쓸 수 있는 네이티브 싱크를 사용하는 대신 온프레미스 파일 시스템에 쓸 수 있는 싱크를 사용합니다. 데이터가 파일 시스템에 있으면 파일을 Cloud Storage에 복사합니다. 자세한 내용은 Cloud Storage의 수집 옵션 개요 및 수집 옵션 선택과 관련된 기준을 참조하세요.
마지막 단계는 데이터 일괄 로드의 안내에 따라 Cloud Storage에서 BigQuery로 데이터를 로드하는 것입니다.
다음 다이어그램은 이 섹션에 요약된 방식을 보여줍니다.
그림 8. 파일을 중간 수단으로 사용하여 데이터 파이프라인 리디렉션
ETL 파이프라인 조정과 관련하여 두 가지 단계를 별도로 수행해야 합니다.
- 기존 온프레미스 파이프라인 조정을 재사용하여 변환된 데이터를 파일 시스템에 씁니다. 이 조정을 확장하여 온프레미스 파일 시스템에서 Cloud Storage로 파일을 복사하거나, 정기적으로 실행하여 복사 단계를 수행하는 추가 스크립트를 작성합니다.
- 데이터가 Cloud Storage에 있는 경우 Cloud Storage 전송을 사용하여 Cloud Storage에서 BigQuery로 반복되는 로드를 예약합니다. Cloud Storage 전송 대신 Cloud Storage 트리거와 Cloud Composer를 사용할 수 있습니다.
그림 8에서 GCP의 조정이 SFTP와 같은 프로토콜을 사용하여 파일을 검색하는 방법으로 가져오기 모델을 사용할 수 있음을 참조하세요.
기존 ELT 파이프라인을 BigQuery로 마이그레이션
ELT 파이프라인은 두 가지 부분으로 구성됩니다. 즉 데이터를 데이터 웨어하우스에 로드하는 부분과 SQL을 사용하여 데이터를 다운스트림에서 소비할 수 있도록 변환하는 부분입니다. ELT 파이프라인을 마이그레이션할 때 이러한 각 부분에는 고유한 마이그레이션 방식이 있습니다.
데이터를 데이터 웨어하우스에 로드하는 부분(EL 부분)의 경우, EL 파이프라인에 속하지 않은 변환에 대한 조언을 제외하고 데이터 파이프라인 리디렉션 섹션의 가이드라인을 따를 수 있습니다.
데이터 소스가 BigQuery Data Transfer Service(DTS)에서 직접 또는 타사 통합을 통해 지원되는 경우 DTS를 사용하여 EL 파이프라인을 교체할 수 있습니다.
기존 OSS 데이터 파이프라인을 Dataproc으로 마이그레이션
데이터 파이프라인을 Google Cloud로 마이그레이션할 때 Apache Hadoop, Apache Spark, Apache Flink와 같은 오픈소스 소프트웨어 프레임워크로 작성된 일부 기존 작업을 마이그레이션할 수 있습니다.
Dataproc을 사용하면 간단하고 비용 효율적인 방법으로 빠르고 사용하기 쉬운 완전 관리형 Hadoop 및 Spark 클러스터를 배포할 수 있습니다. Dataproc은 Apache Hadoop InputFormat 및 OutputFormat 클래스의 추상화된 버전을 사용하여 Hadoop 및 Spark가 BigQuery에서 직접 데이터를 처리할 수 있게 해주는 Java 라이브러리인 BigQuery 커넥터와 통합됩니다.
Dataproc을 사용하면 하나의 모놀리식 클러스터를 사용하는 대신 여러 개의 임시 클러스터를 사용할 수 있도록 클러스터를 쉽게 생성하고 삭제할 수 있습니다. 이 방식의 장점은 다음과 같습니다.
- 개별 작업마다 다른 클러스터 구성을 사용할 수 있으므로 작업이 바뀔 때마다 도구를 직접 관리할 필요가 없습니다.
- 개별 작업 또는 작업 그룹에 맞게 클러스터 규모를 조정할 수 있습니다.
- 작업에서 리소스를 사용할 때만 비용을 지불합니다.
- 클러스터가 사용될 때마다 새로 구성되므로 클러스터를 장시간 유지보수할 필요가 없습니다.
- 개발, 테스트, 프로덕션용 인프라를 별도로 관리할 필요가 없습니다. 필요에 따라 동일한 정의를 사용하여 서로 다른 여러 클러스터 버전을 필요한 만큼 얼마든지 만들 수 있습니다.
작업을 마이그레이션할 때는 점진적인 방식을 사용하는 것이 좋습니다. 점진적으로 마이그레이션하면 다음을 수행할 수 있습니다.
- 성숙한 환경에 내재된 복잡성으로부터 기존 Hadoop 인프라의 개별 작업을 분리할 수 있습니다.
- 분리된 각 작업을 조사하여 요구사항을 평가하고 최선의 마이그레이션 경로를 판단할 수 있습니다.
- 예기치 않은 문제가 발생해도 독립된 작업을 지연시키지 않으면서 대응할 수 있습니다.
- 프로덕션 환경에 영향을 주지 않으면서 복잡한 각 프로세스에 대한 개념 증명을 진행할 수 있습니다.
- 작업을 권장되는 임시 모델로 신중하고 주의 깊게 이동할 수 있습니다.
기존 Hadoop 및 Spark 작업을 Dataproc으로 마이그레이션할 때 작업의 종속 항목이 지원되는 Dataproc 버전에 포함되는지 확인할 수 있습니다. 커스텀 소프트웨어를 설치해야 할 경우 사용자 고유의 Dataproc 이미지를 만들거나, 사용 가능한 초기화 작업(예: Apache Flink)의 일부를 사용하거나, 사용자 고유의 초기화 작업을 작성하거나, 커스텀 Python 패키지 요구사항을 지정할 수 있습니다.
시작하려면 Dataproc 빠른 시작 가이드 및 BigQuery 커넥터 코드 샘플을 참조하세요. 온프레미스에서 Dataproc으로 Hadoop 작업 마이그레이션 및 Apache Spark 작업을 Dataproc로 마이그레이션에 대한 가이드도 참조하세요.
타사 데이터 파이프라인을 호스팅하여 Google Cloud에서 실행
온프레미스 데이터 파이프라인을 구축할 때 일반적인 시나리오는 타사 소프트웨어를 사용하여 파이프라인 실행 및 컴퓨팅 리소스 할당을 관리하는 것입니다.
이러한 파이프라인을 클라우드로 이동하려면 사용 중인 소프트웨어의 기능과 라이센스, 지원, 유지보수 조건에 따라 여러 가지 대안이 있습니다.
다음 섹션에는 이러한 대안 중 몇 가지가 나와 있습니다.
개략적으로 Google Cloud에서 타사 소프트웨어를 가장 단순한 것부터 가장 복잡한 것까지 실행하기 위한 대안은 다음과 같습니다.
- 소프트웨어 공급업체가 Google Cloud와 제휴하여 Google Cloud Marketplace에서 소프트웨어를 제공합니다.
- 타사 소프트웨어 공급업체는 Kubernetes에서 실행할 수 있습니다.
- 타사 소프트웨어는 하나 이상의 가상 머신(VM)에서 실행됩니다.
타사 소프트웨어가 Cloud Marketplace 솔루션을 제공하는 경우 관련된 작업은 다음과 같습니다.
- Cloud Marketplace 콘솔에서 타사 소프트웨어를 배포합니다.
- 반복적인 접근법을 사용한 마이그레이션에 설명된 반복적 방식에 따라 사용 사례를 선택하고 마이그레이션합니다.
공급업체가 제공하는 친숙한 플랫폼을 사용하여 데이터 파이프라인을 클라우드로 온보딩하기 때문에 이러한 대안이 가장 간단합니다. 공급업체의 독점적인 도구를 사용하여 원래 환경과 Google Cloud의 새 환경 간에 쉽게 마이그레이션할 수 있습니다.
공급업체가 Cloud Marketplace 솔루션을 제공하지 않지만 해당 제품이 Kubernetes를 기반으로 실행할 수 있으면 Google Kubernetes Engine(GKE)을 사용하여 파이프라인을 호스팅할 수 있습니다. 다음과 같은 작업이 관련됩니다.
- 공급업체의 권장사항에 따라 타사 제품이 Kubernetes가 제공하는 작업 병렬화를 활용할 수 있도록 GKE 클러스터를 생성합니다.
- 공급업체 권장사항에 따라 GKE 클러스터에 타사 소프트웨어를 설치합니다.
- BigQuery로 데이터 웨어하우스 마이그레이션: 개요에 설명된 반복적 방식에 따라 사용 사례를 선택하고 마이그레이션합니다.
이 대안은 복잡성 측면에서 중간 수준에 해당합니다. Kubernetes에 대한 공급업체의 기본 지원을 활용하여 파이프라인 실행을 확장하고 병렬화합니다. 하지만 GKE 클러스터를 생성하고 관리해야 합니다.
공급업체가 Kubernetes를 지원하지 않는 경우 작업을 확장하고 병렬화할 수 있도록 VM 풀에 소프트웨어를 설치해야 합니다. 공급업체 소프트웨어가 기본적으로 여러 VM에 대한 작업 분배를 지원하는 경우, 제공된 기능을 사용하여 VM 인스턴스를 관리 인스턴스 그룹(MIG)으로 그룹화하여 필요에 따라 확장 및 축소할 수 있습니다.
작업의 병렬화를 처리하기는 쉽지 않습니다. 공급업체가 다른 VM에 작업을 배포하는 기능을 제공하지 않으면 작업 팜 패턴을 사용하여 MIG의 VM에 작업을 배포하는 것이 좋습니다. 다음 다이어그램은 이러한 방식을 보여줍니다.
그림 9. 3대의 VM이 있는 관리형 인스턴스 그룹(MIG)
이 다이어그램에서 MIG의 각 VM은 타사 파이프라인 소프트웨어를 실행합니다. 여러 가지 방법으로 파이프라인 실행을 트리거할 수 있습니다.
- 자동: 새 데이터가 Cloud Storage 버킷에 도착하면 Cloud Scheduler, Cloud Composer 또는 Cloud Storage 트리거를 사용하는 방법
- 프로그래매틱 방식: Cloud Endpoint 또는 Cloud 함수를 호출하거나, Pub/Sub API를 사용하는 방법
- 수동: Google Cloud CLI를 사용하여 Pub/Sub 주제에 새 메시지를 배치하는 방법
본질적으로 이러한 모든 메서드는 사전 정의된 Pub/Sub 주제로 메시지를 보냅니다. 각 VM에 설치할 간단한 에이전트를 만듭니다. 에이전트는 하나 이상의 Pub/Sub 주제를 수신 대기합니다. 주제에 메시지가 도착할 때마다 에이전트는 주제에서 메시지를 가져와서 타사 소프트웨어에서 파이프라인을 시작하고 완료를 수신 대기합니다. 파이프라인이 완료되면 에이전트는 수신 중인 주제에서 다음 메시지를 검색합니다.
모든 시나리오에서 공급업체와 협력하여 파이프라인이 Google Cloud에서 작동하기 위한 적절한 라이선스 조건을 준수하는 것이 좋습니다.
Google Cloud 관리형 서비스를 사용하기 위해 데이터 파이프라인을 다시 작성
경우에 따라 기존 데이터 파이프라인 중 일부를 다시 작성하여 Google Cloud에서 완전 관리형 새로운 프레임워크 및 서비스를 사용할 수도 있습니다. 이 옵션은 기존 파이프라인이 원래 더 이상 사용되지 않는 기술로 구현되었거나 클라우드에서 파이프라인을 수정하지 않고 유지 관리하는 것이 너무 비현실적이거나 비용이 많이 드는 것으로 예상되는 경우에 효과적입니다.
다음 섹션에서는 데이터 변환을 대규모로 수행할 수 있는 완전 관리형 Google Cloud 서비스인 Cloud Data Fusion 및 Dataflow를 설명합니다.
Cloud Data Fusion
오픈소스 CDAP 프로젝트를 기반으로 하는 Cloud Data Fusion은 그래픽 인터페이스를 통해 데이터 파이프라인을 구축 및 관리하기 위한 완전 관리형 데이터 통합 서비스입니다.
소스를 변환, 싱크, 기타 노드에 연결하여 DAG를 형성함으로써 Cloud Data Fusion UI에서 데이터 파이프라인을 개발합니다. 데이터 파이프라인을 배포하면 Cloud Data Fusion 플래너가 이 DAG를 Dataproc에서 Apache Spark 작업으로 실행되는 일련의 병렬 계산으로 변환합니다.
Cloud Data Fusion을 사용하면 코드를 작성할 필요 없이 Java Database Connectivity(JDBC) 드라이버를 사용하여 데이터를 읽고 변환한 후 원하는 대상(예: BigQuery)에 로드하는 방법으로 소스 시스템의 데이터베이스에 연결할 수 있습니다. 이렇게 하려면 JDBC 드라이버를 Cloud Data Fusion 인스턴스에 업로드하고 데이터 파이프라인에서 사용할 수 있도록 구성해야 합니다. 자세한 내용은 Cloud Data Fusion에서 JDBC 드라이버 사용에 대한 가이드를 참조하세요.
Cloud Data Fusion은 소스, 변환, 집계, 싱크, 오류 수집자, 알림 게시자, 작업, 실행 후 작업을 맞춤설정 가능한 플러그인으로 표현합니다. 사전 빌드된 플러그인은 광범위한 데이터 소스에 대한 액세스를 제공합니다. 플러그인이 존재하지 않으면 Cloud Data Fusion 플러그인 API를 사용하여 고유한 플러그인을 빌드할 수 있습니다. 자세한 내용은 플러그인 개요를 참조하세요.
Cloud Data Fusion 파이프라인을 사용하면 일괄 및 스트리밍 데이터 파이프라인을 모두 만들 수 있습니다. 데이터 파이프라인은 로그 및 측정항목에 대한 액세스를 제공함으로써 관리자가 커스텀 도구 없이 데이터 처리 워크플로를 운영하기 위한 방법을 제공합니다.
시작하려면 Cloud Data Fusion 개념 개요를 참조하세요. 실제 예시는 빠른 시작 가이드와 캠페인 파이프라인 타겟팅 생성에 대한 가이드를 참조하세요.
Dataflow
Dataflow는 Apache Beam 작업을 대규모로 실행하기 위한 완전 관리형 서비스입니다. Apache Beam은 BigQuery용 커넥터를 포함하여 소스 및 싱크 커넥터의 생태계는 물론 다양한 창과 세션 분석 기본 도구를 제공하는 오픈소스 프레임워크입니다. Apache Beam은 스트리밍(실시간) 모드와 일괄(기록) 모드에서 신뢰성과 표현 능력을 동일하게 지원하면서 데이터를 변환하고 강화할 수 있게 해줍니다.
Dataflow의 서버리스 방식은 성능, 확장성, 가용성, 보안, 규정 준수가 자동으로 처리되므로 운영 오버헤드가 사라집니다. 이를 통해 서버 클러스터를 관리하는 대신 프로그래밍에 집중할 수 있습니다.
Dataflow 작업은 명령줄 인터페이스, Java SDK, Python SDK를 통해 여러 방법으로 제출할 수 있습니다. 또한 모든 SDK와 실행기 간에 완벽한 상호 운용성을 제공하는 이동성 프레임워크를 개발하고 있습니다.
다른 프레임워크에서 Apache Beam 및 Dataflow로 데이터 쿼리 및 파이프라인을 마이그레이션하려면 Apache Beam 프로그래밍 모델 및 공식 Dataflow 문서를 참조하세요.
실제 예시는 Dataflow 빠른 시작 및 가이드를 참조하세요.
조정 및 일정 예약
간단히 말해서 조정은 여러 시스템의 자동화된 조정인 반면, 일정 예약은 조정 작업의 자동화된 트리거링을 의미합니다.
- 확대: 데이터 파이프라인 자체가 DAG(데이터 처리 DAG)로 설명되는 데이터 변환의 조정입니다.
- 축소: 데이터 파이프라인이 다른 데이터 파이프라인의 출력에 의존하는 경우 여러 파이프라인을 조정해야 합니다. 각 파이프라인은 더 큰 DAG의 하위 DAG(조정 DAG)를 구성합니다.
이러한 설정은 데이터 웨어하우징에서 일반적입니다. ETL 섹션의 그림 1은 설정 예시를 보여줍니다. 다음 섹션에서는 여러 데이터 파이프라인의 조정을 중점적으로 살펴봅니다.
종속 항목
종속 항목은 여러 데이터 파이프라인이 조정 DAG의 정점으로 병합되는 팬인(fan-in)이거나, 단일 데이터 파이프라인이 여러 개의 다른 데이터 파이프라인을 트리거하는 팬아웃(fan-out)이거나, 또는 아래 다이어그램처럼 둘 다일 수도 있습니다.
그림 10. 팬인 및 팬아웃 종속 항목이 함께 사용된 경우
차선책 환경에서 일부 종속 항목은 사용 가능한 리소스의 양이 제한되어 있기 때문에 발생한 결과입니다. 예를 들면 데이터 파이프라인이 실행되고 부차적인 결과로 공통 데이터가 생성됩니다. 다른 데이터 파이프라인은 재계산을 피하기 위해 단순히 이 공통 데이터에 의존하지만 데이터를 생성한 데이터 파이프라인과는 관련이 없습니다. 이 첫 번째 파이프라인에 기능적 문제 또는 비기능적 문제가 발생하면 아래 다이어그램과 같이 장애가 종속된 데이터 파이프라인으로 진행되어, 최선의 경우 종속 파이프라인이 기다려야 하거나 최악의 경우 종속 파이프라인이 아예 실행되지 않습니다.
그림 11. 데이터 파이프라인을 계단식으로 연결하지 않으면 종속 파이프라인이 실행되지 않습니다.
Google cloud에서 파이프라인 실행 및 조정을 최적화할 수 있는 다양한 컴퓨팅 리소스와 특수한 도구를 사용할 수 있습니다. 나머지 섹션에서는 이러한 리소스와 도구에 대해 설명합니다.
관련된 마이그레이션 작업
조정 요구를 단순화하는 것이 가장 좋습니다. 데이터 파이프라인 간의 종속 항목 수가 많으면 조정이 복잡해집니다. Google Cloud로 마이그레이션하면 조정 DAG를 검사하고 종속 항목을 식별하며 이러한 종속 항목을 최적화하는 방법을 결정할 수 있습니다.
다음과 같이 종속 항목을 점진적으로 최적화하는 것이 좋습니다.
- 첫 번째 반복에서는 조정을 Google Cloud로 그대로 이동합니다.
- 이후의 반복에서 종속 항목을 분석하고 가능한 경우 병렬화합니다.
- 마지막으로 일반적인 작업을 자체 DAG로 추출하여 조정을 재구성합니다.
다음 섹션에서는 실제 예시를 들어 이 방법을 설명합니다.
실제 예시
조직에 두 개의 관련된 파이프라인이 있다고 가정합니다.
- 첫 번째 파이프라인은 전체 조직의 손익(P&L)을 계산합니다. 많은 변환이 포함된 복잡한 파이프라인입니다. 파이프라인의 일부는 월간 판매량 계산으로 구성되며, 이는 후속 변환 단계에서 사용되며 결국 테이블에 기록됩니다.
- 두 번째 파이프라인은 마케팅 부서가 광고 캠페인 노력을 조정할 수 있도록 서로 다른 제품에 대한 전년 대비 및 월별 판매 성장을 계산합니다. 이 파이프라인에는 P&L 데이터 파이프라인에서 이전에 계산한 월별 판매 데이터가 필요합니다.
조직에서는 P&L 데이터 파이프라인이 마케팅 파이프라인보다 우선순위가 높다고 간주합니다. 하지만 P&L은 복잡한 데이터 파이프라인이라서 많은 양의 리소스를 소비하기 때문에 다른 파이프라인이 동시에 실행되지 않습니다. 또한 P&L 파이프라인이 실패하면 마케팅 파이프라인 및 기타 종속 파이프라인에 실행할 수 있는 필수 데이터가 없으며 P&L의 재시도를 기다려야 합니다. 다음 다이어그램은 이러한 상황을 보여줍니다.
그림 12. 복잡한 데이터 파이프라인이 우선순위가 낮은 파이프라인의 실행을 방해할 수 있습니다.
조직이 BigQuery로 마이그레이션하려고 합니다. P&L과 마케팅 매출 증가라는 두 가지 사용 사례를 식별하여 마이그레이션 백로그에 포함했습니다. 다음 반복을 계획할 때 조직은 P&L 사용 사례의 우선순위를 지정하고 반복 백로그에 포함합니다. 이는 현재 온프레미스 리소스에 의해 크게 제한되고 주기적으로 지연을 유발하기 때문입니다. 여기에는 종속 사용 사례 중 일부도 포함되어 있으며, 이 중에 마케팅 사용 사례도 있습니다.
마이그레이션팀이 첫 번째 반복을 실행합니다. 리디렉션 방식을 사용하여 P&L 및 마케팅 사용 사례를 모두 Google Cloud로 이동하기로 선택합니다. 파이프라인 단계 또는 조정을 변경하지 않습니다. 중요한 차이점은 이제 P&L 파이프라인이 거의 무제한의 컴퓨팅 성능을 처리할 수 있으므로 온프레미스보다 훨씬 빠르게 실행될 수 있다는 것입니다. 파이프라인은 월별 판매 데이터를 마케팅 성장 파이프라인이 사용하는 BigQuery 테이블에 씁니다. 다음 다이어그램은 이러한 변경사항을 보여줍니다.
그림 13. 리디렉션 방식을 사용하여 복잡한 데이터 파이프라인을 가속화합니다.
Google Cloud는 비기능적 P&L 문제에 도움을 주었지만 여전히 기능적인 문제가 남아 있습니다. 월간 매출 계산에 앞서 관련이 없는 일부 작업은 종종 계산을 방해하는 오류를 발생시켜 종속 파이프라인을 시작할 수 없게 합니다.
두 번째 반복에서 팀은 반복 백로그에 두 가지 사용 사례를 모두 포함하여 성능을 향상시키려고 합니다. 팀은 P&L 파이프라인에서 월별 매출을 계산하기 위한 파이프라인 단계를 식별합니다. 다음 다이어그램과 같이 단계가 하위 DAG를 구성합니다. 마이그레이션팀은 하위 DAG를 마케팅 파이프라인에 복사하여 파이프라인이 P&L과 독립적으로 실행될 수 있게 합니다. Google Cloud에 충분한 컴퓨팅 성능이 있으면 두 개의 파이프라인을 동시에 실행할 수 있습니다.
그림 14. 하위 DAG를 사용하여 동시에 실행되는 파이프라인
단점은 하위 DAG 논리를 복제하면 코드 관리 오버헤드가 발생한다는 것입니다. 이제 팀은 하위 DAG 논리의 두 사본을 동기화해야 합니다.
세 번째 반복에서 팀은 사용 사례를 다시 검토하고 월별 판매 하위 DAG를 독립적인 파이프라인으로 추출합니다. 새로운 월별 판매 파이프라인이 완료되면 P&L, 마케팅 성장, 기타 종속 파이프라인을 트리거하거나 팬아웃합니다. 이 구성은 새로운 전체 조정 DAG를 생성하며 각 파이프라인은 하위 DAG 중 하나입니다.
그림 15. 자체 하위 DAG에 각 파이프라인이 있는 전체 조정 DAG
이후 반복에서 마이그레이션팀은 나머지 기능 문제를 해결하고 파이프라인을 마이그레이션하여 다음과 같은 Google Cloud 관리형 서비스를 사용할 수 있습니다.
- Dataflow: Beam 모델을 사용하여 각 데이터 파이프라인을 자체 포함 DAG로 정의할 수 있습니다.
- Cloud Composer: 보다 광범위한 조정을 하나 이상의 Airflow DAGs로 정의할 수 있습니다.
Airflow는 기본적으로 하위 DAG를 지원하지만 이 기능은 성능을 제한할 수 있으므로 권장하지 않습니다.
그 대신 독립적인 DAG를 TriggerDagRunOperator 연산자와 함께 사용하세요.
다음 단계
데이터 웨어하우스 마이그레이션의 다음 단계를 자세히 알아보세요.
특정 데이터 웨어하우스 기술에서 BigQuery로 이전하는 방법도 알아볼 수 있습니다.