[Cloud] : 05. MSA 기본

March 10, 2022

서론

이번 시간에는 Cloud를 활용한 대표적인 어플리케이션 개발 방법론인 MSA에 대해서 포스팅할려고 한다. MSA가 무엇인지 부터 시작해서 필자가 이전에 MSA 개발하면서 경험했던 기술들과 고려가 필요한 부분이 무엇이 있는지 알려드리고자 한다.

MSA를 설명하기 앞서 Cloud Native Application이라는 단어부터 정의할 필요가 있다. 많은 사람들이 Cloud Native Application와 MSA를 착각하거나 명확하게 구분할줄 모른다. Cloud Native Application 이란 클라우드를 적극 활용할 애플리케이션이라는 의미로서 MSA는 Cloud Native Application를 만들기 위한 접근 방식 중 하나라고 할 수 있다.
Cloud Native Application을 만들기 위한 접근 방식 및 기술은 대표적으로 아래 사진과 같이 네가지 있다.

[참고:paas-ta.kr]

MSA : 어플리케이션을 서비스 단위로 쪼개어 각 서비스는 API를 통해 통신하게 만드는 소프트웨어 아키텍처.
DevOps : 프로세스 자동화를 목표로 개발자와 운영자가 협업하여 짧은 주기내 신뢰성 있는 소프트웨어 생성, 테스트, 릴리즈 할 수 있는 문화와 환경.
CI/CD : Continuous Integration(지속적인 통합) / Continuous Delivery(지속적인 제공)라는 의미로서 어플리케이션 코드 변경에 대해서 정기적인 빌드 및 테스트 진행, 지속적인 통합를 통한 서비스의 빌드 및 배포에 대한 신뢰성을 확보하는 방법론.
Container : 컨테이너 가상화를 통해 각 어플리케이션을 컨테이너 단위로 수행하게 하여 높은 수준의 안정성과 확장성을 제공.

[참고:paas-ta.kr]

MSA란 Micro Service Architecture의 약자로서 어플리케이션을 각 서비스 단위로 쪼개어 개발한 소프트웨어 아키텍처로서 미국의 유명한 소프트웨어 엔지니어인 마틴 파울러는 다음과 같이 MSA를 정의하고 있다. “마이크로서비스 아키텍처이란 단일 애플리케이션을 자체 프로세스로 실행되고 경량 매커니즘(주로 HTTP 리소스 API)으로 통신하는 작은 서비스들의 모음으로 개발하는 방식이다”
하나의 어플리케이션을 서비스 단위로 나눈다는 말이 이해 안될 수 있지만, 아래 사진을 의해 쉽게 생각할 수 있다. 일반적인 온라인 쇼핑물을 각 서비스 단위로 나눈다면 “사용자관리”, “상품관리”, “주문관리”로 나눌수 있다.

image-center

[참고:paas-ta.kr]

기존 전통적인 어플리케이션을 Monolithic Architecutre라고 한다. 모널리틱 아키텍처의 경우 오늘날에 들어 아래와 같은 문제점이 발생하였다. 아래와 같은 문제점 떄문에 MSA가 등장하였다.
부분 장애가 전체 장애가 될 수 있다
- 개발자 한명의 실수로 인해 발생한 문제가 전체 시스템의 치명적인 장애로 다가올 수 있다.
확장이 상대적으로 힘들다
- 신규 기능을 추가하기 위해서는 기존의 소스에 추가하는 형태로 되기 때문에 기존 시스템에 영향이 있기 떄문에 확장에 제약이 생긴다.
배포 및 유지보수에 비용이 많이 든다
- 시스템을 단일 소스를 가는 경우 소스의 양이 많고 각 기능에서 사용하는 라이브러리 등 신경써야 될 부분이 많기 때문에 배포가 오래 걸리며 전체 단위로 유지보수를 하는 경우 체계적인 관리가 힘들기 때문에 비용이 많이 든다.
한가지 기술에 종속적이다
- 만일 JAVA 기반의 웹 어플리케이션을 만들었다면 JAVA의 종속적인 기술을 쓸 수 밖에 없다. 어느 경우는 Python와 같은 언어가 효과적이지만 단일 시스템이기 때문에 JAVA를 사용할 수 밖에 없는 상황이 된다. 모널리틱 아키텍처는 신기술이나 다양한 기술을 사용하기 힘들다.

Monolithic의 단점을 보안하고자 만들어진 MSA는 아래와 같은 장점을 가진다.
다양한 기술 사용 가능
- 각 요구사항, 기능에 대해서 최적한된 언어와 아키텍처를 사용할 수 있다.
회복성과 확장성
- 클라우드를 Scale OUT/IN을 사용하여 언제든지 확장 및 축소가 가능하며, 클라우드 레벨에서 각 어플리케이션에 대한 복구를 담당한다.
쉬운 유지보수
- DevOps와 결합된 MSA는 자동화된 파이프라인을 통해 배포 및 테스트를 간편하게 할 수 있다. 이를 통해 조금 더 쉬운 유지보수가 가능하다.
추가 기능 개발 용이
- 만일 추가적인 기능 및 시스템을 개발하기 용이하다. 만일 필요하다면 새로운 서비스를 추가하는 방식으로 개발이 가능하다.

MSA도 또한 장점만 가지는 방법이 아니다. MSA는 아래와 같은 단점을 가진다.
시스템 복잡성 증가
- 단일 시스템을 각 서비스를 나눠어 개발 및 관리하기 때문에 일정 수준 이상의 시스템이 아닌 경우 관리할 서비스 개수만 증가하여 관리하기 더 힘들 수 도 있다.
- MSA 기반의 어플리케이션을 개발하기 위해서 MSA를 위한 기능&시스템을 적용해야 한다.
- 서비스 단위로 나누는 방법이 정해져 있지 않기 때문에 이를 분해하기 위한 기획 및 분석이 필요하다.
통합 테스트가 어렵다
- 각 서비스로 나눠져 있기 때문에 통합 테스트가 하기가 어렵다.
중복성
- 각 서비스가 나눠져 있기 때문에 기능이 중복되는 경우가 발생하거나 소스, 코드, 데이터 중복이 발생할 수 있다.(예 : 공통 처리를 위한 소스)
높은 러닝 커브
- MSA 기반의 어플리케이션을 만들고 관리하기 위해서는 Infra, 클라우드, CI/CD, DevOps, K8S 와 같은 기반 지식들이 필요하다. 이러한 기술 및 지식을 배우기 위해서는 많은 시간이 필요하다.

이번 시간에는 MSA에 대한 전반적인 내용을 다뤘다. 다음 시간에는 이전에 MSA 개발 했던 경험을 토대로 MSA 개발하기 위해서는 필요한 기술이 뭐엇이 있는지 알아보겠다.