Micro Service에서 WebFlux의 장점

마이크로 서비스에서 WebFlux의 장점을 알아보기에 앞서, 기존에 자주 사용되었던 아키텍처 방식인 모놀리딕 아키텍처 환경에 대해 간단하게 알아보고 그 문제점에 대해 얘기해 보겠습니다.

 

Monolitic Architecture

소프트웨어의 모든 구성요소가 한 프로젝트(모듈)에 통합되어 있는 형태.

모놀리식 아키텍처의 경우 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행됩니다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 합니다. 코드 베이스가 증가하게 되면 모놀리식 애플리케이션의 기능을 추가하거나 개선하기가 더 복잡해집니다.

 

이러한 기존 모놀리딕 아키텍처 환경은 여러 문제점들이 있었습니다.

• 하나의 모듈이 변경되어도 전체 서버를 배포해야 했습니다.
• 작은 기능의 문제점이 곧 서버 전체의 문제점이 되었습니다.

 

이러한 문제점들을 극복하기 위해 MSA(MicroService Architecture)가 탄생했습니다.

 

기존 모놀리딕 방식의 하나의 커다란 서비스 → MSA 방식의 독립적인 작은 단위의 모듈로 쪼개지게 되었고, 기능의 추가나 확장은 각각의 모듈을 통해서 이루어졌습니다. 그럼 MSA란 정확히 무엇인가 생각이 드실 수 있습니다. 그에 대한 간략한 설명으로는 아래에서 설명하고 있습니다.

MicroService Architecture

마이크로서비스 아키텍처는 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행됩니다. 이러한 서비스는 경량 API(주로 RESTAPI 사용)를 사용하여 잘 정의된 인터페이스를 통해 통신합니다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행합니다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있습니다.

이렇게 모놀리딕 환경에서 MSA 환경으로 변화하면서 생긴 장점들 뿐만 아니라 문제들도 같이 생겨나게 되었습니다

 

기존의 모놀리딕 아키텍처 환경에서는 Thread Pool을 이용해 동기식 프로그래밍의 blocking을 감당할 수 있었고,

단일 애플리케이션 내부에서 정보 교환이 일어나기 때문에 blocking 되는 시간이 그리 길지 않았었습니다.

 

하지만 모놀리딕 아키텍처에서 하나의 큰 서비스가 작은 단위의 독립된 모듈로 쪼개지면서, 단일 애플리케이션 내부에서만 일어나던 정보교환이 네트워크를 통한 모듈과 모듈 간 정보 교환(REST API를 주로 이용)으로 바뀌게 되었고, 문제들이 발생하게 됩니다.

• Blocking 시간이 길어지면 응답을 기다리는데 스레드를 모두 소진할 수도 있다.
• 타임아웃이 발생할 정도의 지연이 발생하면 다른 모듈에도 영향을 주어 전체 시스템이 다운될 수 있다.

 

이런 문제점들을 극복하기 위해 MSA 환경에 들어서면서 부각되기 시작한 게 이벤트 루프를 활용한 비동기 프로그래밍입니다. Spring에서도 버전 5부터 도입된 WebFlux를 통해 비동기 프로그래밍을 도입했습니다.(이벤트 루프를 활용하면 요청을 보내고 응답이 올 때까지 무작정 기다리는 대신 자신에게 할당된 다른 여러 소켓의 요청을 순차적으로 빠르게 처리합니다.)

 

마무리

MSA 환경에서 Spring WebFlux가 가지는 장점에 대해 정리해 보았습니다. 마이크로 서비스 아키텍처는 경량 API를 사용해 모듈끼리의 통신을 네트워크를 이용해 진행하기 때문에, 네트워크 처리 시의 IO를 WebFlux의 특징 중 하나인 NonBlocking  IO 처리 방식을 통해 모듈간의 통신 속도 향상을 가져올 수 있지 않을까 생각해 봅니다.