비동기 컨트롤러의 작동 방식
Rails 8.1은 컨트롤러가 백그라운드 큐를 전혀 거치지 않고도 렌더링, 스트리밍 및 yield를 수행할 수 있는 패러다임의 변화를 도입합니다. 이는 Ruby 4.0의 Ractor 및 Fiber 스케줄러에 의해 구동되는 async def 및 await 구문을 통해 달성됩니다.
ruby
class EmailsController < ApplicationController
async def send_bulk
recipients = User.newsletter_subscribers
await recipients.each do |user|
Mailer.newsletter(user).deliver_later
end
render json: { status: "done" }
end
end
기존의 스레딩 모델과 달리, 이 접근 방식은 애플리케이션 프로세스 내에서 관리되는 논블로킹 I/O 작업을 활용합니다. 이는 백그라운드 처리처럼 보이지만 런타임의 Fiber 풀 내에서 작동하며, 일시적인 작업에 대한 즉각적인 Redis 영속성(persistence)의 필요성을 없앱니다.
Turbo Streams 2.0: 피드백 루프 닫기
Turbo Streams 2.0은 이러한 새로운 비동기 기능의 전달 메커니즘 역할을 합니다. 이를 통해 비동기 액션이 여러 클라이언트에 실시간으로 업데이트를 브로드캐스트할 수 있습니다. UI 요소를 업데이트하기 위해 작업을 큐에 넣는 고전적인 패턴은 이제 인라인 실행 흐름으로 간소화됩니다.
- I/O 바운드 작업을 Await합니다.
- 부분 템플릿(partial) 또는 데이터를 렌더링합니다.
- Turbo Stream을 통해 직접 브로드캐스트합니다.
이는 진행률 표시줄 또는 실시간 알림과 같은 기능에 대한 아키텍처적 마찰을 줄여, 실시간 UX를 복잡한 추가 기능이 아닌 기본값으로 만듭니다.
런타임 제약 및 조용한 폴백
아키텍트에게 가장 중요한 기술적 세부 사항 중 하나는 이 비동기 레이어의 관리입니다. 실행은 특정 환경 변수에 의해 제한됩니다.
RAILS_MAX_FIBERS(기본값: 128)RAILS_MAX_RACTORS(기본값: 8)
이러한 할당량이 포화 상태가 되면 Rails 8.1은 충돌하지 않고, 조용히 동기 모드로 폴백(fallback)합니다. 이러한 “조용한 성능 저하”는 새로운 모니터링 과제를 제시하며, Sidekiq 큐 길이에서 Fiber yield 및 Ractor 경합으로 초점을 이동시킵니다.
Sidekiq vs. 비동기: 전략적 공존
인라인 실행과 백그라운드 작업 간의 경계가 이동했습니다. Sidekiq은 애플리케이션 재시작 후에도 유지되어야 하거나, 복잡한 재시도 로직이 필요하거나, CPU 집약적인 연산을 포함하는 작업에 대한 표준으로 남아 있습니다. 반대로 비동기 컨트롤러는 짧은 I/O 바운드 작업(100ms ~ 2초)과 별도의 워커 프로세스 오버헤드가 불필요한 대화형 순간에 최적화되어 있습니다.