아마존 넷플릭스과 같은 해외 기업에서부터 배달의 민족, 쿠팡, 페이코와 같은 국내 IT기업까지 많은 기업에서 msa 전환 에 성공했다는 이야기가 들려온다.
왜 많은 기업들이 msa 전환을 하고 있을까?

그리고 본인의 프로젝트인 Dining-together 회식모아 프로젝트에 Monolithic Architectrue대신 Micro Services Architecture 를 선택한 이유가 무엇일까?

이러한 이유를 알기위해 기존의 모놀리식 아키텍쳐와 마이크로 서비스 아키텍쳐의 차이점을 알아보도록 하자.

Monolichic, 모놀리식 아키텍쳐

Monolithic Architecture란 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 형태입니다.
DB, View, Contorller로 구성된 컴포넌트들이 하나의 프로젝트에서 관리되고 하나의 공통된 DB를 바라보고 있다는것이 특징입니다.

장점

과거부터 현재까지 아직까지 많은 서비스들이 모놀리식 구조이기 때문에 다양한 정보가 존재하고 인프라의 구성과 운용이 간편하다.

테스트 코드 작성과 배포 파이프라인 구성이 쉽다 -> 마이크로 서비스를 적용 할때 가장 힘든 부분이였음

문제점

하지만 이러한 장점은 애플리케이션이 간단하거나 규모가 작을 때의 이야기이다. 시간이 지나면서 애플리케이션은 크고 복잡해지고 추가 요구사항, 새로운 기능들을 구현하면서 코드 양은 점점 늘어가면서 문제점이 드러난다.

• 서비스/프로젝트가 커지면 커질수록, 영향도 파악 및 전체 시스템 구조의 파악에 어려움
• 빌드 시간 및 테스트시간, 그리고 배포시간이 기하급수적으로 늘어남
• 서비스를 부분적으로 scale-out하기 어려움
• 부분의 장애가 전체 서비스의 장애로 이어질 수 있음

• 모놀리식 아키텍쳐의 문제점을 해결하기 위해 msa 도입

Micro, 마이크로 서비스 아키텍쳐

전체 서비스를 특정 목적을 가진 서비스 단위로 나누어 변경과 조합이 가능하도록 만든 아키텍쳐이다.
나누어진 서비스는 크기가 작을 뿐 하나의 모놀리식 아키텍쳐와 유사한 구조를 가진다.
각각의 서비스는 다른 서비스에 대한 의존성이 최소화 되어야한다.
REST API와 같은 가벼운 방식으로 통신을 하고 서비스를 독립적으로 배포가 가능하다.

장점

커지면서 생겼던 모놀리식 아키텍쳐의 문제점들을 어느정도 보완 가능

• 배포(deployment) 관점
  * 서비스 별 개별 배포 가능 ( 배포 시 전체 서비스의 중단이 없음)

	요구사항을 신속하게 반영하여 빠르게 배포할 수 있음.
    

• 확장(scaling) 관점
  * 특정 서비스에 대한 확장성이 용이함.

	클라우드 사용에 적합한 아키텍쳐.

• 장애(failure) 관점
  * 장애가 전체 서비스로 확장될 가능성이 적음

	부분적 장애에 대한 격리가 수월함
    
    

단점

모놀리식 아키텍쳐는 단순한 아키텍쳐인데 비해 msa 보다 복잡한 아키텍쳐로, 전체 서비스가 커짐에 따라 그 복잡도가 기하급수적으로 늘어남

• 성능 - 서비스 간 호출 시 API를 사용하기 때문에, 통신비용이나 Latency가 그만큼 늘어남

• 테스트/트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고, 많은 자원을 필요

• 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어려움

---

결론

마이크로 서비스는 대규모 서비스에 알맞는 아키텍처이다. 필자의 프로젝트는 그저 학생들끼리 진행한 소규모 프로젝트이지만 현재 IT 트렌드에 발 맞춰 마이크로 서비스 아키텍처를 적용해 보았다.

참고문서

https://velog.io/@tedigom/MSA-제대로-이해하기-1-MSA의-기본-개념-3sk28yrv0e
https://futurecreator.github.io/2018/09/14/what-is-microservices-architecture/
https://kmseop.tistory.com/163