▲

GN⁺: 서버리스를 재고하다: FLAME 기술

 (fly.io)
3P by neo 5달전 | favorite | 댓글 1개

FLAME 패턴: 애플리케이션의 탄력적인 확장을 위한 새로운 접근법

  • 서버리스/FaaS(Function as a Service)는 탄력적인 확장과 사용량 기반 비용 지불이라는 장점을 제공하지만, 실제로는 더 많은 복잡성을 초래함.
  • 기존 앱 코드를 함수로 감싸서 임시 앱 복사본에서 실행할 수 있다면 자동 확장이 가능해질 것임.
  • FLAME(Fleeting Lambda Application for Modular Execution) 패턴은 전체 애플리케이션을 람다처럼 취급하여 모듈식 부분을 단기간 인프라에서 실행함.

FLAME 패턴

  • FLAME 패턴은 서버 관리 없이, 앱 코드의 특정 부분에 대한 수요 기반의 세밀한 탄력적 확장을 원함.
  • 기존 애플리케이션을 다시 작성하거나 독점 런타임에서 부분적으로 작성할 필요가 없음.
  • Elixir의 flame 라이브러리는 FLAME 패턴을 구현하며, Fly.io 백엔드 어댑터를 포함하지만, 앱 코드를 실행할 수 있는 API를 제공하는 모든 클라우드에서 사용 가능함.

FLAME 백엔드

  • Fly.io 인프라에서 FLAME.FlyBackend는 새로운 Machine을 부팅하여 약 3초 내에 부모 작업에 연결할 수 있음.
  • FLAME은 LocalBackend와 FlyBackend를 기본으로 제공하지만, 서버를 프로비저닝하고 앱 코드를 실행할 수 있는 API를 제공하는 모든 호스트가 FLAME 백엔드로 작동할 수 있음.
  • Fly.io는 애플리케이션을 도커 이미지로 패키징하여 실행하기 때문에, 동일한 이미지로 새로운 Machine을 부팅하기만 하면 됨.

FLAME 외부의 Elixir

  • Elixir는 프로세스 감독과 분산 메시징과 같은 기능을 무료로 제공하기 때문에 FLAME 모델에 매우 적합함.
  • 언어가 합리적인 동시성 기본 요소를 가지고 있다면, 이 패턴을 활용할 수 있음.
  • JavaScript 애플리케이션에서도 FLAME 패턴을 구현할 수 있는 예제가 있으며, 모듈식 실행을 새 파일로 이동하여 실행함.

배경 작업 프로세서에 대해

  • FLAME은 배경 작업 프로세서 내에서 잘 작동하지만, 작업 라이브러리가 작업 풀을 확장하는 것과는 별개의 문제임.
  • 내구성을 보장하는 작업과 탄력적 실행을 분리하는 것이 중요함.

탄력적 확장을 위한 풀링

  • Elixir의 FLAME 구현을 통해 탄력적 풀의 러너를 정의할 수 있으며, 이를 통해 제로로 확장하고 최대 동시성 한계를 가진 FLAME 서버를 탄력적으로 확장할 수 있음.

프로세스 배치

  • Elixir에서 상태를 가진 애플리케이션 부분은 프로세스 기본 요소를 중심으로 구축되며, FLAME.call이나 FLAME.cast로 감싸진 상태로 잘 작동함.

원격 모니터링

  • 부모가 러너를 스핀업할 때, 러너는 작업이 없을 때 자체적으로 아이들링을 관리하고 부모 노드와의 연결이 끊어지면 안전하게 종료되도록 해야 함.

GN⁺의 의견

이 글에서 가장 중요한 것은 FLAME 패턴이 기존의 서버리스/FaaS 접근법의 복잡성을 줄이면서 애플리케이션의 탄력적 확장을 단순화할 수 있다는 점입니다. 이 패턴은 개발자들이 기존 코드를 크게 변경하지 않고도 필요한 부분만 빠르게 확장할 수 있게 해주며, 이는 클라우드 인프라를 사용하는 많은 소프트웨어 엔지니어들에게 매력적인 솔루션이 될 수 있습니다. FLAME 패턴은 특히 Elixir와 같은 언어에서 강력한 도구가 될 수 있으며, 다른 언어로의 구현 가능성도 탐색되고 있어 다양한 개발 환경에서의 적용을 기대하게 합니다.

▲
neo 5달전  [-]
Hacker News 의견

  • 100개 이상의 람다 함수로 구성된 애플리케이션을 4년간 다루며 겪은 고통과 복잡성에 대해 이 글이 서버리스 FaaS 아키텍처의 단점을 잘 지적함.

    • 초기에는 이러한 단점이 눈에 띄지 않으며, 사용량이 적을 때 무료이고 유지보수가 거의 필요 없는 등의 분명한 장점이 있음.
    • 하지만 시간이 지나면서 상호 의존성으로 인해 점점 더 경직된 람다 워크플로우의 혼란을 겪고, 자체 관리하는 모놀리식 접근 방식을 선택하고 약간의 추가 비용을 지불하는 것이 나았을 것이라는 생각이 듦.

  • 글의 저자로서, FLAME 패턴을 자바스크립트, Go 등 다른 언어로 구현하려는 사람들에게 흥미를 불러일으키기를 바라며, 질문에 답변할 준비가 되어 있음.

  • PiCloud 서비스는 작업을 투명하게 워커에게 전달하는 모델을 사용했었고, 이는 Elixir가 아닌 다른 언어에서도 유사하게 적용될 수 있음을 시사함.

  • FLAME을 사용하면 기존 앱 코드를 함수로 감싸서 임시 앱 복사본에서 실행할 수 있으며, 이는 서버리스 환경에서 프로세스를 분기하는 것과 유사함.

  • Windmill.dev는 소스 코드 수준에서 추상화 단위를 고려하며, 주요 함수와 임포트를 파싱하여 인수와 의존성을 추출하고 원하는 런타임에서 코드를 실행함.

  • FLAME을 사용하면 개발 및 테스트 러너가 로컬 백엔드에서 실행되므로 서버리스 환경에서 좋은 로컬 개발 경험을 제공함.

  • "Flame.call"을 사용할 때마다 새로운 앱 프로세스를 시작하고 실행 컨텍스트를 복사하는데, 이는 스케일링에 간단한 해결책이지만 앱 시작 시간에 추가되는 지연과 메모리 사용에 대한 고려가 필요함.

  • 해커뉴스의 헤드라인 대문자 사용에 대한 비판과 함께, 서버리스 원칙이 아닌 serverless.com 회사의 재고에 대한 희망을 표현함.

  • Inngest.com은 기존 코드를 서버리스 함수로 사용할 수 있게 하는 것과 유사한 방식을 제공하며, 코드의 상태를 외부에서 관리하고, 모니터링 및 관찰 가능성의 중요성을 강조함.

  • "Long Lambda"라는 시스템을 만들어 람다가 15분 이상 실행될 수 있다면 모든 작업을 람다에서 처리할 수 있으며, 로컬에서 실행 및 디버깅이 가능함.

이 요약은 각 댓글의 주요 내용을 간결하게 전달하며, 초급 소프트웨어 엔지니어가 이해하기 쉬운 수준으로 작성되었습니다. 배경 지식이 필요한 부분은 최소한으로 설명하였으며, 중립적인 태도를 유지하고 주제에서 벗어나지 않았습니다.

답변달기