먼저 MSA가 나오기 전의 Architecture 에 대해서 먼저 알아보도록 하겠다.

 

 

MSA가 도입되기 전의 모놀리식 아키텍처 (Monolithic Architecture)

모놀리식 아키텍처는 마이크로서비스 아키텍처에 반대되는 개념으로, 애플리케이션의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태를 말한다.

 

이러한 모놀리식 아키텍처의 장단점으로는 아래와 같다.

 

장점
  • 개발 초기에 단순한 아키텍처 구조로 인해 개발에 용이하다.
  • 어떤 서비스든지 개발되어 있는 환경이 같아서 복잡하지 않다.
  • 배포가 간단하다.
  • 확장성이 쉽다.
    • 로드밸런스를 이용하여 로드 부하를 나눠 가지는 방식으로 진행한다.
  • 쉽게 고가용성 서버 환경을 만들 수 있다.
  • End-to-End 테스트가 용이하다.

 

단점
  • 프로젝트의 규모가 커짐에 따라 애플리케이션 구동 시간이 늘어나고 빌드 및 배포 시간이 길어진다.
  • 조그마한 수정 사항이 있어도 전체를 다시 빌드하고 배포해야 한다.
  • 많은 양의 코드가 몰려 있어서 개발자가 모든 코드를 이해하기 힘들며, 유지 보수가 어렵다.
  • 일부분의 오류가 전체에 영향을 미친다. (장애가 전파된다.)
  • 기술 스택이 한 번 정해지면 바꾸기 어렵다.
  • 전체 애플리케이션 확장은 쉽지만, 부하 분산을 위해 각 컴포넌트를 독립적으로 확장하기 어렵다.

 

 

MSA 마이크로서비스 아키텍처 (Microservice Architecture)

 

MSA 아키텍처는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 형태를 말한다. 작은 레고 블록(microservice) 하나 하나를 붙여 어떠한 큰 결과물을 만드는 레고 놀이를 생각하면 이해하기 쉽다.

 

마이크로 서비스의 특징
  • 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 모놀리식 아키텍처와 유사한 구조를 갖는다.
  • 각각의 서비스는 독립적으로 배포가 가능해야 한다.
  • 각각의 서비스는 다른 서비스에 대한 의존성이 작아야 한다.
  • 각 서비스는 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 함.

 

마틴 파울러의 MSA에 대하여 아래와 같이 정리를 하였는데, 

"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."

위 문장에서 small services, each running in its own process(스스로 돌아갈 수 있는 작은 서비스) 와 independently deployable(독립적 배포 가능) 2가지 특징이 마이크로 서비스를 잘 정의한다. 정리하자면, 마이크로 서비스는 스스로 돌아갈 수 있으며 독립적으로 배포가 가능한 서비스라 할 수 있다.

 

 

이러한 마이크로서비스 아키텍처의 장단점은 아래와 같다.

장점
  • 배포 관점
    • 서비스 별 개별 배포가 가능하다. (배포 시 전체 서비스의 중단이 없음.)
    • 독립 배포가 가능하므로 개발자의 자율성이 증가한다. (내가 A 기능 다 만들었고, 다른 사람이 B 기능 못 만들었으면, 나는 그냥 놀아도 됨.)
    • 요구 사항을 신속하게 반영하여 빠르게 배포할 수 있다.
  • 확장 관점
    • 특정 서비스에 대한 확장성이 용이하다.
    • 클라우드 사용에 적합하다.
  • 장애 관점
    • 장애가 전체 서비스로 확장될 가능성이 적다.
    • 부분적 장애에 대한 격리가 수월하다.
  • 코드 / 유지 보수 관점
    • 팀 별로 프로젝트가 분리되어 있으므로 코드의 이해도가 증가하고, 그에 따라 유지 보수하기 쉽다.
  • 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발 및 운영할 수 있다.
    • polyglot 개발: 여러 프로그래밍 언어, 패러다임 등을 사용
단점
  • 성능 관점
    • 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간이 증가한다.
  • 데이터 관리 관점
    • 데이터가 여러 서비스에 걸쳐서 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어렵다.
  • 테스트 / 트랜잭션 관점
    • 단위 테스트는 쉽지만, 통합 테스트 및 End-to-End 테스트 단위로 들어가면 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
    • 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기 까다롭다.
  • 아키텍처가 다소 복잡하므로 개발 및 관리가 어렵고, 비용이 많이 든다.

 

MSA 정리

모놀리식 아키텍처란?

모놀리식 아키텍처는 마이크로서비스(MSA) 아키텍처에 반대되는 개념으로, 애플리케이션의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태를 말한다.

 

 

마이크로 서비스가 무엇인가?

 

마이크로 서비스는 스스로 돌아갈 수 있으며 독립적으로 배포가 가능한 서비스를 의미한다.

 

 

언제 모놀리식 아키텍처를 사용하고, 언제 MSA 아키텍처를 사용해야 하는가?

 

초기 시작은 프로젝트의 규모가 작은 경우가 많으므로 모놀리식 아키텍처로 사용하다가 다음 관점들을 비교하여 이득이 된다면 MSA 아키텍처로 전환하는 것이 좋다.
  • 비용: MSA 아키텍처를 도입할 경우, 모놀리식 아키텍처에 비해 비용을 얼마나 절감할 수 있는가?
  • 개발 생산성: 마이크로 서비스를 요구할 만큼 시스템 복잡도가 높은가? 또는 복잡도를 지나치게 높인 마이크로 서비스가 생산성을 저해하고 있진 않은가?
  • 운영: 개발 팀에게 개발과 운영을 동시에 할 만큼 인프라가 준비되어 있는가? 또는 개발 인력이 마이크로 서비스를 관리할 역량이 있는가?
  • 배포: 배포를 충분히 자주 하고 있는가? MSA는 빠른 변화에 대응하기 위해 도입하는 것인데, 회사마다 배포 일이 정해져 있고, 배포가 가끔 일어난다면 효율이 떨어진다.

 

 

 

 

참조 및 출처
  • https://steady-coding.tistory.com/595
  • http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/

+ Recent posts

티스토리툴바