[MSA] 마이크로 서비스의 빛과 그림자

MSA 관련 포스팅 한지 1개월... 

 그동안 포스팅을 못한 이유는 여러 가지가 있지만, 아무래도 가장 큰 이유는 스프링에 있다. 후반부로 갈수록 마이크로 서비스 구현 코드를 이해할 수 없었고, 무시하고 계속 진행하기엔 무리가 있다고 판단되었다.

그래서 잠시 MSA는 접어두고 스프링과 JPA, QueryDSL을 학습하는 시간을 가졌고, 학습하면서 그동안 많은 부분을 잘못 알고 있었음을 깨달았다. (사실 모르는데 그냥 넘어간 게 대다수였다.)

아무튼 이제 MSA코드가 잘 읽혀나간다고 생각이 되어 다시 포스팅을 이어나가 보려고 한다.

---

 

마이크로 서비스 구축

• 큰 서비스에서 시작해서 작게 리팩터링 한다.
  처음부터 작은 서비스로 분할하게 되면 단순한 데이터 서비스로 전락할 수 있고, 너무 빠르게 복잡함을 야기시킬 수 있다.
• 서비스 간 교류하는 방식에 먼저 집중한다.
  일단 두 개의 마이크로 서비스로 분할해서 교류를 성공시킨 이후에 더 분할하는 방식으로 진행한다,
• 문제 영역의 이해가 깊어지면 서비스의 책임도 변한다.
  단일 서비스 -> 여러 서비스로 분화, 원래 서비스는 새로운 서비스의 기능을 캡슐화.

-> MSA를 처음부터 완벽하게 설계하기가 어렵기 때문에, 천천히 점진적으로 프로젝트를 진화시키도록 하자.

나쁜 마이크로 서비스

마이크로 서비스가 너무 크게 나뉘어 있다면 다음과 같은 특징을 가지게 된다.

• 책임이 너무 많은 서비스
  비즈니스 로직의 흐름이 복잡하며 지나치게 다양한 규칙을 시행하는 경우
• 많은 테이블을 관리하는 서비스
  서비스 하나당 보통 3~5개의 테이블을 갖는 게 적당하고, 그 이상이라면 분리가 필요한 지 고민해봐야 한다.
• 과다한 테스트 케이스
  테스트를 위해 수백 개의 단위 테스트와 통합 테스트가 필요하다면 리팩터링이 필요할 것이다.

반대로 너무 잘게 나뉘어 있는 경우엔 다음과 같은 특징이 나타난다.

• 한 서비스에 수십 개의 서비스가 접근하게 되는 경우
  잘게 쪼개어진 수십 개의 마이크로 서비스가 하나의 DB에 접근한다면 트래픽 문제가 생길 가능성이 높아진다.
• 지나치게 상호 의존적이다.
  하나의 요청 처리를 위해 서로 계속 호출하게 된다면 하나로 합치는 것을 고려해야 한다.
• 단순한 CRUD의 집합이 되는 경우
  MSA는 비즈니스 로직의 표현이지 Data Source의 추상화 계층을 위함이 아니다.

마이크로 서비스를 사용하지 말아야 할 때

1. 분산 시스템 구축의 복잡성

구축에 많은 리소스가 필요한 것은 마이크로 서비스의 가장 큰 단점이기도 하다.
자동화와 운영 작업에 투자할 의사가 없는 조직이라면 MSA는 지양하는 것이 좋다.

2. 가상 서버/컨테이너 스프롤(*)

마이크로 서비스의 가장 일반적인 배포 모델 중 하나는 한 서버에 하나의 MSA를 배포하는 것이다.
즉, 50개의 서비스로 이뤄져 있다면 50개의 서버가 필요하다는 말이고, 클라우드로 비용 문제는 어느 정도 커버된다고 해도, 운영 작업의 복잡성은 커질 수밖에 없다.

3. 애플리케이션 유형

마이크로 서비스는 높은 회복성과 확장성이 요구되는 대규모 애플리케이션에 적합한 방식이지, 소형 어플리케이션에 적용하는 것은 복잡성만 커지는 결과를 낳게 될 것이다.

4. 데이터 변환과 일관성

마이크로 서비스 사이에 트랜잭션을 처리하는 표준이 없다. 즉, 필요하다면 직접 만들어야 하고, 메세징 큐(MQ) 방식을 사용하여 통신이 가능하지만 MQ는 업데이트 시 지연시간이 발생할 수밖에 없다.

** 스프롤 : 활용도가 낮은 서버가 실제 작업량보다 더 큰 공간과 리소스를 차지하게 되는 현상

 

 

 

마이크로 서비스가 확장성, 회복성이 높고 독립된 서비스는 높은 응집도를 갖는 장점을 가지고 있지만, 이런 장점들 뒤에는 앞서 설명한 여러가지 그림자들이 존재하기에 MSA도입 했을때 발생하는 Trade-Off를 잘 생각해 볼 필요가 있다.