Netty 훑어보기

 

Netty?

 Netty 는 서버 및 클라이언트이 필요한 네트워크 어플리케이션을 빠르고 쉽게 개발이 가능하게 해주는 NIO 기반의 서버 프레임워크 이다.  기본적으로 Netty는 비동기 이벤트 드리븐 방식의 프레임워크이다. TCP , UDP 을 모두 지원한다. 

 

 Netty의 기본 구조 이다. 코어 부분을 보면 이벤트 모델을 가지고 있고 쉽게 사용이 가능하도록 해주는 API 를 제공 하고있으며 zero copy capable rich bytebuffer 라는것을 지원하는데 이 특징으로 인해서 GC 를 최소화 하여 고성능을 보장하게 된다. Netty는 비동기식으로 작동하기때문에 적은 스레드로도 많은 요청 처리 가능하여 서버 자원을 효율적으로 사용이 가능하다.

 

Netty를 쓰는이유?

 일단 각종 네트워크 코덱을 기본 지원한다. 그리고 필요한부분들을 만들어서 조립이가능하며 멀티스레딩처리에 대한 고민을 덜어준다. 개인적으로 Netty를 쓰는 이유라고 생각하는건 단연 처리속도이다. 그럼 Netty는 과연 얼마나 빠를까 ? 

12위에 netty가 위치하고있다. JSON serializtion 기준으로 나온 순위인데 netty는 고성능이라고 하는데 12위? 근데 순위를 자세히 살펴볼 필요있다. 맨위에 2위에 undertow가 보인다. undertow 기본 netty 기반으로 동작을 하고 있다. 결국은 netty 를 응용해서 만들어진 녀석이라는것이다. 

 개인적으로 보기에는 spring 혹은 netty 기반으로 새로운 제품들이 많이 생겨나는거 같다. 특히 netty 경우 vert.x 도 netty를 기반으로 만들어졌으며, 이벤트처리방식 도입의 필요성이 많아 지면서 좀더 많은 형태로 응용되거나 변화 되서 사용되고있는거 같다. spirng 도 netty를 기본적으로 지원하고있으니 사용해볼법하다. 

 Netty는 2019년도 까지 업데이트가 계속 되고 있으며, 앞으로도 꾸준히 버전이 업데이트 될것 으로 보인다. 왜냐면 앞서 말했듯이 이젠 자바진영에서 사용할수있는 대표적인 고성능 프레임워크이기 때문이다. 

 

Netty 는 기본적으로 Java NIO 를 기반으로 동작 하는데, NIO 는 JDK 1.4 부터 등장 한다. NIO 는 기존 socket 기반의 I/0 를 감시하기 위해선 요청마다 Thread 를 생성해서 관리를 했고 엄청난 접속자수에 따라 엄청난 Thread 가 생성 될수 있어 많은 Context-switching 과 hip 메모리 사용을 초래하게 된다. 그렇기때문에 이런 경우의 비효율성을 개선하기 위해 등장했고 NIO 를 기반으로 탄생 한게 Netty 이다.

 

 Netty ? C++?

 

 맨처음 Netty 란걸 알게되었을때가 지금으로부터 3~4년전인거 같다. 그땐 주변에서 이런소리를 가장 많이 들었다.

 

    " 속도 생각하면 당연 C로 짜야지 그걸 느린자바로 왜만들어 ?" 

그땐 참 순진하게 그런가보다 라는 생각을 많이 했다. 그리고 그땐 비동기식을 쓸이유도 쓸 기회조차 없었기에 관심을 접었다. 지금은 찾기가 힘들어서 글에 첨부하진 못했지만 C++에 비해 어느경우에는 빠르게 동작하는경우도 있는 벤치마크 글을 본적이 있다. 결론 부터 말하면 C++ 로 짠걸 이길순 없었다. 하지만 그 수치에 대해선 ms 정도의 차이였기에 굉장히 고무적이였다. 자바가 빨리 돌아갈수 있다라는것을 보여준 예가 아닌가 싶다. 그리고 이 Netty 자체를 만드신분이 한국사람( 현재 라인에 계신 이희승 님 ) 이란 점. 그리고 한다리 거쳐 내 지인중에 한분이 그분의 측근이란 점에서 여러가지 복잡한 요소들로 참 흥미로운 상황을 맞이 했다.  역시 이 업계는 은근 좁은거 같다. 지인의 말에 의하면 지금 이희승님께서 새로 만드신 Armeria 란거에 대해서 이야기를 들었다. 어플리케이션 서버라고 하는데 기회가 되면 한번 관심을 가지고 볼필요가 있을거 같다. 

  살짝 다른이야기로 빠졌지만, 난 자바개발자이기 때문에 철저히 자바 편을 들고 싶다. C++ 과 자바로 짜여진 서비스라면 속도측면에서 어마어마 한 차이가 나지 않는 상황에선 자바가 좀 더 좋지 않나라는 생각이 든다. 운영적 이점과 유지보수 측면에서 자바가 더 압도적이라 생각한다. 자바라는 언어가 가지고 있는 강점들을 그대로 가져가되 C++ 보단 느리지만 그래도 비벼볼수있을만한 성능이라면 난 100번을 선택해도 Netty 의 손을 들어 줄거 같다. 

 

 무조건 Netty Go?

 

이렇게 빠르다면 다들 Netty 로 가야 하는거 아닐까 ? 음 역시나 항상 서비스를 구축할때마다 동일하게 생각이 드는거지만 용도에 맞아야만 써야 된다고 본다. 개인적으로 Netty 정말 Rest API 를 만들때나 혹은 데몬형태의 배치성 서비스에 쓰는게 맞다고 생각한다. 

 지인 한분이 조언해주신 이야기를 참고하면 Netty 가지고 웹서비스를 구현한다고하면 결국엔 Servlet  을 사용하게 되고 단순한 JSON 통신이 아닌 Templete 엔진을 붙여야 하기 때문에 생각보다 빠른 응답을 내려주진 않을거라고 말씀해주셨다. 듣고보면 당연한 이야기 인거 같다. 단순한 Text 형태의 데이터를 응답해주는것과 JSP 형태의 데이터를 응답으로 주는것, 분명 작업량에선 단순히 봐서도 차이가 나는게 맞는거 같다.  그래도 역시 빠른건 빠른것이다. 

 

 

 

Event Loop

 

Netty 를 대표하는 컴포넌트이다. I/O 발생시 EventLoop 를 이용하여 task 를 실행한다. 이벤트 방식이라면 기본적인 구조가 아닌가 싶다. Eventloop 에서 pipe line 을 사용할경우 일종에 이벤트 핸들러 역할을 하게 된다. pipe line 에서는 이벤트 루프가 발생시킨 이벤트를 Inbound 핸들러에게 전달하게 되고 그 이벤트의 outbound 이벤트를 outbound 핸들러에게 다시 전달하게 된다. 그리고 최종적으로 I/O 처리 마무리는 EventLoop가 담당하게 된다.

 

이런 형태로 동작하다보니 Netty 구조상 결국 비지니스 로직은 단순하게 개발자 관점으로 봤을때 Netty를 이용하여 몇개의 핸들러 클래스를 구현하면 끝! 물론 뭔가 완성도를 높히기 위해선 Netty 에 대한 이해도를 더 높이고 사용해야할 요소들이 존재한다.  조금만 검색해보면 알겠지만 Netty 는 최소 10만이상의 클라이언트 접속이 가능하다고 한다. 개인의 기술 성숙도나 역량에 따라 10만이상의 몇 십만 건의 트래픽 처리도 가능하지 않을까 싶다.

기존의 Node.js 동작 방식인데 Netty 동작 구성도 위와 같은 구조를 채택하고 있다.  구글의 RPC 프레임워크인 gRPC 에서도 Netty 를 내부 transport로 사용중인것으로 알고 있다.