2025 02 22

2025-02-22¶

싱글코어 CPU에서도 병렬처리 가능할까?¶

Qs) 응답에 1초가 걸리는 API, 10개의 API Call -> 병렬 처리 시 싱글코어에서도 1초면 처리가능?

각 API 호출이 네트워크 1초 I/O가 거의 전부라면 CPU 연산 적기떄문에,
OS는 I/O 기다리는 동안 쓰레드 대기 상태로 전환하여 다른 쓰레드 처리하러 감. (컨텍스트 스위칭)
- OS에서 커널 쓰레드가 I/O 대기 시, 기존 쓰레드 대기로 돌리고, CPU를 다른 작업에 할당하는 것 기억하지?
거의 1초내의 응답을 받을 것

Qs) 이벤트 루프가 계속 돌아간다는 것의 의미

대부분의 이벤트 루프 기반 프레임워크는 OS의 비동기 I/O 메커니즘을 차용
- 대기 상태: 이벤트 발생 전까지 해당 쓰레드는 OS 호출로 인해 블록되므로 CPU를 불필요하게 점유하지 않음.
- 이벤트 발생 시: OS가 스레드를 깨워서 이벤트 처리 시작, 처리 완료시 대기 상태 전환

Qs) 싱글 코어에서 이벤트 루프?

단일 코어에서 이벤트 루프, 사용자 요청 처리 등을 단일 코어에서 처리한다면, 컨텍스트 스위칭을 통해 효율적 관리

이벤트 루프 아키텍쳐¶

thread-per-request 방식이 아닌, 단일/소수 쓰레드로 요청 비동기적 처리 하도록 설계 1. 요청 수신 및 초기 처리
- 서버 소켓 생성 : 네트워크 소켓 생성 후 소켓에 서버 IP/Port 할당
- 논블로킹 모드 : 비동기 I/O를 위한 논블로킹 모드 전환, O_NONBLOCK 플래그 전환
  1. 리스닝 소켓
    - 보통 하나 생성
    - 클라이언트의 요청 기다림.
    - 지정된 포트에 바인딩한 후, 클라이언트 연결 요청.
  2. 클라이언트 소켓
    - 클라이언트 연결 수립시마다 하나씩 생성
    - 각 클라이언트와 실제 데이터 통신 (읽기/쓰기) 담당
    - 이 소켓도 논블로킹, 이벤트 루프에 등록
    - 해당 소켓에서 읽기/쓰기 이벤트 발생시마다 이벤트 루프에서 처리
- 소켓 등록 : 생성한 논블로킹 소켓을 이벤트 루프에 등록
  - 이벤트 루프 : 단일/소수 쓰레드에서 여러 소켓의 상태(연결,쓰기,읽기) 감시하고, 이벤트 발생시 해당 작업 처리 역할
  - 리눅스 : epoll_create()로 epoll 인스턴스, 소켓을 epoll 관심 목록에 추가
    - 관심 이벤트 (EPOLLIN, EPOLLOUT) 지정
- 이벤트 루프는 등록된 모든 소켓 감시하기 위해 주기적으로 시스템 콜 호출
  - epoll_wait: epoll 인스턴스 등록된 소켓들 중, 지정된 이벤트 발생했는지 확인
- 요약
  - 소켓 등록을 통해 여러 소켓 한번에 감시
  - 논블로킹 모드를 이용해 요청/응답 시 블로킹 방지
  - 시스템 콜 활용해 이벤트 발생때 까지 효율적 대기

이벤트 발생 및 요청 처리
- 요청 도착: 클라이언트로 부터 HTTP 요청 도착시, OS가 해당 소켓에 이벤트 발생
- 이벤트 디스패치: 이벤트 루프 깨어나 해당 이벤트 확인, 그 이벤트에 연결된 콜백/핸들러 호출
  - 핸들러에서 요청 데이터 읽고, HTTP 요청 파싱후 어플리케이션 로직으로 전달
- 비동기 처리 시작
  - 어플리케이션 로직 필요에 따라 추가 I/O 비동기적 실행.
  - 별도의 비동기 작업 등록, 이벤트 루프는 다른 이벤트 처리 계속 진행
이벤트 루프에서 응답 준비
- 비동기 작업 대기: 결과 처리하기 위한 콜백이 실행. 콜백은 이벤트 루프에서 호출
- 응답 준비: 논블로킹 방식으로 소켓에 전송

이벤트 루프가 CPU를 사용하는 방식
- busy waiting 처럼 보이지만, 실제로는 OS의 비동기 I/O 호출에 의해 블록되었다가 이벤트 발생시 깨어나서 처리
- 이벤트 루프 자체가 CPU 코어를 점유하여 다른 작업 방해하진 않음
  - 단일 코어 환경에서도 이벤트 루프 블록 상태, 각종 콜백 실행 사이에서 효율적으로 컨텍스트 스위칭 수행