들어가며
이번 프로젝트에서 모놀리식 아키텍쳐 대신 MSA 구조를 선택하기로 하면서, 모놀리식 아키텍쳐와 MSA는 어떻게 다르고 왜 이런 의사결정을 하기로 했는지 현재 프로젝트에 빗대어 기술해보려고 한다!
🔎모놀리식 아키텍쳐란?
모놀리식 아키텍처( Monolithic Architecture )는 소프트웨어 프로그램의 전통적인 모델로, 자체 포함 방식이며 다른 애플리케이션과 독립적인 통합된 유닛으로 만들어진다. “모놀리스"라는 단어는 거대하고 빙하 같은 것을 의미하는 경우가 많은데, 소프트웨어 설계의 모놀리식 아키텍처도 크게 다르지 않다.
즉, 한 문장으로 간단히 정리해 보면!
MSA가 등장하기 이전에 하나의 서비스로 하나의 애플리케이션을 만드는 것이 모놀리식 아키텍쳐이다.
모놀리식 아키텍쳐의 장점
모놀리식 아키텍쳐로 개발하는 가장 큰 장점은 무엇보다 애플리케이션이 하나의 코드 베이스에 기반을 두어서 단순하기 때문에 개발 속도가 빠르다는 것이다. 다음은 모놀리식 아키텍쳐로 개발할 때의 장점들이다.
1. 편리한 개발
프로젝트 초기에는 코드 관리, 인지 오버헤드 면에서 모놀리스가 편리할 수 있다. 모놀리스에서 모든 것을 한꺼번에 릴리스할 수 있기 때문이다.
2. 테스트 간소화
모놀리식 애플리케이션은 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 엔드투엔드 테스트를 더 빠르게 수행할 수 있다.
3. 간편한 디버깅
모든 코드가 한 애플리케이션에 있으므로, 요청을 따라가서 문제를 찾기가 비교적 더 쉽다.
4. 손쉬운 배포
실행 파일 또는 디렉토리가 하나여서 개발 초기 단계에서 배포가 쉽다.
모놀리식 아키텍쳐의 단점
모놀리식 애플리케이션은 규모가 너무 커지고 확장이 어려워지면 더 이상 효과적이지 않다.
하나의 기능을 조금만 변경하려고 해도 전체 플랫폼을 컴파일하고 테스트해야 하기 때문에, 요즈음 많은 개발자들이 선호하는 애자일 접근 방식과는 더더욱 맞지 않다고 생각한다.
애플리케이션의 규모가 커짐에 따라 생기는 모놀리식 아키텍쳐의 단점은 아래와 같다.
1. 느려지는 개발 속도
대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려진다.
2. 확장에 불리
개별 컴포넌트를 확장할 수 없다. 즉 코드의 수정 및 추가가 힘들다.
3. 장애에 불리
부분적인 서버의 장애가 곧 전체 장애로 번질 수 있다.
4. 기술 채택의 장벽
프레임워크 또는 언어를 변경하면 애플리케이션 전체에 영향을 미치므로 변경 시 시간과 비용이 많이 소요될 수 있다. 즉 신기술 적용이 힘들어진다.
5. 불편해지는 배포
모놀리식 애플리케이션을 약간만 변경하는 경우에도 전체 모놀리스를 다시 배포해야 한다.
객체지향 프로그래밍을 공부하다 보면 '의존성'이라는 단어를 많이 접하게 된다. 결국 아키텍쳐 구조에도 의존성에 관한 개념을 적용해볼 수 있을 것 같다고 생각했다.
점점 성장하는 서비스를 생각해보면, 구현해왔던 여러 기능들이 하나의 애플리케이션에 묶여있고 서로간의 의존성이 높아지면서 쉽게 이해할 수 없는 레거시 코드로 이어질 것이다. 결국 이런 문제에 맞닥뜨리게 되는 서비스가 고려하게 되는 것이 MSA이고 이것이 곧 MSA의 탄생 배경인 것 같다.
🔎MSA 란?
이름에서부터 느낄 수 있듯 MSA(Micro Service Architecture)는 위에서 설명한 모놀리식 아키텍쳐의 단점을 도메인을 작은 단위로 분리하면서 상쇄하도록 한 아키텍쳐이다. 각 서비스는 특정 기능을 담당하며, 독립적으로 배포되고 운영된다.
마이크로서비스는 복잡성을 줄여주지는 않지만, 작업이 서로 독립적으로 작동하고 전체에 기여하는 더 작은 프로세스로 분리하여 복잡성을 눈으로 볼 수 있고 관리하기 쉽도록 만든다.
MSA의 장점
MSA가 모든 문제의 정답이라고 말할 순 없지만, 상단에서 서술한 모놀리스식 아키텍쳐의 여러 문제를 해결한다.
1. 유연한 기술 적용
MSA를 사용하면, 어떤 한 프레임워크나 언어에 종속되지 않고 팀이 원하는 기술을 선택할 수 있다.
2. 장애 격리
한 서버의 문제가 다른 서비스에 영향을 끼치지 않는다.
3. 독립적 & 지속적 배포 가능
마이크로서비스는 개별적인 유닛으로 이루어져 있으므로, 개별 기능을 빠르고 독립적으로 배포할 수 있다. 또 더 자주 릴리즈할 수도 있게 된다.
4. 유지보수 용이
하나의 서비스가 작고 독립적이기 때문에 유지보수가 쉬워진다.
5. 확장에 유리
각 서비스가 독립적으로 확장될 수 있어 특정 기능에 대한 성능 최적화가 용이하다.
MSA의 단점
여러 개의 독립적인 서비스로 분리함으로써 얻는 장점들도 많지만, 작은 단위로 나누면서 복잡성이 증가해서 오히려 여러 문제를 야기시킬 수도 있다.
1. 복잡도 증가, 초기 개발 시간 증가
마이크로서비스의 경우 여러 팀이 더 많은 장소에 더 많은 서비스를 만들기 때문에 서비스 간 통신, 데이터 일관성, 트랜잭션 관리가 모놀리스 아키텍처에 비해 더 복잡해진다. 무분별한 개발 확산이 적절하게 관리되지 않으면 개발 속도가 느려지고 운영 성능이 저하되는 결과가 나타날 수 있다.
2. 네트워크 비용 이슈
여러 서비스가 독립적으로 운영되므로 모니터링, 로깅, 배포 등의 운영 비용이 증가한다.
3. 복잡해지는 디버깅
각 마이크로서비스는 자체적인 로그 집합을 가지고 있어 디버깅이 더 모놀리식보다 더 복잡하다. 또한 여러 시스템에서 하나의 비즈니스 프로세스가 실행될 수 있으므로 디버깅이 더욱 복잡해진다.
🔎필자의 팀이 MSA 구조를 선택한 이유
서론이 길었다. 이제 본론으로 들어오게 됐는데, 필자의 팀이 프로젝트에서 MSA를 선택한 이유는 다음과 같다.
1. 단일 장애 포인트를 만들고 싶지 않았다.
단일 장애 포인트는 모놀리식 아키텍쳐의 최대 단점이라고 생각한다. 필자의 프로젝트는 온라인 강의 플랫폼으로, 결제, 주문, 강의, 강의자료, 쿠폰, 유저와 같은 여러 개의 도메인이 존재한다. 선착순 쿠폰 이벤트 등으로 동시성 이슈가 발생할 만한 서비스도 있었고, 결제와 같은 서비스에서 장애가 발생하면 온 서비스가 다운될 수 있는 모놀리식 아키텍쳐의 단점을 생각했을 때, 사용자의 경험만을 생각해보면 이런 단일 장애 포인트를 제거하여 전체 서비스 중단 위험을 감소시키는 것이 좋다고 여겼다.
2. 각 마이크로서비스 별로 DB를 분리함으로써 얻는 이점이 있었다.
도메인마다 적합한 DBMS가 다를 수 있다. 어떤 마이크로서비스에는 RDB가 적합하고, 다른 마이크로서비스에서는 NoSQL이 더 적합할 수 있다. 이렇듯 각 서비스에 적합한 DB를 정의할 수 있다.
또한 성능 상 이점도 가져갈 수 있다. 필자의 프로젝트에선 강의 관련 도메인을 '강의' 도메인과 '강의 자료' 도메인으로 나눠두었는데, 각 서비스가 다른 DB를 가지면서 강의 목록 조회 시 성능 향상을 기대할 수 있게 되었다.
3. 애플리케이션이 크고 복잡해질 것이라는 가정을 함께 하면서 시작했다.
우리 팀은 이 프로젝트가 시간이 지남에 따라 커지고 복잡해질것이라고 가정하면서 개발을 시작했다. 모놀리식 아키텍처에서는 기능이 추가되고 코드베이스가 커지면 유지보수가 어려워지고, 새로운 기능을 추가하거나 기존 기능을 수정할 때 다른 부분에 영향을 미치는 경우가 많아진다. 상단에서 기술했듯 아무래도 MSA는 API Gateway를 통한 대용량 트래픽 처리에 유리하며, 각 마이크로서비스가 독립적으로 개발되고 배포될 수 있어 이러한 문제를 피할 수 있다.
3-1. 독립적인 확장성을 추구했다.
플랫폼이 성장함에 따라 특정 기능에 대한 수요가 급격히 증가할 수 있다. 예를 들어, 강의 업로드 기능이나 동영상 스트리밍 기능은 사용자의 증가에 따라 많은 리소스를 필요로 할 수 있다. 모놀리식 아키텍처에서는 전체 시스템을 확장해야 하지만, MSA에서는 특정 서비스만 독립적으로 확장할 수 있기 때문에 리소스를 효율적으로 사용할 수 있고, 성능을 최적화할 수 있다.
4. 팀으로서 작업하기에 너무 편했다.
초반 MSA 환경 구성할 때만 시간이 다소 소요됐고, 그 이후에는 맡은 도메인 별 작업을 했기 때문에 코드 충돌 걱정이 없어서 너무 편했다. 아무래도 모놀리식 아키텍쳐는 모든 팀원이 동일한 코드, 동일한 프로젝트에서 작업하기 때문에 코드 병합 시 충돌 가능성을 배제할 수 없었고 이를 미연에 방지하기 위해 커뮤니케이션/스크럼에 시간을 더 투자하기 보다 개발에 더 집중할 수 있어 좋았다. (항상 깃 머지할 때마다 충돌날까봐 두근두근 했던 과거의 나 ..)
5. MSA 경험해보고 싶었음 ..ㅡ
마치며
아래는 모놀리식과 마이크로서비스를 비교한 표이다.
모놀리식 아키텍쳐 | 마이크로서비스 아키텍쳐 | |
쉽게 배포 가능? | O | X |
빠르게 배포 가능? | X | O |
비즈니스 확장 쉽게 가능? | X | O |
개발 시 리소스가 적게 드는지? | O | X |
기술은 비즈니스를 위해 존재하는 것
필자의 프로젝트에서는 MSA 구조를 선택했지만, 선택에 앞서 모놀리식와 마이크로서비스를 공부해 보니 특정 어떤 아키텍쳐가 무조건 더 좋다! 라는 정답은 없어보였다. 요즈음 MSA를 많이 쓴다고는 하지만 비즈니스 상황에 따라 맞지 않는 상황도 분명 존재한다. 무작정 모놀리식 아키텍쳐 vs MSA 구도로 나누기보단 ㅡ 현업에서 내가 속한 회사의 규모나 비즈니스의 요구사항, 팀원들의 MSA 경험 유무, 도메인에 대한 이해도 등등 현재 상황을 분석해 보고 어떤 아키텍쳐가 적합할 지 충분한 논의를 거친 후 적용하는 것이 정답일 것 같다.
References
https://www.atlassian.com/ko/microservices/microservices-architecture/microservices-vs-monolith
https://www.youtube.com/watch?v=SrQeIz3gXZg
https://yozm.wishket.com/magazine/detail/1813/
https://velog.io/@dmchoi224/Microservice-Architecture-MSA-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Monolithic
'Project > MSA 프로젝트' 카테고리의 다른 글
[트러블슈팅] '선착순 쿠폰 발급' 로직 - Redis를 통한 동시성 문제 해결 (2/2) (0) | 2024.06.30 |
---|---|
[트러블슈팅] '선착순 쿠폰 발급' 로직 - 동시성 문제 발생 (w/ Race Condition) (1/2) (2) | 2024.06.30 |
[프로젝트] 선착순/일반 쿠폰 발급 로직 분리에 대한 고민 (0) | 2024.06.29 |
[프로젝트][MSA] API Gateway 작성으로 모듈 별 연결하기 (0) | 2024.06.25 |
[프로젝트] 인텔리제이 깃 클론/pull 후 모듈 인식 불가 해결 (0) | 2024.06.13 |