▲

Gleam OTP – 액터 기반 내결함성 멀티코어 프로그램 개발

 (github.com/gleam-lang)
1P by GN⁺ 3달전 | ★ favorite | 댓글 1개
  • Gleam OTP는 액터 모델을 활용하여 내결함성과 멀티코어 성능을 갖춘 프로그램 개발 지원
  • 완전한 타입 안전성과 Erlang OTP와의 호환성을 목표로 하는 것이 특징임
  • 슈퍼바이저를 통한 장애 복구 및 자기치유 기능 제공
  • Erlang/OTP의 일부 기능만 제공하며, 추가적인 관리 전략은 현재 개발 중임
  • 일반적인 프로세스, 액터, 슈퍼바이저 등 다양한 액터 타입을 지원함

Gleam OTP 개요

  • Gleam OTP는 Erlang의 OTP 아키텍처를 참고한 강력한 액터 프레임워크로, 내결함성 멀티코어 프로그램 구현에 적합함
  • 오픈소스 프로젝트로 Apache-2.0 라이선스를 적용받고 있음

주요 특징 및 장점

  • 액터와 메시지의 완전한 타입 안전성 보장
  • Erlang OTP와 호환성 제공, 기존 Erlang 환경과의 통합이 용이한 장점
  • 슈퍼바이저(supervisor) 를 통한 장애 감지, 자동 복구, 종료 관리 등 내결함성 지원
  • Erlang OTP에 준하는 동일한 성능을 추구함
  • 문서화와 예제 제공으로 실전 적용 및 학습이 쉬움

액터 타입별 설명

  • 프로세스(process)

    • OTP 내에서 가장 기본적인 빌딩 블록 역할
    • 다른 액터 타입의 기반이 되지만, Gleam 애플리케이션에서는 자주 직접 사용하지 않음

  • 액터(actor)

    • 대표적으로 사용하는 프로세스 타입이며, Erlang의 gen_server와 유사한 기능 제공
    • OTP 시스템 메시지 자동 처리, 디버깅 및 트레이싱 기능 활성화

  • 슈퍼바이저(supervisor)

    • 다른 프로세스를 시작하고 감독 및 복구를 담당함
    • 자식 프로세스가 충돌이나 예외 상황에서 자동으로 재시작
    • 슈퍼바이저의 중첩 구성(supervision tree) 을 통해 애플리케이션의 내결함성 구조 형성
    • gleam/otp/static_supervisor, gleam/otp/factory_supervisor 문서에서 세부 구현 확인 가능

한계 및 이슈

  • 현재 액터는 모든 OTP 시스템 메시지를 지원하지 않으며, 미지원 메시지는 무시 처리함
  • 일부 OTP 디버깅 API 기능이 제한적임
  • 필요시 issue 등록을 통해 미구현 메시지 지원 요청 가능

결론 및 프로젝트 중요성

  • Gleam OTP는 Erlang 생태계의 강점을 Gleam 언어로 확장, 타입 안전성과 멀티코어 내결함성을 구현할 수 있다는 점에서 큰 의의가 있음
  • 실서비스에서 안정성과 성능이 중요한 애플리케이션에 적합
  • 스타트업, IT 전문 개발자, 일반 개발자 모두에게 학습 및 실전 적용 가치가 높은 오픈소스 프로젝트임
▲
GN⁺ 3달전  [-]
Hacker News 의견
  • 나는 gleam/lustre로 작은 프로젝트를 시작했는데, 지금까지 정말 만족하고 있음
    정적 타입, null 없는 환경, 함수형, ML 계열 언어에 관심이 있다면 gleam을 시도해보길 추천함
    그리고 역시 BEAM에서 돌아감
    • 나도 같은 생각임
      gleam을 설치했더니 내 시스템에 패키지 50개 정도가 깔렸는데, 이게 아마도 Erlang/Elixir 관련 패키지인 듯함
      만약 JS로만 트랜스파일하고 싶으면 어떨까 궁금함. 아마도 내 시스템의 패키징 이슈일 수도 있음
      Lua를 트랜스파일 타겟으로 지원해주면 더 좋을 것 같음. 내 생각에 DSL을 다른 프로그램에 임베딩하려면 Lua가 JS 런타임보다 3배는 쉽다고 느낌
      무엇보다도 지금까지 가장 좋았던 점은 커뮤니티임. gleam 커뮤니티의 라이브러리나 자료 품질이 굉장히 높음
      Rust 커뮤니티가 떠오르는데, 어려운 문제들은 이미 똑똑한 사람이 다뤄서, 좋은 해결법이 잘 올라와 있음 (lustre, squirrel 등)
      실험과 창의적인 시도가 많이 보이는 것도 특징임. 큰 언어 생태계에서는 잘 안 보이던 것들이 여기서는 돋보임. 커뮤니티가 성장하면서 매우 환영하는 분위기임
    • 내가 말한 것들에 다 관심이 있음. 그런데 아직 BEAM이나 OTP는 제대로 이해하지 못함
      어디서부터 배우는 게 좋을지 추천 부탁함
    • 앞서 언급된 것 중 어느 것도 경험이 없는 입장에서, gleam/lustre와 elixir/phoenix 중 뭘 먼저 배우는 게 좋을지 궁금함
  • Gleam을 사용하는 분들 중에 Phoenix 같은 웹 프레임워크도 같이 쓰는지 궁금함
    Phoenix 같은 프레임워크랑 Gleam을 같이 쓸 수 있으면 정말 좋을 것 같아서 알아보는 중임
    현재는 Python으로 새 프로젝트를 준비하고 있는데, Gleam으로도 쓸 만한 옵션이 있으면 시도해보고 싶음
    • Lustre 개발자가 Gleam/Lustre로 LiveView와 비슷한 기능을 구현한 발표 영상이 있음
      프론트엔드/백엔드가 어떤 부분에 들어갈지 아주 쉽게 선택 가능하다는 점이 장점임
      유튜브 링크
    • Phoenix, Django, Rails 같은 완전한 프레임워크는 아직 없음
      대신에 웹앱을 만들 때 자주 쓰는 도구들이 있음
      Lustre는 기본적인 뷰 툴이고, Wisp는 서버 역할을 함
      SQL에는 squirrel과 POG(새롭지만 인기가 있음)가 있음
  • PureScript는 Erlang 백엔드를 지원하는 성숙한 함수형 프로그래밍 언어임
    BEAM 대비 다른 정적 타입 대안이 필요하다면 좋은 선택임
    Haskell의 방언과 같고, 엄격한 평가와 row polymorphism 지원함
    • PureScript의 JS 백엔드는 성숙하지만, Erlang 백엔드와 그 생태계는 Gleam에 비해 매우 작음
    • 공식 웹사이트와 github repo에는 PureScript가 JS로 컴파일된다고만 되어 있는데, Erlang 백엔드 관련해서는 어디서 들었는지 궁금함
  • Erlang/BEAM에 관심이 많은데 실제로 시도해볼 시간은 없었음
    실무에서 어떻게 쓰이고 있는지 궁금함. 모든 서비스 로직을 다 구축하는지, 아니면 특정 부분에만 사용하는지 궁금함
    • 나는 팀을 이끌면서 Gleam으로 점진적 마이그레이션을 하고 있음
      "functional core, imperative shell" 패턴을 극한까지 적용해 Gleam이 기존 Ruby on Rails 코드베이스에서 무거운 계산 작업을 다루도록 분리했음
      OTP 기능은 거의 안 쓰고 있고, Rails는 웹 UI/HTTP API와 같은 본연의 강점에만 집중하고 있음
      Rails가 잡(job)의 입력값 세팅을 담당하고, 잡 데이터는 Redis를 통해 Gleam으로 하나의 원자적 값 집합으로 전달됨
      Elixir로 얇은 래퍼를 만들어 네트워크, 파일 IO만 처리하고, 비즈니스 로직은 Gleam 모듈에서 담당함
      이 방법에 대해 기술적으로 더 자세히 정리해서 조만간 아티클로 쓸 생각임. HN에서 자주 관심 받는 주제임
    • 우리는 TV Labs에서 Elixir로 웹 서비스, 실시간 매칭 엔진, Lua 코드 샌드박싱, 바이너리 프로토콜로 마이크로컨트롤러와 통신, 머신러닝 등 다양한 일을 하고 있음
      Elixir는 범용적으로 훌륭한 언어이고, 여러 분야에서 강점을 가짐
      더 자세한 대화는 내 Developer Voices 영상 참고
      유튜브 링크
    • elixirforum.com에 와서 대화해보길 추천함
      많은 사람들이 Erlang/Elixir & BEAM만으로 진지하게 시스템을 구축하고 있으니 궁금한 점 물어보면 잘 답해줄 것임
    • 두 가지 방식 모두 봤음
      OTP를 충분히 이해하고 나면 모든 시스템을 그 위에 구축하는 게 자연스러움
      나도 7년간 그렇게 해왔는데, 신입 개발자가 이 생태계에 익숙해지는 데는 시간이 오래 걸림을 경험함
  • Gleam이 더 진지하게 받아들여지려면, 프로젝트 페이지에 강한 정치적 메시지를 적지 않는 게 더 좋을 거라 생각함
    기술 프로젝트 페이지에 굳이 정치 이야기를 넣을 필요를 모르겠음
    이건 동의 여부의 문제가 아니라, 전문적인 자리에서는 이런 논의는 빼는 게 더 바람직하다고 생각함
    그렇지 않으면 대화가 불필요하게 논점에서 벗어남
    • "Black lives matter. Trans rights are human rights. No nazi bullsh*t."
      이 한 줄이 페이지 아래쪽에 딱 한 번 등장하는 것을 말하는 것임?
      만약 이 문장 한 줄 때문에 사용하지 않기로 한다면, 애초에 의도한 대로 작동하는 것이라고 생각함
    • "대화가 불필요하게 논점에서 벗어난다"고 했는데
      오히려 본인이 그 논점을 벗어나게 만든 것이라는 생각임
  • 내가 보기엔 액터(actor) 모델은 프로세스 간에 정보를 공유해야 할 때 분산 컴퓨팅 문제가 생김
    내 기준에서 내결함성과 멀티코어를 위해선 Scala/ZIO처럼 소프트웨어 트랜잭셔널 메모리와 함수형 이펙트 시스템을 쓰는 게 더 낫다고 생각함
    아직도 액터 모델이 필요할 때는 쓸 수 있음
    게다가 JVM 생태계의 성숙도나 관찰성, 실전성을 볼 때 BEAM보다 뛰어남
    • 상당히 독특한 시각이라고 생각함
      BEAM의 단점에 대해 비판하는 건 이해하지만, 강점인 부분을 비판하는 것은 별로라고 느낌
      BEAM은 변경 불가능(immutable) 메시지를 가볍고 저렴한 그린 스레드들 사이에서 주고받는 구조임
      견고한 감시 체계(supervisor trees)가 있어서 데이터 레이스나 스레드 정지에 대해 걱정 없음
      이런 것들이 모두 기본 내장이라 보일러플레이트가 없음
      불변성 덕분에 성능도 의외로 좋음
      결국 BEAM은 내결함성, 분산/동시성 시스템에 가장 최적화된 플랫폼임
    • 언급이 안 되었던 부분이 있는데, Erlang(gleam의 기반)은 99.9999999%의 업타임을 실현한 언어임
      이런 내구성을 제공하는 큰 요소 중 하나가 robust supervising 및 크로스머신 인프라임
      액터 시스템 등장에 큰 영감을 준 언어임
      말 그대로 Erlang은 이 한 가지를 위해 존재하고, 정말 잘하고 있음
    • "액터 모델은 프로세스간 공유에 어려움이 있다"는 이야기를 했는데, 사실 액터 모델은 데이터를 복사하거나 메시지 전달로 소유권을 넘기는 방식임
      실제 공유가 필요한 데이터라면 그건 반드시 불변 데이터여야 함
    • 꼭 mutable 데이터를 immutable한 자료구조로 전달할 수 없는 상황의 예시를 들어줄 수 있는지 궁금함
      내가 생각해내는 건 극도로 하드한 수치계산뿐인데 그런 건 elixir나 erlang으로 직접 짜지 않고 NIF로 구현하면 됨
    • Elixir/Gleam/OTP에서는 프로그램이 모두 독립 프로세스들의 집합임
      액터 패턴을 명시적으로 쓰지 않더라도, 상태 전달이나 조정이 다 해결된 문제임
      태스크, 에이전트, GenServer, Supervisor 등 기본 프리미티브가 다 있음
답변달기