Microservice Architecture는 무엇일까

정의 : 마이크로 서비스 아키텍처 스타일은 단일 응용 프로그램을 나누어 작은 서비스의 조합으로 구축하는 방법이다.

수평적으로 방대한 서비스를 단위 기능별로 분리하여 구조를 설계한 형태,
일반적으로 마이크로 서비스 간 REST 방식으로 호출한다.

MSA의 장점

1. 빌드와 테스트 시간을 감소시킬 수 있다.

CI / CD 에 적합하게, 짧은 시간 안에 원하는 서비스를 수정 및 배포할 수 있다.

2. 폴리글랏 프로그래밍이 가능해진다

상황에 맞게 기술 스택을 유연하게 적용할 수 있다.
예를 들어 TPS(시간당 트랜잭션)가 높고, 읽기 작업이 많은 서비스에는 Node + Redis로 구현을 하고,
트랜잭션 및 안정성이 중요한 서비스에는 Spring + RDB를 적용할 수 있다.

3. 선택적이고 탄력적인 확장이 가능해 진다

필요한 서비스만을 scale out 할 수 있다.

4. 하나의 서비스에 문제가 생겨도, 다른 서비스에 문제를 발생시키지 않는다.

그러나 문제가 생긴 서비스를 호출 시에 문제가 발생할 수 있는데, 이는 Circuit Breaker로 해결한다.

MSA 구조 채택 시 문제점

1. Performance issue 가 있다

Monololic에서 메서드로 서비스를 호출했다면, MSA는 http 통신을 이용하여 호출을 하게 된다.
따라서 Network IO에 관련한 오버헤드가 발생할 수 있다.

2. 데이터베이스 트랜잭션이 불편하다

Spring에서는 @Transactional이라는 어노테이션으로 트랜잭션 처리가 가능함.
그러나 서비스가 각각으로 나뉘게 되면, global 트랜잭션이 불편할 수 있다.
따라서 MSA에서는 서비스 간에 Global 트랜잭션이 일어나는 상황보다는,
Local 트랜잭션이 주로 이루어지게 경계를 나누고
불가피하게 서비스 간에 트랜잭션이 필요하면 트랜잭션 로직을 추가해야 한다.

이에 대한 해결책으로, 보상 트랜잭션이 많이 쓰인다. 예를들어 상품 재고 감소 API 가 있다면, 상품 증가 API 를 만들어서 해당 트랜잭션 실패시 보상 트랜잭션인 상품 증가 API를 호출하는 것이다. 그러나 이러한 상황은 아예 안 만드는게 좋다.

3. local sites 의 관리가 불편하다

로깅, 모니터링, 배포, 테스트, 클라우드 환경에서의 관리들이 다소 불편할 수 있다.
테스트 / 빌드 / 배포 자동화에는 jenkins,
모니터링에는 springboot admin 등을 사용한다.

서비스간의 상호작용

동기 : REST/JSON 비동기 : MQ