필자는 Back-End를 공부하는 입장에서 어떻게 하면 구조를 좋게 잡을지 고민이 많았다.
기존에는 하나의 프로그램에 모든 기능을 넣어서 실행하는 방식으로 진행해왔다.
실제로 프로젝트를 진행하면서 윗 줄의 내용처럼 진행을 하니, 한쪽에서 문제가 생겨 프로그램이 죽는다면 다른 모든 기능들을 사용할 수 없게 된다.
추가적으로 프로젝트의 규모가 조금씩 커지면서, 유지보수를 할 때 연관되어있는 부분이 있다면 함께 수정해야되서 비교적 까다로웠다.
그래서 프로그램을 개발할 때, 어떻게 구조를 가져가면 좋을지 알아보던 중, MSA라는 아키텍쳐를 알게 되었다.
그래서 이번에 MSA에 대해서 알게된 것, 기존 프로그램의 방식과의 차이점이 무엇인지 알아보려고 한다.
기존의 프로그램 구조, 모놀리식(Monolithic)
모놀리식 아키텍쳐는 하나의 코드베이스로 이루어진 구조를 가지는 아키텍쳐이다.
여기서 하나의 코드베이스라는 말은 모듈이나 서비스 등의 코드들이 하나의 프로젝트 안에 모두 들어가 있고, 단일 DB를 사용함을 의미한다.
예를 들어 커뮤니티를 만든다고 하면 User를 관리하는 기능, 게시물을 관리하는 Post 기능 등이 있을 수 있는데, 이를 표현하면 아래 그림과 같다.
모놀리식의 장점
모놀리식 아키텍쳐의 장점은 다음과 같다.
- 간단한 개발과 실행
- 애플리케이션의 설계가 비교적 적게 들어가서 개발하기 용이하다.
- 이를 실행할 때도 단일의 프로그램을 실행하면 되기에 간편하다.
- 기술 스택의 단일화
- 하나의 코드베이스로 돌아가기 때문에 단일의 프로그래밍 언어나 기술 스택을 선택한다.
- 그래서 협업하는 대상과 관련 지식을 공유하기 쉽다.
- 디버깅이 용이함
- 모든 코드가 단일 프로그램에 들어가 있기 때문에, end-to-end 디버깅 하기가 쉽다.
- 간편한 배포
- 프로그램을 배포할 때도 단일 프로그램으로 배포하기 때문에 간편하다.
- 이후에 수정사항이 생겨 코드를 수정한다 하더라도 다시 단일 프로그램으로 배포하면 된다.
모놀리식의 단점
모놀리식 아키텍쳐의 단점은 다음과 같다.
- 규모가 크기와 유지보수성의 반비례
- 프로그램의 규모가 커질수록 관리하기가 어려워진다.
- 특정 부분에서 문제가 생긴다면, 프로그램 전체에 영향을 주어 유지보수가 어려워진다.
- 유연성의 부족
- 하나의 코드베이스로 이루어진 구조이기에 하나의 기능이 다른 부분에도 연관되어 있을 수도 있다.
- 만일 특정 부분을 수정해야 하는데, 연관된 다른 부분이 있다면 그 부분까지 수정해야 하므로 불필요한 시간 낭비가 생기가 된다.
- 협업의 어려움
- 각각 다른 부분을 개발하고 병합하는 과정에서, 하나의 프로젝트에서 합치는 것이기 때문에 다른 사람의 충돌이 빈번하게 일어날 수 있다.
- 또한 단일의 프로그래밍 언어와 기술 스택을 사용하므로 다른 언어나 기술스택을 사용하기 어렵다.
- 개발 및 배포 속도 저하
- 조금의 수정사항이 생기더라도 프로그램 전체를 빌드해서 배포해야 하기 때문에 속도가 느릴 수 있다.
- 그리고 배포의 속도는 프로그램의 규모가 커질수록 더욱 느려진다.
MSA(Microservice Architecture)란 무엇인가
마이크로서비스 아키텍쳐(이하 MSA)는 프로그램을 서비스 단위로 분할해서 실행되는 구조를 말한다.
마틴 파울러의 MSA 정의
아래는 마틴 파울러가 정의한 MSA에 대한 정의다.
링크 : https://martinfowler.com/articles/microservices.html
the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
위 문장에서 small services, each running in its own process, independently deployable services에 중점을 두고싶다.
각각의 의미는 개별 프로세스에서 돌아가는 소규모 서비스, 독립적으로 배포 가능한 서비스를 의미한다.
요약하면 MSA는 개별 프로세스에서 돌아가면서, 독립적으로 배포가 가능한 소규모의 서비스를 의미한다고 생각해도 될 것 같다.
MSA의 장점
MSA의 장점은 다음과 같다.
- 독립적
- 각각의 서비스가 개별적으로 돌아가고 있기 때문에 독립적이다.
- 따라서 하나의 서비스가 문제가 생겨 프로그램이 다운되더라도 다른 서비스는 이용할 수 있다.
- 확장 및 유지보수의 용이
- 특정 서비스 기능이 필요한 경우, 별도 서비스를 개발하여 추가하면 된다.
- 이로 인해 개별적인 코드 관리로 유지보수가 비교적 쉬워진다.
- 자유로운 기술 스택의 선택
- 서비스 별로 각각 다른 프로그래밍 언어나 기술 스택을 선택할 수 있다.
- 그래서 협업할 때 하나의 기술에 얽매이지 않고 자유롭게 기술스택을 선택할 수 있다.
- 배포의 용이성
- 소규모의 microservice 단위로 배포를 하기 때문에 전체 서비스에 영향을 주지 않고 빠른 배포가 가능하다.
- 이로인해 요구사항을 신속하게 반영할 수 있다.
MSA의 단점
MSA의 단점은 다음과 같다.
- 설계의 어려움
- 초기 설계를 진행할 때 모놀리식 방식 보다 생각해야 할 부분이 많다.
- 그래서 설계할 때 비교적 어려움이 발생할 수 있다.
- 테스트
- 개별적인 단위 테스트는 쉽지만, 통합 테스트가 된다면 여러 서비스의 API를 검증해야 한다.
- 때문에 시간과 비용이 많이 들어갈 수 있다.
- 성능의 문제
- 서비스간 호출 시 API간 통신을 진행하기 때문에 통신 시간 및 지연 시간이 발생할 수 있다.
API Gateway
MSA는 개별 서비스로 돌아가게만 두면 여러가지 문제가 발생할 수 있다.
Client에서 각각의 microservice에 접속하면 소규모의 모놀리식 애플리케이션이 여러 개 있는 것과 똑같다.
이럴 경우 문제는 다음과 같다.
- 그렇기에 애플리케이션마다 인증/인과 같은 공통된 작업을 추가적으로 구현해야 한다.
- Client에서도 각각의 microservice에 개별적으로 요청해야 하므로 각각의 EndPoint를 관리해야 해서 번거롭다.
그래서 MSA를 개발할 때 API Gateway를 도입한다.
API Gateway를 도입할 경우 생기는 이점은 다음과 같다.
- Client에서는 API Gateway의 EndPoint만 관리하면 된다.
- API Gateway에서 인증(Authentication)/인가(Authorization) 를 처리하여 각각의 서비스의 부담을 줄인다.
- 요청에 따라 개별 서비스에 요청을 보내는 로드 밸런서 역할을 한다.
물론 API Gateway를 추가함으로서 네트워크 통신의 복잡함은 늘어날 수 있기 때문에 주의할 필요가 있다.
모놀리식과 MSA의 선택 방법
위 정리를 통해서 모놀리식과 MSA가 각각 어떠한 특징을 지니고 장단점이 어떤지를 알 수 있다.
그러면 개별 서비스를 실행하는 MSA를 선택하는 것이 무조건 좋을까?
무조건 맞다 라고는 할 수 없을 것이다.
프로젝트를 진행하면서 소규모의 프로젝트를 진행 할 경우, MSA를 사용하게 되면 오히려 개발 기간이 늘어나고 테스트하기 번거로울 수 있다.
그렇다고 모놀리식으로 개발을 이어가자니, 나중에 확장을 해야하면 큰 문제가 발생할 수 있을 것이다.
그래서 설계 할 때 최종적으로 어떤 아키텍쳐를 선택할 지를 고민하는 것이 좋다고 생각한다.
만일 위의 방식이 안된다면 모놀리식으로 개발을 진행하다가 MSA로 전환하는 것도 고민해볼만 하다고 생각한다.
출처 : 모놀리식 vs 마이크로서비스, 어떤 아키텍쳐를 선택할까?, [데이터 분산 처리] MSA 아키텍처란?, MSA 제대로 이해하기 -(3)API Gateway
'개념정리 > 설계' 카테고리의 다른 글
| 도메인 주도 설계(DDD)란? (1) | 2024.01.27 |
|---|
