이 페이지에서는 스트리밍 파이프라인을 업그레이드하기 위한 안내와 권장사항을 제공합니다. 예를 들어 Apache Beam SDK의 새 버전으로 업그레이드해야 하거나 파이프라인 코드를 업데이트해야 할 수 있습니다. 여러 시나리오에 맞게 다양한 옵션이 제공됩니다.
작업 완료 시 중지되는 일괄 파이프라인과 달리 스트리밍 파이프라인은 중단 없는 처리를 제공하기 위해 지속적으로 실행되는 경우가 많습니다. 따라서 스트리밍 파이프라인을 업그레이드할 때는 다음 사항을 고려해야 합니다.
- 파이프라인의 중단을 최소화하거나 피해야 할 수 있습니다. 파이프라인의 새 버전이 배포되는 동안 일시적인 처리 중단을 허용할 수 있는 경우가 있지만 애플리케이션이 중단을 허용하지 않는 경우도 있습니다.
- 파이프라인 업데이트 프로세스는 메시지 처리 및 기타 연결된 시스템의 중단을 최소화하는 방식으로 스키마 변경을 처리해야 합니다. 예를 들어 이벤트 처리 파이프라인의 메시지 스키마가 변경되면 다운스트림 데이터 싱크의 스키마도 변경해야 할 수 있습니다.
파이프라인 및 업데이트 요구사항에 따라 다음 방법 중 하나를 사용하여 스트리밍 파이프라인을 업데이트할 수 있습니다.
업데이트 중에 발생할 수 있는 문제와 이를 방지하는 방법에 대한 자세한 내용은 교체 작업 유효성 검사 및 작업 호환성 검사를 참조하세요.
권장사항
- Apache Beam SDK 버전을 파이프라인 코드 변경과 별도로 업그레이드합니다.
- 추가 업데이트를 수행하기 전에 각각 변경한 후 파이프라인을 테스트합니다.
- 파이프라인에서 사용하는 Apache Beam SDK 버전을 정기적으로 업그레이드합니다.
진행 중인 업데이트 수행
작업을 중지하지 않고 진행 중인 일부 스트리밍 파이프라인을 업데이트할 수 있습니다. 이 시나리오를 진행 중인 작업 업데이트라고 부릅니다. 진행 중인 작업 업데이트는 다음과 같이 제한된 상황에서만 사용할 수 있습니다.
- 작업이 Streaming Engine을 사용해야 합니다.
- 작업이 실행 중 상태여야 합니다.
- 작업에 사용되는 작업자 수만 변경합니다.
자세한 내용은 수평 자동 확장 페이지의 자동 확장 범위 설정을 참조하세요.
진행 중인 작업 업데이트를 수행하는 방법은 기존 파이프라인 업데이트를 참조하세요.
교체 작업 실행
업데이트된 작업이 기존 작업과 호환되는 경우 update 옵션을 사용하여 파이프라인을 업데이트할 수 있습니다. 기존 작업을 교체하면 새 작업이 업데이트된 파이프라인 코드를 실행합니다.
Dataflow 서비스는 작업 이름을 유지하지만 업데이트된 작업 ID로 교체 작업을 실행합니다. 이 프로세스로 인해 기존 작업이 중지되고 호환성 검사가 실행되어 새 작업이 시작될 때 다운타임이 발생할 수 있습니다. 자세한 내용은 작업 교체의 영향을 참조하세요.
Dataflow는 업데이트된 파이프라인 코드를 실행 중인 파이프라인에 안전하게 배포할 수 있도록 호환성 검사를 수행합니다. 기존 단계에서 부차 입력이 추가 또는 삭제되는 경우와 같이 특정 코드 변경으로 인해 호환성 검사가 실패할 수 있습니다. 호환성 검사가 실패하면 준비가 된 작업 업데이트를 수행할 수 없습니다.
교체 작업을 실행하는 방법은 교체 작업 실행을 참조하세요.
파이프라인 업데이트가 현재 작업과 호환되지 않으면 파이프라인을 중지하고 교체해야 합니다. 파이프라인에 다운타임이 허용되지 않는 경우에는 병렬 파이프라인을 실행합니다.
파이프라인 중지 및 교체
처리를 일시적으로 중지할 수 있는 경우 파이프라인을 취소하거나 드레이닝한 다음 업데이트된 파이프라인으로 바꿀 수 있습니다. 파이프라인을 취소하면 Dataflow가 즉시 처리를 중지하고 가능한 빨리 리소스를 종료하므로 처리 중인(진행 중인) 데이터의 일부가 손실될 수 있습니다. 대부분의 경우 데이터 손실을 방지하기 위해 드레이닝을 사용하는 것이 좋습니다. 또한 Dataflow 스냅샷을 사용하여 스트리밍 파이프라인의 상태를 저장할 수 있습니다. 따라서 상태가 손실되지 않고 새 버전의 Dataflow 작업을 시작할 수 있습니다. 자세한 내용은 Dataflow 스냅샷 사용을 참조하세요.
파이프라인을 드레이닝하면 처리 중인 모든 창이 즉시 닫히고 모든 트리거가 실행됩니다. 진행 중인 데이터가 손실되지는 않지만 드레이닝을 수행하면 창에 불완전한 데이터가 발생할 수 있습니다. 이 경우 처리 중인 창에서는 일부 또는 불완전한 결과를 내보냅니다. 자세한 내용은 작업 드레이닝의 영향을 참조하세요. 기존 작업이 완료되면 업데이트된 파이프라인 코드가 포함된 새 스트리밍 작업을 실행하여 처리를 재개할 수 있습니다.
이 방법을 사용하면 기존 스트리밍 작업이 종료되는 시점과 교체 파이프라인이 데이터 처리를 재개할 수 있는 시점 사이에 몇 차례의 다운타임이 발생합니다. 그러나 기존 파이프라인을 취소하거나 드레이닝한 다음 업데이트된 파이프라인으로 새 작업을 실행하는 것은 병렬 파이프라인을 실행하는 것보다 덜 복잡합니다.
자세한 내용은 Dataflow 작업 드레이닝을 참조하세요. 현재 작업을 드레이닝한 후 동일한 작업 이름으로 새 작업을 시작합니다.
Pub/Sub 스냅샷 및 Seek을 사용한 메시지 재처리
경우에 따라 드레이닝 파이프라인을 교체하거나 취소한 후에 이전에 전송된 Pub/Sub 메시지를 다시 처리해야 할 수도 있습니다. 예를 들어 데이터를 다시 처리하려면 업데이트된 비즈니스 로직을 사용해야 할 수 있습니다. Pub/Sub Seek 기능을 사용하면 Pub/Sub 스냅샷에서 메시지를 재생할 수 있습니다. Dataflow로 Pub/Sub Seek를 사용하면 구독 스냅샷이 생성된 시점부터 메시지를 다시 처리할 수 있습니다.
개발 및 테스트 중에 Pub/Sub Seek을 사용하여 알려진 메시지를 반복 재생하여 파이프라인의 출력을 확인할 수도 있습니다. Pub/Sub Seek를 사용하는 경우 파이프라인에서 구독을 사용 중일 때는 구독 스냅샷을 탐색하지 마세요. 탐색하면 Dataflow의 워터마크 로직이 무효화되고 Pub/Sub 메시지가 정확히 한 번만 처리되게 할 수 있습니다.
터미널 창에서 Dataflow 파이프라인으로 Pub/Sub Seek를 사용하는 데 권장되는 gcloud CLI 워크플로는 다음과 같습니다.
구독 스냅샷을 만들려면
gcloud pubsub snapshots create명령어를 사용합니다.gcloud pubsub snapshots create SNAPSHOT_NAME --subscription=PIPELINE_SUBSCRIPTION_NAME
파이프라인을 드레이닝하거나 취소하려면
gcloud dataflow jobs drain명령어나gcloud dataflow jobs cancel명령어를 사용합니다.gcloud dataflow jobs drain JOB_ID
사용하여
gcloud dataflow jobs cancel JOB_ID
스냅샷을 탐색하려면
gcloud pubsub subscriptions seek명령어를 사용합니다.gcloud pubsub subscriptions seek SNAPSHOT_NAME
구독을 사용하는 새 파이프라인을 배포합니다.
병렬 파이프라인 실행
업데이트 중에 스트리밍 파이프라인이 중단되지 않도록 하려면 병렬 파이프라인을 실행합니다. 업데이트된 파이프라인 코드가 있는 새 스트리밍 작업을 만들고 기존 파이프라인과 동시에 새 파이프라인을 실행합니다.
새 파이프라인을 만들 때는 기존 파이프라인에 사용한 것과 동일한 기간 설정 전략을 사용합니다. 워터마크가 업데이트된 파이프라인에서 처리한 가장 오래된 완료 윈도우의 타임스탬프를 초과할 때까지 기존 파이프라인을 계속 실행할 수 있습니다. 그런 다음 기존 파이프라인을 드레이닝하거나 취소합니다. 업데이트된 파이프라인은 해당 위치에서 계속 실행되고 자체 처리 작업을 효과적으로 인계받습니다.
다음 다이어그램은 이 프로세스를 보여줍니다.
다이어그램에서 파이프라인 B는 파이프라인 A에서 인계받은 업데이트된 작업입니다. t 값은 파이프라인 B에서 처리된 가장 오래된 완료 기간의 타임스탬프입니다. w 값은 파이프라인 A의 워터마크입니다. 편의를 위해 지연 데이터가 없는 완벽한 워터마크라고 가정합니다. 가로축에 처리 및 실제 경과 시간이 표시됩니다. 두 파이프라인 모두 5분의 고정(텀블링) 기간을 사용합니다. 워터마크가 각 기간의 끝을 통과한 후 결과가 트리거됩니다.
두 파이프라인이 겹치는 기간 동안 동시 출력이 발생하므로 결과를 서로 다른 대상에 쓰도록 두 파이프라인을 구성합니다. 그런 다음 다운스트림 시스템은 데이터베이스 보기와 같은 두 대상 싱크에 대한 추상화를 사용하여 결합된 결과를 쿼리할 수 있습니다. 이러한 시스템은 추상화를 사용하여 중첩 기간에서 결과를 중복 삭제할 수도 있습니다.
다음 예시는 Pub/Sub에서 입력 데이터를 읽고, 일부 처리를 수행하고, 결과를 BigQuery에 쓰는 파이프라인의 사용 방법을 설명합니다.
초기 상태에서는 기존 스트리밍 파이프라인(파이프라인 A)이 실행 중이고 구독(구독 A)을 사용하여 Pub/Sub 주제(주제)에서 메시지를 실행하고 읽습니다. 결과는 BigQuery 테이블(테이블 A)에 기록됩니다. 결과는 기본 테이블 변경사항을 마스킹하는 파사드 역할을 하는 BigQuery 뷰를 통해 사용할 수 있습니다. 이 프로세스는 파사드 패턴이라는 디자인 메서드의 애플리케이션입니다. 다음 다이어그램은 초기 상태를 보여줍니다.
업데이트된 파이프라인의 새 구독(구독 B)을 만듭니다. 구독 B를 사용하여 Pub/Sub 주제(주제)에서 읽고 별도의 BigQuery 테이블(테이블 B)에 쓰는 업데이트된 파이프라인(파이프라인 B)을 배포합니다. 이 흐름을 다이어그램으로 나타내면 다음과 같습니다.
이 시점에서 파이프라인 A 및 파이프라인 B는 동시에 실행되며 결과를 별도의 테이블에 씁니다. 시간 t는 파이프라인 B에서 처리된 가장 오래된 완료 기간의 타임스탬프로 기록합니다.
파이프라인 A의 워터마크가 시간 t를 초과하면 파이프라인 A를 드레이닝합니다. 파이프라인을 드레이닝하면 열린 창이 모두 닫히고 진행 중인 데이터의 처리가 완료됩니다. 파이프라인에 윈도우가 있고 완료 윈도우가 중요한 경우(지연 데이터가 없다고 가정) 파이프라인 A를 드레이닝하기 전에 겹치는 윈도우가 완료될 때까지 두 파이프라인 모두 실행합니다. 진행 중인 데이터를 모두 처리하고 테이블 A에 기록한 후에는 파이프라인 A의 스트리밍 작업을 중지합니다. 다음 다이어그램은 이 단계를 보여줍니다.
이 시점에서는 파이프라인 B만 실행됩니다. 테이블 A와 테이블 B의 파사드 역할을 하는 BigQuery 뷰(파사드 뷰)에서 쿼리할 수 있습니다. 두 테이블에 동일한 타임스탬프가 있는 행의 경우 테이블 B의 행을 반환하거나 테이블 B에 행이 없는 경우 테이블 A로 돌아가도록 뷰를 구성합니다. 다음 다이어그램은 테이블 A와 테이블 B에서 읽는 뷰(파사드 뷰)를 보여줍니다.
이 시점에서 구독 A를 삭제할 수 있습니다.
새 파이프라인 배포에서 문제가 감지되었을 때 병렬 파이프라인을 사용하면 롤백이 간소화될 수 있습니다. 이 예시에서는 정확한 작동을 위해 파이프라인 B를 모니터링하면서 파이프라인 A를 계속 실행하는 것이 좋습니다. 파이프라인 B에서 문제가 발생하면 파이프라인 A로 롤백할 수 있습니다.
제한사항
이 방식에는 다음과 같은 제한사항이 있습니다.
- 같은 입력에서 파이프라인 2개를 실행하면 출력에 중복 데이터가 생성될 수 있습니다. 다운스트림 시스템은 중복 데이터를 인식하고 이를 허용할 수 있어야 합니다.
- Pub/Sub 소스에서 읽을 때 여러 파이프라인에 같은 구독 사용은 권장되지 않으며 정확성 문제가 발생할 수 있습니다. 그러나 추출, 변환, 로드(ETL) 파이프라인과 같은 일부 사용 사례에서 파이프라인 2개에서 같은 구독을 사용하면 중복이 줄어들 수 있습니다. 자동 확장 문제가 이 시나리오에서 발생할 수 있지만 진행 중인 작업 업데이트 기능을 사용하여 완화할 수 있습니다. 자세한 내용은 Pub/Sub 스트리밍 파이프라인의 자동 확장 처리 미세 조정을 참조하세요.
- Pub/Sub 소스에서 읽을 때 두 번째 구독을 사용하면 중복이 생성되지만 데이터 정확성과 자동 확장에서 문제가 발생하지 않습니다.
스키마 변형 처리
데이터 처리 시스템은 비즈니스 요구사항의 변경이나 기술적인 이유로 스키마 변형을 수용해야 하는 경우가 많습니다. 일반적으로 스키마 업데이트를 적용할 때는 비즈니스 정보 시스템이 중단되지 않도록 신중하게 계획하고 실행해야 합니다.
Pub/Sub 주제에서 JSON 페이로드가 포함된 메시지를 읽는 파이프라인을 고려해보세요. 파이프라인은 각 메시지를 TableRow 인스턴스로 변환한 다음 행을 BigQuery 테이블에 씁니다. 출력 테이블의 스키마는 파이프라인에서 처리되는 메시지와 유사합니다.
다음 다이어그램에서는 스키마를 스키마 A라고 합니다.
시간이 지나면서 메시지 스키마가 간단하지 않은 방식으로 변형될 수 있습니다. 예를 들어 필드가 추가, 삭제 또는 교체됩니다. 스키마 A는 새로운 스키마로 발전합니다. 다음 다이어그램에서는 새 스키마를 스키마 B라고 합니다. 이 경우 파이프라인 A를 업데이트해야 하며 출력 테이블 스키마는 스키마 B를 지원해야 합니다.
출력 테이블의 경우 다운타임 없이 일부 스키마 변형을 수행할 수 있습니다.
예를 들어 다운타임 없이 새 필드를 추가하거나 열 모드를 완화할 수 있습니다(예: REQUIRED를 NULLABLE로 변경).
이러한 변형은 일반적으로 기존 쿼리에 영향을 주지 않습니다. 그러나 기존 스키마 필드를 수정하거나 삭제하는 스키마 변형으로 인해 쿼리가 중단되거나 다른 중단 문제가 발생합니다. 다음 방법은 다운타임 없이 변경사항을 수용합니다.
파이프라인이 기록한 데이터를 기본 테이블과 하나 이상의 스테이징 테이블로 분리합니다. 기본 테이블은 파이프라인이 쓴 이전 데이터를 저장합니다. 스테이징 테이블에는 최신 파이프라인 출력이 저장됩니다. 기본 및 스테이징 테이블에 BigQuery 파사드 뷰를 정의하면 소비자가 이전 데이터와 최신 데이터를 모두 쿼리할 수 있습니다.
다음 다이어그램에서는 스테이징 테이블(스테이징 테이블 A), 기본 테이블, 파사드 뷰를 포함하도록 이전 파이프라인 흐름을 수정합니다.
수정된 흐름에서 파이프라인 A는 스키마 A를 사용하는 메시지를 처리하고 호환되는 스키마를 가진 스테이징 테이블 A에 출력을 씁니다. 기본 테이블에는 파이프라인의 이전 버전에서 쓴 이전 데이터와 스테이징 테이블에서 주기적으로 병합되는 결과가 포함됩니다. 소비자는 파사드 뷰를 사용하여 이전 데이터와 실시간 데이터를 포함한 최신 데이터를 쿼리할 수 있습니다.
메시지 스키마가 스키마 A에서 스키마 B로 변형되면 스키마 B를 사용하는 메시지와 호환되도록 파이프라인 코드를 업데이트해야 할 수 있습니다. 기존 파이프라인을 새 구현으로 업데이트해야 합니다. 병렬 파이프라인을 실행하면 중단 없이 스트리밍 데이터 처리를 진행할 수 있습니다. 파이프라인을 종료하고 교체하면 파이프라인이 일정 시간 동안 실행되지 않으므로 처리가 중단됩니다.
업데이트된 파이프라인은 스키마 B를 사용하는 추가 스테이징 테이블(스테이징 테이블 B)에 씁니다. 파이프라인을 업데이트하기 전에 조정된 워크플로를 사용하여 새 스테이징 테이블을 만들 수 있습니다. 가능한 관련 워크플로 단계를 사용하여 새 스테이징 테이블의 결과를 포함하도록 파사드 보기를 업데이트합니다.
다음 다이어그램은 스키마 B를 포함한 스테이징 테이블 B를 보여주는 업데이트된 흐름과 기본 테이블 및 두 스테이징 테이블에서 콘텐츠를 포함하도록 파사드 뷰가 어떻게 업데이트되었는지 보여줍니다.
파이프라인 업데이트와는 별도의 프로세스로 스테이징 테이블을 주기적으로 또는 필요에 따라 기본 테이블에 병합할 수 있습니다. 다음 다이어그램은 스테이징 테이블 A가 기본 테이블에 어떻게 병합되는지 보여줍니다.
다음 단계
- 기존 파이프라인 업데이트 세부 단계 알아보기