본문으로 건너뛰기
피드

LittleHorse 1.0 — 비즈니스 로직을 코드로 표현하는 마이크로서비스 오케스트레이션 엔진

backend 약 4분
vote
0
댓글
북마크

Apache Kafka 기반의 고성능 워크플로우 오케스트레이션 엔진 LittleHorse가 1.0을 출시함. 비즈니스 프로세스를 코드로 직접 표현하는 'Business-as-Code' 방식으로 마이크로서비스 간 조율, 재시도, 타임아웃, 분산 추적 등을 엔진 레벨에서 처리해줌.

  • 1

    Business-as-Code 접근 — 워크플로우 명세(WfSpec)를 코드로 작성해 비즈니스 프로세스와 1:1 매핑

  • 2

    Apache Kafka / Kafka Streams 위에 구축, 기존 Kafka 생태계와 연동 용이

  • 3

    재시도, 타임아웃, 이벤트 대기, 에러 핸들링, 조건 분기 등 내장 지원

  • 4

    Java, Go, Python, C#, JS 멀티 언어 SDK 제공

  • 5

    Docker 이미지 하나로 빠른 시작, 1.0부터 Semantic Versioning 적용

  • 6

    라이선스 GNU AGPL v3 — 상업적 활용 시 주의 필요

Apache Kafka 위에 올라간 고성능 워크플로우 엔진이 1.0을 찍었음. "Business-as-Code"라는 개념으로 비즈니스 프로세스를 코드로 직접 표현하는 방식을 밀고 있음.

  • 마이크로서비스 연결의 복잡함을 없애줌 — RPC 호출이나 메시지 큐로 서비스들 수동으로 엮는 작업, 재시도 로직, 타임아웃, 데드레터 큐 같은 것들을 엔진이 대신 처리해줌

  • 코드가 곧 비즈니스 프로세스 — WfSpec이라고 부르는 워크플로우 명세를 코드로 작성하면, 실제 비즈니스 흐름과 거의 1:1로 매핑됨. 예시에서 KYC(고객 신원 확인) 프로세스를 Java 코드로 표현하는데 꽤 직관적임

  • 내장된 기능들이 실용적임 — 변수에 .searchable(), .masked() 같은 속성 지정 가능, 이벤트 대기(waitForEvent)에 타임아웃 + 상관 ID 설정, 에러 핸들링, 조건 분기까지 한 곳에서 처리됨

  • Apache Kafka 기반 — Kafka와 Kafka Streams 위에 구축돼 있어서 기존 Kafka 생태계와 궁합이 좋음. 워크플로우 업데이트를 Kafka 토픽으로 실시간 수신하는 것도 지원

  • 멀티 언어 지원 — Java, Go, Python, C#, JS SDK 제공. 다만 JS SDK는 아직 WfSpec 생성을 지원 안 해서 lhctl로 우회해야 함

  • 시작이 간단함 — Docker 이미지 하나(lh-standalone)로 서버 + 대시보드 바로 띄울 수 있고, brew install lhctl로 CLI 설치, 120초 안에 첫 워크플로우 실행 가능하다고 함

  • 라이선스는 GNU AGPL v3 — 서버와 대시보드 코드 전부 AGPL. 상업적 활용 시 주의 필요함

  • 1.0 이후 Semantic Versioning 적용 — 이전까지는 버전 보장이 없었는데 이제부터는 공식 릴리즈 일정과 하위 호환 정책이 생김


Temporal이나 Conductor 같은 워크플로우 엔진과 비슷한 포지션인데, Kafka 네이티브라는 점이 차별점임. 이미 Kafka 인프라를 쓰고 있는 팀이라면 진입 장벽이 낮을 것 같음.

Temporal, Conductor 등과 같은 워크플로우 엔진 포지션이지만 Kafka 네이티브라는 점이 핵심 차별점. Kafka 인프라를 이미 운영 중인 팀에게 진입 장벽이 낮고, AGPL 라이선스라 엔터프라이즈 도입 시 라이선스 검토가 필요함.

댓글

댓글

댓글을 불러오는 중...

backend

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.