마이크로서비스(MSA) 네트워킹

모노리스 : 

 마이크로서비스 아키텍처 이전 아키텍처를 모노리스라고 한다. 

 기존엔 WAR파일 하나로 묶여, 배포 되었다. (WAR 파일 1개 내부에 모든 기능을 다 담는다)

(또한 DB는 1개의 통합 스키마로 구성) - 이러한 DB를 INTERGRATION DB라고 한다.

이러한 모노리스 구성은, 기능의 변경과 수정 등 과정이 번거롭다. 

 

마이크로서비스 : 

독립적인 요소들의 원할때 상호작용(각자가 독립적으로 존재함이 포인트이다)

주로 UML로 DIAGRAM을 표현하는 것이 좋다. 

1개의 마이크로서비스는 독립적인 CONTAINER에 배포될 것이다.  

교류를 진행하기 때문에 INTERFACE와 , 둘을 지나는 메세지 등이 있다.

이 통신 구조상, REST를 주로 사용한다. 

 

(Netflix가 MSA구조의 예시가 된다) 

해당 분할의 기준은 , 주로 1개의 비지니스 기능(단일 책임의 원칙에 따라)만을 담당한다. 

 

EX) EAMIL 리스트 작성 -> 해당 정보 판단후 DB에 저장 -> 해당 사용자 판단 -> EMAIL들에게 MAIL 전송

이럴땐 구조를 어떻게 해야할까?

EAMIL LIST용  MS, EAMIL전송용 MS를 구현한다. 그리고 둘 간의 통신을 가능하게끔 한다. 

또한, INTERFACE를 최소화 하는 형태로 구현하는 것이 좋다. 

 

<그러면, MSA에서 DB는 어떻게 할 것 인가>

 

핵심은, 통합 DB를 사용하지 않는다는 것이다. 

한마이크로서비스는 , 한개의 db만을 확인한다.

실무에서 이미 존재하는 DB를 변경하거나 삭제할 수 없다면, MSA구조로 설계는 불가능함을 인지하자. 

 

장점)

1 . MYSQL , MONGODB와 같은 비지니스별 다른 DB를 사용할 수 있다.  

 

EX)

user 마이크로서비스 (원칙 db(id,pw)) -> 주소를 활용하는 서비스 (주소 db에 , address만을 포함)

그 이후 user와 주소 서비스간 통신을 통해 원하는 사용자의 주소에 메일을 보내게 끔 해야한다.

 

<배포 실습 : QUEUE 배포>

EX)현재 배송중인 차량 위치 추적

 

web browser -> (rest를 주로 활용해서) -> Reverse Proxy -> API GATEWAY 

(프론트 단의 rest call을받아, 객체 혹은 restcall로 다시 마이크로 서비스에 전송한다)

->위치 찾기 MICROSERVICE(위도와 경도를 읽는다) -> (이제 읽은 DATA를 보내야지)

->큐 (microservice들의 data를 저장한다) <---> 읽어온 data로 계산하는 microservice

 

서비스단, 밑에 queue만 보면 되는데
30010 - 8161은 http와의 통신만을 위해서, 61616은 메세지의 cluster 내부 전송을 위해서 만들었다.

 

POD를 생성하였다. 대부분의 내용은 동일하다.

 

 

<배포 실습: 마이크로소프트 >

 

실질적인 밖에 보이는 역할은 없이, 내용을 받아서 QUEUE에게 전달하면 되기 때문에 노출될 필요가 없다. 

 

즉, service단이 필요 없다는 의미이다. 

 

kubectl logs -f 이후 pod이름을 작성하면, application layer의 로그도 볼 수 있다.

 

queue에 message가 전송됨이 확인. 

 

 

*추가 팁. IMG를 받아올때 PROPERTIES를 변경하는 방법

 

개발한 사람과의 연락이 필요하다. 

 

<pod 로그 검사>

kubectl logs queue-5cc8db6498-fb8zt 해당 명령어로 pod의 로그를 확인할 수 있다.

 

혹은 kubectl logs -f queue-5cc8db6498-fb8zt를 사용할 수도 있다. 

 

<QUEUE를 읽고, MESSAGE를 GATEWAY에 전송하는 마이크로 서비스가 필요하다>

 

8080 PORT가 REST INTERFACE를 호출한다.

POD는 쉽게 생성했다. 

 

Service는 cluster내부에서만 확인되는 8080 IP를 사용할 것이므로 

ClusterIp를 사용했다. 

 

 

Queue를 확인하고, 해당 결과를 return했다. (clusterip가 아닌 node로 변경했을때)

 

(포트 포워딩을 사용하지 않고 queue는 외부에서 30010 -> 8161로
내부에서는 container와 교류하는 port 넘버를 고민해봐야한다. 

 

<api gateway> 

내부에서 8080 포트로 사용하겠다. 

 

SERVICE는 , 크게 달라지지 않는다.

 

* 주의해야할것은, name을 serivce단에서 모든 네트워크와 연결해 검색하기 때문에 생성시 주의해야한다. 

 

<WEBAPP>

 

웹과의 상호작용을 위한 POD

 

이와 같이 전체적으로 동작한다

webapp - api gateway - (ms1(외부와 동작) - queue - ms2(내부적으로만 , 포트노출x))의 구조를 이해하자. 

 

webapp으로 접근, apigateway로 전송 , 그떄그때 이동 정보를 받아 queue에 전송하고 이를 다시 front(webapp을 통해)에 보내는 형태가 완성되었다.