1.3 버전에서 3.x 시리즈에 이르기까지, Apache DolphinScheduler는 아키텍처, 기능 및 확장성 전반에 걸쳐 상당한 개선을 도입하며 여러 차례의 진화를 거쳤습니다. 이러한 변화는 커뮤니티로부터 상당한 관심을 끌었습니다.

이 글은 테이블 구조의 진화, 작업 유형(task type)의 확장, 레지스트리(registry)의 다양화, 아키텍처 최적화, 그리고 기능 강화라는 다섯 가지 관점에서 Apache DolphinScheduler 1.3과 3.x 사이의 주요 차이점을 체계적으로 비교합니다. 또한 t_ds_process_definition에서 t_ds_workflow_definition으로의 테이블 명명 리팩토링(refactoring), 12개 작업 유형에서 30개 이상의 작업 유형으로의 확장, 단일 ZooKeeper 레지스트리에서 다중 레지스트리 구현으로의 진화를 비롯하여, 마이크로커널 플러그인 아키텍처(microkernel plugin architecture), 분산형 설계(decentralized design), 결함 허용 메커니즘(fault tolerance mechanisms), 로그 액세스 아키텍처를 포함한 주요 기술 업그레이드를 심층적으로 분석합니다.

이 심층 분석은 사용자들이 Apache DolphinScheduler의 아키텍처 진화 여정과 주요 업그레이드 고려 사항을 더 잘 이해하도록 돕습니다. 이는 특히 이전 버전에서 최신 3.x 릴리스로 업그레이드를 계획 중인 팀에게 매우 가치가 있습니다.

1. 시스템 아키텍처 개요

1.1 핵심 아키텍처 설계

Apache DolphinScheduler 3.x는 **마이크로커널 + 플러그인 아키텍처(microkernel + plugin architecture)**를 채택하여, 작업 유형, 리소스 저장소 및 레지스트리 구현과 같은 핵심 역량이 확장 지점(extension points)으로 설계되었습니다. 시스템은 유연성과 확장성을 높이기 위해 SPI (Service Provider Interface)를 사용합니다.

1.2 분산형 아키텍처 설계

Apache DolphinScheduler는 분산형 아키텍처 (decentralized architecture)를 채택합니다. Master 및 Worker 클러스터는 ZooKeeper, JDBC, Etcd와 같은 레지스트리 (registry) 구현체를 통해 통신하고 조정하며, 이를 통해 단일 중앙 노드 없이도 고가용성 (high availability) 및 분산 시스템을 구현합니다.

• MasterServer: 주로 DAG 작업 분할, 작업 제출 모니터링, 그리고 다른 MasterServer 및 WorkerServer 인스턴스의 상태 모니터링을 담당합니다.
• WorkerServer: 주로 작업 실행 및 로그 서비스 제공을 담당합니다.
• Registry: 클러스터 관리 및 결함 허용 (fault tolerance)을 위해 ZooKeeper, JDBC, Etcd의 세 가지 구현체를 지원합니다.

2. 전체 워크플로우 저장 구조 (3.x 버전)

2.1 테이블 구조의 진화

1.3 시리즈에서 3.x 시리즈로 넘어오면서, Apache DolphinScheduler는 **"process"**라는 용어를 **"workflow"**로 교체하여 핵심 데이터베이스 테이블의 명칭을 표준화했습니다. 이러한 변경은 플랫폼의 워크플로우 중심 개념을 더 잘 반영합니다.

2.2 핵심 테이블 상세 분석

2.2.1 워크플로우 정의 테이블 (t_ds_workflow_definition)

1.3 버전과 비교했을 때, 3.x에서 도입된 주요 변경 사항은 다음과 같습니다:

• 기존의 id 대신 code를 비즈니스 고유 식별자로 사용합니다.
• 직렬 실행 전략을 지원하기 위해 execution_type 필드를 추가했습니다.
• 워크플로우를 알림 그룹과 연결하기 위해 warning_group_id 필드를 추가했습니다.
• process_definition_json 필드를 제거했습니다. 작업 정보는 이제 관련 테이블을 통해 저장되고 관리됩니다.

2.2.2 워크플로우 데이터 모델 관계

2.3 핵심 서비스 레이어 (Core Service Layer) API

ProcessService 인터페이스는 워크플로우 정의 관리(workflow definition management)를 위한 핵심 API를 제공합니다:

3. 작업 유형 분류 시스템 (Task Type Classification System)

3.1 작업 유형 아키텍처 (Task Type Architecture)

Apache DolphinScheduler 3.x는 지원되는 작업 유형을 30개 이상으로 확장하였으며, 기능적 특성에 따라 5개의 주요 그룹으로 분류합니다:

3.2 작업 유형 비교 (1.3 vs 3.x)

3.3 전형적인 작업 파라미터 구조 (Typical Task Parameter Structure)

3.3.1 모든 작업 유형에 대한 공통 파라미터 구조

모든 작업 유형은 다음의 공통 파라미터를 지원합니다:

3.3.2 Shell 작업 파라미터 예시

{
  "localParams": [],
  "resourceList": [
...

3.3.3 SQL 작업 파라미터 예시

{
  "type": "MYSQL",
  "datasource": 1,
...

4. 핵심 아키텍처 흐름 (Core Architecture Flow)

4.1 워크플로우 실행 흐름 (Workflow Execution Flow)

4.2 레지스트리 아키텍처 (Registry Architecture)

Apache DolphinScheduler 3.x는 ZooKeeper, JDBC, Etcd를 포함한 다양한 레지스트리 (Registry) 구현을 지원하여 진정한 탈중앙화 아키텍처 (Decentralized Architecture)를 가능하게 합니다.

4.2.1 JDBC 레지스트리 (JDBC Registry)

JDBC 레지스트리는 관계형 데이터베이스 (Relational Database)를 사용하여 이벤트 리스닝 (Event Listening) 및 분산 잠금 (Distributed Locking)을 구현합니다. 이는 이미 데이터베이스 인프라가 구축되어 있는 환경에 적합합니다.

주요 특징:

• 이벤트 리스닝 (Event Listening): JdbcRegistryDataChangeListenerAdapter를 사용하여 데이터베이스 변경 사항을 모니터링합니다.
• 분산 잠금 (Distributed Locking): 차단형 잠금 획득 (Blocking Lock Acquisition)과 타임아웃 기반 잠금 획득 (Timeout-based Lock Acquisition)을 모두 지원합니다.
• 하트비트 메커니즘 (Heartbeat Mechanism): 하트비트 감지를 사용하여 클라이언트 가용성을 모니터링하고 만료된 잠금을 자동으로 정리합니다.

설정 예시:

registry:
  type: jdbc
  heartbeat-refresh-interval: 3s
...

4.2.2 Etcd 레지스트리 (Etcd Registry)

Etcd 레지스트리는 Jetcd 클라이언트 라이브러리를 기반으로 구현되었으며, 클라우드 네이티브 (Cloud-native) 환경을 위해 설계되었습니다.

주요 특징:

• Watch API: 지정된 키(Key) 또는 키 접두사(Key Prefix)의 변경 사항을 모니터링합니다.
• 임대 잠금 (Lease Lock): TTL 기반의 임대 (Lease) 메커니즘을 사용하여 클라이언트가 연결 해제될 때 잠금을 자동으로 해제합니다.
• 연결 상태 모니터링 (Connection Health Monitoring): EtcdConnectionStateListener를 통해 연결 상태를 추적합니다.

5. 결함 허용 설계 (Fault Tolerance Design)

5.1 장애 복구 메커니즘 (Failure Recovery Mechanism)

Apache DolphinScheduler의 결함 허용 (Fault Tolerance) 설계는 레지스트리에서 제공하는 와처 (Watcher) 메커니즘에 의존합니다. 이는 주로 두 가지 시나리오를 다룹니다: 마스터 페일오버 (Master Failover) 및 워커 페일오버 (Worker Failover).

5.2 태스크 실패 재시도 (Task Failure Retry)

태스크 실패 재시도 (Task failure retry), 워크플로우 실패 복구 (workflow failure recovery), 그리고 워크플로우 실패 재실행 (workflow failure rerun)은 서로 다른 세 가지 개념입니다:

• 비즈니스 노드 (Business Nodes): Shell, SQL, Spark, Flink 및 실패 재시도를 지원하는 기타 실행 가능한 태스크들.
• 논리 노드 (Logical Nodes): DEPENDENT, SUB_WORKFLOW, CONDITIONS 및 실패 재시도를 지원하지 않는 기타 제어 흐름 (control-flow) 태스크들.

6. 태스크 우선순위 설계 (Task Priority Design)

Apache DolphinScheduler는 중요한 태스크가 먼저 실행되도록 보장하기 위해 다단계 우선순위 스케줄링 메커니즘 (multi-level priority scheduling mechanism)을 채택합니다.

구현 메커니즘 (Implementation Mechanism):

• 레지스트리 태스크 큐 (registry task queue)에 workflow instance priority_workflow instance id_task priority_task id 정보를 저장합니다.
• 문자열 비교 (string comparison)를 사용하여 우선순위가 가장 높은 태스크를 결정합니다.
• 워크플로우 우선순위 (workflow priority)와 태스크 우선순위 (task priority) 모두 5개의 단계를 포함합니다: HIGHEST, HIGH, MEDIUM, LOW, LOWEST.

7. 로그 액세스 메커니즘 (Log Access Mechanism)

Apache DolphinScheduler 3.x는 이전의 Netty 기반 구현을 대체하여 원격 로그 액세스 (remote log access)를 위해 gRPC를 사용합니다.

**Logback 설정의 주요 포인트 (Key Points of Logback Configuration):

• SiftingAppender를 사용하여 작업 ID (task IDs)를 기반으로 로그 파일을 분리합니다.
• TaskLogFilter를 사용하여 작업 관련 로그를 필터링합니다.
• TaskLogDiscriminator를 사용하여 taskAppId를 기반으로 서로 다른 작업을 구분합니다.
• SensitiveDataConverter를 사용하여 민감한 정보를 마스킹 (masking) 합니다.

8. 시스템 모듈 아키텍처 (System Module Architecture)

Apache DolphinScheduler는 여러 개의 핵심 모듈로 구성되어 있으며, 각 모듈은 명확하게 정의된 책임을 가집니다: