Fly Machines로 사용자별 개발 환경 만들기

원문 보기 위키 갱신 2026.10.08

Fly Machines는 간단한 API 뒤에서 빠르게 실행되는 VM이에요. 이 가이드에서는 Fly Machines를 사용해 사용자(또는 로봇)별로 안전하고 격리된 임시 개발·실행 환경을 호스팅하는 방법을 설명해요. fly-replay를 활용한 동적 서브도메인 라우팅까지 함께 다뤄요.

출처: 문서

본문

개요 (Overview)

Fly Machines는 간단한 API 뒤에서 빠르게 실행되는 VM으로, 전 세계 어디서나 밀접하게 격리된 앱 인스턴스를 밀리초 단위로 실행할 수 있게 해 줘요.

재미있는 사용 사례가 하나 있어요. 사용자(또는 로봇)를 위한 격리된 개발 환경을 실행하는 거예요. Fly Machines는 아무리 위험해 보이는 사용자 생성(또는 LLM 생성) 코드라도 안전하게 실행할 수 있는 샌드박스예요.

이 가이드는 fly-replay를 사용한 동적 서브도메인 라우팅으로 임시 개발·실행 환경을 안전하게 호스팅하는 방법을 설명해요.

아키텍처에 포함해야 할 것

라우터 앱 (Router app(s))
- 와일드카드 서브도메인(*.example.com)에 대한 요청을 처리하는 Fly.io 앱이에요. fly-replay 헤더를 사용해 각 요청을 올바른 앱과 머신으로 투명하게 리다이렉트해요. 사용자(또는 로봇) 클러스터가 여러 지리적 리전에 있다면 여러 리전에 라우터 앱을 만들 수 있어요. 라우팅 패턴 구현 방법은 사용자 Machine에 연결하기를 참고하세요.
사용자 앱 (사전 생성)
- 사용자(또는 로봇)별 전용 Fly 앱(고객/로봇별 전용 앱을 만들어야 하는 이유에 대해 더 알아보세요). 각 앱에는 격리된 Fly Machines가 들어 있어요. 앱과 Machine 생성은 즉시 되지 않으므로, 필요해지기 전에 이 풀(pool)을 미리 프로비저닝해 두고 요청이 오면 빠르게 할당하는 것을 권장해요.
Fly Machines (선택적으로 볼륨 포함)
- 영구 Fly 볼륨에 연결할 수 있는 빠른 실행 VM이에요.

아키텍처 다이어그램 예시

다이어그램은 라우터 앱이 볼륨이 있는 Fly Machines를 담은 사용자 앱으로 트래픽을 보내는 모습을 보여줘요.

라우터 앱

라우터 앱은 모든 수신 와일드카드 트래픽을 처리해요. 그 책임은 단순해요:

서브도메인 추출(alice.example.com → alice-123 같은 것)
해당 사용자에 대한 올바른 앱(선택적으로 machine ID) 조회
Fly Proxy가 요청을 내부적으로 리다이렉트하도록 fly-replay 헤더 발행(라우터 앱이 사용자와 가까운 곳에 배포되어 있다면 지연 시간이 ~10밀리초 이하로 늘어나야 해요)
적절할 때 리플레이 캐싱을 사용해 지연 시간과 라우터 앱 부하 추가로 줄이기
라우터 앱에 와일드카드 도메인(*.example.com)을 추가했는지 확인(자세한 내용은 Certificates API 참조 참고)

사용자 앱

요청 시점에 각 사용자에 대해 앱을 동적으로 만드는 것은 느릴 수 있어요. 빠른 프로비저닝을 보장하려면:

미리 생성해 두세요. ( Fly Machines API 또는 CLI 사용) Fly 앱과 머신 풀을 넉넉히 만들어 두세요.
앱 세부 정보(예: app\_name: alice-123)를 라우터 앱이 접근할 수 있는 데이터 저장소에 저장하세요.
프로비저닝 시점에 사용자에게 앱을 할당하세요.

Fly Machines

사용자 앱마다 Machine을 하나 이상 실행하는 것이 좋아요(앱에는 필요한 만큼 Machine을 둘 수 있어요). 개발 환경에 영구 저장소(Machine 재시작 후에도 유지돼야 하는 데이터)가 필요하다면:

각 머신을 만들 때 Fly 볼륨을 연결하세요.
머신 재시작 시 임시 파일 시스템 상태는 사라지지만 볼륨 데이터는 유지된다는 점을 기억하세요.
Machines API 리소스와 Volumes API 리소스에 대해 더 알아보세요.

포인터 & 함정 (Pointers & Footguns)

Machine과 볼륨은 물리 하드웨어에 묶여 있어요: 하드웨어 장애가 Machine과 연결된 볼륨을 파괴할 수 있어요. 중요한 사용자 데이터(코드, 설정, 출력물)는 항상 외부 저장소(Tigris Data 또는 AWS S3 같은 곳)에 영구 저장하세요.
사용자는 자신의 환경을 망가뜨릴 거예요: 하드웨어·런타임 장애나 필연적인 사용자/로봇 환경 오염을 처리하려면 대기(standby) 머신을 미리 만들어 두세요. 이런 시나리오에서 빠르게 활성화할 수 있는 대기 머신을 미리 프로비저닝하세요.
Machine 재시작은 임시 파일 시스템을 초기화해요: 임시 Fly Machine 파일 시스템 상태는 Machine 재시작 시 초기화되어 깨끗한 환경을 보장해요. 하지만 볼륨 데이터는 유지되므로 사용자 진행 상황이나 상태를 보존하는 데 유용해요.
사용자당 앱 하나: 모든 사용자 Machine을 단일 앱에 넣고 동적 라우팅으로 라우팅하는 것은 동작해요. 하지만 규모가 커지면 auto_stop이 예상대로 동작하지 않아요. Fly Proxy의 중지 루프에는 속도 제한이 있어요. 각 패스마다 리전당 Machine을 최대 하나 중지/일시중단하며, 몇 분마다 실행돼요. /reference/fly-proxy-autostop-autostart#fly-proxy-process-to-stop-or-suspend-machines 이것은 일반 앱에는 문제없어요. 하지만 수천 개의 Machine이 있으면 루프가 따라잡을 수 없어 대부분의 유휴 Machine이 계속 실행돼요. 단일 앱의 Machine은 또한 앱 수준 시크릿과 플랫(flat)한 프라이빗 네트워크를 공유해요. 손상된 사용자 환경이 앱의 다른 모든 Machine에 접근할 수 있게 되죠. 모든 사용자 Machine을 하나의 앱에 두기로 했다면, 앱이나 오케스트레이터에서 유휴 시 중지 동작을 구현하세요(유휴 시 종료되는 앱 참고). 대부분의 Machine을 중지된 상태로 유지하는 것은 Fly Proxy에 기대지 마세요.

더 알아보기 (Learn more)

사용자 Machine에 연결하기 — 개별 사용자에게 전용 머신 팔레트(fleet)를 만들 때 라우팅과 네트워킹을 관리하는 방법.
멀티 컨테이너 Machines — 사용자별 환경에서 메인 서비스 옆에 사이드카(로그, 메트릭 내보내기, 에이전트 프로세스)가 필요할 때.