찰떡개발자 코딩

Vert.x의 개념을 잡아보는 시간..! 정리 하면서 다시한번 개념을 잡아보자...!

Vert.x란?

Node.js와 같은 비동기 서버 프레임워크이다.

먼저 Tomcat 설명을 통해 이해를 도와보자..!

Tomcat의 경우 Request가 들어오면 Request Queue에 적재되고, queue에 쌓인 요청들은 Thread pool에 있는 Thread에게 하나씩 하나씩 할당되어 요청을 처리하는 방식이다.

요청을 마치게되면, request가 들어온 Connection으로 요청완료된 response를 보내고, 해당 작업을 한 Thread는 Thread Pool에 다시 들어가게된다.

이 구조에서, Tomcat이 동시에 처리할수 있는 Connection의 수는 보통 Thread pool의 Thread 수만큼이라고 하는데, 통상적으로 Tomcat서버 하나당 500개의 Connection을 관리한다.

=> 500Connection : 500 Thread

동시에 대용량의 Connection을 관리하기가 Tomcat(WAS)만으로는 부족한 부분이 있어 나오게 된것이 Node.js와 같은 비동기 소켓 서버이다.

Vert.x는 Node.js와 거의 비슷한 개념을 가지고 있지만, Node.js보다 훨씬 더 강력한 아이인것 같다.

그이유는 차근차근 보도록 하자!

Vert.x는 기본적으로 Single Thread Model이다.

여기서 Vert.x에 클라이언트가 연결되면(Request) Main Event Loop가 요청을 검사하고, 해당 요청을 수행한다.

보통 하나의 EventLoop를 처리하는 Single Thread에서는 10,000~20,000개 정도의 Connection을 처리할수 있다고 한다.

자 Vert.x의 장점을 한번보자

• Apache Netty를 서버 엔진으로 사용하고 있고, Vert.x 노드간의 통신을 지원하기 위해 HazelCast를 사용!
  Netty와 HazalCast에 대해서는 별도로 공부할 예정이다.!
  클러스터링과, 네트워크 고속 처리 부분을 신뢰가 가는 오픈 소스를 기반으로 했다고하니 안정성에서는 걱정이 없다고한다.!
• Clustering을 지원한다!. 이부분이 아주 매력적이다.
  여러개의 Vert.x서버를 띄우고 Vert.x서버 간 통신을 할수있다. = > 데이터 공유는 불가능 하지만 메시지를 보내서 하나의 서버처럼 사용할 수 있다.
• 빠른 속도 !
  Vert.x는 기본적으로 Single Thread EventLoop로 동작하지만 내부적으로 여러개의 ELP를 띄울수 있다. Multi Thread를 띄워 Verticle 하나씩 제어를 할수 있다는 엄청난 장점이있다. WAS 의 Multi Thread와는 다른데, 각 Thread는 독립적인 EventLoop를 가지고 Thread간의 객체 공유나 자원의 공유없이 독립적으로 동작한다. 
  Node.js도 여러개의 Process를 동시에 띄워 여러개의 Core를 동시에 사용할 수 는 있지만 Process의 Context Switching 비용이 Thread의 Context Switching 비용보다 크기 때문에, 여러개의 Thread 기반으로 동작하는 Vert.x의 성능이 훨씬 우수하다.
  

• Embedded
  Vert.x는 서버로써 사용되기도 하지만, 내가 볼때는 데몬이나, 라이브러리 형태로 사용하기가 더 편리하다고 생각한다. Vert.x는 하나의 JVM에서 Tomcat과 함께 사용이 가능하다. 그래서 Http Request는 Tomcat이 처리하고, Connection이 많이 일어나는 WebSocket은 Vert.x가 처리하게 할 수 있다.!
• Worker Verticle
  이후 천천히 설명 하겠지만, Vert.x는 Verticle이라는 프로그램?이라고 생각하면 되는 아이가 있는데, 이 Verticle은 내부적으로 Worker Verticle을 가지고있다. Main Verticle이 요청을 받아 Event Bus를 통해 메세지를 보내면, 서브로 대기하고 있던 개별 Worker Verticle들이 메세지를 받아 처리한다. Main Verticle은 이때 다른일을 하고, Worker Verticle은 일을 완료 한뒤 다시 Event Bus에 결과메세지를 보낸다. => Event Bus의 응답을 받은 Main Verticle이 응답 메세지를 처리한다.
  위와 같은 방식으로 Asynchronous Call Back 패턴을 만드는데, DB 작업이나 개별적으로 긴 로직을 태울때 사용하기 편리하다.
• Worker Verticle instance / Thread Pool
  Worker Verticle은 Thread pool을 지원 하고있다. Main Verticle과 같이 Worker Verticle instance는 Thread Pool에 있는 Thread중 사용가능한 아이를 전달받아 사용하는 방식으로 진행된다.
  이때 Worker Verticle의 instance 개수와 ThreadPool의 Size를 설정하여 각각의 Worker Verticle 별로 성능을 설정, 수정 할수 있다는 엄청난 기능을 지원한다. => 성능관리 와따!
• Event Bus! => 엄청난 기능!
  Event Bus는 Message Queue와 같은 개념인데, Verticle 간 / Verticle instance간의 통신을 지원한다.
  추가적으로 다른 JVM의 Verticle과의 메시지 전달도 지원하는데, 1:1 통신 뿐아니라 1:N 통신 까지도 지원한다.!
  예를 들어보자.
  클라이언트가 Request를 받아 Consumer에게 메시지를 보내고 자신은 다른일을 한다.(응답은 아직 없다 Connection만 물고있는 상태) => 메시지를 받은 Consumer가 메시지를 처리한다. => 다른 일을 하고있던 클라이언트가 Consumer가 보낸 응답 메시지를 받아 처리 및 Http Response한다.
  이처럼 Single Thread임에도 불구하고, 하위에서 비동기처리를 할수 있게 구현되어 있어 굉장히 특이하면서 효율적으로 사용할 수 있다고 생각한다.

자 여기까지 Vert.x 기본 개념이었다....!

Vert.x는 성능적으로나 성능관리 면으로나, 굉장히 파워풀 한것같다.

아직은 깊이 알지 못하지만...!

차근차근 사용해보는 시간을 가져보려고한다...!