Blocking I/O, Non-Blocking I/O

22·2024년 4월 1일

Spring

목록 보기
3/5

I/O 란 ?

  • 운영체제 측면에서 컴퓨터 시스템이 외부의 입출력 장치들과 데이터를 주고받는 것을 의미한다.

웹 애플리케이션 측면에서는 ?

  • 파일 I/O, DB I/O ,, 네트워크 I/O!

Blocking I/O?

  • 하나의 스레드가 I/O 에 의해서 차단되어 대기하는 것.
  • 문제점을 보완하기 위해 멀티스레딩 기법으로 차단된 그 시간을 효율적으로 쓸 수 있다.
  • 하지만 멀티스레딩도 문제가 있다.

멀티스레딩의 문제

  • JVM 의 디폴트 스택 사이즈는 64bit => 1024 KB 으로, 64,000명이 동시 접속을 한다면 64GB 정도의 메모리가 추가로 필요하게 된다.

  • Java 웹 어플리케이션은 요청당 하나의 스레드를 할당한다. 만약에! 또 다른 작업을 처리하기 위해 스레드를 추가로 할당하게 된다면(멀티스레딩) 과다한 메모리 사용으로 오버헤드가 발생할 수 있다.

  • 대량의 요청이 발생하게 된 경우 스레드 풀에 유휴 스레드가 없을 경우, 스레드 풀에서 응답지연이 발생할 수 있다.

Non-Blocking I/O

  • Blocking I/O 와 반대로 스레드가 차단되지 않는다!
  • 차단되지 않기 때문에 하나의 스레드로 많은 수의 요청을 처리할 수 있다.
  • 더 적은 수의 스레드를 사용하기 때문에 Blocking I/O에서 멀티스레딩을 사용할 때의 문제점들이 생기지 않는다.
  • 단점,, 스레드 내부에 cpu 를 많이 사용하는 작업이 포함된 경우 성능에 악영향을 준다. (왜지? 이건 어떤 경우에도 그렇지 않나..)
  • Blocking I/O 요소가 포함된 경우 Non-Blocking 의 이점이 없다.

Spring Framework , Blocking I/O, Non-Blocking I/O

  • Spring MVC 는 Blocking I/O 를 사용한다.
  • Spring WebFlux 는 Netty 같은 비동기 Non-Blocking I/O 기반의 서버 엔진을 사용함으로써 적은 수의 스레드로 많은 수의 요청을 처리한다.
    즉, 적은 컴퓨팅 파워로 고성능의 애플리케이션을 운영할 수 있다.

Non-Blocking I/O 방식의 통신이 적합한 시스템은?

  • 고려해야할 것: 학습 난이도, 리액티브 프로그래밍 경험이 있는 개발 인력을 확보할 수 있는가 ?
  • 대량의 요청 트래픽이 발생하는 시스템 : 서버 증설이나 VM 확장 등을 통해 트래픽을 분산할 수 있겠지만 그만큼의 높은 비용을 지불해야 한다.
  • 마이크로 서비스 기반 시스템 : MSA 특성상 서비스들 간에 많은 수의 I/O 가 발생한다. 따라서 특정 서비스들 간의 통신에서 Blocking 으로 인한 응답 지연이 발생하게 된다면 해당 서비스뿐만 아니라 연쇄 작용으로 다른 서비스들에도 영향을 미칠 가능성이 높다. (MSA 에는 반드시 필요하다고 할 수 있다!)
  • 스트리밍 또는 실시간 시스템 : 무한한 데이터 스트림을 전달받아서 효율적으로 처리할 수 있다.


Reference

스프링으로 시작하는 리액티브 프로그래밍 chater3

0개의 댓글