Rails 8의 Solid Queue와 Solid Cache: 2026년 기술 면접 완벽 가이드

Solid Queue와 Solid Cache는 Rails 역사상 가장 중대한 인프라 전환을 대표하는 컴포넌트입니다. 두 컴포넌트 모두 Rails 8에서 기본값으로 탑재되며, 백그라운드 작업과 캐싱에서 Redis 의존성을 제거하고 데이터베이스 기반 대안으로 대체합니다. 이를 통해 운영 복잡성의 한 계층 전체가 사라집니다.

Solid Queue가 Redis 기반 작업 백엔드를 대체하는 방식

Solid Queue는 PostgreSQL, MySQL, SQLite에 작업을 직접 저장하는 데이터베이스 기반 Active Job 백엔드입니다. 핵심 메커니즘은 FOR UPDATE SKIP LOCKED입니다. PostgreSQL 9.5 이상과 MySQL 8 이상에서 사용 가능한 이 SQL 기능은 일반 데이터베이스 테이블을 블로킹 없는 동시 작업 큐로 변환합니다.

아키텍처는 세 가지 컴포넌트로 구성됩니다.

• Worker는 solid_queue_ready_executions 테이블을 폴링하고 SKIP LOCKED를 사용하여 작업을 할당받습니다
• Dispatcher는 예약된 작업을 solid_queue_scheduled_executions에서 실행 시각이 도래했을 때 ready 테이블로 이동합니다
• Scheduler는 설정 파일에 정의된 반복 작업을 관리합니다

# config/solid_queue.yml
production:
  dispatchers:
    - polling_interval: 1
      batch_size: 500
  workers:
    - queues: "*"
      threads: 5
      polling_interval: 0.1
      processes: 2

이 설정은 각각 5개의 스레드를 가진 2개의 워커 프로세스를 실행하며, 100밀리초마다 폴링합니다. Dispatcher는 1초마다 500개 단위의 배치로 예약된 작업을 확인합니다.

Rails 8의 트랜잭션 기반 작업 인큐잉

Solid Queue가 Redis 기반 백엔드에 대해 갖는 가장 강력한 이점 중 하나는 트랜잭션 기반 인큐잉입니다. 데이터베이스 트랜잭션 내에서 인큐된 작업은 해당 트랜잭션이 커밋된 후에만 가시화됩니다. Redis 기반 백엔드는 이 보장을 제공할 수 없습니다. 작업이 트리거한 트랜잭션이 완료되기 전에 실행되어, 아직 존재하지 않는 레코드를 참조할 수 있습니다.

# app/jobs/send_welcome_email_job.rb
class SendWelcomeEmailJob < ApplicationJob
  self.enqueue_after_transaction_commit = true

  queue_as :default

  def perform(user_id)
    user = User.find(user_id)
    UserMailer.welcome(user).deliver_now
  end
end

# app/models/user.rb
class User < ApplicationRecord
  after_create do
    SendWelcomeEmailJob.perform_later(id)
    # Job only enqueued after the CREATE transaction commits
    # No risk of the job running before the user record exists
  end
end

enqueue_after_transaction_commit가 활성화되면, 작업은 래핑 트랜잭션이 성공할 때까지 지연됩니다. 트랜잭션이 롤백되면 작업은 인큐되지 않습니다. 이로써 Redis 기반 큐에서 문제가 되는 레이스 컨디션의 전체 범주가 제거됩니다.

동시성 제어와 우선순위 큐

Solid Queue는 Sidekiq에서 유료 Enterprise 버전에서만 제공하는 내장 동시성 제어 기능을 갖추고 있습니다. concurrency_limit 옵션을 통해 특정 유형의 작업이 동시에 실행될 수 있는 횟수를 제한할 수 있습니다.

# app/jobs/api_sync_job.rb
class ApiSyncJob < ApplicationJob
  limits_concurrency to: 3, key: ->(account_id) { "api_sync_#{account_id}" }

  def perform(account_id)
    account = Account.find(account_id)
    ExternalApi.sync(account)
  end
end

이 설정은 계정당 최대 3개의 API 동기화 작업만 동시에 실행되도록 보장하여 외부 조율 메커니즘 없이도 API 속도 제한 위반을 방지합니다. 차단된 작업은 solid_queue_blocked_executions에 저장되며, 슬롯이 비면 자동으로 해제됩니다.

우선순위는 두 가지 수준에서 작동합니다. 작업별 숫자 우선순위(숫자가 낮을수록 우선순위가 높음)와 워커 설정에서의 큐 순서입니다. 두 가지를 결합하면 작업 실행 순서를 세밀하게 제어할 수 있습니다.

Cron 없이 반복 작업 실행하기

Solid Queue는 cron 기반 스케줄링을 내장 스케줄러로 대체합니다. 반복 작업은 YAML 설정 파일에 정의되며 스케줄러 프로세스에 의해 관리됩니다.

# config/recurring.yml
production:
  cleanup_expired_sessions:
    class: CleanupExpiredSessionsJob
    schedule: every 6 hours
  daily_report:
    class: DailyReportJob
    schedule: every day at 6am
    queue: reports
  weekly_digest:
    class: WeeklyDigestJob
    schedule: every Monday at 9am

스케줄러 프로세스가 이 파일을 읽고 정의된 간격에 따라 적절한 작업을 인큐합니다. cron과 달리 동일한 프로세스 슈퍼바이저 내에서 실행되며 동일한 데이터베이스 연결을 공유합니다.

Puma 통합을 통한 배포

Rails 8은 Kamal과 결합하여 Solid Queue의 제로 설정 배포를 제공합니다. SOLID_QUEUE_IN_PUMA=1을 설정하면 Puma가 웹 서버와 함께 Solid Queue 프로세스를 포크하여 관리합니다.

# config/puma.rb (Rails 8 default)
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]

이 단일 프로세스 배포 모델은 컨테이너 오케스트레이션을 간소화합니다. 하나의 Docker 이미지로 웹 서버와 작업 프로세서를 모두 실행할 수 있어, 중소규모 애플리케이션의 운영 오버헤드를 줄여줍니다.

Solid Cache: 확장 가능한 데이터베이스 기반 캐싱

Solid Cache는 데이터베이스 기반의 ActiveSupport::Cache::Store로, 최신 SSD 성능을 활용하여 Redis와 Memcached를 기본 캐시 저장소로서 대체합니다. 그 전제는 SSD의 읽기 성능이 RAM에 비해 미세하게만 느리면서도, 훨씬 적은 비용으로 훨씬 더 큰 저장 용량을 제공한다는 것입니다.

Solid Cache는 LRU(Least Recently Used) 대신 FIFO(First In, First Out) 만료 전략을 사용합니다. FIFO는 이론적으로 LRU보다 효율이 떨어지지만, 훨씬 큰 저장 용량이 이를 보완합니다. 항목이 캐시에 더 오래 유지되어 전체적인 캐시 미스가 감소합니다.

# config/environments/production.rb
config.cache_store = :solid_cache_store

# config/solid_cache.yml
production:
  databases:
    - cache
  store_options:
    max_age: 604800        # 1 week in seconds
    max_size: 256           # Max entry size in KB
    namespace: "app_v1"
    expiry_batch_size: 100  # Entries cleaned per expiry cycle

캐시 아키텍처와 만료 메커니즘

Solid Cache는 내부 카운터를 사용하여 쓰기를 추적합니다. 카운터가 설정된 expiry_batch_size의 50%에 도달하면 만료된 항목을 정리하는 백그라운드 작업이 트리거됩니다. 이 분할 상환 방식은 메모리 제약이 있는 Redis 인스턴스에서 LRU 축출 시 발생할 수 있는 스톱 더 월드(Stop-the-World) 일시 중지를 방지합니다.

solid_cache_entries 테이블에 모든 캐시 데이터가 저장됩니다.

# db/cache_schema.rb (generated by installer)
create_table :solid_cache_entries do |t|
  t.binary :key, null: false, limit: 1024
  t.binary :value, null: false, limit: 262144  # 256 KB default
  t.datetime :created_at, null: false
  t.index :key, unique: true
  t.index :created_at  # For FIFO expiry
end

이 테이블의 읽기와 쓰기는 기본적으로 애플리케이션의 나머지 부분과 동일한 커넥션 풀을 사용합니다. 트래픽이 많은 애플리케이션에서는 캐시 데이터를 위한 별도의 데이터베이스를 구성하여 캐시 변동이 프라이머리 데이터베이스 성능에 영향을 미치는 것을 방지할 수 있습니다.

캐시 전용 별도 데이터베이스 구성

Solid Cache를 전용 데이터베이스에 분리하는 것은 간단하며, 대량의 캐시 트래픽이 발생하는 프로덕션 워크로드에서 권장됩니다.

# config/database.yml
production:
  primary:
    <<: *default
    database: myapp_production
  cache:
    <<: *default
    database: myapp_cache_production
    migrations_paths: db/cache_migrate

이 분리를 통해 수백만 건의 캐시 쓰기 작업이 프라이머리 데이터베이스의 WAL(Write-Ahead Log)을 비대화시키거나, 애플리케이션 쿼리와 커넥션 풀 슬롯을 두고 경쟁하는 것을 방지합니다.

샤딩과 암호화

Solid Cache는 부하 분산을 위해 캐시 데이터를 여러 데이터베이스에 샤딩하는 것을 지원합니다. 또한 암호화된 속성을 지원하여, 캐시 데이터가 저장 시 암호화된 상태를 유지합니다. 이는 민감한 정보를 다루는 애플리케이션의 컴플라이언스 요구사항입니다.

# config/solid_cache.yml
production:
  databases:
    - cache_shard_1
    - cache_shard_2
    - cache_shard_3
  store_options:
    max_age: 1209600  # 2 weeks

항목은 캐시 키의 일관된 해싱을 사용하여 샤드 간에 분산됩니다. 샤드를 추가하거나 제거하면 항목이 재분배되는 동안 일시적으로 캐시 미스가 증가하지만, 데이터 손실은 발생하지 않습니다.

Mission Control Jobs를 통한 모니터링

Mission Control Jobs는 Solid Queue 작업을 검사하고 관리하기 위한 웹 대시보드를 제공합니다. 마운트된 Rails 엔진을 통해 워커, 큐, 작업 상태(진행 중, 완료, 차단, 실패)를 표시합니다.

# config/routes.rb
Rails.application.routes.draw do
  mount MissionControl::Jobs::Engine, at: "/jobs"
end

# Gemfile
gem "mission_control-jobs", ">= 1.0.1"

Mission Control은 실패한 작업에 대한 일괄 작업을 위한 콘솔 API도 제공합니다.

# Rails console
ActiveJob.jobs.failed.where(job_class: "ApiSyncJob").retry_all
ActiveJob.jobs.failed.where(job_class: "BrokenJob").discard_all

이 프로그래밍 방식의 접근은 대시보드를 수동으로 클릭하지 않고도 대규모 작업 실패를 처리하는 데 필수적입니다.

기술 면접 핵심 질문

Rails 8 면접에서는 Solid 스택에 대한 질문이 점점 더 많아지고 있습니다. 다음은 가장 빈번하게 출제되는 질문과 기대되는 답변 수준입니다.

Q: Solid Queue는 Redis 없이 어떻게 동시 작업 처리를 달성합니까? Solid Queue는 FOR UPDATE SKIP LOCKED라는 SQL 절을 사용합니다. 이를 통해 여러 워커가 서로를 차단하지 않고 동일한 테이블을 폴링할 수 있습니다. 각 워커는 행 배치를 잠그고 처리한 후 실행 레코드를 삭제합니다. 다른 워커는 이미 잠긴 행을 건너뛰고 다른 작업을 할당받습니다.

Q: 트랜잭션 기반 인큐잉은 어떤 문제를 해결합니까? 작업을 트리거한 데이터베이스 트랜잭션이 커밋되기 전에 작업이 실행되는 것을 방지합니다. 이것이 없으면 롤백된 레코드를 작업이 참조하여 ActiveRecord::RecordNotFound 오류가 발생할 수 있습니다.

Q: Solid Cache가 LRU 대신 FIFO를 사용하는 이유는 무엇입니까? FIFO는 데이터베이스에서 구현이 더 간단하며, 매 읽기마다 접근 타임스탬프를 갱신하는 쓰기 증폭을 회피합니다. SSD의 대용량 저장 공간 덕분에 항목이 더 오래 유지되므로, 최적이 아닌 축출 전략에도 불구하고 높은 적중률이 유지됩니다.

Q: 애플리케이션이 Solid 스택 대신 Redis를 사용해야 하는 경우는 언제입니까? Redis는 분당 10,000건 이상의 작업을 처리하는 애플리케이션, 서브밀리초 캐시 읽기가 필요한 워크로드, 또는 다른 용도(Pub/Sub, 속도 제한, 세션 저장소)로 이미 Redis를 실행 중인 애플리케이션에서 여전히 우위를 점합니다. Solid 스택의 목표는 최대 처리량이 아닌 단순성입니다.

이러한 질문들을 SharpSkill의 ActiveJob & 백그라운드 작업 모듈 과 캐싱 전략 모듈에서 연습할 수 있습니다.

결론

• Solid Queue는 FOR UPDATE SKIP LOCKED를 활용한 동시 처리로 Redis 기반 작업 큐를 데이터베이스 기반 솔루션으로 대체합니다
• 트랜잭션 기반 인큐잉은 데이터베이스 쓰기와 작업 실행 사이의 레이스 컨디션을 제거합니다. 이는 Redis가 제공할 수 없는 보장입니다
• 내장 동시성 제어, 반복 작업, Puma 통합이 Solid Queue에 추가 비용 없이 포함됩니다
• Solid Cache는 SSD 기반 FIFO 캐싱과 선택적 샤딩 및 암호화를 제공하여, Memcached와 Redis를 인프라 스택에서 제거합니다
• Solid Cache의 별도 데이터베이스 구성으로 캐시 변동이 프라이머리 데이터베이스 성능에 영향을 미치는 것을 방지합니다
• Mission Control Jobs는 웹 대시보드와 콘솔 API를 통해 프로덕션 모니터링과 일괄 작업 관리를 제공합니다
• 2026년 대부분의 Rails 8 애플리케이션에서 Solid 스택이 권장 기본값입니다. Redis는 분당 10,000건을 초과하는 고처리량 엣지 케이스에서만 선택지가 됩니다