Apache DolphinScheduler 3.x는 아키텍처를 완전히 뒤바꿨습니다. 1.3 버전을 사용하는 팀은 업그레이드 전에 클러스터 레이아웃을 재구성하고 데이터베이스 스키마를 다시 작성해야 합니다. 기존의 단일 노드 마스터는 사라지고, 작업 스케줄링, 저장 및 로깅 방식이 다른 플러그인 기반의 분산형 시스템으로 대체되었습니다.
왜 이 변화가 중요한가
1.3 버전은 모든 스케줄링 결정을 처리하는 중앙 집중식 마스터에 의존했으며, 내장된 작업 유형은 12개에 불과했습니다. 3.x는 이를 작업 유형과 스토리지 어댑터를 플러그인으로 로드하는 마이크로커널 방식으로 전환했으며, 마스터와 워커가 레지스트리 서비스를 통해 통신하게 함으로써 단일 장애점(SPOF)을 제거했습니다. 운영자는 확장성과 탄력성을 얻고, 개발자는 코어 코드를 수정하는 대신 JAR 파일을 추가하는 것만으로 스케줄러를 확장할 수 있습니다.
아키텍처 개편
- 마이크로커널 플러그인 시스템 – 작업 정의, 리소스 핸들러 및 사용자 정의 상태 확인(health check)이 이제 별도의 모듈로 분리되었습니다. 플러그인을 클래스패스(classpath)에 배치하고 해당 노드를 재시작하면 새로운 작업 유형을 추가할 수 있습니다.
- 분산형 코디네이션 – 마스터와 워커는 레지스트리를 통해 서로를 탐색합니다. 레지스트리는 ZooKeeper(기존 기본값), JDBC 기반 관계형 데이터베이스 또는 Etcd 클러스터가 될 수 있습니다. 기존 스택에 맞는 기술을 선택하십시오.
- 확장된 작업 카탈로그 – 내장 작업이 12개에서 30개 이상으로 늘어나 클라우드 네이티브 워크로드와 머신러닝 파이프라인을 지원합니다.
- MasterServer vs WorkerServer – MasterServer는 이제 DAG 파티셔닝, 제출 및 상태 모니터링을 담당합니다. WorkerServer는 로그 스트리밍 기능도 갖춘 순수 실행 엔진 역할을 합니다. 이러한 분리는 책임을 명확히 하고 각 레이어를 독립적으로 규모에 맞게 조정할 수 있게 해줍니다.
- Watcher를 통한 결함 허용 – Watcher는 레지스트리를 감시하며 노드 장애를 확인합니다. 마스터나 워커가 중단되면 레지스트리가 자동 페일오버를 트리거합니다.
- gRPC 로그 전송 – 원격 로그 검색 방식이 Netty 기반 프로토콜에서 gRPC로 변경되었으며, 소스에 따르면 성능이 더 향상되었습니다.
무시할 수 없는 데이터베이스 리팩토링
스키마 개편은 업그레이드 시 가장 실질적인 장애물입니다:
| 1.3 테이블 | 3.x 테이블 | 변경 사항 |
|---|---|---|
t_ds_process_definition |
t_ds_workflow_definition |
UI 및 API 용어와 일치하도록 “process”라는 용어가 “workflow”로 변경되었습니다. |
t_ds_process_instance |
t_ds_workflow_instance |
런타임 레코드에 대해서도 동일한 의미론적 변화가 적용되었습니다. |
이름 변경 외에도, 3.x는 이전에 JSON 블롭(blob) 내에 저장되었던 작업 메타데이터를 전용 관계형 테이블로 추출하여 데이터 관리를 더욱 깔끔하게 만들었습니다.
마이그레이션 체크리스트
- 모든 데이터 백업 – 1.3 데이터베이스 전체 덤프를 내보내고
conf디렉토리를 복사합니다. - 기존 테이블을 새 이름으로 매핑 –
t_ds_process_definition을t_ds_workflow_definition으로,t_ds_process_instance를t_ds_workflow_instance로 변경하는 스크립트를 실행합니다. 이후 외래 키(foreign-key) 제약 조건을 확인합니다. - JSON 작업 필드 마이그레이션 – JSON으로 인코딩된 작업 데이터를 새로운 관계형 테이블로 복사합니다. 스케줄러가 새로운 레이아웃을 제대로 읽는지 확인하기 위해 몇 개의 DAG를 테스트합니다.
- 레지스트리 선택 – 이미 ZooKeeper를 사용 중이라면 그대로 유지하고, 그렇지 않으면 JDBC 기반 레지스트리나 Etcd 클러스터를 설정한 후 모든 노드가 새 주소를 가리키도록 합니다.
- 플러그인 배포 – 1.3에서 사용하던 사용자 정의 작업 유형을 3.x 호환 플러그인으로 패키징하여 각 MasterServer에 배포합니다.
- MasterServer 우선 배포 – 마이그레이션된 데이터베이스를 가리키는 새로운 MasterServer 인스턴스를 시작합니다. 기존 워크플로가 목록에 표시되는지, 상태 대시보드에 오류가 없는지 확인합니다.
- WorkerServer 추가 – WorkerServer를 하나씩 실행합니다. 레지스트리에 성공적으로 등록되는지 확인하고 로그가 gRPC를 통해 흐르는지 확인합니다.
- 스모크 테스트 실행 – 가장 일반적인 작업 유형을 포함하는 몇 개의 저위험 DAG를 실행합니다. UI에 로그가 나타나는지, 작업 상태 업데이트가 올바르게 전파되는지 확인합니다.
- 페일오버 모니터링 – MasterServer 충돌을 시뮬레이션하고 Watcher가 대기(standby) 노드를 승격시키는지 관찰합니다. 실행 중인 작업이 수동 재시작 없이 계속되는지 확인합니다.
주의해야 할 점
새로운 플러그인 모델은 강력하지만, 사용자 정의 개발의 난이도를 높입니다.
결론적으로: 1.3에서 3.x로의 전환은 단순한 버전 업그레이드가 아닙니다. 이는 조율된 데이터베이스 이름 변경, JSON-to-relational 마이그레이션, 그리고 플러그인 활성화 및 레지스트리 기반 모델을 중심으로 한 클러스터의 재설계를 필요로 합니다. 체크리스트를 단계별로 따르고 조기에 테스트를 진행하십시오. 그러면 수평 확장(scale out)이 가능하고, 자동으로 복구되며, 현대적인 클라우드 서비스와 동일한 프로토콜을 사용하는 스케줄러를 확보하게 될 것입니다.