마이크로서비스가 무엇인지 살펴보고, 마이크로서비스의 장단점을 알아보자.
모놀리식 아키텍처
마이크로서비스 아키텍처를 이해하기 위해, 기존 엔터프라이즈 애플리케이션이 갖고 있던 모놀리식 아키텍처와 비교해보자.
모놀리식 아키텍처
모든 업무 로직을 하나의 분리된 형태로 묶어서 서비스하는 형태
쇼핑몰을 개발한다고 가정을 했을 때, 사용자와 관련된 기능, 주문, 배송, 결제, 제품 등등
다양한 기능들을 하나의 패키지로 묶어서 서비스하는 형태가 모놀리식 아키텍처를 갖는 애플리케이션이다.
모놀리식 아키텍처는 장점도 있지만, 서비스가 커질 경우 규모가 커질수록 특정 기능을 변경하는 데 시간이 오래 걸릴 수밖에 없다. 즉, 전체 서비스가 하나의 패키지로 구성되기 때문에 특정 기능 하나를 수정하고자 해도 다른 서비스들도 영향을 받는 그런 형태다.
단점
- 특정 기능 하나를 수정하기 위해 전체를 다시 재편해야 하기 때문에 개발 사이클이 길어진다
- 복잡한 구조를 가질 수밖에 없다
- 확장성이 낮아진다
개발 과정
모놀리식 애플리케이션은 규모가 커질수록 개발 및 유지보수, 배포에 이르기까지 많은 문제점이 있다.
먼저, 다수의 개발자들이 단일 코드베이스를 기준으로 개발 진행된 후, 개발된 서비스들은 업그레이드, 테스트, 릴리즈 과정을 통해서 하나의 어플리케이션으로 완성된다.
단일 코드베이스를 기준으로 개발을 진행하게 되면 개발팀에 분리되기 시작하고, 그에 대한 관리, 그리고 최종 프로덕션 배포까지 개발이 진행될수록 복잡하거나 증가할 수밖에 없다.
기술을 즉시 변경하게 되면, 새로운 기술을 적용하는 데 있어서도 전체 애플리케이션에 영향을 받기 때문에 반영하는 데 어려움이 있다.
SOA
특정 기술 셋을 가지고 개발을 진행하다, 데이터베이스를 바꾼다든지, 아니면 특정 기능에 따라서는 자바가 아닌 다른 언어를 사용하게 되는 부분은 쉽게 반영할 수 없다. 이와 같은 모놀리식 애플리케이션은 규모가 커질수록 개발부터 유지보수, 배포에 이르기까지 여러 단점들을 갖고 있다. 그래서 이를 개선하기 위해서 나온 것이 바로 SOA라는 아키텍처다.
SOA '서비스 지향 아키텍처'
서비스 단위로 독립된 프로그램을 만들고, 독립적인 소프트웨어로 만든 이들이 서로 커뮤니케이션을 할 수 있게 하여 전체 서비스를 만드는 형태
별도의 독립적인 애플리케이션으로 개발을 진행하고, 이 전체를 하나의 서비스로 묶어서 각 서비스 간의 커뮤니케이션할 수 있도록 한다. 이렇게 되면 별도의 독립적인 서비스로 만들어서 진행하기 때문에 각각의 서비스별로 영향을 적게 받게 된다(루즈 커플링).
이렇게 되면 각각의 서비스들은 서비스에 맞는 기술 스택을 적용할 수 있게 된다. 빌드 배포 또한 변경된 서비스만 빌드 배포를 진행하기 때문에 다른 서비스는 영향을 받지 않게 되는 형태다.
SOAP
SOA의 커뮤니케이션하는 방법이 SOAP(Simple Object Access Protocol)다.
이 SOAP를 이용해서 서로 커뮤니케이션을 하게 되는데, 이 SOAP라는 프로토콜을 적용하려면 ESB라는 엔터프라이즈 서비스 버스라는 별도의 미들웨어를 통해서 커뮤니케이션을 진행하게 된다.
커뮤니케이션에 이 SOAP라는 다소 무거운 통신 방식을 사용하기 때문에 이 부분에서도 문제가 발생한다.
SOA와 마이크로 서비스는 개념적으로 큰 차이가 없다.
SOA가 서비스 단위로 나눠져서 독립적인 프로세스로 만들어, 독립적인 프로세서가 동작하는 어플리케이션으로 만들어 서로 커뮤니케이션하는 형태로 하나의 서비스를 완성하는 개념은 마이크로 서비스와 SOA가 동일한 개념이다.
다만 SOA가 커뮤니케이션하는 방식이 SOAP를 이용한 방식이었다면,
마이크로서비스는 각각의 서비스 간의 커뮤니케이션하는 방식이 대표적으로 REST API를 이용한 방식을 사용한다.
(서비스들 간의 커뮤니케이션하는 방식은 REST뿐만 아니라, 어떤 RPC라는 것도 있고 여러 가지 형태가 있을 수 있지만, 가장 기본적인 방식이 REST를 이용한 커뮤니케이션 방법이다.)
따라서 마이크로서비스 아키텍처를 갖는 서비스를 개발한다는 것은 해당 서비스를 작은 서비스 단위로 나누고, 이 각각의 서비스 간의 원활하게 커뮤니케이션을 할 수 있도록 구성을 해서 전체 서비스를 만드는 개념이다.
MSA
기존 어플리케이션의 개발 방식은 하나의 어플리케이션으로 개발되는 형태 , 즉 모듈 쌓기 방식으로 개발되는 어플리케이션은 다른 말로 일체형 어플리케이션이라 할 수 있다.
마이크로 서비스는 소규모의 독립적인 구성 요소로 나누고, 그리고 각각의 분산된 구성 요소로써 하나씩 개발하는 형태, 즉 개별적으로 개발하는 형태를 마이크로 서비스 아키텍처라고 할 수 있다.
분산되어진 하나의 마이크로 서비스는 독립적으로 디자인, 개발, 배치 및 서비스를 진행하며 관리되는 것까지 잘 정의된 비즈니스 기능을 제공할 수 있는 형태가 된다. 대규모의 서비스를 잘게 나누고 작게 나눈 서비스들이 서로 커뮤니케이션해서 하나의 어플리케이션을 만들어 내는 형태의 아키텍처다.
vs 모노리스 아키텍처
한 주제로 하나의 모노리스 아키텍처를 갖는 서비스를 만들었다고 가정해보자.
서비스는 시간이 지나면서 규모가 커지게 될 것이다. 트래픽, 사용자 가입, 그 다음에 관리하는 품목들이 기하급수적으로 늘날 수 있다. 이때 몇 문제점이 발생할 수 있다.
서비스 자체적인 측면의 문제
사용자가 늘어 많아진 요구사항 및 개선사항과 기능 세분화, 다양한 기능을 제공하기 위한 개선등의 서비스 자체적인 측면에서 문제가 생길 수 있다.
해당 서비스는 일체형 서비스 형태로 만들어졌기 때문에 각각의 서비스들 간의 결합도가 높다.
하나의 서비스, 하나의 기능을 변경하기 위해서는 영향을 받는 다양한 기능들이 존재할 수밖에 없는 것이다.
서비스 측면에서 기능을 좀 더 추가한다고 하더라도 문제가 생길 수밖에 없다.
개발 측면의 문제
규모가 커질수록 전체 서비스 전체를 이해하기 어려워 진다. 한정된 부분만 이해하고 있는 상황에서 무언가를 변경했을 때, 다른 서비스가 영향을 받는지 저는 알기가 힘들다.
해당 서비스를 사용하는 다른 서비스가 어떤 것들이 있는지도 잘 모르고, 변경했을 때 어떤 사이드 이펙트가 있을지를 알 수가 없는 것이다. 따라서 하나의 기능을 추가하고 변경하는 것에 많은 기간이 필요할 수밖에 없고, 협의가 필요할 수밖에 없다.
환경 문제
사용자가 많아져서 트래픽이 증가하면 물리적인 서버의 성능도 높여야 한다.
서버의 기능을 확장해야 하는데, 서버에 기능을 확장하는 방법에는 서버를 증설하여 늘리는 방법이 있다. 기존의 방식은 서버를 증설하는 방법은 어렵다. 그래서 기존의 서버에 대해서 성능을 높이는 방법인 수직(=버티컬) 스케일링을 할 수 있다. 현재 동작하고 있는 서버의 성능을 높여서, 사용자의 트래픽을 감당하는 형태가 될 수도 있다. 다만 수직 스케일링은 비용이 기하급수적으로 늘어난다. 서버의 사양을 높인다는 것은 높일수록 비용이 많이 발생할 수밖에 없다.
앞선 문제의 기본은 서비스의 규모가 커져서 발생하게 되는 문제들이다.
규모가 큰 서비스를 작은 서비스 단위로 나누어서 모듈화하는 형태로 서비스를 하게 되면 문제점들을 개선할 수 있다. 서비스가 제공해주는 서비스들을 별도의 서비스로 나누고, 나누어진 서비스들을 특정 개발 팀들이 관리한다면, 그 개발팀은 전체 서비스에 대한 각각의 서비스가 서로 간의 느슨한 관계를 갖게된다. 각각의 서비스를 개발하는 개발팀은 해당 서비스에 대해서만 알고 있으면 되기 때문에, 기능의 확장, 추가가 쉽고 빠르게 진행할 수 있게 된다.
또한 물리적인 환경적인 측면에서도 이 각각의 서비스들이 별도의 서버일 수도 있습니다. AWS, GCP, 구글 클라우드 등 다양한 클라우드 환경의 각각의 서비스들을 올리고, 그리고 특정 서비스의 트래픽이 많아진다면 해당 서비스에 대한 스케일만 넓혀주면 된다.
장점
- 작은 코드 베이스와 서비스 별 코드가 나누어져 개별적으로 관리
- 서비스별 스케일링 가능
- 서비스 특성에 따른 기술 다양성(다른 프레임 워크 등)
- 하나의 서비스의 결함이 다른 서비스의 영향을 주지 않음
- 부분적 로직 업데이트 가능
단점
- 초기 구성 난이도
- 분산 환경이기 때문에 디버깅과 추적이 어려움
- 어떤 특정 계획에 대해서 엔드 투 엔드 테스트가 많이 이루어져야 됨
- 어플리케이션을 개발하고 배포하는 내용들이 중복 제약이 있는 각각의 서비스들이 빌드되고 배포되는 과정이 굉장히 중요
- 서비스 간의 호출 (커뮤니케이션) 비용이 증가
- 서비스 간의 일관성 유지가 어려움
- 시스템이 돌아가지만 특정 서비가 off되면 재기능을 못할 수 있음
이런 단점들을 개선하기 위한, 보완해 주고 해결해 주는 넷플릭스 OSS와 스프링 클라우드 등 다양한 소프트웨어가 있다.
MSA의 여러 요소
- 서비스 로직
- 게이트웨이
- 모니터링 서버
- 변수관리 서버
참고:
https://www.youtube.com/watch?v=O1un1Nf810Y&list=PLJkjrxxiBSFBPk-6huuqcjiOal1KdU88R
https://www.youtube.com/watch?v=-JHAUaOq6l0&list=PLOSNUO27qFbv95vD0Cc5Vwtro4vcMZGiy&index=11
