마이크로서비스패턴[1] — 1장
1장 모놀리식 지옥에서 벗어나라
1장 모놀리식 지옥에서 벗어나라
2장 분해 전략
3장 프로세스 간 통신
4장 트랜잭션 관리: 사가
5장 비즈니스 로직 설계
6장 비즈니스 로직 개발: 이벤트 소싱
7장 마이크로서비스 쿼리 구현
8장 외부 API 패턴
9장 마이크로서비스 테스트 1부
10장 마이크로서비스 테스트 2부
11장 프로덕션 레디 서비스 개발
12장 마이크로서비스 배포
13장 마이크로서비스로 리팩터링
1. 모놀리식 아키텍처와 마이크로서비스 아키텍처
1.1.모놀리식 서비스 다시보기
지난 모놀로식 아키텍처를 생각하며 아래 그림을 보자.
앞으로도 계속 예시로 볼 가상의 회사인 FTGO는 위와 같은 구조로 시스템을 사용하고 있다. FTGO가 제공하는 REST API와 UI 어댑터로 어플리케이션은 내부적으로 각종 비즈니스 로직을 처리하고, MySQL 어댑터를 통해 DB에 저장하거나, 사용중인 클라우드서비스를 호출해주는 어댑터를 쓰는 모습을 보여준다.
FTGO의 모듈을 이루는 모듈조직들은 하나의 소스코드저장소에 저장을 하고, 모든 모듈이 통합된 하나의 WAR파일을 실제 어플리케이션으로 구동하여 서비스를 운영한다.
여기서 생각해 볼 수 있는 모놀리식의 단점은 복잡성이다.
모듈과 관련된 코드를 확인하기 위해서는 많은 시간이 걸리고, 새로운 기능을 구현하기에도 기존 코드를 전부 분석하기에는 쉽지 않다.
그리고 개발속도도 느려진다.
대규모 소스를 전부 개발자 각각의 PC에서 구동시켜야 하기 때문에 IDE의 실행속도나, 빌드시간이 오래 걸림으로써 생산성이 떨어지게 된다.
배포 또한 어려워진다.
모듈간의 복잡한 코드들을 전부 통합하여 한번에 릴리즈를 하기에는 소스병합이나 테스트를 하기에는 어려움이 따른다.
이밖에도 하나의 어플리케이션으로 구동하기 때문에 확장성도 떨어지며, 모듈들중 하나의 어플리케이션이라도 문제가 생긴다면 전체 어플리케이션에 영향을 미치게 된다. 또한 하나의 어플리케이션 형태로 배포가 되기 때문에 프로젝트 초기에 결정된 기술을 그대로 따를 수 밖에 없어 버전업이나 기술스택을 변경하는 일이 쉽지 않다.
모놀리식 아키텍처는 이정도면 장단점을 충분히 알아본 것 같다.
그렇다면 이 책의 저자가 생각하는 마이크로서비스 아키텍처란 무엇이길래 바꿔야 하는지도 알아봐야한다.
1.2. 확장큐브
저자가 마이크로서비스 아키텍처에 영감을 받았다는 아래의 확장큐브라는 모델을 보자. 확장큐브의 모델에 따르면 어플리케이션을 X,Y,Z축 세 방향으로 확장시킬 수 있다.
- X축 : 다중 인스턴스로의 확장
X축 확장은 로드밸런서를 통해 요청을 인스턴스들에게 고루 분배하여 어플리케이션들의 가용성을 높일 수 있다는 것이다. - Z축 : 데이터의 파티셔닝
X축 확장에서 인스턴스 단위로 부하를 분산시켰지만, 분산 이전에 라우터를 통해서 지정된 인스턴스별로도 요청을 나눔으로써, 트랜잭션이나 데이터볼륨을 처리하기 위한 확장방안으로 볼 수 있다. - Y축 : 기능에 따른 서비스의 분해
X축과 Z축은 어플리케이션의 가용성을 높였지만 복잡성은 해결시킬 수 없다. Y축확장은 모놀리식 어플리케이션을 여러 서비스로 나누는것을 의미한다.
위 그림에서 확인할 수 있는 것은 Order Service, Customer Service, Review Service 라는 서비스단위로 분리한 Y축의 역할, 그리고 서비스의 요청은 로드밸런서를 통해 X축을 확장시키거나, 필요시 Z축으로 인스턴스의 리소스를 차등적으로 분배하여 시스템을 확장시킬 수 있다는 것이다.
넓은 관점에서 바라보면 마이크로서비스 아키텍처는 하나의 어플리케이션을 여러 서비스로 기능을 분해하는 아키텍처 스타일이다. 여기서 어플리케이션을 나누는 것은 규모가 아닌 서비스 도메인을 기준으로 책임을 가진다는 것이다.
1.3. 마이크로서비스의 특징
최근의 어플리케이션들은 규모가 방대하고 내용이 복잡해서 모듈단위로 분해하여 개발한다. 과거의 모놀리식은 언어구성체(자바 패키지)나 빌드 아티팩트(JAR)를 조합한 단위로 모듈을 정의하지만, 버전이나 디팬던시와 같은 문제가 많아서 점점 지저분해지고 복잡해진다고 한다.
이러한 문제를 MSA는 서비스를 모듈성의 단위로 사용하여, 각 서비스는 다른 서비스에서 직접 접근할 수 없도록 API를 통해서만 접근할 수 있게 한다. 따라서 시간이 지나더라도 각자의 모듈은 독립성을 유지하기 수월하며, 독립적으로 배포/확장할 수 있는 장점도 가지게 된다.
그리고 서비스는 각각 자체 DB를 가지기 때문에 런타임시 DB락과 같은 서비스 블로킹이 발생하지 않는다.
MSA와 같이 구성한다면 아래와 같은 장점이 있다.
- 크고 복잡한 어플리케이션을 지속적으로 전달/배포할 수 있다.
- 서비스 규모가 작아 관리하기 쉽다.
- 서비스를 독립적으로 배포/확장할 수 있다.
- 팀이 자율적으로 움직일 수 있다.
- 결함 격리가 잘 된다.
- 새로운 기술을 도입하기 용이하다.하지만 역시 단점도 존재한다.
적절한 서비스를 찾기 어렵다.
분산시스템은 복잡해서 개발, 테스트, 배포가 어렵다.
여러 서비스에 걸친 기능들을 배포할 때 주의가 필요하다.
MSA의 도입시점을 결정하기 어렵다.1.4. 마이크로서비스 패턴
책에서는 마이크로서비스 패턴과 마이크로서비스 패턴 언어를 말하는데,
이해한 바로는
패턴이란 : 문제 해결을 위한 해법
패턴 언어란 : 패턴들의 집합
을 말하며, 패턴을 적용하였을 때의 결과는 패턴 적용시 발생하는 장점과 단점, 그리고 새로 발생할 이슈에 대해 기술하면서 설계를 해야한다는 것이다.
즉, 마이크로서비스 패턴을 적용할 때에는 패턴 적용시의 장점, 단점, 이슈라는 3가지 관점으로 놓고 보아야 더 나은 설계를 할 수 있다는 것이다.
그리고 이 패턴들의 관계를 나타내는 종류는 5가지가 있다.
선행자(Motivation Pattern) : 패턴이 필요하게 된 원인을 유발한 패턴
후행자(Solution Pattern) : 패턴으로 야기된 이슈를 해결하는 패턴
대안(Solution) : 해당 패턴의 대체 솔루션을 제공하는 패턴. 둘 중 하나를 선택할 수 있음
일반화(General) : 문제를 해결하는 일반적인 패턴
세분화(Specific) : 특정 패턴을 세부적으료 표현✲ 책에 있는 영문과 실제 원본의 내용이 달라서 원본을 기준으로 작성
위 그림은 마이크로서비스 패턴을 모아 놓은 패턴그룹이다.
좌측 상단의 범례를 보면서 파악하는 것이 좋다.
패턴은 3계층으로 분류된다.
- 어플리케이션 패턴(Application Pattern)
- 어플리케이션 인프라 패턴(Application Infrastructure Pattern)
- 인프라 패턴(Infrastructure Pattern)
위에서 나오는 다양한 패턴들은 각 장마다 계속해서 나올 예정이므로, 위 이미지를 보면서 전체적으로 파악하는 것이 좋을 것이다.
