회사에서 개발을 할 때 우리의 개발은 MSA
로 진행이 된다. 입사 초반에는 MSA
가 뭔지, 왜 굳이 이렇게 나눈건지 신경쓸 일 없이 얼른 코드를 짜서 배포하느라 바빴다.
이번에 개발을하고, 서버팀 규모도 커지면서 공통적인 코드가 많아진 느낌이라 오히려 MSA
가 독인 거 같아서 어떻게 하면 코드 관리를 잘 할 수 있을지 혼자서 리서치를 해보기로했다. (잘 정리되면 공유하기,,)
MSA는 MicroService Architecture의 줄임말로, MicroService는 애플리케이션을 느슨하게 결합시킨 서비스의 모임을 구조화하는 서비스 지향 아키텍쳐 (SOA) 스타일 중 하나인 개발 기법이다.
SOA는 Service Oriented Architecture의 줄임말로 애플리케이션 구성요소가 통신 프로토콜을 통해서 다른 구성요서에 서비스를 제공하는 아키텍쳐 접근 방식이다.
기존에 Monolithic Architecture를 사용하면서 소프트웨어 모든 구성요소들을 한 프로젝트에 통합시킨 서비스로, 현재 회사들의 소프트웨어가 legacy 또는 필요로 인하여 Monolithic 형태로 구현이 되어 있다.
소규모 프로젝트에서 Monolithic 형태는 간단하고, 유지보수가 편하지만 소규모 프로젝트에서 점점 규모가 커지게 되면 Monolithic은 오히려 독이 될 수 있다.
위 토글에 적힌 것과 마찬가지로 Monolithic Architecture의 한계점으로 MSA가 나오게 됐다.
MSA는 API
를 통해서 상호작용을 한다. EndPoint API 형태로 외부에 노출하며, 실질적인 세부 사항은 모두 추상화를 한다.
내부 구현 로직, 아키텍쳐와 프로그래밍 언어, DB, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해서 철저히 가려진다.
제대로 설계된 마이크로 서비스는 어플리케이션 출시처럼 하나의 목표를 가지고 움직이지만, 자기가 개발하는 서비스만 책임을 진다. 또한 여러 애플리케이션에서 재사용이 가능해야한다.
애플리케이션은 항상 기술 중립적 프로토콜을 사용해서 통신하기 때문에 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 애플리케이셔을 다양한 언어와 기술로 구축할 수 있는 걸 의미한다.
마이크로 서비스는 SOA처럼 집중화된 관리 체계를 사용하지 않는다. 마이크로 서비스 구현체의 공통적인 특징 중 하나인 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다.
REST
등 가벼운 통신 아키텍쳐, 또는 Kafka
를 이용한 Message Stream을 주로 사용한다.