MSA란?

MSA란? (MicroService Architecture)

마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 할 수 있다. 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.

MSA와 Monolithic의 비교

MSA의 등장배경

Monolithic 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에 의해 철저하게 가려진다. 

MSA의 장점

• 각각의 서비스는 모듈화가 되어있으며 이러한 모듈까리는 RPC 또는 message-driven API등을 이용하여 통신한다. 이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게할 수 있도록 한다. 
• 팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있다. 회사가 java의 spring 기반이라도 MSA를 적용하면 node.js로 블록체인 개발 모듈을 연동함에 무리가 없다. 
• 마이크로서비스는 서비스별로 독립적 배포가 가능하다. 따라서 지속적인 배포 CD도 모놀로식에 비해서 가볍게 할 수 있다.
• 마이크로서비스는 각각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다. 메모리, CPU적으로 상당부분 이득이 된다.

MSA의 단점

복잡성 증가

• MSA는 여러 개의 서비스로 시스템을 분해하므로, 서비스 간의 통신, 데이터 일관성, 트랜잭션 관리 등 복잡한 문제가 발생할 수 있습니다. 이로 인해 시스템의 전반적인 복잡성이 증가할 수 있습니다.

팀 간 협업 어려움

• MSA에서는 각 서비스를 독립적으로 관리해야 하므로, 팀 간의 협업이 어려워질 수 있습니다. 서비스 간의 인터페이스 및 통신 프로토콜을 정의하고 유지보수하는 것이 복잡할 수 있습니다.

배포 복잡성

• 각 서비스가 독립적으로 배포될 수 있지만, 서비스 간의 종속성을 관리해야 합니다. 따라서 변경 사항을 조율하고 여러 서비스를 함께 배포하는 것이 복잡할 수 있습니다.

분산 시스템 관리

• MSA에서는 여러 개의 서비스를 관리해야 하므로, 서비스 디스커버리, 로깅, 모니터링, 보안 등 다양한 측면에서 추가적인 관리 노력이 필요합니다.

데이터 일관성 유지

• 각 서비스가 자체 데이터베이스를 가지고 있을 수 있으므로, 데이터 일관성을 유지하기 위한 적절한 전략이 필요합니다. 데이터의 일관성을 보장하기 위해서는 서비스 간의 데이터 동기화와 일관된 데이터 모델링이 필요합니다.

성능 문제
-MSA에서는 서비스 간의 네트워크 통신이 증가하므로, 성능 문제가 발생할 수 있습니다. 또한, 각 서비스가 독립적으로 확장될 수 있지만, 전체 시스템의 성능을 최적화하는 것이 어려울 수 있습니다.

최종 프로젝트에서 제대로된 MSA는 아니였지만 경험을 해보면서 느낀점이라고하면 많이 복잡해 팀원들과 소통하고 서비스들의 정상 작동을하고있는지 확인하고 문제가 있다면 파악하는데 시간이 많이 소요되었던거 같다. 또한 각각 분산되어있는 서비스에 통신과 환경변수 공통 라이브러리 같은 설정도 고민해봐야한다. MSA사용방법이나 후기는 다음 포스트에 더 자세하게 다뤄보도록 해야겠다.