본문으로 건너뛰기
데이터 엔지니어 코스

스케줄링과 실행 모드 — 매일 자동으로 도는 파이프라인

같은 파이프라인을 cron 또는 이벤트 기반으로 자동 실행시키고, overwrite · append · CDC 실행 모드와 실패 시 통보 채널을 정합니다.

8분

지금까지 만든 파이프라인은 손으로 Run 버튼을 눌러야 도는 상태입니다. 운영에 올리려면 정해진 주기로 알아서 돌고, 실패하면 누가 알아챌지를 설정해 둬야 합니다. 이번 레슨은 그 둘을 한 번에 다룹니다.

스케줄 빌더 — 세 가지 트리거

파이프라인 상단 설정 → 스케줄 탭에 들어가면 트리거 셋 중 하나를 고릅니다.

  1. 시간 기반(cron) — 매일 03:00, 매주 월요일 06:00, 매 15분 같은 주기.
  2. 이벤트 기반 — 다른 파이프라인의 성공 또는 실패를 기다림. 마트 단계 파이프라인은 보통 source 단계의 성공을 기다리는 형태로 묶입니다.
  3. 수동만 — 운영에 올리지 않은 실험 단계는 이대로.

대부분의 마트 파이프라인은 (1) 일 1회 새벽 + (2) 직전 단계 성공 트리거를 같이 거는 게 안전합니다. 새벽 실행이 어떤 이유로 빠져도 의존 파이프라인이 성공 이벤트를 못 받았기 때문에 알아챌 수 있습니다.

cron 표현은 빌더로

스케줄 빌더는 cron 표현을 직접 적지 않고도 분·시·일·월·요일을 드롭다운으로 고를 수 있습니다. 직접 표현을 적고 싶다면 같은 패널의 표현 직접 입력으로 전환. 시간대는 기본이 인스턴스의 운영 시간대(Asia/Seoul)이고, 다른 시간대로 명시할 때만 표기합니다.

실행 모드와 멱등성

직전 레슨에서 Sink 노드의 쓰기 모드를 짧게 봤습니다. 스케줄링과 같이 보면 의미가 더 또렷해집니다.

쓰기 모드다시 실행했을 때 결과흔한 용례
overwrite전체 데이터셋 재생성마트 테이블, 매일 풀스캔이 빠른 규모
append기존 행 뒤에 새 행 추가이벤트 로그, 측정값 시계열
upsert키 기준으로 갱신 또는 추가운영 master 테이블 미러링
CDC (변경 데이터 캡처)직전 실행 이후 변경된 행만 가져와 반영큰 운영 테이블의 시간별 동기화

운영에 올리는 파이프라인은 몇 번 돌려도 같은 결과를 보장하는 편이 디버깅을 살립니다 (멱등성). overwrite와 upsert는 자연스럽게 멱등하고, append는 입력 데이터에 같은 키가 두 번 들어오지 않는지 보호 장치를 본인이 둬야 합니다.

CDC는 외부 시스템이 변경 시점 컬럼(updated_at)이나 변경 로그(PostgreSQL logical replication 등)를 제공할 때만 쓸 수 있습니다. 02 레슨의 커넥터 등록에서 증분 컬럼을 명시해 둔 경우 포털이 자동으로 CDC 모드를 켭니다.

실패 시 통보 — 채널과 사다리

같은 설정 패널의 알림 탭에서 실패 통보를 설정합니다.

  • 채널 — 이메일·Slack·Webhook 셋이 기본. 운영팀이 포털과 별도로 페이저 시스템을 운영한다면 Webhook으로 forwarding.
  • 트리거 조건 — 실행 실패·임계 시간 초과·데이터 품질 체크 실패 세 가지를 따로 켤 수 있습니다.
  • 사다리 — 첫 통보는 본인, 30분 무응답이면 팀 채널, 1시간이면 oncall으로 묶는 형태가 흔합니다. 포털은 에스컬레이션 정책 옵션 한 줄로 이 사다리를 표현합니다.

알림이 한 명에게만 가면 그 사람이 자리에 없을 때 침묵합니다. 본인 한 명 + 팀 채널 하나의 두 채널 동시 통보가 흔한 안전 기본값입니다.

한 번 손으로 실패시켜 보기

스케줄과 알림을 켰다면 마지막 단계는 실제로 알림이 가는지 확인하는 것.

  1. 파이프라인의 코드 노드 안에 일부러 raise ValueError("test alert") 한 줄을 넣고 저장.
  2. Run 을 손으로 한 번.
  3. 채널(이메일·Slack)에 알림이 도달하는지, 메시지에 어떤 파이프라인·어떤 노드·어떤 시각이 모두 들어 있는지 확인.
  4. 한 줄을 다시 제거하고 저장. 다음 스케줄에서 정상 통과.

이 고의 실패 한 번이 운영에서 두고두고 본인을 살립니다. 실제 첫 실패가 새벽 04:00에 났을 때 알림 자체가 안 갔다는 사실은 너무 늦게 알게 됩니다.

자가 점검

  • 본인의 파이프라인이 스케줄 빌더에서 주기 + 다음 실행 시각으로 보이는가
  • Sink 노드의 쓰기 모드가 의도와 일치하는가 (overwrite·append·upsert·CDC)
  • 알림 채널이 두 군데 이상에 동시 등록돼 있는가
  • 고의 실패 한 번으로 알림이 실제로 두 채널 모두에 도달했는가
  • 03:00 정각이 아닌 분 단위로 시작 시각을 분산시켰는가

다음 레슨

마지막 레슨은 운영 중에 실제 실패가 났을 때 로그와 노드 상태로 어디서 막혔는지 좁히는 법, 그리고 본인이 만든 데이터셋을 분석가에게 깔끔히 인계하는 법을 한 번에.