[백엔드 개발자 로드맵 2020] 백엔드 서비스 아키텍처 패턴

모놀리식 아키텍처

- 하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍쳐를 가지는 형태

 

- 장점

 : 개발초기에 단순한 아키텍쳐를 구성할 수 있으며 개발에 용이함

 : 어떤 서비스든지 개발환경에 있어 복잡하지 않음

 : End-to-End 테스트가 용이

 

- 단점

 : 내부요소간 의존성이 강해 기능의 추가와 삭제가 어려움

 : 일부분의 오류가 전체에 영향

 : 조그마한 수정사항이 있어도 전체를 다시 빌드하고 배포해야함

 : 기능별로 적합한 기술, 언어, 프레임워크를 선택하기 어려움

 

 

 

 

 

마이크로서비스

- 하나의 기능 단위로 세분화하여 독립적으로 구축하는 방식

 

- 장점

 : 서비스 단위의 작업할당을 통해 개발자가 해당 부분을 온전히 이해할 수 있음

 : 새로 추가되거나 수정사항이 있을 경우 해당 서비스(기능)만 빠르게 빌드 및 배포 가능

 : 해당 기능에 맞는 기술, 언어등을 선택하여 사용할 수 있음

 : 일부분에 오류가 있어도 빠르게 발견 및 수정이 가능하며 영향이 적음

 

- 단점

 : 서비스가 작은 단위로 분산되어 있어 관리가 힘듬

 : 서비스끼리 서로를 호출하는 방식이기 때문에 개발이 까다로움

 : 통신관련 오류 발생의 위험이 있음

 : 테스트의 불편함

 

 

 

 

 

 

SOA (서비스 지향 아키텍처, Service Oriented Architecture)

- 중복되는 프로세스나 업무들을 하나의 서비스 단위로 개발하여 각 서비스를 호출하는 방식

 

- MSA와의 차이점

 ㆍ서비스의 공유

   : SOA = ESB를 도입하여 서비스를 최대한 공유

   : MSA = 최대한 독립적으로 구성

 

 ㆍ서비스의 상대적인 크기

   : SOA = 비즈니스 전체를 하나로 작성

   : MSA = 정보관리, 계약관리 등 작은 서비스 하나로 상세하게 나눠서 작성

 

 ㆍ서비스의 오너십

   : 하나의 작은팀에서 관리

 

 ㆍ기술구조

   : SOA = ESB라는 공통된 채널을 통해 서비스 제공

   : MSA = 개별적 API로 서비스 제공

 

※ ESB (Enterpris Service Bus)

 : 서비스들을 컴포넌트화된 논리적 집합으로 묶는 핵심 미들웨어

 

 

 

 

 

http://auconsil.blogspot.com/2013/08/cqrs-command-query-responsibility.html <다중구조>

 

CQRS (명령과 조회의 책임 분리, Command and Query Responsibility Segregation)

- 시스템에서 명령을 처리하는 부분과 조회를 처리하는 부분을 분리하는 형태의 아키텍쳐

 : 명령 (시스템의 상태를 변경하는 작업)

 : 조회 (시스템의 상태를 반환하는 작업)

 : 이벤트 소싱과 함께 사용

 => 시스템의 상태를 변경하는 작업과 시스템의 상태를 반환하는 작업의 책임을 분리

 

- 장점

 : 각각의 도메인 목적에 맞게 집중하여 개발할 수 있음

 : 명령과 쿼리 파이프라인을 원하는대로 최적화 하면서 다른 요소가 깨질 위험을 줄일수 있음

 

- 단점

 : 구현해야할 코드가 많아짐

 : 더 많은 구현 기술이 필요해짐

 : 유지비용의 증가

 

 

※ 이벤트 소싱

- 순차적으로 발생하는 이벤트를 저장하는 데이터 저장방법

 : 최종 결과값만 저장하는 기존의 저장방법과 달리 발생하는 이벤트 자체를 저장

 : UPDATE와 DELETE의 개념이 없음

 : 현재시점의 최종 값을 알기 위해 스냅샷도 함께 활용

=> CQRS에서 조회를 처리하는 부분을 위한 데이터 저장에서 활용

 

 

 

 

서버리스 (Serverless)

- 개발자가 서버를 관리할 필요없이 애플리케이션을 빌드하고 실행하도록 하는 클라우드 네이티브 개발 모델

 : 애플리케이션 구현에 필요한 기능의 함수를 호출하여 따로 서버를 두지 않고 기능을 사용하는 방식

 : BaaS (Backend as a Service)와 FaaS (Function as a Service)로 나뉨

 : 기능을 사용(호출) 할때만 실행되며 작업을 마치면 종료되는 방식

 

- 관련 서비스

 : Firebase (BaaS)

 : Kinvey (BaaS)

 : AWS Lambda (FaaS)

 : Azure Functions (FaaS)

 : Google Cloud Functions (FaaS)

 

 

 

 

 

 

 

 

Refference

lion-king.tistory.com/entry/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-vs-%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-MicroService-vs-Monolithic-Architecture-%EA%B0%84%EB%8B%A8-%EC%86%8C%EA%B0%9C-%EB%B0%8F-%EC%A3%BC%EA%B4%80%EC%A0%81-%EC%9D%98%EA%B2%AC

m.blog.naver.com/dktmrorl/221863498991

www.redhat.com/ko/topics/microservices/what-are-microservices

hsboee.medium.com/msa-vs-soa-e933ef582f3b

justhackem.wordpress.com/2016/09/17/what-is-cqrs/

http://auconsil.blogspot.com/2013/08/cqrs-command-query-responsibility.html

www.popit.kr/cqrs-eventsourcing/

coding-start.tistory.com/265

medium.com/@mjspring/%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EC%86%8C%EC%8B%B1-event-sourcing-%EA%B0%9C%EB%85%90-50029f50f78c