MSA에 대해 조금씩 알아가보자.
그럼, MSA가 무엇인지부터 봐야할 것 같다.
MSA가 뭘까?
MSA(MicroService Architecture)란, 하나의 큰 애플리케이션을 여러 개의 작은 서비스(MicroService)로 쪼갠 구조를 의미한다. 나눠진 각각의 서비스는 의존성을 갖지 않고, 최대한 독립적으로 실행되도록 해야한다.
그럼, 서비스는 어떤 단위로 나누는거지?
기능, 목적, 스케일을 기준으로 나눌 수 있다.
독립적으로 실행될 수 있는 구조를 갖어야 하기때문에, 배포가 가능한 단위가 된다.
서비스가 각각 독립적으로 실행된다고 했는데, 그래도 내부적으로 다른 서비스가 필요하면 어떡해?
각 서비스끼리 통신을 통해 요청을 주고 받아 이러한 부분을 해결한다.
근데, 어떻게 알고 서비스끼리 통신을 할 수 있을까?
우리가 보통 요청을 보낼 때, 필요한 것을 생각해보자.
네이버야, 나 이거 검색해줘!
라고, 보낸다면 우리는 이거 검색해줘!라는 구체적인 요청과, 네이버와 같이 이러한 요청을 받을 곳이 필요하다.
그렇다면 우리도 여기서 똑같이 요청을 받을 곳 즉 주소와 요청이 무엇인지를 누군가에게 알려줘야한다.
여기서도, 서비스의 주소와 서비스에 요청할 요청사항이 필요하다.
그럼 이를 위해서는, 서비스의 주소를 각 서비스들이 알고 있어야한다.
여기서 한 번 생각해보자.
우리가 검색을 할 때, 구글 주소나 네이버 주소를 알고서 검색을 해야한다면, 각 서비스에 해당하는 실제 서버 주소가 변경되었을 때마다 우리는 이것을 외우고 그곳에 검색 요청을 보내야한다.
하지만 다행스럽게도, 우리는 이렇나 서버의 주소록을 가지고 있는 DNS(Domain Name System)서버가 있다.
덕분에, 우리는 서버 주소가 바뀌든말든 상관없이 편리하게 검색을 할 수 있다.
이처럼 우리도 각 서비스에 대해 주소를 가지고 있는 주소록 역할을 해주는 친구를 세우는 것이다.
이 친구의 이름은 레지스트리(Registry)다.
레지스트리를 이용해 서비스를 찾을텐데,
서비스를 찾는 것을 서비스 디스커버리(Service Discovery)라고 한다.
서비스 디스커버리 방식이 2가지가 존재한다.
1. 주소록 역할을 해주는 레지스트리에게 요청을 보낼 곳인 서비스의 주소를 물어보고, 물어본 서비스 주소에 직접 요청을 보내는 방법
2. 다른 누군가에게 아예 이러한 일을 모두 넘겨줘버리는 방법
1번을 Client-Side Discovery, 2번을 Server-Side Discovery라고 한다.
보통 스케일아웃을 할 규모가 아니라면, Client-Side Discovery 방식을 사용하기 때문에, 참고자료도 많을뿐더러 상대적으로 더 적은 비용을 가지고 개발할 수 있다고 생각한다.
그렇기때문에, 서비스가 직접 서비스에게 요청을 전달하는 Client-Side Discovery 방식을 선호할 것 같고, MSA를 도입한다면 이러한 방식을 적용할 것같다.
