1 자동 동시성

Rails는 자동으로 다양한 작업을 동시에 수행할 수 있게 합니다.

기본값인 Puma와 같은 스레드 웹 서버를 사용할 때, 여러 HTTP 요청이 동시에 처리되며, 각 요청은 자체 controller 인스턴스를 가집니다.

내장된 Async를 포함한 스레드 Active Job 어댑터도 마찬가지로 여러 job을 동시에 실행합니다. Action Cable 채널도 이와 같은 방식으로 관리됩니다.

이러한 메커니즘들은 모두 여러 스레드를 사용하며, 각 스레드는 특정 객체(controller, job, channel)의 고유 인스턴스에 대한 작업을 관리하면서 전역 프로세스 공간(클래스와 그 설정, 전역 변수 등)을 공유합니다. 이러한 공유 요소를 수정하지 않는 한, 다른 스레드가 존재한다는 것을 대부분 무시할 수 있습니다.

이 가이드의 나머지 부분에서는 Rails가 이를 "대부분 무시할 수 있게" 만드는 메커니즘과, 확장 기능과 특별한 요구사항이 있는 애플리케이션에서 이를 사용하는 방법을 설명합니다.

2 Executor

Rails Executor는 애플리케이션 코드를 프레임워크 코드와 분리합니다: 프레임워크가 애플리케이션에서 작성한 코드를 호출할 때마다 Executor로 래핑됩니다.

Executor는 두 개의 콜백으로 구성됩니다: to_run과 to_complete. Run 콜백은 애플리케이션 코드 실행 전에 호출되고, Complete 콜백은 실행 후에 호출됩니다.

2.1 Default Callbacks

기본 Rails 애플리케이션에서 Executor callbacks은 다음과 같은 용도로 사용됩니다:

• autoloading과 reloading에 안전한 위치에 있는 스레드 추적
• Active Record query cache 활성화 및 비활성화
• 획득한 Active Record 연결을 pool에 반환
• 내부 캐시 수명 제한

Rails 5.0 이전에는 이러한 일부 기능들이 별도의 Rack middleware 클래스(예: ActiveRecord::ConnectionAdapters::ConnectionManagement)에 의해 처리되거나, ActiveRecord::Base.connection_pool.with_connection과 같은 메서드로 코드를 직접 래핑하여 처리되었습니다. Executor는 이러한 방식들을 하나의 더 추상적인 인터페이스로 대체합니다.

2.2 애플리케이션 코드 래핑하기

라이브러리나 컴포넌트를 작성할 때 애플리케이션 코드를 호출하는 경우, executor를 사용하여 래핑해야 합니다:

Rails.application.executor.wrap do
  # 여기에 어플리케이션 코드를 호출합니다
end

애플리케이션 코드를 실행하기 전에 각 스레드를 wrap해야 합니다. 따라서 만약 애플리케이션이 Thread.new나 스레드 풀을 사용하는 Concurrent Ruby 기능을 통해 다른 스레드에 작업을 수동으로 위임하는 경우, 블록을 즉시 wrap해야 합니다:

Thread.new do
  Rails.application.executor.wrap do
    # 여기에 코드 작성
  end
end

Executor는 안전하게 재진입이 가능합니다. 현재 스레드에서 이미 활성화되어 있다면, wrap은 아무 동작도 하지 않습니다.

애플리케이션 코드를 블록으로 감싸는 것이 비실용적인 경우(예를 들어, Rack API는 이를 까다롭게 만듭니다), run! / complete! 쌍을 사용할 수 있습니다:

Thread.new do
  execution_context = Rails.application.executor.run!
  # 여기에 코드 작성
ensure
  execution_context.complete! if execution_context
end

2.3 동시성

Executor는 현재 스레드를 Load Interlock의 running 모드로 전환합니다. 다른 스레드가 상수를 autoloading하거나 애플리케이션을 unloading/reloading하는 중이라면 이 작업은 일시적으로 블록됩니다.

3 Reloader

Executor와 마찬가지로, Reloader도 애플리케이션 코드를 감싸고 있습니다. 현재 스레드에서 Executor가 활성화되어 있지 않다면, Reloader가 대신 이를 호출하므로 둘 중 하나만 호출하면 됩니다. 이는 또한 Reloader가 수행하는 모든 작업(모든 콜백 호출 포함)이 Executor 내부에서 실행되도록 보장합니다.

Rails.application.reloader.wrap do
  # 여기에 애플리케이션 코드를 호출하세요
end

Reloader는 웹 서버나 job queue처럼 프레임워크 레벨의 장기 실행 프로세스가 애플리케이션 코드를 반복적으로 호출하는 경우에만 적합합니다. Rails는 웹 요청과 Active Job worker들을 자동으로 래핑하므로, 직접 Reloader를 호출할 일은 거의 없을 것입니다. 항상 Executor가 해당 사용 사례에 더 적합한지 고려해보세요.

3.1 Callbacks

wrapped 블록에 들어가기 전에, Reloader는 실행 중인 애플리케이션이 리로드되어야 하는지 확인합니다 -- 예를 들어 model의 소스 파일이 수정되었기 때문입니다. 리로드가 필요하다고 판단하면, 안전할 때까지 기다렸다가 계속 진행하기 전에 리로드를 수행합니다. 변경 사항 감지 여부와 관계없이 항상 리로드하도록 애플리케이션이 구성된 경우에는 대신 블록 끝에서 리로드가 수행됩니다.

Reloader는 to_run과 to_complete callback들도 제공합니다. 이들은 Executor의 callback들과 동일한 시점에 호출되지만, 현재 실행이 애플리케이션 리로드를 시작했을 때만 호출됩니다. 리로드가 필요하지 않다고 판단될 때는, Reloader는 다른 callback 없이 wrapped 블록만 실행합니다.

3.2 Class Unload

리로딩 프로세스의 가장 중요한 부분은 모든 autoload된 클래스들이 제거되고 다시 로드될 준비가 되는 Class Unload입니다. 이는 reload_classes_only_on_change 설정에 따라 Run 또는 Complete callback 직전에 발생합니다.

종종 Class Unload 직전이나 직후에 추가적인 리로딩 작업을 수행해야 할 필요가 있습니다. 이를 위해 Reloader는 before_class_unload와 after_class_unload callback들을 제공합니다.

3.3 동시성

Reloader는 오직 장시간 실행되는 "최상위 레벨" 프로세스에서만 호출되어야 합니다. Reloader가 리로드가 필요하다고 판단하면, 다른 모든 스레드가 Executor 호출을 완료할 때까지 블로킹되기 때문입니다.

만약 이것이 Executor 내에서 대기 중인 부모 스레드가 있는 "자식" 스레드에서 발생한다면, 피할 수 없는 교착 상태가 발생할 것입니다: 리로드는 자식 스레드가 실행되기 전에 발생해야 하지만, 부모 스레드가 실행 중일 때는 안전하게 수행될 수 없습니다. 자식 스레드는 대신 Executor를 사용해야 합니다.

4 프레임워크 동작

Rails 프레임워크 컴포넌트들도 자체적인 동시성 요구사항을 관리하기 위해 이러한 도구들을 사용합니다.

ActionDispatch::Executor와 ActionDispatch::Reloader는 각각 제공된 Executor나 Reloader로 요청을 감싸는 Rack 미들웨어입니다. 이들은 기본 애플리케이션 스택에 자동으로 포함됩니다. Reloader는 코드 변경이 발생했을 때 새로 로드된 애플리케이션 복사본으로 도착하는 HTTP 요청이 처리되도록 보장합니다.

Active Job도 Reloader로 작업 실행을 감싸서, 큐에서 각 작업을 실행할 때 최신 코드를 로드합니다.

Action Cable은 대신 Executor를 사용합니다: Cable 연결이 클래스의 특정 인스턴스에 연결되어 있기 때문에, 도착하는 모든 WebSocket 메시지에 대해 리로드하는 것이 불가능합니다. 메시지 핸들러만 감싸지며, 장시간 실행되는 Cable 연결이 새로운 수신 요청이나 작업에 의해 트리거되는 리로드를 방해하지는 않습니다. 대신 Action Cable은 Reloader의 before_class_unload 콜백을 사용하여 모든 연결을 끊습니다. 클라이언트가 자동으로 재연결할 때, 새로운 버전의 코드와 통신하게 됩니다.

위의 것들은 프레임워크의 진입점이므로, 각각의 스레드가 보호되도록 보장하고 리로드가 필요한지 결정할 책임이 있습니다. 다른 컴포넌트들은 추가 스레드를 생성할 때만 Executor를 사용하면 됩니다.

4.1 설정

Reloader는 config.enable_reloading이 true이고 config.reload_classes_only_on_change가 true일 때만 파일 변경을 체크합니다. 이것들은 development 환경의 기본값입니다.

config.enable_reloading이 false일 때(production에서 기본값), Reloader는 단순히 Executor로의 패스스루만 수행합니다.

Executor는 데이터베이스 연결 관리와 같은 중요한 작업을 항상 수행합니다. config.enable_reloading이 false이고 config.eager_load가 true일 때(production 기본값), 리로딩이 발생하지 않으므로 Load Interlock이 필요하지 않습니다. development 환경의 기본 설정에서는 Executor가 Load Interlock을 사용하여 상수가 안전할 때만 로드되도록 보장합니다.

5 Load Interlock

Load Interlock은 멀티스레드 런타임 환경에서 autoloading과 reloading을 활성화할 수 있게 해줍니다.

한 스레드가 적절한 파일에서 클래스 정의를 평가하여 autoload를 수행할 때, 다른 스레드가 부분적으로 정의된 상수를 참조하지 않도록 하는 것이 중요합니다.

마찬가지로, 애플리케이션 코드가 실행 중이지 않을 때만 unload/reload를 수행하는 것이 안전합니다: reload 후에는 예를 들어 User 상수가 다른 클래스를 가리킬 수 있습니다. 이 규칙이 없다면, 잘못된 타이밍의 reload로 인해 User.new.class == User 또는 심지어 User == User가 false가 될 수 있습니다.

이러한 제약 조건들은 모두 Load Interlock에 의해 처리됩니다. Load Interlock은 현재 어떤 스레드가 애플리케이션 코드를 실행 중이거나, 클래스를 로드 중이거나, autoloaded 상수를 언로드 중인지 추적합니다.

한 번에 하나의 스레드만 load 또는 unload할 수 있으며, 이를 수행하기 위해서는 다른 스레드가 애플리케이션 코드를 실행하지 않을 때까지 기다려야 합니다. 스레드가 load를 수행하기 위해 대기 중이라도, 다른 스레드의 load를 막지 않습니다(실제로는 서로 협력하여 각각 대기 중인 load를 차례로 수행한 후 모두 함께 다시 실행을 재개합니다).

5.1 permit_concurrent_loads

Executor는 블록 동안 자동으로 running lock을 획득하며, autoload는 언제 load lock으로 업그레이드하고 이후 다시 running으로 전환할지 알고 있습니다.

하지만 Executor 블록(모든 애플리케이션 코드 포함) 내에서 수행되는 다른 blocking 작업들은 불필요하게 running lock을 유지할 수 있습니다. 다른 스레드가 autoload 해야 하는 상수를 만나면 데드락이 발생할 수 있습니다.

예를 들어, User가 아직 로드되지 않았다고 가정할 때, 다음 코드는 데드락이 발생할 것입니다:

Rails.application.executor.wrap do
  th = Thread.new do
    Rails.application.executor.wrap do
      User # 내부 스레드가 여기서 대기합니다; 다른 스레드가 실행되는 동안
           # User를 로드할 수 없습니다
    end
  end

  th.join # 외부 스레드가 여기서 대기하며, 'running' 잠금을 유지합니다
end

교착 상태를 방지하기 위해, 외부 thread는 permit_concurrent_loads를 사용할 수 있습니다. 이 메서드를 호출함으로써, thread는 제공된 block 내부에서 자동 로드될 수 있는 어떤 constant도 역참조하지 않을 것을 보장합니다. 이 약속을 지키는 가장 안전한 방법은 blocking 호출에 최대한 가깝게 배치하는 것입니다.

Rails.application.executor.wrap do
  th = Thread.new do
    Rails.application.executor.wrap do
      User # 내부 스레드가 'load' 락을 획득하고,
           # User를 로드하고, 계속 진행할 수 있음 
    end
  end

  ActiveSupport::Dependencies.interlock.permit_concurrent_loads do
    th.join # 외부 스레드가 여기서 대기하지만, 락을 가지고 있지 않음
  end
end

다음은 Concurrent Ruby를 사용하는 예시입니다:

Rails.application.executor.wrap do
  futures = 3.times.collect do |i|
    Concurrent::Promises.future do
      Rails.application.executor.wrap do
        # 여기서 작업을 수행하세요
      end
    end
  end

  values = ActiveSupport::Dependencies.interlock.permit_concurrent_loads do
    futures.collect(&:value)
  end
end

5.2 ActionDispatch::DebugLocks

애플리케이션이 deadlocking 상태이고 Load Interlock이 관련되어 있다고 생각되는 경우, config/application.rb에 ActionDispatch::DebugLocks middleware를 임시로 추가할 수 있습니다:

config.middleware.insert_before Rack::Sendfile,
                                  ActionDispatch::DebugLocks

애플리케이션을 재시작하고 deadlock 조건을 다시 발생시키면, /rails/locks는 현재 interlock에 알려진 모든 thread의 요약 정보를 보여줍니다. 여기에는 thread가 보유하거나 대기 중인 lock level과 현재 backtrace가 표시됩니다.

일반적으로 deadlock은 interlock이 다른 외부 lock이나 blocking I/O 호출과 충돌할 때 발생합니다. 이를 발견하면 permit_concurrent_loads로 래핑할 수 있습니다.