[Etc] MSA 적응기 - 3(결론)

MSA로 프로젝트 구성 시 주의할 점

앞서 MSA 의 단점에서 언급했던 내용들이지만 다시 정리해봅니다.

1. 서버 간 통신에서의 성능저하

   1. 모놀리식에서는 내부 메소드 호출이었기에 문제가 되지 않았지만, MSA 구조에서는 API통신을 통해 마이크로서비스들 간의 통신이 이루어지기 때문에 네트워크 비용이 발생한다.
   2. 상황에 맞는 통신방법(gRPC, GraphQL 등)을 택해 네트워크 통신 비용을 최소화 할 수 있도록 해야 합니다.

2. 트랜잭션 처리

   1. 모놀리식에서는 트랜잭션에 문제가 생기면 DB에서 제공하는 트랜잭션 제어방법(ACID)를 통해 처리했지만, MSA 구조에서는 요청이 실패하거나 처리 중 오류가 발생했을 경우 별도의 대책이 필요합니다.
   2. SAGA 패턴
   3. 보상 트랜잭션이라는 개념으로 각 서비스별 존재하는 트랜잭션들을 한데 묶는 거시적인 트랜잭션이라고 이해하면 편합니다.
   4. 각 서비스별로 성공/실패가 발생할 경우 여러 로컬 트랜잭션들에서 다음 단계로 이벤트를 전송하고 마지막 트랜잭션 과정에서 데이터의 유효성을 검사한 후 영속처리합니다.
   5. 즉, 여러 로컬 트랜잭션들 중 하나에서 문제가 발생하면 데이터를 원상복구시키기 위한 롤백을 어플리케이션 레이어에서 처리하기 위한 방법입니다.
   6. 물론 모든 단계가 다 보상 트랜잭션이 존재해야 하는 것은 아니므로 구현 복잡도는 생각보다 높습니다.

3. 인증/인가를 어떻게 처리할 것인지

   1. 기존 모놀리식에서는 서버쪽에 유저 정보를 저장하는 서버기반 인증을 많이 사용하였습니다.
   2. 토큰 기반 인증방식을 사용하는 것이 좋습니다.
   3. 확장성이 뛰어납니다.
   4. 서버가 늘어나도 토큰을 인증하는 방식만 알고 있으면 상관없습니다.

   5. 토큰을 클라이언트에 저장하기 때문에, 토큰을 탈취 당한다면 토큰의 유효시간 안에 토큰을 알고있는 누구나 인증이 유효해지는 위험이 존재합니다.

      1. 토큰의 유효시간을 짧게 가져가자.
      2. 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/

읽어주셔서 감사합니다.🖐