요즘 공고를 보거나 이름 내놓으라는 기업들을 보다 보면 MSA라는 단어를 많이 접하게 된다.
본인이 개발할 때도 MSA로 서비스를 분리하여 개발하고 관리하였는데 과연 MSA가 무조건 정답일까?
그럼 이전 모놀리식 아키텍처를 사용하는 것은 잘못된 개발이었을까?라는 의문이 생길 수 있다.
오늘 이 글은 필자가 개발하고 공부하면서 고민했던 내용들을 정리하고자 작성한다.
모놀리식 아키텍처가 뭔가요?
해당 내용을 다루기 전에 모놀리식 아키텍처가 무엇인지 알아보자.
모놀리식 아키텍처란 프로그램을 하나의 코드베이스에 개발하는 전통적인 아키텍처 모델을 의미한다.
이게 무슨 말인가?
우리가 서비스를 제공한다 하면 기본적으로 아래와 같은 비즈니스 기능들을 제공하게 될 것이다.
- 회원관리
- 게시판
- 알림
위와 같은 기능들을 제공한다 가정할 때 하나의 애플리케이션이 모든 비즈니스 기능들을 제공하는 책임을 가지는 것이다.
즉 Client가 회원관리 요청을 보내든 게시판관리 요청을 보내든 알림 관련 기능 요청을 혹은 응답을 보내든 하나의 서버에서 해당 기능들을 처리하는 것을 의미한다.
이렇게 개발하였을 때의 장점과 단점은 무엇일까?
우선 장점은 이와 같이 생각해 볼 수 있다.
1. 개발 시작이 간단하다.
하나의 코드베이스에서 모두 개발하기 때문에 간단한 설계 이후 바로 개발이 가능하다.
왜냐면 어차피 하나의 코드베이스에서 개발하기 때문에 추후 리펙토링이 간단하기 때문이다.
2. 배포가 간단하다.
하나의 코드베이스에서 개발하게 된다면 하나의 애플리케이션만 관리하면 되므로 하나만 잘 관리하면 문제 될 일이 없을 것이다.
3. 기술이 통합된다.
하나의 애플리케이션에서 개발하고 관리하게 되므로 사용하는 기술이 단일화될 것이다.
그렇다면 단점은 무엇이 있을까?
1. 확장이 어렵다.
새로운 기능이 추가될 때마다 애플리케이션의 크기가 거대해질 수밖에 없다.
이렇게 된다면 추후 유지보수성을 떨어트릴 뿐만 아니라 추가 기능구현에도 제약이 발생할 확률이 높다.
2. 배포가 어렵다.
애플리케이션에 간단한 수정내용을 반영하고 배포를 하게 된다면 통째로 재배포하게 된다.
이는 애플리케이션의 크기가 작다면 괜찮겠지만 크기가 커졌을 경우 배포시간이 길어지게 되면서 리소스를 많이 소모하게 되는 현상이 발생하게 된다.
3. 기술에 제약이 생긴다.
애플리케이션에서 사용하는 기술들이 통합되다 보니 추가적인 기술 도입이나 서로 다른 언어로 개발하는 것은 매우 어려운 일이 될 것이다.
예를 들어 Java/Spring으로 개발 중인 애플리케이션에 Python/Django를 사용해야 하는 상황이 발생한다면 이는 매우 어려운 길을 걷게 될 것이다.
위와 같은 장단점들을 보았을 때 모놀리식 아키텍처를 사용하는 것은 대규모 프로젝트 혹은 많은 비즈니스 기능들을 처리해야 하는 상황에서는 어려운 점들이 보일 것이다.
다만 소규모 프로젝트나 MVP처럼 빠른 시일 내에 개발하여야 하거나 적은 비즈니스 기능들을 처리하는 애플리케이션을 개발한다 할 때에는 오히려 개발 및 관리가 편한 아키텍처라 볼 수 있다.
MSA가 뭔가요?
그럼 우리가 이번글에서 비교하고자 하는 MSA는 무엇일까?
MSA란 Micro Service Architecture의 약자로 직역하자면 '작은 서비스 아키텍처'이다.
MSA는 서비스의 크기를 작게 나누는 개념이라고 볼 수 있다.
우리가 모놀리식 아키텍처를 사용하면서 가장 큰 불편함이 무엇인지를 생각해 보자.
기능이 추가됨에 따라 하나의 서비스가 커져 여러 불편한 상황이 발생하는 것이 문제점이라 생각한다.
즉, MSA는 기존에 하나의 서비스에 다 개발하였던 비즈니스 기능들을 관심사에 맞춰 부리한 여러 개의 서비스로 나눠 관리할 수 있는 아키텍처라고 보면 된다.
이와 같이 모놀리식 아키텍처에서 MSA를 적용하여 서비스들을 나눠볼 수 있다.
이렇게 보면 MSA를 적용했을 때의 장점은 다음과 같이 생각해 볼 수 있다.
1. 독립성 및 확장성
특정 비즈니스 기능들을 묶어 개발하게 되면서 각 서비스들은 특정 관심사를 책임지게 된다.
이는 각각의 서비스가 담당하는 비즈니스 기능들이 명확해지면서 추후 오류 추적이나 디버깅이 수월해질 수 있다.
또한 기능을 추가하더라도 각각의 관심사에 맞는 서비스에 기능을 추가하면 되므로 확장성과 유지보수성이 좋다.
2. 스케일의 용이
모놀리식의 경우 하나의 서비스를 관리하기 때문에 대용량 트래픽 혹은 대용량 데이터 처리와 같은 과제를 만나게 된다면 스케일 아웃과 같은 방법으로 처리하는 것은 매우 비효율적인 상황이 발생할 것이다.
하지만, MSA로 분리한 경우 대용량 트래픽이 몰리는 서비스만 스케일 업이나 스케일 아웃을 통해 해결하면 되므로 MA에 비해 컨트롤할 수 있는 방법이 많아진다.
3. 배포가 쉽다.
간단한 수정사항이 발생하였을 경우 해당 수정이 발생한 애플리케이션만 재배포를 진행하면 되므로 재배포에 대해 MA에 비해 적은 부담을 가지게 된다.
4. 기술적 제약이 적다
각각의 서비스가 물리적으로 분리되어있다 보니 특정 서비스의 기술을 다르게 개발할 수 있는 유연함이 생긴다.
즉 Java로 구현하든 Python으로 구현하든 Javascript로 구현하든 서로 영향을 미치는 범위가 적어 유연한 개발이 가능하다는 의미다.
장점이 있다면 단점 또한 존재하는 법 어떤 단점이 존재할까?
1. 설계의 복잡도
만약 처음부터 MSA를 적용하여 개발을 하게 된다면 어떤 기준으로 서비스들을 나누어야 하는지 설계의 고민이 필요하다.
설계가 잘못되어 하나의 서비스가 의도와 다르게 거대해진다면 이는 MSA를 적용하였지만 각각의 서비스는 MA를 적용하여 개발하는 것과 다를게 없어진다 생각한다.
2. 분산 시스템의 복잡도
여러 서비스로 나누다 보니 각각 어떤 통신을 하는지, 오류가 발생했을 때 해당 오류를 찾기 위해 여러 서비스를 확인해야 한다는 단점이 존재한다.
또한, 테스트를 진행할 때 특정 비즈니스 기능들이 모여있어 해당 기능들을 테스트하기는 수월하지만, 서비스 간 통신을 통한 비즈니스 기능들은 테스트하기 어려움이 존재한다.
트랜잭션 관리에 있어 어려움이 있으며, 이를 해결하기 위해 보상 트랜잭션과 같은 기능들이 구현해야 하기 때문에 자연스레 개발 난이도 및 유지보수 난이도가 올라간다.
3. 인프라 구축의 난이도 상승
각 서비스를 어떻게 관리할 것인지 또한 어떻게 배포할 것인지 각 서비스 간 통신은 어떻게 할 것인지에 대한 인프라가 구축되어야 한다.
이는 MA의 단순한 인프라에 비해 많은 리소스를 필요로 할 것이다.
이렇듯 MSA 또한 장점만 가지고 있는 것이 아닌 단점 또한 가지고 있다.
MSA 해보니 어땠나?
MSA를 경험하며 다양한 고민과 배움을 얻을 수 있었다.
혼자 사이드 프로젝트를 진행하면서 대규모 서비스들을 개발하는 경험은 쉽지 않다 생각한다.
현장에서 MSA로 구축된 프로젝트를 진행하면서 각 서비스를 나누는 기준과 어떤 어려움이 존재하는지를 경험할 수 있는 기회는 매우 소중한 경험이었다.
다만 무엇이든 잘못 설계하면 그렇듯이 너무 잘게 나누어 "굳이 나눌 필요가 있을까?"와 같은 고민들을 하게 될 수 있으며,
각 서비스 간 통신 방법에 대하여 동기와 비동기방식 중 어떤 것을 사용할지에 대해 고민하게 될 것이다.
처음부터 MSA를 도입하는 것은 어려운 선택일 수 있다.
먼저 모놀리식 아키텍처를 경험하며 그 한계를 느끼고, 이를 해결하는 과정에서 MSA를 도입하는 것이 더 좋은 학습 과정이 될 것이다.
처음에는 'MSA가 이미 적용되어 있으니 그대로 쓰면 되겠지'라는 생각을 했지만,
이는 왜 MSA로 구축하였는지에 대한 질문에 답변을 내놓지 못하는 상황이 발생할 수 있다.
MA와 MSA에 잘못된 아키텍처는 없다.
다만 "어떤 상황과 문제를 만났기 때문에 어떤 아키텍처를 적용하였다."를 답변하지 못한다면,
이는 스스로 잘못된 방향으로 경험을 쌓았다고 말하고 싶다.
아키텍처는 단순히 잘 돌아가는 것이 목표가 아니다.
주어진 환경에서 최적의 해결책을 찾기 위해 끊임없이 고민하고 실천하는 것이 진정한 개발자의 길이라 생각한다.
'Server' 카테고리의 다른 글
| [해결 과제] 인증 서비스 왜 Refactoring 하였을까? (0) | 2025.04.04 |
|---|---|
| [EDA] EDA는 왜 적용하게 된걸까? (0) | 2025.04.03 |
| [Architecture] Clean Architecture VS Hexagonal Architecture (0) | 2025.01.14 |
| [DNS] 너의 주소는? (6) | 2024.12.30 |
| [ JPA ] OSIV가 뭔가요? (1) | 2024.11.12 |