모놀리식과 비교하며 알아보는 MSA
모놀리식과 비교하며 알아보는 MSA — #MSA #MSA란 #모놀리식 #모놀리식아키텍처 #개발자의도구들 🚨📝 📖 📒✏️💡🔍 AI스...
#MSA #MSA란 #모놀리식 #모놀리식아키텍처 #개발자의도구들
🚨📝 📖 📒✏️💡🔍
AI스쿨 msa기반 java 백엔드 코스 중에 공부한 내용을 작성하였습니다
\* 현재 Spring 프로젝트를 진행 중입니다. 전체적인 목차를 보시려면 여기를 눌러주세요.
MSA란?
MSA는 Micro Service Architecture의 약어로, 서비스를 최대한 작게 쪼게어 설계하는 아키텍쳐입니다. 이번글에서는 아주 핵심적인 부분만 다루고 넘어가도록 하겠습니다.
목차
- Why?
- How?
Why?
근본적인 질문으로 왜 우리는 MSA를 사용해야 하는지, 사용하면 무엇이 좋은지에 대해 알아보겠습니다.
먼저 MSA가 아닌 아키텍쳐라면, Macro Service Architecture인가? 생각했었는데 공식적으로는 Monolithic Architecture가 있습니다.
모놀리식 아키텍처
Monolithic Architecture
그럼 모놀리식 아키텍쳐를 먼저 생각해봅시다. 이는 전통적인 소프트웨어 개발 모델로, 하나의 코드베이스에 여러 비즈니스 모델이 포함된 아키텍쳐입니다.
이런 설계는 치명적인 단점을 가지게 되는데, 제가 지금 만들고 있는 X 프로젝트에 예시를 적용하여 설명하겠습니다.
X의 경우 수많은 서비스를 제공하고 있습니다. 단순 포스팅 부터, 알림, 댓글, DM, 좋아요, 공유 .. 등 등 수만은 비즈니스 로직이 소프트웨어에 있을텐데요. 만약 Like기능에 문제가 생기면 어떻게 될까요?
모놀리식 아키텍처를 적용했다면, 당연히 서버는 멈추게 됩니다. 근데 이런 사소한(?) 서비스 때문에 전체 서비스를 멈추는게 효율적이라고 할 수 있을까요??
물론 정말 중요한 서비스라면 당연히 서버를 멈추는게 맞습니다만, 좋아요는 그렇게 까지 중요하다고 판단되진 않습니다. 물론 당장 좋아요를 누르지 못하는게 조금은 불편할 수 있겠지만, 다른 기능들은 여전히 살아있으니 서버를 닫을 필요는 없습니다.
MSA
이를 해결하기 위해 MSA를 많은 기업에서 사용하게 되었습니다. 앞서 설명했다 싶이 모놀리식과는 반대되는 개념으로, 가능한 많은 서비스를 쪼개어 설계하는것이 핵심이 되겠습니다.
클라이언트에게 직접적으로 데이터를 전달하는 FrontServer를 두고(없을 수도 있습니다), 글쓰기, 좋아요, 알림, DM 등 모든 서비스를 각기의 서버로 쪼개어 설계합니다.
Front Server는 각 Service Server의 프론트가되며, 서로 통신을 통해 데이터를 주고 받습니다. 아래는 Amazon의 Jeff Bazos가 MSA에 관해 언급한 내용입니다.
MSA 아키텍쳐 실습
프로젝트를 진행하면서 헷갈렸던 부분을 정리하고 넘어가고자 합니다. 일단 연습환경 자체가 하나의 컴퓨터이고, 하나의 DB안에 모든 데이터가 들어가 있는데, 이를 강제적으로 분리하여 MSA를 구현하고 있습니다.
그러다 보니 Table간의 Join에 대해서 헷갈리는 부분이 많았었는데, 이를 여기서 정리하고 넘어가고자 합니다.
🤔 테이블을 Join해야 할 일이 생기면 어떻게 처리를 해야할까?
예를 들어 다음과 같은 상황을 고려해 볼 수 있습니다.
Q. 다음과 같은 기능을 구하고자 한다. 어떻게 설계할지 고민해보자.
👉 게시글에 좋아요를 누른 전체 유저 정보를 받아오려고 한다. UserServer는 User정보를 담은 DB를,
LikeServer는 Like정보를 담은 DB를 가지고 있다. 잉때 boardId를 클라이언트가 넘기면 MSA 아키텍쳐로
구현된 FrontServer에서 UserList를 클라이언트에게 보내는 로직을 구현하라.
원래 하나의 서버에 모든 서비스가 구현되어 있다면 쉽게 Join을 통해서 유저 정보를 데이터로 넘길 수 있겠습니다만, 현재는 각 서버가 나눠져있고, 서버별로 데이터도 다 나눠져 있습니다. 이를 MSA에서는 어떻게 데이터를 처리해야 할까요?
질문에 대한 답은 다음 게시글에 올려보도록 하겠습니다.