MSA로 프로젝트 구성 시 주의할 점
앞서 MSA 의 단점에서 언급했던 내용들이지만 다시 정리해봅니다.
-
서버 간 통신에서의 성능저하
- 모놀리식에서는 내부 메소드 호출이었기에 문제가 되지 않았지만, MSA 구조에서는 API통신을 통해 마이크로서비스들 간의 통신이 이루어지기 때문에 네트워크 비용이 발생한다.
- 상황에 맞는 통신방법(gRPC, GraphQL 등)을 택해 네트워크 통신 비용을 최소화 할 수 있도록 해야 합니다.
-
트랜잭션 처리
- 모놀리식에서는 트랜잭션에 문제가 생기면 DB에서 제공하는 트랜잭션 제어방법(ACID)를 통해 처리했지만, MSA 구조에서는 요청이 실패하거나 처리 중 오류가 발생했을 경우 별도의 대책이 필요합니다.
- SAGA 패턴
- 보상 트랜잭션이라는 개념으로 각 서비스별 존재하는 트랜잭션들을 한데 묶는 거시적인 트랜잭션이라고 이해하면 편합니다.
- 각 서비스별로 성공/실패가 발생할 경우 여러 로컬 트랜잭션들에서 다음 단계로 이벤트를 전송하고 마지막 트랜잭션 과정에서 데이터의 유효성을 검사한 후 영속처리합니다.
- 즉, 여러 로컬 트랜잭션들 중 하나에서 문제가 발생하면 데이터를 원상복구시키기 위한 롤백을 어플리케이션 레이어에서 처리하기 위한 방법입니다.
- 물론 모든 단계가 다 보상 트랜잭션이 존재해야 하는 것은 아니므로 구현 복잡도는 생각보다 높습니다.
-
인증/인가를 어떻게 처리할 것인지
- 기존 모놀리식에서는 서버쪽에 유저 정보를 저장하는 서버기반 인증을 많이 사용하였습니다.
- 토큰 기반 인증방식을 사용하는 것이 좋습니다.
- 확장성이 뛰어납니다.
- 서버가 늘어나도 토큰을 인증하는 방식만 알고 있으면 상관없습니다.
-
토큰을 클라이언트에 저장하기 때문에, 토큰을 탈취 당한다면 토큰의 유효시간 안에 토큰을 알고있는 누구나 인증이 유효해지는 위험이 존재합니다.
- 토큰의 유효시간을 짧게 가져가자.
- refresh token으로 새로운 토큰을 요청하는 등의 방어로직 필요.
느낀점
당연한 말이지만 모든 프로젝트들이 MSA구조로 전환할 필요는 없습니다.
단지 전 백엔드 사이드를 공부하는 개발자 입장에서, MSA 구조를 맞닥뜨리며 많은 성장을 했다고 생각합니다. 모놀리식 구조에서는 깊게 고민하지 않았던 여러가지 도전적인 과제들을 만나게 되었고, 학습해보고 실무에서 부딪히고 깨지며 얻는 바가 적지 않았습니다.
좀 더 안정적인 설계에 고민하는 시간이 많아지게 되었고, 여러 클라우드 인프라, 여러 개발 언어, 여러 DB를 사용하게 되면서 선택할 수 있는 선택지가 많아졌다고 생각합니다.
비즈니스 측면에서 MSA구조로의 전환이 무조건 정답은 아니지만, 개발자의 측면에서는 MSA 구조를 겪어봄으로써 한층 더 성장할 수 있는 백엔드개발자가 되지 않을까 합니다.
참고 :
https://brunch.co.kr/@maengdev/3
https://www.samsungsds.com/kr/insights/msa_architecture_edm.html
https://www.msaschool.io/
읽어주셔서 감사합니다.🖐