2024.05.21 - [Spring/대용량 트래픽] - CPU Bound vs I/O Bound
이전 글에서는 CPU, I/O Bound에 대해서 알아봤다.
이번에는 I/O Bound관점에서 더 자세히 다루고자 한다.
- Sync(동기) : 순차적인 작업의 실행
먼저 요청한 작업이 완료될때까지 기다림. → 응답을 받아야 다음 요청을 함.
- ASync(비동기) : 요청한 작업의 종료를 기다리지않고, 계속 요청함.
완료순서가 보장되지 않는다.
Main Thread는 비동기적으로 요청한 스레드들의 응답이 오기까지 종료되지 않도록, join으로 명시해줘야한다.
Kafka와 같이 메세지 시스템, 즉 메세지 브로커에게 메세지를 전달하여, 별도의 시스템에서 특정로직을 동작하게 하는것 또한 비동기 로직이라고 한다.
위 그림은 소셜서비스 가상 시나리오이다. 어떤 유저 A가 글을 적었고, A를 팔로우하고있는 유저에게 앱푸시를 한다고 가정해보자. Sync(동기)로 위 과정을 진행한다면, 팔로우하는 모든 사람들에게 앱푸시를 보내고, 클라이언트한테 글작성 응답을 주는 것은 너무 느리다. 그래서 메세지 브로커에게 할 작업을 던져주고, 글작성은 바로 응답을 받고, 메세지 브로커와 앱 사이에서는 비동기적으로 앱푸시를 진행하게된다.
- Block : 대기있음
Sync와 연관있다.
- Non-Block : 대기없음
ASync와 연관있다.
연결이 없다면 기다리는 것이아니라, null 값을 리턴한다.
여러가지 I/O 작업을 번갈아가며 진행할수 있다.
ex) 하나의 스레드에서 여러소캣연결도 할 수 있다.(메모리 리소스 관점에서 효율적)
근데, null값을 계속 가져온다면 불필요한 CPU 리소스 낭비이다.
이러한 문제점의 해결책이 바로 I/O Multiplexing이다.
I/O Multiplexing
I/O 요청 결과에 대해서 커널에서 event단위로 알려준다면?
- event 등록 후 대기
- 연결 or 데이터 수신시 커널로부터 event 전달받음
- 다수의 소캣에 대해 이벤트 등록가능
조금 더 세분화해보면 연결담당 스레드, 연결이후 처리담당 스레드인 워커스레드로 분리하여 운영한다.
아무리 event 기반 Multiplexing 이더라도, 하나의 스레드에서 많은 데이터처리를 하거나 지연이 발생하면 다른 요청들이 대기를 해야하기 때문이다.
2024.05.22 - [Spring/대용량 트래픽] - Spring MVC와 Webflux
'Spring > 대용량 트래픽' 카테고리의 다른 글
Spring Webflux Reactor와 다양한 연산자 (0) | 2024.05.22 |
---|---|
Spring MVC와 Webflux (0) | 2024.05.22 |
CPU Bound vs I/O Bound (1) | 2024.05.21 |
Spring Webflux란? (0) | 2024.05.21 |
Redis Replication (0) | 2024.05.21 |