[데브옵스 개발자 로드맵 2020] MSA (Micro Service Architecture)

Architecture

- 시스템의 목적을 달성하기 위해 시스템 간 상호작용 등의 시스템 디자인에 대한 제약 및 설계

 : 시스템 구성 및 동작원리

 : 시스템 구성요소에 대한 설계 및 구현에 대한 기술

 : 구성 요소 간의 관계 및 외부환경과의 관계 묘사

 : 요구사양 및 시스템 수명주기 고려

 

 

 

 

출처 https://jins-dev.tistory.com/

Monolithic Architecture (모놀리식 아키텍쳐)

- 시스템의 구성요소가 한 프로젝트에 통합되어 있는 형태

 : 부분 장애가 전체 서비스의 장애로 확대

 : 각 컴포넌트가 강한 의존성을 띄고 결합되어 있어 서비스 수정 이후에 대한 영향 파악 난해

 : 시스템의 규모가 커질수록 배포의 어려움 발생

 

※ 컴포넌트 

   : 소프트웨어의 기능을 수행하는 독립된 단위 모듈

 

※ 의존성

   : 시스템 내의 컴포넌트 간 상호연관성

   : 의존성이 강하면 소스코드의 수정이 어려워짐

   : ex) 은행어플의 지문인식 기능은 스마트폰의 지문인식잠금 기능과 연관되어 있어

          스마트폰의 지문인식잠금 기능을 수정하면 은행어플에 영향을 끼침

 

 

 

 

 

출처 https://jins-dev.tistory.com/

MSA (Micro Service Architecture)

- 시스템의 기능을 최대한 작은 단위로 쪼개 의존성을 제거한 형태

 : 컴포넌트끼리 상호간 영향을 미치지 않고 독립적으로 역할을 수행하는 설계

 : 특정 서비스에서 문제 발생시 발견과 수정이 쉬움

 

- Micro Service

 : 한 개 이상의 기능을 하는 작은 애플리케이션

 : 쉽게 교체될 수 있으면서 독립적으로 개발되고 전개될 수 있는 작은 컴포넌트

 

 

 

 

MSA의 장점

- 각 서비스가 모듈화 되있음에 따라 개발과 유지보수가 빠름

  : 장애 발생시 전체에 대한 영향이 적음

 

- 팀 단위 및 필요에 따라 기술 스택을 다르게 사용 가능

 : 기능에 최적화된 기술, 언어를 선택하여 사용 가능

 : ex) A기능을 JavaScript로 작성, B기능은 C++로 작성하여 RPC 등으로 통신하여 기능 수행

 

 

 

MSA의 단점

- 서비스가 작은 단위로 분산되어있어 모니터링이 힘듬

 

- 서비스끼리 호출하면서 서비스가 작동되기 때문에 다른 서비스를 호출하는 코드의 추가가 필요

 : 모놀리식에 비해 개발의 까다로움

 

- 통신관련 오류 빈번

 : 통신 프로토콜의 통일 필요

 

- 테스트의 불편함 

 : 여러개의 Micro Service를 구동시켜야 하기 때문

 

 

 

 

MSA를 통한 개발

- 서비스 구현

 : 한 가지의 기능을 수행하는 API로 개발

 : API는 API서버에 저장

 : API정의서 작성

 

- 통신방식

 : REST

 : RPC

 

 

 

※ REST통신

 - HTTP 1.1 기반

 - POST, GET, PUT, DELETE 상태를 가짐

 - XML 이나 JSON을 전송

 - 구현이 쉬움

 

 

출처 https://nesoy.github.io/articles/2019-07/RPC

※ RPC 통신 (Remote Procedure Call)

 - 클라이언트 측에서 일반메소드 호출처럼 호출

 

 - 서버 측에서도 메소드 다루듯이 구현

 

 - 구조

 : Caller / Callee

  ㆍ클라이언트와 서버에게 필요한 로직을 작성하는 Layer

  ㆍIDL(interface definition Language)로 작성

 : Stub

  ㆍstub compiler가 IDL파일을 읽어 원하는 언어로 stub파일을 생성

  ㆍRPC프로토콜로 전송

 :  RPC RunTime

  ㆍ서버와 클라이언트간 통신을 빌딩하는 Layer

  ㆍ커뮤니케이션 중 발생한 에러 처리도 진행