[2019.03.13] 마이크로 서비스 아키텍처

강의 주소 : https://www.youtube.com/watch?v=XSwWn1M2XYg&t=437s&app=desktop

---

1. 아키텍처 발전사

전통적인 아키텍처

전통적인 아키텍처 + 이중화 + 로드 밸런싱

전통적인 아키텍처 + 이중화 + 로드 밸런싱에 기능추가

지금이야 서비스가 2개라서 괜찮지만 기능이 계속 늘어나면 서버가 엄청 커짐 

=> 새로운 사람이 들어왔을 때 시스템을 파악하기가 어려워진다. 

=> 후폭풍을 예상할 수가 없으니 코드를 건드리기가 무서워진다. 

=> 최신기술을 함부로 도입할 수 가 없다. 

=> 시스템이 커지니까 통배포가 어렵다 

=> 기능을 때서 분리하는방식으로하자

---

2. 시스템을 확장하는법 (xyz 확장) 

x축 확장 : 장비를 늘린다. 

y축 확장 : 기능 분할

z축 확장 : 같은 성질을 가지는 애들을 분리하는 법 

x축 확장 : 장비를 늘린다. 

전통적인 아키텍쳐에서 이중화 + 로드밸런싱으로 확장하는 방식 

그런데 이제 이런식으로 장비를 늘리는 방법으로는 확장하기 어렵다. 

배포하기가 어렵고 문제가 생겼을 때 영향력을 판별하기 힘들다.

=> 기능과 DB를 분리하자.

y축 확장 : 기능 분할 

z축 확장 : 같은 성질을 가지는 애들을 분리하는 법 (데이터베이스 파티셔닝)

---

3. MSA

MSA 가 나온 배경 

Domain Driven Desgin 

Continuous Delivery 

On-demand virtualization 

Elastic search 

Scalable 

Resilience 

Polygot programming 

Infrastructure Automation 

Agile 

Reusability 

Self-government Team

MSA의 특징

1. 작다

2. API로 다른 서비스와 연계된다.

3. 자율적이다

4. 한 가지 일을 잘하는데 초점을 맞춤

MSA 에서의 자율성

특정 MSA를 만드는데 어떤 형태로 만드는지에 대해서는 개발자 마음대로 만들수 있도록 하자.

-> 나는 이 기술을 사용하고 싶다.

-> OK 너맘대로 만들어라

이게 가능하다.

MSA의 장점

기술적으로 여러가지를 섞어서 쓸 수 있다.

서비스가 쪼개져서 영향력이 적다.

서비스가 쪼개져서 배포가 쉽다.

서비스가 쪼개져서 확장성이 좋다.

조직 할당도 MSA 단위로 할 수있다.

교체가 쉽다. -> 서비스가 별로면 빨리 버릴 수 있다.

MSA 단점

복잡해짐

DB간의 Transaction 관리가 힘들다.

테스트가 힘들다.

배포화 시스템이 자동화가 되있지않으면 어렵다.

여러 서비스를 거치는 경우 개발이 어렵다.

MSA 이전에 비슷했던 SOA

옛날에 SOA라는 방식도 있었다.

그런데 SOA는 큰 대기업이 SOA 방식을 솔루션으로 파는 방식이었다.

SOA 는 SOA, XML 기반으로 통신했다.

MSA 역사

어떤 큰 기업이 주도하는게 아닌 서비스 회사들이 주도해서 개발하다보니 이러한 형태를 띌 수 밖에 없게 됨

현실에서 검증된 기술을 바탕으로 발전

오픈 테크놀로지 기반이라서 

REST, JSON 기반

MSA를 구현하는 팁

API 를 먼저 정의하라. API가 정말 중요하다.

API 를 REST Maturity level 2 이상이 되도록 해라

API 문서를 유지해라 - swagger

ORM 을 활용하라

DB에 의존하지마라

도메인 내부에서 의미있는 값을 외부에 노출하지마라

MSA가 별 설정 없이 바로 기동 가능하게 하라

MSA 에서의 고민과 API Gateway 

클라이언트와 서비스가 여러개 쪼개지면 어떻게 통합할 것인가? 

각 마이크로 서비스들이 추가될 때마다 앞단의 게이트웨이를 계속 구현해줘야한다면? 

1. LB를 마이크로 서비스 별로 추가해줘야함 

2. 인증도 마이크로 서비스 별로 구현해야함 

3. 로깅도 마이크로 서비스 별로 구현해야함

4. …

=> 중복 투자에 효율성 낭비

=> 외부 API 호출에 대해서 방어해야한다.

=> API Gateway를 사용하자

=> API Gateway가 외부의 호출을 방어, 인증, 권한 여부를 판단해서 서비스에 넘겨준다.

=> API Gateway에 너무 의존적인거 아니냐.

=> API Gateway도 xyz 확장하면 된다.

비효율적인 구조

API Gateway를 도입

API Gateway를 LB와 함께 확장

서비스간의 통신 방법

1. 동기 방식 : A 서비스가 B 서비스를 바로 호출하는 방식

2. 비동기 방식 : A 서비스가 Message Broker에 이벤트를 넣고 서비스 B가 가져다 쓰는 방식 (publish and subscribe)

각 마이크로 서비스 앞에 하드웨어 LB를 둔다고 치면 서비스별로 세팅이 복잡해진다.

=> HA proxy를 아예 호출하는 클라이언트 쪽에두자

=> HA proxy는 Service registry을 통해 호출을 원하는 서비스에 라우팅해준다.

=> 클라이언트 쪽에서는 서비스의 IP 정보를 담아두고 있을 필요가 없게된다.

* ) Service registry 에는 각 서비스의 IP 정보를 담고있는다.

MSA 의 현실적인 고민들

Local 에서 개발해야하는데 그 많은 서버를 어떻게 다 local 에서 띄우냐

=> 인프라적 지원이 필요하다.

초기 개발시간이 너무 오래걸림 개발 세팅이 오래걸린다.

=> 옛날에는 그냥 pull 받아서 서버를 통으로 뛰우면 되는데 라는 저항.

인프라적 요소가 없으면 원활하지 못함

서비스가 연계할 때는 협의가 너무 필요함

---

4. 전통 아키텍처와 MSA 비교

기존의 구조 전통 아키텍처 구조

MSA의 구조