▲

GN⁺: Windmill - 빠르게 셀프 호스팅 가능한 오픈소스 워크플로우 엔진

 (windmill.dev)
14P by neo 6달전 | favorite | 댓글 2개
  • Windmill이 Airflow, Prefect, Temporal 등 다른 워크플로우 엔진들과 비교하여 가장 빠른 자체 호스팅 가능한 오픈소스 워크플로우 엔진임을 벤치마크를 통해 입증
  • Windmill은 다양한 프로그래밍 언어를 지원하며, 복잡한 SDK나 배포 과정 없이 몇 분 만에 워크플로우를 구축하고 테스트할 수 있는 통합 개발 환경을 제공
  • Airflow/Prefect 는 하나의 런타임(Python)만 지원하지만, Windmill은 Python, Typescript, Go, Bash 를 지원하며 BigQuery, Snowflake, Mysql, Postgresql에 대한 직접 SQL 쿼리를 지원
  • Temporal과 비교할 때, Temporal은 작업 큐 관리에 특화되어 있으나, Windmill은 이벤트 대기(reactivity) 기능을 포함하여 내구성 있는 실행 엔진으로도 기능함

워크플로우 엔진과 작업 큐의 차이점

  • 작업 큐는 워크플로우 엔진의 핵심이며, 많은 개발자들이 자체 논리를 구축하여 워크플로우 엔진을 사용하지 않고 작업 큐를 활용함.
  • SQS, Kafka, Redis with RMSQ, Orban 등 다양한 큐 구현체가 이미 존재함
  • 많은 개발자들이 작업 큐 중심으로 자신의 로직을 구축해서 워크플로우 엔진과 비슷한 만족감을 느낌(자신만의 워크플로우 엔진을 만드는 것)

"All-Inclusive" 워크플로우 엔진이란 무엇인가

  • 워크플로우 엔진은 작업의 의존성 제약을 존중하며 작업을 완료하기 위해 분산 시스템에서 워크플로우를 조정
  • 워크플로우 엔진의 5가지 주요 이점:
    • 리소스 할당: 클러스터를 최대한 활용할 수 있으며 모든 작업을 서로 다른 리소스(CPU, 메모리, GPU)를 가진 서로 다른 작업자에게 할당하고 작업자의 전체 리소스를 작업에 사용할 수 있도록 보장할 수 있음
    • 병렬 처리: 워크플로의 제약 조건으로 인해 일부 단계를 병렬로 실행할 수 있는 경우(브랜치, 포루프), 워크플로우 엔진은 스레드뿐만 아니라 물리적으로 분리된 여러 워커에 해당 단계를 디스패치할 수 있음
    • 관찰 가능성: 모든 작업에는 고유 ID가 있으며 입력, 로그, 출력, 상태를 검사할 수 있는 등 개별적으로 관찰 가능
    • 내구성: 예기치 않은 이유로 기계가 멈추거나 부작용이 발생하면 워크플로를 다시 시작해야 함.
      • 워크플로는 예기치 않은 이벤트가 발생했을 때 최대한 빨리 재시작할 수 있어야 하며, 이를 달성하는 한 가지 방법은 한 번의 작업이 여러 번의 동일한 작업을 수행한 것과 동일한 효과를 내는 비동작성.
      • 확실하지 않은 경우 전체 흐름을 아무런 결과 없이 재생. 이는 일반적으로 작업에 첨부된 고유 ID가 로그의 일부인 경우 부작용을 건너뛰는 로그 파일과 SDK를 사용하여 구현됨.
      • 또 다른 방법은 흐름 상태의 트랜잭션 스냅샷을 생성하여 각 작업 후에 상태를 저장하는 것. 다시 시작하려면 마지막 상태를 다시 로드하고 거기서부터 실행하면 됨
      • Windmill은 후자를 사용하며, 사용자 영역에서 원할 때 비활성화를 구현할 수 있다고 가정
    • 반응성: 웹훅이나 승인과 같은 이벤트에 따라 다시 재개될 때까지 흐름을 일시 중단

Windmill의 빠른 속도의 비결

  • Windmill은 Postgresql과 Rust를 활용하여 간단한 설계와 최적화를 통해 효율성을 극대화함

시스템 설계 및 큐

  • Windmill은 Rust로 컴파일된 단일 바이너리를 제공하며, 작업자와 서버는 Postgresql에 연결되어 있지만 서로에게는 연결되어 있지 않음
  • Postgresql 자체에서 큐를 구현하고, 작업은 API를 통해 외부에서 트리거될 수 있음

상태

  • 워크플로우 엔진은 작업을 유한 상태 기계(FSM)로 표현하며, Windmill은 전체 흐름 자체를 FSM으로 처리함

데이터 전달

  • Windmill은 데이터 전달을 위해 자바스크립트 표현식, 임시 폴더 공유, S3 통합 등 다양한 방법을 제공

작업자 효율성

  • Windmill의 작업자는 한 번에 하나의 작업을 처리하며, 컨테이너 없이 작업을 실행하여 성능을 향상시킴

결론

  • Windmill은 Postgresql과 Rust를 기반으로 단순한 설계와 최적화를 통해 매우 빠른 속도를 제공하는 오픈소스이자 자체 호스팅 가능한 서버리스 런타임 및 플랫폼임

GN⁺의 의견

이 글에서 가장 중요한 점은 Windmill이 다양한 프로그래밍 언어를 지원하고, 복잡한 SDK나 배포 과정 없이 빠르게 워크플로우를 구축하고 테스트할 수 있는 통합 개발 환경을 제공한다는 것이다. 이러한 특징은 소프트웨어 개발자들에게 매우 유용하며, Windmill의 빠른 성능과 효율성은 개발자들이 더 나은 제품을 더 빠르게 출시하는 데 도움이 될 것이다. 이 글은 개발자들에게 흥미로운 내용을 담고 있으며, 특히 자체 워크플로우 엔진을 구축하거나 기존 엔진을 최적화하려는 이들에게 매력적일 것이다.

▲
xguru 6달전  [-]

Windmill - 파이썬 기반 회사 내부용 앱 작성 및 자동화 플랫폼 오픈소스

작년 5월에 살짝 공개가 되었는데, 개발자가 아직 공개할 준비가 안되었다면서 10분후 YC 인터뷰 볼꺼에요! 하더니.. YC 통과 했다고 댓글을 적었는데요.
YC통과하고 1년반 달리고 나서 정식으로 제품을 런칭 한거네요.

답변달기
▲
neo 6달전  [-]
Hacker News 의견
  • Windmill 개발자들은 "한 가지 일을 잘하라"는 조언을 정반대로 실행한 것 같음. Windmill.dev를 봐도 소프트웨어가 무엇에 쓰이는지 명확하지 않음. Retool, Airflow, Temporal의 경쟁자인지, 노코드 워크플로우 빌더인지, 드래그 앤 드롭 UI 빌더인지, 온라인 IDE인지, 수많은 통합 기능이 있는지 혼란스러움.
  • 워크플로우 엔진의 속도가 일정 수준을 넘어서 중요한지 의문. 많은 워크플로우가 장기 실행 작업을 포함하기 때문에, 중요한 것은 멀티 테넌시, 즉 사용자가 원하는 만큼의 작업을 지원하면서 각 작업이 워크플로우 엔진에서 유일한 것처럼 예약되고 실행되는 능력임.
  • 비즈니스 프로세스를 스프레드시트, 개인 이메일, 관리자의 기억에서 웹 폼, 업로드, 자동화된 이메일, 대시보드로 옮기고 싶음. Airtable, Smartsheet, Budibase 등을 살펴봤지만, 프로젝트 관리에 더 초점을 맞춘 것 같고 캘린더 통합이나 이메일, 예약된 스크립트에 대해서는 만족스럽지 않음. 데이터에 대한 API가 있거나 필요하다면 코딩할 수 있으며, 관리자가 스프레드시트 뷰를 가지고 UI 작업을 일부 할 수 있고 프로그래머가 통합을 처리할 수 있는 로우코드 접근 방식을 선호함.
  • 사람들이 이렇게 많은 시간과 노력을 기울여 글을 쓰고도 맞춤법 검사기를 한 번도 사용하지 않는 것에 놀람. 2023년에도 기본적으로 맞춤법 검사를 하지 않는 텍스트 에디터를 사용하는 사람들이 있는지 궁금함.
  • 오픈소스라고 하면서 SSO 사용자 10명 제한이 있다는 것이 혼란스러움. 오픈소스는 일반적으로 코드 수정을 허용하지만, 어떻게 10명의 제한을 집행하는지 의문. 소스 코드를 살펴보니 라이선스 체크 코드가 있음. 오픈소스라면 누구나 그 코드를 제거할 수 있지 않을까? 수정이 불가능하다면 그것은 "소스가 공개된" 것이지 "오픈소스"는 아님. 프로젝트가 멋져 보여서 상사에게 제안하고 싶었지만, 이 부분을 어떻게 설명해야 할지 모르겠음.
  • Windmill을 HN 런칭 때부터 팔로우했고, 1년 미만 전부터 더 많이 사용하기 시작함. Discord 서버가 매우 활발하고 Ruben이 주말에도 몇 분 안에 답변하고 버그를 수정함.
  • Windmill 시스템을 사용하고 싶지만, 라이선스 문제로 망설임. 대부분의 소프트웨어는 AGPLv3 하에 있지만, README의 상업 라이선스 섹션은 AGPL에 대한 광범위한 해석을 시사함. Windmill을 통해 기능을 구축하려면 제품도 AGPLv3이어야 한다는 것은, 심지어 API를 통한 호출만으로도 저작권법이 적용될 수 있다는 것을 의미함. 이는 Windmill을 "완전히 오픈소스"로 포지셔닝하는 것이 기술적으로는 맞지만 실제로는 "소스가 공개된" 것에 더 가까움. Windmill이 라이선스를 이렇게 해석하기를 원하지 않는다면 명확히 해야 함.
  • Windmill은 훌륭함. 자체 호스팅 가능하고 개발자 경험(Developer Experience, DX)에 충실해야 함. 직장에서는 사용할 필요가 없었지만, 집에서 작은 웹 크롤러와 yt-dlp 작업을 실행하는 데 사용함. 매우 재미있는 도구임.
  • 라이선스에 대해 혼란스러움.
  • 데이터베이스에 코드를 저장하고 웹 IDE를 통해 편집하는 것과 깃(Git)에 코드를 체크인하고 일반 개발 및 피어 리뷰 과정을 통해서만 변경하는 것 사이의 균형을 찾는 방법을 아직 찾지 못함. Windmill은 주로 데이터베이스에 코드를 저장하지만 깃 리포지토리에서 동기화할 수 있는 API를 제공함. 특정 스크립트/기능/비밀을 제공된 리포지토리에서 가져온 워크플로우에만 제한하는 규칙을 강제할 수 있는 메커니즘이 있는지 궁금함.
답변달기