[MSA] 1. 모놀리틱 아키텍처와 마이크로서비스 아키텍처

모놀리틱 아키텍처(Monolithic Architecture)

만약 개발자들이 만든 웹앱을 각 Local에서 개발 후 서버에 배포한다고 해보자.

최초 배포)

-> 최초 상용 배포 시 (Tomcat 1대, DB 1대)
-> SCP를 통해 Clean 배포 (stop -> delivery -> start)
-> DNS(12st.com) -> Tomcat
-> 이 경우 무중단 배포가 불가능하다.
-> 그래서 Load Balancer를 도입한다.

Solution1) Load Balancer를 사용했을 때

-> 1번 Tomcat 내리고 -> 배포 -> 1번 재시작
-> 2번 Tomcat 내리고 -> 배포 -> 2번 재시작

그런데 여기서 서비스가 흥행해서 서버를 증설했다. 그래서 LoadBalancer 설정을 변경하고 배포 방식을 변경했다.
-> Jenkins 도입, Ansible 등

이제 회사가 커지고 부서가 늘어났다고 해보자. 부서는 상품팀, 주문팀 등 특정 기능으로 세분화되었다. 그런데 아직 이 회사는 단일 Repository로 소스를 관리 중이다. 이 경우 나타날 수 있는 이슈는

• issue1 : Branch merge conflict
• issue2 : QA
• issue3 : 각자 다른 일정
• ..
• ...
• ....

결국 이 회사는 여러가지 문제로 두 가지 서버군을 쓰기로 결정했다.

Soltuion2) 두 가지 서버군

-> 각 부서는 도메인을 나눠 정해진 도메인으로만 요청할 수 있게한다.
-> 이 경우, 주문 시 상품 정보를 바꿀 수가 없음 (재고라든가..)
-> 그래서 공통의 소스 Repository를 두어 접근할 수 있게할 것이다.
-> 그러면 각 팀끼리 서로 필요한 기능이 생기면 공통 Repository 소스에 그 기능을 추가해 공통 Repo의 어떤 메소드를 호출하시면 됩니다~ 라고만 전달하면 된다.
-> 근데 이렇게 하면 대부분의 개발이 Share Repo에서만 이루어지기 때문에 활용성이 부족하다.

모놀리식 아키텍처의 장점

• 개발이 간단하다
  -> IDE 등 개발 툴은 단일 앺플리케이션 구축에 초점이 맞추어져 있다.
• 애플리케이션을 쉽게 변경할 수 있다
  -> 코드, DB 스키마를 변경해 빌드/배포하기 용이하다.
• 테스트하기 쉽다
  -> 개발자가 애플리케이션을 띄우고, REST API를 호출하고, 셀레늄으로 UI를 시험하는 종단 간 테스트를 작성한다.
• 배포하기 쉽다
  -> 개발자는 서버에 접속하여 톰캣 설치 경로에 WAR 파일을 복사하면 그만이다.
• 확장하기 쉽다
  -> 부하 분산기 뒷면에 애플리케이션 인스턴스를 여러 개 실행한다.

모놀리식 아키텍처의 단점

• 무겁다
  -> IDE가 소스를 못 받쳐줌
• 기술 스택 변경이 어렵다
  -> 최신 기술을 위해 새로운 app을 재작성 하는 것은 비용과 리스크가 높기 때문에 초기에 결정된 기술을 계속 쓸 수 밖에 없다.
• 높은 결합도
• 코드 베이스의 책임 한계와 소유권 불투명
• DB 성능의 한계
• 확실하게 전달하기 어렵다
  -> 신뢰성이 부족하다. 애플리케이션 자체가 덩치가 커서 철저하게 테스트하기 어렵고, 테스트성이 부족하면 결국 버그가 발생할 가능성도 높다. 그러면 메모리 누수가 발생할 가능성도 높아 전체 애플리케이션 인스턴스가 내려가는 경우도 발생할 수 있다
• 모듈 확장이 어렵다
  -> 예를들어, 데이터 용량이 큰 음식점 데이터는 인-메모리 DB 형태로 저장하는데, 이런 DB는 메모리 칩이 많이 장착된 서버에 배포하는 것이 좋지만, 이미지 처리 모듈은 CPU를 집중 소모하므로 CPU 코어 수가 많은 서버에 배포하는 것이 좋다. 같은 애플리케이션이라도 리소스 요건이 상이한 모듈이 존재하므로 서버 구성 시 리소스 배포를 신경써야 한다.

마이크로서비스 아키텍처(MicroService Architecture)

시스템을 여러 개의 독립된 서비스로 나눠서 이 서비스를 조합함으로서 기능을 제공하는 아키텍처 디자인 패턴이다.

확장큐브로 보는 마이크로서비스

(확장의 기술)에 나온 확장큐브의 개념으로 마이크로 서비스를 살펴보자. 확장큐브는 애플리케이션을 확장하는 세 가지 방법을 정의한다.
첫째, X축 확장은 동일한 다중 인스턴스에 들어온 요청을 부하분산
둘째, Z축 확장은 요청의 속성에 따라 요청을 라우팅한다
셋째, Y축 확장은 애플리케이션을 기능에 따라 서비스로 분해한다.

X축 확장 : 다중 인스턴스에 고루 요청 분산
X축 확장은 일반적인 모놀리식 애플리케이션의 확장 수단이다. 부하분산기(Load Balancer) 뒷면에 애플리케이션 인스턴스를 N개 띄워놓고 부하 분산기는 들어온 요청을 이들 인스턴스에 고루 분배한다. ]
애플리케이션 능력과 가용성을 개선하기 위해 사용한다.

Z축 확장 : 요청 속성별 라우팅
모놀리식 애플리케이션의 다중 인스턴스를 실행하는 것은 X축 확장과 같지만, 인스턴스별로 주어진 데이터 하위 집합만 처리하도록 하는 방법이다. 라우터는 요청의 속성에 알맞은 인스턴스로 요청을 라우팅한다.
각 애플리케이션 인스턴스는 자신에게 배정된 사용자 하위집단만 처리한다. 라우터는 요청헤더 Authorization에 포함된 userId를 보고 N개의 동일한 애플리케이션 인스턴스 중 하나를 선택한다.
Z축 확장은 애플리케이션을 확장해서 증가하는 트랜잭션 및 데이터 볼륨을 처리하기 좋은 수단이다.

Y축 확장 : 기능에 따라 애플리케이션을 서비스로 분해
X축/Z축 확장을 하면 애플리케이션 능력과 가용성은 개선되지만, 애플리케이션이 점점 더 복잡해진다. 따라서 여러 서비스로 쪼개기로 한다.
서비스는 주문 관리, 고객 관리 등 지엽적 기능이 구현된 미니 애플리케이션이다. 서비스에 따라 X축/Z축 확장도 가능한다. 예를 들어, 주문 서비스는 여러 서비스 인스턴스를 부하 분산하는 형태로 구성할 수 있다.

특징

• 각 서비스 간에 HTTP 네트워크를 통해 데이터를 주고 받음

• 독립된 배포 단위

• 각 서비스는 쉽게 교체 가능

• 각 서비스는 기능 중심으로 구성

• 각 서비스에 적합한 프로그래밍 언어, DB 환경으로 개발할 수 있음
  -> 마이크로서비스는 서로 느슨하게 결합되어있고 오직 API를 통해서만 통신한다. 근데 이 서비스는들은 각각 자체 DB를 가지고 있다. 때문에 개발 단계에서 다른 서비스 개발자와 일일이 협의하지 않고 개발자 본인이 담당한 서비스 스키마를 변경할 수 있다. 런타임 서비스에서는 완전히 분리되어 있기 때문에 다른 서비스가 DB락을 획득해 내 서비스를 블로킹 하는 일 같은건 일어나지 않을 것이다.

• 서비스는 크기가 작고 상황에 따라 경계를 정하고, 자율적으로 개발되고, 독립적으로 배포되고, 분산되고, 자동화 된 프로세스로 구축되고 배포된다.
  -> 마이크로 서비스 아키텍처는 서비스를 모듈성의 단위로 사용한다. 각 서비스는 다른 서비스가 함부로 규칙을 어기고 침투하지 못하게 API라는 경계선을 갖고 있어 다른 서비스 API를 우회하여 내부 클래스에 마음대로 들어올 수 없다.

• 하나의 서비스를 3~9명의 사람들이 개발할 수 있어야 함

• 아직까진 아이디어 수준에 가깝다

마이크로서비스 아키텍처의 장점

• 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있음
  -> DevOps의 일부인 지속적 전달/배포는 소프트웨어를 빠르게, 자주, 확실하게 전달하는 것이다.
  -> MSA는 세 가지 방법으로 지속적 전달/배포를 실현한다.

1. 테스트성 : 자동화 테스트가 필수적이다. MSA는 상대적으로 크기가 작아 자동화 테스트를 작성하기 쉽고, 더 빨리 실행되며 버그도 적다.
2. 배포성 : 독립적 배포가 가능해 서비스 변경 시 굳이 다른 개발자와 협의할 필요가 없다.
3. 자율성, 느슨한 결합 : 작은 팀이 여럿 결합된 기술 조직을 꾸려갈 수 있음. 팀 별로 하나 이상의 관련 서비스를 개발/배포하는 업무만 담당할 수 있다.

• 서비스 규모가 작아 관리하기 쉽다
• 서비스를 독립적으로 배포/확장할 수 있음
  -> 독립적 확장을 할 수 있고 서비스마다 상이한 리소스 요건에 맞춰 하드웨어에 배포할 수 있다.
• 조직적으로 팀이 자유롭게 움직일 수 있음
• 결함 격리가 잘 된다.
• 새로운 기술을 실험하고 도입하기 쉽다

마이크로서비스 아키텍처의 단점

• 딱 맞는 서비스를 찾기가 쉽지 않다.
  -> MSA에 맞게 여러 서비스로 분해하는 정립된 알고리즘은 따로 없다. 그래서 잘못 분해할 경우 단점만 있는 분산 모놀리식을 구현하게 될 수도 있다. 이는 함께 배포해야하는 결합도가 높은 서비스들로 이루어진 시스템이 탄생하게 될 것이다.
• 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어렵다.
  -> 서비스 간 통신에 필수적인 IPC 단순 메서드 호출보다 복잡하며, 사용불능 또는 지연시간이 긴 원격 서비스, 부분 실패한 서비스를 처리할 수 있도록 설계해야한다.
  이런 여러 서비스를 상대로 유스케이스(use case)를 구현하려면 익숙지 않은 기술도 동원해야한다. 특히 서비스마다 DB가 따로 있어 다중 DB에 접속하여 조회하고 트랜잭션을 구현하는 일이 어렵다. 그래서 MSA는 사가라는 기술로 서비스 간 데이터 일관성을 유지한다. 또, 단순 쿼리로 여러 서비스에 있는 데이터를 조회할 수 없으므로 AP를 조합하거나 CQRS 뷰로 쿼리한다.
  MSA는 여러 인스턴스가 떠 있으니 운영 복잡도 역시 증가한다. 때문에 성공적 배포를 위해서는 다음과 같은 기술을 응용하여 플랫폼을 고도로 자동화해야한다.

1. 넷플릭스 스핀네이커(Netflix Spinnaker) : 자동화 배포 툴
2. 피보탈 클라우드 파운드리(Pivotal Cloud Foundry) 또는 레드햇 오픈시프트(RedHat OpenShift)처럼 바로 쓸 수 있는 PaaS
3. 도커스웜(Docker Swarm), 쿠버네티스(Kubernetes) 등 도커 오케스트레이션 플랫폼

• 여러 서비스에 걸친 기능을 배포할 때 잘 조정해야한다.
• MSA 도입 시점을 정하기 어렵다.
  -> 초기 버전을 개발할 때는 굳이 MSA를 사용해 해결할 이슈가 거의 없다. 오히려 정교한 분산 아키텍처를 사용하면 개발속도가 더딜 수 있고 식속하게 이터레이션(반복)하기도 어렵다.