## 주절주절
MSA가 좋다는 말은 많이 들어봤기 때문에, 개념은 알지만 깊게 공부할 생각을 해보지 않았던 것 같다.
그의 사유는 다음과 같다.
- MSA 구조가 필요할 정도의 규모 프로젝트에 참여해본 적이 없었다.
- 현재도 그렇다.
- 적은 비용으로 사이드 프로젝트를 진행하고 싶었다.
- 설계하는 데 시간을 단축하고 싶었다.
그래도 MSA, MSA 남들은 나 하는데 나만 안 할 수 없지....
이번에 좋은 기회 <<이하 회사돈>> 으로 MSA 강의를 듣게 되었다 !!
패스트 캠퍼스에 올라온
!!!!!!!!비즈니스 성공을 위한 Java/Spring 기반 서비스 개발과 MSA 구축!!!!!!!!
오늘 블로그 작성을 하는 이유는 내가 알고있던 MSA 구조의 개념을 정리하기 위함이다.
나는 원래 전형적인 대한민국 사교육을 받으면 자라왔기 때문에 예습과 복습을 철저히 하는 착한 어린이.. 응애
MSA? MA?
MSA는 Monolithic의 문제점을 보완하기 위해 탄생한 아키텍처이다.
그만큼 서로의 장단점이 다르기 때문에 두 가지의 아키텍처에 대해 말해보려고 한다.
MA(Monolithic Architecture)란
전통적인 웹 시스템 개발 스타일으로, 모든 로직이 하나의 어플리케이션 안에 들어가있는 구조이다.
MA의 장점
- 작은 프로젝트나 개발 초기에 단순한 개발에 용이
- 낮은 서비스 복잡도
- 낮은 테스트 복잡도
- MSA에 비교하면 적은 비용 발생
MA의 단점
- 프로젝트 규모에 따른 구동시간 증가 (프로젝트 규모가 커질 수록, 프로젝트 빌드 및 배포 시간 증가)
- 유지보수 비용 증가(다양한 코드가 모여있어 유지보수가 힘듦)
- 기능간 높은 의존도 (일부 오류가 전체 시스템에 영향을 줌)
- 힘든 확장성 (각 기능마다 다른 기술 스택 사용 불가능)
MSA(MicroService Architecture)란
그대로 해석하면 작은 단위의 서비스 설계이다.
말 그대로 작은 단위로 각각의 기능을 수행하는 서비스로 구성된 설계방식이다.
위의 Monolithic Architecture의 단점들을 보완하기 위해 MSA로 많이 변화하는 추세이며 대형 시스템 개발 시 용이하다.
👉🏻 MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
((해당 글 출처 ㅣ https://wooaoe.tistory.com/57))
MSA의 장점
- 독립적 배포 가능
- 유지보수 난이도 저하 (빠른 이슈 대응)
- 높은 확장성 (각 서비스마다 다른 기술 스택 사용 가능)
- 약한 결합도 (각 기능마다의 의존도가 낮아짐 -> 일부 서비스에 장애가 발생하더라도 전체 서비스 영향도 down)
- 빠른 배포 가능 (모든 서비스를 중지하고 다운타임을 가질 필요 없이 해당 기능만 배포함으로써 시간 단축)
MSA의 단점
- 서비스 복잡도 증가
- 테스트 복잡도 증가
- API 호출 간 비용 발생
- 설계정리 문서 중요
