오늘은 MSA에 대해서 알아보자.
MSA를 더욱 확실하게 이해하기 위해서는 MSA가 도입되기 전의 모습인 Monolithic에 대해서 이해해야 한다.
다음 그림을 보자.
Monolithic은 우리가 처음 프로그래밍을 공부하면서 만드는 어플리케이션과 비슷하다고 생각하면 된다.
그래서 Monolithic은 아주 작은 서비스를 구축할 때 주로 이용된다.
MSA는 MicroService Architecture의 약자이다.
다시 쉽게 풀어서 이야기 해보자면, 어플리케이션의 각 기능들을 모듈로 나누어 작은 어플리케이션 조합으로 만드는 것이다.
웹에서 예를 들어 보자! (하나의 예시입니다. 틀릴 수도 있어요!)
네이버 웹 사이트 접속(네이버 메인 서버에 요청) - 네이버 메인은 사용자 트래픽이 매우 많아서 메인만 따로 모듈을 두는 것으로 알고 있다.
네이버 뉴스로 이동 - 메인 모듈이 뉴스 모듈로 GET 요청 후 응답 값 반환
로그인 - 뉴스 모듈이 로그인 모듈로 요청
댓글 작성 - 뉴스 모듈이 댓글 모듈로 요청
이렇게 각각의 다른 모듈로 통신을 한다.
대표적으로 http 통신을 한다. Rest 방식으로 아주 간단한 방법으로 통신한다.
다른 서버에 배포가 되기 때문에, API Gateway를 앞단에 세워서 End-Point를 묶어준다!
(End Point란 api를 통해서 최종 요청을 하는 URI이다.)
MSA를 이용하면서 Load Balance가 많이 언급된다.
Load Balance는 트래픽의 부하 분산 처리를 위해서 존재하는 것이다. 위의 예시를 가지고 오면, "네이버 메인 모듈"에 대한 트래픽 관리에 사용된다.
트래픽이 증가하면 Load Balance는 예비로 구비해둔 메인 모듈 서버를 Scale-out하게 된다. 또한 트래픽이 줄어들게 되면, 사용되던 예비 서버는 종료하고 상시로 사용되는 서버로 트래픽을 처리하게 된다.
(aws에서 Elastic Load Balance를 제공한다.)
MSA를 이용하면 장점이 아주 많다.
그 외 아주 많은 장점이 있다!
MSA는 각각의 기능을 분리하는 만큼 운영 관리 및 기능간 통신에서 생기는 문제가 많다.
그 외 단점이 있다!
msa에 대해서 공부를 수행했다. 다음 시간에는 Netfilx에서 제공된 MSA 오픈소스에 대해서 공부를 해보자!