MSA에 대해 배우자 - 2. 데이터 저장 방식을 마이크로화 하자

들어가며

기본적으로 MSA라고 한다면 기본적인 개발적 지식을 함양하고 있는 개발자라면 작은 컴포넌트 단위로 서비스를 분리시켜 각각 관리한다는 점을 이해한다.

그렇기에 생기는 문제점들이 있는데 일단 한번에 넣고 관리하는 기존 방식에서는 생기지 않던 문제점들이

발생하기 시작한다.

그중 가장 문제가 바로 데이터의 저장 , 가공에 대한 부분의 문제가 생긴다.

모든서비스의 기본은 데이터를 주고 받는 것이다. 그 이후에 사용자 편의성을 고려한 기술들과 디자인이 나오는 것이다.

 

(사견)

혹자는 (개발자가 아니지만 IT업계에 오래일한사람 , 개발자지만 고여버려 더이상 새로운 기술의 열정을 잃어버린 사람) 들어갔을때 보이는 디자인이나 그냥 갯수로 때려박는 기능수를 중요하게 말한다.

디자인이야 개발자가 신경쓰면 오히려 이상한일이고 (물론 안한다가 아니라 더 잘하는사람이 낫지않음? 이다.)

그냥 갯수만 많은 기능은 사용자 입장에서 햇갈리만 한다. 어디서 쓸지도 모르는 기능이 왜 필요한가? 단순히 단가 올리기에 급급한 사람들이나 하는 행동이라고 생각한다.

 

다시 본론으로 돌아와 기존 방식에서 서비스만 분리하면 다음처럼 된다.

 

 

이러면 문제점이 무엇인가?

기존 방식에서 서비스만 마이크로화 시키면?

당연히 이렇게 만들면 각 서비스들이 하나의 DB에 들어가 작업을 하게 되는데

만약 같은 테이블을 건드리기 시작하면 데드락 같은 문제가 발생하게 되는 것은 당연하고,

각 서비스가 결국 커플링되어 그냥 컴포넌트로 분리해놓은 큰쓰레기에서 작은 쓰레기 몇개로

변하는 거다. (여기서 쓰레기는 아무런 아키텍처 설계 없이 이렇게 하면 돌아가잖아)

 

그래서 선배개발자들은 db자체도 분리하여 각 서비스에 들어있는 마이크로 DB를

따로 관리하는 방식을 고안해 낸 것이다.

 

이것이 그 많이 들은 Persistance Layer가 된다.

 

 

서비스별로 분리를 해두고 생각하는 것이 시작되는 것이다.

 

근데 이러면 문제가 생긴다.

예를들어 A - B - C가 순서대로 동작하는 프로세스라고 가정하자.

그렇다면 결국 서로 종속성이 발생하게 되고 워터폴 이펙트(Waterfall Effect)가 발생하게 된다.

우리가 흔히 말하는 동기 방식의 아키텍처가 여기서 나오게 되는 것이다.

 

물론 아무 생각 없이 그냥 순서대로 호출하는 것도 동기 방식이지만,

서비스 간의 의존 관계와 트랜잭션, 그리고 비즈니스 흐름의 강한 연결성을 고려해서

의도적으로 동기 방식을 선택하는 경우도 존재한다.

이렇게 하면 단점만 있는 것은 아니다.

---

동기 방식의 장점 – 특히 트랜잭션 처리에서

1. 트랜잭션 처리에 유리하다
   • MSA 환경에서는 각 서비스가 독립된 DB를 갖는 것이 일반적이며,
   • 이로 인해 기존의 단일 DB 기반의 ACID 트랜잭션 처리 방식은 적용하기 어렵다.
   • 하지만 동기 방식으로 서비스들을 연결하게 되면, 마치 하나의 큰 호출 체인처럼 동작하게 되어,
   • 전체 비즈니스 흐름을 하나의 논리적 트랜잭션처럼 다룰 수 있다.
   • 예를 들어 A 서비스가 B를 호출하고, B가 C를 호출하는 구조에서,실패 시 A에서 전체 롤백을 제어하는 방식으로 구성할 수 있다.
   • A → B → C가 모두 성공해야 최종 성공으로 처리할 수 있고,
2. 에러 핸들링과 흐름 제어가 직관적이다
   • 호출이 실패하면 예외를 바로 받을 수 있고,
   • 이를 통해 로직을 명확히 분기하거나 사용자에게 정확한 에러 메시지를 반환하는 것이 용이하다.
3. 비즈니스 흐름이 순차적으로 직렬화된다
   • 순서를 보장해야 하는 프로세스에서 유리하다.
   • 예: 결제 요청 → 재고 차감 → 배송 준비

---

물론 이러한 동기 방식은 다음과 같은 단점도 함께 따른다:

• 전체 요청 지연 시간 증가 (가장 느린 서비스에 전체가 끌려간다)
• 서비스 하나만 느려져도 전체 서비스가 영향을 받음
• 장애 전파의 위험성 (하나가 죽으면 체인이 끊긴다)

---

따라서 동기 방식은 트랜잭션이나 흐름 제어가 중요한 영역에만 국한해서 사용하고,

그 외에는 비동기 이벤트 기반 아키텍처를 활용하는 것이 일반적인 MSA 설계 전략이다.

 

(사람과의 장점이 있다.)

누가봐도 이해하기 편하다.

1. 이걸보고 있는 사람들은 기본적인 이해도를 가진 사람들일 것이라고 예상하여 문제가 없겠지만동기 / 비동기 구분을 못해서 이해못하겠고, 니가 틀렸어 라고하는 사람을 진짜로 같이 일해보니
2. 이런사람들 이해시키기에는 그냥 순서대로 동작하는 걸 보여주는게 더 쉽긴하다.
3. 회사에서 일하다 보면 생각보다 진짜 기본적인 것도 모르는 상사들을 보게된다.

다음 포스트에서는 비동기에 대한 이야기와 함께 찾아오겠다