Hydro: Rust용 분산 프로그래밍 프레임워크

 (hydro.run)
1P by GN⁺ | ★ favorite | 댓글 1개

  • 소개

    • Hydro는 Rust를 위한 고수준 분산 프로그래밍 프레임워크임.
    • Hydro는 확장 가능한 분산 서비스를 빠르게 작성할 수 있도록 도와주며, Rust가 메모리 안전성을 보장하는 것처럼 분산 안전성을 보장함.
    • 테스트 모드나 배포 모드에서 분산 프로그램을 쉽게 실행할 수 있도록 지원함.

  • Hydro의 특징

    • Hydro는 고성능 단일 스레드 DFIR 런타임으로 구동되는 분산 데이터 흐름 언어임.
    • 전통적인 아키텍처인 액터나 RPC와 달리, 여러 위치에 걸쳐 계산을 설명할 수 있는 코레오그래픽 API를 제공함.
    • Hydro Deploy와 통합되어 로컬이나 클라우드에서 분산 Hydro 프로그램을 쉽게 배포하고 실행할 수 있음.

  • 컴파일 및 배포

    • Hydro는 두 단계의 컴파일 접근 방식을 사용함.
    • Hydro 프로그램은 표준 Rust 프로그램으로, 개발자의 노트북에서 _배포 계획_을 생성함.
    • 이 계획은 DFIR로 컴파일되어 분산 시스템의 각 기계에 대한 개별 바이너리를 생성함.
    • 생성된 계획과 클라우드 자원 사양을 사용하여 클라우드에 배포됨.

  • 활용 사례

    • Hydro는 2단계 커밋 및 Paxos와 같은 고성능 분산 시스템 구현에 사용됨.
    • 재사용 가능한 구성 요소로 이러한 프로토콜을 제공하는 분산 시스템 표준 라이브러리를 개발 중임.

  • 주의사항

    • Hydro의 문서는 아직 작업 중이며, 질문이나 버그가 있을 경우 Hydro GitHub 저장소에 이슈를 제기할 것을 권장함.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Hydro 프로젝트를 설명하는 좋은 YouTube 발표가 있음. 주로 DFIR에 초점을 맞춤
    https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

  • 실제로 어디에 적용하면 좋을지 이해하려면 현실적인 적용 예시가 더 필요해 보임

  • 중간에 자체 런타임을 가진 중간 언어가 있다면, Rust가 주는 장점을 잃는 건지 궁금함
    별도 Rust 바이너리들을 조율해서 일관되고 동작하는 분산 시스템으로 묶는 언어일 줄 알았는데, 접착제 수준이 아니라 처음부터 끝까지 DFIR로 작성하는 것처럼 보임

    • Hydro 작업을 이끄는 박사과정 학생 중 한 명임. DFIR는 중간 계층 DSL에 더 가깝고, 고수준 언어 개발자들이 Rust 코드를 벡터화 같은 저수준 최적화에 더 적합하게 재구성할 수 있게 해줌
      DFIR 연산자(map, filter 등)는 Rust 클로저를 받기 때문에, 고수준 언어에서 최종 Rust 바이너리까지 그대로 전달할 수 있음. 사용자 입장에서는 DFIR을 직접 다루지 않게 됨
    • 묻는 게 그거라면, DFIR은 Rust로 구현되어 있음

  • 정말 흥미로움. 이 분야를 아는 사람이 있다면 선행 연구나 비슷한 프레임워크가 다른 언어에 있었는지 알려주면 좋겠음
    데이터 흐름 쪽은 여러 사람이 작업해 왔고 Materialize가 꽤 멋지다고 생각했으며, 업무에서 Kafka Streams도 써봤음. 이걸 한데 엮는 프레임워크가 의미 있을 것 같다고 봄

    • 처음 보면 데이터 과학 쪽 작업들과 개념적으로 꽤 비슷해 보임. 문서에서도 언급하는 Spark나 Dask가 떠오름
      특히 Rust 기반이라 다른 언어와 잘 맞물릴 수 있다는 점이 강력해질 가능성이 있어 보임. Spark는 이식성 측면에서 JVM이 좋은 선택이지만 복잡성을 많이 가져오고, Dask는 Python에서 돌아가서 이미 Python을 쓰는 상황이 아니면 꽤 무거운 의존성임
      분산 Rust 쪽으로는 Lunatic도 봤는데 괜찮아 보였지만, Hydro가 지향하는 것보다는 좀 더 저수준으로 보였음
    • 액터 모델 기반이고 분산 시스템에 초점을 둔 Akka(https://getakka.net/, Java 버전보다 덜 엔터프라이즈 느낌)와, rx(https://reactivex.io/) 같은 반응형 라이브러리를 섞은 것처럼 보임
      그래서 https://doc.akka.io/libraries/akka-core/current/stream/index...가 가장 가까운 비교 대상일 수 있음
    • 이 프로젝트는 RISELab에서 나온 것임
      https://rise.cs.berkeley.edu/projects/
      데이터 처리와 분산 시스템 대부분은 이 연구실이 해온 연구와 어느 정도 연결점이 있음

  • 노력은 마음에 들지만, 언젠가 Rust 생태계에 akka.rs 같은 것이 들어오면 좋겠음

  • 데이터 흐름 관점에서 timely [0]와 어떻게 비교되는지 궁금함. 중간 표현에서 반복문 같은 제어 흐름을 표현할 수 있는지도 궁금함
    [0] https://github.com/TimelyDataflow/timely-dataflow

    • Flo 논문을 조금 읽어보니 Timely처럼 데이터 흐름 그래프를 기술하지만, Timely의 더 실행 중심적인 배경과 달리 의미론적 데이터 흐름 계열의 전통에서 나온 것으로 보임
      함수형 반응형 프로그래밍, 합성, 흐름의 흐름, 대수적 연산자, 증명 지향 쪽에 가까움. Timely와는 매우 다른 “진행” 개념을 가지며, 잠재적으로 무한한 스트리밍 입력에서도 합성이 생성적이도록 보장하는 데 초점을 둠
      사실 Flo에는 “적시성” 개념이 거의 없고 타임스탬프도 없음. Timely처럼 중첩 반복을 지원하지만 메커니즘은 매우 다름. 기본 대수는 극도로 비순환적이지만, 중첩 스트림/그래프 형식화가 반복을 가능하게 함
      논문은 DBSP와도 직접 비교하는데, 이해한 바로는 DBSP도 Timely/Naiad 계열임. 저자들은 Flo가 Flink, LVars, DBSP 같은 여러 유사 시스템을 위한 통합 의미론 프레임워크가 될 수 있다고 봄
      그래서 Flo 저자들은 Naiad/Timely를 잘 알고 있고 중첩 반복 그래프에서 영감을 받았지만, 그 외에는 많이 다르다고 봄
    • 최신 논문 [0]에서 Naiad(timely dataflow)를 몇 번 언급함. 예를 들어 “Naiad [34]의 ingress/egress 노드에서 영감을 받아, 중첩 스트림은 더 큰 스트림에서 나온 데이터 조각을 반복 처리하고 반복 간 상태 전달을 지원하는 중첩 데이터 흐름 그래프로 처리될 수 있다”고 함
      [0] https://hydro.run/papers/flo.pdf

  • 각 “프로세스”가 별도 바이너리로 배포된다면 아마 별도 프로세스로 실행된다는 뜻일 텐데, 그러면 오버헤드 증가 측면에서 문제가 있어 보임
    빠른 통신은 어떻게 달성하는지 궁금함. 빠른 공유 메모리 IPC 같은 메커니즘을 쓰는지?
    또 async와의 통합에 대한 내용도 보이지 않음. 좋든 싫든 네트워킹을 다루는 코드의 압도적 다수는 async로 옮겨갔고, 네트워킹이 필요한 많은 영역에서는 좋은 비동기 아닌 라이브러리를 찾기 어려움

    • “분산”이라면 완전히 별도 머신에 나뉘어 있다는 뜻으로 이해했음. 그렇다면 각 구성 요소가 독립 프로세스로 실행되는 게 필요함
    • 현재 Hydro는 네트워크 애플리케이션에 초점을 두고 있고, 병렬성의 대부분은 단일 머신 내부가 아니라 머신 간 병렬성에서 나옴
      그래서 단일 머신 병렬성을 원하면 추가 오버헤드가 좀 있음. 언급한 것처럼 공유 메모리를 통해 앞으로 꼭 해결하고 싶은 부분임
      지난주 POPL 2025에서 Hydro에 참여한 학부생이 async-await 코드 블록을 Hydro 데이터 흐름으로 자동 컴파일하는 컴파일러를 발표했음. 아직 작업 중이고 문서화되지 않았지만 여기서 볼 수 있음: https://github.com/hydro-project/HydraulicLift

  • 정말 멋져 보이고 몇 가지 사용 방식이 떠오름. 특히 배포 부분이 독특해 보임
    문서가 더 채워지길 기대하고 있고, 특히 핵심으로 보이는 Streams, Singletons, Optionals 부분이 궁금함

  • 프로그래밍 모델은 마음에 듦. 애플리케이션을 다시 작성할 때 네트워크 최적화도 수행하는지 궁금함
    네트워크 병목이나 혼잡 처리를 다루는지 알고 싶음

  • 데이터 파이프라인에 Ballista 같은 것을 쓰는 경우와 어떻게 비교되는지 궁금함
    Ballista는 Apache Arrow와 Apache Datafusion 위에 구축된 덕을 많이 봄

    • Hydro 만든 사람 중 한 명임. Ballista와 Arrow, Parquet 주변 생태계는 분석 쿼리 처리에 훨씬 더 초점을 두고 있고, Hydro는 쿼리 처리 세계의 개념을 분산 시스템 구현으로 가져오려는 것임
      목표는 SQL 쿼리를 실행하는 게 아니라, 분산 시스템 코드(예: 마이크로서비스 구현)를 SQL 쿼리처럼 다루는 것임. Arrow와 Parquet 통합도 로드맵에 들어 있음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.