AWS Microservice 웨비나 후기

마이크로 서비스란 무엇인가?

 

비즈니스 도메인을 중심으로 모델링되어있는 독립적으로 배포 가능한 서비스 단위 이다.

 

각각의 서비스가 서로 느슨하게 연결되어 있어 독립 실행이 가능해야한다.

 

쓰리 티어 아키텍처

(ui team, backend team, dba)

 

현재 동작되는 서비스에 추천 서비스를 넣는다고 했을때, 각각의 팀은 따로 개발한다.

 

쓰리 티어같은 경우는 기술 스택을 기준으로 팀이 나누어졌다면,

비즈니스 도메인을 중심으로 모델링을 하여 아래 구조로 변경할 수 있다.

 

카탈로그, 유저 관리, 추천

 

해당 강의에서는

마이크로 서비스에서의 ci/cd 가 가장 핵심적인 키워드 이다.

 

이렇게 마이크로서비스로 나뉠때 조심해야하는것은 데이터베이스 이다.

 

여러 마이크로서비스는 각 서비스 자신의 데이터를 소유해야한다.

데이터베이스 분리하는 것은 쉽지 않지만, 최대한 피하는 것이 베스트이다.

 

 

마이크로서비스 장점

 

- 기술 믹스 앤 매치 :

단일 모놀리스는 팀이 설정한 기술스택을 따라가게 되어있음.

하지만 마이크로서비스는 각 서비스마다 그 서비스에 가장 적합한 기술스택을 사용가능함.

 

- 독립적인 확장 기능

 

- 하이퍼 포커스 2-pizza 팀 : 아마존 용어

한 팀을 만들때 피자 2판을 나눠 먹을 수 있는 정도의 수 이상을 넘지마라.

팀에 개발자가 많아지면 의사소통이 힘듦.

만들고자하는것에 집중하기에 좋은 구조.

 

- 더 많은 개발자를 병렬로 일을 시킬 수 있음.

 

- 더 간단한 워크플로, 모니터링, 문제 해결 및 e2e 테스트

 

 

 

마이크로 서비스가 야기하는 문제점

 

- 네트워크를 신뢰할 수 없음

- 지연시간이 존재함

- 대역폭은 한계가 있음

- 네트워크는 안전하지않음

- 토폴로지가 계속 변경될 수 있음

- 전송 비용이 비쌈

- 각각의 서비스가 서로 신뢰할 수 없음

 

소유권 문제도 야기할 수 있음.

 

 

 

모놀리스 장점

 

- 간단한 배포

- 간단한 개발자 워크플로우

- 간단한 모니터링과 테스트

 

문제

 

- 높은 결합도

- 혼란스러운 소유권 경계

- 배포 경합

 

 

추천과 주문의 연결을 끊는것은 api 를 만드는 것이다.

이렇게 만들면 결합도를 낮출 수 있다.

 

근데, 만약 주문 데이터가 대량이라면? api 가 버티기 힘들지않을까?

 

이럴때는 추천에만 쓰이는 db를 따로 만들면 된다.

이러면 주문 스키마가 바뀌어도 추천에 쓸 수 있다.

 

<일시적 결합도>

워크로드를 따라서 순간만 결합되어 있다면?

 

창고 -> 주문 -> 고객

 

이 순서대로 간다고 했을 때, 주문이나 고객 서비스가 죽어버린다면?

창고는 하염없이 기다려야할것이다.

 

이걸 끊으려면, 비동기 처리를 해주거나 주문 레이어를 일시적으로 갖고 있는 캐시 레이어를 하나 만드는 방법으로 할 수 있다.

 

 

 

이렇게 있다고 했을 때 1. 주문정보 획득