스레들 풀 방식 vs 이벤트 루프 방식

728x90

서버구축실습에서 배운 내용 간단하게 정리해보았습니다.

이 두 가지 모델은 서버에서 요청을 처리하는 방식이 다르다.

Thread-per-Request 모델 (멀티스레드)
- 요청이 올 때마다 새로운 스레드를 생성하거나 스레드 풀에서 할당하여 요청을 처리함.
- 하나의 요청은 하나의 스레드에서 실행됨.
- 스레드가 많아질수록 컨텍스트 스위칭 비용이 증가하여 성능 저하 가능성이 있음.
Event Loop 모델 (싱글스레드 비동기)
- 하나의 스레드에서 비동기 I/O를 활용하여 여러 요청을 처리함.
- 요청이 들어오면 이벤트 루프가 콜백을 등록하고, 비동기 작업(예: 파일 읽기, 네트워크 요청)이 끝나면 다시 실행됨.
- CPU를 많이 쓰는 작업에는 적합하지 않음 (CPU-bound 작업에서는 스레드 사용이 필요).

CPU/코어에서 실행 중이던 프로세스/스레드가 다른 프로세스/스레드로 교체되는 것

컨텍스트는 CPU가 현재 실행 중인 프로세스(또는 스레드)의 상태 정보를 의미합니다. 여기에는 다음과 같은 정보가 포함됩니다.

즉, 컨텍스트는 현재 프로세스가 어떤 상태인지 나타내는 데이터들의 집합!

컨텍스트 스위칭 과정은 다음과 같이 진행된다.

현재 실행 중인 프로세스(또는 스레드)의 컨텍스트를 저장
- CPU 레지스터 값을 PCB(Process Control Block)에 저장.
- 프로세스의 상태 정보를 업데이트.
새로운 프로세스(또는 스레드)의 컨텍스트를 복원
- 스케줄러가 다음 실행할 프로세스를 선택.
- 해당 프로세스의 PCB에서 저장된 상태를 복원.
새로운 프로세스(또는 스레드) 실행 시작
- 이전에 중단된 지점부터 다시 실행.

어떤 작업이 더 많은 부담을 주는지에 따라 실행 방식이 달라진다.

CPU-bound 작업 (CPU 연산이 많이 필요한 작업)
- 예: 데이터 압축, 이미지 처리, 암호화, 머신러닝 연산
- 이런 작업은 CPU를 많이 사용하므로 멀티스레드나 멀티프로세싱을 사용하여 병렬 실행하는 것이 효과적임.
- 싱글스레드 기반의 이벤트 루프 모델에서는 CPU-bound 작업이 끝날 때까지 다른 작업이 블로킹될 수 있음.
I/O-bound 작업 (입출력 대기 시간이 많은 작업)
- 예: 데이터베이스 쿼리, 파일 읽기/쓰기, 네트워크 요청
- 이런 작업은 CPU 사용이 적고 대부분 I/O 대기 시간 때문에 느려짐.
- 이벤트 루프 기반의 비동기 모델이 적합하며, 여러 요청을 동시에 처리할 수 있음.

CPU 코어의 개수에 따라 처리 모델이 다르게 적용된다.

싱글코어 (Single Core)
- CPU-bound 작업에서는 멀티스레딩을 해도 큰 성능 향상이 없음 (한 번에 하나의 작업만 실행 가능).
- I/O-bound 작업에서는 비동기(Event Loop) 모델을 사용하면 CPU가 효율적으로 활용됨.
- 코어가 한 개 일 때는 싱글스레드 방식이 도움이 된다
멀티코어 (Multi Core)
- CPU-bound 작업에서는 멀티스레딩 또는 멀티프로세싱을 활용하여 성능을 향상할 수 있음.
- Python에서는 GIL(Global Interpreter Lock) 때문에 멀티스레딩으로 CPU를 100% 활용하기 어렵지만, 멀티프로세싱을 사용하면 해결 가능.
- Java, C++, Go 등은 멀티스레딩을 활용하여 멀티코어 성능을 극대화할 수 있음.

Thread-per-Request Event Loop

728x90

코딩기록장