Rails 8은 "PaaS가 필요하지 않습니다."라는 대담한 전제를 바탕으로 출시되었습니다. 클라우드 플랫폼의 비용이 더욱 비싸짐에 따라 Ruby on Rails는 개발자가 이전보다 적은 서비스 종속성으로 애플리케이션을 배포하고 실행할 수 있도록 외부 인프라 종속성을 줄이는 방향으로 전환했습니다.
전통적으로 Rails 앱을 인터넷에 배포한다는 것은 데이터베이스 서버(예:PostgreSQL)와 캐싱, 백그라운드 작업 또는 WebSocket을 위한 Redis와 같은 추가 서비스를 프로비저닝하는 것을 의미했습니다. Rails 8을 통해 핵심 팀은 애플리케이션 데이터베이스를 기반으로 하는 캐싱, 작업 대기열 및 실시간 WebSocket용 솔루션을 베이킹하여 이러한 상황을 바꾸고자 합니다.
이 기사에서는 "Solid Trifecta"의 개요를 시작으로 Rails 8이 "PaaS가 필요하지 않음" 약속을 어떻게 이행하는지 살펴보겠습니다.
Redis 없이 캐시하는 데 도움이 되는 Solid Cache
Rails 8에서 제가 가장 좋아하는 추가 기능 중 하나는 솔리드 캐시입니다. , Redis 또는 Memcached의 필요성을 대체하는 새로운 캐시 저장소 . Solid Cache는 메모리 내 키-값 저장소 대신 데이터베이스를 사용하여 캐시된 데이터를 유지합니다. 캐시된 개체를 디스크에 저장하는 것은 기술적으로 RAM보다 느리지만 몇 가지 중요한 이점이 있습니다.
첫째, 디스크 스토리지는 더 많은 공간을 제공하고 메모리보다 훨씬 저렴합니다. Solid Cache를 사용하면 RAM 부족 없이 훨씬 더 많은 데이터를 캐시하고 더 오래 보관할 수 있습니다. 37signals(Basecamp 및 HEY를 개발한 회사)에서는 Redis에서 Solid Cache로 전환하여 캐시를 10테라바이트 이상의 데이터로 확장하고 궁극적으로 P95 렌더링 시간을 50% 단축했습니다.
예, 메모리에서 읽는 것이 디스크에서 읽는 것보다 빠릅니다. 많은 경우(Basecamp의 사용과 같은) 더 많은 데이터를 캐싱한다는 점에서 이러한 속도 향상은 그만한 가치가 있습니다.
기본적으로 Rails 8은 솔리드 캐시(SQLite 지원)를 사용합니다. 물론, Rails 규칙의 일반적인 경우와 마찬가지로 Redis가 더 나은 선택이라면 Redis와 같은 다른 옵션을 선택할 수도 있습니다. 하지만 이 기본값을 고수하면 Redis와 같은 다른 프로덕션 서비스를 지원하지 않고도 항목을 캐시할 수 있으므로 인프라 부담이 줄어듭니다.
Solid Queue는 Redis 없이 백그라운드 작업을 수행하는 데 도움이 됩니다.
"Solid" 세 가지 중 제가 두 번째로 좋아하는 부분은 Redis나 Sidekiq과 같은 별도의 작업 시스템 종속성 없이도 백그라운드 작업 처리를 처리하는 새로운 Active Job 백엔드인 Solid Queue입니다.
많은 Rails 개발자는 Sidekiq(Redis에 의존) 또는 Delayed Job과 같은 gem을 백그라운드 작업에 사용합니다. Solid Queue는 필요를 제거하려는 Rails의 시도입니다. 다른 종속성을 위해. 작업 대기열을 애플리케이션 데이터베이스에 통합하므로 메모리 솔루션이나 대기열 시스템이 필요하지 않습니다.
Solid Queue는 작업을 데이터베이스 테이블의 레코드로 저장하고 효율적인 SQL 기능을 사용하여 작업 대기열을 관리합니다. Rails 웹 프로세스에 내장되거나(단일 서버 설정을 위한 Puma 플러그인으로) 별도의 작업자 프로세스에서 실행될 수 있습니다.
Rails 핵심 팀 구성원 중 한 명은 개발자가 "7개의 서로 다른 gem과 기타 시스템을 관리할 필요 없이 Rails를 설치하고, 데이터베이스를 설정하고, 즉시 백그라운드 작업을 처리할 수 있도록" 하는 것이 목표였습니다.
Solid Cable은 웹 소켓을 수행하는 데 도움이 됩니다(놀랍게도 Redis 없이)
Rails 8의 "Redis가 필요하지 않은" 퍼즐의 세 번째 조각은 Solid Cable입니다. — 짐작하셨겠지만 데이터베이스를 사용하는 새로운 액션 케이블 어댑터입니다. 역사적으로 Action Cable은 여러 Rails 프로세스 간에 메시지를 브로드캐스트하기 위해 Redis 서버가 필요했습니다. Solid Cable을 사용하면 실시간 WebSocket 기능에 Action Cable을 활용하여 추가 서비스를 실행하지 않고도 채팅 및 알림과 같은 애플리케이션 기능에 대한 실시간 업데이트를 잠금 해제할 수 있습니다.
이제 '솔리드' 3요소의 이점이 명확해졌으면 좋겠습니다. Redis 서버나 기타 게시/구독 서비스를 가동하지 않고도 장기 데이터를 캐시하고, 처리량이 높은 백그라운드 작업을 처리하고, 실시간 기능을 배포할 수 있습니다. 이러한 기능은 함께 소규모 앱의 복잡성을 낮추고(하나의 데이터베이스가 있는 단일 호스트에서 모든 것을 실행할 수 있음) 배포를 더 쉽게 한다는 Rails 8 철학에 부합합니다.
Redis가 필요 없게 된 것이 그렇게 큰 일인가요?
Rails 8의 많은 부분이 Redis에 대한 종속성을 제거하는 것에 대해 알고 나면 이것이 실제로 얼마나 중요한지 궁금할 것입니다. 대답은 상황에 따라 다르지만 의심할 여지 없이 몇 가지 주목할만한 이점이 있습니다.
움직이는 부품이 적다는 것은 특히 배포 시 복잡성이 줄어든다는 것을 의미합니다. 모든 추가 서비스(Redis, 별도의 백그라운드 작업 실행기 등)는 중단되거나 확장이 필요할 수 있는 또 다른 서비스입니다. 더 많은 용도로 데이터베이스를 사용하면 생산 작업이 단순화됩니다. Redis 메모리를 모니터링하거나 Redis 인스턴스가 항상 실행되고 있는지 확인할 필요가 없습니다.
많은 Rails 개발자는 개발 중에는 캐시 서버를 실행하지 않거나 다른 큐 어댑터를 사용하지 않지만 프로덕션에서는 Redis/Sidekiq을 사용하는 시나리오에 직면했습니다. 새로운 Rails 기본값을 사용하면 개발 및 프로덕션에서 동일한 설정을 실행하여 예상치 못한 상황을 최소화할 수 있습니다. 스택은 더 독립적이며 생산을 위한 특별한 구성 없이 즉시 "작동"합니다.
서버나 추가 기능이 적다는 것은 호스팅 비용이 더 저렴하다는 것을 의미합니다. 더 큰 규모에서도 인프라를 통합하면 어느 정도 비용 효율성이 높아집니다. 데이터베이스 공간은 메모리보다 저렴합니다!
Rails는 Redis 또는 기타 서비스 사용을 방해하지 않습니다. 단지 선택 사항으로 만드는 것뿐입니다. . 내장된 Solid 어댑터로 시작할 수 있으며, 필요한 경우 나중에 Redis 또는 기타 솔루션을 도입할 수 있습니다.
SQLite는 데이터베이스 프로세스의 필요성을 제거합니다
Rails 8의 또 다른 의미 있는 변화는 Rails의 SQLite 어댑터에 대한 수많은 개선을 통해 SQLite를 사용 가능한 프로덕션 데이터베이스로 수용한 것입니다. 앱이 프로덕션 환경에서 SQLite를 사용할 수 있다면 별도의 데이터베이스 서버를 실행할 필요가 없습니다. 대신 데이터는 앱 프로세스 자체에서 관리하는 디스크의 간단한 파일에 저장됩니다. Rails 8의 SQLite 개선으로 이를 이전보다 더욱 현실적으로 만들었습니다.
SQLite는 배포를 훨씬 더 간단하게 만들 수 있습니다. 서버에 MySQL 또는 Postgres를 설치 또는 관리할 필요가 없으며 관리형 DB 서비스를 사용(및 비용 지불)할 필요도 없습니다. Rails 앱이 읽고 쓰는 파일일 뿐입니다.
물론 SQLite의 규모가 커지면 나중에 모든 기능을 갖춘 데이터베이스 시스템으로 마이그레이션할 수 있습니다. Rails 핵심 팀은 기본값을 경량 옵션으로 변경했습니다. 이는 "No PaaS" 서술에 잘 맞습니다.
Kamal 2는 배포를 도와줍니다
Rails 8은 실행을 단순화합니다. 프로덕션 중인 앱 — 하지만 앱을 에 설치하는 것은 어떻습니까? 생산? Kamal 2의 출시는 이 질문에 답을 시도합니다.
Kamal은 번거로움을 최소화하면서 Docker 컨테이너를 통해 모든 Linux 서버에 앱을 배포하는 오케스트레이션 도구입니다. 모든 서버 설정을 직접 처리할 필요 없이 앱의 이미지 구축, 푸시 및 서버 실행을 자동화합니다.
일부 구성과 하나의 명령(kamal setup ), Kamal은 새로운 Linux 상자를 가져와 Docker 컨테이너를 실행하는 데 필요한 것을 프로비저닝합니다.
그 후 배포는 kamal deploy를 실행하는 것만큼 간단합니다. , 다운타임 없는 배포를 위해 최신 이미지를 가져오고 이전 컨테이너를 새 컨테이너로 교체합니다.
Kamal 2는 모든 Linux 호스트에서 PaaS와 유사한 배포 경험을 제공하기를 희망합니다. 단일 명령으로 모든 서버를 앱을 실행하는 Rails 서버로 전환할 수 있습니다. 초기 구성은 어려울 수 있지만 후속 배포는 훨씬 더 간단합니다. 이는 Heroku와 같은 플랫폼으로 푸시하는 것만큼 편리한 자체 호스팅을 만드는 큰 진전입니다.
'PaaS 없음'은 좋은 생각인가요?
Rails 8이 진짜인가요? 플랫폼을 과거의 것으로 만들까요? 그리고 중소 규모의 팀이 셀프 호스팅을 통해 정말 비용을 절약할 수 있을까요?
최근 Kamal을 사용하여 VPS에 취미 프로젝트를 배포했는데 실망스러운 경험이었습니다. 작업을 마친 후에는 배포가 상대적으로 원활하게 진행되었지만 설정이 멀었고 이 프로젝트를 확장해야 하는 경우 작업이 중단되었습니다.
따라서 제 생각에 대답은 아니오입니다. Rails 8은 플랫폼의 가치 제안을 제거하지 않습니다 . 차라리 내 앱에 집중하고 Heroku 같은 플랫폼이 인프라를 처리하도록 맡기고 싶습니다.
개인 개발자와 소규모 팀은 규모의 경제를 추구하는 것보다 사용자에게 집중함으로써 더 많은 이점을 얻을 수 있습니다. 호스팅, 배포, 확장을 이러한 분야에서 뛰어난 플랫폼으로 아웃소싱하고 고객이 좋아하는 제품을 만드는 데 집중하는 것은 어떨까요?
물론 팀과 애플리케이션이 성장함에 따라 플랫폼 가격이 덜 매력적이라는 것을 알게 될 수도 있습니다. 어떤 시점에서는 SRE 및 운영 책임에 전념할 시간 및/또는 인력을 확보하는 것이 합리적이며 Kamal(다른 멋진 Rails 8 기본 기능과 함께)은 이를 더 쉽게 만드는 큰 진전입니다.
모두 함께 가져오기
Rails 8은 자체 호스팅과 플랫폼 사용 사이의 격차를 좁히지만 "PaaS가 필요하지 않습니다"라고 솔직하게 주장할 만큼 좁혀지지는 않습니다. 그러나 Rails 8을 사용하면 개발자 경험을 너무 많이 희생하지 않고도 PaaS 대신 VPS를 더 쉽게 선택할 수 있다는 점은 분명합니다. 저는 그것이 플랫폼 킬러라고 생각하지 않습니다.
Solid Cache, Solid Queue 및 Solid Cable은 모두 웹 앱에 대한 이전의 타사 요구 사항을 자사 지원으로 가져왔고 이에 대해 감사하게 생각합니다. 애플리케이션을 시작하기 위해 가볍지만 강력한 기본값을 갖는 것은 멋진 일이며, 더 좋은 점은 많은 인프라가 필요하지 않다는 것입니다. 자체 호스팅을 선택하면 Kamal이 배포 부담을 일부 덜어줄 수 있습니다.
플랫폼 사용 여부에 관계없이 오류 및 중단에 신속하게 대응하고 고객에게 훌륭한 사용자 경험을 제공하려면 모니터링이 필수적입니다. Rails 애플리케이션의 상태와 성능에 대한 실시간 통찰력을 얻으려면 Honeybadger에 가입하세요.