회사에서 새로운 task(스케줄을 가지고 주기적으로 실행시키는 작업) 작업을 완성하고 해당 작업을 배포해야할 상황이 있었다.
하지만 해당 task 작업은 매우 무겁기도,
데이터 양에 비례해서 소요시간이 증가하므로 (속도제한 이슈 + 배치성 작업이라 많을땐 2시간까지도..)
기존에 있던 태스크 서버(멀티 스레드 방식)에 배포할지
멀티 프로세스 방식의 태스크 서버를 새로 구축하여 해당 서버에서 task 작업을 작동시킬지 고민이 되었다.
멀티 스레드와 멀티 프로세스의 보편적인 비교
우선 보편적으로 흔히 알고 있는 멀티 스레드 방식과 멀티 프로세스 방식의 비교를 해보겠다.
멀티 스레드 (Multi-Threading)
장점
- 멀티스레드 방식은 각 스레드가 메모리를 공유하기 때문에 프로세스 간 통신이 필요없다.
- 스레드 간 전환에서 소요되는 오버헤드가 작기 때문에, 멀티프로세스 방식보다 빠른 성능을 기대할 수 있다.
- 스레드는 프로세스보다 가벼우므로, 더 많은 스레드를 생성할 수 있다.
단점
- 스레드 간 동기화 문제가 발생할 수 있다. 여러 스레드가 동시에 같은 자원에 접근할 때, 경쟁 상태(race condition)가 발생할 수 있으며, 이는 프로그래머가 별도의 동기화 메커니즘을 구현해야한다.
- 한 스레드에서 예외가 발생하면 해당 프로세스의 모든 스레드가 영향을 받을 수 있다.
멀티 프로세스 (Multi-Processing)
장점
- 각 프로세스는 독립된 메모리 공간을 가지기 때문에, 하나의 프로세스에서 Exception이 발생하더라도, 다른 프로세스들에 영향을 주지 않는다.
- 멀티스레드 방식보다 안정적이다.
단점
- 메모리를 공유하지 않기 때문에, 프로세스 간 통신이 필요할때 추가적인 오버헤드가 발생할 수 있다.
- 프로세스 생성 및 소멸 비용이 스레드보다 더 많이 들어간다.
Task(스케줄 작업) 상황에서의 선택
하지만 앞서 말한 상황처럼 구체적인 상황에서는 비교할 사항들이 더 구체적으로 존재한다.
이에 대해 고민한 내용이다.
개발환경은 코프링(kotlin+spring) 이다.
task는 독립적인 작업이라 task간의 공유는 일어나지 않는다.
task 작업 자체가 가벼운 작업도 있지만, 무거운 작업들도 여러모로 있어 메모리 할당과 메모리 사용과 같은 메모리 측면이 중요함을 전제에 깔고 가자.
멀티 스레드 방식
(task 서버는 항상 떠있고 스케줄에 맞춰 task를 실행할 스레드 생성)
장점
- 하나의 프로세스가 항상 떠있으므로 처음 프로세스를 띄울때만 스프링 빈 초기화 비용을 지불하고 그 이후 몇 개의 task를 실행시키더라도 스프링 초기화 비용은 지불하지 않아도 됨
- 멀티스레드들이 메모리를 공유하므로 최적으로 메모리를 사용할 수 있음.
단점
- 한 프로세스에서 멀티스레드로 동작하므로 한 스레드(한 task)의 exception이 다른 스레드에게 영향을 미칠 수 있음
멀티 프로세스 방식
(task마다 매번 프로세스를 새로 띄우는 방식)
장점
- 한 task마다 한 프로세스를 실행시키므로 하나의 task(프로세스)의 exception이 다른 task(프로세스)에 영향을 미치지 않음.
단점
- task 마다 프로세스가 떠야하므로 task를 돌려야할때마다 스프링 초기화를 해야하므로 불필요한 cost를 지불해야함 (작은 task의 경우 배보다 배꼽이 큰 경우도..)
- 멀티 프로세스들이 메모리를 각각 나누어 점유함으로써 한 프로세스가 점유하는 메모리가 부족할 수 있고 프로세스들간의 메모리 할당을 최적으로 할당해주기 어려우므로 메모리 최적화 관점에서 비효율적
결론
그래서 내린 결론은
작고 가볍고 비즈니스적으로 실행 오류(실패)가 크게 문제되지 않는 task들은 멀티스레드 방식으로,
엄청 무거워서 다른 스레드에 영향을 줄 가능성이 크거나,
다른 테스크에 영향을 받지 않아야하는 (강하게 실패하지 않아야하는) task들은 멀티프로세스 방식으로,
실행시키는 것이 적절하다고 결론을 내렸다.
