프로젝트-X 두번째 멘토링에서 MSA에 대해 짧은 세미나가 진행될 예정이다.
하여 조금이나마 예습을 해보고 참여를 하려고 한다.
📌 MSA(MicroService Architecture)
MSA는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 형태를 말한다.
✅ MSA의 등장 -> Monolithic Architecture
모놀리식 아키텍처는 마이크로서비스(MSA) 아키텍처에 반대되는 개념으로, 애플리케이션의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태를 말한다. 웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발을 하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포되는 형태를 말한다. 이런 어플리케이션을 모놀리식 어플리케이션이라 하며, 웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태를 말한다. 주로 소규모 프로젝트에서 사용된다.
아직 많은 소프트웨어가 Monolithic 형태로 구현되어 있고, 소규모 프로젝트에는 Monolithic Architecture가 훨씬 합리적입니다. 간단한 Architecture이고, 유지보수가 용이하기 때문이다.
하지만 일정 규모 이상의 서비스, 혹은 수백명의 개발자가 투입되는 프로젝트에서 Monolithic Architecture은 뚜렷한 한계가 있다.
-
부분 장애가 전체 서비스의 장애로 확대될 수 있다.
개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 생겼을 때, 서비스 전체의 장애로 확대될 수 있다. -
부분적인 *Scale-out(여러 server로 나누어 일을 처리하는 방식)이 어렵다.
Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기 때문에 부분 Scale-out이 어렵다.
- 서비스의 변경이 어렵고, 수정 시 장애의 영향도 파악이 힘들다.
여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대한 영향도 파악이 힘들다.
- 배포 시간이 오래 걸린다.
최근 어플리케이션 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세이다. 그러나 규모가 커짐에 따라 작은 변경에도 높은 수준의 테스트 비용이 발생하기도 하며, 많은 사람이 하나의 시스템을 개발하여 배포하기 때문에 영향을 줄 수 밖에 없다.
- 한 Framework와 언어에 종속적이다.
Spring framework를 사용할 경우, blockchain 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이며 강세이다. 그러나 java를 이용하여 해당 모듈을 작성할 수 밖에 없다. 선정했던 framework가 Spring이기 때문이다.
이러한 Monolithic Architecture의 문제점들을 보완하기 위해 MSA가 등장하게 되었다. 기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반의 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있다.
✅ MSA의 특징
MSA는 API를 통해서만 상호작용할 수 있다. 즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. 내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
제대로 설계 된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다. 즉, 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다. 그리고 여러 어플리케이션에서 재사용할 수 있어야 한다.
어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
마이크로서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않는다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka 등을 이용한 message stream을 주로 사용한다.
✅ MSA의 장점
-
배포(deployment) 관점
서비스 별 개별 배포가 가능하다.(배포 시 전체 서비스의 중단이 없음)
요구사항을 신속하게 반영하여 빠르게 배포할 수 있다. -
확장(scaling) 관점
특정 서비스에 대한 확장성이 용이하다.
클라우드 사용에 적합한 아키텍쳐이다. -
장애(failure) 관점
장애가 전체 서비스로 확장될 가능성이 적다.
부분적 장애에 대한 격리가 수월하다. -
이외에도, 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발/운영 할 수 있다.
✅ MSA의 단점
전체 서비스/프로젝트가 커질수록 복잡도가 기하급수적으로 늘어날 수 있다.
- 성능 - 서비스 간 호출 시 API를 사용하기 때문에 통신 비용이나 Latency가 늘어나게 된다.
- 테스트 / 트랜잭션 - 서비스가 분리되어 있기 때문에 테스트와 트랜잭션의 복잡도가 증가하고 많은 자원을 필요하게 된다.
- 데이터 관리 - 데이터가 여러 서비스에 걸쳐 분산되기 때문에 한번에 조회하기 어렵고 데이터의 정합성 또한 관리하기 어렵다.
MSA 공부해야할 부분이 많았다. 좀 더 상세한 내용들은 참고페이지를 보도록하자..!!
프로젝트 X.. 고생하셨습니당 3주간