[마이크로서비스패턴] 1. 모놀리식 지옥에서 벗어나라.

1장은 전체적인 이해를 위해 꼭 읽고 넘어가야 한다.

---

모놀리식 아키텍쳐의 장점

1. 개발이 간단하다.
2. 애플리케이션을 쉽게 변경할 수 있다.
3. 테스트하기 쉽다.
4. 배포 및 확장이 쉽다.

모놀리식 아키텍쳐의 한계

규모 있는 애플리케이션은 모놀리식 아키텍쳐가 더이상 맞지 않게된다. 스프린트를 추가할때 구현할 스토리가 늘어났고 코드베이스와 관리 오버헤드가 늘어났다. 팀별로 분화된 스프린트도 불가능해졌다.

사이즈가 늘어나 너무나도 복잡해 이해하기 힘들고 변경도 오래 걸린다. IDE 실행 속도도 느리고 빌드 시간 또한 늘어난다.

아마존은 성공적으로 마이크로 서비스 아키텍쳐를 구축했기에 11.6 초마다 변경점을 배포할 수 있다.

 

확장 큐브와 마이크로 서비스

확장 큐브는 3가지 축으로 모델을 확장할 수 있다.

X축 확장: 다중 인스턴스에 요청 분산 - 흔히 말하는 스케일 아웃

Z축 확장: userId 같은 식별자에 따라 다른 분산 요청을 수행한다.

Y축 확장: 기능에 따라 분해 

 

배달의 민족을 예로 들면 주문, 고객, 리뷰, 사장님 서비스가 전부 분해된 것으로 생각하면 된다.

 

마이크로서비스의 모듈성

모듈성은 크고 복잡한 애플리케이션을 개발할 때 필요한 특성이다. 모듈성을 가지면 다른 서비스가 함부로 침투하지 못하고, API 경계선을 가지고 있어 내부 클래스로 마음대로 들어올 수 없다. 독립적으로 사용해 배포 및 확장에 용이하다.

 

서비스마다 다른 DB

마이크로서비스는 느슨한 결합으로 API를 통해서만 통신한다.

이렇게 되면 개발 단계에서 다른 도메인의 개발자와 협의하지 않고도 담당 스키마를 수정할 수 있다. 런타임 시에도 서비스는 분리되어 있기 때문에 다른 서비스가 DB 락을 획득해 서비스의 블록이 생기는 것도 막을 수 있다.

 

마이크로서비스 아키텍처로의 전환

 

 

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

1. 크고 복잡한 애플리케이션을 지속적 전달/배포할 수 있다. -> 고객 피드백에 신속히 대응할 수 있다. 제품 퀄리티에 더 신경쓸 수 있다.
2. 서비스당 규모가 작아 관리가 용이하다. - 각 서비스마다 다른 리소스 요건에 맞춰 배포할 수 있다. 결함이 있어도 해당 서비스만 수정하면 된다.
3. 독립적 배포 및 확장이 가능하다.
4. 팀당 커뮤니케이션 비용이 감소한다.
5. 새 기술 도입이 쉽다.

 

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

1. 딱 맞는 서비스를 찾기가 어렵다.
2. 분산 시스템이 복잡해 개발,테스트,배포가 어렵다.
3. 여러 서비스를 걸친 기능일땐 커뮤니케이션이 중요하다.
4. 도입 시점을 결정하기 어렵다.

 

마이크로서비스 아키텍처 패턴

마이크로서비스는 충족해야 하는 조건이 많다.

인프라 패턴

개발 영역 밖의 인프라 문제 해결

애플리케이션 인프라 패턴

개발에도 영향을 미치는 인프라 문제를 해결

애플리케이션 패턴

개발자가 마주치는 문제를 해결

 

애플리케이션을 여러 서비스로 분해하는 패턴

1. 비즈니스 능력에 따른 서비스 구성

2. 하위 도메인에 따라 구성

 

통신 패턴(프로세스 간 통신: IPC)

1. 어떤 IPC를 사용하는가?

2. 어떻게 주소를 가져오는가?

3. 신뢰성: 서비스 불능 시 통신의 신뢰성 보장 방법

4. 트랜잭셔널 메시징: DB 트랜잭션에 메시지를 송신하고 이벤트 발행 행위를 어떻게 통합하는가?

5. 외부 API: 클라이언트는  서비스와 어떻게 통신하나?

 

트랜잭션 관리를 위한 데이터 일관성 패턴

 마이크로서비스는 각 DB를 갖고 서로 느슨하게 결합한다. 따로 두면 서비스의 정합성에 문제가 된다. 따라서 사가 패턴에 따라 데이터 일관성을 유지해야 한다.

 

데이터 쿼리 패턴

각각 다른 RDBMS를 구현하면 여러 테이블을 조인해야 하는 문제다. 두 가지 솔루션이 있다.

1. API 조합 패턴 - 여러 서비스를 호출해 결과를 조합

2. CQRS 패턴 - 데이터 복제본을 통해 쿼리하는 방식

 

서비스 배포 패턴

마이크로서비스는 다양한 언어, 프레임워크로 되어 있기에 배포 작업이 훨씬 복잡하고 복잡해 적절한 배포 패턴을 활용해야 한다.

가상 머신, 컨테이너, 서버리스 기술을 활용한 배포가 필요하다.

 

관측성 패턴

마이크로서비스 패턴은 로그 하나론 원인 파악 및 진단이 어렵다.

관측 가능한 서비스 설계를 위한 요구 조건은 6가지가 있다.

1. 헬스 체크 - 서비스 헬스를 반환하는 엔드포인트를 표출한다.
2. 로그 수집 - 서비스 내역을 기록해 검색 기능을 제공
3. 분산 추적 - 외부 요청에 ID를 부여해 서비스를 통과하는 과정을 추적
4. 예외 추적
5. 애플리케이션 지표 - 트래픽이나 여러 지표를 측정
6. 감사 로깅 - 사용자가 한 일을 기록

 

서비스 테스트 자동화 패턴

마이크로서비스 아키텍처는 단위가 작아 테스트하기 쉽지만, 여러 서비스에 걸친 테스트도 중요하다.

다음과 같이 서비스를 분리해 테스트하는 단순 패턴도 중요하다.

 

• 컨슈머 주도 계약 테스트 - 클라이언트의 의도대로 동작하는지 테스트
• 컨슈머 쪽 계약 테스트 -  클라이언트가 서비스와 통신이 가능한지 테스트
• 서비스 컴포넌트 테스트 - 서비스를 따로 테스트

 

횡단 관심사 처리 패턴

횡단 관심사를 처리하는 프레임워크에서 마이크로서비스 섀시 패턴을 적용해 서비스를 구축하는 편이 바람직하다.

 

보안 패턴

API 게이트웨이가 인증한 후 호출 서비스에 관련 정보를 전달한다. JWT를 적용하는 것이다.

 

소프트웨어 평가 지표
1. 배포 빈도
2. 리드 타임
3. 평균 복구 시간
4. 변경분 실패율

 

---