MSA 시작
패스트 캠퍼스 파이널 프로젝트의 RFP가 가고자 하는 방향과 달라 개인 프로젝트로 전환..🥲
개인 프로젝트를 어떠한 주제로 할지 고민하던 차에 미니 프로젝트의 결과물을 MSA 환경으로 마이그레이션을 한 후 Kafka를 통해 서비스간 통신을 구현하는 프로젝트 주제를 멘토님께 제안받아 시작되었습니다.
Monolith Architecture란
모놀리스 아키텍처란 MSA의 반대 되는 개념으로 이제껏 우리가 해왔던 방식을 뜻합니다.
여러 도메인(서비스)를 하나의 통합된 소프트웨어 시스템 내에서 관리를 하고 특정 도메인(서비스)를 수정하더라도 전체 시스템을 대상으로 배포를 해야 합니다.
MSA란
Micro Service Architecture 의 약자로 다음과 같이 설명이 가능합니다.
소프트웨어 시스템을 여러 작은 독립적인 도메인(서비스)로 분할하여 개발하고 배포하는 방식
MSA는 각 도메인(서비스)별 소스 코드 수정 및 관리가 쉽고, 독립적이기 때문에 수정한 도메인(서비스)만 배포가 가능하며, 배포 시 전체 서비스 중단이 없다라는 특징을 지니고 있습니다.
또한, 독립적이기에 예기치 못한 장애가 발생하더라도 해당 도메인(서비스)에 국한되고, 전체적인 장애로 확장될 가능성이 매우 낮습니다.
마지막으로 시스템의 규모가 확장되더라도 해당 도메인(서비스)만 추가하면 되기에 스케일 아웃이 용이합니다.
MSA와 Monolithic의 비교.
출처 - https://metanetglobal.com/bbs/board.php?bo_table=tech&wr_id=38
MSA 마이그레이션시 고려해야할 점
모놀리스 아키텍처라면 하나의 시스템에 각 도메인(서비스)들을 모아둔 형태이다 보니 의존성 주입을 하면 사실상 고민할 이유가 없는 내용이지만 MSA는 각 도메인(서비스)가 독립되어 있고 모놀리식 아키텍처와 같이 의존성 주입을 하게 된다면 주입한 의존성의 서비스에 장애가 발생할 시에 다른 서비스 또한 영향을 받게되므로 다음과 같은 사항에 대해 고려를 해야했습니다.
-
외부의 요청에 대한 서비스 라우팅
- MSA에서는 도메인(서비스)별로 독립적인 시스템이 되었기에 외부 요청에 대한 처리가 필요합니다.
- 외부 요청이 발생하면 어느 도메인(서비스)의 요청인지 분기 처리를 해야하기 때문입니다.
Spring Cloud Routing의 GateWay 의존성을 통해 분기 처리 가능.
-
도메인(서비스)간의 통신
- A도메인(서비스)에서 B도메인(서비스)의 정보에 대한 CRUD 처리가 필요할 때 Request의 전달 방법이 필요합니다.
여러 기술 스택이 존재하지만 Kafka의 비동기 이벤트 Pub/Sub을 통해 구현 가능.
