파트 1 | 스케줄러는 단순히 “타이머” 그 이상이다

Source: Dev.to

위에 제공된 소스 링크 외에 번역할 텍스트가 포함되어 있지 않습니다. 번역을 원하는 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

Cron, 스크립트 스케줄링, 그리고 플랫폼‑레벨 스케줄링의 근본적인 차이

엔지니어링 관점에서 이 도구들은 완전히 다른 종류의 문제를 해결합니다.

Cron – triggering

• 지정된 시간에 프로세스를 시작합니다
• 작업이 성공했는지는 신경 쓰지 않습니다
• 작업 간의 관계를 이해하지 못합니다

Script‑based scheduling – process stitching

• Shell이나 Python을 사용해 단계들을 연결합니다
• 의존성은 코드나 문서에 존재합니다
• 오류 처리는 주로 사람의 경험에 크게 의존합니다

Platform‑level scheduling – execution semantics

• 작업 의존성이 실제로 충족되었는가?
• 실패 후 시스템은 무엇을 해야 하는가?
• 실행을 안전하게 재실행할 수 있는가?
• 실패 후 시스템 상태를 복구할 수 있는가?

시스템이 “몇 개의 스크립트”에서 수백·수천 개의 DAG로 진화할 때, 질문은 작업을 어떻게 실행하느냐에서 다음으로 바뀝니다:

불안정한 환경에서 신뢰할 수 있는 실행 시스템을 어떻게 유지하겠는가?

데이터 플랫폼의 “중추 신경계”인 스케줄러

성숙한 데이터 플랫폼에서 스케줄러는 주변 도구가 아니라 제어 평면입니다:

• 위쪽(Upward): 데이터 개발, 분석, AI, 메트릭 계산을 연결
• 아래쪽(Downward): Flink, Spark, SeaTunnel과 같은 실행 엔진을 오케스트레이션
• 수평(Horizontal): 데이터 생산, 처리, 전달 전체 파이프라인을 포괄

어떤 이상 현상도 결국 스케줄링 레이어에서 드러납니다:

• 상류 지연이 하류 작업을 차단
• 실행 실패가 데이터 부재를 초래
• 수동 백필이 전역 일관성을 위협

따라서 스케줄러는 다음을 제공해야 합니다:

• 전역 뷰
• 관찰 가능한 상태
• 명확한 실패 및 복구 의미론

이 관점에서 스케줄러는 “작업 실행기”가 아니라 전체 데이터 플랫폼의 런타임 코디네이터입니다.

DolphinScheduler가 해결하는 “숨겨진 문제”들

1️⃣ 정의와 실행 혼합

스크립트 기반 스케줄링은 종종 프로세스 정의와 실행 결과를 혼합합니다. 실패가 발생하면 실제로 어느 실행이 실패했는지 불분명해집니다. DolphinScheduler는 정의와 인스턴스를 명확히 구분하여 모든 실행이 추적 가능한 컨텍스트를 갖도록 합니다.

2️⃣ “실패 후에 무엇을 해야 할지 모른다”

스크립트 기반 시스템에서 재시도, 수동 재실행, 데이터 백필은 종종:

• 판단에 의존
• 임시 방편
• 재현 불가능

DolphinScheduler는 이러한 동작을 스케줄링 의미론으로 명시적으로 모델링하여 일관성 책임을 인간이 아닌 시스템으로 이전합니다.

3️⃣ 시스템 장애 후 상태 손실

프로세스 종료, 노드 충돌, 서비스 재시작은 분산 시스템에서 정상적인 현상입니다. 스케줄러는 근본적인 질문에 답해야 합니다:

복구 후 실제로 완료된 작업은 무엇이며, 어느 작업이 단지 실행된 것처럼 보이는가?

DolphinScheduler의 인스턴스 및 상태 메커니즘은 바로 이 문제를 해결하도록 설계되었습니다.

스케줄링 복잡성은 어디서 오는가?

스케줄링 시스템은 많은 기능 때문에 복잡한 것이 아니라 다중 불확실성 레이어를 처리해야 하기 때문에 복잡합니다:

• 불확실한 실행 시간
• 불확실한 자원 가용성
• 불확실한 데이터 도착
• 불가피한 인간 개입

이 모든 것이 하나의 질문으로 수렴합니다:

시스템이 현재…

상태를 신뢰할 수 있는가?

그래서 스케줄러는 본질적으로 장기간 운영되는, 상태 기반의, 분산 시스템이며, 노드와 시간을 아우릅니다.

이것이 DolphinScheduler가 다음을 중심으로 설계된 이유를 설명합니다:

• 상태 머신
• 인스턴스 라이프사이클
• 명확한 마스터 / 워커 분리

단순한 작업 디스패치가 아니라.

DolphinScheduler가 마스터 / 워커 아키텍처를 사용하는 이유

왜 DolphinScheduler는 마스터 / 워커 아키텍처를 채택해야 할까요?

Because in DolphinScheduler:

• 마스터는 작업을 실행하지 않습니다
• 워커는 스케줄링 결정을 내리지 않습니다

This separation is not about performance — it’s about clear responsibility boundaries:

• 마스터는 워크플로우 상태 머신을 구동합니다
• 워커는 실행에만 집중합니다

As a result:

• 워커가 실패해도 워크플로우가 중단되지 않습니다
• 실행 실패 ≠ 스케줄링 실패
• 스케줄링 로직을 독립적으로 발전시킬 수 있습니다

This is the foundation for horizontal scalability and high availability in a platform‑level scheduler.

최종 생각

스케줄러를 단순히 “타이머”로만 생각한다면, DolphinScheduler는 복잡하고 무겁게 느껴질 수 있습니다.

하지만 데이터 플랫폼 엔지니어링 관점에서 보면, 이것은 훨씬 더 근본적인 문제를 해결합니다:

불안정한 작업 집합을 신뢰할 수 있고 복구 가능하며 설명 가능한 실행 시스템으로 어떻게 전환할 수 있을까요?

그래서 결국 스케줄러는 데이터 플랫폼의 중추 신경계가 됩니다.

다음 기사에서는 더욱 깊이 파고들 것입니다 — 가장 기본적이고 중요한 계층부터 시작하여:

👉 DolphinScheduler의 핵심 추상화 모델: 워크플로우, 작업, 인스턴스