Monolithic VS MSA

본 포스팅은 인프런
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
강의를 기반으로 작성된 포스팅입니다.

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

---

Monolithic VS MSA(Microservice Architecture)

Application을 개발하는 방법에는 여러가지 방법론이나 프로세스가 존재한다.

그 중에서 시스템을 구축하고 운영하는 방식인 모놀리스, 마이크로 서비스 방식에 대해서 알아보자.

 

모놀리스

어플리케이션을 개발함에 있어서 필요한 모든 요소를

하나의 커다란 소프트웨어 안에서 모두 포함시켜 개발하는 방법

DB와 관련된 로직, 비지니스 로직, 프론트엔드 기술까지

모든 서비스의 내용들이 하나의 어플리케이션 내에서 유기적으로 연결되어

작동하고 있고 배포되기 위해서 서로 의존성을 가진채 패키징되고

운영서버에 배포하게 된다.

하나의 커다란 건축물과 같다.

 

시스템의 일부만 수정한다 하더라도 전체 어플리케이션을 다시 빌드하고

테스트하고, 패키징, 배포 해야한다는 단점을 가지고 있다.

 

마이크로 서비스

위와 상반되는 방식으로 어플리케이션을 구성하는 각각의 구성요소 및

서비스의 내용을 분리해서 개발하고 운영하는 방식이다.

하나의 큰 덩어리로 개발되어지는 모놀리스 방식에 비해서 유지보수나

변경사항을 적용하는것에 더욱 유리하다.

 

쉽게 말해서 비지니스 로직의 어떤 프로세스가 변경되어 새로 개발, 배포되어야 한다면

필요한 부분에 대해서만 개발하고 분리된 서비스가 다른 서비스에 영향을 주지 않거나

최소화 하면서 독립적으로 배포가 가능하게 된다.

 

따라서 어플리케이션 전체가 다운타임이 되는 현상을 억제할 수 있다.

이러한 마이크로 서비스 방식은 각각의 용도에 맞는 컨테이너들을 모아서

사용하는 서비스의 개념이다.

 

마이크로 서비스 아키텍처 스타일은

HTTP 통신을 이용하여 리소스 API에 통신할 수 있는 작은 규모의

여러 서비스들의 묶음이다. 

 

비지니스 기능을 중심으로 구축되어야 하고 완전하게 자동화된

배포 시스템을 사용하여야 한다. -> CI / CD

 

 

마이크로 서비스에서

각각의 서비스들은 최소한의 중앙 집중식 관리가 되어야하고

서로다른 프로그래밍 언어와 서로 다른 데이터 저장기술을 사용할 수 있다.

기존의 모놀리스 방식과 마이크로 서비스 방식의 가장 큰 차이점은

하나의 서비스를 구성하고 있는 크기이다.

그 서비스의 크기가 도메인의 특성을 고려하여 경계를 구분하여야 하고

구분된 서비스들은 독립적인 언어와 독립적인 데이터베이스를 사용할 수 있다.

 

마이크로 서비스에서는 전체 어플리케이션에서 언어, DB 등을 통일하는것이 아니라

각각의 서비스별로 특색에 맞게 최적화 되어있는 언어와 DB를 사용하는것을

권장하고 있다.

 

각각의 언어와 DB는 각각 최적화 되어있는 퍼포먼스를 발휘할 수 있다.

서비스의 종류와 기능에 맞추어 개발 언어를 선택하고

각각의 서비스들은 자신이 제공해야 하는 서비스나 데이터를 API를 통해서

제어할 수 있도록 하면된다. 굳이 통일된 언어를 사용할 필요가 없다.

 

---

Front End & Back End

마이크로 서비스와 모놀리스 사이에 자주 사용되는 방식

서버와 클라이언트만 분리하여 개발 하게되면

서로에게 필요한 통신만 하게되고 각각 최적화 되어있는

개발 환경을 독립적으로 유지하는게 가능하게 된다.

사용자에게 보여지는 앱의 인터페이스, 화면이 변경되는 경우라 하더라도

백엔드 서버를 같이 포함하여 빌드할 필요가 없어진다.

 

---

MSA

화면의 왼쪽은 전통적인 모놀리스 방식이고

오른쪽은 마이크로 서비스 방식이다.

모놀리스에서는 화면을 나타내는 UI, 웹서비스, 비지니스 로직, DB 로직 등을

하나의 구성요소로 보고있고 시스엠에 DB를 포함하여 함께 구성하게 된다.

 

최근 개발에서는 스마트 디바이스를 고려하지 않을 수 없다.

디바이스가 다양하다는것은 사용자의 요청정보를 처리하는

서버사이드 기술도 거기에 맞는 다양한 형태로 서비스 되어야 한다는것을 의미한다.

그러나 모든 디바이스에 맞는 방식을 일일히 개발하거나 테스트하는것은 무리이다.

 

따라서 이렇게 변화가 많은 클라이언트의 단말기는 프론트에 맡기고

서버에서는 서비스의 핵심적인 내용, 비지니스 내용을 통일된 포맷으로

클라이언트 단말기에 전달하기만 하면 고려해야할 사항이 훨씬 더 줄어들게 된다.

 

또한 서버사이드에서 개발해야하는 각각의 기능들도 각 서비스의

경계에 맞는 형태로 개발되고 테스트, 배포됨으로써 하나의 어플리케이션을

구성해야 하는 다른 서비스라고 할지라도 독립적으로 관리할 수 있게 된다.

 

무엇보다 중요한것은 이러한 마이크로 서비스들을 관리하기 위한 기술도

함께 발전되어야 한다. 서비스 요청에 대한 통일된 게이트웨이나,

서비스들의 등록과 검색, 부하분산, 문제가 발생했을 때 대처하는 방법,

분리된 서비스들의 데이터를 동기화 하기위한 매커니즘들이 필요하게 된다.

 

이러한 기술들이 어플리케이션을 개발함에 있어서

각 서비스의 인프라 스트럭쳐와 운영, 배포 방식을 알아야하는 이유이다.