스레드 중단 원인

Ruby 스레드가 멈추는 주요 원인들은 다음과 같습니다.

1. 데드락 (Deadlocks)

두 스레드가 서로가 점유한 뮤텍스를 기다리며 진행할 수 없는 상태입니다. Ruby는 모든 스레드가 멈췄을 때 데드락을 감지하여 오류를 발생시키지만, 다른 활성 스레드가 있다면 감지하지 못하고 프로그램이 계속 실행될 수 있습니다. 데이터베이스에서도 유사한 데드락이 발생할 수 있으며, 이는 오류로 감지됩니다. 해결책은 뮤텍스 획득 순서를 일관되게 유지하는 것입니다.

2. 라이브락 (Livelocks)

스레드가 계속 실행되지만 실제로는 아무런 진전을 이루지 못하는 상태입니다. try_lock을 사용하여 뮤텍스를 반복적으로 시도하는 루프에서 발생할 수 있으며, CPU를 소모하면서도 작업은 완료되지 않습니다. 데이터베이스에서도 발생할 수 있으며, 데드락과 마찬가지로 일관된 잠금 순서가 해결책입니다.

3. 장시간 CPU 소모 작업 (Long-running CPU)

순수 Ruby 코드에서는 전역 인터프리터 락(GVL)과 스케줄러 덕분에 특정 스레드가 CPU를 완전히 독점하기 어렵습니다. `Thread

priority`를 통해 스레드의 시간 할당량(time slice)을 조절할 수 있지만, 다른 스레드의 작업을 완전히 막지는 못합니다. Sidekiq과 같은 Gem은 스레드 우선순위를 조절하여 의도치 않은 타임아웃 및 스레드 기아 상태를 줄이기도 합니다.

4. 장시간 IO 작업 (Long-running IO)

스레드를 포화시키는 가장 흔한 시나리오입니다. 파일 다운로드와 같은 장시간 IO 작업은 스레드를 점유하여 다른 요청을 처리하지 못하게 합니다. 예를 들어, 5개의 스레드를 사용하는 Puma 서버에서 5개의 느린 클라이언트 다운로드가 발생하면 모든 스레드가 포화되어 6번째 요청은 오랜 시간 대기하게 됩니다. 이러한 작업은 비동기 작업 큐나 외부 서비스로 오프로드하는 것이 이상적입니다.

5. 네이티브 확장 (Native Extensions)

C/Rust/Zig 등으로 작성된 네이티브 확장은 Ruby 런타임의 제어를 덜 받기 때문에, 장시간 실행되는 네이티브 코드는 Ruby 스케줄러의 영향을 받지 않고 모든 런타임을 독점할 수 있습니다. OpenSSL::KDF.pbkdf2_hmac과 같은 함수를 과도하게 호출할 경우 다른 Ruby 스레드의 실행이 크게 지연될 수 있습니다. 중요한 경로에서는 이러한 확장의 성능을 주의해야 합니다.

스레드 종료 기법 및 안전한 사용

1. `Thread

raise와 Thread

kill`의 위험성

`Thread

raise는 대상 스레드 내부에 오류를 발생시켜 종료를 시도하지만, 이 오류를 rescue 블록에서 잡아 처리하거나 retry할 수 있어 예측 불가능한 동작을 초래할 수 있습니다. 또한 ensure 블록의 실행을 방해하여 중요한 정리 작업을 건너뛸 수 있습니다. Thread

kill은 스레드를 즉시 중지시키며 rescue할 수 없지만, 이 역시 ensure` 블록의 실행을 방해하여 데이터 손상이나 리소스 누수를 야기할 수 있습니다. 이러한 메서드는 “공식적인” 스레드 종료 방식이지만, 매우 위험하므로 특별한 경우가 아니면 사용하지 않는 것이 좋습니다.

2. timeout 모듈 사용 금지

Ruby 표준 라이브러리의 timeout 모듈은 `Thread

raise를 기반으로 하므로, 위에서 언급된 모든 위험을 내포하고 있습니다. rack-timeout과 같은 Gem을 사용해야 하는 경우, term_on_timeout` 설정을 활용하여 타임아웃 시 해당 워커 프로세스를 종료함으로써 잠재적인 상태 손상을 격리하는 것이 안전합니다.

3. Thread.handle_interrupt를 통한 안전한 중단

Thread.handle_interrupt는 스레드 외부에서의 인터럽트(예: kill, raise, 프로그램 종료, 시그널)에 대한 스레드의 반응을 제어할 수 있는 저수준 인터페이스입니다. 이를 통해 특정 코드 블록 내에서 ensure 블록이 항상 실행되도록 보장할 수 있습니다.

• ExceptionClass => :never: 해당 예외 클래스(및 그 자손)는 블록 내 코드 실행을 절대 중단시키지 않습니다.

• ExceptionClass => :on_blocking: 해당 예외는 IO 작업, sleep, 뮤텍스 대기 등 블로킹 작업 중에만 발생합니다.

• ExceptionClass => :immediate: 해당 예외는 즉시 발생하며, 기본 동작과 유사합니다.

`Thread

kill에 의한 인터럽트는 Object => :never 또는 Integer => :never를 사용하여 제어할 수 있습니다. handle_interrupt는 Sidekiq이나 Async와 같은 성숙한 프레임워크에서 중요한 정리 작업을 보장하는 데 사용됩니다. 그러나 스레드가 아직 시작되지 않은 경우에는 handle_interrupt`가 적용되기 전에 오류가 발생할 수 있습니다.

4. Puma 서버의 스레드 관리

Puma는 기본적으로 SIGINT 시그널(Ctrl+C)을 받으면 현재 진행 중인 요청이 완료될 때까지 기다립니다. 클러스터 모드(-w 플래그 사용)에서는 worker_shutdown_timeout (기본 30초) 설정으로 워커 종료 대기 시간을 제어할 수 있으며, force_shutdown_after 설정을 통해 강제 종료를 시도할 수도 있습니다. 그러나 Puma는 개별 스레드를 직접 종료하는 기능을 제공하지 않으며, 문제를 해결하는 주요 방법은 서버 재시작입니다.