[MSA] 마이크로서비스 아키텍처

 

마이크로서비스 아키텍처

• 아주 작은 단위로 동작하는 서비스(마이크로서비스)가 구동되도록 시스템, SW 구성과 구성요소 간의 관계를 정의한 아키텍처

 

모놀리스 아키텍처와의 차이점

• 모놀리스
  • 애플리케이션 크기가 클수록 변경, 배포가 쉽지 않은 구조
  • 클라이언트 요청에 대한 처리 반응 속도가 가장 중요한 요소. 애플리케이션에 문제가 생긴하면 시스템이 동작하지 않음 
• 마이크로서비스
  • 하나의 애플리케이션 형태가 아닌 분할된 다수의 서비스
  • 기능뿐만 아니라 데이터까지 분리하여 격리된 독립된 환경으로 구성
  • 서비스의 수평적 확장에 유연하고 탄력성이 높아 성능적 이슈에 대해 유연하게 대처 가능
  • 서비스들을 관리하고 제어하기 위한 에코시스템들의 역할이 중요 (에코시스템: 핵심이 되는 시스템과 상호작용하며 함께 발전해나가는 관련 시스템)
  • 자동화&시각화가 잘 고려되지 않으면 오히려 운영 측면의 risk 증가

 

MAS와 SOA의 차이점

• MAS와 SOA는 모두 소프트웨어 설계 시 서비스 중심의 설계를 지향한다.
• MAS는 한 가지 작은 서비스 집중에 초점. 되도록 서비스를 공유하지 않고 독립되어 실행하는 것을 지향한다. 공유보단, 필요하면 만들고 없으면 폐기하기 쉽게 만들어서 시스템의 탄력성을 높인다. 
• SOA는 많은 서비스 공유를 위해 ESB(Enterprise Service Bus)라는 서비스 채널을 이용하여 서비스를 공유하고 재사용함에 초점

• 서비스 상대적 크기와 관심사
  • MAS에서의 서비스는 작고 한 가지 일에 집중. 하나의 서비스 안에서도 더 세분화하여 작은 서비스들로 쪼개는 것을 지향한다. 하나의 독립된 팀에서 개발하고 관리. 
  • SOA 서비스는 비즈니스에 집중. 서비스는 비즈니스 프로세스의 흐름과 관련된 서비스를 공유하기 위해 중앙 인프라 미들웨어에 탑재하고 필요에 따라 연결 및 조합하여 새로운 서비스를 만듬. 이 과정에서 업무팀, 여러 개발팀들 간의 상호 협업 필수 
• 서비스 공유 정도
  • MAS는 서비스 간의 결합도를 낮추어 변화에 능동적으로 대응하기 위한 민첩성에 초점
  • SOA 재사용을 높여 비용 절감, 품질 상승에 초점
• 기술 방식
  • MAS는 각각의 독립된 서비스가 필요에 따라 노출된 RESTful API 사용. rest api를 보고 호출하여 반환받는 결과값만 활용하므로 구현이 쉽고, 서비스 제공자가 제공하는 서비스 인터페이스에 대한 변경 영향 X. (결합도가 낮기 때문)
  • SOA 공통의 서비스를 ESB라는 공통 채널에 모아 공통 서비스 형식으로 서비스 제공

구분	MSA	SOA
사상	서비스 지향	서비스 지향
서비스 크기	팀 담위 자율성 부여	팀 간의 협업
서비스 공유 정보	서비스 간 독립	서비스 공유
서비스 공유 방식	API	서비스 공유를 위한 미들웨어
서비스 통신 방식	RESTful API 등	SOAP, WSDL, UDDI, ESB 등

 

 

왜 MAS인가?

• 빠르게 변해가는 비즈니스 환경에 능동적으로 대처하기 위해 구현, 반영을 위한 인프라의 유연함이 필요하다.
• 민첩한 서비스를 만들기 위해선 서비스 단위를 아주 잘게 쪼개어 즉시 개발 배포하여 서비스 반응을 볼 수 있는 형태여야한다.
• 유연한 인프라
  • 서비스 개발 배포 운영까지 서비스의 확장이 자유롭고 자동화된 인프라.
• Happy Path
  • Happy Path는 서비스의 기본적인 사상을 실체화하기 위한 최소한의 작업 경로
  • 서비스가 만들어지기까지 여러 단꼐 중 예외상황을 제외한 정상적인 요건과 상황에서 핵심이 되는 최소한의 기능만 개발하여 서비스를 완성
  • 이는 서비스 요건에 대한 이해가 깊어지고, 예상하지 못한 이슈를 도출할 수 있음