장시간 Job의 문제점과 해결책
37Signals의 Basecamp는 Capistrano를 사용하여 배포 시 기존 Job을 완료할 때까지 기다렸습니다. 이는 자체 하드웨어에서 애플리케이션 재시작이 드물었기 때문에 가능했지만, 오래된 코드가 계속 실행되는 등의 문제가 있었습니다. Basecamp를 Docker 기반 배포 프레임워크인 Kamal로 전환하면서, 배포 시 Worker가 30초 후에 강제 종료되는 상황에 직면했습니다. 이로 인해 장시간 실행되는 Job들이 중단되고 처음부터 다시 시작해야 하는 문제가 발생했으며, 이는 고객 경험에 직접적인 영향을 미쳤습니다.
이 문제를 해결하기 위해 37Signals는 약 30개의 Job에 적용할 수 있는 범용적인 중단 및 재개 메커니즘을 모색했습니다. 목표는 기존 Job 코드의 단순한 구조를 유지하면서 최소한의 변경으로 Active Job만 사용하여 이 기능을 구현하고, 이를 Rails에 업스트림하는 것이었습니다.
Active Job Continuations API 및 작동 방식
Active Job Continuations는 다음과 같은 API 단계를 통해 Job을 중단 및 재개 가능하게 만듭니다:
-
ActiveJob::Continuations모듈 포함: Job 클래스에 이 모듈을 포함합니다. -
step메서드를 사용한 Job 분할: Job의 각 논리적 단위를step블록으로 묶습니다.step메서드 사이에는 암묵적인 ‘체크포인트’가 생성됩니다. ```ruby class ExportJob < ActiveJob::Base include ActiveJob::Continuationsdef perform step(:write_files) { # … } step(:zip_files) { # … } step(:upload_files) { # … } end end ```
-
checkpoint메서드를 사용한 수동 체크포인트: 장시간 실행되는step내부에서step.checkpoint를 호출하여 수동으로 체크포인트를 설정할 수 있습니다. 이는 Worker 종료 신호를 받았을 때 Job이 Grace Period 내에 작업을 중단하고 진행 상황을 저장하도록 돕습니다. ```ruby class DestroyRecordsJob < ActiveJob::Base include ActiveJob::Continuationsdef perform step(:destroy_records) do |step| Account.find_each(batch_size: 100) do |account| account.records.in_batches do |batch| batch.destroy_all step.checkpoint # 수동 체크포인트 end end end end end ```
-
cursor를 사용한 반복 작업 추적: 반복 작업에서 진행 상황을 정확히 추적하기 위해step.cursor를 사용합니다.step.set!(value)또는step.advance_from(value)메서드를 호출하여 커서 값을 저장하고 동시에 체크포인트를 생성합니다. Job 재개 시 이 커서 값이 복원되어 중단된 지점부터 작업을 이어서 수행할 수 있습니다. ```ruby class NotifyUsersJob < ActiveJob::Base include ActiveJob::Continuationsdef perform step(:notify_users) do |step| Account.find_each(start: step.cursor) do |account| account.users.find_each(start: step.cursor&.last) do |user| user.notify! step.set!([account.id, user.id + 1]) # 커서 설정 및 체크포인트 end step.set!([account.id + 1, nil]) # 다음 계정으로 이동 end end end end ```
Job이 중단되면 Interrupt 예외가 발생하고, around_perform 콜백에 의해 이 예외가 처리됩니다. 이후 Active Job은 현재 Job을 재시도(retry)하며, 이 과정에서 완료된 step 목록과 cursor 값을 저장합니다. 새로운 Worker가 재시도된 Job을 처리할 때, 저장된 정보를 바탕으로 이미 완료된 step을 건너뛰고 중단된 지점부터 작업을 재개합니다.
주의사항 및 고려사항
-
단계 독립성: 각
step은 독립적으로 실행되어야 하며, 이전step의 내부 상태에 의존해서는 안 됩니다. -
체크포인트 빈도: Worker의 Grace Period보다 더 자주
checkpoint를 호출해야 합니다. 그렇지 않으면 진행 상황이 저장되지 않은 채 Job이 강제 종료될 수 있습니다. -
데이터베이스 트랜잭션: 데이터베이스 트랜잭션 내부에서는
checkpoint를 호출할 수 없습니다. Rails는 이를 감지하고 예외를 발생시켜 데이터 일관성 문제를 방지합니다. -
isolatedStep:isolated로 표시된step은 항상 별도의 Job 호출에서 실행되어 단계 간 독립성을 보장하고, 장시간step이 시작되기 전에 진행 상황을 저장하는 데 유용합니다. -
커서의 직렬화:
cursor는 Integer, String, Array 등 직렬화 가능한 모든 Ruby 객체가 될 수 있습니다. -
테스트 도구:
active_job_continuation_test_helpers모듈을 통해interrupt_job_during_step과 같은 헬퍼 메서드를 사용하여 Job의 중단 및 재개 로직을 테스트할 수 있습니다.
실제 적용 및 기대 효과
Active Job Continuations는 Basecamp에서 6개월 이상 성공적으로 운영되고 있으며, 배포 시마다 10~40개의 Job이 중단되고 재개되는 상황을 처리하고 있습니다. 이는 Job이 Worker 종료 신호에 반응하여 스스로 빠르게 중단되도록 함으로써 배포 시간을 단축하는 부가적인 이점도 제공합니다. 이 기능은 Rails 8.1에 포함될 예정이며, SolidQueue와 Sidekiq 어댑터는 이미 지원하고 있습니다. 다른 Job 백엔드의 경우, queue_adapter.stopping? 메서드를 몽키 패치하여 쉽게 통합할 수 있습니다.