Spring MSA (1) - 마이크로서비스
이제 IT 기업에서 MSA를 사용하지 않는 회사를 찾는것이 드물만큼 MSA는 시스템 아키텍쳐의 표준이 되었습니다. 이번챕터에서는 마이크로서비스의 기본에대해서 먼저 알아보도록 하겠습니다.
Contents List
2.10.1) 마이크로 서비스 아키텍처
MSA(Micro Service Architecture)는 약자 그대로 ‘작은 서비스 구조’ 입니다. 복잡한 비즈니스 구조의 시스템을 독립적인 단위로 나누어 운영하는 서비스 구조로서 기존의 일체형 서비스의 문제점들을 보완해가면서 만들어 졌습니다.
기존 일체형 시스템의 문제점
모든 일체형 시스템들이 문제가 있는것은 아닙니다. 관리하기 편하고 컴포넌트간 호출로, 높은 성능을 보일수 있지만 서비스 규모가 커지고, 해당 시스템을 관리하는 인원이 많아지게된다면 서비스의 복잡도에 따른 여러 문제점들이 나타나게 됩니다.
- 어플리케이션 배포에 많은시간이 소요된다.
- 중복코드 생성 가능성이 높다.
- 부분 수정에 어려움을 겪을 수 있다. (기능들이 전체 시스템에 대해 높은 결합성을 가지고 있다.)
- 모든 개발자가 전체 시스템을 이해 해야한다.
마이크로 서비스의 특징
마이크로 서비스는 다음과같은 특징들을 지닙니다.
1. 단일책임 원칙을 따른다.
하나의 서비스는 하나의 책임을 가짐으로써 결합도를 낮추어 각기 다른 독립적인 서비스로서 관리 할수 있습니다.
2. 각 서비스마다 자율적이다.
각 서비스들이 독립적이기때문에 기본적인 약속만 해두고 자율적인 개발 및 배포가 가능합니다. 이 특징때문에 서비스별 특성에 따라 자유로운 스케일 아웃이 가능하며 개발 환경까지도 자율적으로 선택 할 수 있습니다. 예를 들어 고객관리 시스템은 JAVA로 개발, 주문 관리 시스템은 Python으로 개발 과 같이 서비스별로 자율적인 환경에서 개발이 가능하며 이를 폴리글랏 아키텍쳐라고 부릅니다.
3. 가볍다.
복잡한 시스템을 나누었기 때문에 당연히 ‘가볍다’는 특징을 가집니다. 당연한 특징이지만 이 ‘가벼워진’ 특징으로인해 개인적으로 개발 생태계와 흐름이 완전히 변화되어져 왔다고 생각합니다. 이에대한 내용은 조금있다가 설명드리도록 하겠습니다.
위와같은 엄청난 장점들이있지만 물론, 단점또한 존재합니다.
- 서비스간 통신에 대한 오버헤드가 발생한다.
- 트랜잭션 관리가 까다롭다.
- 서비스가 많아짐에따라 관리하기가 어려워 질 수 있다.
2.10.2) MSA가 이끌어가는 개발 생태계의 흐름
여기서 설명드리고자하는 내용들은 개인적인 생각임을 알려드립니다.
위에서 알아본것 처럼 점점 비대해지는 일체형시스템을 보완하기위해 마이크로서비스가 나타나게 되었습니다. 이 마이크로서비스가 개발의 표준이 됨에 따라 이에 맞추어 많은 개발 생태계의 변화가 왔다고 해도 과언이 아닐것 같습니다.
먼저 위에서 말씀드렸던 마이크로서비스의 장점인 ‘가볍다’라는 특징으로 인해 ‘가벼운 서비스’를 돌리기위한 환경들이 각광을 받기 시작했습니다. 일반적으로 애플리케이션을 배포하는 방식으로 물리서버 혹은 클라우드 서버내의 운영체제에서 애플리케이션, 실행 파일, 라이브러리 등을 설치하여 실행시키는 방식이었다면 운영체제수준의 가상화를 제공하는 ‘컨테이너’기반으로 서비스를 운영하는 생태계가 나타났습니다. 가장 널리 알려져있는 Docker, Kuberntese가 대표적인 컨테이너 서비스로써, OS에 영향을 받지않고 컨테이너단위로 배포가 되기 때문에 이미지 형태로 ‘불변성’을 띄게되고 어떤 클라우드나 OS에서도 같은 환경으로 서비스를 실행가능하게 하여 이식성이 좋습니다.
또한 ‘가벼워진 서비스’를 운영하기 위해 더 쉽고 간편하게 서비스를 할수있도록 Faas(Function as a service) 함수형 서비스, Serverless가 나타나 그저 코드 업로드를 통해 서비스를 실행시킬수 있도록 해주고 있습니다. 이는 AWS Lambda, Azure Functions, Google Cloud Functions 의 대표적인 서비스들이 있습니다.
마이크로서비스가 등장하면서 장점뿐만아니라 단점들도 나타났습니다. 기존의 일체형 서버에서는 하나의 서비스만을 관리하면 되었으나 마이크로서비스로서 작은 단위로 나누어 서비스를 하다보니 수십개의 서비스를 관리하다보니 수십번의 테스트, 빌드, 배포과정이 일어나게 되었을겁니다. 이러한 단점을 보완하기위해 CI(Continuous Integration : 지속적 통합) 의 환경이 발전하면서 자동 테스트와 자동 배포를 지원하는것이 또 표준이 되었습니다. 현재 많은 기업들에서 Jenkins를 주로 사용하며 ‘DevOps:데브옵스’라는 포지션을 따로두어 개발과 배포,운영등의 관리를 따로 할수있게끔 하는 수준까지 발전되어오고 있습니다.
또하나의 문제점으로는 일체형에서는 컴포넌트간 통신으로 빠른 응답을 보였던것과 비교해, 각 서비스마다의 통신으로 인해 오버헤드가 생기면서 성능에대한 이슈가 당연히 나타났습니다. 이로인해 ‘리액티브’가 더 활성화를 띄게되면서 마이크로서비스의 비동기, 메세지기반 통신의 중요성이 높아지고 특히나 Spring 5.0 업데이트에서 Reactive 기반의 WebFlux가 출시되기도 하였습니다.
마무리
이번 챕터에서는 마이크로서비스에 대해 알아보고 마이크로서비스로 인해 바뀌어간 개발 환경들을 알아보았습니다. 이는 개인적인 생각으로 서술한 내용이라 혹시 틀린 내용이 있거나 다른생각이 있으신분은 댓글을 통해 알려주시면 감사드리겠습니다!