Javascript

2024년에 Remix 앱을 위한 최적의 호스팅 옵션 가이드

드리프트2 2024. 6. 6. 09:08

Remix는 많은 다른 호스팅 옵션을 지원합니다.

 

이 가이드는 당신의 앱에 적합한 호스팅을 선택하는 데 도움이 될 것입니다.

추천사항

이 가이드는 당신을 특정 제공 업체로 유도하려는 것이 아니라, 정보에 입각한 결정을 내릴 수 있도록 필요한 정보를 제공하는 것을 목적으로 합니다.

 

그럼에도 불구하고, 대부분의 사람들에게 가장 좋은 아키텍처는 관리되는 컨테이너에서 Remix를 운영하면서 앱 내에서 백엔드-프론트엔드 패턴을 사용하고, 필요할 때마다 서버리스 함수를 호출하는 것이라고 믿습니다.

 

당신의 앱 서버와 데이터베이스를 가능한 한 가까이 유지하는 것을 매우 선호해야 합니다.

 

이것은 아마 단일 가장 중요한 성능 요소일 것입니다.

 

Vercel에서 앱을 호스팅하고 각 로더와 액션이 다른 곳에 호스팅된 API 서버를 호출하게 되면, 앱의 성능을 심각하게 저하시킬 것입니다.

서버리스 함수(Serverless Functions)

서버리스 함수는 요청 시에 시작되고 중단되는 애플리케이션 코드를 관리하는 호스팅 형태입니다.

 

때로는 전체 애플리케이션이 하나의 함수에 맞을 수 있으며, 또는 앱이 여러 개로 분산되어 각 엔드포인트가 자체 함수가 될 수 있습니다.

 

요청 수, 함수가 실행되는 시간, 함수가 사용하는 메모리 양에 의해 종종 요금이 청구됩니다.


대량의 트래픽을 처리할 수 있도록 확장 가능하며, 트래픽이 정상 수준으로 돌아오면 다시 축소할 수 있습니다.


일반적으로 데이터센터에서 실행되지만, 일부는 엣지 네트워크에서 실행되어 전 세계 데이터센터에서, 최종 사용자에게 가까운 곳에서 실행됩니다.


Node.js에서 자주 실행되지만, "엣지" 함수는 매우 빠르지만 지원이 덜 된 V8 런타임에서 실행됩니다.


이러한 함수의 일시적인 특성 때문에, 함수에 대한 첫 번째 요청은 콜드 스타트를 일으키고 응답하기까지 몇 초가 걸릴 수 있습니다.

 

이러한 모든 플랫폼은 Remix SPA 모드와 같이 정적 호스팅도 지원합니다.

  Vercel Fastly Netlify Cloudflare SST
런타임 Node/V8 (경로별) WASM Node/V8 V8 Node
Remix Vite
Git 기반 배포 아니오 Seed와 함께
배포 미리보기 아니오 Seed와 함께
웹소켓 아니오 아니오
번들 크기 50MB 100MB 50MB 25MB 50MB
요청 본문 크기 4.5MB 무제한 3MB (엣지 ♾️) 100MB 6MB
이미지 CDN
공간 데이터베이스 Postgres, KV, Blob KV Blob SQL, KV, Blob
SPA 모드

Long-lived servers

애플리케이션 호스팅에 대한 더 전통적인 접근 방식은 애플리케이션을 장기 실행 서버에서 운영하는 것입니다.

 

서버(또는 여러 서버)는 계속 실행되어 들어오는 요청을 처리합니다.

  • 콜드 스타트 시간이 없으므로 첫 번째 요청이 다른 요청만큼 빠릅니다.
  • 저 트래픽 시 서버리스보다 비용이 더 많이 들 수 있습니다.
  • 동일한 서버에서 데이터베이스를 운영할 수 있으므로 네트워크 지연에 대해 걱정할 필요가 없습니다.
  • 이러한 플랫폼 대부분은 관리되는 Redis 및 Postgres 데이터베이스를 배포하는 것도 지원합니다.
  • 파일 시스템에 완전히 접근할 수 있고, 자식 프로세스를 생성하고, 응답을 스트리밍하고, 지연된 데이터, 서버에서 보내는 이벤트, 앱과 병행하여 웹소켓 서버를 운영하는 등 더 많은 작업을 할 수 있습니다.
  Fly Render Railway DigitalOcean
Git 기반 배포 FlyCD와 함께
미리보기 환경 FlyCD와 함께 아니오 아니오
스테이징 환경 아니오 예 아니오    
정적 자산 CDN 아니오 아니오
다중 지역 배포 아니오 아니오 아니오

Vercel

Vercel은 웹 앱을 위한 서버리스 호스팅 플랫폼입니다.

 

Git 기반 배포와 모든 브랜치 및 풀 리퀘스트에 대한 배포 미리보기를 지원하며, 그 위에 구축된 일부 멋진 협업 도구도 지원합니다.

 

Vercel을 사용하면 페이지별로 Node 런타임이나 V8 Edge 런타임을 사용할지 지정할 수 있어, 일부 페이지에는 Node 함수를 사용하고 다른 페이지에는 V8 함수를 사용할 수 있습니다.

 

기본적으로 edge 함수를 사용하고 필요에 따라 Node 함수를 사용하는 것이 좋습니다.

 

Vercel은 각 엔드포인트를 자체 함수로 분리하기 때문에 각 함수 번들에 대한 50MB 제한을 초과하기가 매우 어렵습니다.

 

Vercel은 웹소켓을 지원하지 않으며, 스트리밍을 지원하지만 연결은 최대 30초 동안만 열릴 수 있으므로 서버에서 보내는 이벤트를 실용적으로 사용하기 어렵습니다.


stale-while-revalidate 및 stale-if-error를 포함한 전체 캐시 제어 지원, 그리고 s-maxage 속성을 지원합니다. s-maxage 속성은 CDN 캐시를 제어하고, max-age 속성은 클라이언트의 브라우저 캐시를 제어합니다.


Vercel의 최대 요청 본문 크기는 4.5MB로, 직접 파일 업로드에 문제가 될 수 있습니다.


Vercel은 여러 공간 데이터베이스를 지원하며, 여기에는 Vercel Postgres, Vercel KV, Vercel Blob이 포함됩니다.

Fastly

Fastly는 강력한 CDN 및 호스팅 플랫폼이며, Remix + React Router 문서의 호스팅 제공 업체로 선정되었습니다.

 

Fastly는 Compute@Edge 플랫폼으로 Remix를 지원합니다. 이는 엣지에서 실행되는 서버리스 플랫폼으로, Typescript를 WebAssembly로 컴파일합니다. 대부분의 엣지 함수처럼 V8이 아니라 Node처럼 실행되지 않습니다.

 

Fastly는 stale-while-revalidate 및 stale-if-error를 포함한 전체 캐시 제어 헤더를 지원합니다.

 

더 많은 제어를 위해 CDN 특정 설정을 위한 Surrogate-Control 헤더를 제공합니다.

 

또한 캐시를 프로그래밍 방식으로 삭제할 수 있는 API를 제공하는데, 이는 서버리스 플랫폼에서는 흔하지 않습니다.

 

웹소켓을 지원하는 Fastly는 서버리스 플랫폼에서는 드문 경우입니다.

 

Node를 실행하지 않기 때문에 많은 Node 모듈이 Fastly의 Remix와 호환되지 않습니다.

 

대신, 현재 가능한 가장 빠른 런타임을 얻게 됩니다.


Fastly는 컴파일 후 WASM으로 측정되고 모든 컴파일러 최적화가 적용된 후에 측정된 100MB 컴파일된 번들 크기 제한을 지원합니다.


Git 기반 배포는 지원하지 않지만, GitHub Actions에서 쉽게 배포할 수 있습니다.


Fastly는 앱과 함께 배포된 KV 저장소를 지원합니다.

Netlify

Netlify는 원래 JAMStack 호스팅 플랫폼으로, 간단한 정적 사이트 호스트에서 전체 기능을 갖춘 서버리스 플랫폼으로 성장했습니다.

 

내장된 Git 기반 배포를 통해 Git 저장소에 푸시할 때마다 Netlify가 앱을 빌드하고 배포합니다. 또한, 풀 리퀘스트를 병합하기 전에 앱을 테스트할 수 있는 배포 미리보기를 사용할 수 있습니다.

 

Netlify는 별도의 대상으로 Node(Netlify 함수)와 V8(Netlify Edge 함수) 런타임을 모두 지원하여, 전체 앱이 하나 또는 다른 하나에서 실행됩니다.

 

Node에서는 함수가 배포되는 지역을 선택할 수 있지만, 한 번에 여러 지역에 배포할 수는 없습니다.

 

Edge 함수는 항상 다중 지역입니다.

 

Netlify의 Edge 함수는 또한 서버에서 보내는 이벤트를 지원합니다.

 

Netlify는 몇 가지 방법으로 세밀한 캐시 제어를 지원합니다.

  • 특정 페이지 또는 자산을 무효화하는 데 사용할 수 있는 Cache-Tag 헤더
  • 장치 유형 또는 특정 쿠키 값(예: 사용자 세션 또는 A/B 테스트) 등 특정 헤더에 대한 캐시 정책을 다양하게 할 수 있는 Netlify-Vary 헤더.
  • 공간 파일 저장소를 위한 Blob 저장소도 지원합니다.

Cloudflare

Cloudflare Pages는 Netlify 또는 Vercel과 같은 호스팅 서비스이지만, Cloudflare의 네트워크 위에 구축되었습니다.

 

Git 기반 배포 워크플로와 다른 브랜치에 대한 미리보기 배포를 받게 됩니다.

 

정적 콘텐츠는 Cloudflare의 CDN에서 호스팅되며, 나머지 Remix 앱은 엣지에서 단일 Cloudflare 작업자로 컴파일됩니다.

 

Vercel의 엣지 함수는 Cloudflare 작업자 위에 구축되며, V8 런타임을 사용하므로 많은 Node 모듈과 호환되지 않습니다.

 

Cloudflare는 CDN 특정 캐시 설정을 위한 추가 CDN-Cache-Control 헤더를 지원합니다.

 

Cloudflare는 대부분의 앱에 대해 100MB의 요청 본문 크기를 지원하지만, 더 많은 용량이 필요한 경우 제한 증가를 요청할 수 있습니다.

 

이는 다른 어떤 서버리스 플랫폼보다 높습니다.

 

웹소켓도 Cloudflare에서 작동하는데, 이는 서버리스 플랫폼에서는 드문 경우입니다.

 

페이지는 25MB의 번들 크기를 지원합니다.


배포는 400ms의 시작 시간 제한을 가지고 있는데, 앱이 성장함에 따라 문제가 될 수 있습니다.

 

빌드와 업로드가 성공한 후에 "No deployment available" 오류가 발생하면 이것이 원인일 수 있습니다.

SST

SST는 AWS에서 서버리스 애플리케이션을 구축하기 위한 인프라-코드 프레임워크입니다.

 

SST는 RemixSite 구조를 통해 Remix를 지원하며, 앱을 AWS Lambda 또는 AWS Lambda@Edge에 배포합니다.

 

엣지 함수와 혼동해서는 안 되며, 이들은 AWS 지역 간에 프록시 역할을 하는 일반 Node 람다 함수입니다.

 

사용자는 배포된 단일 지역이 아니라 가장 가까운 AWS 지역에 연결하게 됩니다. 그리고 CDN으로 Cloudfront를 사용합니다.

 

Git 기반 배포는 포함되어 있지 않지만, Github Action을 사용하거나 SST 팀이 구축한 배포 인프라 도구인 Seed를 사용하여 쉽게 설정할 수 있습니다.


미리보기 및 스테이징 환경은 SST CLI를 통해 생성되며, 이는 Github Action에서 수행할 수 있습니다.

Fly.io

Fly.io는 엣지에서 운영되는 관리형 컨테이너 플랫폼입니다.

 

서버리스 함수가 아닌 서버리스 가상 머신입니다.

 

Fly의 가장 큰 장점 중 하나는 다중 지역 지원입니다.

 

Fly의 20개 이상의 지역 중 어느 곳에나 앱을 배포할 수 있으며, Fly는 배포한 모든 지역에 자동으로 앱을 복제합니다.

 

이는 앱이 사용자에게 더 가까워지고, 장애에 대해 더욱 복원력을 가지게 됨을 의미합니다.

 

간단한 CLI 명령으로 앱에 할당된 RAM과 CPU의 양을 조정할 수 있습니다.

 

기본적으로 Fly는 256MB의 RAM을 제공하지만, Remix 앱에는 이보다 더 많은 512MB를 대부분의 앱에 대한 합리적인 최소값으로 권장합니다.

 

앱을 서비스할 수 있는 기계의 수도 구성할 수 있으며, 범위 내에서 자동 확장하도록 Fly에 지시할 수 있습니다.

 

이는 저 트래픽 애플리케이션을 위해 0으로 자동 확장하는 데 유용합니다.

 

Fly는 앱과 함께 배포하고 배포한 모든 지역에 복제할 수 있는 Postgres 및 Redis 데이터베이스도 지원합니다.

 

Fly는 정적 자산을 제공하기 위한 CDN을 제공하지만, 캐시를 프로그래밍 방식으로 삭제하는 API는 제공하지 않습니다.

 

stale-while-revalidate 및 stale-if-error를 포함한 캐시 제어 헤더가 지원됩니다.

 

Git 기반 배포는 내장되어 있지 않지만, GitHub Actions에서 설정하기 쉽습니다.


미리보기 환경이 없습니다. Fly.io에서 자동 미리보기 환경을 위해 FlyCD를 사용할 수 있습니다.


Fly는 8GB의 미압축 도커 이미지 제한을 가지고 있습니다.


Fly는 10MB의 요청 본문 버퍼를 가지고 있지만, 스트리밍을 통해 더 큰 본문을 처리할 수 있습니다.

Render

Render는 Docker를 필요로 하지 않지만(특별한 의존성을 설치하고 싶은 경우 앱을 Docker 이미지로 패키징할 수는 있음), Remix를 지원하는 관리형 호스팅 플랫폼입니다.

 

Render는 git 기반 배포를 지원하므로 git 저장소에 코드를 푸시하기만 하면 Render가 배포합니다.

 

그들은 또한 팀 플랜에 대한 미리보기 환경을 지원합니다.

 

내장된 데이터베이스는 Postgres와 Redis이지만, 다른 것을 실행하는 새 컨테이너를 설치하는 것을 막지는 않습니다.

 

Fly처럼 다중 지역 지원이 없습니다.


Render는 요청 본문 크기 제한이 없습니다.


그들은 번들/이미지 제한을 공개하지 않았습니다.

Railway

Railway는 관리형 컨테이너 호스팅 플랫폼입니다. 자체 Dockerfile을 제공하지 않으면 Railway는 이를 없이 배포할 수 있게 해줍니다.

 

Railway는 git 기반 배포를 지원하므로 git 저장소에 코드를 푸시하기만 하면 Railway가 배포합니다.

 

그들은 또한 팀 플랜에 대한 미리보기 환경을 지원합니다.

 

데이터베이스의 경우, Railway는 Postgres, MySQL, Redis, MongoDB를 내장 지원하며, 이를 관리하기 위한 웹 UI도 제공합니다.

 

Railway는 다른 대륙 지역으로 배포를 지원하지만, Fly처럼 다중 지역 지원은 없습니다.


자동 미리보기 환경은 없지만, 스테이징 환경을 설정하기는 쉽습니다.

DigitalOcean App Platform

DigitalOcean App Platform은 관리형 컨테이너 호스팅 플랫폼입니다.

 

자체 Dockerfile을 제공하지 않으면 DigitalOcean은 이를 없이 배포할 수 있게 해줍니다.

 

DigitalOcean은 git 기반 배포를 지원하며, 더 고급 배포 워크플로우를 위한 Github 액션도 제공합니다.

 

DigitalOcean 웹 콘솔을 통해 애플리케이션과 함께 배포할 수 있는 Postgres, MySQL, Redis, MongoDB 데이터베이스가 있습니다.

 

자동 미리보기 환경이나 내장 스테이징 환경은 없습니다.

GitHub Pages

Remix v2.5는 SPA 모드를 도입하여, 앱을 정적 HTML, CSS, JS 파일의 번들로 내보낼 수 있게 해줍니다.

 

이러한 파일은 어느 서버리스 플랫폼에서나 호스팅할 수 있으며, 미리보기 환경과 필요한 경우 서버로 쉽게 업그레이드할 수 있는 모든 다른 이점을 얻을 수 있습니다.

 

GitHub Pages는 GitHub 저장소를 위한 공개 웹사이트를 설정할 수 있게 해주는 공식 GitHub 기능입니다.

 

사이트를 로컬에서 빌드하고 호스팅하려는 정적 자산이 포함된 번들을 커밋하거나, GitHub 액션을 사용하여 앱을 빌드하고 정적 자산을 gh-pages 브랜치로 푸시할 수 있습니다.

기타 호스트

PartyKit은 Cloudflare 인프라에 기반한 협업 앱을 구축하기 위한 프레임워크입니다.

 

PartyKit의 Remix 스타터는 Remix 앱과 웹소켓 서버를 Cloudflare에 함께 배포할 수 있는 사용자 정의 서버를 사용합니다.


AWS Fargate는 AWS에서 컨테이너 앱을 실행할 수 있게 해주는 관리형 컨테이너 플랫폼입니다.

 

이는 Fly/Render/Railway와 같지만 AWS에서 직접 실행됩니다.


Arc는 AWS Lambda에 앱을 배포할 수 있게 해주는 서버리스 프레임워크입니다.


Azure Functions를 위한 Remix 어댑터도 사용 가능합니다.

 

이러한 다양한 플랫폼과 서비스들을 통해 개발자는 자신의 Remix 앱을 효율적으로 배포하고 관리할 수 있는 다양한 옵션을 가질 수 있습니다.

 

각 서비스의 특징을 잘 파악하고, 앱의 요구사항과 일치하는 최적의 서비스를 선택하는 것이 중요합니다.