bblog v3 - 구현을 위해 MSA의 개념을 자세히 파악하자

이번 글은 여러 홈페이지에서 제공되는 내용을 많이 참고하였다

 

MSA란 무엇인가

분리된, 독립적인, 느슨하게 결합된, 서비스들을 결합하여 제공하는 아키텍처를 뜻한다 

 

좀 풀어서 말하면.. 예를 드는 게 가장 빠르다 

 

흔히 비교되는 아키텍처가 모놀리스식 아키텍처이다 

 

그리고 MSA를 항상 언급할 때마다 쓰는 짤방이 있는데 이게 가장 쉽게 이해가는 사진 아닐까 

 

쉽게 말하면 서비스들을 하나에 모아 하나의 어플리케이션에 등재시켜 운영하는 게 모놀리스식

 

서비스들을 각각의 어플리케이션에 등재시켜 하나의 서비스처럼 운영하는 게 MSA방식이라 생각하면 될듯하다 

 

이에 따른 이점은 아래와 같다 

 

1. 독립성

모놀리스식에서, 유저의 오류가 발견되면 이 어플리케이션은 하나에 다 들어가 있기 때문에

나머지 게시글, 이메일 관련 서비스들도 다 내릴 수밖에 없다 

 

만약 MSA아키텍처에 따라 클라이언트가 유저, 게시글, 이메일 이렇게 3가지로 나누어져 있다 생각해 보자 

 

각 서비스의 개념이 분산화되어 있으므로 (말 그대로 유저.jar, 게시글.jar, 이메일.jar)

이 중에 하나만 내려서 빠르게 유지보수를 시킬 수 있다는 게 장점이다 

 

2. 최신화

만약 모놀리스식 어플리케이션에서,  예를 들어 스프링 부트를 쓴다 가정해 보자

 

스프링부트 버전이 2.3인데 잘못해서 3.0으로 업데이트되었다 생각하고 이걸 빌드한다 생각해 보자 

자신 있게 확실히 말할 수 있다 최소한 시큐리티 부분에서 무조건 뻑난다 

 

근데 다른 부분에서는 오류가 뜰까??

아니다 아마도 시큐리티 부분 빼고는 거의 다 정상적으로 돌아갈 것이다 

 

만약에 이 시큐리티만 따로 부트 3.0의 시큐리티(6버전)으로 올리고 싶다면..?

이럴 때는 MSA가 매우 유용할 것이다 

 

또한 새로운 기능을 도입하는데 구버전에 없어서 불가피하게 업데이트해야 할 때, 

그런 오류를 고려하지 않고 새로운 버전으로 목표 서비스를 따로 만들어서 적용도 가능해진다 

 

이런 식으로 버전에 대한 유연함도 가지게 된다 

 

3. 생산성

확실히 올라간다

정확히 말하면 협업하는 입장에서는 서비스에 관해 전문적으로 생각하며 몰두할 수 있게 된다

회원이면 회원 게시글이면 게시글 댓글이면 댓글

이런 식으로 집중, 협업이 가능해진다면 그 속도는 엄청나게 늘어날 것이다

 

 

단점은 저 장점들을 그대로 180도 회전시키면 나오는 단점들이다 

 

1. 독립성에 의한 트랜잭션 관리 

생각해 보자,  간단하게 JPA에서 우리는 Transaction을 한 일처리 단위에서 성공성을 보장하기 위해 자주 쓴다

 

MSA는 이와 같은 정보들을 모아서 처리를 해야 하는데 여기서 불변성을 유지하기가 어려워질 수도 있다

이를 막기 위해서 비동기형식의 MQ를 이용하여 한 단위의 서비스를 처리하기도 하지만

어느 때는 동기적 처리가 필요해질 때가 있으며 이런 것은 단점으로 돌아설 수도 있다 

 

2. 유지보수

장점이자 단점이 되는 부분이 이 부분이다

어딘가에서 오류가 났다 하자

모노리스식에서는 그 오류의 추적이 매우 쉽다 그냥 로그 냅다 때리면 나오기 때문이다 

 

하지만 생각해 보자 MSA에서, 게이트웨이에서 서비스단을 타고 들어가 mq, 거기서 서비스를 돌고 나온 값이 오류가 떴다

 

어디서 난 것인지 파악이 바로 가능할까? 소규모의 msa라면 어느 정도 같이 설계한 사람들은 바로 알 수 있을지도 모르겠으나 

 

애초에 많은 서비스, 확장성을 염두해고 만드는 이 서비스에서 이러한 점은 단점이 될 수도 있다 

 

 

3. 설계

 

이건 두말하면 잔소리, 생각해 보자 하나의 어플리케이션에서 모든 걸 설계하다가

서비스단으로 restful 하게 서비스 간의 정보를 모아 앞단으로 던진다 이게 과연 같은 일일까?

 

아니라고 본다 서비스 간의 통신도 어떻게 해야 할지 규격도 잘 정해야할것이고 

또한 서비스 간의 통신에 있어서 하나의 서비스가 바뀌는 경우도 잘 생각해봐야 할 것이고 

여하튼 기타 등등 여러 가지 추가적으로 생각할게 많아진다

 

 

결론적으로 쓰는 게 좋은가?

 

나는 쓰면 정말 좋지 않을까 하면서 작년 12월부터 계속 생각하고 있다

 

물론 언급한 대로 설계에서 매우 힘들고, 처음 쓰는 기술이라 수없는 삽질을 반복하겠지만

 

그것도 또 하나의 재미 아니겠는가 

 

또 이미 있는 유저데이터, 게시글들을 통해서 다른 어플에 똑같은 정보를 적용할 수 있다, 이런 개념 얼마나 멋진가..! 

 

MSA의 구조

마소에서 퍼왔다

그럼 구조는 어떻게 될까 생각해 보자 

 

서비스는 묶여서 api에 제공이 되며 api게이트웨이는 주소를 받아 각 서비스로 신호를 넘긴다

 

또한 서비스들을 묶는 과정에서, 서버들이 무조건 같은 정보만 가진다는 보장은 없기에

 

여기에 서비스 디스커버리라는 개념이 적용된다

 

서비스디스커버리

인터넷을 좀 살펴보니 서버 쪽 디스커버리, 클라이언트 쪽 디스커버리 이런 식으로 나뉘는듯한데

 

개념은 둘 다 같다 서비스의 상태를 종합적으로 파악하고 게이트웨이에 전달하는.. 그런 역할이다

 

간단하게 얘 없으면 MSA의 확장성에서 매우 떨어지지 않을까?

(서버가 다운될 때 다른 서비스로 갈아탄다던가, 서버가 새로운 주소로 바뀐다던가 했을 때의 즉각적 반영 등등.. )

 

스프링 cloud 공시페이지에서는 대표적인 예로는 유레카를 들고 있다 

 

고로 내가 배워야 할 스택 중에 유레카의 정확한 포지션과 사용법만 알면

여태 봐온 MSA개념에 대조하여 대충 넘길 수 있을 듯하다 

 

API게이트웨이

공부하기 전에는 사실 이놈이 핵심 아닐까 하면서 항상 생각했다

얘만 있으면 각 서비스단의 정보들을 유레카에 의뢰해서

깡그리 모아서 가공한 뒤 클라이언트로 보내는.. 그런 개념이 아닌가 했는데 

 

비슷하긴 한데 몇 가지 기능이 더 추가되며 주의점도 많다

조금 더 자세하게 생각할 필요가 있나 보다

보통 인증인가를 여기서 처리하게 되며 로드밸런싱도 여기서 처리한다고 한다 

 

주의점은 조합.. 이 조합이라는 개념이 좀 다르게 적용되야할듯하다 

또한 게이트웨이에서의 요청에따른 보안 범위도 생각해보아야하고

 

여타 생각할게 많아지는듯하다 

 

 

여하튼.. 이 정도만 하면 대충 뼈대는 잡힌듯하다 

 

다음부터는 실전.. 하기 전에 혼자 좀 꼼지락꼼지락 해보고 포스팅을 작성해 보겠다

 

 

https://docs.oracle.com/ko/solutions/learn-architect-microservice/index.html#GUID-1A9ECC2B-F7E6-430F-8EDA-911712467953

Oracle Cloud 기반 마이크로서비스 애플리케이션 설계에 대해 알아보기

https://spring.io/cloud

Spring | Home

https://learn.microsoft.com/ko-kr/azure/architecture/guide/architecture-styles/microservices

마이크로 서비스 아키텍처 스타일 - Azure Architecture Center