Workflow Orchestration / Kestra 알아보기

Workflow Orchestration이란?

워크플로우 오케스트레이션은 독립적인 데이터 도구들을 하나의 파이프라인으로 통합하고, 실행 순서를 지시하며, 오류 로깅, 복잡한 로직 구현(병렬 실행, 반복), 자동 실행(스케줄 또는 이벤트 기반)을 통해 데이터 파이프라인을 강화하는 것을 의미함.

 

---

Kestra 란?

Kestra는 workflow orchestration을 위한 도구로,

Kestra는 데이터 소스에서 데이터를 추출하고 Python 스크립트에서 변환 후, 최종 데이터베이스에 로드하는 모든 과정을 조율하여 수동 작업 없이 데이터 흐름을 자동화하고 관리할 수 있도록 함.

 

Kestra의 장점

Kestra는 다음 장점들을 가지고 있음.

1. 오픈소스 플랫폼이므로 엔지니어가 코딩, 노코드, AI를 활용하여 비즈니스 워크플로우를 무한히 확장 가능하게 관리할 수 있도록 지원함.

2. 1000개 이상의 플로그인으로 postgeSQL, Google Cloud 등 다양한 도구에 연결할 수 있음.

3. 언어에 구애받지 않아 작업에 최적화된 언어(Go, C, Python 등)를 선택할 수 있음.

4. 스케줄 및 이벤트 기반 트리거를 통해 워크플로우를 데이터에 따라 유연하게 관리할 수 있음.

 

 

kestra 기본 개념

Flow를 중심으로 Task를 오케스트레이션하며, Inputs와 Variables로 유연성을 확보하고, Triggers와 Concurrency로 안정적인 자동 실행을 보장하는 툴임.

 

---

1. Flow

작업(Task)들과 그 실행 순서를 정의한 워크플로우 단위

• “무엇을, 어떤 순서로, 어떤 조건에서 실행할지”를 정의 (실행 순서, 조건 분기, 병렬 처리 제어)
• YAML 파일 하나 = 보통 Flow 하나

 

2. Task

Flow 안에서 실제로 실행되는 개별 작업 단위

• SQL 실행, Python 스크립트, API 호출, 파일 처리 등
• Flow 안에 여러 개 task 존재 가능

 

3. Inputs

Flow 실행 시 외부에서 주입되는 동적 파라미터

• Flow를 “하드코딩된 스크립트”가 아니라 재사용 가능한 템플릿으로 만들어 줌

 

4. Outputs

Task 실행 결과를 다음 Task 또는 Flow 외부로 전달하는 데이터

• Task 간 데이터 전달 메커니즘
• 파일, JSON, 숫자, 문자열 등 가능

 

5. Triggers

Flow 실행을 자동으로 시작시키는 메커니즘

• “언제 이 Flow를 실행할 것인가”를 정의
• 수동 실행 없이 자동화 가능

 

6. Execution

특정 시점에 Flow가 한 번 실행된 인스턴스

• Flow 정의 ≠ 실행
• Execution은 “실제 실행 기록 + 상태”

 

7. Variables

여러 Task/Flow에서 재사용 가능한 Key–Value 값

• 공통 설정값 관리용
• 코드 중복 제거

 

8. Plugin Defaults

1개 이상의 Flow 내 모든 Task 타입에 공통으로 적용되는 기본 설정

• 같은 플러그인 설정을 매번 쓰지 않게 해줌
• “전역 기본값” 개념

 

9.Concurrency

동시에 실행 가능한 Execution 수 제한

 

---

docker 에 Kestra 설치하기

Docker-compose.yaml 파일을 아래와 같이 작성하여, Kestra 컨테이너를 설치하여 사용할 수 있음.

...
기존 컨테이너
...

kestra_postgres:
    image: postgres:18
    volumes:
      - kestra_postgres_data:/var/lib/postgresql
    environment:
      POSTGRES_DB: kestra
      POSTGRES_USER: kestra
      POSTGRES_PASSWORD: k3str4
    healthcheck: # DB 준비 상태 확인 명령
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      interval: 30s  # 30초마다 헬스체크 실행
      timeout: 10s  # 헬스체크 타임아웃 10초
      retries: 10 # 최대 10번 재시도

  kestra:
    image: kestra/kestra:v1.1
    pull_policy: always # 항상 최신 이미지를 pull (캐시 무시)
    # Note that this setup with a root user is intended for development purpose.
    # Our base image runs without root, but the Docker Compose implementation needs root to access the Docker socket
    # To run Kestra in a rootless mode in production, see: https://kestra.io/docs/installation/podman-compose
    user: "root" # root 권한으로 실행 (Docker 소켓 접근 필요)
    command: server standalone # 독립 실행형 서버 모드로 시작
    volumes:
      - kestra_data:/app/storage
      - /var/run/docker.sock:/var/run/docker.sock # Docker-in-Docker 실행을 위한 소켓 마운트
      - /tmp/kestra-wd:/tmp/kestra-wd  # 작업 디렉토리 (임시 파일 저장)
    environment: 
      KESTRA_CONFIGURATION: |
        datasources:
          postgres:
            url: jdbc:postgresql://kestra_postgres:5432/kestra
            driverClassName: org.postgresql.Driver
            username: kestra
            password: k3str4
        kestra:
          server:
            basicAuth:
            username: "admin@kestra.io" # it must be a valid email address
              password: Admin1234!
          repository:  # 워크플로우 메타데이터 저장소 = PostgreSQL
            type: postgres
          storage:
            type: local
            local:
              basePath: "/app/storage"
          queue: # 작업 큐 저장소 = PostgreSQL
            type: postgres
          tasks:
            tmpDir: # 태스크 실행 시 임시 디렉토리
              path: /tmp/kestra-wd/tmp
          url: http://localhost:8080/  # Kestra 웹 UI 접속 URL
          
    ports:
      - "8080:8080"  # 웹 UI 포트 (브라우저에서 접속)
      - "8081:8081" # 관리/API 포트
      
    depends_on:
      kestra_postgres:
        condition: service_started # PostgreSQL이 시작된 후에 Kestra 실행

 

❓heathcheck는 왜 필요할까?

컨테이너가 살아 있는지가 아니라, 정상적으로 일할 수 있는 상태인지를 판단하기 위해서 필요함.

• kestra는 외부의존성이 많은 툴이기 때문에, 의존하고 있는 외부 요인들이 모두 정상인 상태여야, 워크플로우가 정상 작동할 수 있음.
• 다음과 같은 상황에 kestra가 오작동하는 경우를 방지하기 위해 heathcheck가 필요함.
  • DB는 아직 안 떴는데 Kestra 컨테이너만 먼저 올라온 경우
  • ..
• 상기 yaml 파일에선, postgres DB가 응답하지 않을 경우 최대 10번까지 retry할 수 있도록 설정함.

❓ 왜 server standalone으로 설정했을까?

• server standalone은 Kestra를 구동하는 데 필요한 모든 구성 요소(Web server, Executor, Scheduler, Worker..)를 단 하나의 프로세스(실행 단위) 안에서 모두 실행하겠다는 의미임.
• 따라서 데이터베이스(PostgreSQL 등)만 연결되어 있다면, 다른 복잡한 설정 없이 바로 Kestra의 모든 기능을 사용할 수 있음.
• 때문에 로컬 환경에서 워크플로우를 개발하거나 기능을 테스트할 때 가장 권장되는 방식임.

standalone 과 분산모드는 다음과 같은 차이점이 있음.

 

🔗 참고 링크

• https://kestra.io/docs/architecture/deployment-architecture

• docker socket은 Docker 엔진에 명령을 내리는, 일종의 명령 전달 창구.

 

❓ kestra는 왜 docker socket에 root 권한으로 접근해야할까

• kestra는 워크플로우 실행 시, Docker 컨테이너를 직접 생성하기 때문임.
• 즉, kestra에서 워크플로우 실행 시 Docker 컨테이너를 생성하기 위해,
  Docker 소켓에 명령을 전달해야하는데,
  Docker 소켓은 보안상 root만 접근 가능하도록 설정되어있기 때문에,
  Kestra에 root 권한을 부여해야 Docker로 워크플로우 실행이 가능함.

• 프로덕션 단계에서는 root권한을 부여하면 위험함. 컨테이너가 해킹되면 호스트 전체가 위험해지기 때문임. 강의 자료에선 프로덕션 단계에선 podman을 대안으로 사용하도록, 참고 주석을 달아놓음.