자바의 NIO (java.nio)

JDK4에서 나오고 JDK7에서 java.nio2로 업데이트 하였다.

NIO의 의미는 비동기-논블로킹 방식의 새로운 입출력이라는 의미이다. (Non-blocking) New Input/Output

공식문서에는 NIO를 New I/O라고 소개하는데, 그 이유는 내부의 모든 I/O가 논블로킹으로 동작하는건 아니기 때문이다.

JDK7부터 nio2를 제공해준다.

📌 스프링에서 제공하는 Webflux와 Netty 서버는 자바의 NIO 기반으로 만들어져있다. 

 

📌 짧막한 자바 역사 이야기

자바의 비동기처리 - Thread 객체는, 거의 초창기 버전부터 지원하는 기능이었다. (물론 그 당시에는 최적화가 구렸지만)

 

다만 웹앱서버인 톰캣(WAS)은 결국 서블릿으로 동작한다. 그래서 과거에는 멀티스레드같은거 지원 안했다.

왜냐하면 자바의 서블릿은 [원래 한개의 요청 = 한 스레드 = 한 개의 서블릿] 처리만 가능하게 설계되었기 때문이다.

하지만 웹 서버에서 연결을 유지한 채, 지속적으로 데이터를 받을 때 속도가 너무 느리다는 단점이 있었다.

 

그래서 2009년 1월, 서블릿 3.0 스펙에서부터 응답을 비동기로 치리가능하게 바뀌었다. (이는 스프링MVC 3.2부터 지원)

이제 서블릿을 실행한 스레드가 없어지더라도, 별도의 스레드를 통해 응답을 나중에 반환할 수 있다.
이는 JDK1.5에 추가된 Callable 등을 사용해서 구현되었다. NIO 아니다.

참고로 톰캣 7.0은 2010년 7월에 베타 버전을 출시했다.

즉, 아래와 같이 한 서블릿에서 여러 개의 멀티스레드를 돌릴 수 있게 바뀌었다.

@Slf4j
@WebServlet(urlPatterns = "/hello", asyncSupported = true)
public class AsyncHelloWorldServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
        throws ServletException, IOException {

        // 비동기 처리를 위한 AsyncContext 객체
        final AsyncContext asyncContext = req.startAsync();

        var thread_T2 = new Thread(() -> {
            var response = (HttpServletResponse) asyncContext.getResponse();
            response.setContentType("text/plain");
            response.setCharacterEncoding("UTF-8");

            try {
                response.getWriter().println("HELLO");
            } catch (IOException e) {...}

            logger.info("complete response");
            asyncContext.complete(); // complete() 메서드를 통해 스레드를 종료시킴
        });

        thread_T2.start(); // 1번 스레드 출발
    }
}

위와 같이 작성하면, 서블릿은 이렇게 동작한다.

1. 제일 앞에 있는 T1(클라이언트 요청을 받은 스레드)는 서블릿의 doGet()을 실행한다.
2. T1은 서블릿의 doGet() 메서드에서  AsyncContext 객체를 만든다.
3. T1은 AsyncContext를 이용해서 비동기로 처리할 새로운 스레드(T2)를 생성하고, 시작한다.
4. T1은 자기 할일이 다 끝났기 때문에 평소처럼 서블릿 객체를 반환하고, 스레드를 종료한다.
5. (현재 T1은 없어진 상황) T2는 별도의 스레드에서 자기 할일을 한다. 
   이때 필요한 request, response는 AsyncContext 에서 받아올 수 있다. 
6. (현재 T1은 없어진 상황) T2 스레드는 AsyncContext를 이용해 클라이언트에 응답을 전송한다.
7. T2스레드는 할일을 마치고, AsyncContext.complete()를 통해 실행을 종료하고 스레드를 반납한다. 

 

🤔 비동기는 알겠는데, 그럼 Tomcat은 아직도 nio, nio2를 사용하지 않는건가요?

톰캣7(서블릿3.0)에서 비동기 기능이 추가되며, 논블로킹 IO HTTP 서블릿 커넥터도 함께 추가되었다.
당연한거지만 톰캣에서 NIO를 사용한다고 [DB I/O나 파일처리]가 자동으로 논블로킹하게 동작하지는 않는다.

톰캣은 서블릿을 처리하는 '웹 서버'이고, 병렬처리는 개발자가 직접 비동기-논블로킹 코드를 작성하는 거다.

NIO Connector는 내부적으로 java의 nio, nio2를 사용한다.

// Tomcat의 ${Tomcat_HOME}/conf/server.xml 설정

protocol="HTTP/1.1" // 기본값, 블로킹 IO
protocol="org.apache.coyote.http11.Http11NioProtocol" // NIO로 변경할 수 있다.

(실제로 스프링부트의 내장 톰캣을 실행하면 기본값인 Http11NioProtocol 을 사용하는 것을 확인할 수 있다.)

 

 

🤔 그럼 Netty는 Tomcat과 뭐가 다르길래 비동기-논블로킹을 그렇게 강조하나요?

톰캣은 [Nio Http 커넥터] 기능을 지원해주는거고, Netty는 기본 설계부터가 다르다.

• Netty는 서블릿 스펙을 사용하지 않는다. [순수한 자바 nio + 함수형]으로 웹 요청을 리액티브하게 다룬다.

리액티브 시스템, 리액티브 프로그래밍은 검색하면 나오니 찾아보도록 하자.

• Netty는 내부적으로 1개의 이벤트를 받는 스레드와, 다수의 worker를 가진다.
  보통 이벤트를 처리하는 방식에 따라, [콜백 패턴]과 [Future 패턴]으로 나뉘는데 Netty는 둘 다 지원한다.

Tomcat의 서블릿을 멀티스레드로 돌리는 것과 기본 설계부터가 다르다.

• [이벤트 루프 처리]를 동기적인-싱글스레드로 할수도있고, 비동기-멀티스레드로 할수도 있다. 장단점이 존재한다.

이벤트를 받는 스레드는 1개이다. [이벤트 루프 처리 스레드들]을 동기적으로 할건지, 비동기로 할건지 정한다.

더 자세한 내용은 스프링5 Webflux나 리액티브 프로그래밍 (RxJava)를 찾아보면 자료가 많으니, 궁금하면 찾아보자.

 

---

💭 기존의 Java I/O와 다른점

Blocking I/O는 데이터가 강물이 흐르듯 스트림으로 전송된다고 가정하는 방식이기 때문에 이해하기는 쉬우나 실제 네트워크상의 데이터전송 방식은 이와 다릅니다. Non-blocking I/O 는 실제 네트워크상의 데이터 전송이 이루어지는 방식과 유사하게 구현되는 I/O 방식입니다.

참고로 기존에 있던 자바 I/O를 BIO, Blocking-I/O 라고 부르기도 한다.

기존의 입출력은 운영체제 I/O 요청을 위한 [입력스트림, 출력 스트림] 객체로 구분되어있었다.

예를 들어 데이터를 읽기 위해서는 InputStream 객체를, 쓰기위해서는 OutputStream 객체를 생성해야 했었다.
또한 버퍼를 내부에서 제공해주지 않기때문에, Buffered 객체를 이용해서 직접 버퍼링 작업을 해주어야했다.

 

NIO에서는 스트림 대신, [Channel] 객체를 제공해준다. 한 채널을 이용해서 양방향 I/O 통신이 가능하다.

또한 채널은 읽은 데이터를 무조건 내부의 버퍼에 저장한다. 사용자는 버퍼에서 필요한 부분만을 읽고 사용할 수 있다.

Non-blocking I/O에서는 스트림대신, 전송할 메시지를 buffer에 담아서 전달하며, 수신측(서버)에서는 네트워크 상의 이벤트를 감지할 수 있는 셀렉터 (일종의 리스너)를 생성하여 이벤트를 대기하다가 이벤트 발생시점에 알맞은 방식으로 데이터를 처리합니다. 또한, 시스템콜(System call) 측면에서 본다면, Direct Buffer는 하드웨어상의 데이터에 대하여 네이티브 접근이 가능하기 때문에 커널상에서 user영역으로의 데이터 복사단계를 줄여 성능면에서 뛰어납니다.

다시말해, Non-blocking I/O는, 하나의 스레드가 동시에 많은 채널을 관리할 수 있는 I/O 방식으로, 일반적으로 셀렉터를 이용하여 네트워크상의 이벤트를 감지하여 처리하는 방식을 사용합니다. 이 방식은 accept에 대한blocking을 피할 수 있는 장점이 있습니다.

이렇게 채널을 제공하는 이유는, 블로킹과 논블로킹 I/O를 둘 다 제공하기 위함이다.

기존의 자바는 블로킹 I/O만 가능했었다. 그래서 멀티스레드 상황에서 I/O 때문에 스레드가 멈추는 일이 많았다.
운영체제에 I/O요청을 한 값이 반환되어야 다음 작업을 시작할 수 있기때문에, 그 동안 스레드는 놀고있는거다.
논블로킹은 Return되지 않았음에도 다음 작업을 시작하는 것을 의미한다. (제어권을 가지고 있지 않고 바로 반환한다.)

동기- 비동기는 "작업을 여러 개를 동시에 할 수 있는가?"에 있다. 제어권을 말하는 [블로킹-논블로킹]과 비교대상이 아니다.

BIO와 NIO의 실제 자바 코드 살펴보기 (참고로 nio의 Selector는 멀티플렉싱 select와 동작이 비슷하다)

BIO는 간단하다. 그냥 기존의 자바 I/O 객체를 이용하면 그게 BIO다.

import java.io.IOException;
import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;</code>
 
public class BioTest {
 
  public static void main(String[] args) throws IOException {
 
    ServerSocket serverSocket = new ServerSocket(8000);
    Socket socket = serverSocket.accept();
 
    InputStream in = socket.getInputStream();
    int oneInt = -1;
    while((oneInt = in.read()) != -1){
      System.out.print((char)oneInt);
    }
    in.close();
  }
}

NIO는 채널객체를 이용해서 아래와 같이 사용한다.

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Iterator;
 
public class NioWithSelectorTest {
 
  static ServerSocketChannel serverSocketChannel = null;
  static Selector selector = null;
 
  public static void main(String[] args) throws IOException, InterruptedException {
 
    // Selector(일종의 리스너) 열기
    selector = Selector.open();
    // 소켓 열기
    serverSocketChannel = ServerSocketChannel.open();
    // 소켓 채널에 non-blocking 설정
    serverSocketChannel.socket().bind(new InetSocketAddress(8000));
    serverSocketChannel.configureBlocking(false); // Blocking false
 
    // Blocking 상태확인
    System.out.println("Blocking 상태확인 :::: " + serverSocketChannel.isBlocking());
 
    // Selector를 이용하여 감지할 이벤트 등록
    serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);
 
    while(true){
      System.out.println("connecting...");
 
      // 준비된 이벤트가 있는지 체크. 이벤트마다 다른 숫자 반환이 있을때까지 blocking
      selector.select();
 
      // 이벤트가 발생하였을 때, 셀렉터의 SelectSet에 준비된 이벤트를 하나씩 처리함.
      Iterator<SelectionKey> iterator = selector.selectedKeys().iterator();
 
      while(iterator.hasNext()){
        SelectionKey selectionKey = iterator.next();
        // Selection Key 에 따라 분기
        if(selectionKey.isAcceptable()){
          // 서버 소켓 채널에 클라이언트가 접속시도
          accept(selectionKey);
        }else if(selectionKey.isReadable()){
          // 이미 연결된 클라이언트가 메시지를 보내는 경우
          read(selectionKey);
        }else{
          System.out.println("그외의 셀렉션 키 : " + iterator.next());
        }
 
        // 처리된 이벤트는 제거
        iterator.remove();
      }
    }
  }
 
  /**
  * 클라이언트가 접속되었을 때 실행되는 메서드
  * @param selectionKey
  * @throws IOException
  */
  private static void accept(SelectionKey selectionKey) throws IOException{
    // 받아들인 채널로 서버소켓채널 생성
    ServerSocketChannel server = (ServerSocketChannel)selectionKey.channel();
    // 받아들인 서버소켓채널로 소켓채널 생성
    SocketChannel sc = server.accept();
    sc.configureBlocking(false); // non-blocking
    // 접속된 후에는 읽기모드로 변경
    sc.register(selector, SelectionKey.OP_READ);
    System.out.println(sc.toString() + " 접속되었습니다.");
  }
 
  /**
  * Read 된 크기를 알려줌.
  * @param selectionKey
  */
  private static void read(SelectionKey selectionKey){
    // SelectionKey 로부터 소켓 채널을 얻어옴
    SocketChannel sc = (SocketChannel)selectionKey.channel();
    // ByteBuffer 생성함
    ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
    try {
      // 요청한 클라이언트의 소켓 채널로 부터 데이터를 읽어들임.
      int read = sc.read(buffer);
      System.out.println(read + " byte를 읽었습니다.");
    } catch (IOException e) {
      try {
        sc.close();
      } catch (IOException e2) {
      }
    }
 
    // buffer 메모리 해제
    clearBuffer(buffer);
  }
 
  /**
  * buffer의 내용을 클리어함.
  * @param buffer
  */
  private static void clearBuffer(ByteBuffer buffer){
    if(buffer != null){
      buffer.clear();
      buffer = null;
    }
  }
}

 

혹시나해서 한번 더 하는 말이지만, 동기/비동기는 NIO와 관련이 없다.

자바의 비동기처리는 옛날부터 Thread 객체를 이용해서 지원하는 기능이었다.

//✨ JDK1.5에 추가된 java.util.concurrent.Executors를 사용하는 방법 ✨//
public static void main(String[] args) {
    ExecutorService executorService = Executors.newCachedThreadPool();

    // 작업1 (스레드)
    executorService.submit(() -> {
        log("작업 1 시작");
        try {
            Thread.sleep(1500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        log("작업 1 종료");
    });

    // 작업2
    log("작업 2 시작");
    try {
        Thread.sleep(500);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    log("작업 2 종료");

    executorService.shutdown();
}

---

💭 그럼 NIO가 무조건 좋겠네요?

NIO는 비동기적인 작업이 많은 [불특정 다수의 클라이언트 연결, 여러 파일 I/O를 동시]에 처리해야 할 때 좋다.

I/O 작업동안 스레드를 놀게하지않고, 다른걸 시킬 수 있기 때문이다.
= 스레드를 더 만들필요없이, 한 스레드를 효과적으로 갈굴 수 있기 때문이다.

운영체제 입장에서 과도한 스레드 생성을 피하고, 내부 버퍼를 이용한 입출력으로 성능향상이 가능하다.

 

하지만 여기에는 함정이있는데, '비동기적으로 처리할 수 있는 작업'에서만 스레드가 다른일을 할 수 있다는 점이다.

예를 들어, [ 이미지 로딩 -> 계산 로직 -> 문자API 발송] 같은 작업에서는 논블로킹이 매우 좋다.

• 블로킹은 이미지 로딩 I/O가 반환되기를 기다리면서 스레드가 다른작업을 못한다. 그냥 놀고있다.
• 논블로킹은 이미지 로딩의 성공여부와 상관없이 다음 작업(계산로직, 문자API발송)을 따로 진행할 수 있다.   

하지만 아래와 같은 계산 로직이라면 어떨까?

[ 현재 GPS 좌표값 요청 -> 좌표값으로 최단거리 계산 -> 최적의 지름길 추천 ] 

논블로킹으로 사용한다고 한들, 좌표값 I/O가 반환되지 않으면 다음작업을 진행할 수 없다.

동기적인 작업에서는 오히려 논-블로킹 때문에 생기는 추가동작때문에, 오버헤드만 발생해서 더 느려질 뿐이다.

기억하자, 병렬처리는 발생하는 예외상황들을 관리하기 정말 어렵다. 추가적인 많은 작업이 필요하다.

 

같은 맥락으로 엄청 큰 대용량의 데이터를 처리할 때에는, 굳이 논블로킹으로 하기보단 스레드를 개수를 늘려서 블로킹으로 처리하는게 더 빠를 것이다. NIO는 논블로킹을 위해 모든 입출력 작업에 버퍼를 이용한다. 대용량 작업에서는 이로인한 메모리 낭비와 추가적인 작업으로 인한 오버헤드가 더욱 커지게된다. 

 

 

💭 만들기도 복잡한 논블로킹 NIO, 왜 생겼을까?

웹 서비스를 생각해보자.

• 웹 서비스는 네트워크를 정말 많이 사용한다.
  [네트워크 I/O]는 서버와 운영체제 입장에서는 [파일 I/O]와 동일하다. 소켓을 열고, 기다려야한다. 

부르는 이름만 다를 뿐, 커널 입장에서는 처리과정이 동일하다.

• 웹 서비스는 데이터베이스를 통한 파일 I/O 접근을 정말 많이 한다.
• 웹 서비스는 불특정 다수가 다른 서비스를 사용한다 = 비동기적인 작업이 많다.
• 웹 서비스는 여러 개의 서버(서비스)가 협력하는 형태가 많다. = 비동기적으로 따로 놀수가 있다.

CPU 계산을 정말 많이 사용한다면, 단순히 컴퓨터의 성능을 극한으로 올리면 해결될 수 있다.

하지만 웹 서비스는 그렇지않다. 대부분의 시간을 I/O를 기다리는데 소비한다.

웹서비스는 Process 2에 가깝다. 그림으로 봐도 알겠지만, [CPU 성능은 문제가 없다.] 하루종일 I/O를 기다리며 놀고있을 뿐이다.

사실 과거에는 이만큼의 고민이 필요없었다. 컴퓨터의 성능이 워낙좋고, 네트워크가 빠르니까 대충 만들면 됬다.

하지만 지금의 웹은 과거랑은 많이 다르다. 사람들은 모바일로 24시간 웹 서비스를 사용하고, 이벤트가 있으면 순간적으로 몇백만의 트래픽 요청이 몰려온다.

 

[잦은 서비스의 장애 = 고객 떠남 = 돈 못벌고 회사 망함]은 당연한 사실이다.

서버컴퓨터, CPU 성능, 메모리 용량을 아무리 늘려봐야 I/O 병목으로 인한 문제는 해결할 수 없다.

 

그럼 어떻게 해야할까? 답은 간단하다. 스레드 여러 개를 병렬로 동시에 돌리면 된다.

1. 웹 서비스는 스레드의 개수를 늘려서, 멀티스레드로 처리하면 I/O 처리성능을 극대화할 수 있다.
그림에도 나와있지만, 서버 CPU의 성능과는 전혀 상관없다. 그냥 스레드가 네트워크 I/O를 기다리면서 놀고있을 뿐이다.

Client를 File로 바꿔보자. 서버 입장에서는 파일I/O와 네트워크 I/O는 동일한 개념이다 (실제로도 운영체제 동작도 그렇다.)

 

2. 하지만 스레드는 비싼자원이다. 스레드를 무한정 늘릴 수는 없다. 운영체제의 컨텍스트 스위칭 비용이 증가한다.

3. 그럼 개수를 늘리는 대신에, 한 스레드를 놀지않고 최대한 많이 갈굴수는 없을까?

 

이런 맥락으로 비동기 멀티스레드를 넘어선 정신나간 논블로킹에 대한 아이디어가 나온 것이다. 

음.. 근데 I/O가 반환되기를 꼭 기다려야하나? 그냥 다른 작업하고 있으면 안될까? (제어권의 반환)

한 스레드가, 여러 개의 Client를 처리하면 안되나? 라는 아이디어.

톰캣에서 NIO를 사용했을 때 모습. Netty는 동작방식이 그림과는 다르다.

 

💭 본질을 파악하자

세션 클러스터링과 세션 저장소.
단일 스레드인 Redis와 멀티 스레드인 Memcache

모든 작업을 처리하는 CPU, 그래픽같은 병렬처리에 특화된 GPU

모든 서비스가 한 프로젝트에 있는 모놀리스, 각각의 서비스가 따로 동작하는 MSA

 

물론 사용하는 장단점은 다르지만, 결국 근본적인 탄생 이유, 본질은 비슷하다.

[잦은 서비스의 장애 = 고객 떠남 = 돈 못벌고 회사 망함] 을 해결하기 위해서, 병렬성을 극대화 하는거다.