Monolithic vs. Microservice
시스템을 구축하고 운영하는 방식 중에, 모놀리식 방식과 마이크로 방식에 대해 알아보자.
Monolithic
개요
어플리케이션을 개발함에 있어 필요한 모든 요소를 하나의 커다란 소프트웨어 안에 전부 포함시켜 개발하는 방법이다.
데이터베이스 관련된 로직이라던가 비즈니스 로직 뿐만 아니라 화면을 처리해주는 프론트엔드 기술까지,
이 모든 서비스의 내용들이 하나의 어플리케이션에서 유기적으로 연결되어 작동되고 있고,
배포되기 위해 서로 의존성을 가지고 패키징 되고 운영서버에 배포하게 된다.
위 사진처럼 하나의 커다란 건축물과 같다고 생각할 수 있다.
조금 더 자세히 알아보자
앞서 설명한 것 처럼, 모놀리식 방식에서는 모든 비즈니스 로직에 관련된 서비스들이 하나의 커다란 어플리케이션 형태로 패키징되어 서비스하게 된다.
일반적으로 어플리케이션에서 사용하는 데이터베이스 자체도 하나의 저장소에서 집중되어 저장하게 된다.
위 사진처럼 세 가지 서비스가 있는 어플리케이션에서 하나의 공통적인 데이터베이스를 쓰는 형식이다.
이러한 모놀리식 방식의 문제점은 하나의 시스템에 어플리케이션을 구성하고 있는 모든 서비스들이 패키징되어 서비스 되어야하기 때문에
시스템 일부만 수정한다하더라도 전체 어플리케이션을 다시 빌드 -> 테스트 -> 패키징 해야한다는 것이다.
예를 들어, calculation 이라는 서비스의 일부 로직이 변경되었을 때,
그것과 관계 없는 todo 기능과 copy 기능을 포함한 전체 어플리케이션을 다시 빌드 -> 테스트 -> 패키징 한다는 것이다.
MSA
개요
MSA 방식은 앞서 설명한 모놀리식 방식과 상반되는 개념으로,
어플리케이션을 구성하는 각각의 구성 요소 및 서비스의 내용을 분리해서 개발하고 응용하는 방식이다.
하나의 큰 덩어리로 개발되는 모놀리식 방식에 비해, 유지보수나 변경사항을 적용하는데 훨씬 더 유리하다.
쉽게 말해, 비즈니스 로직의 어떤 서비스의 프로세스가 변경되어 새로 개발되고 배포되어야 하는 상황이라고 가정했을 때,
필요한 부분에 대해서만 개발하고, 분리된 서비스가 다른 서비스에 영향을 주지 않거나 최소화 하면서 독립적으로 배포가 가능하다.
따라서 어플리케이션 전체가 다운타임이 되는 현상을 없앨 수 있다.
이런 MSA 방식은 각각 용도에 맞는 컨테이너들을 모아서 사용하는 서비스 개념이라고 생각할 수 있다.
조금 더 자세히 알아보자
Building Microservices 라는 책의 저자인 Sam Newman은 마이크로 서비스에 대해 “함께 작동하는 작은 규모의 서비스들” 이라고 정의했다.
앞서 설명한 내용을 하나의 문장으로 잘 정의했다고 볼 수 있다.
더불어, MSA의 스타일에 대해
“HTTP 통신을 이용해 리소스 API에 통신할 수 있는 작은 규모의 여러 서비스들의 묶음이 모여 하나의 어플리케이션을 구성한다.” 라고했다.
이러한 서비스들은 비즈니스 기능을 중심으로 구축되어야 하고, 완전하게 자동화된 배포 시스템을 사용해야 한다.
클라우드 네이티브 어플리케이션에서 가져야 할 4가지 조건을 상기해보자.
- Microserves
- CI/CD
- DevOps
- Containers
지금까지 학습한 내용이 위 4가지에 포함되어있는 것이다.
마이크로 서비스의 창시자로 불리는 Martin Fowler가 정의한 내용에 대해 알아보자.
Martin Fowler는 마이크로 서비스들이 가져야할 특징 중에서,
- 각각의 서비스들은 최소한의 중앙집중식 관리가 되어야하고
- 서로 다른 프로그래밍 언어를 사용할 수 있으며
- 서로 다른 데이터 저장 기술을 사용할 수 있다.
라고 했다. 또한,
- 기존 모놀리식 방식과 마이크로 서비스 개발 방식의 가장 큰 차이점은 “하나의 서비스를 구성하고 있는 크기” 이며
- 그 서비스의 크기가 도메인의 특징을 고려해서 경계를 구분해야하고
- 구분된 서비스들은 독립적인 언어와 독립적인 데이터베이스를 사용할 수 있다.
(각각의 서비스 별로 특색에 맞게 최적화 되어있는 언어와 데이터베이스 사용 권장)
라고 했다.
예를 들어 서버 사이드 개발에서는 java, 하드웨어 제어에서는 c와 c++, 데이터 분석과 머신러닝을 위해서는 python,
서버 사이드 자바 스크립트와 비동기 서비스를 위해서는 nodejs 등…
이렇게 사용하게 되면 각각의 기능에 맞춰 최적화 되어있는 퍼포먼스를 발휘할 수 있다.
서비스의 종류와 기능에 맞춰 개발 언어를 선택하고,
각각의 서비스들을 자신이 제공해야하는 서비스나 데이터를 API를 통해 제어할 수 있도록 한다.
굳이 통일된 언어를 사용할 필요가 없다는 것이다.
더욱이 요즘처럼 다양한 스마트 디바이스들이 클라이언트로서 사용된다고 하면
더이상 웹브라우저에서 제공되는 형태로 프론트엔드 기술을 정할필요도 없고, 거기에 따라 제약을 가진 상태에서 개발 할 필요가 없다.
Monolithic vs Front&Back vs Microservice Architecture
모놀리식 방식과 MSA 방식의 중간 정도의 개발 방식으로써,
프론트엔드와 백엔드를 분리해서 개발하는 방식도 자주 사용된다.
하나의 어플리케이션에 모든 로직과 서비스가 포함되는 모놀리식 방식보다는,
사용자에게 화면을 보여주고 어떤 액션을 처리받도록 하기 위한 프론트엔드 부분과 서버사이드를 분리해서 개발하는 방식이다.
이는 대표적으로 모바일 어플리케이션에서 많이 볼 수 있는 방식이다.
이렇듯 서버와 클라이언트를 분리해서 개발하게 되면, 서로 간에 필요한 통신만 맞다면 각각 최적화되어있는 개발 환경을 독립적으로 유지할 수 있다.
또한 사용자에게 보여지는 앱의 인터페이스 혹은 화면을 변경해야하는 상황에서, 백엔드 서버 자체를 같이 포함해서 빌드할 필요가 없어진다.
마지막으로 MSA에 대해 보면, 하나의 커다란 백엔드가 아니라,
위 사진에서처럼 Product Service, Reco Service, Basket Service, Payment Service 등 각각의 서비스가 독립적으로 구분되고,
데이터베이스도 하나의 통일된 데이터베이스를 사용하는게 아니라 독립적으로 분리되어 사용되는 것을 확인할 수 있다.
Monolithic vs Microservice Architecture
마지막으로, 도식화된 이미지로 둘의 차이를 정리해보자.
Monolithic
위 사진은 전통적인 모놀리식 방식으로 어플리케이션을 개발할 때의 모습이다.
모놀리식 방식에서는 화면을 나타내는 UI 라던가 웹 서비스, 비즈니스 로직, 데이터베이스 로직을 하나의 구성 요소로 보고 있고,
시스템에 데이터베이스를 포함하여 같이 구성을 하게된다.
Microservice Architecture
위 사진은 마이크로 서비스 방식인데, 모놀리식 방식보다는 조금 더 복잡해보인다.
최근에는 어떤 어플리케이션을 개발한다 하더라도 스마트 디바이스를 고려하지 않을 수 없다.
더 많은 사용자들이 자신의 웹브라우저나 윈도우 어플리케이션만을 이용해 서비스를 이용하지 않는다는 의미이다.
10년 전만해도 개발 회사가 사용자를 고려할 때에는, 웹 브라우저 혹은 사용자가 운영체제에 직접 설치하여 사용하는 윈도우 어플리케이션 정도만 고려했다.
그런데 스마트 디바이스의 발달로 기업에서 서비스를 제공함에 있어서 다양한 디바이스를 고려하지 않을 수 없게 되었다.
스마트 워치와 같은 웨어러블 디바이스 혹은 스마트 폰, 태블릿, 노트북과 같은 다양한 형태의 디바이스를 고려해야 한다.
디바이스가 다양하다는 것은, 사용자의 요청 정보를 처리하는 서버 사이드 기술도 그에 맞게 다양한 형태로 서비스 되어야 함을 의미한다.
그러나, 모든 디바에스에 맞는 방식으로 개발/테스트 하는 것에 무리가 따른다.
예를 들어, 삼성전자에서 만드는 갤럭시 폰만 하더라도 S 시리즈, Note 시리즈, A 시리즈 등이 있다.
각각의 디바이스는 디스플레이 장비도, 화면 해상도도, 입력 방식도 모두 다를 것이다.
따라서 이렇게 변화가 많은 클라이언트의 단말기는 프론트엔드 개발 회사에 맡기고,
서버에서는 서비스의 핵심적인 내용과 그러한 비즈니스 로직을 처리하기 위해 필요한 내용을 통일된 포맷으로 클라이언트 단말기에 전달하기만 하면,
고려해야할 사항이 훨씬 줄어들 수 있을 것이다.
또한 서버 사이드에서 개발해야하는 각각의 기능들도 각각의 서비스에 경계에 맞는 형태로 개발 -> 테스트 -> 배포 됨으로써
서로 다른 서비스들과 독립적으로 관리할 수 있게 된다.
무엇보다 중요한 것은, 이러한 마이크로 서비스들을 관리하기 위한 기술도 같이 발전되어야 한다는 것이다.
- 서비스 요청에 대한 통일된 게이트 웨이
- 각각 서비스들의 등록/검색
- 서비스들의 부하 분산
- 서비스에 문제가 생겼을 때 대처하기 위한 방법
- 분리된 서비스들의 데이터를 동기화 하기 위한 매커니즘
들이 필요하다.
바로 이러한 기술들이 우리가 클라우드 네이티브 아키텍처 어플리케이션을 개발함에 있어서
단순한 어플리케이션의 “개발” 뿐만 아니라, 각 서비스의 “infra structure” 와 “배포” 및 “운영 방식”에 대해 같이 알아두어야 할 이유이다.
💛 개인 공부 기록용 블로그입니다. 👻